/dev/zufällig - /dev/random
In Unix-ähnlichen Betriebssystemen , / dev / random , / dev / urandom und / dev / arandom sind spezielle Dateien , die als dienen Pseudo - Zufallszahlengeneratoren . Sie ermöglichen den Zugriff auf Umgebungsgeräusche, die von Gerätetreibern und anderen Quellen erfasst werden . /dev/random wird normalerweise blockiert, wenn weniger Entropie verfügbar war als angefordert; In jüngerer Zeit (siehe unten, verschiedene Betriebssysteme unterscheiden sich) blockiert es normalerweise beim Start, bis genügend Entropie gesammelt wurde, und entsperrt dann dauerhaft. Das /dev/urandom- Gerät war normalerweise nie ein blockierendes Gerät, selbst wenn der Pseudozufallszahlengenerator-Seed seit dem Booten nicht vollständig mit Entropie initialisiert wurde. /dev/arandom blockiert nach dem Booten, bis der Seed sicher mit genügend Entropie initialisiert wurde, und blockiert dann nie wieder. Nicht alle Betriebssysteme implementieren die gleichen Methoden für /dev/random und /dev/urandom und nur wenige bieten /dev/arandom .
Beispiel
> hexdump -C -n 8 /dev/random
0000000 79 5d 13 c2 b4 fe ca d7 |y].´þÊ×|
> hexdump -C -n 8 /dev/random
0000000 bd f1 6d 48 10 f8 25 3c |..mH..%<|
Dieses Shell-Skript ist ein zufällig druckbarer Zeichengenerator, der leicht voreingenommen ist:
#!/bin/sh
printf " \$ti";
read pngs</dev/urandom;
pc=1;
while [ $pc -le $(((${#pngs}%5)+8)) ]; do
read s s2</dev/urandom;
printf "\n\n";
printf `printf "\\%o" "$(((${#s}%26)+65))"`;
printf `printf "\\%o" "$(((${#s2}%26)+97))"`;
l=${#s};
i=1;
while [ $i -le $l ]; do
c=`printf %c "${s%${s#?}}"`;
s=${s#?};
cc=`printf %d \`printf "\047$c" 2>&-\``;
printf `printf "\\%o" "$((((cc+i)%95)+32))"`;
i=$((i+1));
done;
pc=$((pc+1));
done;
Linux
Die Zufallszahlengenerierung im Kernel-Space wurde 1994 von Theodore Ts'o zum ersten Mal für Linux implementiert . Bei der Implementierung wurden sichere Hashes anstelle von Chiffren verwendet , um Exportbeschränkungen für Kryptografie zu vermeiden , die bei der ursprünglichen Entwicklung des Generators galten. Die Implementierung wurde auch unter der Annahme entworfen, dass sich ein bestimmter Hash oder eine bestimmte Verschlüsselung möglicherweise als schwach erweisen könnte, und so ist das Design angesichts solcher Schwächen dauerhaft. Eine schnelle Wiederherstellung nach einer Poolkompromittierung wird nicht als Voraussetzung angesehen, da die Anforderungen für eine Poolkompromittierung für viel einfachere und direktere Angriffe auf nicht verwandte Teile des Betriebssystems ausreichen.
In der Implementierung von Ts'o hält der Generator eine Schätzung der Anzahl von Rauschbits im Entropiepool . Aus diesem Entropiepool werden Zufallszahlen erzeugt. Beim Lesen gibt das /dev/random- Gerät nur zufällige Bytes innerhalb der geschätzten Anzahl von Rauschbits im Entropiepool zurück. Wenn der Entropie - Pool leer ist, liest aus / dev / random Willen Block bis zusätzlicher Umgebungslärm gesammelt. Die Absicht besteht darin, als kryptographisch sicherer Pseudozufallszahlengenerator zu dienen , der eine Ausgabe mit einer möglichst großen Entropie liefert. Dies wird von den Autoren zur Verwendung bei der Generierung kryptografischer Schlüssel für einen hochwertigen oder langfristigen Schutz vorgeschlagen.
Ein Gegenstück zu /dev/random ist /dev/urandom ("unbegrenzte"/nicht blockierende Zufallsquelle), die den internen Pool wiederverwendet, um mehr pseudozufällige Bits zu erzeugen. Dies bedeutet, dass der Aufruf nicht blockiert wird, aber die Ausgabe möglicherweise weniger Entropie enthält als der entsprechende Lesevorgang aus /dev/random . Während /dev/urandom immer noch als Pseudozufallszahlengenerator gedacht ist, der für die meisten kryptografischen Zwecke geeignet ist, weisen die Autoren der entsprechenden Manpage darauf hin, dass es theoretisch einen noch unveröffentlichten Angriff auf den von /dev/urandom verwendeten Algorithmus geben könnte , und dass Benutzer, die über einen solchen Angriff besorgt sind, stattdessen /dev/random verwenden sollten. Es ist jedoch unwahrscheinlich, dass ein solcher Angriff stattfindet, da der Entropiepool, sobald er unvorhersehbar ist, die Sicherheit nicht durch eine reduzierte Anzahl von Bits verliert.
Es ist auch möglich nach /dev/random zu schreiben . Auf diese Weise kann jeder Benutzer zufällige Daten in den Pool mischen. Nicht-zufällige Daten sind harmlos, da nur ein privilegierter Benutzer das zur Erhöhung der Entropieschätzung benötigte ioctl ausgeben kann . Die aktuelle Menge der Entropie und die Größe der Entropiepool Linux - Kernel, die beide in Bits gemessen, sind in / proc / sys / kernel / random / und kann durch den Befehl angezeigt werden cat /proc/sys/kernel/random/entropy_avail
und cat /proc/sys/kernel/random/poolsize
jeweils.
Gutterman, Pinkas & Reinman veröffentlichten im März 2006 eine detaillierte kryptografische Analyse des Linux-Zufallszahlengenerators, in der sie mehrere Schwachstellen beschreiben. Das vielleicht schwerwiegendste Problem, von dem sie berichten, ist bei eingebetteten oder Live-CD- Systemen wie Routern und festplattenlosen Clients , bei denen der Boot-Zustand vorhersehbar ist und die verfügbare Entropie aus der Umgebung begrenzt sein kann. Für ein System mit nichtflüchtigem Speicher empfehlen sie, beim Herunterfahren einen Teil des RNG-Zustands zu speichern, damit er beim nächsten Neustart in den RNG-Zustand aufgenommen werden kann. Im Falle eines Routers, für den der Netzwerkverkehr die primäre verfügbare Entropiequelle darstellt, stellen sie fest, dass das Speichern des Zustands über Neustarts hinweg "potenzielle Angreifer erfordern würde, entweder den gesamten Netzwerkverkehr abzuhören", sobald der Router zum ersten Mal in Betrieb genommen wird, oder direkter Zugriff auf den internen Zustand des Routers. Dieses Problem sei besonders kritisch im Fall eines drahtlosen Routers, dessen Netzwerkverkehr aus der Ferne erfasst werden kann und der den RNG möglicherweise verwendet, um Schlüssel für die Datenverschlüsselung zu generieren.
Der Linux-Kernel bietet Unterstützung für mehrere Hardware-Zufallszahlengeneratoren , falls diese installiert sein sollten. Die Rohausgabe eines solchen Geräts kann von /dev/hwrng abgerufen werden .
Ab Linux-Kernel 3.16 mischt der Kernel selbst Daten von Hardware-Zufallszahlengeneratoren in /dev/random auf einer gleitenden Skala basierend auf der definierbaren Entropie-Schätzqualität des HWRNG. Das bedeutet, dass kein Userspace-Daemon wie rngd von rng-tools benötigt wird, um diese Aufgabe zu erledigen. Mit Linux-Kernel 3.17+ wurde der VirtIO RNG so modifiziert, dass er eine Standardqualität von über 0 hat und ist als solcher derzeit der einzige HWRNG, der standardmäßig in /dev/random gemischt wird.
Der Entropiepool kann durch Programme wie timer_entropyd , haveged , randomsound etc. verbessert werden . Mit rng-tools können Hardware-Zufallszahlengeneratoren wie Entropy Key etc. nach /dev/random schreiben . Die eingefleischten Tests Programme dieharder , eingefleischten und ent können diese Zufallszahlengeneratoren testen.
Im Januar 2014 veröffentlichte Daniel J. Bernstein eine Kritik, wie Linux verschiedene Entropiequellen mischt. Er skizziert einen Angriff, bei dem eine Entropiequelle, die in der Lage ist, die anderen Entropiequellen zu überwachen, ihre Ausgabe modifizieren könnte, um die Zufälligkeit der anderen Entropiequellen aufzuheben. Betrachten Sie die Funktion, bei der H eine Hash-Funktion ist und x , y und z Entropiequellen sind, wobei z die Ausgabe eines CPU-basierten bösartigen HRNG Z ist:
- Z erzeugt einen Zufallswert von r .
- Z berechnet .
- Wenn die Ausgabe von gleich dem gewünschten Wert ist, wird r als z ausgegeben .
- Ansonsten ab 1 wiederholen.
Bernstein schätzte, dass ein Angreifer 16 Mal wiederholen müsste , um DSA und ECDSA zu kompromittieren. Dies ist möglich, weil Linux H fortlaufend neu sät, anstatt einen einzelnen hochwertigen Seed zu verwenden.
Im Oktober 2016, mit der Veröffentlichung der Linux-Kernel- Version 4.8, wurde /dev/urandom des Kernels auf eine ChaCha20- basierte Implementierung des kryptografischen Pseudozufallszahlengenerators (CPRNG) von Theodore Ts'o umgestellt , basierend auf Bernsteins angesehenem Stream Chiffre ChaCha20 .
Im Jahr 2020 blockiert die Linux-Kernel-Version 5.6 /dev/random nur, wenn der CPRNG nicht initialisiert wurde. Nach der Initialisierung verhalten sich /dev/random und /dev/urandom gleich.
FreeBSD
Das FreeBSD- Betriebssystem bietet einen /dev/urandom- Link zu /dev/random . Beide blockieren nur, bis sie richtig ausgesät sind. PRNG ( Fortuna ) von FreeBSD wird regelmäßig neu gesät und versucht nicht, die Entropie zu schätzen. Auf einem System mit geringer Netzwerk- und Festplattenaktivität erfolgt das erneute Seeding nach einem Bruchteil einer Sekunde.
OpenBSD
Seit OpenBSD 5.1 (1. Mai 2012) verwenden /dev/random und /dev/arandom einen auf RC4 basierenden Algorithmus , der jedoch aus Gründen des geistigen Eigentums in ARC4 umbenannt wurde. Während die Zufallszahlenerzeugung hier die auf verschiedene Weise gesammelte Systementropie verwendet, bietet der ARC4-Algorithmus eine Ausfallsicherheit, die sicherstellt, dass ein schneller und qualitativ hochwertiger Pseudo-Zufallszahlenstrom bereitgestellt wird, selbst wenn sich der Pool in einem Zustand niedriger Entropie befindet. Das System verwendet automatisch Hardware-Zufallszahlengeneratoren (wie sie auf einigen Intel PCI-Hubs bereitgestellt werden), sofern diese über das OpenBSD Cryptographic Framework verfügbar sind .
Ab OpenBSD 5.5 (1. Mai 2014) arc4random()
verwendet der für die zufälligen Geräte von OpenBSD verwendete Aufruf nicht mehr ARC4, sondern ChaCha20 (der arc4random- Name könnte als A Replacement Call for Random angesehen werden ).
Die Implementierung der Legacy- API von NetBSDarc4random()
wurde ebenfalls auf ChaCha20 umgestellt.
macOS, iOS und andere Apple-Betriebssysteme
Alle Apple-Betriebssysteme sind seit mindestens Dezember 2019, möglicherweise früher, zu Fortuna umgezogen. Es basiert auf SHA-256 . Es werden mehrere Entropiequellen wie der Secure Enclave RNG, Boot-Phasen-Timing-Jitter, Hardware-Interrupt (Timing angenommen) verwendet. RDSEED/RDRAND wird auf Intel-basierten Macs verwendet, die es unterstützen. Seed-(Entropie-)Daten werden auch für nachfolgende Neustarts gespeichert.
Vor der Änderung verwendeten macOS und iOS 160-Bit- Yarrow basierend auf SHA-1 .
Es gibt keinen Unterschied zwischen /dev/random und /dev/urandom ; beide verhalten sich gleich.
Andere Betriebssysteme
/dev/random und /dev/urandom sind auch unter Solaris, NetBSD, Tru64 UNIX 5.1B, AIX 5.2 und HP-UX 11i v2 verfügbar. Wie bei FreeBSD implementiert AIX sein eigenes Yarrow-basiertes Design, jedoch verwendet AIX erheblich weniger Entropiequellen als die standardmäßige /dev/random- Implementierung und stoppt das Auffüllen des Pools, wenn es der Meinung ist, dass er genügend Entropie enthält.
Unter Windows NT wird eine ähnliche Funktionalität von ksecdd.sys bereitgestellt , aber das Lesen der speziellen Datei \Device\KsecDD funktioniert nicht wie unter UNIX. Die dokumentierten Methoden zum Generieren kryptografisch zufälliger Bytes sind CryptGenRandom und RtlGenRandom .
Obwohl DOS solche Funktionen nicht selbstverständlich bietet, gibt es einen Open-Source-Treiber eines Drittanbieters namens noise.sys , der ähnlich funktioniert, indem er zwei Geräte erstellt, RANDOM$ und URANDOM$ , die auch als /DEV/RANDOM$ . zugänglich sind und /DEV/URANDOM$ , auf die Programme für zufällige Daten zugreifen können.
Der Linux-Emulator Cygwin unter Windows bietet Implementierungen von /dev/random und /dev/urandom , die in Skripten und Programmen verwendet werden können.
EGD als Alternative
Ein Softwareprogramm namens EGD (Entropy Gathering Daemon) ist eine gängige Alternative für Unix-Systeme, die das Gerät /dev/random nicht unterstützen . Es handelt sich um einen User-Space- Daemon , der hochwertige kryptografische Zufallsdaten bereitstellt. Einige kryptografische Software wie OpenSSL , GNU Privacy Guard und der Apache HTTP Server unterstützen die Verwendung von EGD, wenn ein /dev/random- Gerät nicht verfügbar ist. OpenSSL hat die Unterstützung für den EGD-Daemon standardmäßig in OpenSSL 1.1.0 deaktiviert; Anwendungen sollten mithilfe des Präprozessormakros nach Unterstützung suchen.
OPENSSL_NO_EGD
EGD sammelt zufällige Entropie aus verschiedenen Quellen, verarbeitet sie, um Verzerrungen zu beseitigen und die kryptografische Qualität zu verbessern, und stellt sie dann über einen Unix-Domain-Socket (wobei /dev/egd-pool eine gängige Wahl ist) oder über einen TCP-Socket zur Verfügung . Die Entropie Versammlung in der Regel bringt regelmäßig Forking Attribute des Systems Subprozesse zu Abfrage , die wahrscheinlich häufig zu ändern und unberechenbar, wie die Überwachung CPU, I / O und Netzwerk - Nutzung sowie den Inhalt der verschiedenen Protokolldateien und temporäre Verzeichnisse .
Die Alternative PRNGD ist eine kompatible Pseudozufallsquelle.
EGD kommuniziert mit anderen Programmen, die Zufallsdaten benötigen, über ein einfaches Protokoll . Der Client verbindet sich mit einem EGD-Socket und sendet einen Befehl, der durch den Wert des ersten Oktetts identifiziert wird :
- Befehl 0: Abfrage der aktuell verfügbaren Entropiemenge. Der EGD-Daemon gibt eine 4-Byte-Zahl im Big-Endian- Format zurück, die die Anzahl der zufälligen Bytes darstellt, die derzeit ohne Verzögerung erfüllt werden können.
- Befehl 1: zufällige Bytes erhalten, keine Blockierung. Das zweite Byte in der Anfrage teilt EGD mit, wie viele zufällige Ausgabebytes es zurückgeben soll, von 1 bis 255. Wenn EGD nicht genügend Entropie hat, um die Anfrage sofort zu erfüllen, können weniger Bytes oder vielleicht keine Bytes zurückgegeben werden. Das erste Oktett der Antwort gibt an, wie viele zusätzliche Bytes, die die Zufallsdaten enthalten, unmittelbar in der Antwort folgen.
- Befehl 2: zufällige Bytes erhalten, blockieren. Das zweite Byte teilt EGD mit, wie viele zufällige Ausgabebytes es zurückgeben soll. Wenn die EGD nicht genügend Entropie hat, wartet sie, bis sie genug gesammelt hat, bevor sie reagiert. Im Gegensatz zu Befehl 1 beginnt die Antwort sofort mit zufälligen Bytes und nicht mit einem Längenoktett, da die Gesamtlänge der zurückgegebenen Daten nicht von der angeforderten Menge abweicht.
- Befehl 3: Entropie aktualisieren. Mit diesem Befehl kann der Client zusätzliche Entropie bereitstellen, die dem internen Pool von EGD hinzugefügt wird. Die nächsten zwei Bytes, interpretiert als 16-Bit-Big-Endian-Ganzzahl, geben an, wie viele Zufallsbits der Aufrufer vorgibt zu liefern. Das vierte Byte gibt an, wie viele zusätzliche Bytes an Quelldaten in der Anfrage folgen. Der EGD-Daemon kann sich in die empfangene Entropie einmischen und gibt nichts zurück.
Siehe auch
- CryptGenRandom – Das CSPRNG der Microsoft Windows-API
- /dev
- Entropieliefernde Systemaufrufe
- Fortuna-Algorithmus
- Hardware-Zufallszahlengenerator
- Standardstreams
Verweise
Externe Links
- Biege, Thomas (2006-11-06). "Analyse eines starken Pseudo-Zufallszahlengenerators durch Anatomisierung des Zufallszahlengeräts von Linux" (PDF) .
- Hühn, Thomas (2014). "Mythen über /dev/urandom" .