cloud computing: trop dans les nuages?

Je vais aujourd'hui m'attarder sur une présentation d'Alex Stamos au blackhat 2009 concernant le cloud computing. Pas de réelle vulnérabilité ou d'exploit fantastique mais des considérations sur la sécurité qui valent la réflexion:
Il semblerait que la génération de nombres aléatoires, un problème réglé depuis des années, en redevienne un.
En effet, pour petit rappel, l'ordinateur utilise les périphériques bas niveau pour collecter des données aléatoires. Il se sert ensuite de ce "réservoir" pour obtenir des nombres "vraiment" aléatoires (donc quasiment non prédictibles). Mais le cloud computing serait en train de changer la donne:
Là ou un pc utilise les mouvements de la souris et les touches du claviers pour collecter de l'aléatoire, un serveur ne possède rien de cela. Il peut toutefois utiliser les mouvements du disque dur comme source d'aléa. Mais qu'en est il d'un serveur virtualisé? N'ayant pas accès aux matériels physiques, il ne lui reste que la mesure du temps exacte depuis sa mise en route, ce qui est bien peu et pas assez pour générer des nombres robustes.
Bien sur plus le temps passe et plus les ressources d'éléments aléatoires sont importantes. Mais Alex Stamos s'intéresse aux machines générées à la volée pour une tache particulière. Ces dernières sont éphémère et d'après lui n'ont pas le temps d'atteindre des seuils raisonnables de ressources aléatoire.
Il imagine ainsi un scénario où l'attaquant se crée une machine sur un serveur. Le peu d'entropie l'aidera grandement dans la prédiction des nombres aléatoires et réduira ainsi considérablement le temps de crackage du chiffrement des autres machines virtualisé.
Ce n'est bien sur à l'heure actuelle que de l'extrapolation, mais loin d'être une chimère ce fait mérite d'y porter attention. Juste en petit exemple du défaut d'entropie des systèmes virtualisés je vous cite un commentaire du dernier article:

The same problem (lack of randomness) may also affect IP sequence number generation for virtual machines. A quick nmap scan of a Fedora Core 10 system running as a VM ends with:

TCP Sequence Prediction: Difficulty=0 (Trivial joke)

but the same host running Fedora Core 11 natively gives:

TCP Sequence Prediction: Class=random positive increments
Difficulty=939462 (Good luck!)

Cheers,
Dave

ca laisse songeur n'est ce pas...

Les deux articles (bien plus complets et abordant pour le second d'autres problèmes que l'aléa) sur cette conférence: ici et là