Fonctionnement interne de Hash-DRBG, HMAC-DRBG et CTR-DRBG

Chacun des trois mécanismes DRBG de NIST conserve des composants d'état interne différents, conformément à son approche algorithmique sous-jacente. Hash_DRBG stocke V (une graine de longueur égale à celle du hachage) et C (une constante dérivée de V, utilisée lors de la génération de la sortie). HMAC_DRBG stocke la clé K (une clé secrète de longueur égale à celle du hachage) et la valeur V (une valeur de chaînage de longueur égale à celle du hachage). CTR_DRBG stocke la clé K (une clé AES) et V (un compteur de longueur égale à celle d'un bloc). Tous trois maintiennent un reseed_counter qui comptabilise les appels à Generate depuis le dernier ensemencement. La taille de l'état détermine l'empreinte mémoire : Hash_DRBG et HMAC_DRBG avec SHA-256 utilisent 64 octets d'état, tandis que CTR_DRBG avec AES-256 en utilise 48 (clé de 32 octets + compteur de 16 octets).

Hash_DRBG utilise Hash_df (fonction de dérivation par hachage) pour dériver l'état à partir du matériau d'entropie. Hash_df(input_string, no_of_bits_to_return) itère ainsi : pour counter = 1, 2, ..., calculer H(counter || no_of_bits || input_string) et concaténer les sorties jusqu'à obtenir suffisamment de bits. Cela étend de courtes entrées d'entropie en graines de la taille de l'état. Lors de Generate, la fonction de sortie calcule W = H(0x03 || V), où le préfixe 0x03 distingue cette utilisation des autres utilisations du hachage. La boucle de sortie est la suivante : data = H(0x01 || V) ; V = V + 1 ; répéter pour produire davantage de sortie. Après la génération, V est mis à jour : V = V + H(0x03 || V) + C + reseed_counter. La séparation des domaines au moyen des octets de préfixe (0x01, 0x03) empêche de confondre la sortie de la phase de génération avec celle de la phase de mise à jour de l'état.

La fonction Update de HMAC_DRBG constitue le cœur de toutes les transitions d'état. Update(provided_data, K, V) : K = HMAC(K, V || 0x00 || provided_data) ; V = HMAC(K, V). Si provided_data n'est pas vide : K = HMAC(K, V || 0x01 || provided_data) ; V = HMAC(K, V). Cette mise à jour en deux étapes garantit que la nouvelle clé et la nouvelle valeur dépendent toutes deux de l'état précédent et de toute entropie nouvelle. Generate : répéter V = HMAC(K, V) et ajouter chaque résultat à la sortie jusqu'à obtenir suffisamment de bits, puis appeler Update avec additional_input pour faire progresser l'état. La sécurité de HMAC_DRBG repose sur l'hypothèse que HMAC est un PRF sécurisé : un adversaire incapable de distinguer la sortie de HMAC d'une sortie aléatoire ne peut pas distinguer la sortie du DRBG d'une sortie aléatoire.

CTR_DRBG utilise Block_Cipher_df (fonction de dérivation) pour transformer le matériau d'ensemencement en une clé et un compteur. Block_Cipher_df(input_string, no_of_bits) utilise une construction BCC (enchaînement par chiffrement par blocs) : il applique AES-CBC de manière itérative à des blocs d'entrée afin de produire une sortie de la longueur requise. Cette fonction de dérivation est nécessaire pour gérer des entrées d'entropie de longueur variable et assurer la séparation des domaines. CTR_DRBG sans fonction de dérivation (autorisé pour les essais FIPS avec des entrées au format précisément défini) est plus rapide, mais plus sensible aux exigences de formatage de l'entrée. La boucle Generate est la suivante : temp = E(K, V) ; V = V + 1 ; ajouter temp à la sortie. Update : K || V = Block_Cipher_df(V || additional_input, seedlen) ; appliquer un XOR avec la clé actuelle.

Les performances varient considérablement selon le type de DRBG. Sur un CPU x86_64 moderne avec AES-NI, CTR_DRBG (AES-256) atteint environ 5 à 10 GB/s de sortie pseudoaléatoire : l'instruction AES-NI rend le calcul d'AES presque gratuit. HMAC_DRBG (SHA-256) atteint environ 200 à 400 MB/s : SHA-256 est rapide, mais n'est pas accéléré matériellement au même degré. Hash_DRBG (SHA-256) atteint environ 100 à 300 MB/s. Pour la génération de clés en volume ou le remplacement d'un chiffrement par flot, CTR_DRBG est nettement plus rapide. Pour les utilisations à faible débit (génération de clés de session, dérivation de valeurs nonce), la différence de performance est négligeable. OpenSSL 3.0 utilise CTR_DRBG (AES-256) par défaut pour cette raison.

Lors de l'instanciation, les trois DRBG acceptent une personalization_string facultative, mélangée à l'entrée d'entropie afin de rendre l'instance du DRBG unique. Cela empêche deux DRBG instanciés simultanément avec la même entropie de produire la même sortie : leurs flux divergent en fonction de la chaîne de personnalisation. Chaînes de personnalisation recommandées : identifiant de l'application + ID du processus + ID du fil d'exécution + horodatage + identifiant matériel. Même si deux VM reçoivent la même entropie (problème lié aux instantanés de VM dans le cloud), des chaînes de personnalisation différentes garantissent des flux de DRBG différents. NIST SP 800-90C recommande de toujours utiliser une chaîne de personnalisation. Le paramètre nonce remplit une fonction similaire : il s'agit d'une valeur courte et unique qui garantit qu'aucune instanciation ne commence dans le même état qu'une autre.

Les trois DRBG prennent en charge un paramètre additional_input dans les appels à Generate. Celui-ci permet à l'appelant d'injecter un contexte ou une entropie supplémentaire dans un seul appel à Generate, sans effectuer de réensemencement complet. Utilisations : (1) injecter, pour chaque requête, une entropie provenant d'une source d'entropie secondaire ; (2) fournir un contexte au niveau de l'application (ID de requête, horodatage) afin de lier les valeurs générées à leur utilisation ; (3) fournir une résistance facultative à la prédiction en injectant une entropie fraîche provenant du système d'exploitation. Additional_input est mélangé à l'état du DRBG avant la génération de la sortie. Si additional_input fournit une véritable entropie, il améliore la sécurité sans nécessiter de réensemencement officiel, lequel implique l'interface de la source d'entropie et la surcharge associée.

Après la désinstanciation d'un DRBG (ou lors du passage à une nouvelle instance), l'état interne doit être mis à zéro de manière sécurisée. L'état V, C (Hash_DRBG), K, V (HMAC_DRBG et CTR_DRBG), ainsi que toutes les variables de travail intermédiaires doivent être écrasés par des zéros. Cette opération est appelée mise à zéro explicite et est obligatoire dans les modules FIPS 140-3. En C, utilisez explicit_bzero() ou SecureZeroMemory() : un memset optimisé par le compilateur peut être supprimé comme optimisation d'une écriture morte, laissant le matériau de clé en mémoire. La crate zeroize de Rust et les solutions similaires propres à chaque langage assurent cette opération de manière portable. La destruction sécurisée des clés est importante dans les contextes où des vidages mémoire, des attaques de démarrage à froid ou des outils d'inspection des processus pourraient exposer l'état résiduel.

NIST fournit des vecteurs d'essai du programme de validation des algorithmes cryptographiques (CAVP) pour tous les DRBG SP 800-90A. Types d'essais : (1) essais à réponse connue — avec une entrée d'entropie, un nonce et une chaîne de personnalisation fixes, vérifier que la sortie générée correspond aux valeurs précalculées ; (2) essais de réensemencement — vérifier l'état du DRBG après une opération de réensemencement ; (3) essais PR (résistance à la prédiction) — vérifier que demander prediction_resistance=true produit la sortie correcte après l'injection d'une entropie fraîche. La validation CAVP est requise pour une soumission FIPS 140-3. Les bibliothèques à code source ouvert (OpenSSL, mbedTLS) incluent des vecteurs d'essai CAVP dans leurs suites d'essais de régression afin de détecter les régressions dans les implémentations de DRBG.

Les implémentations de DRBG sont confrontées à des risques subtils de canaux auxiliaires qui vont au-delà du modèle de sécurité algorithmique. Les attaques temporelles par cache contre AES (dans CTR_DRBG sans AES-NI) peuvent divulguer des éléments des clés de ronde ; AES-NI élimine ce risque en effectuant les calculs dans des registres, sans consultation de tables. HMAC_DRBG utilise HMAC en interne, qui fonctionne à temps constant si le SHA-256 sous-jacent fonctionne lui aussi à temps constant ; SHA-256 est généralement considéré comme fonctionnant à temps constant, car il ne comporte aucune branche dépendant des données. Les canaux auxiliaires physiques (analyse de la consommation électrique, rayonnement EM) visant le matériel qui produit le DRBG sont préoccupants pour les cartes à puce et les objets connectés ; les implémentations avec masquage permettent d'y remédier. L'attaque par lecture de l'état : si un adversaire peut lire l'état du DRBG au moyen d'une vulnérabilité de divulgation de mémoire (de type Heartbleed), toute la sortie future est compromise jusqu'au prochain réensemencement avec une entropie fraîche.

Si l'état d'un DRBG est compromis (par exemple au moyen d'une vulnérabilité de divulgation de mémoire), sa récupération exige : (1) détecter la compromission — les fuites de l'état du DRBG ne sont pas décelables par elles-mêmes ; une surveillance externe ou des contrôles d'intégrité sont nécessaires ; (2) effectuer un réensemencement avec une entropie fraîche provenant d'une source de confiance qui n'a pas été impliquée dans la compromission ; (3) renouveler toutes les clés cryptographiques dérivées du DRBG compromis (clés de session, clés de signature générées depuis le dernier réensemencement sain) ; (4) pour les implémentations logicielles, redémarrer le processus afin de créer une nouvelle instanciation propre du DRBG. SP 800-90C recommande des sources d'entropie chaînées : si l'une d'elles est compromise, l'ensemble reste sécurisé si l'autre fournit une véritable entropie.

Hash_DRBG utilise un hachage itératif avec Hash_df pour la dérivation et produit la sortie au moyen de boucles H(0x01 || V). HMAC_DRBG utilise HMAC comme PRF, avec une fonction Update en deux étapes (d'abord la clé, puis la valeur) qui fournit une réduction de sécurité claire. CTR_DRBG utilise AES en mode compteur avec Block_Cipher_df et atteint 5 à 10 GB/s sur du matériel doté d'AES-NI. Tous acceptent personalization_string lors de l'instanciation pour garantir l'unicité de l'instance, ainsi que additional_input lors de chaque génération pour lier le contexte. Les vecteurs d'essai CAVP valident les implémentations. L'état doit être mis à zéro de manière sécurisée après utilisation. Une compromission de l'état exige un réensemencement avec une entropie fraîche et le renouvellement des clés du matériel dérivé.