Architecture zéro connaissance : le serveur ne voit rien

L'architecture zéro connaissance signifie que le fournisseur de services n'a aucune capacité technique à lire vos fichiers — les clés de chiffrement n'atteignent jamais leurs serveurs, et il n'existe ni clé maître, ni porte dérobée, ni "faites-nous confiance" requis. Votre navigateur chiffre les fichiers avec AES-256-GCM avant l'envoi en utilisant une clé générée localement, et cette clé ne parvient au destinataire que via le fragment d'URL après #, que les navigateurs ne transmettent jamais aux serveurs. Même sous une réquisition judiciaire valide, le fournisseur ne peut produire que du texte chiffré. C'est le modèle utilisé par Tresorit, Proton, SwissTransfer et HexaTransfer, et il est mathématiquement différent du "chiffrement au repos".

La preuve se trouve dans ce que le serveur peut produire

Le test le plus probant du zéro connaissance : que pourrait remettre l'entreprise si elle y était contrainte ? Dans le stockage cloud traditionnel (Google Drive, Dropbox, OneDrive), la réponse est : vos fichiers, en clair. Le rapport de transparence 2023 de Google montre qu'ils ont répondu favorablement à 83 % des demandes gouvernementales, produisant le contenu des utilisateurs quand la loi l'exigeait. Ce n'est pas un échec de la sécurité de Google — c'est la façon dont l'architecture fonctionne.

Avec le zéro connaissance, l'entreprise peut produire :

Des blobs de fichiers chiffrés (inutiles sans la clé)
Des métadonnées de compte (e-mail, IP d'inscription)
Des adresses IP et horodatages d'envoi et de téléchargement
Des informations de paiement le cas échéant

Elle ne peut pas produire les noms de fichiers, le contenu, l'identité du destinataire, ni les clés de déchiffrement. Non pas parce qu'elle refuse — mais parce qu'elle ne les possède pas.

L'astuce du fragment d'URL, expliquée précisément

Le mouvement technique central consiste à utiliser le fragment d'URL comme canal de clé discret. Quand un navigateur demande https://hexatransfer.com/d/xyz789#k=BASE64KEY, il envoie uniquement GET /d/xyz789 au serveur. Le fragment reste dans la barre d'adresse du navigateur. Le JavaScript lit ensuite la clé via window.location.hash et la passe à crypto.subtle.decrypt().

Cette approche a été pionnée par Mega.nz vers 2013 et affinée par Firefox Send avant que Mozilla ne le ferme en 2020. Le modèle est désormais standard. Les journaux côté serveur, y compris les journaux d'accès sur nginx ou Caddy, ne capturent jamais le fragment car la RFC 3986 HTTP le définit comme étant exclusivement côté client.

Un fournisseur pourrait théoriquement journaliser le fragment via du JavaScript côté client, c'est pourquoi les services zéro connaissance publient leur code client pour inspection et l'expédient souvent sous forme d'assets statiques signés servis depuis une origine séparée.

Pourquoi c'est différent du "chiffrement au repos"

Chaque fournisseur cloud chiffre les fichiers au repos — c'est une exigence de base, généralement requise par les certifications SOC 2 Type II et ISO 27001. Mais le "chiffrement au repos" avec des clés détenues par le fournisseur signifie que le chiffrement est invisible pour les attaquants ayant des disques volés, et invisible pour vous dans le sens où le fournisseur déchiffre automatiquement sur demande.

Le zéro connaissance inverse la garde des clés : vous détenez la clé, le fournisseur détient le texte chiffré. Le fournisseur ne tire aucun bénéfice à déchiffrer car il ne peut pas. Cela importe face à trois menaces spécifiques :

Employés malveillants. Un employé du fournisseur avec accès à la base de données ne voit que du texte chiffré.
Réquisitions judiciaires. L'article 48 du RGPD et les demandes en vertu du CLOUD Act américain peuvent contraindre la divulgation, mais on ne peut pas divulguer ce qu'on n'a pas.
Violations de serveurs. La violation de LastPass en 2021 a exposé des coffres chiffrés ; les mots de passe maîtres faibles ont quand même été craqués, mais la conception zéro connaissance a empêché une exposition massive de texte en clair.

Ce qui est chiffré, ce qui reste des métadonnées

Une implémentation naïve chiffre le contenu des fichiers mais laisse les noms de fichiers, tailles et structure de dossiers visibles. Le vrai zéro connaissance chiffre aussi le nom du fichier, généralement en préfixant un en-tête JSON comme {"name": "bilan-Q4.pdf", "type": "application/pdf"} aux octets du fichier avant le chiffrement AES-GCM.

Métadonnées difficiles à cacher :

Taille du fichier — la longueur du texte chiffré approxime la longueur du texte en clair. Le rembourrage vers des tailles fixes (1 Mo, 10 Mo, 100 Mo, 1 Go) masque cela mais gaspille de la bande passante.
Horodatage d'envoi — la corrélation d'horodatages avec d'autres données peut quand même divulguer des informations.
Adresses IP — le fournisseur voit qui a envoyé et téléchargé. Combinez avec Tor ou un VPN de confiance si cela est important.

Proton et Tresorit publient des matrices d'exposition de métadonnées détaillées. SwissTransfer et HexaTransfer adoptent une approche plus simple : métadonnées minimales, rétention courte (24 heures à 7 jours), et aucun lien avec un compte pour les transferts gratuits.

Le problème d'authentification

Le zéro connaissance crée un défi : si le serveur ne peut pas déchiffrer vos fichiers, comment authentifie-t-il les utilisateurs pour empêcher des inconnus de télécharger ? Trois modèles courants :

Authentification par lien. La possession de l'URL (et du fragment) constitue l'autorisation. Utilisé par SwissTransfer, HexaTransfer, Tresorit Send. Simple, fonctionne sans compte.
Liens protégés par mot de passe. Le fragment d'URL contient un sel ; la clé réelle est dérivée avec PBKDF2 à partir du mot de passe. Le serveur stocke un vérificateur (hash de la clé) pour rejeter rapidement les mauvaises tentatives.
Zéro connaissance lié à un compte. Proton et Tresorit dérivent votre clé maître de votre mot de passe de connexion via Argon2id, puis l'utilisent pour déverrouiller les clés par fichier stockées chiffrées sur le serveur.

Chacun a ses compromis. Basé sur un lien : le plus simple mais expose la clé à quiconque obtient l'URL. Protégé par mot de passe : ajoute un second facteur. Lié à un compte : nécessite de faire confiance au code client pour ne pas exfiltrer la clé maître.

Pièges d'implémentation qui brisent le zéro connaissance

Plusieurs défaillances réelles méritent d'être connues :

Aperçus de fichiers côté serveur. Si le fournisseur génère des vignettes ou extrait du texte pour la recherche, il a besoin du texte en clair. Les services zéro connaissance ne peuvent pas proposer ces fonctionnalités sur du contenu chiffré.
Résolution des conflits de synchronisation. Comparer des contenus de fichiers entre appareils nécessite normalement le texte en clair. Syncthing et Cryptomator gèrent cela avec des différences côté client.
SDK d'analytics. Des scripts tiers de Google Analytics ou Segment peuvent lire window.location.hash dans le code client. Les services zéro connaissance hébergent eux-mêmes leurs analytics ou suppriment l'accès au fragment.
Réinitialisation de mot de passe. Si le fournisseur peut réinitialiser votre mot de passe et vous donner quand même accès à d'anciens fichiers, il doit détenir une clé de récupération — ce qui brise le zéro connaissance. Proton avertit explicitement que la réinitialisation du mot de passe entraîne la perte des données chiffrées.

Qui délivre vraiment le zéro connaissance

Une courte liste de services avec des affirmations de zéro connaissance crédibles, vérifiées par des audits tiers (Cure53, NCC Group, Trail of Bits) :

Tresorit — suisse, SOC 2 Type II, synchronisation de fichiers et Send zéro connaissance.
Proton Drive — suisse, basé sur le modèle cryptographique de Proton Mail.
SwissTransfer — niveau gratuit avec E2EE optionnel, géré par Infomaniak.
Mega.nz — Nouvelle-Zélande, livre blanc de cryptographie publié.
HexaTransfer — basé sur navigateur, sans compte, 10 Go par transfert.

Services chiffrés mais pas zéro connaissance : Google Drive, Dropbox, OneDrive, Box, iCloud (sauf le niveau Advanced Data Protection) et le niveau standard de WeTransfer.

Mise en pratique

Avant de faire confiance à un service avec des fichiers sensibles, parcourez cette liste de vérification :

La politique de confidentialité stipule-t-elle que le fournisseur ne peut pas lire vos fichiers ?
Existe-t-il un livre blanc de sécurité publié nommant AES-256-GCM et le KDF ?
L'URL de partage contient-elle un fragment (texte après #) ?
Existe-t-il des rapports d'audit tiers des 24 derniers mois ?
Le code client est-il open source ou au moins auditable ?

Quatre oui signifient que vous avez trouvé un service zéro connaissance. Trois ou moins signifient que le fournisseur peut voir vos fichiers.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.