Entropie auf virtuellen Maschinen

Wie Sie vielleicht wissen, ist es nicht so einfach, auf einer virtuellen Maschine Entropie zu erzeugen wie auf einem "normalen" PC. Das Generieren eines GPG-Schlüssels auf einer virtuellen Maschine kann eine Weile dauern, selbst mit den richtigen Tools.

Es gibt viel mehr Kryptofunktionen, die nicht so entropiebewusst sind wie gpg.

Kann man also sagen, dass Kryptografie auf einer virtuellen Maschine weniger sicher ist?

Lassen Sie mich zunächst sagen, dass ich überhaupt kein Sicherheitsexperte bin.

Da die Erstellung von GPG-Schlüsseln /dev/randomals Zufallszahlengenerator verwendet wird, ist sie auf einer virtuellen Maschine genauso sicher wie auf einer realen Maschine.
/dev/randomist ein Blockiergerät und gibt keine Zufälligkeiten mehr aus, die über den verfügbaren Betrag hinausgehen. Sie können Ihre verfügbare Zufälligkeit überprüfen, indem Sie
cat /proc/sys/kernel/random/entropy_avail(sollte etwa 2000 sein )

Auf einer virtuellen Maschine ist die verfügbare Zufälligkeit aufgrund des fehlenden Hardwarezugriffs tatsächlich geringer als auf einer realen Maschine.
Sie können die Entropie erhöhen, indem Sie z. B. Entropieschlüssel anwenden und / oder auf eine nicht virtualisierte Maschine umschalten.

Es gibt einen schönen Artikel über Entropie auf virtuellen Maschinen. Leider sind beide Teile des Artikels derzeit nur in Google Cache verfügbar.

Entropie hat weitere Auswirkungen auf die SSL / TLS-Verschlüsselung. Wenn Sie also /dev/urandomeine nicht wirklich zufällige Quelle verwenden, wirkt sich dies in der Tat auf die Sicherheit Ihrer Anwendungen aus.

In Bezug darauf, wie zuverlässig im /dev/urandomVergleich zu wahrer Zufälligkeit ist;
Ich bin nicht in der Lage, Ihnen eine anständige Antwort zu geben, tut mir leid.

Weitere Informationen zu diesem Thema finden Sie unter http://security.stackexchange.com . dieser Beitrag

Ja, Kryptografie ist auf einer virtuellen Maschine in den meisten Fällen weniger sicher als auf einem "echten" Server.

Letztere können zumindest Entropie von einer tatsächlichen Hardware sammeln. Tatsächlich ist der Betrieb eines HW-Teils in den meisten Fällen an ein physikalisches Phänomen gebunden, das immer kleinen Schwankungen unterworfen ist, die von allen Seiten zufällig sind. Da Server in der Regel sehr lange ohne Zurücksetzen ausgeführt werden, ist der resultierende Entropiepool möglicherweise von ausreichender Qualität.

Virtuelle Maschinen leiden unter drei Problemen.

1. Die Hardware, die sie sehen, ist nicht real und wird daher kaum von physikalischen Phänomenen beeinflusst. Sie werden in der Lage sein, Entropie viel langsamer zu sammeln.
2. VMs werden sehr viel häufiger zurückgesetzt als echte Server und haben möglicherweise nicht einmal genügend Zeit, um genügend Entropie zu sammeln (weshalb es sinnvoll ist, den aktuellen Entropiezustand beim Herunterfahren zu speichern und ihn beim Neustart zum Füttern des Entropiepools zu verwenden).
3. Während ein realer Server möglicherweise eine gewisse Chance hat, festzustellen, wann es sich um einen fehlerhaften Entropiepool handelt, funktioniert die virtuelle Maschine einfacher, wenn der Entropiepool als gut eingestuft wird (da er von HW erfasst wurde, ohne jedoch zu wissen, dass dies der Fall ist) nicht real), wohingegen es eigentlich schlecht ist.

Die beste Lösung ist, die VM einfach aufgeben zu lassen und zu erkennen, dass die HW, die sie sieht, eine schlechte Entropiequelle ist. Richten Sie dann einen lokalen Netzwerkdienst für die Verteilung hochwertiger Entropie ein (siehe Entropy Broker ). Der "Entropie-Server" kann Zufälligkeiten aus allgemeiner Hardware (in diesem Fall muss er ausreichend lange arbeiten und ein anständiges Betriebssystem haben) oder aus spezifischer Krypto-Hardware (einem TPM-Chip, einem VIA-Vorhängeschloss-Chip usw.) extrahieren.

Eine VM einen solchen Dienst verwenden kann sogar mehr sicher (verschlüsselt weise) als eine „echte“ Server, der gerade gestartet hat.