Aller au contenu
Générateur

Guide n° 05 Définition technique

Qu'est-ce que le chiffrement zero-knowledge ?

Le chiffrement zero-knowledge est l’un des fondements des gestionnaires de mot de passe modernes. Il signifie, en pratique, que l’éditeur ne peut pas lire vos données, même s’il héberge votre coffre-fort ou synchronise vos identifiants sur plusieurs appareils. C’est un modèle de confiance minimal, pensé pour limiter l’exposition de vos secrets au strict nécessaire.

§ 01

Comprendre

Zero-knowledge : une architecture où l’éditeur ne voit jamais vos données en clair

Le terme est souvent employé, parfois de façon abusive. Voici ce qu’il recouvre réellement dans un gestionnaire de mots de passe.

Un gestionnaire de mots de passe zero-knowledge repose sur une idée simple : seul l’utilisateur possède la clé permettant de déchiffrer le coffre-fort. L’éditeur stocke ou synchronise des données chiffrées, mais il ne dispose ni du mot de passe maître, ni de la clé finale en clair. Sans cette clé, il ne peut pas ouvrir le coffre, ni consulter vos identifiants, ni lire vos notes sécurisées.

Ce modèle est très différent d’une base de données classique protégée par un simple mot de passe côté serveur. Dans une architecture zero-knowledge, le chiffrement se fait côté client : sur votre ordinateur ou votre téléphone, avant l’envoi vers le serveur. Le service ne reçoit donc que des données déjà chiffrées. Même une personne ayant accès à l’infrastructure serveur ne peut pas les lire sans votre secret.

Le principe repose généralement sur une dérivation de clé à partir du mot de passe maître. Ce mot de passe ne sert pas directement à chiffrer le coffre. Il passe d’abord par une fonction de dérivation comme PBKDF2 ou Argon2id, qui transforme un secret humainement mémorisable en clé cryptographique robuste. Cette clé sert ensuite à chiffrer le coffre-fort avec un algorithme symétrique comme AES-256.

En pratique, le coffre est donc illisible pour l’éditeur, pour son hébergeur et pour tout tiers qui intercepterait les sauvegardes sur le serveur. C’est l’intérêt majeur du zero-knowledge : réduire la confiance nécessaire envers le fournisseur. Vous n’avez pas seulement à croire qu’il est honnête ; vous bénéficiez d’une architecture qui l’empêche techniquement de voir vos données en clair.

§ 02

Technique

Le mécanisme : dériver une clé, chiffrer localement, synchroniser le coffre chiffré

Le zero-knowledge n’est pas un slogan. C’est une chaîne technique précise, avec plusieurs étapes.

La séquence la plus courante est la suivante : l’utilisateur saisit son mot de passe maître, le client local exécute une fonction de dérivation de clé comme PBKDF2 ou Argon2id, puis le coffre est chiffré avec AES-256. Ce n’est qu’après ce chiffrement que les données partent vers le serveur pour la sauvegarde ou la synchronisation.

PBKDF2 et Argon2id n’ont pas le même rôle exact, mais poursuivent le même objectif : ralentir massivement les attaques par force brute et par dictionnaire. L’idée est d’empêcher un attaquant de tester des millions de mots de passe en peu de temps. Argon2id est aujourd’hui souvent recommandé car il est conçu pour être coûteux en calcul et en mémoire. PBKDF2, plus ancien, reste encore largement utilisé.

Le chiffrement du coffre se fait généralement avec AES-256, une norme symétrique très répandue. Le point clé est le suivant : le serveur ne stocke pas votre coffre en clair, mais une version chiffrée de ce coffre. Sans la clé dérivée localement, les données restent inexploitables.

Il faut distinguer cela d’un simple chiffrement en transit. Le chiffrement en transit protège les données entre votre appareil et le serveur, par exemple via TLS. C’est indispensable, mais insuffisant. En effet, un service qui ne chiffre qu’en transit peut, en théorie, lire les données une fois arrivées sur ses serveurs. Le zero-knowledge va plus loin : les données restent chiffrées avant l’envoi, pendant la transmission et au repos sur le serveur.

Autre conséquence technique : si le mot de passe maître est perdu, le fournisseur ne peut pas « réinitialiser » le coffre en le déchiffrant pour vous. Il peut parfois proposer une procédure de remise à zéro du compte, mais pas une récupération du contenu. Cette contrainte est le prix de la confidentialité maximale.

§ 03

Vérification

Comment savoir si un service est vraiment zero-knowledge ?

  1. Le mot de passe maître n’est jamais connu de l’éditeur

    Le fournisseur doit préciser qu’il ne stocke pas votre mot de passe maître en clair, et qu’il ne peut pas le reconstituer. Si le service propose une « récupération complète » du coffre par le support, cela mérite d’être interrogé.

  2. Le chiffrement est effectué côté client

    Cherchez une documentation qui décrit un chiffrement local avant envoi. La présence d’un coffre chiffré côté serveur ne suffit pas ; il faut savoir où et quand la clé est créée.

  3. La fonction de dérivation de clé est documentée

    Un service sérieux indique l’usage de PBKDF2 ou Argon2id, avec des paramètres publiés ou au moins décrits. L’absence d’information technique est un mauvais signal.

  4. Les audits indépendants sont disponibles

    Un audit par un tiers ne prouve pas tout, mais il permet de vérifier l’architecture, la gestion des clés, les flux réseau et parfois la résistance du coffre. Recherchez des rapports récents, idéalement datés et publiés.

  5. Le code source ouvert aide, sans tout garantir

    Le code source ouvert permet une vérification par la communauté, des chercheurs et des clients. Ce n’est pas une preuve absolue de sécurité, mais c’est un indicateur fort de transparence, surtout lorsqu’il est accompagné d’audits.

  6. La politique de confidentialité est cohérente avec le discours

    Un service zero-knowledge ne doit pas promettre une lecture humaine des données pour l’assistance technique. Il doit aussi expliquer clairement ce qu’il voit : métadonnées, adresse e-mail, journaux techniques, ou rien de plus.

§ 04

Pièges

Les erreurs fréquentes quand on parle de zero-knowledge

  1. Confondre chiffrement en transit et zero-knowledge

    Le HTTPS protège la connexion. Il ne garantit pas que l’éditeur est incapable de lire vos données une fois reçues. Le zero-knowledge concerne l’architecture complète, pas seulement le transport.

  2. Croire qu’un mot « AES-256 » suffit

    Un gestionnaire peut annoncer AES-256 sans être zero-knowledge. Tout dépend de l’emplacement des clés, de la dérivation locale et du moment où le chiffrement est appliqué.

  3. Accepter une récupération « magique » du coffre

    Si le support peut vous redonner l’accès à vos données chiffrées sans votre mot de passe maître, il faut comprendre par quel mécanisme. Dans une architecture strictement zero-knowledge, le contenu du coffre n’est pas restaurable en clair par l’éditeur.

  4. Penser qu’un audit ancien suffit pour toujours

    Un audit de sécurité vieillit vite. Les applications évoluent, les bibliothèques changent, les paramètres aussi. Un service crédible publie des audits réguliers et, si possible, des correctifs suivis.

  5. Oublier la menace du mot de passe maître faible

    Le zero-knowledge protège contre l’éditeur, mais pas contre un mot de passe maître trop court. Sans secret robuste, la dérivation de clé ne compense pas tout. La qualité du mot de passe maître reste décisive.

  6. Supposer que tout est invisible

    Même en zero-knowledge, le fournisseur peut parfois voir certaines métadonnées : adresse e-mail, date de connexion, appareil utilisé, volume de stockage. Il faut distinguer les secrets du coffre et les données de fonctionnement.

§ 05

Conséquences

Ce que change le zero-knowledge dans la vie réelle

  • Perte du mot de passe maître

    L’utilisateur oublie son mot de passe maître et n’a pas configuré de mécanisme de secours.

    Dans un modèle zero-knowledge, la récupération du coffre est impossible sans le secret. Il faut prévoir des procédures de secours dès l’inscription : clés de récupération, codes de secours, ou double authentification bien conservée.

  • Réquisition judiciaire ou demande administrative

    Un tiers demande au fournisseur de remettre les données en clair d’un utilisateur.

    Si le service est réellement zero-knowledge, l’éditeur ne peut pas produire le contenu lisible du coffre. Il peut seulement remettre des données chiffrées, sauf si l’utilisateur a exposé des informations en dehors du coffre.

  • Compte compromis côté serveur

    Un attaquant obtient un accès aux serveurs de synchronisation.

    Le risque reste fort, mais l’impact est réduit : l’attaquant récupère surtout des coffres chiffrés. Sans la clé dérivée du mot de passe maître, le contenu demeure protégé.

  • Utilisation sur plusieurs appareils

    L’utilisateur synchronise son coffre sur ordinateur, mobile et tablette.

    Le zero-knowledge est particulièrement adapté. Chaque appareil déchiffre localement le coffre après authentification, puis resynchronise des données toujours chiffrées.

  • Partage de secrets avec des proches ou des collègues

    Des mots de passe doivent être partagés de façon ponctuelle ou en équipe.

    Privilégiez des fonctions de partage chiffré de bout en bout, avec droits limités et révocation possible. Le zero-knowledge doit s’appliquer aussi aux objets partagés.

§ 06

Annexes

Questions fréquentes

Qu’est-ce qu’un chiffrement zero-knowledge, en une phrase ?
C’est un modèle dans lequel l’éditeur ne possède pas la clé permettant de lire vos données : votre coffre-fort est chiffré avant envoi et seul votre mot de passe maître permet de le déchiffrer localement.
Quelle différence entre zero-knowledge et chiffrement de bout en bout ?
Les deux notions sont proches. Le chiffrement de bout en bout décrit le trajet des données chiffrées entre vos appareils et le serveur. Zero-knowledge insiste sur le fait que le fournisseur ne peut pas accéder à la clé ni aux données en clair.
Pourquoi le mot de passe maître est-il si important ?
Parce qu’il sert à dériver la clé de chiffrement de votre coffre. S’il est faible, tout le modèle est fragilisé. S’il est perdu, le coffre est généralement irrécupérable en clair.
Un gestionnaire zero-knowledge peut-il récupérer mon coffre si j’ai oublié mon mot de passe ?
En principe non. C’est justement la contrepartie du modèle : l’éditeur ne pouvant pas lire vos données, il ne peut pas non plus les déchiffrer à votre place.
Le chiffrement zero-knowledge protège-t-il contre le piratage ?
Il réduit fortement l’impact d’une fuite serveur, car les données récupérées sont chiffrées. En revanche, il ne protège pas contre un appareil compromis, un hameçonnage ou un mot de passe maître trop faible.
Comment vérifier qu’un service est vraiment zero-knowledge ?
Lisez la documentation technique, cherchez des audits indépendants, vérifiez l’usage de PBKDF2 ou Argon2id, et contrôlez si le code source est ouvert ou auditable.
Les gestionnaires zero-knowledge sont-ils légaux en France ?
Oui. Ils sont compatibles avec le cadre du RGPD et avec les recommandations de protection des données, à condition que l’éditeur respecte aussi ses obligations de sécurité, de transparence et de gestion des incidents.
Bitwarden, 1Password ou Proton Pass sont-ils zero-knowledge ?
Ces services sont souvent cités pour leur approche zero-knowledge ou leur architecture proche. Il faut toutefois vérifier leur documentation à jour, leurs audits et les détails de leur modèle de chiffrement avant de conclure.

Choisissez un gestionnaire zero-knowledge

Tous les outils de notre comparatif sont conformes à cette architecture.

Voir le comparatif