Le déclic : séparer la dédup (clé de
convergence) de la récupération (clé d'enveloppe).
Personne ne mémorise de secret par client — on
empile les clés.
On ne demande pas à chaque client de conserver un secret. On met en place une hiérarchie de clés (envelope encryption), où dédup et récupération vivent à des étages différents :
CK — clé de convergence,
par revendeur. C'est elle qui fait
converger les chunks identiques. Partagée dans
le pool, gérée par la plateforme, jamais
mémorisée par un humain.
Les clés de chunk =
BLAKE3_keyed(CK, chunk), stockées
dans les manifestes. C'est
obligé : on ne peut pas re-dériver une clé
convergente sans le clair, donc la recette de
chaque fichier embarque les clés de ses propres
chunks.
CMK — clé maître du client final. Chiffre
SES manifestes et sa racine. C'est ça,
« les clés de mes données ».
KEK — clés d'enveloppe qui
emballent la CMK. C'est ici, et
uniquement ici, que vit la politique de
récupération.
Hiérarchie de clés — du haut (récupération) au
bas (données)
Pour lire un fichier, il faut descendre toute la
chaîne :
KEK → CMK → manifeste → clé_chunk → chunk. La récupération agit tout en haut (sur la
CMK) ; la dédup agit tout en bas (sur les
chunks).
Conséquence — deux risques à deux étages
Le pool de chunks est partagé au niveau revendeur,
mais les manifestes de chaque client sont chiffrés
sous SA CMK. Un voisin peut, avec CK,
confirmer l'existence d'un chunk qu'il devine
(l'oracle, au niveau chunk) — mais pour
lire le fichier entier d'un voisin, il lui
faudrait son manifeste. Les deux risques ne sont pas
au même étage.
Deux postures — une seule implémentation. La CMK peut être emballée sous plusieurs KEK simultanément ; les deux modes ne sont que deux configurations d’emballage différentes, gérées par le même code.
Configurations d'emballage de la CMK
Les deux modes coexistent sur la même plateforme. L'emballage (b) — KEK managée — est simplement présent ou absent. Activer le ZK = retirer cet emballage : acte fort, irréversible sauf en ré-activant le managé.
Flux du mode managéInscription : la CMK est générée localement, puis emballée sous (a) la KEK passphrase et (b) la KEK managée du revendeur ; les deux CMK-emballées sont stockées dans les métadonnées. La KEK managée ne sort jamais du coffre.
Usage normal : aucun appel au coffre. Le client déverrouille sa CMK via sa passphrase localement.
Récupération : après vérification d'identité par le revendeur, le backend demande au coffre de déballer la CMK à l'intérieur (unwrap), puis la ré-emballe sous la nouvelle passphrase (wrap). Pendant cette opération la CMK transite en clair dans la RAM de l'infrastructure — c'est le prix explicite de la récupérabilité.
Mode zéro-connaissance — acte fort
Basculer en ZK retire l'emballage managé. Garde-fous obligatoires : avertissement sans ambiguïté (« plus personne côté serveur ne pourra récupérer vos données »), double confirmation, tracé dans l'audit log. État du mode (managé ou ZK) visible dans le dashboard client, sur les factures et dans l'API — libellé clair : « récupérable par le support » vs « non récupérable par quiconque côté serveur ».
La loi d'airain
Tu ne peux pas avoir à la fois « moi seul peux jamais déchiffrer » et « on peut restaurer mes données quand j'ai perdu mon accès ». La récupérabilité impose qu'un autre détienne — ou puisse reconstituer — du matériel de clé. Le mode managé choisit la récupérabilité ; le mode ZK choisit l'isolation totale. Les deux sont légitimes ; l'un doit être le défaut.
Décision prise — défaut produitManagé = défaut. Standard commercial (Veeam, Datto, Acronis). Récupération indolore pour le client final. Le revendeur est le tiers de confiance ; l'éditeur reste aveugle (pas de droit ACL sur les KEK des revendeurs). ZK = option à la demande : disponible pour les clients qui l'exigent, avec les garde-fous ci-dessus.
En clair — trois serrures, trois chantiers
Changer une clé n'a pas le même coût selon l'étage de la pyramide. En haut, la KEK : changer le code du coffre-fort où est pendue la clé maîtresse — cinq minutes, aucune serrure de l'immeuble n'est touchée. Au milieu, la CMK : refaire les serrures d'un étage — borné, faisable. En bas, la CK : changer la langue dans laquelle toutes les étiquettes de l'entrepôt sont écrites — chaque brique change de nom, tout est à réécrire. Le coût de rotation est inversement proportionnel à la hauteur dans la pyramide.
KEK — rotation de routine, instantanée. La CMK est emballée par les KEK — c'est tout l'intérêt de l'enveloppe : changer une passphrase ou révoquer la KEK d'un revendeur = déballer/remballer quelques octets. Aucune donnée ne bouge. À encourager, sans friction.
CMK — rotation bornée. Elle chiffre les annuaires et racines de ce client : la tourner = re-chiffrer ces métadonnées (petites). Opération d'heures au pire, déclenchée sur suspicion de compromission d'une machine. Les chunks ne bougent pas d'un octet.
CK — pas une rotation, une migration. La CK détermine les clés de chunks, donc les chiffrés, donc les adresses : la tourner = tout re-chiffrer, tout ré-uploader, dédup à zéro. Structurellement identique à changer les paramètres du chunker.
Aucune rotation imposée — sur événement, jamais sur calendrier
La rotation « d'hygiène » tous les X mois vient du monde des clés qui voyagent (certificats TLS, tokens d'API — exposés en permanence, donc renouvelés). Nos clés ne voyagent jamais : la CK et la CMK ne quittent pas les clients. Les tourner par calendrier n'apporte aucune sécurité et coûte réel — le re-chiffrement qui tourne mal est un risque en soi. Si une conformité (type PCI-DSS) exige une rotation périodique, on la satisfait en tournant le haut de la pyramide — la KEK, annuellement, comme AWS KMS : coût zéro, case cochée. On ne tourne jamais le bas pour faire plaisir à un auditeur.
Événement
Ce qui tourne
Coût
Fréquence réelle
Changement de passphrase, départ d’un employé du revendeur
KEK (le code du coffre)
~zéro, instantané
Aussi souvent qu’on veut
Machine suspectée compromise
CMK (le trousseau)
Borné — re-chiffrer les métadonnées du client
Rare — réponse à incident
CK prouvée compromise
CK, par attrition (époques)
Élevé mais étalé
Exceptionnel — jamais en routine
CK compromise — gravité relative, réponse par attrition
D'abord relativiser : la CK volée ne déchiffre rien en masse. Elle permet l'oracle de confirmation (deviner un fichier candidat, vérifier sa présence) et de dériver la clé d'un chunk dont on possède déjà le clair — pour lire les données, il faut la CMK (le chemin racine → annuaire → manifeste). La CK est un secret de dédup, pas la clé du royaume. D'où la politique : pas de rotation planifiée (on ne paie pas une migration par hygiène — on protège la CK, provisionnée à l'enrôlement, jamais transmise ailleurs), et en cas de compromission avérée, rotation par attrition : une époque CK₂ pour les nouvelles données, les anciennes restent sous CK₁ et s'évaporent par la rétention. Perte temporaire de dédup entre époques, zéro re-upload massif — la mécanique des profils épinglés, réutilisée telle quelle.
Dernier maillon : la montée en force du KDF (voir les paramètres Argon2id) se fait gratuitement à chaque rotation de KEK — changer de passphrase re-dérive, et re-dériver est l’occasion de re-calibrer vers le haut. Les deux mécanismes se referment l’un sur l’autre.