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 sans connaissance est une architecture limitée au fournisseur dans laquelle le service 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 conserver cette capacité sur les 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 directives de gestion des clés du NIST placent la conservation des clés au cœur de l'accès, mais l'application client, le système d'exploitation et l'appareil déverrouillé restent une partie de la limite de confiance.
Comment fonctionne le chiffrement zero-knowledge
L'analogie la plus simple : un coffre-fort 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 des informations d'identification telles qu'un mot de passe, une phrase secrète ou un modèle. Une fonction de dérivation de clé basée sur un mot de passe la 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 les informations d'identification humaines.
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 texte brut. 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 du compte, du trafic, de la taille de l'enregistrement et du timing peuvent toujours 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 sa garde clé 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 chemin efficace vers le texte 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 aveugle au 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 crypté ; les métadonnées et le texte chiffré peuvent encore fuir | Systèmes de coffre-fort et de sauvegarde crypté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 le chiffrement côté client aveugle du fournisseur, le service ne reçoit pas la clé de contenu en texte brut via 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 livraison du logiciel nécessitent 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. Le chiffrement aveugle du fournisseur sépare ces actifs : 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. La devinette des informations d’identification et la compromission des clients 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 aveugle au 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 texte brut. 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 iCloud données.
"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. Le chiffrement aveugle du fournisseur modifie la garde des clés, de sorte que le chemin de service documenté ne dispose pas d'une clé de contenu en texte brut. Il s'agit d'une frontière architecturale plus forte, mais sa force dépend toujours d'un code client correct, d'une livraison de logiciels authentifiés, d'une récupération sonore, de périphériques 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 modèle 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 (Fonction 2 de dérivation de clé basée sur un mot de passe), 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. Ils n’ajoutent pas d’entropie à un modèle ou à un mot de passe prévisible, le choix des informations d’identification et la vérification hors ligne restent donc importants.
Comment Vaultaire implémente la séparation des clés fournisseur
Vaultaire est un coffre-fort chiffré côté client pour iPhone. Dans le sens du produit, souvent commercialisé comme « zéro connaissance », son affirmation documentée la plus étroite est que Wraxle ne reçoit pas le contenu du coffre-fort en texte brut 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 clé. L'utilisateur dessine un motif sur une grille 5x5 de 25 points. PBKDF2-HMAC-SHA512 combine cette séquence avec une seule à l'échelle de l'appareil Keychain salt pour 600 000 itérations pour dériver une clé de coffre-fort de 256 bits. La clé du coffre-fort authentifie l'index chiffré et encapsule une clé principale aléatoire distincte de 256 bits. Les informations de récupération, y compris le modèle, sont stockées dans un AES-GCM crypté Keychain base de données plutôt que des fichiers en texte brut ou un compte Vaultaire.
Cryptage de fichiers. Chaque fichier importé est crypté avec AES-256-GCM sous la clé principale aléatoire. CryptoKit crée des boîtes scellées authentifiées avec de nouveaux noms occasionnels, et le format de streaming dérive un nom occasionnel distinct pour chaque morceau commandé.
Cryptage des métadonnées. Noms de fichiers, MIME les types, 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-fort.
Gestion des clés. Vaultaire stocke le sel de son appareil et la base de données de récupération cryptée comme d'habitude iOS Keychain éléments de mot de passe générique protégés par le WhenUnlockedThisDeviceOnly classe d'accessibilité. Les clés de coffre-fort dérivées de modèles 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-fort. L'interface normale n'affiche pas de liste de coffre-fort. Le format local stocke exactement 1 fichier d'index chiffré pour chaque coffre-fort, et le code de maintenance peut énumérer ces fichiers. Une personne ayant accès au conteneur d'application peut donc compter les index chiffrés, bien que les noms de fichiers ne révèlent pas de modèles, de noms ou de contenu en texte brut. Voir l'intégralité architecture de sécurité et explication du cryptage des modèles.
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 la réinitialisation du courrier électronique restaure à elle seule les 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 des anciens appareils 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 l'appareil secret ou de confiance qui l'a autorisé. La connexion au compte suggère à elle seule 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écrypter le contenu. Inspectez la hiérarchie des clés, la conception de la récupération, le code ou l'audit client, la politique de métadonnées et si le texte chiffré authentifié permet la vérification des informations d'identification 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 occasionnelles, les enveloppes de récupération, le stockage secret local, les métadonnées du cloud et le point où existent les clés en texte brut. 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 les limites du fournisseur, la récupération doit donc être conçue séparément. Vaultaire génère une phrase personnalisée contenant 9 mots distincts dont la clé de récupération dérivée ouvre une enveloppe de clé de coffre-fort cryptée. La phrase ne régénère ni ne code la clé, et la restauration sur un nouvel appareil nécessite également la clé chiffrée correspondante. CloudKit enregistrements.
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 texte brut détenue par le fournisseur, ce fournisseur ne peut pas utiliser son chemin de service normal pour déchiffrer le contenu. L'exploitation des appareils, la découverte des informations d'identification, 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 ?
AES-256-GCM la performance 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 équilibrer la réactivité par rapport au coût imposé à chaque estimation hors ligne.
Zero-knowledge signifie-t-il que l'application ne collecte absolument aucune donnée ?
Pas nécessairement. Le terme concerne la limite de clé de contenu du fournisseur, et non tous les 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é et affirme que ses analyses basées sur le consentement excluent le contenu, les modèles, les phrases et les clés de déchiffrement du coffre-fort ; c'est 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 à des iCloud catégories et utilise le modèle de récupération de compte Apple. Vaultaire conserve le contenu du coffre-fort local par défaut et ne nécessite aucun compte d'identité Vaultaire ; la sauvegarde, la synchronisation et le partage en option utilisent le chiffrement côté client CloudKit enregistrements dans le compte Apple de l'utilisateur. Vaultaire propose également un accès au coffre-fort séparé par motifs et mode contrainte, avec les limites de stockage et de récupération décrites dans son documentation sur le déni plausible.
Résumé
Le chiffrement sans connaissance est mieux traité comme une revendication de séparation des clés du fournisseur : le service ne contient pas la clé en clair nécessaire pour déchiffrer le contenu stocké. C'est plus puissant 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 en fonction de sa hiérarchie clé, de sa conception de récupération, de sa mise en œuvre et de son examen indépendant.