Zero-knowledge : ce que les recherches révèlent vraiment

Ces dernières semaines, plusieurs travaux de recherche académique ont suscité de nombreuses réactions autour des promesses de zero-knowledge formulées par certains gestionnaires de mots de passe cloud. Pour beaucoup, ces publications ont pu donner l’impression qu’un modèle présenté comme très protecteur révélait soudain des failles structurelles majeures.

Chez Mailinblack, et plus particulièrement autour de notre gestionnaire de mots de passe Sikker, nous avons souhaité prendre un moment pour revenir sur le sujet avec clarté. L’objectif n’est pas de minimiser ces recherches, ni de les dramatiser, mais d’expliquer simplement ce qu’elles montrent réellement, ce qu’elles ne disent pas, et ce qu’il faut comprendre derrière le terme souvent mis en avant de zero-knowledge.

Ce que montrent réellement ces travaux

Première précision essentielle : ces recherches ne remettent pas en cause les algorithmes de chiffrement eux-mêmes. Les chercheurs n’ont ni “cassé” AES, ni deviné des mots de passe maîtres, ni accédé directement à des coffres-forts chiffrés en contournant la cryptographie.

Leur démarche repose en réalité sur une hypothèse volontairement extrême : que se passerait-il si le serveur du fournisseur était entièrement compromis ?

Autrement dit, le scénario étudié n’est pas celui d’un service qui lirait discrètement les données de ses utilisateurs alors même que son architecture fonctionnerait normalement. Il s’agit d’un cas de compromission forte, dans lequel un acteur malveillant aurait pris le contrôle de l’infrastructure du fournisseur et disposerait d’un accès administrateur complet à des composants critiques du service.

Dans cette situation, l’attaque ne vise pas directement le chiffrement en lui-même. Elle cherche plutôt à exploiter certains mécanismes périphériques indispensables au fonctionnement d’un gestionnaire de mots de passe moderne, notamment lorsqu’il propose des fonctions de partage, de synchronisation ou de gestion collaborative.

Le point le plus sensible évoqué par la recherche concerne précisément le partage d’un coffre-fort. Pour permettre à un utilisateur de partager l’accès à des données chiffrées avec un autre, il faut transmettre de manière sécurisée la clé qui protège ces données. Ce type de partage repose généralement sur un mécanisme de cryptographie asymétrique : une clé publique permet de chiffrer l’information destinée à un utilisateur, et seule la clé privée correspondante permet ensuite de la déchiffrer.

Dans l’hypothèse où un attaquant, via un serveur compromis, parviendrait à substituer la clé publique d’un utilisateur par sa propre clé publique, alors les éléments chiffrés à destination de cet utilisateur pourraient, dans certains cas, devenir lisibles par l’attaquant grâce à sa propre clé privée.

Le point important ici est le suivant : la cryptographie n’est pas “brisée”. Ce qui est interrogé, c’est la solidité de la chaîne de confiance autour de cette cryptographie, en particulier lorsque le serveur joue un rôle dans la distribution, la synchronisation ou la mise à disposition de certains éléments nécessaires au partage.

Le zero-knowledge : un principe puissant, mais souvent mal compris

Le terme zero-knowledge est fréquemment perçu comme une promesse absolue. Dans l’imaginaire collectif, il suggère qu’un fournisseur ne peut, en aucune circonstance, accéder aux données de ses utilisateurs. Cette lecture est compréhensible, mais elle simplifie une réalité plus nuancée.

Dans le contexte des gestionnaires de mots de passe, le zero-knowledge désigne un principe d’architecture précis : les données sont chiffrées côté utilisateur, avant leur envoi vers le serveur, et le fournisseur ne dispose pas des secrets nécessaires pour les déchiffrer. Concrètement, cela signifie que le serveur stocke des données chiffrées, mais qu’il n’est pas censé posséder la clé permettant de les lire en clair.

C’est un modèle de sécurité très fort, car il réduit considérablement la confiance à accorder à l’opérateur du service. Même en cas d’accès aux bases de données, un tiers ne devrait pas pouvoir lire directement les contenus protégés sans disposer des secrets détenus par l’utilisateur.

Mais il est important de rappeler que le zero-knowledge n’est pas une formule magique. Ce n’est pas une propriété qui résume, à elle seule, toute la sécurité d’un produit. C’est un principe de confidentialité des données stockées, pas une garantie universelle couvrant tous les aspects du système.

En pratique, un service ne se limite jamais à stocker passivement des données chiffrées. Il doit aussi gérer :

• l’authentification des utilisateurs,
• la synchronisation entre appareils,
• les fonctions de partage,
• parfois la récupération d’accès,
• les métadonnées nécessaires au fonctionnement du service,
• et l’intégrité des échanges entre les composants.

C’est à ce niveau qu’il faut bien comprendre les limites du modèle. Le zero-knowledge protège le contenu chiffré contre une lecture triviale par le serveur, mais il ne dispense pas de sécuriser tout le reste : infrastructure, distribution des clés publiques, contrôle des accès, intégrité des clients, protection contre la compromission de l’environnement serveur, audit des mécanismes de partage, etc.

Autrement dit, les recherches récentes ne disent pas que le zero-knowledge serait faux ou inutile. Elles rappellent plutôt qu’un bon modèle cryptographique doit toujours être accompagné d’un bon modèle de confiance.

Ce que ces travaux ne disent pas

Il est tout aussi important de préciser ce que ces travaux n’affirment pas.

Ils ne disent pas que tous les gestionnaires de mots de passe seraient “ouverts” ou “lisibles” par défaut. Ils ne disent pas non plus que les fournisseurs mentent systématiquement lorsqu’ils mettent en avant une architecture zero-knowledge. Enfin, ils ne démontrent pas qu’un utilisateur verrait automatiquement son coffre compromis en conditions normales d’utilisation.

Ce qu’ils montrent, c’est qu’il existe des scénarios extrêmes dans lesquels la sécurité d’un système dépend non seulement du chiffrement, mais aussi de la capacité du fournisseur à préserver l’intégrité de son environnement et de certains mécanismes de confiance. C’est une distinction importante, car elle replace le débat au bon niveau : non pas celui d’un échec de la cryptographie, mais celui de la sécurité globale d’une plateforme.

Le zero-knowledge reste pertinent à condition de bien en comprendre le périmètre

Il serait erroné de conclure de ces publications que le modèle zero-knowledge perd son intérêt. Au contraire, il demeure aujourd’hui l’un des fondements les plus solides pour protéger des secrets sensibles dans un service cloud.

Sans ce modèle, le fournisseur disposerait potentiellement des moyens techniques d’accéder directement aux données. Avec lui, cette lecture directe devient impossible sans compromettre d’autres éléments de la chaîne. Cela change profondément le niveau de protection offert aux utilisateurs.

En revanche, ces travaux rappellent une réalité essentielle : la sécurité n’est jamais réductible à un slogan marketing. Une architecture zero-knowledge est un atout majeur, mais elle doit s’inscrire dans une approche plus large, combinant robustesse cryptographique, sécurité de l’infrastructure, contrôle des accès, supervision, durcissement des environnements et revue régulière des modèles de menace.

Et concernant Sikker ?

Sikker n’est pas cité dans ces recherches. Pour autant, les questions soulevées sont légitimes pour tout gestionnaire de mots de passe reposant sur un modèle zero-knowledge avec un serveur intermédiaire.

C’est précisément pour cette raison que notre approche ne se limite pas à l’affichage d’un principe cryptographique. Elle repose sur deux piliers complémentaires : une architecture conçue pour empêcher l’accès du fournisseur aux données en clair, et un ensemble de mesures d’infrastructure destinées à réduire drastiquement la probabilité d’un scénario de compromission avancée.

1. Une architecture zero-knowledge par conception

Le premier pilier est celui du modèle cryptographique lui-même. Les données sont chiffrées localement, côté utilisateur. Les clés utilisées pour leur protection sont dérivées de secrets qui ne sont pas détenus par le serveur. En conséquence, le fournisseur n’a pas vocation à accéder au contenu en clair des informations stockées sur son infrastructure.

Ce principe reste au cœur de notre conception : faire en sorte que l’hébergement de données chiffrées ne se transforme pas en capacité de lecture.

2. Une sécurité d’infrastructure renforcée

Le second pilier répond directement au type de scénario étudié dans les travaux académiques. Puisque ceux-ci reposent sur l’hypothèse d’une compromission profonde du serveur, il est essentiel de mettre en œuvre des mesures fortes pour empêcher qu’un tel niveau de compromission ne se produise.

Dans cette logique, nous avons renforcé plusieurs couches de sécurité, notamment :

• le contrôle d’accès et d’identité, avec authentification multifacteur et gestion stricte des privilèges ;
• la segmentation réseau ;
• la séparation des environnements ;
• l’usage de registres privés ;
• le suivi et les mises à jour régulières des composants ;
• le durcissement des bases de données, avec comptes séparés, TLS 1.3 et chiffrement ;
• la journalisation des accès et la supervision continue de la disponibilité, des vulnérabilités et des chemins d’exploitabilité.

À cela s’ajoutent les pratiques de security by design appliquées par nos équipes de développement et de sécurité. Chaque évolution significative est analysée sous l’angle du risque, et les modifications apportées aux applications font l’objet d’une attention particulière afin d’éviter d’introduire des faiblesses dans la chaîne de confiance.

L’objectif est clair : réduire autant que possible la probabilité qu’un scénario de compromission serveur tel que celui décrit dans les recherches académiques puisse se produire, et limiter au maximum ses effets potentiels.

Transparence avant tout

Ces travaux académiques sont utiles. Ils rappellent que la sécurité ne se résume ni à une étiquette, ni à une promesse simplifiée. Elle repose sur un ensemble cohérent de choix d’architecture, de modèles de menace, de contrôles techniques et de pratiques opérationnelles.

Ils rappellent aussi qu’un gestionnaire de mots de passe reste aujourd’hui l’un des moyens les plus efficaces de se protéger contre les attaques les plus courantes, comme la réutilisation de mots de passe, le phishing ou la compromission de comptes liée à de mauvais usages.

L’essentiel est donc moins de rechercher une promesse absolue que de comprendre précisément ce que recouvrent les garanties avancées. Il faut choisir des solutions transparentes sur leur fonctionnement, lucides sur leur périmètre de sécurité et exigeantes dans leur mise en œuvre opérationnelle.

Le zero-knowledge n’est pas un mythe à déconstruire, ni une garantie magique à surinterpréter. C’est un cadre de sécurité pertinent, robuste et utile à condition de l’inscrire dans une approche globale, cohérente et rigoureuse de la protection des données.