Les générateurs
de nombres aléatoires

Les documents généralement pénibles à lire, forcément vu le sujet.

Important : ce qui est écrit ici n'est peut-être plus à jour au moment où vous le lisez. Ce sera de toutes manières de votre faute si vous ne vous référez pas aux dernières éditions des standards, alors faite votre homework, retournez aux sources, puis oubliez ce qui est écrit ici. Ce n'est qu'une misérable introduction aux problèmes auxquels vous allez vous confronter.

NIST FIPS 140-1, 140-2 & 140-3

• Les standards utilisés principalement pour les TRNG dans les applications hors carte à puce.
• Ils s'intéressent surtout à ce qui sort du TRNG: ce sont principalement des tests statistiques, mais bon, les choses évoluent, la 140-3 va remplacer les précédentes.

NIST SP800-90

Trois sections :

• SP800-90A Pseudo-aléatoire / déterministe)
• SP800-90B Source d'entropie
• SP800-90C Combinaison des deux

Comble essentiellement le manque des normes FIPS précédentes.

Le protocole AIS31 est défini par le BSI ("Bundesamt für Sicherheit in der Informationstechnik") et recommandé par l'ANSSI française ("Agence Nationale de la Sécurité des Systèmes d'Information").

BSI AIS20/S31 ou plus simplement AIS-31

• Une norme très exigeante, souvent indiquée en référence pour les cartes à puce (Smartcards) et les Critères Communs.
• Deux classes sont définies :
  • La classe P1 qui s'intéresse essentiellement à la sortie du TRNG, donc les tests statistiques
  • La classe P2 ajoute des exigences afin de garantir un haut niveau d'entropie par le biais d'un modèle mathématique (stochastique).
• Cette histoire de modèle et de son utilisation pour faire de l'auto-contrôle est très délicate à gérer. Autrement dit, "ce n'est pas de la tarte".

L'ANSSI suit essentiellement l'AIS31.

C'était le plus simple à proposer, et bien le minimum. Je le sais, la première fois que j'ai proposé un RNG, en 2003, je me suis pelé la génération de 2 gigas de données (à l'époque, c'était quasiment la taille d'un disque dur) puis j'ai passé les tests pendant des heures qui n'ont rien donnés : on m'a dit alors que c'était bien 😊 car il ne faut pas trouver de répétitions ou d'écart statistique.

FIPS140-1 and FIPS140-2

• 4 tests (Monobit, Poker, Runs, Long runs) appliqués sur 20 000 bits
• Attention aux seuils, différents pour FIPS 140-1 et FIPS 140-2
• et les standards évoluent, des tests disparaissent, alors... vérifiez.

NIST 800-22

• 15 tests statistiques avec une stratégie indiquée
• requièrent à peu près 1 giga de données aléatoires

DIEHARD

• 15 tests statistiques similaires aux tests du NIST
• 80 millions de bits requis

AIS31

Neuf tests statistiques proposés, très clairement définis :

• T0 - Disjointness test (216 48-bit random blocks must be different), rejection probability for an ideal random source : 10^-17
• T1 - T4 - Four tests from FIPS140-1 (not from FIPS140-2 !) with rejection probability limit 10^-6
• T5 - Autocorrelation test. Tests applied on the raw binary signal in class PTG.2 and PTG.3 (some weaknesses are tolerable)
• T6 - Uniform distribution test
• T7 - Comparative test for multinomial distribution
• T8 - Coron's entropy test

En résumé, une série précise de tests à réaliser. On trouvera du software avec les normes pour vous faciliter la tâche (et éviter de vous gourer en programmant).

Quand le TRNG marche normalement, tout va bien. Mais fonctionne-t-il toujours correctement ?

Il vaut mieux s'en assurer, et à l'aide de votre modèle mathématique, vous pouvez définir des bornes de fonctionnement, à commencer par vérifier que ce qui en sort semble avoir une distribution normale —pas que des zéros par exemple...

L'idée est d'ajouter des modules qui vont scruter en permanence certaines sorties afin de s'assurer que les signaux soient corrects, et envoyer un signal d'alarme le cas échéant.

Par exemple, un TRNG basé sur le temps aléatoire entre deux "clicks" de radioactivité peut facilement vérifier la statistique du nombre de clicks sur une durée relativement courte. En fonctionnement normal, le nombre moyen de clicks sur une seconde devrait se situer entre un minimum et un maximum, tout ça parce que l'on a conçu le système de cette manière (le modèle mathématique est alors très simple).

Si un malandrin approchait une source radioactive externe (un morceau de minerai d'uranium), dans le but de perturber la statistique de durée entre deux clicks, alors le niveau de radioactivité augmenterait bien au-dessus de la valeur attendue, et le TRNG déclencherait une alarme.

Il n'est pas toujours possible de vérifier toutes les étapes suivant le principe physique employé.

Surtout, il ne faut pas que le test embarqué perturbe le système —une mauvaise conception consisterait à vérifier lorsque la sortie ne sert pas (ce qui n'est pas terrible), et en plus vous ne savez pas si le test perturbe le système...