Interna von Hash-DRBG, HMAC-DRBG und CTR-DRBG

Jeder der drei NIST-DRBG-Mechanismen verwaltet andere interne Zustandskomponenten, die den jeweiligen algorithmischen Ansatz widerspiegeln. Hash_DRBG speichert V (einen Seed in Hash-Länge) und C (eine aus V abgeleitete Konstante, die während der Ausgabegenerierung verwendet wird). HMAC_DRBG speichert den Schlüssel K (einen geheimen Schlüssel in Hash-Länge) und den Wert V (einen Verkettungswert in Hash-Länge). CTR_DRBG speichert den Schlüssel K (einen AES-Schlüssel) und V (einen Zähler in Blocklänge). Alle drei verwalten einen reseed_counter, der die Generate-Aufrufe seit der letzten Initialisierung zählt. Die Zustandsgröße bestimmt den Speicherbedarf: Hash/HMAC_DRBG mit SHA-256 verwenden 64 Byte Zustand; CTR_DRBG mit AES-256 verwendet 48 Byte (32-Byte-Schlüssel + 16-Byte-Zähler).

Hash_DRBG verwendet Hash_df (Hash-Ableitungsfunktion), um aus Entropiematerial den Zustand abzuleiten. Hash_df(input_string, no_of_bits_to_return) führt folgende Iteration aus: Für counter = 1, 2, ... wird H(counter || no_of_bits || input_string) berechnet und aneinandergehängt, bis genügend Bits erzeugt wurden. Dadurch werden kurze Entropieeingaben zu Seeds in Zustandsgröße erweitert. Während Generate berechnet die Ausgabefunktion W = H(0x03 || V), wobei das Präfix 0x03 diese Verwendung von anderen Hash-Verwendungen unterscheidet. Die Ausgabeschleife lautet: data = H(0x01 || V); V = V + 1; für weitere Ausgaben wiederholen. Nach der Generierung wird V aktualisiert: V = V + H(0x03 || V) + C + reseed_counter. Die Domänentrennung durch Präfixbytes (0x01, 0x03) verhindert, dass die Ausgabe der Generierungsphase mit der Zustandsaktualisierungsphase verwechselt wird.

Die Update-Funktion von HMAC_DRBG ist der Kern aller Zustandsübergänge. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Wenn provided_data nicht leer ist: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Diese zweistufige Aktualisierung stellt sicher, dass sowohl der neue Schlüssel als auch der neue Wert vom vorherigen Zustand und von jeder neuen Entropie abhängen. Generate: V = HMAC(K, V) wiederholen und die Ergebnisse an die Ausgabe anhängen, bis genügend Bits erzeugt wurden; anschließend Update mit additional_input aufrufen, um den Zustand weiterzuentwickeln. Die Sicherheit von HMAC_DRBG lässt sich auf die Annahme reduzieren, dass HMAC eine sichere PRF ist: Ein Angreifer, der die HMAC-Ausgabe nicht von Zufallswerten unterscheiden kann, kann auch die DRBG-Ausgabe nicht von Zufallswerten unterscheiden.

CTR_DRBG verwendet Block_Cipher_df (Ableitungsfunktion), um Seed-Material in ein Schlüssel-/Zählerformat zu überführen. Block_Cipher_df(input_string, no_of_bits) verwendet eine BCC-Konstruktion (Block Cipher Chaining): Dabei wird AES-CBC iterativ auf Eingabeteile angewendet, um eine Ausgabe mit der erforderlichen Länge zu erzeugen. Die Ableitungsfunktion ist erforderlich, um Eingaben variabler Länge zu verarbeiten und eine Domänentrennung bereitzustellen. CTR_DRBG ohne Ableitungsfunktion (für FIPS-Tests mit exakt formatierten Eingaben zulässig) ist schneller, reagiert aber empfindlicher auf die Anforderungen an das Eingabeformat. Die Generate-Schleife lautet: temp = E(K, V); V = V + 1; temp an die Ausgabe anhängen. Update: K || V = Block_Cipher_df(V || additional_input, seedlen); XOR mit dem aktuellen Schlüssel anwenden.

Die Leistung unterscheidet sich zwischen den DRBG-Typen erheblich. Auf einer modernen x86_64-CPU mit AES-NI erreicht CTR_DRBG (AES-256) ungefähr 5–10 GB/s bei der Erzeugung pseudozufälliger Ausgaben – die AES-NI-Anweisung macht die AES-Berechnung nahezu kostenlos. HMAC_DRBG (SHA-256) erreicht ungefähr 200–400 MB/s – SHA-256 ist schnell, aber nicht im gleichen Maße hardwarebeschleunigt. Hash_DRBG (SHA-256) erreicht ungefähr 100–300 MB/s. Für die Erzeugung großer Mengen von Schlüsseln oder als Ersatz für Stromchiffren ist CTR_DRBG deutlich schneller. Bei Anwendungen mit geringem Durchsatz (Erzeugung von Sitzungsschlüsseln, Ableitung von Nonces) ist der Leistungsunterschied unbedeutend. OpenSSL 3.0 verwendet aus diesem Grund standardmäßig CTR_DRBG (AES-256).

Bei der Instanziierung akzeptieren alle drei DRBGs einen optionalen personalization_string, der mit der Entropieeingabe vermischt wird, um die DRBG-Instanz eindeutig zu machen. Dadurch erzeugen zwei gleichzeitig instanziierte DRBGs mit derselben Entropie nicht dieselbe Ausgabe, sondern unterscheiden sich aufgrund des Personalisierungsstrings. Empfohlene Personalisierungsstrings: Anwendungskennung + Prozess-ID + Thread-ID + Zeitstempel + Hardwarekennung. Selbst wenn zwei VMs dieselbe Entropie erhalten (ein Problem bei Cloud-VM-Snapshots), sorgen unterschiedliche Personalisierungsstrings für unterschiedliche DRBG-Datenströme. NIST SP 800-90C empfiehlt, immer einen Personalisierungsstring zu verwenden. Der nonce-Parameter erfüllt einen ähnlichen Zweck: ein eindeutiger kurzer Wert, der sicherstellt, dass keine zwei Instanziierungen im selben Zustand beginnen.

Alle drei DRBGs unterstützen bei Generate-Aufrufen einen additional_input-Parameter. Dadurch kann der Aufrufer zusätzlichen Kontext oder zusätzliche Entropie in einen einzelnen Generate-Aufruf einbringen, ohne eine vollständige Neuinitialisierung durchzuführen. Mögliche Verwendungen: (1) Entropie pro Anfrage aus einer sekundären Entropiequelle einbringen; (2) Anwendungskontext (Anfrage-ID, Zeitstempel) bereitstellen, um erzeugte Werte an ihre Verwendung zu binden; (3) optional Prediction Resistance ermöglichen, indem frische Entropie aus dem Betriebssystem eingebracht wird. additional_input wird vor der Ausgabegenerierung in den DRBG-Zustand eingemischt. Liefert additional_input echte Entropie, verbessert es die Sicherheit, ohne eine formale Neuinitialisierung zu erfordern, die die Schnittstelle der Entropiequelle und den damit verbundenen Overhead umfasst.

Nachdem ein DRBG deinitialisiert wurde (oder beim Wechsel zu einer neuen Instanz), muss der interne Zustand sicher auf null gesetzt werden. Die Zustände V und C (Hash_DRBG), K und V (HMAC/CTR_DRBG) sowie alle temporären Arbeitsvariablen müssen mit Nullen überschrieben werden. Dies wird als explizites Nullsetzen (explicit zeroization) bezeichnet und ist in FIPS-140-3-Modulen vorgeschrieben. Verwenden Sie in C-Code explicit_bzero() oder SecureZeroMemory() – ein compileroptimiertes memset kann als Dead-Store-Optimierung entfernt werden, sodass Schlüsselmaterial im Speicher verbleibt. Rusts zeroize-Crate und ähnliche sprachspezifische Lösungen erledigen dies portabel. Die sichere Vernichtung von Schlüsseln ist wichtig, wenn Speicherabbilder, Cold-Boot-Angriffe oder Tools zur Prozessinspektion auf verbliebene Zustandsdaten zugreifen könnten.

NIST stellt Testvektoren des Cryptographic Algorithm Validation Program (CAVP) für alle DRBGs nach SP 800-90A bereit. Testtypen: (1) Known Answer Tests (KATs) – bei einer festen Entropieeingabe, einem Nonce und einem Personalisierungsstring wird geprüft, ob die erzeugte Ausgabe mit vorberechneten Werten übereinstimmt. (2) Reseed-Tests – prüfen den DRBG-Zustand nach einer Neuinitialisierung. (3) PR-Tests (Prediction Resistance) – prüfen, ob die Anforderung prediction_resistance=true nach dem Einbringen frischer Entropie die korrekte Ausgabe erzeugt. Eine CAVP-Validierung ist für die Einreichung nach FIPS 140-3 erforderlich. Open-Source-Bibliotheken (OpenSSL, mbedTLS) enthalten CAVP-Testvektoren in ihren Regressionstests, um Regressionen in DRBG-Implementierungen zu erkennen.

DRBG-Implementierungen sind über das algorithmische Sicherheitsmodell hinaus mit subtilen Seitenkanalrisiken konfrontiert. Cache-Timing-Angriffe auf AES (in CTR_DRBG ohne AES-NI) können Rundenschlüsselmaterial offenlegen; AES-NI verhindert dies, indem die Berechnung in Registern ohne Tabellenzugriffe erfolgt. HMAC_DRBG verwendet intern HMAC, das eine konstante Laufzeit aufweist, wenn die zugrunde liegende SHA-256-Implementierung konstante Laufzeit hat – SHA-256 gilt im Allgemeinen als laufzeitkonstant, da es keine datenabhängigen Verzweigungen gibt. Physische Seitenkanäle (Leistungsanalyse, elektromagnetische Abstrahlung) gegen DRBG-erzeugende Hardware sind bei Smartcards und IoT-Geräten ein Problem und werden durch maskierte Implementierungen behandelt. Beim Zustandskopien-Angriff gilt: Wenn ein Angreifer den DRBG-Zustand über eine Schwachstelle zur Speicheroffenlegung (Heartbleed-ähnlich) auslesen kann, ist jede künftige Ausgabe bis zur nächsten Neuinitialisierung mit frischer Entropie kompromittiert.

Wenn ein DRBG-Zustand kompromittiert wurde (beispielsweise durch eine Schwachstelle zur Speicheroffenlegung), ist für die Wiederherstellung Folgendes erforderlich: (1) Die Kompromittierung erkennen – Lecks des DRBG-Zustands sind nicht von selbst erkennbar; externes Monitoring oder Integritätsprüfungen sind erforderlich. (2) Eine Neuinitialisierung mit frischer Entropie aus einer vertrauenswürdigen Quelle durchführen, die nicht an der Kompromittierung beteiligt war. (3) Sämtliches kryptografisches Material neu schlüsseln, das vom kompromittierten DRBG abgeleitet wurde (Sitzungsschlüssel und Signaturschlüssel, die seit der letzten erfolgreichen Neuinitialisierung erzeugt wurden). (4) Bei Softwareimplementierungen stellt ein Neustart des Prozesses eine saubere neue DRBG-Instanziierung bereit. SP 800-90C empfiehlt verkettete Entropiequellen – wenn eine Quelle kompromittiert ist, bietet die Kombination weiterhin Sicherheit, sofern die andere Quelle echte Entropie liefert.

Welcher DRBG-Mechanismus ist auf modernen CPUs bei der Erzeugung großer Mengen pseudozufälliger Ausgaben am schnellsten?

Hash_DRBG verwendet iterative Hash-Berechnung mit Hash_df zur Ableitung und erzeugt die Ausgabe in Schleifen mit H(0x01 || V). HMAC_DRBG verwendet HMAC als PRF mit einer zweistufigen Update-Funktion (zuerst der Schlüssel, dann der Wert), die eine klare Sicherheitsreduktion ermöglicht. CTR_DRBG verwendet AES im Zählermodus mit Block_Cipher_df und erreicht auf Hardware mit AES-NI 5–10 GB/s. Alle akzeptieren bei der Instanziierung personalization_string für die Eindeutigkeit der Instanz und bei jedem Generate-Aufruf additional_input zur Bindung an den Kontext. CAVP-Testvektoren validieren die Implementierungen. Der Zustand muss nach der Verwendung sicher auf null gesetzt werden. Eine Kompromittierung des Zustands erfordert eine Neuinitialisierung mit frischer Entropie und eine neue Schlüsselerzeugung für das abgeleitete Material.