NIST SP 800-90A: DRBG-Standards

Kryptografische Operationen benötigen hochwertige Zufallszahlen: zur Schlüsselgenerierung, für Nonces, IVs, Salts und Sitzungstokens. Echte Zufallszahlengeneratoren (TRNGs) gewinnen Entropie aus physikalischen Quellen (Hardware-Rauschen, Interrupts, thermisches Rauschen), sind jedoch langsam und nicht immer verfügbar — insbesondere in virtuellen Maschinen oder während der frühen Boot-Phase. Deterministische Zufallsbitgeneratoren (DRBGs) lösen dieses Problem: Ein DRBG wird mit einer kleinen Menge echter Entropie initialisiert und verwendet einen kryptografischen Algorithmus, um daraus einen großen Strom pseudozufälliger Bits zu erzeugen, die für einen Angreifer rechnerisch nicht von echten Zufallsbits zu unterscheiden sind. NIST SP 800-90A definiert drei zugelassene DRBG-Mechanismen, die praktisch in allen modernen kryptografischen Implementierungen verwendet werden.

Ein DRBG arbeitet mit drei grundlegenden Operationen. Instanziieren: den internen Zustand des DRBG mithilfe von entropy_input (aus einer Entropiequelle), einer Nonce (einem einmalig verwendeten Wert zur Sicherstellung der Eindeutigkeit) und optional einer personalization_string (einem anwendungsspezifischen Kontext) initialisieren. Generieren: die angeforderte Anzahl pseudozufälliger Bits erzeugen und den internen Zustand aktualisieren, um Backtracking zu verhindern. Reseeding: frische Entropie in den DRBG-Zustand einbringen, um Vorhersagewiderstand zu gewährleisten — nach dem Reseeding kann selbst ein Angreifer, der den vorherigen Zustand kannte, zukünftige Ausgaben nicht vorhersagen. NIST legt für alle drei DRBG-Typen maximale Generierungsintervalle (reseed_interval) fest: 2^48 Anforderungen vor einem obligatorischen Reseeding.

NIST SP 800-90A definiert vier Sicherheitsstufen: 112, 128, 192 und 256 Bit. Die Sicherheitsstärke bestimmt die bei der Instanziierung erforderliche Mindestentropie und die Qualität der erzeugten Ausgaben. Für eine Sicherheit von 128 Bit muss die Entropieeingabe mindestens 128 Bit Entropie liefern. Der Zusammenhang lautet: security_strength Entropiebits -> DRBG-Ausgabe, die für einen Angreifer mit 2^security_strength Operationen rechnerisch nicht von Zufall zu unterscheiden ist. Die Wahl der Schlüssellänge (AES-128 gegenüber AES-256) und des Hashes (SHA-256 gegenüber SHA-512) muss so erfolgen, dass die gewünschte Sicherheitsstärke erreicht oder überschritten wird. Eine Überdimensionierung (SHA-512 für 128-Bit-Sicherheit) ist sicher, aber ineffizient; eine Unterdimensionierung gefährdet die Sicherheit.

Hash_DRBG verwaltet zwei Zustandswerte: V (einen Wert, der die Ausgabe erzeugt) und C (eine Konstante, die während der Generierung addiert wird). Generieren: hash_gen erzeugt Bits durch Iteration von H(0x01 || V), H(0x01 || V+1), ... , bis genügend Ausgabe verfügbar ist; anschließend wird V mit V = V + H(0x03 || V) + C + reseed_counter aktualisiert. Reseeding: Hash_df (Hash-Ableitungsfunktion) kombiniert den aktuellen Wert V mit frischer Entropie, um neue Werte für V und C zu erzeugen. Hash_DRBG ist einfach zu implementieren und lässt sich leicht sicherheitsanalytisch untersuchen, wodurch es für ressourcenbeschränkte Umgebungen geeignet ist. NIST empfiehlt die Instanziierung mit SHA-256 oder SHA-512. Hash_DRBG wird in Java's SHA1PRNG (älter) und im veralteten DRBG von OpenSSL verwendet.

HMAC_DRBG verwaltet den Zustand (Schlüssel K, Wert V). Generieren: V = HMAC(K, V) wird iteriert, bis genügend Ausgabe erzeugt wurde; anschließend werden K = HMAC(K, V || 0x00) und V = HMAC(K, V) berechnet. Aktualisieren: additional_input wird übernommen und K und V werden mithilfe von HMAC-Operationen neu initialisiert. HMAC_DRBG verfügt über einen klaren Sicherheitsbeweis, der auf der Sicherheit von HMAC beruht (PRF-Annahme für HMAC). Es ist der am häufigsten empfohlene DRBG: OpenSSL (seit 1.1.1), mbedTLS, wolfSSL und die meisten TLS-Stacks verwenden HMAC_DRBG. Die HMAC-Konstruktion sorgt für eine integrierte Durchmischung zwischen aufeinanderfolgenden Aufrufen, wodurch Backtracking-Angriffe selbst bei einer teilweisen Offenlegung des Zustands schwieriger werden.

CTR_DRBG verwendet eine Blockchiffre (AES) im Zählermodus. Zustand: Schlüssel K und Zähler V. Generieren: aufeinanderfolgende Zählerwerte E(K, V), E(K, V+1), ... werden verschlüsselt und V wird erhöht. Aktualisieren: Block_Cipher_df leitet aus additional_input neue Werte für K und V ab. CTR_DRBG ist der schnellste DRBG — die Hardwarebeschleunigung durch AES-NI macht ihn auf modernen Prozessoren um Größenordnungen schneller als hashbasierte DRBGs. Er ist der Standard-DRBG in Windows CNG (CryptGenRandom verwendet CTR_DRBG mit AES-256), in OpenSSL 3.0 (Standard) und im Linux-Kernel-RNG (getrandom-Systemaufruf). Die Sicherheit von CTR_DRBG beruht darauf, dass AES eine pseudozufällige Permutation ist, was durch jahrzehntelange Analysen umfassend gestützt wird.

Vorhersagewiderstand ist eine Eigenschaft, bei der die DRBG-Ausgabe selbst für einen Angreifer unvorhersagbar bleibt, der den DRBG-Zustand zuvor kompromittiert hat, sofern durch Reseeding frische Entropie eingemischt wird. Ein DRBG mit prediction_resistance_flag=true ruft vor jedem Generate-Aufruf die Entropiequelle auf, um frische Entropie einzubringen. Ohne Vorhersagewiderstand ermöglicht eine Kompromittierung des Zustands zum Zeitpunkt T die Berechnung aller zukünftigen Ausgaben (die Vorwärtssicherheit ist gebrochen). Rückwärtssicherheit (auch Backtracking-Resistenz genannt) bedeutet, dass vergangene Ausgaben selbst bei Kenntnis des aktuellen Zustands nicht vorhergesagt werden können — HMAC_DRBG und CTR_DRBG erreichen dies durch ihre Aktualisierungsschritte, die nach jedem Generate-Aufruf einen neuen Schlüssel aus dem aktuellen Zustand ableiten.

SP 800-90A spezifiziert die DRBG-Algorithmen, nicht jedoch die Entropiequelle. SP 800-90B definiert Anforderungen an Entropiequellen: Hardware-Rauschquellen müssen charakterisiert und validiert werden, Entropieschätzungen müssen konservativ sein und Gesundheitstests müssen Ausfälle der Entropiequelle erkennen. SP 800-90C legt fest, wie Entropiequellen mit DRBGs zu vollständigen Zufallsbitgeneratoren kombiniert werden. Typische Entropiequellen sind: CPU RDRAND/RDSEED (Hardware-RNGs, die seit 2012 auf Intel-/AMD-CPUs verfügbar sind), Betriebssystementropie (/dev/urandom unter Linux, BCryptGenRandom unter Windows), Hardware-Sicherheitsmodule, der TPM-2.0-RNG und Umgebungsrauschen (Festplatten-Timing, Netzwerk-Jitter). Bedingungen mit geringer Entropie (virtuelle Maschinen, frühe Boot-Phase) erfordern besondere Maßnahmen, um schwache Seeds zu vermeiden.

FIPS 140-3 (der aktuelle Standard für die Validierung kryptografischer Module) schreibt NIST-SP-800-90A-DRBGs für die gesamte Zufallszahlenerzeugung innerhalb zertifizierter Module vor. Das Modul muss: einen zugelassenen DRBG (Hash, HMAC oder CTR) verwenden, ihn aus einer zugelassenen Entropiequelle seeden, die die Anforderungen von SP 800-90B erfüllt, Einschalt-Selbsttests (POST) zur Überprüfung des DRBG-Betriebs durchführen, kontinuierliche RNG-Tests (CRNGT) implementieren, die auf null oder eins festhängende Entropiefehler erkennen, und ein Reseeding unterstützen, sobald die Entropiequelle verfügbare Entropie meldet. HSMs (Thales Luna, AWS CloudHSM, Utimaco), TLS-Beschleunigerkarten und Netzwerkverschlüsselungsgeräte erfordern häufig FIPS-140-3-validierte Module, was die Verbreitung von SP 800-90A vorantreibt.

Moderne Betriebssysteme verwalten einen DRBG auf Kernel-Ebene, der aus Hardware-Entropiequellen initialisiert wird. Linux verwendet einen auf ChaCha20 basierenden DRBG (seit Kernel 5.17 als Ersatz für das ältere Fortuna-ähnliche Design), der aus RDRAND, Interrupts sowie Festplatten- und Netzwerkereignissen initialisiert wird. /dev/urandom liefert DRBG-Ausgaben und blockiert nach der anfänglichen Initialisierung nicht. /dev/random blockiert, bis ausreichend Entropie verfügbar ist (ein Legacy-Verhalten, das in neueren Kerneln größtenteils entfernt wurde). Der Systemaufruf getrandom(2) ist die moderne Schnittstelle und blockiert nur während des frühen Systemstarts, bevor der DRBG initialisiert wurde. Windows verwendet CTR_DRBG (AES-256) im Kernel-RNG, der aus dem TPM und Hardwareereignissen initialisiert wird. Anwendungen sollten den DRBG des Betriebssystems über High-Level-APIs verwenden, anstatt eigene DRBGs aus Zeitstempeln oder PIDs zu initialisieren.

In der Praxis entstehen DRBG-Schwachstellen eher durch Implementierungsfehler als durch Schwächen des Algorithmus. (1) Unzureichende Initialisierung: Ein Seed, der nur aus dem aktuellen Zeitstempel oder der PID besteht, ist für Angreifer erratbar. (2) Fork-Blindheit: Wenn ein Prozess einen Fork ausführt, teilen sich übergeordneter und untergeordneter Prozess denselben DRBG-Zustand – sie erzeugen identische Zufallszahlen. Abhilfe: nach dem Fork neu initialisieren (pthread_atfork oder ein expliziter getrandom-Aufruf). (3) Wiederverwendung von VM-Snapshots: Wird ein VM-Snapshot wiederhergestellt, kehrt der DRBG-Zustand in den Zustand des Snapshots zurück und erzeugt bereits zuvor ausgegebene Werte erneut. Abhilfe: beim Start der VM eindeutige Entropie einspeisen (VIRTIO RNG). (4) Fehlgeschlagene Gesundheitsprüfungen stillschweigend ignorieren: Ein DRBG, der nach dem Erkennen eines Entropiefehlers weiterhin Werte erzeugt, liefert für Angreifer vorhersagbare Ausgaben. (5) Nonces über mehrere DRBG-Instanzen hinweg wiederverwenden.

NIST SP 800-90A definiert drei zugelassene DRBG-Mechanismen: Hash_DRBG (iterative Hash-Berechnung, einfach), HMAC_DRBG (HMAC-basiert, mit einem klaren Sicherheitsbeweis, weit verbreitet) und CTR_DRBG (AES im Zählermodus, dank AES-NI am schnellsten, Standard in Windows/OpenSSL). Alle verwenden denselben Lebenszyklus aus Instantiate/Generate/Reseed mit einer reseed_interval-Grenze von 2^48. Die Sicherheitsstärke (112–256 Bit) bestimmt die Anforderungen an die Entropie. Prediction Resistance erfordert eine Neuinitialisierung vor jedem Generate-Aufruf. FIPS 140-3 schreibt DRBGs nach SP 800-90A zusammen mit Entropiequellen nach SP 800-90B vor. Fork-Blindheit, die Wiederverwendung von VM-Snapshots und unzureichende Initialisierung sind die wichtigsten Implementierungsprobleme in der Praxis.