Chiffrement zero-knowledge : ce que ça signifie pour vos mots de passe

Zero-knowledge : le terme le plus utilisé et le moins compris de la cybersécurité

Le zero knowledge chiffrement gestionnaire mots de passe est l’argument phare de tous les acteurs du secteur. Mais que signifie vraiment « zero-knowledge » ? C’est devenu un argument marketing standard, au point que le terme a perdu une partie de son sens. En tant que développeur freelance qui audite régulièrement des architectures de sécurité, je vais vous expliquer ce que zero-knowledge signifie vraiment, comment le vérifier concrètement, et lesquels des gestionnaires populaires sont réellement conformes à ce principe.

Commençons par le commencement : le terme « zero-knowledge » dans le contexte des gestionnaires de mots de passe ne désigne pas les zero-knowledge proofs (ZKP) au sens mathématique du terme (protocoles cryptographiques permettant de prouver une connaissance sans la révéler). Il désigne une architecture dans laquelle le fournisseur de service ne peut pas accéder à vos données en clair — même s’il le voulait.

Le problème avec le chiffrement « standard »

Pour comprendre le zero-knowledge, il faut d’abord comprendre son opposé : le modèle où le serveur peut (en théorie) accéder à vos données.

Prenez l’exemple d’un service email classique comme Gmail. Google chiffre vos emails « en transit » (HTTPS) et « au repos » sur ses serveurs. Mais Google détient les clés de chiffrement. Si Google reçoit une ordonnance judiciaire, si un employé malveillant accède aux systèmes, ou si Google est compromis par un attaquant sophistiqué — vos données peuvent être lues.

C’est ce qu’on appelle le chiffrement côté serveur : le serveur gère les clés, le serveur peut déchiffrer.

L’architecture zero-knowledge expliquée

Dans un système zero-knowledge authentique, la hiérarchie des clés est la suivante :

1. Le mot de passe maître comme générateur de clés

Votre mot de passe maître ne quitte jamais votre appareil. Il n’est jamais envoyé au serveur, ni même son hash direct. À la place, il sert à dériver une clé cryptographique via une fonction de dérivation de clé (KDF).

2. La dérivation de clé (KDF)

Les gestionnaires modernes utilisent des KDF robustes :

• PBKDF2 (Password-Based Key Derivation Function 2) : utilisé par Bitwarden (100 000 itérations minimum recommandées, configurable jusqu’à 600 000+)
• Argon2id : plus récent, plus résistant aux attaques GPU/ASIC — utilisé par Bitwarden (option), ProtonPass, 1Password partiellement
• bcrypt / scrypt : moins courants dans ce contexte

La KDF transforme votre mot de passe maître + un sel unique en une clé de chiffrement symétrique (généralement AES-256). Ce calcul est fait localement, sur votre appareil.

3. Le chiffrement local avant envoi

Vos mots de passe, notes, URL et métadonnées sont chiffrés avant d’être envoyés au serveur. Le serveur ne reçoit que des données chiffrées, opaques, sans signification sans la clé — qu’il ne possède pas.

4. La vérification d’authentification sans transmission du secret

Comment le serveur vérifie-t-il que vous êtes bien vous, sans connaître votre mot de passe maître ? Via un hash secondaire. Bitwarden, par exemple, dérive deux valeurs de votre mot de passe maître :

• La clé de chiffrement (dérivée avec sel local)
• Un hash d’authentification (un second passage de PBKDF2, avec le sel email) — c’est ce hash qui est envoyé au serveur pour vérifier l’identité

Même si un attaquant intercepte ce hash d’authentification, il ne peut pas l’utiliser pour déchiffrer le coffre — c’est une valeur différente de la clé de chiffrement.

Schéma simplifié de l’architecture zero-knowledge

Pour visualiser concrètement :

• Appareil utilisateur → [Mot de passe maître + Sel] → KDF (Argon2/PBKDF2) → Clé symétrique AES-256
• Clé AES-256 → Chiffrement des données → Blob chiffré → Serveur (stockage uniquement)
• Appareil utilisateur → [Mot de passe maître + Email] → PBKDF2 → Hash auth → Serveur (vérification identité)

Le serveur stocke : le blob chiffré + le hash auth. Il ne stocke ni mot de passe maître ni clé de chiffrement. C’est ça, le zero-knowledge.

Différences avec un chiffrement non zero-knowledge

Pour être précis, voici les signes qu’un service n’est pas vraiment zero-knowledge :

• Il peut vous montrer vos données après réinitialisation de mot de passe sans vérification d’identité forte
• Il propose une récupération de compte côté serveur sans clé de secours locale
• Son équipe support peut accéder à vos mots de passe pour résoudre un problème
• Ses serveurs ont déjà été compromis et les mots de passe des utilisateurs ont été exposés en clair ou déchiffrables

L’exemple tristement célèbre : LastPass. Lors des fuites de 2022, les coffres volés étaient certes chiffrés, mais les métadonnées (URL des sites, noms des entrées) n’étaient pas chiffrées. Une architecture véritablement zero-knowledge protège aussi les métadonnées. Notre analyse de la faille LastPass 2022 détaille ce point important.

Lesquels des gestionnaires sont vraiment zero-knowledge ?

Bitwarden — ZK authentique et vérifiable

Bitwarden est probablement le gestionnaire le plus transparent sur son architecture ZK. Le code source est entièrement open source (client ET serveur), audité régulièrement par des firmes indépendantes (Cure53, etc.). Vous pouvez littéralement lire le code de chiffrement sur GitHub. La documentation technique de Bitwarden détaille chaque étape de la dérivation de clés. Pour les paranoïaques de la sécurité, c’est la référence.

1Password — ZK avec un twist : la Secret Key

1Password implémente une architecture ZK solide, avec une particularité unique : la Secret Key (une clé de 34 caractères générée lors de la création du compte). Cette clé entre dans la dérivation en plus du mot de passe maître, ce qui signifie que même si un attaquant obtient votre mot de passe maître, il ne peut pas déchiffrer votre coffre sans cette Secret Key. C’est une couche de protection supplémentaire par rapport à une architecture ZK standard. L’architecture est documentée dans le white paper public de 1Password.

ProtonPass — ZK par design, héritage Proton

ProtonPass s’appuie sur l’expertise cryptographique de l’équipe Proton (ProtonMail). L’architecture ZK est documentée et cohérente avec les autres produits Proton. Le code client est open source. Particularité : les alias email Hide My Email sont directement intégrés, eux aussi protégés par l’architecture ZK.

NordPass — ZK avec XChaCha20

NordPass utilise l’algorithme XChaCha20-Poly1305 plutôt que l’AES-256 classique. Les deux sont considérés comme robustes, mais XChaCha20 est plus adapté aux environnements sans accélération hardware AES. L’architecture est ZK, auditée par Cure53. Le code client n’est pas open source, ce qui limite la vérification indépendante.

Dashlane — ZK, mais architecture partiellement propriétaire

Dashlane implémente le zero-knowledge et l’a documenté publiquement. La migration vers une architecture basée sur Argon2 a été réalisée ces dernières années. Le code client n’est pas entièrement open source, mais Dashlane publie ses white papers de sécurité.

Keeper — ZK avec certifications entreprise

Keeper est ZK et le fait certifier dans le cadre de ses certifications SOC 2 Type II, ISO 27001, et FedRAMP. Pour les entreprises, ces certifications offrent une garantie supplémentaire au-delà des affirmations marketing.

Comment vérifier qu’un gestionnaire est vraiment zero-knowledge ?

Voici ma checklist de développeur :

1. Le code est-il open source ? (client au minimum) → Bitwarden, ProtonPass, KeePass : oui
2. Y a-t-il un audit de sécurité public récent ? → Cherchez le rapport sur le site officiel
3. La documentation technique détaille-t-elle la dérivation de clés ? → White papers, documentation développeur
4. Que se passe-t-il en cas de fuite serveur ? → Si les coffres volés sont déchiffrables par les attaquants avec des ressources raisonnables, l’implémentation ZK est défaillante
5. Les métadonnées sont-elles chiffrées ? → URLs, noms des entrées, notes → Point faible historique de plusieurs gestionnaires

Pour aller plus loin sur la compréhension du chiffrement, notre article sur le chiffrement AES-256 complète parfaitement cette lecture.

Les limites du zero-knowledge

Soyons honnêtes : le zero-knowledge ne protège pas contre tout :

• Compromission de l’appareil : si votre machine est infectée par un keylogger ou un malware qui capture les données après déchiffrement, le ZK ne sert à rien
• Mot de passe maître faible : un attaquant avec le coffre chiffré peut tenter une attaque par dictionnaire si votre mot de passe maître est faible
• Implémentation défaillante côté client : si l’application chiffre mal (mauvaise génération de sel, faible nombre d’itérations PBKDF2…), le ZK théorique ne compense pas l’implémentation boiteuse
• Métadonnées non chiffrées : même sans les mots de passe, savoir que vous avez un compte sur tel site bancaire ou tel service sensible peut être exploité

Consultez notre guide sur la sécurité réelle des gestionnaires de mots de passe pour une analyse complète des vecteurs d’attaque restants même avec du zero-knowledge.

Conclusion : le zero-knowledge, condition nécessaire mais pas suffisante

Le zero-knowledge est la condition minimale pour faire confiance à un gestionnaire de mots de passe cloud. Sans lui, vous donnez littéralement les clés de votre vie numérique à une entreprise tierce. Avec lui, vous avez une garantie mathématique que même une compromission des serveurs n’expose pas vos données.

Mais le ZK n’est pas une baguette magique. La qualité de l’implémentation, la robustesse des algorithmes choisis, la fréquence des audits indépendants, et la sécurité de votre propre appareil restent des facteurs déterminants. Mon conseil : privilégiez les gestionnaires open source avec audits publics — Bitwarden en tête — et vérifiez vous-même si vous en avez la compétence technique.