RNG matériel ou PRNG dans un HSM

RNG matériel ou PRNG dans un HSM

Une clé privée, un nonce AES-GCM, un sel de dérivation ou un facteur de signature ne valent que ce que vaut leur imprévisibilité. Dans un HSM (Hardware Security Module), le générateur aléatoire n’est donc pas une commodité d’API : c’est une dépendance cryptographique dont une défaillance peut contaminer des années d’opérations valides en apparence.

Explication de la marmotte

Un générateur aléatoire cryptographique ressemble à un tirage de tickets dont personne ne peut deviner le prochain numéro, même après avoir observé les précédents. Il sert à empêcher qu’une clé, un code secret ou une preuve numérique puisse être reconstitué par calcul ou par chance organisée.

→ Lire l’explication complète de la marmotte

RNG matériel, entropie et générateur pseudo-aléatoire

Le compromis central est direct : tirer chaque octet depuis une source physique maximise l’indépendance vis-à-vis d’un état logiciel, mais paie en débit, latence et dépendance à un composant matériel. Utiliser un DRBG (Deterministic Random Bit Generator, générateur déterministe de bits aléatoires) est rapide et contrôlable, mais toute sa sécurité repose sur la qualité de sa graine et la protection de son état interne.

La recommandation est de ne pas opposer ces deux mécanismes. Un HSM sérieux utilise une source d’entropie matérielle pour alimenter et réamorcer périodiquement un DRBG interne. La source physique fournit l’imprévisibilité initiale ; le DRBG fournit le débit nécessaire aux appels applicatifs. Exiger un accès direct au bruit brut pour chaque génération de nonce est une mauvaise exigence d’architecture : elle réduit les performances sans améliorer la sécurité démontrable du résultat conditionné.

L’entropie mesure l’incertitude réelle d’une source. Le bruit thermique, les fluctuations électroniques ou certains phénomènes quantiques peuvent fournir cette incertitude, à condition que le composant mesure réellement un phénomène physique et pas le fantôme marketing d’un oscillateur mal surveillé. Une source matérielle biaisée, bloquée ou manipulée peut produire beaucoup d’octets différents sans apporter assez d’imprévisibilité.

Le conditionnement transforme les échantillons bruts en une graine exploitable, généralement avec une fonction de hachage ou un mécanisme cryptographique dédié. Le DRBG étend ensuite cette graine en sorties pseudorandomisées. NIST (National Institute of Standards and Technology) documente notamment Hash_DRBG, HMAC_DRBG et CTR_DRBG dans SP 800-90A. Le choix du mécanisme importe moins que trois propriétés : graine initiale suffisante, réamorçage correctement déclenché et état impossible à lire ou restaurer hors contrôle.

Un HSM ne transforme pas magiquement une API médiocre en source sûre. La présentation du module cryptographique matériel couvre la frontière de confiance ; ici, le point à retenir est plus étroit : une clé générée dans le module reste faible si les bits qui l’ont créée étaient prédictibles.

Décision d’architecture : générer dans le HSM, pas à côté

Les clés asymétriques, les clés symétriques maîtresses, les KEK (Key Encryption Key, clés de chiffrement de clés), les valeurs secrètes de signature et les nonces gérés par un mécanisme interne doivent être générés dans le HSM. Exporter des octets aléatoires vers l’application pour construire ensuite une clé revient à déplacer la racine du problème vers la mémoire applicative, les traces de débogage et les snapshots. Le HSM finit alors cantonné au rôle de presse-papier très onéreux.

La règle admet une nuance : tous les aléas ne nécessitent pas une génération dans le HSM. Un identifiant de corrélation, un échantillon de test ou une valeur de remplissage non secrète peut provenir du générateur du système d’exploitation, à condition qu’il soit un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator, générateur pseudo-aléatoire cryptographiquement sûr). En revanche, un IV (Initialization Vector, vecteur d’initialisation) AES-GCM doit être unique pour une clé donnée ; le hasard seul ne fournit cette garantie qu’avec une marge statistique et une gouvernance de volume explicite.

Pour les nonces AES-GCM massifs, préférer un compteur persistant ou une construction déterministe validée plutôt que demander des blocs au HSM à chaque chiffrement. Le HSM protège alors la clé et, si nécessaire, la racine servant à dériver les nonces. Cette séparation évite de faire dépendre le débit de données du débit de l’interface cryptographique. Un bus saturé n’améliore aucune primitive, malgré ce que promettent certaines slides avec un cadenas géant.

La même discipline s’applique à l’envelope encryption. Une DEK (Data Encryption Key, clé de chiffrement des données) peut être générée localement par un CSPRNG correctement administré si elle est immédiatement enveloppée par une KEK non exportable du HSM. Cette exception n’est valable que si le processus applicatif protège sa mémoire et si la durée de vie en clair est minimale. Les contraintes de séparation entre DEK et KEK sont détaillées dans KEK et DEK et dans l’envelope encryption.

Surface d’attaque du générateur aléatoire du HSM

La première attaque vise l’entropie avant le DRBG. Une panne physique, une source bloquée, une température hors plage ou une alimentation instable peut réduire l’incertitude sans interrompre immédiatement les appels. Les tests de santé doivent détecter les répétitions, les distributions anormales et les défaillances continues. Le module doit échouer fermé : refuser toute génération et remonter une erreur exploitable. Continuer avec la dernière graine connue est une décision catastrophique emballée dans une disponibilité trompeuse.

La deuxième attaque vise l’état du DRBG. Si un attaquant extrait l’état courant, il peut prédire les sorties suivantes jusqu’au prochain réamorçage. Si l’algorithme ne garantit pas la résistance à la compromission future, il peut aussi recalculer les sorties passées. Exiger la forward secrecy du générateur, c’est exiger qu’une compromission présente ne révèle pas les tirages antérieurs ; exiger la backward secrecy, c’est imposer un réamorçage qui rend les sorties futures imprévisibles après compromission. Les noms varient selon les fournisseurs, les propriétés ne varient pas.

Les instantanés de machines virtuelles créent un risque distinct pour les HSM virtuels et les consommateurs locaux de hasard. Restaurer un état de DRBG sauvegardé peut reproduire une séquence. Le contrôle doit porter sur la détection de restauration, le réamorçage au démarrage et l’interdiction de cloner un état cryptographique. Un clone qui répète ses nonces est parfaitement disponible, parfaitement supervisé, et parfaitement dangereux.

La troisième attaque est opérationnelle : firmware compromis, bibliothèque cliente remplacée, mécanisme PKCS#11 (Public-Key Cryptography Standards #11) mal sélectionné, ou journalisation accidentelle des sorties. Une certification FIPS (Federal Information Processing Standard) 140-3 apporte une assurance sur un périmètre évalué, pas une garantie que l’intégration appelle le bon slot, contrôle les erreurs ou surveille les alertes. Une étiquette de conformité ne répare pas une exception ignorée.

Enfin, les tests statistiques sur une sortie ne prouvent pas l’imprévisibilité. Un flux déterministe bien conçu peut réussir ces tests, comme un flux compromis soigneusement choisi. Ils détectent des défauts grossiers, pas une porte dérobée ni une graine faible. L’audit doit examiner l’architecture de génération, la chaîne de mise à jour et les indicateurs matériels, pas seulement lancer une batterie de graphiques jusqu’à obtenir une courbe décorative.

Vérifier l’appel PKCS#11 et les erreurs de génération

PKCS#11 expose C_GenerateRandom pour demander des octets aléatoires à un jeton initialisé. Cet appel ne garantit pas que la clé applicative sera créée dans le HSM : pour une clé non exportable, il faut utiliser les mécanismes de génération de clé du module, avec les attributs d’objet appropriés. La différence est fondamentale.

L’exemple suivant vérifie qu’un module expose une sortie aléatoire et produit un fichier binaire de test avec OpenSC pkcs11-tool. Le chemin du module, le slot et l’authentification doivent correspondre à l’environnement concerné.

# Lire 64 octets depuis le générateur du jeton PKCS#11.
# Ne jamais écrire cette sortie dans les journaux ni la committer.
pkcs11-tool \
  --module /opt/vendor/lib/libpkcs11.so \
  --slot 0 \
  --generate-random 64 > random.bin

# Vérifier uniquement la taille obtenue, pas la "qualité" cryptographique.
wc -c random.bin
# Résultat attendu : 64 random.bin

En intégration, contrôler explicitement le code de retour CKR_RANDOM_NO_RNG ou CKR_DEVICE_ERROR. Un repli silencieux vers rand() historique, une horreur qui survit parfois dans des dépendances oubliées, annule la frontière de confiance sans déclencher d’alerte. La politique doit être binaire : l’appel échoue, l’opération cryptographique échoue, l’alerte part.

Avant validation, vérifier la compatibilité entre le firmware du HSM, le client fournisseur et la version de l’interface PKCS#11 annoncée. Le support de PKCS#11 2.40 ou 3.0 ne signifie pas que tous les comportements de génération, de réamorçage ou de code d’erreur sont identiques. La page PKCS#11 expliqué traite la session et les objets ; le contrat de hasard doit s’ajouter aux tests d’intégration.

Exploitation : réamorçage, supervision et reprise

Le réamorçage est la frontière entre une compromission limitée et une compromission durable. Documenter la politique du fournisseur : événements qui déclenchent un réamorçage, quantité minimale d’entropie, comportement après échec de test de santé et visibilité des compteurs. Si ces éléments ne sont pas obtenables, le produit ne fournit pas assez de matière pour une fonction racine de confiance.

Superviser les transitions d’état du générateur, les alarmes matérielles, les erreurs de génération et la dérive de latence. Une hausse de latence peut signaler une source dégradée, un mécanisme de protection ou une saturation. Elle ne doit pas être corrigée en contournant le HSM avec une bibliothèque locale. La disponibilité se conçoit avec plusieurs modules, pas avec un plan B qui détruit le modèle de sécurité.

En haute disponibilité, chaque membre doit disposer de son entropie propre ou d’un mécanisme fournisseur démontré pour éviter la duplication d’état. Répliquer des clés est normal selon le modèle retenu ; répliquer un état de DRBG est une dette cryptographique. Les contraintes de bascule, de partition réseau et de cohérence sont à rapprocher de l’architecture HSM haute disponibilité.

Les sauvegardes doivent préserver les clés selon le protocole du fournisseur, jamais les sorties aléatoires ni des états de génération exportés. Après restauration, imposer les contrôles matériels et un réamorçage avant toute opération. La rotation des clés limite l’impact d’une génération suspecte, mais ne corrige pas rétroactivement des nonces réutilisés ou des clés prévisibles : la rotation des clés est une mesure de confinement, pas une machine à remonter le temps.

🐝 Ce qui arrive si on s’en passe

Sans source d’entropie matérielle qui amorce et réamorce le DRBG, les défauts de hasard deviennent directement exploitables par calcul. Deux signatures ECDSA produites avec le même nonce livrent la clé privée par simple algèbre, et un nonce seulement biaisé de quelques bits suffit à la retrouver par réduction de réseaux sur un lot de signatures publiques. Des clés RSA générées avec peu d’entropie finissent par partager un facteur premier : un calcul de PGCD entre modules publics collectés les factorise sans aucun accès au module. Une réutilisation d’IV AES-GCM expose la clé d’authentification GHASH, ce qui permet de forger des messages acceptés comme authentiques. Comme les sorties restent statistiquement normales, rien ne permet ensuite de dater le début du défaut : toute clé issue de la période suspecte doit être considérée comme compromise.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité fabrique et protège des clés de chiffrement. Pour fabriquer une clé impossible à deviner, il doit d’abord obtenir des informations réellement imprévisibles, produites par un phénomène physique mesuré dans l’appareil. Ces informations brutes peuvent contenir des défauts ou des déséquilibres ; elles sont donc vérifiées puis transformées avant usage.

Le module utilise ensuite une méthode mathématique qui produit rapidement beaucoup de nombres difficiles à prévoir. Cette méthode part d’une valeur secrète initiale obtenue grâce aux mesures physiques. Elle est régulièrement alimentée à nouveau par de nouvelles mesures afin de limiter les conséquences d’une fuite de son état interne.

Quand une application demande une nouvelle clé, la meilleure option consiste à demander au module de créer directement cette clé. La clé reste alors dans l’appareil. Demander seulement des nombres au module, les envoyer à l’application, puis y créer la clé augmente les endroits où un attaquant peut les voler.

Le système doit arrêter la génération si les contrôles détectent une panne ou une source physique dégradée. Continuer avec des anciens nombres ou basculer discrètement vers une fonction moins protégée rendrait les futurs secrets devinables. En cas de reprise après incident, l’appareil doit aussi refaire ses vérifications avant de produire de nouveaux nombres.

À lire aussi

• Produire de l’aléa utilisable en cryptographieMontrer pourquoi l’aléa est une dépendance critique et comment le consommer sans affaiblir clés, nonces, sels, challenges et tokens.
• 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é.
• Comment isoler les clés dans un HSM multi-tenantGestion multi-tenant d'un HSM partagé, isolation logique des clés par partition et règles d'exploitation entre applications ou équipes internes.
• Migrer un fournisseur HSM sans interruptionMéthode de migration progressive d'un système cryptographique vers un nouveau fournisseur HSM sans interrompre les services.

Pages voisines

La citent

• Attestation matérielle HSM des clés générées
• Vulnérabilités documentées des HSM certifiés
• Produire de l’aléa utilisable en cryptographie

RNG matériel ou PRNG dans un HSM

Elle cite

• Architecture module cryptographique materiel haute disponibilite
• Envelope encryption
• KEK vs DEK
• PKCS#11 explique
• Protéger des données avec un HSM (hardware security module)
• Rotation des cles
• Courbes elliptiques : compacité, validation et pièges
• RSA : trappe, padding et usages restreints
• L'entropie au démarrage