Sauvegarde et restauration sécurisée des clés HSM

Un HSM (Hardware Security Module) protège une clé tant que le module fonctionne, que ses domaines de sécurité existent encore et que son stockage persistant reste lisible. Une panne matérielle, une corruption de partition ou la perte d’un domaine administratif impose de restaurer les clés sans jamais accepter qu’elles circulent en clair.

→ Lire l’explication complète de la marmotte

Key backup et wrapped export : le compromis à accepter

Le compromis central est brutal : sauvegarder une clé améliore la disponibilité, mais crée une copie supplémentaire et donc une nouvelle cible. Une clé non exportable sans mécanisme de reprise peut devenir irrécupérable après la destruction du HSM. Une clé exportable sans frontière cryptographique devient récupérable par un administrateur trop curieux, un poste compromis ou un script d’exploitation qui a soudainement découvert une vocation archéologique.

La recommandation est de préférer le backup natif du constructeur pour les clés de racine et les clés de signature à fort impact, lorsque la restauration vers un HSM de remplacement est supportée et contrôlée par plusieurs détenteurs. Le wrapped export convient aux clés applicatives devant survivre à un remplacement de matériel, à une migration de fournisseur ou à une architecture multi-sites, à condition que la clé de wrapping soit séparée des clés sauvegardées.

Le backup natif produit généralement un artefact propriétaire lié à une famille de modules, à un domaine de sécurité, à des cartes d’opérateur ou à une clé de sauvegarde matérielle. Il protège bien contre l’export arbitraire, mais il enferme la reprise dans la compatibilité constructeur. Un plan de reprise qui exige un modèle retiré du catalogue n’est pas un plan : c’est une collection de souvenirs industriels.

Le wrapped export encapsule une clé sous une KEK (Key Encryption Key), une clé dédiée au chiffrement d’autres clés. La clé encapsulée est souvent une DEK (Data Encryption Key), une clé servant directement à chiffrer ou déchiffrer des données. Cette séparation est obligatoire : utiliser la même clé pour protéger les données et leur sauvegarde détruit la frontière de confiance. Si la clé de données est compromise, la sauvegarde l’est aussi. Si la KEK est compromise, toutes les sauvegardes qu’elle protège deviennent suspectes.

Une clé marquée non extractible peut néanmoins être wrappée, selon les politiques du HSM et les attributs de l’objet. Ce n’est pas une contradiction. Non extractible signifie qu’aucune exportation en clair n’est autorisée ; le wrapped export produit un blob chiffré, inutilisable sans la KEK et sans les droits nécessaires à l’opération d’unwrap.

Pour le mécanisme de wrap et unwrap lui-même, voir wrap et unwrap. La présente page traite la sauvegarde de reprise : inventaire, séparation, conservation, restauration et preuve que la reprise fonctionne réellement.

Préparer le périmètre de restauration HSM

Avant de sauvegarder quoi que ce soit, inventorier les objets cryptographiques et leurs dépendances. Une clé privée de certificat, une clé de chiffrement de base de données et une KEK de coffre applicatif n’ont ni le même impact, ni le même délai de reprise, ni le même droit à l’export.

Pour chaque clé, consigner au minimum :

l’identifiant stable, le label et le type cryptographique ;
l’usage autorisé : signature, chiffrement, déchiffrement, dérivation ou wrapping ;
les attributs d’export : extractible, wrappable, modifiable, sensible ;
le ou les certificats publics associés ;
la KEK de protection et son identifiant de version ;
le HSM source, le domaine de sécurité et le profil de partition ;
le délai maximal de restauration et la dépendance applicative ;
la procédure de révocation si une sauvegarde est perdue ou exposée.

Le stockage de sauvegarde ne doit jamais contenir seul tout ce qui permet une restauration. Séparer au minimum trois choses : le blob chiffré, la KEK ou les éléments nécessaires à son activation, et les secrets d’authentification des opérateurs. Les réunir dans un même coffre de mots de passe est pratique, donc dangereux. Les coffres universels ont toujours une slide très convaincante avant le premier incident.

La KEK de sauvegarde doit être créée dans un HSM distinct ou dans un domaine cryptographique séparé du domaine productif. Une panne logique, telle qu’une suppression de partition ou une corruption de politique, ne doit pas détruire simultanément la clé sauvegardée et le moyen de la restaurer. Pour une architecture à haute disponibilité, la réplication native entre modules peut réduire le besoin de restauration, mais elle ne remplace pas une sauvegarde hors domaine. Voir l’architecture HSM haute disponibilité.

Définir aussi le RPO (Recovery Point Objective), soit la perte de données acceptable, et le RTO (Recovery Time Objective), soit le délai acceptable avant reprise. Une clé créée après la dernière sauvegarde est perdue si le HSM tombe avant la sauvegarde suivante. Pour une clé de signature, cette perte peut imposer l’émission d’un nouveau certificat et la révocation de l’ancien. Pour une clé de chiffrement de données, elle peut rendre un lot entier définitivement illisible.

Enfin, tester la compatibilité de restauration avant d’adopter un format. Les blobs AES-KWP (Advanced Encryption Standard Key Wrap with Padding), définis par RFC 5649, sont interopérables en théorie ; les attributs d’objet, les mécanismes autorisés et les politiques de fournisseur le sont beaucoup moins. Le mot « standard » ne répare pas un attribut CKA_ALLOWED_MECHANISMS absent après import.

Wrapped export PKCS#11 : exemple contrôlé

PKCS#11 (Public-Key Cryptography Standard numéro 11) expose les objets et opérations d’un HSM via une interface standardisée. L’exemple suivant utilise OpenSC et pkcs11-tool pour wrapper une clé AES sous une KEK AES. Il suppose que le jeton, les objets et les droits sont déjà créés. Les identifiants sont binaires et doivent être uniques dans le jeton.

# Vérifier que la KEK n'autorise que le wrapping et l'unwrapping.
# La clé de sauvegarde, identifiée par 01, ne doit pas servir à chiffrer des données.
pkcs11-tool --module /usr/lib/pkcs11/vendor.so \
  --login --pin "$HSM_USER_PIN" \
  --list-objects --type secrkey

# Exporter la DEK identifiée par 10 sous la KEK identifiée par 01.
# Le fichier obtenu est chiffré, mais il reste sensible : conserver son intégrité.
pkcs11-tool --module /usr/lib/pkcs11/vendor.so \
  --login --pin "$HSM_BACKUP_PIN" \
  --wrap --id 10 --application-id 01 \
  --mechanism AES-KEY-WRAP-PAD \
  --output-file dek-10-v3.wrapped

# Calculer une empreinte pour détecter une altération du blob stocké.
sha256sum dek-10-v3.wrapped > dek-10-v3.wrapped.sha256

Les options exactes varient selon le fournisseur et la version de pkcs11-tool. Le mécanisme doit être vérifié par C_GetMechanismList ou l’outil du constructeur avant automatisation. AES-KWP accepte des clés dont la longueur n’est pas un multiple de huit octets, contrairement à AES-KW (Advanced Encryption Standard Key Wrap), mais cette commodité ne dispense pas de gérer les attributs lors de l’unwrap.

Le fichier de checksum ne fournit pas d’authenticité si un attaquant peut modifier à la fois le blob et son empreinte. Stocker l’empreinte dans un dépôt séparé, signé ou immuable. Une signature de manifeste par une clé dédiée est préférable à une somme de contrôle déposée à côté du fichier, ce duo ayant la résistance d’un cadenas collé sur une porte ouverte.

La restauration doit recréer les attributs de sécurité attendus : CKA_SENSITIVE=true, CKA_EXTRACTABLE=false, usages limités et label versionné. Ne jamais accepter les attributs par défaut du fournisseur. Une clé restaurée avec l’autorisation de wrapping alors qu’elle ne l’avait pas avant restauration élargit la surface d’attaque au pire moment, celui où l’équipe croit avoir terminé.

Surface d’attaque du backup de clés

Le blob wrapped est confidentiel tant que la KEK résiste, mais il reste une cible de substitution, de rejeu et de destruction. Un attaquant peut remplacer un blob par une ancienne version, faire restaurer une clé obsolète ou supprimer une sauvegarde pour provoquer une perte définitive. Le chiffrement ne garantit ni fraîcheur, ni disponibilité, ni intention administrative. Il garantit seulement, selon le mécanisme employé, la confidentialité et l’intégrité cryptographique du paquet.

Versionner chaque sauvegarde avec un identifiant de clé, une version de KEK, une date, un état de cycle de vie et un hash signé. La restauration doit refuser un manifeste incohérent : mauvaise KEK, clé révoquée, version antérieure à un seuil de sécurité ou certificat associé expiré. Le seuil doit être stocké hors du dépôt de sauvegarde, sinon le rejeu restaure aussi la règle qui l’interdit. La sécurité adore les paradoxes administratifs, surtout quand ils sont sérialisés en JSON.

L’accès à l’opération d’unwrap doit être séparé de l’accès aux fichiers. Un compte de stockage ne doit pas disposer du droit HSM d’unwrapping ; un opérateur HSM ne doit pas lire seul le dépôt de blobs. Appliquer un contrôle partagé, avec authentification distincte et journalisation inviolable des opérations. Les journaux doivent inclure l’identité, le rôle, l’objet source, la KEK, le mécanisme et le résultat, sans jamais enregistrer de PIN (Personal Identification Number), de clé ou de blob complet.

Les attaques connues contre le wrapping incluent les attaques par oracle d’unwrap, les confusions de type d’objet et les abus d’attributs. Un service qui accepte un blob fourni par un appelant puis retourne une erreur différenciée peut devenir un oracle. Limiter l’unwrap à des blobs issus du dépôt approuvé, vérifier le manifeste avant appel HSM et ne jamais exposer l’opération comme une API applicative générique. Le HSM n’est pas une borne automatique à convertir les secrets des autres.

Exploitation, rotation et reprise après panne

Sauvegarder à chaque création de clé exportable sous wrapping, puis après toute modification d’attribut ou de certificat associé. La sauvegarde doit être transactionnelle : créer la clé, vérifier ses attributs, wrapper, vérifier le blob, enregistrer le manifeste, puis seulement déclarer la clé utilisable. Dans l’ordre inverse, une panne entre création et backup produit une clé active sans reprise possible.

La rotation de KEK impose de rewrapper toutes les sauvegardes sous la nouvelle KEK, puis de vérifier une restauration de contrôle avant de détruire l’ancienne. Conserver l’ancienne KEK jusqu’à la validation complète, mais ne pas la laisser active pour de nouveaux exports. La rotation des clés traite le cycle de vie ; ici, le point non négociable est que la destruction d’une KEK rend irrécupérables tous les blobs qui en dépendent.

Tester la restauration au moins à chaque changement de version HSM, de micrologiciel, de bibliothèque cliente, de mécanisme de wrapping ou de politique d’accès. Restaurer dans une partition isolée, comparer l’identifiant public ou une opération de test connue, puis détruire la clé de test selon la procédure. Ne jamais tester une reprise en restaurant par-dessus la clé de production : ce serait vérifier un parachute en sautant avec.

Une sauvegarde n’est pas un dispositif de continuité complet. Elle ne restaure pas automatiquement les certificats, les listes de révocation, les droits applicatifs, les politiques réseau, les journaux ni les données chiffrées avec une clé perdue avant sauvegarde. Ces éléments doivent provenir des mécanismes de sauvegarde et de supervision de leur propre couche. La séparation entre KEK et DEK est détaillée dans KEK versus DEK.

🐝 Ce qui arrive si on s’en passe

Sans sauvegarde de reprise, la destruction d’une clé non extractible devient une action à la portée d’un attaquant sans aucun secret : sur de nombreux modules, l’épuisement du compteur d’échecs d’authentification de l’officier de sécurité, ou une détection d’intrusion physique, déclenche l’effacement du jeton. Un simple déni de service suffit alors à rendre définitivement illisibles les données chiffrées. L’absence de procédure pousse aussi à des contournements : clés passées en extractibles pour en garder une copie en clair, qui disparaît ensuite des journaux du HSM, ou exports improvisés sous wrapping RSA PKCS#1 v1.5 dont l’unwrap répond par des erreurs distinctes. Ce second cas rejoint la brèche « la question qui rend le module bavard ».

🦫 Explication de la marmotte 🍫

Une clé de chiffrement est une information secrète qui permet de lire des données ou de produire une signature. Un module matériel de sécurité garde cette information dans un appareil conçu pour empêcher sa copie en clair. Si l’appareil tombe en panne, la clé peut être perdue avec lui. La sauvegarde consiste donc à produire une copie chiffrée de la clé, que personne ne peut lire directement.

Cette copie est chiffrée avec une autre clé, réservée à cette tâche. Les deux clés ne doivent pas être conservées ensemble. La copie chiffrée est déposée dans un stockage protégé ; la clé qui permet de la récupérer reste dans un autre appareil ou sous le contrôle de plusieurs personnes. Les comptes qui lisent le fichier de sauvegarde ne doivent pas pouvoir restaurer la clé, et ceux qui restaurent la clé ne doivent pas pouvoir lire seuls le fichier.

Lors d’une panne, on vérifie d’abord que le fichier de sauvegarde correspond bien à la bonne clé et qu’il n’a pas été remplacé. Le nouvel appareil déchiffre ensuite la copie avec la clé de protection et recrée la clé protégée. Ses droits sont vérifiés avant de remettre le service en route.

Si la clé de protection est perdue, la sauvegarde devient inutilisable. Si elle est volée, toutes les copies qu’elle protège doivent être considérées comme exposées. C’est pourquoi la restauration doit être testée régulièrement, sur un environnement séparé, avant que la panne ne transforme une hypothèse en incident.

Pages voisines

La citent

Sauvegarde et restauration sécurisée des clés HSM

Elle cite

Sauvegarde et restauration sécurisée des clés HSM

Sauvegarde et restauration sécurisée des clés HSM

Key backup et wrapped export : le compromis à accepter

Préparer le périmètre de restauration HSM

Wrapped export PKCS#11 : exemple contrôlé

Surface d’attaque du backup de clés

Exploitation, rotation et reprise après panne

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines