Le chiffrement zero-knowledge expliqué

Q: Que voit réellement le serveur dans un système zero-knowledge ?

C'est la question critique. Un serveur ne peut jamais voir rien — il y a toujours des métadonnées requises pour faire fonctionner le service. Dans un système zero-knowledge bien conçu, le serveur voit :

Réponse rapide. Le chiffrement zero-knowledge est une architecture où le service qui héberge vos données ne peut pas les déchiffrer — la clé de chiffrement ne quitte jamais votre appareil en clair. Même si le serveur est compromis, fait l'objet d'une réquisition judiciaire, ou est administré par un employé malveillant, tout ce dont il dispose est de la donnée chiffrée opaque. Utilisé par Signal, Tutanota, Proton, Bitwarden et la sync cloud de Filarr.

Quand un service cloud annonce « vos données sont chiffrées », c'est généralement vrai mais rarement suffisant. Les données sont chiffrées en transit (TLS) et au repos (chiffrement côté serveur avec des clés que le service détient). Mais le service possède toujours les clés. S'il veut lire vos données, il peut. S'il y est contraint par un tribunal, il le fera.

Le chiffrement zero-knowledge est l'architecture qui rend ça impossible par construction. Le service ne peut littéralement pas lire vos données, parce que les clés pour les déchiffrer ne quittent jamais votre appareil.

Cet article explique le zero-knowledge en français simple, détaille comment ça fonctionne en pratique, et clarifie la confusion classique avec le chiffrement end-to-end.

Que signifie le chiffrement zero-knowledge ?

« Zero-knowledge » dans ce contexte est un terme marketing qui emprunte le nom d'un vrai concept cryptographique (les preuves zero-knowledge) et l'utilise de manière relâchée. Le terme technique plus clair est chiffrement côté client sans accès aux clés côté serveur.

La promesse est simple :

Votre appareil génère les clés de chiffrement
Votre appareil chiffre vos données avant de les envoyer au serveur
Le serveur ne stocke que des blobs chiffrés et n'a jamais les clés pour les déchiffrer
Quand vous vous connectez depuis un autre appareil, votre mot de passe (ou un secret dérivé) déchiffre les clés localement

Le résultat : le service a zero connaissance du contenu de vos données. Il peut voir les métadonnées (tailles de fichiers, timestamps de sync, adresses IP), mais le contenu lui-même lui est opaque.

En quoi le zero-knowledge diffère du chiffrement cloud classique ?

Presque tous les services cloud aujourd'hui chiffrent les données au repos. Dropbox, Google Drive, iCloud, OneDrive — tous chiffrent vos fichiers sur leurs serveurs. La question cruciale est : qui possède la clé ?

Modèle de chiffrement	Le serveur peut déchiffrer ?	Exemples
TLS uniquement (en transit)	Oui — le serveur stocke en clair	Beaucoup de petits services
Chiffrement au repos côté serveur	Oui — le serveur a la clé	Dropbox, Google Drive, iCloud (la plupart)
Chiffrement côté client, serveur garde la clé	Oui (toujours !)	Certains services « chiffrés » où le serveur garde une copie de la clé maître
Zero-knowledge / E2E	Non — clé uniquement sur le client	Signal, Proton, Tutanota, Bitwarden, sync cloud Filarr

Le chiffrement côté serveur protège contre une seule menace : un voleur qui dérobe les disques physiques du data center. Il ne protège pas contre l'opérateur du service qui lit vos données, les hackers qui pénètrent le service, ou les gouvernements qui contraignent le service à livrer vos données.

Le zero-knowledge protège contre les trois.

Comment fonctionne réellement le chiffrement zero-knowledge ?

Le mécanisme est une chaîne d'opérations exécutées entièrement sur votre appareil. Un service zero-knowledge typique pour une app de notes fonctionne comme ça :

SUR VOTRE APPAREIL                              SUR LE SERVEUR
──────────────────                              ──────────────

1. Vous saisissez votre mot de passe
        │
        ▼
2. KDF (PBKDF2 / Argon2id)
   étire le mot de passe en KEK
        │
        ▼
3. File Encryption Key (FEK)
   aléatoire générée pour chaque fichier
        │
        ▼
4. AES-256-GCM(fichier, FEK) ──► blob chiffré ──► stocké en octets opaques
        │
        ▼
5. AES-256-GCM(FEK, KEK) ────► FEK chiffrée ───► stockée à côté du blob
        │
        ▼
6. La KEK ne quitte jamais l'appareil
   (certains services uploadent une copie
   chiffrée de la KEK que seul votre
   mot de passe peut déverrouiller)

Le point de vue du serveur sur le monde : un flux d'octets opaques. Même avec un accès root complet au serveur, un attaquant lit du bruit chiffré.

Pour que la vue de l'utilisateur ait du sens entre appareils, la KEK chiffrée est généralement uploadée aussi — mais uniquement sous forme chiffrée. Pour la déverrouiller sur un nouvel appareil, vous devez ressaisir votre mot de passe, que le serveur ne voit jamais.

Que voit réellement le serveur dans un système zero-knowledge ?

C'est la question critique. Un serveur ne peut jamais voir rien — il y a toujours des métadonnées requises pour faire fonctionner le service. Dans un système zero-knowledge bien conçu, le serveur voit :

Un blob chiffré opaque par fichier
La taille de chaque blob (à un facteur près — certains systèmes complètent)
Les timestamps de sync (quand les blobs sont mis à jour)
Votre identifiant de compte (typiquement un email ou un nom d'utilisateur)
Les métadonnées d'authentification (un vérificateur de mot de passe, mais jamais le mot de passe lui-même)

Il ne voit pas :

Le contenu des fichiers
Les noms des fichiers (les systèmes bien conçus les chiffrent aussi)
La structure des dossiers (chiffrée également)
Les titres de notes, tags, ou toute métadonnée intra-app

Les catégories qui fuient (taille, timing, email du compte) constituent un risque de canal auxiliaire — un adversaire suffisamment motivé peut parfois inférer des informations à partir des seules tailles. Les implémentations zero-knowledge sérieuses complètent les blobs vers des tailles cibles et ajoutent du jitter sur les timestamps pour atténuer ça.

Pourquoi le zero-knowledge compte pour vos données ?

Trois scénarios concrets. Dans une architecture zero-knowledge :

Scénario 1 — Le service est piraté. Un attaquant vole toute la base de données. Il récupère des blobs chiffrés et des adresses email, rien d'autre. Les blobs sont inutiles sans les clés, qui sont sur les appareils des utilisateurs.

Scénario 2 — Le service est réquisitionné. Un gouvernement contraint le service à livrer les données utilisateur. Le service obtempère — en livrant ce qu'il a : des blobs chiffrés. Le gouvernement ne peut pas les déchiffrer non plus.

Scénario 3 — Un employé malveillant ou négligent. Un admin avec accès base de données essaie de lire les fichiers utilisateurs. Il voit des octets chiffrés. Il ne peut pas déchiffrer sans le mot de passe de l'utilisateur, que le système n'a jamais stocké.

Le service ne peut littéralement pas vous trahir, même s'il le veut ou s'il y est contraint. C'est la valeur du zero-knowledge : l'exigence de confiance est éliminée par les mathématiques, pas par des promesses.

Quel est le coût du chiffrement zero-knowledge ?

Le zero-knowledge a de vrais compromis d'ingénierie.

1. Mot de passe perdu = données perdues. Si le service ne peut pas déchiffrer vos données, il ne peut pas non plus réinitialiser votre mot de passe. La plupart des services zero-knowledge offrent des codes de récupération ou des phrases de récupération, mais si vous perdez votre mot de passe ET votre secret de récupération, vos données sont définitivement inaccessibles. C'est le coût de la vraie vie privée.

2. Les fonctionnalités côté serveur sont limitées. Le service ne peut pas chercher dans vos données, ne peut pas générer d'aperçus côté serveur, ne peut pas lancer de résumé IA sur vos notes — parce qu'il ne voit rien. Toutes ces fonctionnalités doivent tourner sur votre appareil.

3. La sync multi-appareils est plus dure. Partager les clés entre vos appareils requiert un protocole de pairing soigné (typiquement ECDH avec dérivation HKDF). Concevoir ça correctement n'est pas trivial.

4. La collaboration en temps réel est plus dure. Si deux utilisateurs éditent le même document chiffré, le merge doit se faire côté client ou via des protocoles cryptographiques (les CRDT sur données chiffrées sont un sujet de recherche actif).

Ce sont des coûts acceptés. La garantie de vie privée est trop précieuse pour la sacrifier pour des gains marginaux de fonctionnalités.

En quoi le zero-knowledge diffère du chiffrement end-to-end ?

Les termes sont souvent utilisés comme synonymes. Ils se chevauchent mais ne sont pas identiques.

Le chiffrement end-to-end (E2E) décrit une propriété : seules les extrémités d'une communication peuvent lire le contenu. Aucun intermédiaire (serveur, FAI) ne le peut. L'exemple canonique est Signal : un message est chiffré sur votre téléphone, envoyé via les serveurs Signal, et déchiffré uniquement sur le téléphone du destinataire.

Le zero-knowledge est un modèle de déploiement pour les services de stockage : le serveur stocke vos données chiffrées avec des clés qu'il n'a pas. On peut le voir comme du E2E appliqué à une « communication » entre votre vous-passé (au moment où vous uploadez) et votre vous-futur (au moment où vous téléchargez sur un autre appareil).

La plupart des services zero-knowledge implémentent aussi du E2E pour le partage (quand vous partagez un fichier avec un autre utilisateur, les clés sont échangées de client à client sans que le serveur ne les voie). Mais on peut avoir du zero-knowledge sans partage (un coffre personnel) ou du E2E sans stockage (une app de chat qui ne garde pas l'historique).

Pour une comparaison plus profonde, voir end-to-end vs zero-knowledge : quelle différence ?.

Quelles apps utilisent le chiffrement zero-knowledge ?

Services notables qui implémentent correctement le zero-knowledge :

Signal — messagerie end-to-end
Bitwarden — gestionnaire de mots de passe (aussi zero-knowledge pour le stockage du coffre)
1Password — gestionnaire de mots de passe
Proton (Mail, Drive, Calendar) — fournisseur suisse, entièrement zero-knowledge
Tutanota — email, agenda, contacts chiffrés
Standard Notes — notes chiffrées
Cryptomator — chiffrement local pour stockage cloud
Filarr — workspace local-first avec sync cloud zero-knowledge optionnelle

Services souvent crus zero-knowledge mais qui ne le sont pas : iCloud (Apple détient les clés pour la plupart des données, sauf les éléments derrière Advanced Data Protection), Dropbox, Google Drive, OneDrive.

Comment Filarr implémente le zero-knowledge ?

Filarr est un workspace local-first où la couche de sync cloud est zero-knowledge. L'architecture :

Les fichiers vivent chiffrés sur votre disque d'abord. Pas besoin de cloud pour que l'app locale fonctionne — c'est la partie local-first.
Quand vous activez la sync cloud, votre appareil chiffre chaque fichier avec AES-256-GCM en utilisant une FEK par fichier. Voir KEK et FEK expliqués pour la hiérarchie de clés.
Le serveur ne stocke que des blobs chiffrés. Les données vivent sur Cloudflare R2 en Europe. Sans votre mot de passe, les blobs sont du bruit.
Le pairing multi-appareils utilise ECDH (Diffie-Hellman sur courbe elliptique) avec des clés de session dérivées via HKDF pour partager votre clé maître entre vos appareils sans jamais l'exposer au serveur.
Même votre login compte utilise un vérificateur de mot de passe — votre mot de passe n'arrive jamais sur nos serveurs, seulement un dérivé qui prouve que vous le connaissez.

Le résultat : si nos serveurs étaient compromis demain, des attaquants récupéreraient du bruit chiffré et des emails. Ils ne pourraient lire aucun fichier. Si on recevait une réquisition, on ne pourrait livrer que ce qu'on a — des blobs chiffrés — et on ne peut pas les déchiffrer.

Lire l'architecture de sécurité complète de Filarr pour les paramètres exacts, le modèle de menace et les résultats d'audit.