True Random Number Generator

Un circuit peut mesurer de petites fluctuations électriques et les transformer en nombres. L’essentiel est la part de la mesure qu’un attaquant ne peut pas prédire. Produire rapidement beaucoup de données ne suffit pas. NIST SP 800-90B évalue donc la source de bruit précise, son échantillonnage, le traitement éventuel et les contrôles de fonctionnement. Nommer le phénomène physique ne remplace pas cette évaluation. [1]

Une source peut produire plus de zéros que de uns. Le traitement appelé conditioning aide à réduire ce biais et à concentrer l’entropie disponible, l’incertitude du point de vue de l’attaquant, dans une sortie plus courte. Il ne crée pas l’incertitude absente. NIST SP 800-90B lie donc l’entropie reconnue en sortie à l’entrée et à la méthode utilisée. Même un hash, une empreinte calculée des données, ne prouve pas leur imprévisibilité : une entrée connue permet de recalculer la même empreinte. [1]

Si la source renvoie toujours la même valeur, le dispositif ne doit pas l’ignorer. NIST SP 800-90B utilise Repetition Count Test pour suivre les répétitions et Adaptive Proportion Test pour les fréquences inhabituelles. Ces contrôles recherchent certaines pannes ; ils ne détectent pas automatiquement chaque attaque ou défaut. Lorsqu’une panne persistante est détectée, la source ne doit pas continuer à fournir des données comme en fonctionnement normal. [1]

La présence d’un TRNG ne suffit pas à établir la sécurité d’un portefeuille. Il faut aussi savoir comment la version précise utilise ses données et réagit aux erreurs. NIST SP 800-90C considère donc les sources avec les générateurs qui les suivent. Évaluer un composant ne revient pas à évaluer tout le portefeuille. Même une excellente source d’aléa ne protège pas une sauvegarde que vous révélez ensuite. [4]

Un long enregistrement d’un appareil en marche révèle d’autres aspects de son comportement que des arrêts et redémarrages répétés. NIST SP 800-90B inclut donc des tests de redémarrage. L’évaluation doit correspondre à la source précise et à ses conditions de fonctionnement. Le résultat d’un échantillon ne couvre pas automatiquement tous les appareils ou environnements. Modifier le micrologiciel, le programme interne de l’appareil, peut aussi nécessiter une nouvelle évaluation. [1]

Les instructions RDRAND et RDSEED apparaissent dans la documentation technique. Intel les décrit dans son guide du DRNG, un générateur matériel de nombres aléatoires. RDRAND fournit les résultats d’un générateur déterministe qui calcule des valeurs à partir de son état interne. RDSEED fournit de l’entropie traitée pour l’initialisation, c’est-à-dire la création de l’état de départ d’un générateur. Ces deux voies peuvent partir d’une source physique sans pour autant donner un accès direct au bruit brut. [2]

Le processeur n’a pas forcément un résultat prêt à chaque demande. Intel exige donc de vérifier l’indicateur d’état CF pour RDRAND et RDSEED : 1 signifie résultat disponible, 0 indisponible. Chercher seulement un zéro numérique dans le registre de destination, un petit espace de stockage du processeur, ne suffit pas. Il faut lire l’indicateur de réussite. Le fait qu’un processeur accepte une instruction ne garantit pas la réussite d’une demande particulière. [2]

Sous Linux, l’interface hw_random permet de lire une source matérielle par /dev/hwrng, à la manière d’un fichier. Sa documentation avertit explicitement que cette interface n’applique pas elle-même de tests de qualité aux données. Un matériel défectueux ou altéré peut donc renvoyer des données incorrectes que l’application parvient pourtant à lire. Une lecture réussie ne prouve pas une entropie suffisante. Il faut évaluer la source et la manière dont le programme utilise ses résultats. [3]