Zero-knowledge cloud : quand votre fournisseur ne sait rien de vous
Zero-knowledge, c’est le terme que les fournisseurs cloud utilisent quand ils veulent dire « même nous, on ne peut pas lire vos fichiers ». C’est séduisant. C’est aussi, dans 80% des cas, une exagération marketing qui couvre une réalité technique plus nuancée. Le concept vient de la cryptographie (les preuves à divulgation nulle de connaissance, un truc élégant inventé dans les années 80) mais dans le contexte du cloud, il a été recyclé pour signifier quelque chose de plus simple : le fournisseur ne détient pas votre clé de déchiffrement. Point. Si vous venez de la page sécurité et chiffrement du cloud, vous savez que la question centrale est « qui détient la clé ». Le zero-knowledge est la réponse la plus radicale : personne d’autre que vous.
En pratique, voici ce que ça implique : quand vous créez un compte sur un service zero-knowledge comme Tresorit ou Sync.com, votre mot de passe est utilisé pour dériver localement une clé de chiffrement (via un algorithme comme PBKDF2 ou Argon2). Cette clé chiffre vos données avant qu’elles n’atteignent le serveur. Le serveur ne reçoit que des blobs opaques. Il ne stocke pas votre mot de passe en clair, il ne stocke même pas un hash qui permettrait de reconstituer la clé. Si vous oubliez votre mot de passe, vos données sont perdues. Définitivement. C’est la contrepartie non négociable du zero-knowledge.
Le test ultime du zero-knowledge : que se passe-t-il quand vous perdez votre mot de passe ?
C’est la question qui sépare le vrai zero-knowledge du marketing. Si vous pouvez réinitialiser votre mot de passe et retrouver vos fichiers, le service n’est pas zero-knowledge – il possède un moyen de déchiffrer vos données sans votre mot de passe, ce qui signifie qu’il peut le faire aussi sous injonction judiciaire ou en cas de compromission interne.
Tresorit, par exemple, est catégorique : pas de récupération du mot de passe. Si vous le perdez et que vous n’avez pas configuré de clé de récupération, vos données sont mathématiquement inaccessibles. Sync.com adopte la même approche. pCloud offre le zero-knowledge via son option Crypto, mais seulement pour le dossier spécifique que vous choisissez de protéger – le reste de votre cloud pCloud n’est pas zero-knowledge.
Et les grands ? Google Drive, OneDrive, Dropbox – aucun n’est zero-knowledge. Ils chiffrent au repos, oui. Mais ils détiennent les clés. Ils peuvent (et doivent, sur demande légale) déchiffrer vos fichiers. C’est un choix architectural assumé qui leur permet d’offrir la recherche plein texte, les aperçus de documents, la co-édition en temps réel et toutes ces fonctionnalités qui nécessitent de voir le contenu côté serveur.
kDrive d’Infomaniak se positionne entre les deux : chiffrement au repos avec des clés gérées par Infomaniak en Suisse, dans un cadre juridique qui offre une protection supérieure aux alternatives américaines. Ce n’est pas du zero-knowledge au sens strict, mais la juridiction suisse compense en partie – un juge américain ne peut pas forcer Infomaniak à fournir vos données, contrairement à Microsoft ou Google. C’est un compromis pragmatique.
Le chiffrement bout-en-bout est le mécanisme, le zero-knowledge est la promesse
La confusion entre E2EE et zero-knowledge est fréquente, et les fournisseurs ne font rien pour la dissiper (ça les arrange). Le chiffrement bout-en-bout est un mécanisme technique : les données sont chiffrées sur votre appareil et déchiffrées uniquement sur l’appareil du destinataire. Le zero-knowledge est une politique architecturale : le fournisseur s’engage à ne jamais avoir accès à vos données en clair, ce qui implique l’E2EE mais va plus loin – pas de logs de contenu, pas de traitement côté serveur, pas de clé maître de secours.
Un service peut être E2EE sans être zero-knowledge (s’il conserve des métadonnées ou possède un mécanisme de récupération). Un vrai zero-knowledge est forcément E2EE. C’est une relation d’inclusion, pas une équivalence.
La gestion des clés détermine si la promesse tient
La différence entre « nous sommes zero-knowledge » et « nous le sommes vraiment » réside dans la gestion des clés de chiffrement. Si le fournisseur génère la clé côté serveur et vous l’envoie, ce n’est pas du zero-knowledge – même s’il prétend « supprimer » la clé après transmission. Si la clé est dérivée de votre mot de passe côté client et ne quitte jamais votre appareil, c’est crédible. Si le fournisseur utilise des HSM (Hardware Security Modules) pour stocker les clés dans un environnement isolé, c’est un entre-deux respectable mais ce n’est pas du zero-knowledge.
Pour vérifier, posez trois questions à votre fournisseur : (1) Pouvez-vous réinitialiser mon mot de passe et me redonner accès à mes fichiers ? Si oui, ce n’est pas zero-knowledge. (2) Où la clé de chiffrement est-elle générée ? Si la réponse est « sur nos serveurs », ce n’est pas zero-knowledge. (3) Un employé de votre entreprise peut-il techniquement accéder au contenu de mes fichiers ? Si la réponse est « seulement en cas de… », ce n’est pas zero-knowledge.
Le zero-knowledge est une garantie puissante, mais c’est aussi un engagement irréversible. Pas de bouton « j’ai oublié mon mot de passe ». Pas de prévisualisation de fichiers dans le navigateur (sauf avec déchiffrement côté client, ce que Proton Drive et Tresorit gèrent assez bien). Pas de recherche dans le contenu des documents côté serveur. Et si vous perdez à la fois votre mot de passe et votre clé de récupération, aucune force sur terre – ni le fournisseur, ni la NSA, ni un tribunal suisse – ne pourra récupérer vos données.
Pour les données critiques (santé, juridique, propriété intellectuelle sensible), c’est exactement ce qu’on veut. Pour le cloud de bureau quotidien d’une PME, le chiffrement standard avec un fournisseur suisse comme Infomaniak offre un ratio sécurité/praticité souvent plus adapté. Le zero-knowledge est un coffre-fort dont vous êtes le seul à avoir la clé – si ça vous rassure plus que ça ne vous inquiète, c’est fait pour vous.