Qu'est-ce que le chiffrement zero-knowledge ? Un guide simple
Le chiffrement zero-knowledge signifie que le fournisseur ne peut pas accéder à vos données.
Le chiffrement à connaissance nulle est une architecture dans laquelle le fournisseur ne détient pas la clé nécessaire pour déchiffrer le contenu utilisateur stocké. Contrairement au chiffrement cloud standard dans lequel le fournisseur contrôle la clé de contenu, le chiffrement côté client peut réserver cette capacité aux appareils des utilisateurs. Une demande légale, une violation ou un initié peut toujours exposer du texte chiffré, des enregistrements de compte, des données de trafic ou d'autres métadonnées conservées par le fournisseur. Les recommandations du NIST sur la gestion des clés placent la garde des clés au cœur de l'accès, mais l'application cliente, le système d'exploitation et l'appareil déverrouillé restent dans la limite de confiance.
Comment fonctionne le chiffrement zero-knowledge
L'analogie la plus simple : un coffre d'hôtel où vous seul définissez la combinaison, et l'hôtel ne la connaît jamais. Si vous oubliez la combinaison, l'hôtel ne peut pas ouvrir le coffre-fort pour vous. Ce n'est pas un défaut de conception. C'est la conception.
En termes techniques, le chiffrement zero-knowledge fonctionne en trois étapes :
Dérivation de clé sur l'appareil. L'utilisateur fournit un identifiant : mot de passe, phrase secrète ou motif. Une fonction de dérivation de clé à partir d'un mot de passe le combine avec un sel pour produire une clé sur l'appareil de l'utilisateur. Une conception bien séparée peut utiliser cette clé pour déverrouiller une clé de chiffrement de contenu aléatoire au lieu de chiffrer chaque fichier directement avec l'identifiant saisi par l'humain.
Chiffrement avant transmission. Toutes les données sont chiffrées sur l'appareil à l'aide de la clé dérivée avant de quitter l'appareil pour le stockage cloud ou la sauvegarde. La sortie chiffrée (texte chiffré) est ce qui est téléchargé.
Le fournisseur ne reçoit aucune clé de contenu en clair. Les clés de contenu existent nécessairement dans la mémoire du client lors de l'utilisation et peuvent également être stockées localement ou à distance dans des enveloppes chiffrées authentifiées. Le fournisseur peut stocker le texte chiffré et les clés encapsulées sans détenir le secret utilisateur nécessaire pour les ouvrir. Les métadonnées de compte, de trafic, de taille des enregistrements et de calendrier peuvent rester visibles.
La contrainte critique : si l'utilisateur perd tous les identifiants et chemins de récupération valides, le contenu chiffré devient inaccessible. La récupération peut encore exister, mais la garde de ses clés doit être expliquée. Si une réinitialisation d'e-mail restaure à elle seule un contenu lisible sans l'approbation de l'ancien appareil, une phrase de récupération, une clé de récupération ou un secret équivalent détenu par l'utilisateur, le fournisseur a conservé un accès effectif au contenu en clair.
Chiffrement zero-knowledge vs autres types de chiffrement
Le terme "chiffrement" apparaît dans les documents marketing de presque tous les services cloud. Les différences entre les types sont substantielles.
| Type | Qui détient la clé | Le fournisseur peut lire les données | Survit à une violation du fournisseur | Exemple |
|---|---|---|---|---|
| Pas de chiffrement | N/A | Oui | Non | Dropbox (niveau standard) |
| Chiffrement en transit (TLS) | Fournisseur | Oui (au repos sur leurs serveurs) | Non | Google Photos |
| Chiffrement côté serveur au repos | Fournisseur | Oui (il détient la clé de déchiffrement) | Partiellement (dépend de l'étendue de la violation) | iCloud (standard) |
| Chiffrement de bout en bout de la plateforme | Appareils clients et système de récupération de compte | Pas via le chemin de service normal | Dépend du client, de la récupération et de l'exposition des métadonnées | iCloud avec protection avancée des données |
| Chiffrement côté client opaque pour le fournisseur | Chemin de récupération contrôlé par le client et l'utilisateur | Aucune clé de contenu en texte brut détenue par le fournisseur | Le contenu peut rester chiffré ; les métadonnées et le texte chiffré peuvent encore fuir | Systèmes de coffre et de sauvegarde chiffrés |
La distinction entre "chiffrement au repos" et "chiffrement zero-knowledge" est la plus fréquemment confondue. Avec le chiffrement au repos, le fournisseur chiffre vos données sur ses serveurs en utilisant des clés qu'il contrôle. Cela protège contre le vol physique du matériel serveur. Cela ne protège pas contre la lecture de vos données par le fournisseur, une assignation gouvernementale pour les données et les clés, ou une menace interne. Le fournisseur a la capacité de déchiffrement.
Avec un chiffrement côté client opaque pour le fournisseur, le service ne reçoit pas la clé de contenu en clair par le protocole documenté. Le texte chiffré stocké peut rester opaque pour ce fournisseur, tandis que le logiciel client, le chemin de récupération, les métadonnées du compte et le canal de distribution du logiciel exigent toujours confiance et examen.
Pourquoi le chiffrement zero-knowledge est important
Les violations de données exposent des milliards d'enregistrements chaque année
L’Identity Theft Resource Center a signalé 3 205 compromissions de données aux États-Unis en 2023, affectant environ 353 millions de personnes. Lorsqu'un fournisseur détient des clés de contenu, une violation peut exposer à la fois les données stockées et un chemin pour les déchiffrer. Un chiffrement opaque pour le fournisseur sépare ces deux éléments : une violation du serveur peut toujours exposer le texte chiffré et les métadonnées, mais pas une clé de contenu en clair détenue par le fournisseur. Deviner l'identifiant et compromettre le client restent des risques distincts.
La contrainte légale est une menace réelle
Les fournisseurs peuvent être tenus de divulguer les données qu’ils conservent. Une conception opaque pour le fournisseur peut limiter cette réponse au texte chiffré et aux métadonnées disponibles du compte, du trafic, de la facturation ou du service, car le fournisseur ne détient pas la clé de contenu en clair. La question de savoir si une autre partie peut obtenir un identifiant d'utilisateur, exploiter un client ou exiger une divulgation est une question distincte. Apple a introduit la protection avancée des données dans iOS 16.2 comme extension facultative du chiffrement de bout en bout pour les données iCloud.
"Faites-nous confiance" n'est pas une architecture de sécurité
Le chiffrement côté serveur repose sur des clés et des politiques contrôlées par le fournisseur. Un chiffrement opaque pour le fournisseur change la garde des clés : le chemin de service documenté ne dispose d'aucune clé de contenu en clair. C'est une frontière architecturale plus solide, mais sa solidité dépend toujours d'un code client correct, d'une distribution authentifiée du logiciel, d'une récupération bien conçue, d'appareils sécurisés et d'une implémentation conforme aux spécifications.
La norme NIST derrière la cryptographie
AES-GCM a été normalisé par le National Institute of Standards and Technology en SP800-38D (2007). AES lui-même a été sélectionné par le NIST lors d'un concours public en 2001. Le « 256 » de AES-256 fait référence à une clé de 256 bits. Une recherche exhaustive sur une clé uniformément aléatoire est informatiquement irréalisable, mais un mot de passe ou un motif choisi par un humain peut fournir beaucoup moins d'entropie, même lorsqu'une fonction de dérivation de clé génère 256 bits.
GCM (mode Galois/Compteur) ajoute le chiffrement authentifié, ce qui signifie que le processus de déchiffrement détecte toute altération du texte chiffré. Si un seul bit des données chiffrées est modifié, le déchiffrement échoue plutôt que de produire une sortie corrompue. Cela empêche les attaquants de manipuler les données chiffrées sans détection.
PBKDF2 (Password-Based Key Derivation Function 2), spécifiée dans RFC8018, convertit un identifiant fourni par un humain en clé de longueur fixe via des appels de fonctions pseudo-aléatoires répétés. Plus d'itérations augmentent le coût de chaque supposition. Elles n’ajoutent pas d’entropie à un motif ou à un mot de passe prévisible : le choix de l'identifiant et la vérification hors ligne comptent donc toujours.
Comment Vaultaire sépare les clés du fournisseur
Vaultaire est un coffre chiffré côté client pour iPhone. Au sens où le marketing parle souvent de « zéro connaissance », son affirmation documentée la plus précise est que Wraxle ne reçoit ni le contenu du coffre en clair ni les clés nécessaires pour le déchiffrer. Voici comment fonctionnent la mise en œuvre et les limites de confiance restantes à chaque couche.
Dérivation de clé. L'utilisateur dessine un motif sur une grille 5x5 de 25 points. PBKDF2-HMAC-SHA512 combine cette séquence avec un sel Keychain commun à tout l'appareil, sur 600 000 itérations, pour dériver une clé de coffre de 256 bits. La clé du coffre authentifie l'index chiffré et désencapsule une clé principale aléatoire distincte de 256 bits. Les informations de récupération, y compris le motif, sont stockées dans une base de données chiffrée par AES-GCM et protégée par le Keychain plutôt que dans des fichiers en clair ou un compte Vaultaire.
Chiffrement de fichiers. Chaque fichier importé est chiffré avec AES-256-GCM sous la clé principale aléatoire. CryptoKit crée des boîtes scellées authentifiées avec des nonces neufs, et le format en flux dérive un nonce distinct pour chaque bloc ordonné.
Chiffrement des métadonnées. Les noms de fichiers, les types MIME, les dates, les enregistrements d'index et les données miniatures sont également protégés par AES-256-GCM. Vaultaire n'utilise pas ChaCha20 pour les métadonnées du coffre.
Gestion des clés. Vaultaire stocke le sel de l'appareil et la base de données de récupération chiffrée comme éléments ordinaires de mot de passe générique du Keychain iOS, protégés par la classe d'accessibilité WhenUnlockedThisDeviceOnly. Les clés de coffre dérivées de motifs et les clés principales aléatoires sont traitées dans la mémoire de l'application via CryptoKit. Le verrouillage supprime l'état de la clé active, mais Swift et iOS ne garantissent pas que chaque copie transitoire soit écrasée.
Découverte du coffre. L'interface normale n'affiche pas de liste de coffres. Le format de stockage conserve un répertoire de stockage pour chaque coffre. Une personne ayant accès au conteneur d'application peut donc compter les coffres, bien que les noms des répertoires ne révèlent pas de motifs, de noms ou de contenu en clair. Voir l'architecture de sécurité complète et l'explication du chiffrement par motif.
Comment savoir si une application utilise un vrai chiffrement zero-knowledge
Commencez par trois tests rapides, puis vérifiez l'architecture publiée :
Le test du mot de passe oublié. Si une réinitialisation par e-mail suffit à restaurer des données lisibles, demandez quel mécanisme détenu par le fournisseur a récupéré la clé de contenu effective. Les phrases de récupération détenues par l'utilisateur, l'approbation par un ancien appareil et les réinitialisations contrôlées par le fournisseur sont des conceptions différentes.
Le test du nouvel appareil. Si un nouvel appareil restaure un contenu lisible, identifiez le secret ou l'appareil de confiance qui l'a autorisé. Une simple connexion au compte laisse penser à un chemin de récupération contrôlé par le fournisseur ; une phrase de récupération et des enregistrements de sauvegarde chiffrés peuvent préserver la séparation des clés du fournisseur.
Le test du compte. Une adresse e-mail ou un numéro de téléphone relie l’identité aux métadonnées du service, mais cela ne prouve pas en soi que le fournisseur peut déchiffrer le contenu. Inspectez la hiérarchie des clés, la conception de la récupération, le code ou l'audit du client, la politique de métadonnées, et vérifiez si le texte chiffré authentifié permet de tester des identifiants hors ligne.
Ces tests sont des filtres, pas une preuve de sécurité. Une spécification cohérente doit nommer la clé de contenu, la clé de déverrouillage, les sels, les paramètres de dérivation, le format de chiffrement authentifié, les règles d'usage des nonces, les enveloppes de récupération, le stockage local des secrets, les métadonnées cloud et l'endroit où les clés existent en clair. Un examen indépendant constitue une preuve plus solide qu’une étiquette de produit.
Questions fréquentes
Le chiffrement zero-knowledge est-il identique au chiffrement de bout en bout ?
Ils se chevauchent mais ne sont pas identiques. Le chiffrement de bout en bout (E2EE) signifie que les données sont chiffrées sur l'appareil de l'expéditeur et déchiffrées uniquement sur l'appareil du destinataire. Le chiffrement zero-knowledge signifie que le fournisseur ne peut pas accéder aux données. Un service peut être chiffré de bout en bout sans être zero-knowledge si le fournisseur a généré ou a accès aux clés à un moment donné. Le chiffrement zero-knowledge est la norme la plus stricte.
Que se passe-t-il si je perds mon mot de passe avec le chiffrement zero-knowledge ?
Vos données deviennent définitivement inaccessibles si tous les identifiants valides et toutes les enveloppes de récupération sont perdus. Une réinitialisation ou une clé principale contrôlée par le fournisseur affaiblirait cette séparation : la récupération doit donc être conçue à part. Vaultaire génère une phrase personnalisée de 9 mots distincts dont la clé de récupération dérivée ouvre une enveloppe de clé de coffre chiffrée. La phrase ne régénère ni n'encode la clé, et la restauration sur un nouvel appareil nécessite également la clé chiffrée correspondante dans les enregistrements CloudKit.
Les forces de l'ordre peuvent-elles accéder aux données chiffrées zero-knowledge ?
Un fournisseur peut devoir divulguer le texte chiffré stocké et les métadonnées de compte, de trafic, de facturation ou de service qu'il conserve. Sans clé de contenu en clair détenue par le fournisseur, ce fournisseur ne peut pas utiliser son chemin de service normal pour déchiffrer le contenu. L'exploitation de l'appareil, la découverte des identifiants, les copies de récupération et la divulgation forcée sont des voies distinctes dont la légalité et l'efficacité varient selon la juridiction et les faits.
Le chiffrement zero-knowledge est-il plus lent que le chiffrement ordinaire ?
La performance d'AES-256-GCM ne dépend pas de celui qui détient la clé. La dérivation basée sur un mot de passe ajoute du travail lors du déverrouillage et sa durée dépend de l'algorithme, du nombre d'itérations, de l'appareil et de l'implémentation. Les applications doivent mesurer ce coût sur le matériel pris en charge et trouver l'équilibre entre réactivité et coût imposé à chaque supposition hors ligne.
Zero-knowledge signifie-t-il que l'application ne collecte absolument aucune donnée ?
Pas nécessairement. Le terme concerne le fait que le fournisseur ne détient pas les clés de contenu, et non l'ensemble des flux de données. Une application peut toujours traiter des données de compte, des analyses, des rapports d'erreur, des adresses IP, des tailles d'enregistrement, des délais ou d'autres métadonnées de service. Vaultaire ne nécessite aucun compte d'identité. Ses statistiques d'application et ses diagnostics de plantage sont activés par défaut et se désactivent avec « Partager les erreurs anonymement » dans Réglages. La politique d'événements documentée exclut le contenu du coffre, les motifs, les phrases et les clés de déchiffrement ; la politique de confidentialité décrit les règles actuelles de collecte et de conservation.
Comment le chiffrement zero-knowledge se compare-t-il à la Protection avancée des données d'Apple ?
La protection avancée des données (ADP) d'Apple, introduite dans iOS 16.2, étend le chiffrement de bout en bout à d'autres catégories iCloud et utilise le modèle de récupération du compte Apple. Vaultaire chiffre le contenu du coffre sur l'appareil et ne nécessite aucun compte d'identité Vaultaire ; sa sauvegarde iCloud (activée par défaut) et la synchronisation et le partage en option utilisent des enregistrements CloudKit chiffrés côté client dans le compte Apple de l'utilisateur. Vaultaire propose aussi un accès aux coffres séparé par motif et un mode contrainte, avec les limites de stockage et de récupération décrites dans son documentation sur le déni plausible.
Résumé
Mieux vaut lire le chiffrement à connaissance nulle comme une affirmation sur la séparation des clés : le fournisseur ne détient pas la clé en clair nécessaire pour déchiffrer le contenu stocké. C'est plus solide que le chiffrement côté serveur avec des clés contrôlées par le fournisseur, mais cela ne signifie pas que les clés n'existent qu'en mémoire, que les métadonnées disparaissent ou que toute compromission de client et d'appareil est vaincue. Jugez le produit sur sa hiérarchie de clés, de sa conception de récupération, de sa mise en œuvre et de son examen indépendant.