Glossaire

Confidentialité et chiffrement

Ces mots sont employés à la légère dans les descriptions d’apps, et c’est exactement dans les différences entre eux que se trouve la valeur. Caché n’est pas verrouillé. Verrouillé n’est pas chiffré. Et une clé que quelqu’un d’autre détient n’est pas vraiment la tienne.

Caché ou chiffré

Caché veut dire qu’une app accepte de ne pas montrer quelque chose. Chiffré veut dire que les octets sur le disque sont illisibles sans clé. Le premier est une promesse ; le second, de l’arithmétique.

Un dossier caché reste un dossier ordinaire. Tout ce qui lit le disque directement — une sauvegarde, un gestionnaire de fichiers, un outil d’analyse forensique, une autre app avec la bonne autorisation — voit exactement ce qu’il contient, parce que rien n’a changé dans le fichier.

Le chiffrement, lui, change le fichier. Ce qui se trouve sur le disque est du bruit, et ça reste du bruit pour quiconque n’a pas la clé, y compris pour qui a écrit l’app. La distinction n’apparaît que le jour où elle compte, et c’est pour ça qu’il vaut mieux la connaître avant.

Voir aussi : Au repos ou en transitChaCha20-Poly1305

ChaCha20-Poly1305

Un algorithme de chiffrement moderne qui à la fois masque les données et détecte toute altération. Rapide sur les téléphones, qui n’ont pas toujours d’accélération matérielle pour l’alternative plus ancienne.

ChaCha20 fait le chiffrement ; Poly1305 produit une étiquette qui vérifie que les données n’ont pas été modifiées. Ensemble, c’est ce qu’on appelle du chiffrement authentifié — le déchiffrement échoue bruyamment sur un fichier modifié au lieu de produire un charabia plausible.

C’est la même construction que celle utilisée dans TLS et dans la messagerie sécurisée moderne. Sur du matériel sans accélération AES, il est sensiblement plus rapide qu’AES, et c’est pour ça que les téléphones ont tendance à le préférer.

Voir aussi : Au repos ou en transitEnveloppement de clé

Enveloppement de clé

chiffrement par enveloppe

Chiffrer les fichiers avec une clé, puis chiffrer cette clé séparément avec chaque moyen d’entrer. Changer de code réenveloppe une petite clé au lieu de tout rechiffrer.

Les fichiers sont chiffrés une seule fois, avec une clé générée sur l’appareil. Cette clé est ensuite enveloppée — chiffrée — par le code, puis enveloppée à nouveau par le code de récupération. Deux enveloppes, une même clé dans chacune.

Les conséquences sont toutes pratiques. Un changement de code réécrit quelques centaines d’octets au lieu de cent gigaoctets. Le déverrouillage biométrique est une enveloppe de plus, pas un second modèle de sécurité. Et perdre toutes les enveloppes, c’est perdre la clé, parce que la clé n’existe nulle part ailleurs.

Voir aussi : Code de récupérationChaCha20-Poly1305

Code de récupération

Une chaîne à usage unique capable de désenvelopper la clé maîtresse quand le code est oublié. Personne ne peut la réémettre, parce que personne d’autre ne l’a jamais eue — y compris ceux qui ont écrit l’app.

Il est affiché une seule fois, à la configuration, et c’est la seconde des deux portes. Noté et gardé ailleurs que sur l’appareil, il transforme un code oublié en simple contrariété.

Si le code est oublié et le code de récupération perdu, les fichiers ne peuvent être déchiffrés par personne. Ce n’est pas une politique de support qu’on pourrait discuter ; c’est ce que signifie n’avoir aucune copie de la clé. Range-le avec autant de soin que les fichiers le méritent.

Voir aussi : Enveloppement de cléZero-knowledge

Coffre leurre

déni plausible

Un second code qui ouvre un autre coffre, anodin. Quelqu’un que l’on force à déverrouiller l’app peut le faire, et ce qui s’ouvre n’est pas ce que l’on cherchait.

Les deux codes sont réels et les deux ouvrent un vrai coffre. Rien à l’écran n’indique qu’un autre existe, et on ne peut pas demander à l’app lequel elle affiche.

Ça existe pour la situation où refuser de déverrouiller n’est pas une option — une frontière, une exigence, quelqu’un debout derrière toi. Le chiffrement seul n’aide pas là : le problème n’est pas la clé, c’est d’être contraint de s’en servir.

Voir aussi : Code de récupérationCaché ou chiffré

Trousseau

Le magasin protégé du système pour les petits secrets, adossé au matériel de sécurité de l’appareil. C’est là que doivent vivre les clés et les jetons, et c’est là que rien de volumineux n’a sa place.

Les éléments qu’il contient peuvent porter des conditions : lisibles seulement quand l’appareil est déverrouillé, seulement sur cet appareil, seulement après une confirmation biométrique ou par code. Ces conditions sont appliquées par le matériel, pas par une app qui demande poliment.

Il stocke des secrets, pas des données. Les clés, les jetons et le matériel enveloppé vont là ; les fichiers chiffrés eux-mêmes vivent sur le disque, où la taille n’est pas un problème.

Voir aussi : Enveloppement de cléAu repos ou en transit

Au repos ou en transit

Chiffré au repos veut dire illisible sur le disque. Chiffré en transit veut dire illisible sur le réseau. Ce sont deux protections distinctes, et un produit peut honnêtement revendiquer l’une sans faire l’autre.

HTTPS, c’est du chiffrement en transit : à l’abri de qui observe le réseau, et parfaitement lisible par le serveur à l’autre bout une fois arrivé. Le chiffrement au repos concerne la copie stockée, ce qui compte le jour où un appareil est perdu ou un disque copié.

Lire attentivement une promesse de confidentialité revient le plus souvent à déterminer duquel des deux elle parle. « Tes données sont chiffrées », sans l’un ni l’autre mot, est une phrase choisie pour ne rien dire.

Voir aussi : ChaCha20-Poly1305Zero-knowledge

Zero-knowledge

Une conception dans laquelle l’opérateur ne peut pas lire ce qu’il stocke, parce que les clés ne quittent jamais les appareils de l’utilisateur — le « à connaissance nulle ». Le test est simple : peut-il réinitialiser ton mot de passe et te rendre quand même tes données ?

Si un service peut restaurer l’accès après que tu as tout oublié, c’est qu’il détient quelque chose capable de déverrouiller tes données — ce qui veut dire qu’on peut le contraindre à s’en servir, et que quiconque le pirate hérite de la même capacité.

Le compromis est réel et devrait être énoncé clairement plutôt que vendu comme un pur avantage : du vrai zero-knowledge, c’est vraiment perdre l’accès quand la dernière clé est perdue. Il n’y a pas de troisième option où l’opérateur peut te sauver sans que personne d’autre ne le puisse.

Voir aussi : Code de récupérationAu repos ou en transit

Biométrie

Face ID, Touch ID

C’est l’appareil, pas l’app, qui confirme que c’est bien toi ; l’app reçoit un oui ou un non. Aucune donnée d’empreinte ou de visage n’atteint jamais une app, et rien de tout ça n’est un mot de passe.

Le déverrouillage biométrique est une commodité posée autour d’un secret, pas un remplacement. Ce qu’il protège, c’est une clé stockée, et c’est pour ça qu’un code existe toujours derrière — la biométrie peut échouer, et le repli doit être quelque chose que tu sais.

La comparaison se fait dans du matériel dédié et les gabarits n’en sortent jamais. Une app qui propose Face ID pose une question au système, elle ne collecte rien.

Voir aussi : TrousseauEnveloppement de clé

Analytique anonyme

Compter des événements sans enregistrer qui les a faits. La valeur de la promesse dépend entièrement de ce qui est attaché à chaque événement — et les noms de fichiers, les chemins et les URL sont là où ce genre de promesse casse en général.

Savoir qu’un écran a été ouvert, c’est un compteur. Savoir quel fichier a été lu, c’est la description d’une personne. La frontière entre les deux n’est pas le mot « anonyme » ; ce sont les champs que l’événement transporte.

Une promesse digne de confiance dit ce qui n’est *pas* envoyé aussi précisément que ce qui l’est : pas de noms de fichiers, pas de chemins, pas d’URL, aucun identifiant de connexion, aucun identifiant qui survit d’une session à l’autre — et elle offre un moyen de tout couper.

Voir aussi : Au repos ou en transit

Les autres sujets