Dimensionner un HSM pour la migration post-quantique
Dimensionner un HSM pour la migration post-quantique
Section intitulée « Dimensionner un HSM pour la migration post-quantique »La migration post-quantique ne consiste pas à cocher une nouvelle primitive dans un catalogue de mécanismes. Elle modifie les tailles d’objets, les buffers de session, le débit de signature, les certificats et parfois le modèle de stockage entier du HSM (Hardware Security Module). Le compromis central est net : gagner une résistance aux attaques quantiques impose de payer en mémoire, en bande passante et en capacité opérationnelle.
→ Lire l’explication complète de la marmotte
Tailles post-quantiques et capacité des HSM
Section intitulée « Tailles post-quantiques et capacité des HSM »Les familles normalisées par le NIST (National Institute of Standards and Technology) changent fortement le profil de stockage. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardisé dans FIPS 203, sert à établir un secret partagé. ML-DSA (Module-Lattice-Based Digital Signature Algorithm), défini dans FIPS 204, sert à signer. SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), défini dans FIPS 205, offre une alternative fondée sur les fonctions de hachage.
ML-KEM-768 emploie une clé publique de 1 184 octets, une clé privée de 2 400 octets et produit un texte chiffré de 1 088 octets. À comparer avec une clé publique X25519 de 32 octets. ML-DSA-65 emploie une clé publique de 1 952 octets, une clé privée de 4 032 octets et une signature de 3 309 octets. Une clé privée RSA (Rivest, Shamir, Adleman) 3072 bits tient approximativement dans quelques centaines d’octets de matériau mathématique. L’écart ne reste donc pas dans les slides : il entre dans les partitions cryptographiques.
Le piège consiste à ne compter que les clés privées persistantes. Un HSM conserve aussi des attributs d’objet, des copies chiffrées internes, des index, des journaux d’audit et des objets temporaires de session. Une implémentation peut réserver plusieurs buffers de la taille maximale d’une signature pour chaque session concurrente. Un module qui accepte mille sessions RSA n’acceptera pas mécaniquement mille sessions ML-DSA. La mémoire volatile devient souvent la première limite, avant la capacité non volatile.
Le dimensionnement doit séparer quatre postes :
- les clés persistantes et leurs métadonnées ;
- les objets temporaires créés lors de l’encapsulation ou de la signature ;
- les buffers de transport entre l’application et le HSM ;
- les sauvegardes chiffrées et les jetons de reprise.
La règle défendable est de réserver au moins le double de la capacité calculée pour les objets post-quantiques, hors mécanismes hybrides. Cette marge absorbe la coexistence des générations, les clés de rotation et les écarts d’implémentation entre firmware. Dimensionner à l’octet près revient à construire une salle serveur sans place pour un câble : économiquement brillant pendant exactement une semaine.
Les objets de chiffrement de données ne doivent pas devenir post-quantiques par réflexe. Une DEK (Data Encryption Key) AES (Advanced Encryption Standard) reste généralement une clé symétrique de 256 bits. La migration touche d’abord les clés asymétriques servant au transport, à la signature et à la certification. L’envelope encryption limite précisément l’explosion du nombre de clés protégées par le HSM.
Débit ML-DSA et latence des partitions matérielles
Section intitulée « Débit ML-DSA et latence des partitions matérielles »La taille n’est qu’une moitié du problème. Les opérations post-quantiques manipulent des polynômes, des échantillons aléatoires et des fonctions de hachage en volume. Elles ne se comportent pas comme RSA, dont le coût varie fortement selon l’opération, ni comme ECDSA (Elliptic Curve Digital Signature Algorithm), dont les objets restent petits.
Un HSM existant peut présenter trois cas très différents :
- le firmware exécute ML-KEM ou ML-DSA dans le processeur général du module ;
- une accélération matérielle spécialisée existe ;
- l’algorithme est absent et le logiciel l’exécute hors module.
Le troisième cas ne doit jamais être présenté comme une migration HSM. Si la clé privée ML-DSA est chargée en mémoire applicative pour signer, la frontière matérielle disparaît. Le produit garde éventuellement son logo de coffre-fort, mais la clé a déjà pris l’air.
Le débit réel doit être mesuré avec le nombre maximal de sessions prévu, les tailles de messages attendues et l’audit actif. Une signature ML-DSA sur un message court n’indique rien sur une autorité de certification qui signe des certificats hybrides, génère des listes de révocation et alimente plusieurs services TLS (Transport Layer Security). Les signatures plus grandes aggravent aussi la pression sur les files d’attente réseau et les limites de taille des appliances intermédiaires.
Un mécanisme hybride associe une primitive classique et une primitive post-quantique. Cette stratégie est recommandée durant la transition lorsque les piles clientes ne valident pas encore les signatures ou échanges post-quantiques seuls. Elle double toutefois les objets, les opérations et parfois les chaînes de certificats. Le choix dépend d’une question précise : faut-il conserver l’interopérabilité avec des clients non migrés ? Si oui, prévoir le coût hybride. Sinon, ne pas empiler deux algorithmes par superstition architecturale.
La haute disponibilité doit être recalculée. Deux HSM actifs ne fournissent pas une capacité utile égale au double du débit nominal si la réplication des objets, les sauvegardes ou la journalisation saturent le lien de synchronisation. L’architecture HSM haute disponibilité doit conserver une marge de débit après perte d’un nœud, avec les mécanismes post-quantiques activés.
Compatibilité PKCS #11 et inventaire des mécanismes
Section intitulée « Compatibilité PKCS #11 et inventaire des mécanismes »PKCS #11 (Public-Key Cryptography Standards numéro 11) expose les objets et opérations cryptographiques d’un HSM aux applications. La présence d’une bibliothèque PKCS #11 récente ne prouve pas la disponibilité de ML-KEM ou ML-DSA. La version de l’interface, le firmware du HSM, le microcode des accélérateurs et les politiques de partition doivent tous annoncer le mécanisme.
Un inventaire doit recenser, pour chaque partition :
- les mécanismes proposés et leurs paramètres autorisés ;
- les tailles minimales et maximales de clés ;
- le nombre maximal de sessions simultanées ;
- l’espace non volatile libre ;
- les limites de taille pour
C_Sign,C_Encrypt,C_WrapKeyetC_UnwrapKey; - la compatibilité des objets avec la réplication et la sauvegarde.
L’absence de mécanisme de wrapping (encapsulation chiffrée d’une clé) post-quantique oblige parfois à exporter une clé sous une protection classique vers un autre composant. Cette conception annule une partie du bénéfice recherché. Une clé non exportable ne devient pas exportable parce que le calendrier de migration est tendu. Les règles de wrap et unwrap de clés restent applicables, y compris lorsque les objets grossissent.
Les certificats constituent une limite distincte. Une signature ML-DSA augmente la taille du certificat et de la chaîne transmise. Les proxys, répartiteurs et bibliothèques TLS peuvent imposer des plafonds implicites sur les messages de négociation. Un HSM peut signer parfaitement un certificat que l’infrastructure refuse ensuite de transporter. Le matériel ne corrige pas les limites de protocole, ce serait lui demander de réparer la plomberie avec un marteau-fort.
Exemple de vérification de mécanismes PKCS #11
Section intitulée « Exemple de vérification de mécanismes PKCS #11 »Avant toute projection de capacité, vérifier ce que le module expose réellement. La commande suivante utilise pkcs11-tool, fourni par OpenSC, et interroge les modules déclarés par p11-kit. Elle ne crée ni clé ni objet, donc elle peut être exécutée sans modifier une partition.
# Afficher les modules PKCS #11 déclarés sur l'hôte.p11-kit list-modules
# Identifier le chemin de la bibliothèque du fournisseur dans la sortie précédente,# puis lister les mécanismes du module. Remplacer uniquement le chemin affiché.pkcs11-tool \ --module /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so \ --list-mechanisms | grep -Ei 'ML-KEM|ML-DSA|SLH-DSA|RSA|ECDSA'
# Vérifier les emplacements et les informations générales exposées par le module.pkcs11-tool \ --module /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so \ --list-slotsCette commande ne certifie pas que le mécanisme est activé sur la partition ciblée. Certains fournisseurs annoncent un mécanisme globalement puis le restreignent par rôle, licence, politique ou niveau de firmware. Créer une clé de test dans une partition de validation, signer, exporter uniquement la partie publique et supprimer l’objet constituent le test minimal. La documentation du fournisseur reste nécessaire pour les attributs exacts, mais croire une table marketing sans interrogation de module reste une activité sportive.
Rotation, sauvegarde et reprise des clés post-quantiques
Section intitulée « Rotation, sauvegarde et reprise des clés post-quantiques »La migration doit conserver une séparation stricte entre KEK (Key Encryption Key), clé utilisée pour protéger d’autres clés, et DEK. Une KEK post-quantique de grande taille peut réduire le nombre d’objets admissibles dans une partition, sans modifier la taille des DEK symétriques. La page KEK versus DEK décrit cette hiérarchie, qui devient encore plus nécessaire quand chaque objet asymétrique coûte davantage.
Une rotation ne garantit pas la disparition des anciennes clés. Les sauvegardes HSM, les partitions de secours, les journaux et les certificats restent susceptibles de contenir des références aux versions précédentes. Une procédure de destruction doit couvrir chaque copie chiffrée, sans supprimer prématurément une clé encore nécessaire au déchiffrement d’archives. La rotation des clés doit donc maintenir un inventaire de dépendances, des dates de fin d’usage et une preuve de restauration.
La supervision doit alerter sur l’espace d’objets, l’utilisation mémoire des sessions, la latence percentile 95 et 99, les échecs de mécanisme, les refus de politique et les délais de réplication. Un compteur de signatures réussies ne détecte pas une partition qui approche de sa limite d’objets. Or cette limite se manifeste souvent au moment de la rotation, lorsque l’ancienne et la nouvelle génération coexistent. La cryptographie aime les cérémonies, mais elle les organise volontiers un vendredi soir.
Ce mécanisme ne garantit ni la sécurité des applications appelantes, ni l’authentification correcte des opérateurs, ni la validité des certificats émis. Un HSM protège principalement le matériau de clé et l’exécution d’opérations autorisées. L’IAM (Identity and Access Management), les rôles de sécurité, la séparation des détenteurs de secrets, les journaux inviolables et le contrôle des politiques doivent venir d’ailleurs.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans dimensionnement préalable, la migration tend à être repoussée ou réalisée partiellement, et les clés de transport restent classiques (RSA, ECDH). Un échange de clés enregistré aujourd’hui sur le réseau reste alors déchiffrable plus tard par un adversaire disposant d’un calculateur quantique suffisant. C’est le principe de la collecte immédiate pour déchiffrement différé, qui concerne toute donnée dont la confidentialité doit durer au-delà de cette échéance. Côté signature, une autorité racine RSA ou ECDSA à longue durée de validité devient falsifiable au même horizon. Cela permet d’émettre des certificats ou des mises à jour logicielles acceptés par les clients qui lui font confiance. Aucun journal du HSM ne signale ce risque : la capture passive ne produit aucun appel au module, donc aucune trace exploitable par la supervision.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un module cryptographique matériel est un appareil conçu pour garder des clés secrètes et réaliser des calculs de chiffrement ou de signature sans laisser ces clés sortir. Les nouveaux algorithmes conçus pour résister à de futurs ordinateurs quantiques utilisent souvent des clés, des signatures ou des messages plus grands que les anciens algorithmes.
La migration commence par l’inventaire des opérations réellement réalisées : établir un secret avec un autre système, signer un certificat, protéger une autre clé ou vérifier une signature. Ensuite, il faut vérifier que l’appareil possède bien les nouveaux algorithmes dans sa version installée. S’il ne les possède pas, faire le calcul dans l’application expose la clé secrète à la mémoire de cette application.
Quand les nouveaux algorithmes sont disponibles, il faut mesurer l’espace occupé par chaque clé, les données temporaires créées pendant un calcul et le temps nécessaire quand plusieurs demandes arrivent en même temps. Pendant une transition, anciens et nouveaux algorithmes peuvent coexister. L’appareil doit alors stocker davantage de clés et parfois produire deux signatures.
Une panne peut venir d’un manque d’espace, d’une mémoire temporaire insuffisante, d’un programme qui refuse des messages plus grands ou d’une copie de secours incapable de restaurer les nouvelles clés. Il faut donc tester la sauvegarde, la restauration, la rotation des clés et le fonctionnement après perte d’un appareil.
À lire aussi
- 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.
- Migrer un fournisseur HSM sans interruptionMéthode de migration progressive d'un système cryptographique vers un nouveau fournisseur HSM sans interrompre les services.
- 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.
Pages voisines
La citent
Dimensionner un HSM pour la migration post-quantique
Elle cite