Rendez moi mon entropie !

Toute la cryptographie repose sur la génération de nombres aléatoires, on a ainsi pû en voir les effets à de nombreuses reprises. Tout le monde citera la fameuse débacle Debian/OpenSSL mais c'est un incident parmi tant d'autres... Par exemple, un des CVE d'aujourd'hui concerne un défaut dans l'initialisation de la graîne (CVE-2009-0255) dans un CMS, "hier" c'était le générateur pseudo-aléatoire Microsoft qui était prit la main dans le sac par newsoft et Kostya, etc.

Tout ça, ce sont des problèmes "résolvables" : il y a tout un tas de recommendations pour éviter que cela ne se reproduise, en théorie. Mais si on commençe à regarder ce que le futur nous prévoit, on se rend compte qu'on va vers un tas d'ennuis...

L'entropie & ses problèmes

Commençons par expliquer comment on fait aujourd'hui. Tout d'abord, à part avec du matériel dédié, on ne sait générer que des nombres pseudo-aléatoires. Pour cela, on va utiliser des sources de bruit environnementales (température, timing d'accès disque, bruit d'un capteur, accéléromètre, interruptions clavier, etc.). Bref, tout ça relève quand même de la bidouille, mais de la bidouille qui fonctionne :)

Les choses se compliquent avec les nouvelles générations de matériels. On peut considérer qu'on est progressivement en train de changer "on-the-fly" la moquette par du lino tout en laissant les meubles posés. Autrement dit, on se repose sur les hypothèses de la dernière décennie pour montrer la solidité d'un système d'aujourd'hui.

Hardware 2.0

L'exemple du temps d'accès disque est flagrant, il avait été montré en 1995 que le temps d'accès pouvait être considéré comme aléatoire grace aux turbulences à l'intérieur des disques dur donc cela validait son utilisation pour contribuer à l'entropie du système. Mais là où ça devient embetant, c'est que l'on n'a pas remit en question cette propriété pour les disques dur SSD qui sont pourtant dépourvus de système mécanique. Hypothèse fail

Les mini-ordinateurs (NAS, bornes d'accès Wifi, boxes Internet, etc.) sont dépourvus de disques dur (remplaçés par de la CF ou équivalent), n'ont pas de clavier et ont tous une configuration exactement identiques en sortie d'usine (à part l'adresse MAC et le numéro de série marqué en NVRAM), comment peuvent ils avoir une entropie suffisante pour générer des clefs robustes (administration HTTPS, clefs SSH, clefs Wifi, etc.) lors du premier démarrage ? Rien ne l'indique... Il y a quelques "work-arounds" comme l'obligation de se plugger en Ethernet à la box afin de l'administrer pour la première fois (ça charge ainsi un peu d'entropie) mais les cryptographes ne considèrent pas les évenements venant du réseau comme "sûr" pour alimenter l'entropie.

Hypothèses fail

Virtualisation

La virtualisation apporte aussi son lot de problème : on utilise par exemple les interruptions car on considère qu'elles sont décorrélées de l'horloge du processeur (puisqu'elles sont normalement déclenchées par un évenement externe). Or avec un hyperviseur logiciel comme Xen, ce n'est plus le cas puisque c'est le dom0 qui génère ces interruptions, donc l'hypothèse de départ est encore invalidée. FAIL

De plus, avec la virtualisation matérielle, étant donné que les guests et le host partagent quelques ressources matérielles, sommes-nous vraiment certains qu'un guest ne peut pas prévoir le PRNG de son host ou de son voisin ?

Mutualisation

Beaucoup plus simplement, on a vu que la mutualisation de virtual hosts PHP pouvait mener à en partager un peu trop : s'ils ne sont pas utilisés en CGI, deux scripts PHP de vhosts différents peuvent tourner dans le même processus. Grossièrement, cela signifie que si le premier script fixe la graine d'aléa, le deuxième script utilisera le PRNG laissé dans l'état précédent. FAIL

Solution

La solution ? L'utilisation de RNG matériel est la seule possibilité. Les chipsets Intel et Via intègrent déjà cette fonctionnalité en XOR-ant les sorties d'oscillateurs libres fonctionnant à des horloges différentes.

Il n'y a plus qu'à espérer que ces HW-RNG soient vraiment robustes et que les implémentations soient correctes (pas comme NetBSD qui croyait détecter un HW-RNG alors que ce hub ne fournissait qu'un flux de 0xff :)...

Mise à jour du 30 janvier 2009 : En fait, c'est newsoft qui avait souligné le problème de clef dans Windows en lisant la note du CERTA.