Entropie sur les machines virtuelles

Comme vous le savez peut-être, il n'est pas aussi facile de générer de l'entropie sur une machine virtuelle que sur un PC "normal". La génération d'une clé gpg sur une machine virtuelle peut prendre un certain temps, même avec les bons outils.

Il existe de nombreuses autres fonctions de cryptage qui ne sont pas aussi sensibles à l'entropie que le gpg.

Peut-on donc dire que la cryptographie est moins sécurisée sur une machine virtuelle?

Tout d'abord, permettez-moi de dire que je ne suis pas du tout un expert en sécurité.

Comme la création de clés gpg utilise /dev/randomcomme générateur de nombres aléatoires, elle est aussi sécurisée sur une machine virtuelle, que sur une machine réelle.
/dev/randomest un dispositif de blocage et cessera de fournir tout caractère aléatoire au-delà du montant disponible. Vous pouvez vérifier votre caractère aléatoire disponible par
cat /proc/sys/kernel/random/entropy_avail(devrait être autour de 2000 )

Sur une machine virtuelle, le caractère aléatoire disponible est en effet inférieur à celui d'une machine réelle, en raison du manque d'accès au matériel.
Vous pouvez augmenter l'entropie en appliquant par exemple des clés d'entropie et / ou basculer vers une machine non virtualisée.

Il y a un bel article disponible sur l'entropie sur les machines virtuelles. Malheureusement, les deux parties de l'article ne sont disponibles que dans le cache Google pour le moment.

L'entropie a d'autres effets sur tout cryptage ssl / tls. Ainsi, l'utilisation /dev/urandomou toute autre source non vraiment aléatoire a en effet un impact sur la sécurité de vos applications.

En termes de fiabilité /dev/urandompar rapport au vrai hasard;
je ne suis pas en mesure de vous donner une réponse décente là-bas, désolé.

Pour plus d'informations sur ce sujet, vous pouvez aller sur http://security.stackexchange.com et / ou lire par exemple. ce post

Oui, dans la plupart des cas, la cryptographie est moins sécurisée sur une machine virtuelle que sur un "vrai" serveur.

Ce dernier peut au moins recueillir l'entropie à partir de certains matériels réels. En fait, le fonctionnement d'un élément matériel est - dans la plupart des cas - lié à un phénomène physique, qui est toujours soumis à de petites variations, aléatoires par tous les comptes. Étant donné que les serveurs fonctionnent généralement très longtemps sans réinitialisation, le pool d'entropie résultant sera finalement de qualité suffisante.

Les machines virtuelles souffrent de trois problèmes.

1. Le matériel qu'ils voient n'est pas réel et n'est donc pas influencé par un phénomène physique. Ils pourront collecter l'entropie de manière beaucoup plus lente.
2. Les machines virtuelles sont réinitialisées beaucoup plus souvent que les serveurs réels et elles peuvent même ne pas avoir le temps de collecter suffisamment d'entropie (c'est pourquoi il est bon de sauvegarder l'état d'entropie actuel lors de l'arrêt et de l'utiliser pour alimenter le pool d'entropie lors du redémarrage).
3. Alors qu'un vrai serveur peut avoir une chance de déterminer quand il traite un mauvais pool d'entropie, la machine virtuelle fonctionnera plus facilement sous l'impression que le pool d'entropie est bon (car il a été collecté à partir du matériel, mais sans savoir que le matériel est pas réel), alors qu'il est en fait mauvais.

La meilleure solution consiste à laisser la machine virtuelle simplement abandonner et à se rendre compte que le matériel qu'elle voit est une mauvaise source d'entropie. Ensuite, organisez un service de réseau local pour distribuer une entropie de haute qualité (voir Entropy Broker ). Le "serveur entropie" peut extraire le caractère aléatoire du matériel générique (auquel cas il doit fonctionner pendant un temps suffisant, et il doit avoir un système d'exploitation décent) ou du matériel cryptographique spécifique (une puce TPM, une puce VIA Padlock, etc.).

Une machine virtuelle utilisant un tel service peut même être plus sécurisée (cryptographiquement) qu'un "vrai" serveur qui vient de démarrer.