Le test : qui détient les clés ?
« Chiffré » seul dit peu de chose. Presque tous les services chiffrent les données en transit et sur leurs disques, mais ils détiennent aussi les clés : ils peuvent donc lire vos données, tout comme quiconque s'introduit chez eux ou les y contraint. Avec le chiffrement de bout en bout, les clés n'existent que sur vos appareils et le serveur ne reçoit que du texte chiffré.
Un contrôle rapide : l'entreprise peut-elle réinitialiser votre mot de passe et vous rendre vos données ? Si oui, elle peut lire vos données, ou en a le moyen. Avec une vraie conception de bout en bout, perdre à la fois votre mot de passe et votre clé de récupération fait perdre les données.
Le même test vaut pour l'outil qui garde vos accès aux serveurs : un gestionnaire de clés SSH avec coffre chiffré doit le passer.
Ce que le serveur peut encore voir
Le chiffrement cache le contenu. Il ne peut pas tout cacher, car le serveur doit quand même gérer un compte et livrer des données :
- Votre e-mail et votre formule, et souvent les noms de vos appareils.
- Les dates d'activité, et votre adresse IP quand vous vous connectez.
- Le nombre d'éléments chiffrés que vous avez et leur taille approximative. Le remplissage (padding) peut brouiller la taille mais pas la supprimer.
Le serveur peut aussi supprimer ou bloquer vos données. Le chiffrement de bout en bout protège le secret, il ne garantit pas la disponibilité : gardez votre propre copie de ce que vous ne pouvez pas perdre.
Ce contre quoi il ne protège pas
- Un mot de passe faible. Si vos clés viennent de votre mot de passe, celui qui vole la base peut deviner hors ligne, sans limite de débit. Voir Argon2id expliqué.
- Une mise à jour malveillante. L'application détient vos clés : celui qui contrôle ce que fait l'application peut les lire. La signature limite qui peut publier une mise à jour, mais vous faites toujours confiance à l'éditeur et à sa clé de signature.
- Un appareil compromis. Un logiciel malveillant sur un appareil déverrouillé peut lire ce que vous lisez.
- Un appareil déverrouillé entre de mauvaises mains, si l'application n'a pas de verrouillage propre.
- Du code livré par le serveur. Une application web chargée depuis le serveur à chaque visite peut être remplacée par celui qui contrôle ce serveur, et elle pourrait voler votre mot de passe pendant que vous le saisissez.
Questions à poser à n'importe quel éditeur
- Où le chiffrement est-il fait, et des clés vous sont-elles jamais envoyées, même enveloppées ?
- Comment le mot de passe devient-il une clé, et faut-il aussi un second secret, comme une clé créée sur mon appareil ?
- Quelles métadonnées stockez-vous exactement ? Les noms et types d'éléments sont-ils chiffrés ?
- Que se passe-t-il si j'oublie mon mot de passe ? Toute réponse autre qu'une clé de récupération que je détiens demande une explication.
- Un site web ou une application web voit-il jamais mon mot de passe ?
Questions
Le chiffrement de bout en bout, est-ce la même chose que le zero knowledge ?
En pratique, oui. Zero knowledge est un nom commercial pour la même idée : le fournisseur stocke vos données sans les clés pour les lire.
Un service chiffré de bout en bout peut-il récupérer mes données si j'oublie mon mot de passe ?
Seulement avec une clé ou un kit de récupération que vous détenez. Si l'entreprise peut vous rendre vos données après une simple réinitialisation par e-mail, elle possède une clé, et les données ne sont pas chiffrées de bout en bout.
Le chiffrement de bout en bout cache-t-il mes métadonnées ?
Non. Le serveur voit toujours votre e-mail, vos dates d'activité et le nombre et la taille approximative de vos éléments. Seul le contenu est caché.