Migrer un fournisseur HSM sans interruption

Migrer un fournisseur HSM sans interruption

Changer de fournisseur HSM (Hardware Security Module) n’est pas une migration d’appliance : c’est une migration d’identités cryptographiques, de politiques d’usage et de dépendances applicatives. La recommandation est nette : faire coexister les deux domaines cryptographiques, créer les nouvelles clés sur la cible et migrer les références applicatives progressivement ; ne jamais compter sur une restauration de sauvegarde propriétaire comme stratégie de portabilité.

Explication de la marmotte

Changer le coffre qui protège les clés d’un bâtiment sans fermer le bâtiment ressemble à remplacer les serrures d’un immeuble encore occupé. Les nouvelles serrures doivent fonctionner avant que les anciennes disparaissent, et chaque porte doit être vérifiée. L’objectif est de préserver l’accès légitime sans offrir une entrée gratuite au premier chaos administratif venu.

→ Lire l’explication complète de la marmotte

Le compromis de la migration HSM : portabilité contre continuité

Un HSM protège des clés privées en empêchant leur exportation en clair. C’est précisément son travail. Une clé de signature créée sous une politique non exportable ne doit donc généralement pas être extraite pour être importée dans un autre HSM. Si elle le pouvait par défaut, la frontière de sécurité serait surtout décorative, avec un logo rassurant sur la façade.

La continuité de service s’obtient en faisant tourner simultanément l’ancien et le nouveau fournisseur. Les applications doivent pouvoir choisir un domaine cryptographique selon l’identité de la clé, la version d’un objet ou un indicateur de configuration. Cette coexistence coûte : double supervision, double gestion des accès, double validation de conformité et davantage de chemins de panne. Elle évite en revanche le scénario toxique où une fenêtre de bascule transforme une incompatibilité PKCS#11 (Public-Key Cryptography Standard 11) en indisponibilité nationale.

La migration directe d’une clé n’est acceptable que sous quatre conditions cumulatives :

1. la clé est légalement et techniquement exportable sous forme encapsulée ;
2. les deux HSM supportent le même mécanisme d’encapsulation et les mêmes attributs ;
3. une clé d’encapsulation KEK (Key Encryption Key) de transit est créée et contrôlée dans les deux domaines selon une procédure approuvée ;
4. l’import est vérifié par une opération cryptographique, puis l’objet source et les traces de transit sont détruits conformément à la politique de conservation.

Dans les autres cas, générer une nouvelle paire de clés est la bonne décision. Pour une autorité de certification, cela implique un nouveau certificat et, souvent, une chaîne de confiance à gérer pendant la période de chevauchement. Pour du chiffrement applicatif, cela implique de réenvelopper les DEK (Data Encryption Key), pas de rechiffrer aveuglément toutes les données métier.

La distinction entre clés de données et clés de protection est détaillée dans KEK et DEK. Une architecture d’envelope encryption réduit radicalement le périmètre de migration : seules les petites clés de données encapsulées changent de protection, tandis que les volumes chiffrés restent intacts.

Préparer l’inventaire cryptographique et le double routage

Avant toute création de clé sur la cible, établir un inventaire consommable par une machine et auditable par un humain. Un tableur sans identifiant stable finit toujours par devenir une fouille archéologique avec filtres automatiques. Chaque objet doit disposer au minimum des champs suivants :

• identifiant logique stable, indépendant du libellé fournisseur ;
• type d’objet : clé RSA (Rivest, Shamir, Adleman), clé EC (Elliptic Curve), certificat, clé symétrique ou secret de dérivation ;
• algorithme, taille, courbe et mécanismes autorisés ;
• propriétaire applicatif et environnement ;
• statut d’exportabilité, de sauvegarde et de rotation ;
• dépendances externes : certificat, enregistrement DNS (Domain Name System), client TLS (Transport Layer Security), fournisseur d’identité ;
• objectif de reprise RPO (Recovery Point Objective) et délai de reprise RTO (Recovery Time Objective).

Il faut ensuite séparer l’identité logique de clé de son emplacement physique. Une application ne doit pas référencer slot 3, objet 17, label signing-prod. Elle doit demander payment-signing/v4, puis un service de résolution associe cette version au module actif. Le numéro de slot est une propriété de pilote, pas une primitive de sécurité. Le graver dans le code revient à écrire une dépendance matérielle dans du béton frais.

Le double routage doit être explicite. Pour les signatures, le service émetteur sélectionne la clé active et les vérificateurs acceptent les certificats ancien et nouveau pendant le chevauchement. Pour le chiffrement, chaque contenu conserve l’identifiant de la clé qui l’a protégé : la lecture choisit l’ancien ou le nouveau HSM, l’écriture cible uniquement le nouveau. Cette règle de double lecture et écriture unique rend le retour arrière possible sans inventer de magie rétroactive.

Les sessions PKCS#11 ont aussi leur mot à dire. Certaines bibliothèques mettent en cache les sessions, les handles d’objet ou les mécanismes disponibles au démarrage. Un changement de configuration sans redémarrage contrôlé peut donc continuer à utiliser l’ancien module. La compatibilité d’interface ne garantit pas la compatibilité de comportement : codes d’erreur, gestion de concurrence, recherche d’objets par label et sémantique de reconnexion varient selon les implémentations. La page PKCS#11 expliqué couvre les primitives concernées.

Créer, valider et basculer les clés du nouveau HSM

Créer les nouveaux objets dans le HSM cible avec des attributs restrictifs dès l’origine. Une clé privée de signature doit porter CKA_SIGN=true, CKA_DECRYPT=false, CKA_EXTRACTABLE=false et un identifiant binaire unique. Une clé de chiffrement ne doit pas devenir clé de signature par commodité. Les clés polyvalentes sont le couteau suisse de la crypto : très pratiques jusqu’au moment où une lame apparaît là où personne ne l’attendait.

Les mécanismes doivent être figés par politique. Pour RSA, préférer RSA-PSS avec SHA-256 ou SHA-384 lorsque le protocole le supporte, et interdire PKCS#1 v1.5 pour les nouveaux usages de signature. Pour les courbes elliptiques, vérifier l’interopérabilité complète entre la courbe, le format de signature et les bibliothèques clientes. Pour AES (Advanced Encryption Standard), contrôler séparément les usages GCM (Galois/Counter Mode), l’unicité des vecteurs d’initialisation et les longueurs d’étiquette.

La validation porte sur les opérations réelles, pas seulement sur la présence d’objets dans une console. Exécuter au minimum :

• signature et vérification depuis chaque runtime applicatif ;
• chiffrement, déchiffrement et réenveloppement de clés ;
• ouverture de sessions concurrentes jusqu’à la limite attendue ;
• bascule d’un nœud HSM haute disponibilité ;
• redémarrage du client PKCS#11 pendant une opération non destructive ;
• restauration contrôlée d’un objet de test depuis le mécanisme de sauvegarde cible.

La haute disponibilité entre deux HSM d’un même fournisseur ne remplace pas la coexistence entre fournisseurs. La première protège d’une panne matérielle ou de site selon l’architecture. La seconde protège la migration. Les confondre est un raccourci de slide qui s’arrête au premier changement de firmware. Les contraintes de réplication et de quorum sont détaillées dans l’architecture HSM haute disponibilité.

Basculer par classe de service : d’abord les environnements de test, puis les charges sans état, les usages de chiffrement à double lecture, enfin les clés de signature exposées à des tiers. Une clé de signature de certificat ne se traite pas comme une clé de chiffrement interne : le nouveau certificat doit être publié, distribué et accepté avant activation. La révocation d’un certificat ne retire pas les certificats déjà mis en cache ni les sessions TLS déjà établies.

Exemple reproductible : inventorier les objets PKCS#11 avant bascule

L’exemple suivant utilise pkcs11-tool de OpenSC avec un module PKCS#11 accessible localement. Il produit un inventaire minimal avant toute migration. Exécuter la commande avec un compte d’exploitation autorisé, jamais avec le code PIN (Personal Identification Number) collé dans l’historique shell.

# Définir le chemin vers la bibliothèque PKCS#11 du fournisseur source.
export PKCS11_MODULE=/opt/vendor-source/lib/libpkcs11.so

# Lister les slots et relever le token réellement utilisé.
pkcs11-tool --module "$PKCS11_MODULE" --list-slots

# Ouvrir une session interactive : le PIN est demandé sur l'entrée standard.
# Les attributs permettent de vérifier type, label, identifiant et permissions.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --login \
  --list-objects \
  --verbose \
  | tee inventaire-hsm-source.txt

# Exporter uniquement une clé publique de test, jamais une clé privée.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --login \
  --read-object \
  --type pubkey \
  --id 01 \
  --output-file cle-publique-test.der

# Vérifier que le fichier DER contient bien une clé publique lisible.
openssl pkey -pubin -inform DER -in cle-publique-test.der -text -noout

L’inventaire doit être rapproché du registre de clés, puis signé ou stocké dans un dépôt immuable. Un label n’est pas un identifiant fiable : il peut être dupliqué, tronqué ou modifié. L’attribut CKA_ID, associé à l’identifiant logique applicatif, constitue la référence opérationnelle.

Surface d’attaque, reprise et retrait de l’ancien fournisseur

La coexistence augmente la surface d’attaque. Deux HSM signifient deux plans d’administration, deux ensembles de comptes, deux chaînes de mises à jour et parfois deux réseaux de gestion. Isoler les interfaces d’administration, imposer une authentification multifacteur et journaliser les opérations d’administration dans un système externe au fournisseur sont des exigences minimales.

Le risque le plus courant n’est pas une attaque contre l’algorithme, c’est une erreur d’autorisation. Un compte de migration capable de créer, encapsuler, importer et détruire tout objet ne doit exister que pendant une fenêtre définie, avec séparation des rôles et approbation à plusieurs personnes. Réduire ce compte à un rôle temporaire, puis prouver sa suppression. Les privilèges temporaires ont une capacité remarquable à devenir du mobilier.

Le matériel ne garantit pas l’intégrité du code appelant. Un processus compromis peut demander au HSM de signer tant que ses identifiants et ses autorisations restent valides. Le matériel ne garantit pas non plus la disponibilité réseau, l’exactitude du routage de clés, la révocation immédiate des certificats ou la récupération d’une clé détruite sans sauvegarde. Ces propriétés doivent venir de l’IAM (Identity and Access Management), de la segmentation réseau, des politiques applicatives, de la supervision et du plan de reprise.

Superviser au moins le taux d’erreurs PKCS#11, la latence par mécanisme, le nombre de sessions, les refus d’autorisation, les tentatives d’administration, l’état de réplication et les dates d’expiration des certificats. Définir des alertes sur la divergence entre nombre d’objets attendus et observés. Une clé créée mais jamais référencée est une dette ; une référence active vers une clé absente est une panne avec un costume de configuration.

Le retrait final suit une séquence stricte : arrêter les écritures vers l’ancien domaine, mesurer l’absence de lectures pendant une période couvrant les traitements différés, révoquer les comptes clients, exporter les journaux et preuves d’audit, tester la restauration documentaire, puis détruire les objets selon une procédure approuvée. La rotation des clés donne le cadre de conservation des versions antérieures. Débrancher l’ancien HSM avant d’avoir démontré l’absence de dépendance est une méthode de découverte, pas une méthode de migration.

🐝 Ce qui arrive si on s’en passe

Sans coexistence ni double routage, la bascule pousse à rendre les clés transportables : une clé générée ou modifiée avec CKA_EXTRACTABLE=true porte ensuite CKA_NEVER_EXTRACTABLE=false de façon définitive, et plus aucune attestation ne peut prouver qu’elle n’a jamais quitté un HSM. Toute signature émise avec cette clé perd donc sa preuve d’origine matérielle, quelles que soient les précautions prises après coup. Sans identifiant de clé conservé avec chaque contenu, un retour arrière rend illisibles les données écrites sous la nouvelle clé pendant la fenêtre de bascule. De plus, des slots ou handles figés dans le code continuent de viser l’ancien module : la panne n’apparaît qu’au retrait, alors que l’ancien fournisseur n’est plus sous contrat de support.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité est un appareil qui garde des clés secrètes et effectue des opérations de chiffrement ou de signature sans laisser sortir ces clés. Lorsqu’il faut changer de fournisseur, certaines clés ne peuvent pas être déplacées : leur protection interdit leur copie. Il faut alors créer de nouvelles clés dans le nouvel appareil.

La migration commence par un inventaire : chaque clé, son rôle, les logiciels qui l’utilisent et les certificats associés doivent être connus. Ensuite, l’ancien et le nouveau matériel restent actifs en même temps. Les logiciels reçoivent une règle pour trouver la bonne clé selon la version demandée.

Pour protéger des données, les nouvelles écritures utilisent la nouvelle clé. Les anciennes données restent lisibles avec l’ancienne clé jusqu’à leur mise à jour. Pour les signatures, le nouveau certificat est distribué avant que la nouvelle clé soit utilisée, afin que les destinataires puissent vérifier les signatures.

Chaque opération doit être testée : chiffrer, déchiffrer, signer, vérifier, redémarrer un logiciel et perdre un appareil. Si le nouveau matériel échoue, les logiciels doivent pouvoir revenir temporairement vers l’ancien, tant que les anciennes clés restent disponibles.

Enfin, l’ancien matériel n’est retiré qu’après vérification qu’aucun programme ne le sollicite encore. Les accès sont supprimés, les journaux sont conservés et les clés sont détruites selon une procédure contrôlée.

À lire aussi

• Sauvegarde et restauration sécurisée des clés HSMMettre en place le key backup et le wrapped export des clés d'un HSM en cas de panne matérielle, sans transformer la sauvegarde en voie d'exfiltration.
• Dimensionner un cluster HSM à forte charge transactionnelleMéthode de capacité, tests de charge et exploitation d’un cluster HSM pour le paiement et la signature de masse.
• Attestation matérielle HSM des clés généréesVérifier par preuve cryptographique qu’une clé a été créée et reste protégée dans un HSM certifié.
• Vulnérabilités documentées des HSM certifiésLes attaques documentées contre les modules cryptographiques matériels montrent pourquoi certification, firmware, API et exploitation doivent être traités comme une seule surface de risque.

Pages voisines

La citent

• Sauvegarde et restauration sécurisée des clés HSM
• Protéger des données avec un HSM (hardware security module)
• Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

Migrer un fournisseur HSM sans interruption

Elle cite

• ⇄Lien dans les deux sens :PKCS#11 explique
• Architecture module cryptographique materiel haute disponibilite
• Envelope encryption
• KEK vs DEK
• Rotation des cles
• Cycle de vie d'une autorité de certification intermédiaire
• RSA : trappe, padding et usages restreints
• Accès juste-à-temps et privilèges temporaires

⇄ : les deux pages se citent l’une l’autre.