RDRAND - RDRAND
RDRAND(für "read random"; bekannt als Intel Secure Key Technology , früher bekannt als Bull Mountain ) ist eine Anweisung zum Zurückgeben von Zufallszahlen von einem Intel On-Chip- Hardware-Zufallszahlengenerator, der von einer On-Chip-Entropiequelle geimpft wurde. RDRANDist in Ivy Bridge- Prozessoren verfügbar und Teil der Intel 64- und IA-32- Befehlssatzarchitekturen . AMD hat im Juni 2015 Unterstützung für die Anweisung hinzugefügt.
Der Zufallszahlengenerator entspricht Sicherheits- und kryptografischen Standards wie NIST SP 800-90A , FIPS 140-2 und ANSI X9.82 . Intel beauftragte Cryptography Research Inc. außerdem im Jahr 2012 mit der Überprüfung des Zufallszahlengenerators, was zu dem Papier Analysis of Intels Ivy Bridge Digital Random Number Generator führte .
RDSEEDist RDRANDder entropieerzeugenden Hardware ähnlich und bietet Zugriff auf niedrigerer Ebene. Die RDSEEDGenerator- und Prozessorbefehle rdseedsind mit Intel Broadwell CPUs und AMD Zen CPUs verfügbar .
Überblick
Die CPUIDAnweisung kann sowohl auf AMD- als auch auf Intel- CPUs verwendet werden , um zu überprüfen, ob die RDRANDAnweisung unterstützt wird. Wenn ja, wird Bit 30 des ECX-Registers nach dem Aufrufen der CPUID-Standardfunktion gesetzt 01H. AMD-Prozessoren werden mit demselben Test auf die Funktion überprüft. RDSEEDBei Intel-CPUs kann die Verfügbarkeit auf ähnliche Weise überprüft werden. Falls RDSEEDunterstützt, wird das Bit 18 des EBX-Registers nach Aufruf der CPUID-Standardfunktion gesetzt 07H.
Der Opcode für RDRANDist 0x0F 0xC7, gefolgt von einem ModRM-Byte, das das Zielregister angibt und optional mit einem REX-Präfix im 64-Bit-Modus kombiniert wird.
Intel Secure Key ist Intels Name sowohl für die RDRANDAnweisung als auch für die zugrunde liegende Hardwareimplementierung des Zufallszahlengenerators (RNG), die während der Entwicklung den Codenamen "Bull Mountain" trug. Intel nennt seinen RNG einen "digitalen Zufallszahlengenerator" oder DRNG. Der Generator nimmt Paare von 256-Bit-Roh-Entropie-Samples, die von der Hardware-Entropiequelle generiert werden, und wendet sie auf einen Advanced Encryption Standard (AES) (im CBC-MAC- Modus)-Conditioner an, der sie auf ein einzelnes 256-Bit-konditioniertes Entropie-Sample reduziert. Ein deterministischer Zufallsbitgenerator namens CTR_DRBG , der in NIST SP 800-90A definiert ist, wird durch die Ausgabe des Konditionierers geimpft und liefert kryptographisch sichere Zufallszahlen an Anwendungen, die sie über den RDRANDBefehl anfordern . Die Hardware gibt maximal 511 128-Bit-Samples aus, bevor der Seed-Wert geändert wird. Die Verwendung der RDSEEDOperation ermöglicht den Zugriff auf die konditionierten 256-Bit-Samples vom AES-CBC-MAC.
Die RDSEEDAnweisung wurde Intel Secure Key hinzugefügt, um einen weiteren Pseudozufallszahlengenerator zu setzen, der in Broadwell- CPUs verfügbar ist . Die Entropiequelle für den RDSEEDBefehl läuft asynchron auf einer selbstgetakteten Schaltung und verwendet thermisches Rauschen innerhalb des Siliziums, um einen zufälligen Bitstrom mit einer Rate von 3 GHz auszugeben, langsamer als die effektiven 6,4 Gbit/s, die von RDRAND(beide Raten werden geteilt) zwischen allen Kernen und Fäden ). Der RDSEEDBefehl ist für das Seeding eines Software-PRNG beliebiger Breite RDRANDgedacht , wohingegen der für Anwendungen gedacht ist, die lediglich Zufallszahlen hoher Qualität benötigen. Wenn keine kryptografische Sicherheit erforderlich ist, ist ein Software-PRNG wie Xorshift normalerweise schneller.
Leistung
Auf einem Intel Core i7-7700K, 4500 MHz (45 x 100 MHz) Prozessor (Kaby Lake-S Mikroarchitektur) benötigt eine einzelne RDRANDoder RDSEEDAnweisung unabhängig von der Operandengröße (16/32/64 Bit) 110 ns oder 463 Taktzyklen. Diese Anzahl von Taktzyklen gilt für alle Prozessoren mit Skylake- oder Kaby-Lake- Mikroarchitektur. Auf den Silvermont- Mikroarchitekturprozessoren benötigt jeder der Befehle ungeachtet der Operandengröße ungefähr 1472 Taktzyklen; und auf Ivy-Bridge- Prozessoren RDRANDdauert es bis zu 117 Taktzyklen.
Auf einer AMD Ryzen-CPU benötigt jede der Anweisungen etwa 1200 Taktzyklen für einen 16-Bit- oder 32-Bit-Operanden und etwa 2500 Taktzyklen für einen 64-Bit-Operanden.
Ein astrophysikalischer Monte-Carlo-Simulator untersuchte die Zeit, um 10 7 64-Bit-Zufallszahlen mit RDRANDeinem Quad-Core Intel i7-3740 QM-Prozessor zu generieren . Sie fanden heraus, dass eine C-Implementierung von RDRANDetwa 2x langsamer lief als der standardmäßige Zufallszahlengenerator in C und ungefähr 20x langsamer als der Mersenne Twister . Obwohl ein Python-Modul von erstellt RDRANDwurde, wurde festgestellt, dass es 20-mal langsamer ist als der standardmäßige Zufallszahlengenerator in Python, obwohl kein Leistungsvergleich zwischen einem PRNG und einem CSPRNG durchgeführt werden kann.
Ein von Intel im Juni 2020 veröffentlichtes Microcode-Update, das die CrossTalk-Schwachstelle abschwächen soll (siehe Abschnitt zu Sicherheitsproblemen weiter unten), wirkt sich negativ auf die Leistung RDRANDund RDSEEDaufgrund zusätzlicher Sicherheitskontrollen aus. Auf Prozessoren mit angewendeten Abschwächungen verursacht jeder betroffene Befehl zusätzliche Latenz und die gleichzeitige Ausführung von RDRANDoder RDSEEDüber Kerne hinweg wird effektiv serialisiert. Intel hat einen Mechanismus eingeführt, um diese Sicherheitsüberprüfungen zu lockern, wodurch die Leistungseinbußen in den meisten Szenarien reduziert werden, aber Intel-Prozessoren wenden diese Sicherheitslockerung nicht standardmäßig an.
Compiler
Visual C++ 2015 bietet intrinsische Wrapperunterstützung für die RDRANDund RDSEED-Funktionen. GCC 4.6+ und Clang 3.2+ bieten intrinsische Funktionen für RDRANDwenn -mrdrnd in den angegebenen Flaggen , auch __RDRND__ Einstellung zu ermöglichen bedingte Kompilierung . Neuere Versionen bieten zusätzlich die Möglichkeit immintrin.h, diese eingebauten Funktionen in Funktionen zu integrieren, die mit Version 12.1+ von Intels C-Compiler kompatibel sind. Diese Funktionen schreiben zufällige Daten an die Position, auf die ihr Parameter zeigt, und geben bei Erfolg 1 zurück.
Anwendungen
Es ist eine Option, kryptographisch sichere Zufallszahlen mit RDRANDund RDSEEDin OpenSSL zu generieren , um die Kommunikation zu sichern.
Eine wissenschaftliche Anwendung RDRANDfindet sich in der Astrophysik. Radiobeobachtungen von massearmen Sternen und Braunen Zwergen haben ergeben, dass einige von ihnen Funkwellen aussenden. Diese Radiowellen werden durch magnetische Wiederverbindung verursacht , den gleichen Prozess, der Sonneneruptionen auf der Sonne verursacht. RDRANDwurde verwendet, um große Mengen von Zufallszahlen für einen Monte-Carlo- Simulator zu erzeugen , um die physikalischen Eigenschaften der Braunen Zwerge und die Auswirkungen der sie beobachtenden Instrumente zu modellieren. Sie fanden heraus, dass etwa 5 % der Braunen Zwerge ausreichend magnetisch sind, um starke Funkstöße auszusenden. Sie bewerteten auch die Leistung des RDRANDBefehls in C und Python im Vergleich zu anderen Zufallszahlengeneratoren.
Rezeption
Im September 2013 veröffentlichte Theodore Ts'o als Reaktion auf einen Artikel der New York Times , der die Bemühungen der NSA zur Schwächung der Verschlüsselung enthüllte , öffentlich die Verwendung von for im Linux-Kernel :
RDRAND/dev/random
Ich bin so froh, dass ich dem Druck der Intel-Ingenieure widerstanden habe,
/dev/randommich nur auf dieRDRANDAnweisungen zu verlassen. Um aus dem [New York Times-Artikel] zu zitieren: "Bis zu diesem Jahr hatte das Sigint Enabling Project Wege in einigen der Verschlüsselungschips gefunden, die Informationen für Unternehmen und Regierungen verschlüsseln, entweder indem es mit Chipherstellern zusammenarbeitete, um Hintertüren einzufügen..." Sich ausschließlich auf den Hardware-Zufallszahlengenerator zu verlassen, der eine Implementierung verwendet, die in einem Chip versiegelt ist und der nicht auditiert werden kann, ist eine SCHLECHTE Idee.
Linus Torvalds wies Bedenken hinsichtlich der Verwendung von RDRANDim Linux-Kernel zurück und wies darauf hin, dass es nicht als einzige Entropiequelle für verwendet wird /dev/random, sondern vielmehr dazu verwendet wird, die Entropie zu verbessern, indem die empfangenen Werte RDRANDmit anderen Zufallsquellen kombiniert werden . Taylor Hornby von Defuse Security demonstrierte jedoch, dass der Linux-Zufallszahlengenerator unsicher werden könnte, wenn eine Hintertür in die RDRANDAnweisung eingefügt wird, die speziell auf den Code abzielt, der ihn verwendet. Hornbys Proof-of-Concept-Implementierung funktioniert auf einem unmodifizierten Linux-Kernel vor Version 3.13. Das Problem wurde 2013 im Linux-Kernel behoben.
Entwickler , die geändert FreeBSD entfernt Kernel verwenden RDRANDund VIA PadLock direkt mit dem Kommentar „Für FreeBSD 10, wir denselben Weg zurückverfolgen , und entfernen Sie gehen RDRANDBackends und Vorhängeschloss und sie in füttern Schafgarbe statt ihre Ausgabe direkt liefern zu / dev / random . Es wird nach wie vor auf Hardware-Zufallszahlengeneratoren, d. h. RDRANDVorhängeschloss usw., direkt per Inline-Assembly oder bei Bedarf über OpenSSL aus dem Userland zugreifen zu können, denen wir aber nicht mehr vertrauen können." FreeBSD /dev/random verwendet Fortuna und RDRAND ab FreeBSD 11.
Sicherheitsprobleme
Juni 2020 veröffentlichten Forscher der Vrije Universiteit Amsterdam einen Seitenkanalangriff namens CrossTalk ( CVE-2020-0543 ), der RDRANDeine Reihe von Intel-Prozessoren betraf . Sie entdeckten, dass die Ausgaben des Hardware Digital Random Number Generators (DRNG) in einem Staging-Puffer gespeichert wurden, der von allen Kernen gemeinsam genutzt wurde. Die Sicherheitsanfälligkeit ermöglichte es bösartigem Code, der auf einem betroffenen Prozessor ausgeführt wird, das Lesen RDRANDund die RDSEEDAnweisungsergebnisse einer Opferanwendung, die auf einem anderen Kern desselben Prozessors ausgeführt wird, einschließlich Anwendungen, die in Intel SGX-Enklaven ausgeführt werden . Die Forscher entwickelten einen Proof-of-Concept-Exploit , der nach nur einer Signaturoperation einen vollständigen ECDSA- Schlüssel aus einer SGX-Enklave extrahierte, die auf einem separaten CPU-Kern ausgeführt wurde. Die Sicherheitsanfälligkeit betrifft Szenarien, in denen nicht vertrauenswürdiger Code zusammen mit vertrauenswürdigem Code auf demselben Prozessor ausgeführt wird, beispielsweise in einer Shared Hosting-Umgebung.
Intel bezeichnet die CrossTalk-Schwachstelle als Special Register Buffer Data Sampling (SRBDS). Als Reaktion auf die Forschung hat Intel Microcode-Updates veröffentlicht, um das Problem zu mildern. Der aktualisierte Mikrocode stellt sicher, dass Off-Core-Zugriffe verzögert werden, bis sensible Operationen – insbesondere die Anweisungen RDRAND, RDSEED, und EGETKEY– abgeschlossen sind und der Staging-Puffer überschrieben wurde. Der SRBDS-Angriff betrifft auch andere Anweisungen, z. B. solche, die MSRs lesen , aber Intel hat aufgrund von Leistungsproblemen und der geringeren Notwendigkeit der Vertraulichkeit der Ergebnisse dieser Anweisungen keine zusätzlichen Sicherheitsvorkehrungen getroffen. Betroffen war eine breite Palette von Intel-Prozessoren, die zwischen 2012 und 2019 auf den Markt kamen, darunter Desktop-, Mobil- und Server-Prozessoren. Die Abschwächungen selbst führten zu negativen Leistungseinbußen bei der Verwendung der betroffenen Anweisungen, insbesondere bei paralleler Ausführung durch Multithread-Anwendungen, aufgrund der erhöhten Latenzzeiten, die durch die Sicherheitsprüfungen und der effektiven Serialisierung der betroffenen Anweisungen über Kerne hinweg eingeführt wurden. Intel hat eine Opt-out-Option eingeführt, die über den IA32_MCU_OPT_CTRLMSR auf jedem logischen Prozessor konfigurierbar ist und die Leistung verbessert, indem die zusätzlichen Sicherheitsprüfungen für Anweisungen deaktiviert werden, die außerhalb einer SGX-Enklave ausgeführt werden.