Livre blanc sur la sécurité de WIGGWIGG

Version : 1.0.2 · Date : 2026-09-10

WIGGWIGG est un produit de numéro de téléphone et d’identité axé sur la confidentialité. Ce document explique, en détail technique, comment on protège vos données : ce qu’on ne peut pas lire, ce qu’on peut lire et pourquoi, la cryptographie qu’on utilise, et où s’arrêtent nos garanties. Il s’adresse à un lecteur technique et sceptique.

Notre noyau cryptographique est ouvert sur github.com/WiggWiggDev/crypto (le paquet @wiggwigg/crypto) : les primitives de dérivation de clé, de scellement et de signature décrites ici sont vérifiables indépendamment de l’application fermée.

1. Résumé et position

• À connaissance nulle par conception. Votre mot de passe, vos entrées de coffre-fort, vos identités et vos contacts sont chiffrés sur votre appareil avec des clés qu’on ne détient jamais. Le contenu de vos messages est scellé une fois stocké, pour la clé de communication de votre compte, que nos clients pris en charge ouvrent après votre connexion et votre déverrouillage, et on détruit notre copie de la clé de scellement (section 5, qui nomme aussi un petit ensemble de messages de la bêta privée qui ne le sont pas encore). Pour un message scellé, on ne détient aucune clé, et on ne peut pas être contraints de produire une clé qu’on n’a pas. Lisez-le tel quel : c’est une affirmation sur un message au repos, et la section 5 expose ce qui se passe avant le scellement.
• Noyau ouvert, pas « code source ouvert ». On a ouvert le noyau cryptographique pour que vous puissiez vérifier comment les clés et les données sont protégées. Le reste de l’application (les surfaces opérationnelles et de lutte contre les abus) est fermé. On ne laisse jamais entendre le contraire.
• Les limites. Les numéros de téléphone et les métadonnées de routage sont lisibles par le serveur parce que le service téléphonique l’exige. Un message que vous envoyez passe chez nous en clair avant d’atteindre l’opérateur, et les messages photo sont vérifiés contre le matériel illégal connu avant d’être stockés : en cas de correspondance, on conserve la photo, et cette copie survit à votre compte. Les communications ne sont pas chiffrées de bout en bout en transit (le réseau téléphonique est antérieur à cette possibilité). On n’a pas encore de confidentialité persistante ni de protection post-quantique. Les options et les exceptions qui déplacent une donnée d’un niveau à l’autre sont à la section 4 ; les limites de fond, aux sections 5, 10 et 11.
• Auto-attesté aujourd’hui, audité de l’extérieur plus tard. Ce document s’appuie sur du code source ouvert et une politique publiée de divulgation des vulnérabilités. Un audit cryptographique et applicatif par un tiers est prévu ; on le publiera une fois terminé et on ne le revendiquera pas avant.

2. Modèle de menace et frontières de confiance

On conçoit la frontière cryptographique du stockage contre un serveur pleinement malveillant, pas seulement honnête mais curieux : on suppose que notre infrastructure peut être compromise, saisie par ordonnance judiciaire ou exploitée par quelqu’un qui ne devrait pas voir vos données, et qu’elle pourrait activement mentir à votre appareil plutôt que se contenter de regarder. La garantie sur les données stockées suppose que le code client qui effectue le chiffrement est légitime et non altéré. Une personne qui contrôle la livraison de l’application web pourrait modifier le code servi lors d’une prochaine session et tenter de capter du texte en clair ou des clés; du code web livré à distance ne peut pas être indépendant du serveur qui le livre. Avec un client légitime et non altéré, une copie de nos données stockées et des clés côté serveur ne peut pas ouvrir le texte chiffré à connaissance nulle, puisque les clés nécessaires vivent sur votre appareil. C’est le modèle de menace retenu par l’analyse cryptographique des gestionnaires de mots de passe publiée à USENIX Security 2026 (Zero Knowledge (About) Encryption, Scarlata et coll.), et c’est celui contre lequel on se mesure; les résidus qu’il nous reste sous ce modèle sont énoncés à la section 10, pas passés sous silence.

On ne défend pas contre un appareil compromis (un logiciel malveillant sur votre propre appareil ou une extension de navigateur malveillante), une compromission active qui modifie l’application web livrée lors d’une prochaine session, ni contre les métadonnées inhérentes au fait de passer un appel ou un SMS sur le réseau public. Voir la section 10.

3. Architecture cryptographique

Toutes les primitives ci-dessous proviennent de bibliothèques auditées (@noble/curves, @noble/hashes, @scure/bip39). On n’écrit pas la nôtre.

• Dérivation de clé : votre mot de passe est étiré avec Argon2id (128 Mio de mémoire, 3 itérations). Elle est coûteuse en mémoire, ce qui la rend résistante au forçage par GPU et ASIC. Les paramètres sont identiques au bit près entre le web et le mobile, pour que vos clés concordent sur tous vos appareils.
• Indirection de la clé de coffre-fort : la clé principale dérivée du mot de passe enveloppe une clé de coffre-fort distincte, propre au compte, et vos données sont chiffrées sous la clé de coffre-fort. Changer votre mot de passe ré-enveloppe la clé de coffre-fort ; la clé sous laquelle vos données sont chiffrées, elle, ne change pas. (Vos entrées sont tout de même réécrites sous de nouveaux nonces lors d’un changement de mot de passe. Ce qui ne bouge pas, c’est la clé, pas le texte chiffré.)
• Chiffrement symétrique : AES-256-GCM (authentifié) pour les entrées de coffre-fort, les identités, les contacts, le contenu des messages et les champs opérationnels côté serveur.
• Scellement par clé publique : le contenu des messages entrants est chiffré avec AES-256-GCM sous une clé à usage unique, elle-même scellée à la clé publique X25519 du compte (X25519-ECDH, HKDF-SHA256, XChaCha20-Poly1305 : un coffre scellé de style libsodium). Si le compte n’a pas encore déposé de clé X25519, la clé de session est plutôt enveloppée en RSA-2048-OAEP, le schéma hérité ; chaque blob enregistre lequel a servi. Les blobs écrits avant l’existence de ce marqueur le laissent vide, et un lecteur traite « vide » comme le schéma RSA. Les deux sont à connaissance nulle (section 5), et le retrait de RSA figure à la feuille de route (section 11).
• Authentification : prouver que vous connaissez votre mot de passe sans le révéler (section 6).
• Séparation des clés : chaque clé dérivée reçoit sa propre étiquette de domaine (HKDF-SHA256 sous une chaîne info distincte, ou HMAC-SHA256 sur une étiquette distincte), donc compromettre l’une n’en livre jamais une autre. Deux familles ne viennent délibérément pas de la clé principale : la clé de coffre-fort est aléatoire et seulement enveloppée par elle, et les clés de récupération viennent de votre phrase BIP39 (section 7).
• Agilité cryptographique : chaque schéma propre au compte porte une version, et les lignes de coffre-fort, d’identité, de contact et de message enregistrent la version de clé sous laquelle elles ont été écrites, pour qu’on puisse faire pivoter une primitive sans casser les données stockées. Quelques champs côté serveur plus petits (étiquettes de contact, partages de coffre-fort, le numéro conservé sur une ligne du journal d’appels) n’en portent pas encore : les faire pivoter veut dire re-chiffrer plutôt qu’aiguiller. C’est ainsi que la mise à niveau post-quantique de la section 11 arrive sans réécriture.

4. Classification des données

Ce qui est, ou n’est pas, à connaissance nulle :

Les niveaux portent le nom de qui peut lire la donnée, parce que c’est la seule distinction qui change ce qu’une fuite ou un mandat exposerait. L’application pose les mêmes noms sur chaque étiquette de champ, pour qu’une étiquette dans le produit et une ligne de ce tableau veuillent dire la même chose.

Après l’acceptation de la Déclaration de confidentialité actuelle, WIGGWIGG inscrit automatiquement jusqu’à 10 navigateurs ou appareils mobiles actifs par compte lorsque la personne se connecte et déverrouille ses données, afin qu’ils puissent recevoir ses appels. Le code de reconnaissance aléatoire est conservé seulement sur l’appareil qui le crée. Il parvient transitoirement à notre serveur quand l’appareil demande à être reconnu, mais n’y est ni journalisé ni stocké. On conserve plutôt une empreinte à sens unique, à clé et limitée au compte. Tant qu’une inscription est active, le serveur peut lire le lien au compte, un identifiant interne aléatoire, la classe navigateur ou mobile, le numéro d’ordre propre au compte, les identifiants de téléphone associés, l’état du cycle de vie et les dates d’inscription, de disponibilité et d’activité du cycle de vie. Pour chaque numéro de téléphone, le serveur peut aussi lire si l’acheminement comprend tous les appareils inscrits ou un sous-ensemble personnalisé, puis déduire les liens aux appareils choisis dont il a besoin pour les appels entrants. Ce choix touche seulement la sonnerie des appels entrants; un appareil inscrit et autrement autorisé peut encore faire des appels même s’il n’est pas choisi pour sonner. Le nom personnalisé est chiffré sous la clé de coffre-fort du client, donc on ne peut pas le lire.

Un refus ou un retrait historique propre aux appareils d’appel est conservé comme un état d’acheminement en pause, lisible par le serveur, jusqu’à une réactivation explicite après une authentification récente. Aucune date distincte n’est conservée pour ce changement d’état. Retirer un appareil arrête immédiatement les nouveaux appels vers son inscription. Le nettoyage chez le fournisseur peut prendre plus de temps. La base permet à l’appareil de devenir terminal seulement après la disparition confirmée de tous les points d’accès chez le fournisseur; cette transition efface la classe, le numéro d’ordre, les liens aux téléphones, les dates et le nom personnalisé chiffré. Le dossier contre la réutilisation qui reste contient seulement le lien au compte, l’identifiant interne opaque, l’empreinte à clé avec sa version de clé et l’état révoqué. Il est immuable et subsiste seulement jusqu’à la suppression du compte ou au retrait plus hâtif de cette clé d’empreinte. Tant que le dossier existe, l’ancien code ne peut pas créer une nouvelle inscription. Les clients WIGGWIGG officiels produisent un nouveau code lors d’une nouvelle inscription. Un registre distinct d’événements liés au compte, contenant seulement un identifiant interne aléatoire, le lien au compte et l’heure de la tentative, fait respecter les limites calculées sur une heure et sur 24 heures, puis est balayé après sa fenêtre de 24 heures.

L’inscription ne demande aucune déclaration de pays. Pendant l’accès anticipé, les numéros de téléphone, l’essai de sept jours d’un numéro canadien et tout achat exigent une province canadienne confirmée pour les taxes. L’activation de l’essai téléphonique et le paiement par carte, en bitcoin ou en crédits valident séparément une province choisie et confirmée par la personne. Cette province est conservée pour le calcul des taxes; le formulaire de carte de Stripe peut recueillir un code postal séparément.

Les exceptions : les numéros de téléphone sont lisibles par le serveur parce que le réseau doit router vos appels.

Notre copie stockée de votre adresse E911 est à connaissance nulle, et nos serveurs ne la déchiffrent jamais. Voici la partie honnête : pour que le 911 fonctionne, votre appareil nous envoie l’adresse en clair une fois, à la configuration, pour qu’on puisse la valider et l’enregistrer chez notre fournisseur, qui la conserve pour acheminer les appels d’urgence. La répartition utilise sa copie. On ne garde pas la nôtre en clair, mais on l’a bel et bien vue à ce moment-là, et aucun chiffrement côté client n’y change quoi que ce soit.

Le contenu de la messagerie vocale est à connaissance nulle lorsqu’une clé de communication de compte utilisable est trouvée, sauf si vous activez « Permettre l’écoute par téléphone » pour un numéro (désactivé par défaut, et réglé par numéro plutôt que par compte). Une fois activé, la nouvelle messagerie vocale de ce numéro est conservée sous une forme que nos serveurs peuvent lire, pour pouvoir vous la jouer sur la ligne téléphonique, et il n’existe aucune copie scellée à côté. Elle n’est pas non plus chiffrée sous une clé à nous : c’est un enregistrement en clair, protégé au repos par notre fournisseur de stockage et par rien d’autre. Le numéro de l’appelant sur ces messages devient lisible par le serveur lui aussi. Même si l’écoute par téléphone est désactivée, quand le compte ne possède aucune clé de communication utilisable, on sauvegarde la nouvelle messagerie sous cette même forme lisible par le serveur plutôt que de la perdre; le serveur journalise ce recul de sécurité. Une fois une clé utilisable disponible, désactiver l’écoute par téléphone ramène immédiatement la nouvelle messagerie au scellement par la clé du compte. Ça ne rescelle pas la messagerie qu’on détient déjà, ni sur le serveur ni pendant la passe web automatique. L’ancienne messagerie lisible par le serveur le reste jusqu’à ce qu’une maintenance distincte puisse prouver que l’objet exact conservé a été supprimé après un rescellement réussi. Laissez l’écoute par téléphone désactivée à moins d’en avoir besoin : c’est la plus grosse chose que vous pouvez choisir de céder ici.

Vos contacts sont à connaissance nulle sauf si vous activez « Reconnaissance des contacts lors des appels » (désactivée par défaut), qui conserve une empreinte à clé du numéro de chaque contact afin de reconnaître un appelant ou un expéditeur connu lors d’un appel ou d’un texto entrant, ce qui rend ces numéros récupérables par nos serveurs tant que c’est activé. Le désactiver efface ces empreintes de nos systèmes actifs, et les copies de sauvegarde chiffrées habituelles expirent en une trentaine de jours au plus.

Deux autres, qui ne sont pas des options mais des conséquences du fonctionnement même de la fonctionnalité :

• Les messages d’accueil, annonces et invitations de vos lignes sont lisibles par nos serveurs, en texte comme en audio, parce que le réseau téléphonique doit les jouer pendant l’appel et que l’appelant n’a ni compte ni clé.
• Les intros que vos appelants enregistrent (filtrage d’appel) sont lisibles par le serveur, toujours. Le réseau téléphonique vous joue cet extrait au moment où l’appel sonne, ce qui exige un contenu qu’on peut récupérer. Comme l’appelant n’a ni compte ni clé chez nous, aucun scellement à votre seule intention n’est réalisable ici.
• Les réponses automatiques sont lisibles par le serveur, puisque c’est notre serveur qui les rédige et les envoie en votre nom.

Ce sont des compromis assumés pour un service téléphonique fonctionnel. On les énonce pour que vous puissiez en juger.

Un mot honnête sur les index aveugles : un HMAC à clé d’une valeur à faible entropie reste énumérable pour quiconque détient la clé : l’espace des numéros de téléphone se parcourt par force brute. Cette protection vise une fuite de la base sans la clé ; elle ne tient pas devant une compromission du serveur en marche, qui la détient.

Certains champs chiffrés côté serveur sont liés à leur contexte (les identifiants SIP et les graines TOTP sont cryptographiquement liés à leur propriétaire), pour qu’un texte chiffré ne puisse pas être déplacé d’un enregistrement à l’autre. On est franc sur la portée : ce lien ne couvre pas encore tous les champs serveur, et les numéros de téléphone, notamment, n’y sont pas encore. Étendre ce lien à chaque champ serveur, ainsi qu’une dérivation de clé par utilisateur, figure à notre feuille de route publiée.

5. Communications : « aveugle au serveur », pas à confidentialité persistante

Chaque SMS, MMS ou message vocal écrit par notre méthode de scellement actuelle est scellé à la clé publique de communication du compte (X25519, ou le repli RSA-2048 de la section 3 si le compte n’a pas encore de clé X25519), que vous l’ayez envoyé ou reçu. Sur le chemin X25519, on génère une paire de clés d’expéditeur, on l’utilise une seule fois et on la détruit dès que le message est stocké ; le repli RSA, lui, chiffre directement vers la clé publique de votre compte, donc il n’y a aucune clé d’expéditeur au départ. Dans les deux cas, le résultat est le même : pour un message scellé, on ne conserve aucune clé capable de le lire : ni au repos, ni plus tard, ni sous un mandat qui nous vise. On peut être contraints de produire les octets chiffrés ; on ne peut pas être contraints de produire une clé qu’on n’a pas.

Cette phrase a une portée précise, et c’est ainsi qu’on l’entend. C’est une affirmation sur un message déjà scellé et au repos, pas une promesse générale sur tout ce qu’un mandat atteint. Voici la liste complète des exceptions, y compris les parties les moins confortables à écrire.

Un petit ensemble de communications conservées depuis la bêta privée est encore sous notre ancien chiffrement côté serveur. On peut les lire au repos, et la phrase ci-dessus ne les couvre pas. Il n’y a pas que des corps de messages : la plupart sont le numéro de l’autre partie dans un journal d’appels, et le reste est de l’audio et des numéros d’appelant de messagerie vocale, une pièce jointe MMS et des corps de SMS. Ils appartiennent à une poignée de comptes dont les lignes conservées n’ont pas terminé la passe de rescellement web prise en charge depuis l’arrivée des clés de communication de compte. Une connexion dans l’application mobile peut approvisionner la clé du compte, mais elle ne démarre pas cette passe; aujourd’hui, seuls la connexion et le déverrouillage dans un client web pris en charge la démarrent automatiquement. Cette passe limitée peut resceller jusqu’à 50 lignes de SMS admissibles. Elle ne migre ni les messages vocaux de la bêta privée, ni les numéros des anciens journaux d’appels, ni les pièces jointes MMS, ni les versions d’objets conservées, ni toutes les lignes de SMS restantes d’un seul coup. Ces copies exclues restent lisibles par nos serveurs jusqu’à des passes ultérieures ou une maintenance distincte. En particulier, la migration des messages vocaux est retenue parce que les anciennes lignes ne conservent pas la version exacte de l’objet nécessaire pour prouver la destruction de l’audio lisible par le serveur. On garde cette exception publiée tant que chaque ligne touchée et chaque copie conservée n’a pas convergé.

Avant que cette passe lise le moindre texte clair conservé, le client web doit ouvrir un défi ponctuel et de courte durée, scellé à la clé de communication X25519 actuelle et exacte du compte. Le serveur ne conserve que l’empreinte du défi, consomme une preuve réussie une seule fois et revérifie l’empreinte de la même clé publique au remplacement de chaque ligne. Si l’enveloppe de la clé privée est endommagée, correspond à une autre clé, expire, est rejouée ou entre en concurrence avec un changement de clé, la passe s’arrête et la source lisible par le serveur reste en place.

Le parcours actuel des notifications iOS conserve une clé plus large que ce dont un aperçu a besoin. Après le premier déverrouillage de l’appareil, l’app recopie la paire de clés brute de communication du compte dans un trousseau partagé AfterFirstUnlockThisDeviceOnly, afin que l’extension de service de notifications puisse déchiffrer du contenu pendant que l’appareil est verrouillé. Elle le fait même si le réglage d’affichage des notifications est Rien. Cette copie subsiste lorsque le coffre-fort ou l’appareil se verrouille et peut ouvrir tout l’historique scellé pour la clé du compte, pas seulement les aperçus de notifications. L’app tente de l’effacer à la déconnexion, mais la déconnexion ne bloque pas et ne réessaie pas si l’effacement échoue. L’élément du trousseau reste sur cet appareil et n’est pas téléversé à WIGGWIGG. Android utilise une clé d’affichage des notifications dérivée séparément, dont la portée est limitée aux aperçus. On ne généralise pas à iOS cette propriété plus étroite d’Android. Remplacer la copie iOS par une clé étroite et vérifier son effacement reste un suivi de sécurité côté client.

Avant le scellement, un message passe chez nous en clair. Un message que vous envoyez nous parvient en texte clair, parce qu’on doit le remettre à l’opérateur. On le scelle au moment de le stocker et on n’en garde aucune clé ensuite, mais on l’a bel et bien eu en mémoire entre les deux. C’est scellé au repos, pas de bout en bout (section 11).

On compare les messages photo aux banques d’images illégales connues, et cette vérification lit la photo. Faire cette vérification est notre décision, pas une obligation que la loi nous impose ; ce que la loi impose, c’est ce qui suit une correspondance confirmée, plus bas. Elle s’exécute en mémoire, sur nos propres serveurs, avant le stockage. Ce qui parvient à un détecteur est une empreinte à sens unique, jamais la photo : chaque détecteur compare cette empreinte à sa banque et répond. On en utilise deux, un canadien et un américain, et aucun ne reçoit d’image. Quand une photo est saine, on ne conserve pas la photo, et on n’en garde aucune empreinte. Il reste une ligne de verdict indiquant qu’une vérification a eu lieu et qu’elle n’a rien trouvé, effacée au plus tard après 90 jours (section 9).

Quand une vérification établit une correspondance, on conserve la photo elle-même. Il y a deux types de correspondance, et ils ne se valent pas : on les distingue ici plutôt que de laisser le plus sévère parler pour les deux.

Pour le matériel confirmé illégal, la loi nous oblige à en informer un agent de la paix. L’image est écrite dans une quarantaine scellée, placée sous obligation de conservation, et elle accompagne notre signalement à l’unité de la GRC qui reçoit ces dossiers, le Centre national contre l’exploitation des enfants, à Ottawa. Le signalement reste au Canada.

Pour le second type, le détecteur canadien signale une photo comme nuisible pour les enfants sans la classer parmi le matériel confirmé illégal. On la bloque et on la conserve de la même façon, et aucune loi ne nous obligeait à la garder. C’est notre décision, et on préfère la nommer comme telle plutôt que de l’abriter derrière le mot « obligatoire ». Cette catégorie n’est pas un constat de légalité : elle est volontairement prudente pour valoir dans plusieurs pays, et la définition canadienne est plus large. Rien n’est signalé automatiquement, mais si un examen conclut que le matériel est criminel au Canada, on le signale.

Une fois conservées, les deux copies sont traitées pareil : on peut ouvrir et consulter la photo, supprimer votre compte ne l’enlève pas, et un mandat l’atteint. On ne fixe de date de fin à aucune des deux, et cela aussi relève de notre choix et non d’une obligation légale. Les deux valent autant pour une photo qu’on vous a envoyée que pour une que vous avez envoyée. C’est la seule catégorie où on détient votre contenu lui-même plutôt qu’une clé, et on préfère vous le dire ici que vous laisser le découvrir.

Les exceptions de la section 4 portent elles aussi une clé qu’on détient : la messagerie vocale quand l’écoute par téléphone est activée ou quand le compte ne possède aucune clé de communication utilisable, les enregistrements de filtrage d’appel, le texte des réponses automatiques, et les messages d’accueil, annonces et invitations de vos lignes, en texte comme en audio. Pendant au plus trente jours, on garde aussi un lien qui nous permet de récupérer une photo chez l’opérateur.

Les métadonnées ne sont pas du contenu et ne sont pas scellées : les enregistrements détaillés d’appel (qui a appelé qui, quand, combien de temps) sont inhérents à la téléphonie. On les conserve, selon la rétention décrite à la section 9. Sous la méthode actuelle, le numéro de l’autre partie dans votre journal de messages est scellé avec le message. Dans un journal d’appels, ce numéro est scellé lorsqu’une clé de communication de compte utilisable est trouvée. Si le compte n’a aucune clé utilisable ou si la recherche de clé du journal d’appels échoue, on stocke ce numéro sous la clé du serveur pour ne pas interrompre l’appel en cours, et on journalise ce repli. Un index de recherche côté serveur portant sur le même numéro se trouve à côté des deux formes (le paragraphe honnête de la section 4 s’applique ici aussi); le fait qu’un appel ou un message ait eu lieu n’est pas scellé du tout.

Ce que ce n’est pas : ce n’est pas de la confidentialité persistante. Vos messages sont scellés à la clé de communication à long terme de votre compte, soit la même clé que chaque appareil que vous déverrouillez utilise pour relire votre historique. Si votre clé privée était compromise, votre historique stocké pourrait être déchiffré. On optimise pour l’aveuglement au serveur (un serveur ou un mandat ne peut pas lire votre contenu), qui est la propriété atteignable et utile pour un historique de messages stocké et relisible. La vraie confidentialité persistante entre en conflit avec un historique multi-appareils et n’est pas une chose qu’on revendique. Le durcissement post-quantique de ce sceau figure à notre feuille de route (section 11).

Le transit sur le réseau opérateur (SS7/SIP) est visible par les opérateurs comme tout service téléphonique. Pour un chiffrement de bout en bout en transit, utilisez Signal ou WhatsApp avec votre numéro WIGGWIGG.

6. Authentification

Votre mot de passe ne quitte jamais votre appareil. Les nouveaux comptes, ainsi que les comptes de la bêta privée qui ont terminé leur migration, utilisent un défi-réponse Ed25519 pour se connecter : votre appareil dérive une clé de signature à partir de votre clé principale (Argon2id), le serveur conserve la clé publique correspondante, et vous prouvez la possession en signant un défi serveur à usage unique de 60 secondes. Pour ces comptes, la clé publique stockée ne peut pas être rejouée pour se connecter.

Certains comptes de la bêta privée conservent encore un vérificateur de connexion statique jusqu’à ce qu’un client WIGGWIGG à jour termine la migration pendant une connexion réussie. Pour ces comptes, le vérificateur stocké équivaut à un jeton : s’il fuit, une autre personne pourrait se connecter au compte. Il ne révèle ni le mot de passe ni la clé du coffre-fort. Une fois que le serveur a enregistré la clé publique prouvée par le client, le vérificateur statique n’est plus accepté pour la connexion et les prochaines connexions utilisent le défi-réponse.

Authentification à plusieurs facteurs : WebAuthn/clés d’accès (résistantes à l’hameçonnage) et TOTP. Anti-hameçonnage : avant que vous tapiez votre mot de passe complet, le site se prouve à vous avec un repère propre au compte (phrase, couleurs, avatar, audio optionnel) affiché sur votre appareil à partir d’une graine qu’on ne conserve que chiffrée. La graine est scellée sous une clé dérivée des premiers caractères de votre mot de passe, les mêmes qui déclenchent l’affichage (vérification partielle HMAC-SHA256), de sorte que le serveur ne détient jamais de repère qu’il pourrait afficher, et qu’une fuite de la base de données seule ne peut pas forger votre repère sans forcer ces caractères contre la fonction d’étirement de clé. Ici, cette fonction est PBKDF2-SHA256 plutôt que l’Argon2id de la section 3 : cette vérification doit s’exécuter avant le déverrouillage de votre coffre-fort, alors elle reste fixée à l’ancienne.

Une limite honnête. La protection est bornée par cette faible entropie de quelques caractères, elle n’est pas incassable : ce qu’elle déjoue vraiment, c’est la contrefaçon de masse à partir d’une base de données volée, le scénario réellement exploité après une brèche.

7. Récupération de compte

La récupération utilise une phrase BIP39 de 24 mots (256 bits d’entropie) que vous détenez et qu’on ne voit jamais. Votre appareil en dérive trois valeurs, séparées les unes des autres par leur propre étiquette de domaine : une clé X25519, à laquelle votre matériel de clé est scellé ; une clé de signature Ed25519, qui autorise un changement de mot de passe au moyen d’une signature sur un défi serveur à usage unique ; et un vérificateur symétrique plus ancien, qui est ce qui garde aujourd’hui l’entrée du parcours de récupération.

On conserve les deux clés publiques, un haché du vérificateur, et un blob scellé qu’on ne peut pas ouvrir. Soyons clairs sur ce vérificateur, parce que c’est le point le plus faible de cette section : contrairement aux deux clés, c’est un secret partagé et non un secret public, et votre appareil nous l’envoie à la configuration puis à chaque tentative de récupération. Une fuite de notre base ne le livre pas, puisqu’on n’en garde qu’un haché. Mais on le voit passer, et c’est justement la propriété que les deux clés sont conçues pour ne pas avoir. Le remplacer par le défi-réponse Ed25519, qui n’envoie aucun secret, figure à la feuille de route (section 11).

Ce blob scelle votre clé de coffre-fort, pas votre clé principale. La distinction compte : la clé de coffre-fort ne change pas quand vous changez de mot de passe, donc l’enveloppe de récupération n’a jamais à être re-scellée automatiquement. Un re-scellement automatique serait exactement la prise qu’un serveur malveillant chercherait, en substituant sa propre clé de récupération pour se rendre capable d’ouvrir l’enveloppe ; en scellant une clé stable, cette prise n’existe pas. Un changement de mot de passe lancé depuis une récupération est autorisé par une signature Ed25519 de votre phrase sur un défi serveur à usage unique de deux minutes, et votre appareil vérifie que la clé récupérée déchiffre bien vos données avant de re-chiffrer quoi que ce soit.

La clé de récupération de confiance est en outre épinglée dans vos préférences chiffrées, que le serveur ne peut pas lire : si la clé qu’il présente ne correspond pas à celle que votre appareil a épinglée, l’opération s’arrête et vous demande la confirmation de votre phrase, au lieu de sceller à l’aveugle sous une clé fournie par le serveur. Cet épinglage existe aujourd’hui dans l’application web. Un compte créé sur le téléphone est épinglé la première fois que vous vous connectez sur le web ; d’ici là, re-sceller votre clé de récupération vous demande de confirmer votre phrase plutôt que de faire confiance à la clé proposée par le serveur.

Une limite pratique, qu’on énonce ici plutôt que de vous la faire découvrir au pire moment : la récupération se termine dans l’application web. L’application téléphone met votre phrase en place et vous dirige vers le site pour vous en servir.

Si vous perdez à la fois votre mot de passe et votre phrase de récupération, vos données à connaissance nulle sont irrécupérables par conception : on ne peut pas les déchiffrer pour vous. Il n’existe aucune procédure administrative qui ouvre votre compte à votre place : la seule action administrative qui touche à votre mot de passe force une réinitialisation, et il faut quand même votre phrase de récupération pour la terminer.

8. Gestion et rotation des clés

Les clés côté serveur vivent dans un coffre de secrets géré, validé au démarrage. La clé de champ opérationnel est un anneau versionné, enveloppé par une clé KMS gérée ; la clé d’index aveugle et la graine de métadonnées par utilisateur sont des secrets gérés uniques, pas des anneaux. Chaque schéma (KDF, clé de coffre-fort, sceau asymétrique, clé serveur) porte une colonne de version, conçue pour une rotation sans interruption : les nouvelles écritures utilisent la version courante, et les lecteurs traitent la version stockée comme une piste rapide plutôt qu’une vérité : si elle ne déchiffre pas, ils essaient chaque clé de l’anneau (sans risque, puisque l’étiquette d’authentification GCM garantit que seule la bonne clé produit un texte clair valide) et un repli réussi incrémente un compteur d’écart, plutôt que d’être absorbé en silence. Ce compteur vit dans le processus aujourd’hui et n’est pas encore exporté vers nos métriques ; c’est une lacune qu’on est en train de combler. La garantie d’intégrité, c’est le contrôle de retrait ci-dessous, pas l’étiquette de version. Les colonnes qui enveloppent vos clés, soit l’enveloppe de la clé principale, celle de la clé de coffre-fort et les deux enveloppes de clé privée, sont protégées par des déclencheurs de base de données qui refusent de les vider ou de les mettre à nul.

En pratique, une rotation complète de la clé serveur se fait aujourd’hui en fenêtre de maintenance plutôt qu’à chaud : les deux versions cohabitent dans l’anneau, donc tout se déchiffre pendant la transition, et l’ancienne version n’est retirée qu’après une vérification qui refuse de la lâcher tant qu’une seule ligne en dépend encore. Pour l’anneau de chiffrement des champs, ce contrôle déchiffre réellement un échantillon avant de lâcher prise. La clé d’index aveugle est vérifiée plus faiblement, en comptant les étiquettes de version sur les tables qui en portent une ; une vérification qui re-dérive un index, et des étiquettes pour les tables qui n’en ont pas encore, sont en cours. On décrit ici le mécanisme, pas une opération de routine, et on ne revendiquera la rotation à chaud qu’une fois qu’elle sera réellement exercée de bout en bout.

9. Sécurité de l’application et de l’infrastructure

• Sécurité au niveau des lignes : la base de données refuse elle-même de remettre à un compte les lignes d’un autre, et l’application s’y connecte avec un rôle qui ne possède pas ces tables et ne peut pas contourner leurs politiques : les politiques s’appliquent donc bien à elle. Sur les tables les plus sensibles (coffre-fort, identités, messages, contacts, consentements, clés de récupération), la politique appelle une fonction de contexte qui lève une erreur quand le contexte de la requête manque, pour qu’un oubli échoue bruyamment au lieu de ne rien retourner en silence ; ces tables portent aussi FORCE ROW LEVEL SECURITY, qui soumet également le propriétaire de la table. Sur les autres tables protégées, un contexte manquant ne donne aucune ligne plutôt qu’une erreur. Deux garde-fous statiques s’exécutent avant qu’un changement n’entre : l’un exige que chaque table liée à un compte porte une politique ou une exemption écrite et revue, l’autre rejette toute requête émise hors d’un contexte lié. Certaines tables sont délibérément exemptées (recherches avant authentification, webhooks de fournisseurs qui doivent trouver un propriétaire avant de le connaître, et registres de sécurité et d’intégrité), chacune avec sa raison consignée. Amener les tables les plus faibles au mécanisme le plus fort n’est pas terminé.
• Transport : TLS partout, avec redirection de HTTP vers HTTPS à chaque bordure ; en-têtes de sécurité (CSP/HSTS), où la politique de sécurité du contenu est appliquée par les applications plutôt qu’au réseau de diffusion de contenu (RDC) ; CSRF défendue par des témoins SameSite et une liste blanche d’origine stricte.
• Réseau : chaque service auxiliaire tourne dans son propre VPC, joint par une connexion d’appairage point à point dédiée, et aucune passerelle NAT n’est jamais partagée entre eux.
• Chiffrement au repos : la base de données, ainsi que les compartiments de stockage qui portent vos contenus, les pièces de preuve et les journaux d’audit, sont chiffrés avec des clés AWS KMS gérées par nous ; la cache et les compartiments de journaux d’accès sont chiffrés avec des clés gérées par le fournisseur. Tout cela se trouve sous le chiffrement applicatif et à connaissance nulle ci-dessus.
• Défense en profondeur : un pare-feu applicatif géré protège la bordure publique de l’application, avec détection de menaces en continu, journalisation d’audit du plan de contrôle, journaux de flux sur les réseaux applicatifs, et sauvegardes chiffrées et versionnées. Notre site vitrine statique est servi par un autre fournisseur et ne se trouve pas derrière ce pare-feu ; il ne porte aucune donnée de compte.
• L’observabilité est pseudonyme par défaut : notre base de données applicative ne conserve aucune adresse IP brute. Chaque IP qu’on enregistre est hachée sous un secret serveur, par compte et par jour, ce qu’une fuite de la base seule ne permet pas d’inverser. Les RDC qui servent votre application et vos médias sont délibérément configurés pour ne conserver aucun journal d’accès. Les répartiteurs de charge et le pare-feu devant eux journalisent bel et bien les adresses IP de connexion, comme tout service internet, et la piste d’audit du plan de contrôle de notre fournisseur infonuagique conserve l’adresse source des appels administratifs pendant plusieurs années, parce qu’une piste d’audit qu’on peut rogner ne sert à rien. La télémétrie est conçue pour ne porter aucune identité d’utilisateur, et les registres réservés au serveur qu’on garde pour la sécurité et l’acheminement (les verdicts des vérifications de contenu qui n’ont rien trouvé, cache de recherche d’opérateur, compteurs de vélocité antipourriel) sont purgés par un balayage à 90 jours. Votre historique d’appels et de messages n’est pas sur cette horloge : il reste jusqu’à la fermeture de votre compte. Soyons précis sur ce que supprimer un message fait aujourd’hui : cela retire le message de vos applications, et la ligne demeure chez nous jusqu’à la fermeture de votre compte. Il n’existe pas encore de commande pour supprimer votre historique d’appels. Les deux sont à la feuille de route ; d’ici là, on préfère que vous le sachiez.
• On efface ce qu’on n’a plus besoin de garder. Une vérification de numéro expirée ne conserve pas votre numéro : passé un court délai, on réduit l’enregistrement à la preuve de possession dont la protection anti-usurpation a besoin (une empreinte à clé, pas le numéro), et on efface le numéro chiffré lui-même ainsi que le NIP de vérification. Ce qu’on ne garde pas, une compromission ne peut pas le révéler.
• On ne conserve pas votre agent utilisateur. La chaîne complète que votre navigateur envoie est une empreinte à faible entropie : la hacher la masque sans la supprimer. On la réduit dès la collecte à une étiquette grossière tirée d’une liste blanche fixe de 49 valeurs, comme « Chrome / macOS » : sans version, sans modèle d’appareil, sans clé. Ce qui pourrait vous distinguer est jeté avant d’être écrit. C’est de la minimisation des données, pas de l’anonymisation : l’étiquette reste sur une ligne qui porte votre identifiant de compte.
• Minimisation des données des fournisseurs : l’opérateur n’apprend que ce que le routage exige. Le processeur de cartes (Stripe) ne vous identifie auprès de nous que par un identifiant opaque, jamais par un nom, un courriel, un numéro ou une adresse ; il voit en revanche ce que vous avez acheté, parce qu’une ligne de reçu doit dire de quoi il s’agit (« Numéro de téléphone », un changement de forfait, une option), avec la juridiction fiscale applicable. On relit chez eux un paiement complété pour le confirmer, et on ne leur demande rien d’autre à votre sujet. Le processeur Bitcoin (Blockonomics) ne voit qu’une adresse de paiement et un montant.

10. Limites et non-objectifs

On les énonce clairement :

• Appareil compromis. Un logiciel malveillant ou une extension malveillante sur votre appareil peut lire vos données après que vous l’avez déverrouillé. Le chiffrement côté client ne peut pas défendre un client compromis. Dans les versions iOS actuelles, la copie destinée à l’extension de notifications décrite à la section 5 garde aussi la clé de communication du compte disponible après le premier déverrouillage de l’appareil, même quand le coffre-fort ou l’appareil est verrouillé, jusqu’à ce que son effacement à la déconnexion réussisse.
• Aucune confidentialité persistante sur les messages stockés (section 5).
• Intégrité du coffre-fort. Chaque entrée est scellée à sa propre identité : un serveur ne peut ni la lire, ni la déplacer vers un autre champ ou un autre compte. Pour l’ensemble qu’on vous renvoie, un manifeste authentifié sous votre clé de coffre-fort (section 11) est actif : votre appareil détecte si un serveur omet une entrée ou en restitue une version antérieure. La deuxième couche, la liaison de version par entrée (« zk2 », section 11), est active elle aussi : les nouveaux comptes l’ont dès le départ. Un compte existant y passe en une passe à sa prochaine connexion sur le web. Si vous n’utilisez que l’application téléphone, vos entrées y passent une à une, à mesure que vous les modifiez, donc d’ici là certaines restent sur la première liaison, sans cette deuxième couche. Deux limites honnêtes demeurent : les deux applications bloquent quand la vérification échoue, plutôt que de simplement avertir, mais sur le web il existe un bref instant avant que cette barrière ne se mette en place ; et un retour en arrière du coffre-fort entier sur un appareil neuf, sans historique local, reste possible, un résidu que partagent tous les coffres-forts à connaissance nulle sans état côté client.
• L’épinglage de la récupération ne couvre pas encore la clé de signature de récupération (section 7) : un serveur qui la substituerait provoquerait un déni de service au moment de la récupération, pas une lecture de vos données.
• Aucune protection post-quantique pour l’instant (section 11) : un adversaire quantique futur pourrait déchiffrer les données scellées en X25519 d’aujourd’hui (« récolter maintenant, déchiffrer plus tard »).
• Les métadonnées du service téléphonique (qui a appelé qui, quand, combien de temps) sont inhérentes au réseau public et visibles par les opérateurs, et on ne peut pas rendre privée la copie qu’ils gardent. De notre côté, on conserve votre historique d’appels et de messages jusqu’à la fermeture de votre compte (voir la section 9 pour ce que supprimer un message fait, et ne fait pas, aujourd’hui).
• Fermer votre compte n’est ni immédiat ni total. Il y a une période de grâce de 30 jours, et vous reconnecter pendant celle-ci annule la suppression. Ensuite, les données personnelles sont supprimées définitivement, sauf les factures et relevés de facturation gardés au moins 7 ans selon la loi fiscale canadienne, qui indiquent le montant, la date, les taxes, le type de mode de paiement et le produit facturé, sans aucune donnée d’identité, aucune communication ni aucun contenu chiffré; le verdict des vérifications de contenu qui ont signalé quelque chose et la copie préservée pour chacune des deux classes de correspondance de la section 5 (seule la classe confirmée illégale est imposée par la loi); et les journaux d’audit de sécurité gardés jusqu’à 7 ans pour la sécurité du service.
• Les données opérationnelles lisibles par le serveur (numéros, facturation) ne sont pas à connaissance nulle (section 4), car elles sont requises pour fonctionner.

Ce qu’apprend une compromission totale du serveur

Prenons le pire cas au sérieux, puisque c’est notre modèle de menace (section 2) : un adversaire qui contrôle nos serveurs détient aussi les clés côté serveur. L’inventaire ci-dessous décrit ce que révèlent les données stockées et ces clés avant que l’adversaire ne modifie le code d’un client. Sur le web, un adversaire actif pourrait aussi livrer un client altéré et viser les prochaines sessions, comme l’explique la section 2.

Il lit vos numéros de téléphone et vos identifiants SIP, le lien entre votre compte, vos identités et vos numéros, vos métadonnées d’appel et de SMS aussi longtemps que vous les avez gardées, les métadonnées d’acheminement des appareils d’appel actifs, ainsi que le lien au compte, l’identifiant opaque de l’événement et l’heure de la tentative dans le registre des limites d’inscription jusqu’à son balayage à 24 heures. Il peut énumérer les index aveugles, y compris les empreintes à clé des codes de reconnaissance actifs et révoqués (le paragraphe honnête de la section 4), mais il ne peut pas retrouver un code de reconnaissance à haute entropie à partir de son empreinte. Pour tout compte de la bêta privée qui n’a pas terminé la migration d’authentification de la section 6, il obtient aussi un vérificateur de connexion statique qui pourrait lui permettre de se connecter à ce compte et d’en lire les données lisibles par nos serveurs. À partir de la copie stockée, il ne lit pas votre coffre-fort, le contenu de vos identités, vos contacts, les noms personnalisés de vos appareils d’appel ni le contenu de vos messages, sauf les communications de la bêta privée nommées à la section 5, pourvu qu’un code client légitime et non altéré ait chiffré ces données. Les clés nécessaires sont les vôtres; on ne les conserve que sous une forme qu’on ne peut pas ouvrir, et on ne peut pas être contraint de produire une clé qu’on ne détient pas. C’est la frontière de la section 4, énoncée du point de vue de l’attaquant, et c’est pour la rétrécir qu’on minimise et qu’on efface (sections 9 et 11), parce que la seule donnée qu’une compromission ne révèle jamais est celle qu’on n’a pas gardée.

11. Feuille de route

• Messagerie chiffrée de bout en bout entre utilisateurs WIGGWIGG. Sous notre méthode actuelle, on scelle vos messages au repos pour la clé de communication du compte, ce qui rend la copie scellée illisible pour nous. Le petit ensemble conservé depuis la bêta privée décrit à la section 5 reste lisible par nos serveurs tant que son rescellement n’est pas terminé. Ce n’est pas du chiffrement de bout en bout : un message qui traverse le réseau téléphonique public est visible par les opérateurs en transit, et aucun service téléphonique ne peut y changer quoi que ce soit. On compte ajouter une messagerie chiffrée de bout en bout entre comptes WIGGWIGG, où le texte en clair n’existe jamais hors des deux appareils, à la manière de Signal. Ce n’est pas encore construit, et tant que ce ne l’est pas, on ne décrira rien de ce qu’on fait comme étant de bout en bout. Pour une conversation qui exige cette propriété aujourd’hui, utilisez Signal.
• Infrastructure entièrement canadienne. Ce qu’on stocke, on le stocke au Canada. Les segments qu’on ne possède pas ne fonctionnent pas tous ainsi : le trafic téléphonique passe par l’infrastructure américaine de notre transporteur, et les paiements par notre processeur. On compte migrer vers des fournisseurs canadiens de bout en bout à mesure qu’on grandit. L’offre de transporteurs et de processeurs canadiens qui répondent à nos autres exigences est mince aujourd’hui : on n’y est donc pas, et on ne le prétendra pas tant que chaque segment n’y sera pas.
• Post-quantique : enveloppement de clé hybride X25519 + ML-KEM-768 pour le sceau des messages et l’enveloppe de récupération, pour qu’un attaquant doive briser les deux. Ça répond directement au « récolter maintenant, déchiffrer plus tard » pour les données stockées à long terme.
• Authentification : évaluer un PAKE asymétrique (OPAQUE).
• Récupération : retirer le vérificateur symétrique de récupération (section 7) pour qu’entrer en récupération, comme se connecter, ne nous envoie plus aucun secret ; épingler aussi la clé de signature de récupération, pas seulement la clé de scellement ; et amener la récupération elle-même, ainsi que l’épinglage de la clé de récupération, dans l’application téléphone.
• Intégrité du coffre-fort : les deux couches sont actives. La première, un manifeste authentifié sous votre clé de coffre-fort (la liste chiffrée de vos entrées avec un compteur anti-retour en arrière), rend détectable une suppression ou un retour à une version antérieure côté serveur. La deuxième (« zk2 »), activée elle aussi, lie cryptographiquement la version de chaque entrée à celle du manifeste, pour qu’un serveur ne puisse pas non plus revenir en douce à une ancienne version d’une seule entrée qu’on n’a pas retouchée. Deux choses restent sur la feuille de route ici : refermer le bref instant, sur le web, entre l’affichage d’une page et la mise en place de la barrière d’intégrité, et amener la migration en une passe dans l’application téléphone, qui réécrit aujourd’hui une entrée vers la nouvelle liaison au fil de vos modifications plutôt que d’un coup.
• Retirer RSA-2048 (le sceau de repli des communications décrit à la section 3, et le chiffrement des billets de soutien administrateur) au profit du coffre scellé X25519.
• Élargir la liaison au contexte (AAD) et la dérivation de clé par utilisateur à tous les champs chiffrés côté serveur.
• Audit tiers : une revue cryptographique et applicative externe, prévue.

12. Vérification et divulgation

• Vérifiez la crypto : github.com/WiggWiggDev/crypto. Les primitives de KDF, de sceau, de signature et de récupération sont exactement celles décrites ici. Le code source ouvert prouve la conception et les primitives côté client ; à lui seul, il ne prouve pas que nos serveurs les exécutent sans modification, donc des versions client reproductibles et des empreintes de paquet publiées figurent à la feuille de route.
• Signaler une vulnérabilité : voir notre politique de divulgation des vulnérabilités (ou le security.txt, lisible par machine). On s’engage à ne pas poursuivre une personne qui divulgue une faille de bonne foi, et on vise à accuser réception d’ici un jour ouvrable.

Ce document est versionné et daté. Si la réalité et ce document divergent un jour, c’est un bogue dans l’un des deux. Dites-le-nous.