Comment détruire une clé pour effacer des données chiffrées

Le crypto-shredding consiste à rendre des données chiffrées irrécupérables en détruisant la ou les clés nécessaires à leur déchiffrement. Ce n’est pas un effacement de fichiers, ni une rotation de clés ratée avec un vocabulaire plus dramatique : c’est une opération cryptographique irréversible qui exige une architecture préparée avant le premier octet chiffré.

→ Lire l’explication complète de la marmotte

Crypto-shredding : détruire la bonne clé, au bon niveau

Le compromis central est brutal : le crypto-shredding offre un effacement rapide et indépendant du stockage, mais il échange cette rapidité contre une perte irréversible. Une clé détruite par erreur ne se restaure pas grâce à la motivation, à un ticket prioritaire ou à une slide de fournisseur.

La méthode ne fonctionne que si les données ont été chiffrées avec une hiérarchie de clés exploitable. Le modèle recommandé est l’envelope encryption : une DEK (Data Encryption Key) chiffre les données, puis une KEK (Key Encryption Key) chiffre, ou encapsule, cette DEK. La KEK reste dans un HSM (Hardware Security Module), matériel qui exécute les opérations cryptographiques sans exposer la clé privée ou secrète à l’application.

La séparation entre KEK et DEK décide du périmètre de destruction. Détruire une DEK efface cryptographiquement un objet, un tenant ou une période donnée. Détruire une KEK rend inexploitables toutes les DEK qu’elle encapsule. Cette seconde option est plus rapide, mais son rayon d’explosion est celui d’une démolition contrôlée menée avec les plans à l’envers.

La recommandation est nette : affecter une KEK distincte à chaque domaine de rétention destructible, puis stocker les DEK encapsulées avec les données. Une KEK globale pour toutes les données applicatives interdit une suppression sélective. Une DEK unique par enregistrement permet une granularité maximale, mais augmente le volume de métadonnées, les appels au HSM et la complexité de reprise. Le bon niveau dépend de l’unité réelle de suppression : dossier, client, archive, sauvegarde ou classe de données.

Le crypto-shredding n’est pas une alternative à la rotation. La rotation de clés maintient la sécurité d’un actif encore nécessaire ; la destruction met fin à son utilisabilité. Réutiliser une procédure de rotation pour supprimer une clé est une erreur classique : une ancienne version archivée, une clé de secours ou une règle de rollback peut alors restaurer exactement ce qui devait disparaître.

Prérequis HSM et PKCS#11 avant destruction

Un HSM doit exposer une suppression d’objet authentifiée et journalisable. Avec PKCS#11 (Public-Key Cryptography Standards #11), l’opération correspond à C_DestroyObject. La présence de cette fonction dans l’interface ne prouve rien sur la réalité opérationnelle : certains modules répliquent les objets entre nœuds, d’autres conservent des copies dans des domaines de sauvegarde, et certains opérateurs distinguent suppression logique et remise à zéro physique.

Avant d’autoriser le crypto-shredding, il faut vérifier les points suivants :

La clé cible est non extractible (CKA_EXTRACTABLE=false) et sensible (CKA_SENSITIVE=true). Une copie exportée avant destruction annule la promesse d’effacement.
Le HSM impose une authentification d’utilisateur de sécurité, idéalement avec séparation des rôles entre demandeur, approbateur et opérateur.
Les identifiants d’objets sont stables. Un label est un commentaire humain ; un identifiant PKCS#11 (CKA_ID) est le sélecteur de sécurité.
Le mécanisme de haute disponibilité propage la suppression à tous les membres et refuse les opérations tant que la convergence n’est pas confirmée. L’architecture HSM haute disponibilité doit être relue sous cet angle, pas seulement sous celui de la disponibilité.
Les journaux d’audit sont exportés hors du domaine administré par les opérateurs de clés. Un audit stocké uniquement sur l’équipement qui exécute la destruction est une preuve rangée dans la corbeille.
Les sauvegardes de clés sont identifiées, chiffrées et soumises à la même décision de destruction. Une sauvegarde de HSM est une copie de clés, pas une décoration réglementaire.

PKCS#11 version 2.40 suffit pour C_DestroyObject; un client compatible version 3.0 reste acceptable si le fournisseur le supporte explicitement. Le point bloquant n’est pas la version de l’API, mais le comportement documenté du module pour la suppression, la réplication, la sauvegarde et la restauration. Sans réponse précise du fournisseur sur ces quatre sujets, la destruction ne doit pas être qualifiée comme définitive.

Procédure de destruction PKCS#11 vérifiable

Une destruction exige une demande identifiée, un périmètre de données connu, une période de gel et une approbation séparée. Le gel bloque les nouveaux chiffrement et déchiffrement avec la clé cible. Sans ce gel, une application peut recréer des données chiffrées sous une clé déjà déclarée morte, ce qui produit des incidents d’intégrité assez surréalistes.

L’exemple suivant utilise pkcs11-tool, fourni par OpenSC, avec un objet de type clé secrète. Il doit être exécuté uniquement sur une clé de test ou dans une procédure approuvée : la commande finale est irréversible.

# Lister les clés secrètes et relever l'identifiant hexadécimal exact.
pkcs11-tool \
  --module /usr/lib/softhsm/libsofthsm2.so \
  --login \
  --list-objects \
  --type secrkey

# Vérifier dans le registre de clés que l'ID 6b65792d32303236
# correspond à la KEK prévue, à son périmètre et à sa version.
# Ne jamais sélectionner un objet sur son seul label.

# Détruire l'objet PKCS#11 ciblé après approbation hors bande.
pkcs11-tool \
  --module /usr/lib/softhsm/libsofthsm2.so \
  --login \
  --delete-object \
  --type secrkey \
  --id 6b65792d32303236

# Confirmer l'absence de l'objet dans le jeton après reconnexion.
pkcs11-tool \
  --module /usr/lib/softhsm/libsofthsm2.so \
  --login \
  --list-objects \
  --type secrkey

L’absence de l’objet dans une session ne suffit pas. Il faut contrôler la réplication HSM, tenter un déchiffrement sur un échantillon de données, vérifier qu’aucun service ne possède une DEK en mémoire ou dans un cache, puis tester une restauration depuis une sauvegarde représentative. Le test attendu est l’échec de déchiffrement, pas le succès d’une restauration. Cette nuance évite de transformer une procédure d’effacement en exercice de résurrection.

Le registre de destruction doit contenir l’identifiant immuable de la clé, son empreinte publique si elle existe, le périmètre de données, le motif, les approbations, l’heure, les identités des opérateurs et le résultat de convergence. Il ne doit jamais contenir la matière de clé, même sous prétexte d’audit. Cette précision semble absurde, jusqu’au jour où un export CSV devient le meilleur coffre-fort de l’organisation.

Surface d’attaque et échecs du crypto-shredding

La principale attaque vise les copies. Une DEK exportée dans un journal applicatif, un cache distribué, une image mémoire, une sauvegarde de base ou un environnement de test permet toujours de déchiffrer les données. Le HSM protège la KEK s’il est correctement configuré ; il ne protège pas une clé qu’une application a déjà sortie de son périmètre.

Une attaque par suppression malveillante est aussi une attaque de disponibilité. Un compte autorisé à détruire une KEK peut rendre un domaine entier définitivement indisponible. La contre-mesure n’est pas un droit d’administration plus large, cette vieille réponse à tout problème de droits : il faut un double contrôle, un délai de grâce court mais explicite, et une séparation entre création, approbation et exécution.

Les erreurs de ciblage sont fréquentes lorsque les applications utilisent des labels réutilisables comme master-key-prod. Une rotation crée alors plusieurs objets portant le même label. La destruction doit sélectionner une combinaison stable : identifiant, version, tenant, algorithme et période de validité. Les métadonnées de clé doivent être signées ou au moins protégées contre une modification non tracée, sinon un attaquant peut faire pointer une demande approuvée vers une autre clé.

La destruction ne garantit pas l’effacement des données en clair, des index non chiffrés, des journaux, des exports analytiques, des captures réseau antérieures au chiffrement ou des sauvegardes qui contiennent déjà le texte lisible. Elle ne détruit pas non plus les clés détenues par un tiers, les copies légales, ni les données déchiffrées avant l’opération. Le reste doit venir de politiques de rétention, de chiffrement applicatif, de contrôle des exports et d’effacement de stockage lorsque nécessaire.

Exploitation : sauvegarde, rotation et reprise impossible

Une clé destinée à être détruite ne doit pas avoir de chemin de reprise caché. C’est la condition qui rend l’opération crédible et qui dérange légitimement les équipes d’exploitation. Il faut donc séparer deux catégories : les clés actives, sauvegardées selon une procédure de reprise testée, et les clés arrivées en fin de rétention, détruites dans tous les domaines de sauvegarde.

La sauvegarde HSM doit être inventoriée par génération et par domaine de clés. Lorsqu’une KEK est détruite, chaque archive qui peut la restaurer doit être invalidée, détruite ou rendue inutilisable par destruction de sa propre clé de protection. Copier une sauvegarde chiffrée sur un stockage froid ne règle rien si la clé de restauration survit dans un coffre administré séparément.

La supervision doit détecter trois états distincts : demande de destruction, destruction propagée, échec de déchiffrement confirmé. Un simple événement C_DestroyObject réussi ne garantit que l’acceptation locale de l’appel. Une supervision sérieuse alerte aussi sur les usages tardifs de la clé, les tentatives de restauration, les erreurs de déchiffrement inattendues et les divergences entre nœuds HSM.

Le crypto-shredding convient aux données dont la période de conservation est définie, dont le chiffrement est applicatif ou par enveloppe, et dont les clés ne quittent jamais le périmètre maîtrisé. Pour un disque entier, une base de données chiffrée par une clé globale ou une sauvegarde historique non segmentée, la destruction sera trop large ou insuffisante. Dans ces cas, il faut revoir l’architecture de chiffrement avant de promettre un effacement définitif. La cryptographie ne corrige pas une taxonomie de données dessinée au feutre sur un coin de table.

🐝 Ce qui arrive si on s’en passe

Sans architecture de crypto-shredding préparée avant le premier octet chiffré, on ne dispose d’aucun moyen fiable de rendre des données irrécupérables en détruisant leur clé. La suppression doit alors se faire copie par copie, un processus lent, incertain et souvent impossible à garantir sur des sauvegardes, des réplicas et des archives dispersés. La conséquence est que des données censées être effacées survivent quelque part, hors de tout contrôle, et qu’une obligation d’effacement ne peut être démontrée. Si les clés ne sont pas cloisonnées par périmètre de données dès la conception, détruire une clé efface plus ou moins que prévu, ou n’efface rien d’exploitable. Le coffre reste alors ouvrable : les documents demeurent présents et lisibles pour qui retrouve une copie du matériel cryptographique, faute d’avoir pu détruire l’unique moyen de les déchiffrer.

🦫 Explication de la marmotte 🍫

Des données chiffrées ne peuvent être relues qu’avec une information secrète appelée clé. Le crypto-shredding consiste à détruire cette information secrète pour empêcher définitivement la lecture des données, même si les fichiers restent sur les disques ou dans des archives.

Pour que cela fonctionne, les données doivent avoir été chiffrées dès le départ avec une organisation prévue pour la suppression. Une petite clé chiffre les données d’un groupe précis. Cette petite clé est elle-même protégée par une autre clé, conservée dans un équipement spécialisé. Selon le besoin, il est possible de détruire la petite clé pour supprimer un groupe limité, ou la clé de protection pour rendre illisible un ensemble plus large.

Avant la destruction, il faut arrêter les logiciels qui utilisent la clé. Il faut aussi vérifier quelles données dépendent d’elle, quelles copies existent et si des sauvegardes peuvent remettre la clé en service. La destruction est ensuite autorisée par plusieurs personnes, enregistrée dans un journal, puis exécutée dans l’équipement qui conserve la clé.

Après l’opération, il faut vérifier que les copies de la clé ont disparu et qu’un essai de lecture échoue. Si une copie de la clé existe dans une sauvegarde, dans un logiciel ou dans une exportation, les données restent lisibles : la destruction a alors échoué pour ce périmètre.