NIST SP 800-90A : normes DRBG

Les opérations cryptographiques nécessitent des nombres aléatoires de haute qualité : génération de clés, valeurs à usage unique, vecteurs d’initialisation, sels et jetons de session. Les générateurs de nombres véritablement aléatoires (TRNG) recueillent l’entropie à partir de sources physiques (bruit matériel, interruptions, bruit thermique), mais ils sont lents et ne sont pas toujours disponibles, notamment dans les machines virtuelles ou au début du démarrage. Les générateurs de bits aléatoires déterministes (DRBG) résolvent ce problème : on amorce un DRBG avec une petite quantité d’entropie véritable, puis on utilise un algorithme cryptographique pour l’étendre en un vaste flux de bits pseudo-aléatoires, computationnellement indiscernables de bits véritablement aléatoires. NIST SP 800-90A définit trois mécanismes DRBG approuvés, utilisés dans pratiquement toutes les implémentations cryptographiques modernes.

Un DRBG fonctionne selon trois opérations fondamentales. Initialisation : initialiser l’état interne du DRBG à l’aide d’une entrée d’entropie (provenant d’une source d’entropie), d’une valeur à usage unique (garantissant l’unicité) et, facultativement, d’une chaîne de personnalisation (contexte propre à l’application). Génération : produire le nombre demandé de bits pseudo-aléatoires et mettre à jour l’état interne afin d’empêcher la remontée vers l’état précédent. Réensemencement : injecter de l’entropie fraîche dans l’état du DRBG afin d’assurer la résistance à la prédiction — après un réensemencement, même un adversaire qui connaissait l’état précédent ne peut pas prédire les sorties futures. NIST spécifie des intervalles maximaux de génération : 2^48 requêtes avant le réensemencement obligatoire pour les trois types de DRBG.

NIST SP 800-90A définit quatre niveaux de sécurité : 112, 128, 192 et 256 bits. Le niveau de sécurité détermine l’entropie minimale requise lors de l’initialisation ainsi que la qualité de la sortie produite. Pour une sécurité de 128 bits, l’entrée d’entropie doit fournir au moins 128 bits d’entropie. La relation est la suivante : une entropie de n bits produit une sortie DRBG computationnellement indiscernable d’une sortie aléatoire pour un adversaire disposant de 2^n opérations. Les choix de longueur de clé (AES-128 contre AES-256) et de fonction de hachage (SHA-256 contre SHA-512) doivent correspondre au niveau de sécurité souhaité ou le dépasser. Un paramétrage excessif (SHA-512 pour une sécurité de 128 bits) est sûr, mais inutilement coûteux ; un paramétrage insuffisant compromet la sécurité.

Hash_DRBG conserve deux valeurs d’état : V (une valeur qui génère la sortie) et C (une constante ajoutée pendant la génération). Génération : hash_gen produit des bits en itérant H(0x01 || V), H(0x01 || V+1), ... jusqu’à obtenir une sortie suffisante ; V est ensuite mis à jour avec V = V + H(0x03 || V) + C + reseed_counter. Réensemencement : Hash_df (fonction de dérivation par hachage) combine V avec l’entropie fraîche pour produire de nouvelles valeurs de V et C. Hash_DRBG est simple à implémenter et son analyse de sécurité est simple, ce qui le rend adapté aux environnements contraints. NIST recommande une initialisation avec SHA-256 ou SHA-512. Hash_DRBG est utilisé dans SHA1PRNG de Java (ancienne version) et dans le DRBG historique d’OpenSSL.

HMAC_DRBG conserve un état composé d’une clé K et d’une valeur V. Génération : il itère V = HMAC(K, V) jusqu’à produire une sortie suffisante ; puis K = HMAC(K, V || 0x00) et V = HMAC(K, V). Mise à jour : elle prend une entrée supplémentaire et réinitialise K et V au moyen d’opérations HMAC. HMAC_DRBG dispose d’une preuve de sécurité claire fondée sur la sécurité de HMAC (hypothèse de PRF sur HMAC). C’est le DRBG le plus largement recommandé : OpenSSL (depuis la version 1.1.1), mbedTLS, wolfSSL et la plupart des piles TLS utilisent HMAC_DRBG. La construction HMAC assure un mélange intégré entre les appels successifs, ce qui rend les attaques de retour en arrière plus difficiles à mener, même si une partie de l’état est exposée.

CTR_DRBG utilise un chiffrement par blocs (AES) en mode compteur. État : clé K et compteur V. Génération : il chiffre les valeurs successives du compteur E(K, V), E(K, V+1), ... et incrémente V. Mise à jour : Block_Cipher_df sert à dériver de nouvelles valeurs de K et V à partir de l’entrée supplémentaire. CTR_DRBG est le DRBG le plus rapide : l’accélération matérielle AES-NI le rend plusieurs ordres de grandeur plus rapide que les DRBG fondés sur le hachage sur les processeurs modernes. Il s’agit du DRBG par défaut dans Windows CNG (CryptGenRandom utilise CTR_DRBG avec AES-256), dans OpenSSL 3.0 (par défaut) et dans le RNG du noyau Linux (appel système getrandom). La sécurité de CTR_DRBG repose sur le fait qu’AES est une permutation pseudo-aléatoire, propriété étayée par des décennies d’analyse.

La résistance à la prédiction est une propriété selon laquelle la sortie du DRBG reste imprévisible même pour un adversaire ayant auparavant compromis l’état du DRBG, à condition qu’une entropie fraîche soit mélangée par réensemencement. Un DRBG dont l’indicateur de résistance à la prédiction vaut true appelle la source d’entropie avant chaque génération afin d’injecter une entropie fraîche. Sans résistance à la prédiction, une compromission de l’état à l’instant T permet de calculer toutes les sorties futures, ce qui compromet la confidentialité des sorties futures. La sécurité rétrospective (également appelée résistance au retour en arrière) signifie que les sorties passées restent imprévisibles même si l’état actuel est connu ; HMAC_DRBG et CTR_DRBG l’assurent grâce à leurs étapes de mise à jour, qui dérivent une nouvelle clé à partir de l’état actuel après chaque génération.

SP 800-90A spécifie les algorithmes DRBG, mais pas la source d’entropie. SP 800-90B définit les exigences applicables aux sources d’entropie : les sources de bruit matériel doivent être caractérisées et validées, les estimations d’entropie doivent être prudentes et les tests de bon fonctionnement doivent détecter les défaillances des sources d’entropie. SP 800-90C précise comment combiner des sources d’entropie avec des DRBG pour obtenir des générateurs complets de bits aléatoires. Sources d’entropie courantes : RDRAND/RDSEED des CPU (RNG matériel, disponible sur les CPU Intel/AMD depuis 2012), entropie de l’OS (/dev/urandom sous Linux, BCryptGenRandom sous Windows), modules de sécurité matériels, RNG du TPM 2.0 et bruit environnemental (temporisation des disques, gigue réseau). Les conditions de faible entropie (machines virtuelles, début du démarrage) nécessitent un traitement particulier afin d’éviter les graines faibles.

FIPS 140-3 (la norme actuelle de validation des modules cryptographiques) impose les DRBG de NIST SP 800-90A pour toute génération de nombres aléatoires au sein des modules certifiés. Le module doit : utiliser un DRBG approuvé (hachage, HMAC ou CTR), s’initialiser à partir d’une source d’entropie approuvée satisfaisant aux exigences de SP 800-90B, effectuer des autotests au démarrage (POST) vérifiant le fonctionnement du DRBG, mettre en œuvre des tests continus du RNG (CRNGT) détectant les défaillances d’entropie bloquée à zéro ou à un, et prendre en charge le réensemencement lorsque la source d’entropie indique qu’une entropie est disponible. Les HSM (Thales Luna, AWS CloudHSM, Utimaco), les cartes accélératrices TLS et les dispositifs de chiffrement réseau exigent couramment des modules validés FIPS 140-3, ce qui favorise l’adoption de SP 800-90A.

Les systèmes d'exploitation modernes maintiennent un DRBG au niveau du noyau, initialisé à partir de sources d'entropie matérielles. Linux utilise un DRBG fondé sur ChaCha20 (depuis le noyau 5.17, en remplacement de l'ancienne conception de type Fortuna), initialisé à partir de RDRAND, des interruptions et d'événements liés aux disques et au réseau. /dev/urandom renvoie la sortie du DRBG et ne se bloque plus une fois l'initialisation initiale effectuée. /dev/random se bloque jusqu'à ce qu'une entropie suffisante soit disponible (comportement historique, en grande partie supprimé dans les noyaux récents). L'appel système getrandom(2) constitue l'interface moderne et ne se bloque qu'au tout début du démarrage, avant l'initialisation du DRBG. Windows utilise CTR_DRBG (AES-256) dans le RNG du noyau, initialisé à partir du TPM et d'événements matériels. Les applications doivent utiliser le DRBG du système d'exploitation via des interfaces de haut niveau plutôt que d'initialiser leurs propres DRBG à partir d'horodatages ou de PID.

Les vulnérabilités réelles des DRBG proviennent d'erreurs d'implémentation plutôt que de faiblesses de l'algorithme. (1) Initialisation insuffisante : initialiser uniquement avec l'horodatage actuel ou le PID fournit aux attaquants une graine facile à deviner. (2) Aveuglement lors de la création d'un processus fils : lorsqu'un processus crée un processus fils, le parent et l'enfant partagent le même état du DRBG et génèrent donc des nombres aléatoires identiques. Correctif : réinitialiser le DRBG après la création du processus fils (avec pthread_atfork ou un appel explicite à getrandom). (3) Réutilisation d'un instantané de VM : si un instantané de VM est restauré, l'état du DRBG revient à celui de l'instantané et génère une sortie déjà observée. Correctif : injecter une entropie unique au démarrage de la VM (VIRTIO RNG). (4) Ignorer silencieusement les contrôles de bon fonctionnement : un DRBG qui continue à générer des valeurs après avoir détecté une défaillance d'entropie fournit une sortie prévisible pour l'attaquant. (5) Réutiliser des valeurs nonce entre différentes instances de DRBG.

Quelle propriété le réensemencement d'un DRBG avec une entropie fraîche fournit-il ?

NIST SP 800-90A définit trois mécanismes DRBG approuvés : Hash_DRBG (hachage itératif, simple), HMAC_DRBG (fondé sur HMAC, avec une preuve de sécurité claire, largement déployé) et CTR_DRBG (mode compteur d'AES, le plus rapide grâce à AES-NI, utilisé par défaut dans Windows et OpenSSL). Tous partagent le cycle de vie Instantiate/Generate/Reseed, avec une limite reseed_interval de 2^48. La robustesse de sécurité (de 112 à 256 bits) détermine les exigences en matière d'entropie. La résistance à la prédiction exige un réensemencement avant chaque appel à Generate. FIPS 140-3 impose des DRBG SP 800-90A avec des sources d'entropie SP 800-90B. L'aveuglement lors de la création d'un processus fils, la réutilisation d'instantanés de VM et l'initialisation insuffisante sont les principaux pièges d'implémentation rencontrés dans la pratique.