(Mise en garde : Je ne prétends certainement pas que HAVEGE est à la hauteur de ses prétentions. Je n'ai pas vérifié leur théorie ou leur mise en œuvre.)
Pour obtenir de l'aléatoire, HAVEGE et les systèmes similaires se nourrissent des "événements physiques", et en particulier du timing d'événements physiques. De tels événements incluent des occurrences d'interruptions matérielles (qui, à leur tour, rassemblent des données sur les frappes de touches, les mouvements de souris, les paquets Ethernet entrants, le temps nécessaire à un disque dur pour terminer une demande d'écriture...). HAVEGE prétend également se nourrir de tous les types de cache miss qui se produisent dans un CPU (cache L1, cache L2, TLB, prédiction de branchement...); le comportement de ces éléments dépend de ce que le processeur a fait au cours des quelques milliers de cycles d'horloge précédents, il y a donc un potentiel de « caractère aléatoire ». Cela dépend de la possibilité de mesurer l'heure actuelle avec une grande précision (pas nécessairement exacte), c'est là que le rdtsc l'instruction entre en jeu. Il renvoie le contenu actuel d'un compteur interne qui est incrémenté à chaque cycle d'horloge, il offre donc une précision inférieure à la nanoseconde.
Pour un système de machine virtuelle, il y a trois choix en ce qui concerne cette instruction :
- Laissez l'instruction aller directement au matériel.
- Intercepter l'instruction et l'émuler.
- Désactivez complètement l'instruction.
Si le gestionnaire de VM choisit la première solution, alors rdtsc a toute la précision nécessaire et devrait fonctionner aussi bien que s'il s'agissait d'une machine physique, dans le but de collecter l'entropie à partir d'événements matériels. Cependant, puisqu'il s'agit d'une machine virtuelle, il s'agit d'une application sur le système hôte; il n'obtient pas le CPU tout le temps. Du point de vue du système d'exploitation invité utilisant rdtsc , cela donne l'impression que son processeur a été "volé" occasionnellement :deux rdtsc successifs les instructions, nominalement séparées par un seul cycle d'horloge, peuvent signaler une augmentation du compteur de plusieurs millions . En bref, quand rdtsc est simplement appliqué sur le matériel, puis l'OS invité peut l'utiliser pour détecter la présence d'un hyperviseur.
La deuxième solution vise à rendre l'émulation plus "parfaite" en maintenant un compteur de cycles virtuel par VM, qui garde une trace des cycles réellement alloués à cette VM. L'avantage est que rdtsc , du point de vue de l'invité, ne présentera plus l'effet "cycles volés". L'inconvénient est que cette émulation est effectuée en déclenchant et en piégeant une exception CPU, ce qui augmente le coût du rdtsc opcode de quelques dizaines de cycles d'horloge (cela dépend de la marque du processeur ; certains exécutent rdtsc en moins de 10 cycles, les autres utilisent 60 ou 70 cycles) à plus de mille de cycles. Si l'invité essaie de faire beaucoup de rdtsc (comme HAVEGE aura tendance à le faire), alors il ralentira jusqu'à ramper. De plus, le code de gestion des exceptions perturbera la mesure ; au lieu de mesurer la synchronisation des événements matériels, le code mesurera le temps d'exécution du gestionnaire d'exceptions, ce qui peut éventuellement réduire la qualité du caractère aléatoire extrait.
La troisième solution (désactiver rdtsc ) empêchera simplement HAVEGE de renvoyer un bon caractère aléatoire. Puisqu'il utilise en interne un PRNG, la sortie peut toujours tromper les outils d'analyse statistique, car il y a une énorme différence entre "avoir l'air aléatoire" et "être imprévisible" (les outils d'analyse statistique suivent le chemin "avoir l'air aléatoire", mais la sécurité cryptographique repose sur l'imprévisibilité ).
Le manuel de VirtualBox affirme que VirtualBox, par défaut, suit la première méthode (rdtsc est inconditionnellement autorisé et appliqué directement sur le matériel), mais peut être configuré pour appliquer la deuxième solution (ce que vous ne voulez pas, dans ce cas).
Pour tester ce que fait votre VM, vous pouvez essayer ce petit programme (compilé avec gcc -W -Wall -O sur Linux ; le -O est important) :
#include <stdio.h>
#if defined(__i386__)
static __inline__ unsigned long long rdtsc(void)
{
unsigned long long int x;
__asm__ __volatile__ (".byte 0x0f, 0x31" : "=A" (x));
return x;
}
#elif defined(__x86_64__)
static __inline__ unsigned long long rdtsc(void)
{
unsigned hi, lo;
__asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}
#endif
int
main(void)
{
long i;
unsigned long long d;
d = 0;
for (i = 0; i < 1000000; i ++) {
unsigned long long b, e;
b = rdtsc();
e = rdtsc();
d += e - b;
}
printf("average : %.3f\n", (double)d / 1000000.0);
return 0;
}
Sur une machine non virtuelle, avec le "vrai" rdtsc , cela doit rapporter une valeur comprise entre 10 et 100, selon la marque du processeur. Si la valeur rapportée est 0, ou si le programme plante, alors rdtsc est désactivé. Si la valeur est en milliers, alors rdtsc est émulé, ce qui signifie que la collecte d'entropie peut ne pas fonctionner aussi bien que prévu.
Notez que même obtenir une valeur entre 10 et 100 n'est pas une garantie que rdtsc n'est pas émulé, car le gestionnaire de VM, tout en maintenant son compteur virtuel, peut lui soustraire le temps attendu nécessaire à l'exécution du gestionnaire d'exceptions. En fin de compte, vous avez vraiment besoin de bien regarder le manuel et la configuration de votre gestionnaire de VM.
Bien sûr, toute la prémisse de HAVEGE est discutable. Pour toute sécurité pratique, vous avez besoin de quelques bits "réels aléatoires", pas plus de 200, que vous utilisez comme graine dans un PRNG cryptographiquement sécurisé. Le PRNG produira des gigaoctets de pseudo-alea indiscernables du vrai hasard, et c'est suffisant à toutes fins pratiques.
Insister pour revenir au matériel pour chaque bit ressemble à une nouvelle éclosion de cette idée erronée qui considère l'entropie comme une sorte d'essence, que vous brûlez quand vous la regardez.
Sur l'avis polarssl :une réponse technique détaillée peut être trouvée dans la source debian la plus récente :
http://bazaar.launchpad.net/~ubuntu-branches/debian/experimental/haveged/experimental/revision/12?start_revid=12#debian/README.Debian
Le résumé analytique est :polarssl !=haveged !=HAVEGE
Sur les expériences de l'émulateur embloms.se :
Le haveged suite de tests, NIST et ent , vérifiez qu'une version source a produit un RNG fonctionnel. Des tests d'exécution sont nécessaires pour vérifier le fonctionnement dans un environnement virtuel. C'est un ajout assez récent à haveged.
Sur les tests statistiques :
Supposons que vous ayez un hardware RNG , un TRNG , comment savez-vous qu'il n'est pas cassé ? Cassures matérielles. L'organisme de normalisation allemand a une spécification qui traite de ce problème, AIS31 . Cette approche est adoptée par haveged. Une discussion (partielle) des normes pour RNG telles qu'elles s'appliquent à haveged peut être trouvée à :
http://www.issihosts.com/haveged/ais31.html
La non-prévisibilité de HAVEGE est exactement le même mécanisme que celui observé dans les logiciels de benchmarking. Ce n'est pas dû à la dérive de la minuterie, mais à l'agrégation des comportements asynchrones dans un processeur moderne. Peu importe que les variations de performances proviennent d'un manque de cache ou d'une tranche de temps transmise à un autre processeur. La précision de la minuterie n'a pas non plus d'importance tant qu'elle est "adéquate". Comment est-ce déterminé ? Par la sortie. Par conception (ou peut-être sur conception) /dev/random est immunisé contre les mauvaises données d'entrée. La seule façon de subvertir la conception est de mentir sur l'entropie ajoutée au pool d'entropie. Les versions les plus récentes de haveged effectuent une estimation de l'entropie d'exécution sur la sortie générée pour s'assurer que la sortie est cohérente avec un TRNG idéal.
Synthèse :haveged la sortie est indiscernable d'un TRNG selon les tests utilisés par l'organisme de normalisation allemand pour certifier TRNG . Si ce n'est pas le cas, haveged va s'arrêter.
(Mise à jour , avec nos remerciements à gwuertz l'auteur/responsable actuel de haveged , j'ai raté la séparation entre HAVEGE et haveged .)
haveged est une implémentation distincte de la méthode HAVEGE pour générer des nombres aléatoires, elle est actuelle, maintenue et documentée ici :http://www.issihosts.com/haveged/ (et n'utilise plus directement libhavege).
HAVEGE n'est pas très actuel (2006), bien que quelqu'un l'ait corrigé plus récemment (2009) pour plus de rapidité et d'exactitude. Je serais prudent car il ne documente pas sa méthode, ne mentionne pas les machines virtuelles et, comme indiqué, s'appuie (fortement) sur RDTSC (ou plate-forme équivalente). (De plus, le code source me fait frissonner, mais c'est assez subjectif.)
Je soutiendrai que la machine virtuelle hôte ne devrait pas divulguer involontairement un état aux invités, elle ne devrait donc pas être considérée comme une bonne source d'entropie lors de l'utilisation de cette méthode.
Une meilleure approche sur Linux est rng-tools avec le pilote rng paravirtualisé virtio-rng (c'est-à-dire permettre à un invité d'accéder à l'entropie recueillie par l'hôte, éliminant ainsi de nombreux problèmes potentiels concernant la vue d'invités d'événements "aléatoires"), ou vous pouvez trouver Entropy Courtier plus utile. Sur les puces Intel récentes, vous pouvez également exposer l'instruction RDRAND aux invités, évitant ainsi le problème.
Cet article (tiré de la conférence de hpa à LinuxCon Europe 2012 ) est une lecture utile :http://lwn.net/Articles/525459/ , il traite également de HAVEGE /haveged (bien que la distinction ne soit pas claire ici non plus).
Voir les réponses à cette question pour quelques réflexions sur la façon de déterminer le manque de l'aléatoire :quelles statistiques peuvent être utilisées pour identifier les données pseudo-aléatoires ?