Re: [HS] Informatique et entropie disponible
On Wed, May 27, 2009 at 03:21:48PM +0200,
mathieu <mathieu.ferrandez@gmail.com> wrote
a message of 55 lines which said:
> Elle sert en informatique à générer des valeurs aléatoires (très
> utile pour la cryptographie par exemple) Il vaut donc mieux qu'elle
> soit haute. Généralement, sur les ordinateurs, l'entropie est
> généré à partir du matériel (cycles CPU ou autres..) Cela est utile
> pour les applications ayant besoin de valeurs aléatoires (génération
> de clés gpg par exemple) Pour la faire augmenter, un bon find /
Une bonne lecture est le RFC 4086 :
RFC 4086 : Randomness Requirements for Security
http://www.bortzmeyer.org/4086.html
----------------------------
Auteur(s) du RFC: D. Eastlake (Motorola), J. Schiller (MIT), S. Crocker (MIT)
----------------------------
La sécurité, c'est toujours un problème difficile. Parmi les
sous-problèmes à résoudre pour rendre un système informatique sûr, la
sécurité du générateur de nombres aléatoires occupe une bonne place,
mais qui est souvent méconnu. Ce RFC fait donc le point sur le problème
et sur les mesures à adopter lors de la mise en œuvre des protocoles
IETF.
L'alerte de sécurité CVE-2007-2926
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926) sur le
générateur aléatoire de BIND est venue nous le rappeler : beaucoup de
mécanismes de sécurité informatique reposent sur la génération « sûre »
de nombres aléatoires. « Sûre » voulant dire ici « Difficile à prévoir
par l'adversaire ». Comme tout serveur récursif DNS, BIND doit placer
dans les requêtes sortantes une "query ID" que le serveur faisant
autorité mettra dans sa réponse, permettant ainsi de s'assurer de la
validité de la réponse (la "query ID" sert donc de "cookie"). Si les
"query ID" sont prévisibles par un méchant, il peut facilement
fabriquer de fausses réponses qui ont l'air vraies et ainsi empoisonner
le cache du serveur récursif.
Cette faille est très classique : nombreux sont les logiciels qui
utilisent, sans bien s'en rendre compte, un générateur aléatoire
prédictif. Notre RFC donne une explication partielle pour cet
aveuglement : les textes classiques sur les générateurs aléatoires ne
les jugent que par des considérations statistiques, pas en prenant le
point de vue d'un adversaire qui chercherait à trouver le nombre
suivant. Notre RFC cite l'exemple d'un générateur qui, devant fabriquer
des nombres de 128 bits aléatoires, produirait en moyenne 50 % de
nombres égaux à zéro et 50 % de nombres aléatoires. Statistiquement, il
y aurait toujours 64 bits d'entropie, ce qui peut sembler suffisant.
Mais un attaquant n'aurait qu'à essayer un nombre nul pour réussir la
moitié du temps et l'entropie réelle serait donc de un bit...
Ce RFC, qui succède au RFC 1750, est donc consacré à l'exposé des
bonnes pratiques en matière de générateur aléatoire. Depuis le RFC
1750, le monde des protocoles Internet a été bouleversé puisque presque
tous dépendent désormais plus ou moins de la cryptographie, qui
elle-même dépend souvent de générateurs aléatoires sûrs, par exemple
pour fabriquer les clés de session.
Les bonnes pratiques peuvent se regrouper en deux catégories, utiliser
le hasard présent dans la matériel, et utiliser des générateurs
cryptographiquement forts.
Le matériel d'un système informatique est en effet source de nombreux
bruits très aléatoires. Le bruit de fond du micro (section 3.2.1) ou
les interruptions envoyées par le disque dur (section 3.2.2) sont deux
bons exemples. Presque tous les ordinateurs ayant un tel matériel, il
est recommandé de l'utiliser comme source d'entropie. (Les cartes
réseaux ne sont mentionnées qu'en passant, car leurs interruptions
peuvent être influencées par un tiers, surtout s'il est sur le même
réseau.) Idéalement, il faudrait utiliser des dispositifs quantiques
comme un ensemble d'atomes radioactifs dont on mesure la désintégration
mais les PC ont plus souvent un micro qu'un compteur Geiger...
Le RFC détaille aussi des mauvaises idées, par exemple le programmeur
qui doit initialiser un générateur aléatoire avec une graine ("seed")
utilise souvent l'horloge de la machine (par exemple en Python, quelque
chose comme generator = random.Random (time.time()) ou bien en C,
initstate(time(NULL), state, NUMSTATES);). C'est en général très peu
sûr, car les horloges ont typiquement une résolution très faible : si
l'attaquant sait à quelle heure approximative le système a démarré, il
peut trouver la graine et en déduire les nombres générés (section 3.4
du RFC). La section 6.1 détaille d'autres mauvaises idées, notamment
celle de croire que, si on fait des manipulations très complexes des
données, on est d'avantage en sécurité (en fait, c'est souvent le
contraire).
Il y a beaucoup d'autres détails à prendre en compte (le RFC note que
le problème est « étonnemment difficile ») comme le fait qu'une machine
qui démarre a accumulé peu d'entropie et est donc particulièrement
vulnérable (sauf si on sauvegarde le dernier résultat du générateur
lors de l'arrêt, pour l'utiliser comme graine au démarrage suivant).
Pour le programmeur qui trouve cela bien difficile, notons que le RFC,
dans le traditionnel esprit IETF de se soucier des problèmes pratiques,
pas juste de la théorie, a prévu une section 7 qui détaille les
fonctions déjà écrites et qu'il n'y a plus qu'à utiliser comme
/dev/random sur beaucoup de systèmes Unix. /dev/random est un
pseudo-fichier rempli par le noyau du système en utilisant diverses
sources d'entropie, dont celles fournies par le matériel. Il existe
aussi un /dev/urandom, moins sûr (car utilisant également un générateur
pseudo-aléatoire) mais non bloquant (la lecture de /dev/random peut
durer longtemps, car le noyau n'y écrit rien tant qu'il n'a pas assez
récolté d'entropie). Voici un exemple d'utilisation de /dev/urandom
pour obtenir 512 octets aléatoires dans un fichier :
dd bs=512 count=1 if=/dev/urandom > /tmp/random_data
Ceux qui aiment lire le code source noteront que, dans les noyaux Linux
2.6, ce mécanisme est programmé dans drivers/char/random.c et que les
commentaires très détaillés de ce fichier sont instructifs.
Les personnes allergiques aux mathématiques sont prévenues que ce RFC
est un des rares documents de l'IETF à comporter des formules
mathématiques (qui n'ont pas été faciles à publier en texte seul).
Reply to: