it-swarm.com.de

Wird Ubuntu RANDOM_TRUST_CPU im Kernel aktivieren und was würde das bewirken?

Entsprechend The Register article from 2018-08-28 und anderen Artikeln hat der Linux-Kernel Version 4.19 ein Kompilierungsflag mit dem Namen RANDOM_TRUST_CPU. Hier ist auch ein Link zu einem Mailinglisteneintrag vom Patch-Autor, einschließlich der tatsächlichen Codeänderungen. Soweit ich verstanden habe, können Systeme unter bestimmten Umständen den Startvorgang beschleunigen, indem sie nicht warten, bis genügend Entropie aus verschiedenen Quellen für die Sicherheit gesammelt wurde Setzen Sie den Zufallszahlengenerator, überspringen Sie diesen Teil jedoch und verlassen Sie sich ausschließlich auf den in der CPU integrierten Zufallszahlengenerator.

Dies würde die kryptografische Sicherheit des Systems schwächen, da es (wenn ich das richtig verstehe) nicht nur auf die CPU als einzelne Entropiequelle angewiesen ist, sondern auch die Sicherheit vollständig untergraben kann, wenn die Implementierung dieser CPU nicht vertrauenswürdig ist (Fehler, absichtliche Hintertüren, ...).

  • Würde der Zufallszahlengenerator des Kernels dann die ganze Zeit nur vom Generator der CPU aus initialisiert, oder würde er dies nur in den frühen Startphasen tun und später mehr Entropie von den "traditionellen" Quellen in den Pool hinzufügen, was die kryptografische Sicherheit erhöht mal wieder zurück auf aktuelles/altes niveau?

  • Da dies anscheinend ein Flag für die Kompilierungszeit ist, werden die in den Ubuntu-Repositorys bereitgestellten Kernelpakete mit einem aktivierten oder deaktivierten Flag geliefert?

  • Könnte es eine andere Möglichkeit geben, sich an- oder abzumelden, als von nun an selbst Kernel zu kompilieren?

  • Gibt es eine Möglichkeit zu testen, ob dies einen Unterschied in der Startzeit bewirken würde? Gibt es derzeit Metriken zur Wartezeit auf Entropie während des Startvorgangs?

  • Und welche Ubuntu-Versionen können sogar Kernel-Versionen ab 4.19 ausführen?

4
Byte Commander

Erstens wird die kryptografische Sicherheit des Systems - seine Unvorhersehbarkeit - in keiner Weise geändert, unabhängig davon, ob die in der CPU integrierte HWRNG (z. B. RDRAND in Intel) verwendet wird oder nicht Sie haben festgestellt, dass dies die Sicherheit des RNG (und alles, was davon abhängt) unvermeidlich schwächen würde.

Kurz gesagt, um zusammenzufassen, während des Bootstrapping-Prozesses, nachdem der Kernel den Randomness-Treiber geladen hat, wird der Linux-RNG initialisiert alle zufälligen Pools ( Entropie-Pools , bei denen es sich nur um Speicherbereiche handelt, in denen zufällige Daten gespeichert sind), einschließlich des Hauptpools (), indem sie mit Daten gefüllt werden Entropie, die aus dem HWRNG stammt, falls verfügbar, ansonsten über random_get_entropy(), das ein Makro für get_cycles() ist, dessen Implementierung von der Architektur abhängt (z. B. in aarch64 ein Lesen des Registers CNTVCT_EL0) ist erledigt , das ist eine Art Frequenzzähler, nicht die Taktrate, die stattdessen in x86-64 durch Lesen des TSC-Registers verwendet wird). Alle diese Daten werden an einen primären Chiffrierstatus übergeben (primary_crng, ein Objekt vom Typ struct crng_state, das die Implementierung des ChaCha20-Algorithmus ist und einen Schlüssel von 384 enthält wirklich zufällige Bits, die schließlich der Schnittstelle /dev/urandom zugeführt werden.

Nun, mit dieser Kontextualisierung, um Ihre Frage zu beantworten, geschieht die eigentliche RNG-Initialisierung des Kernels durch Rand_initialize(), die ein early_initcall ist, offensichtlich nur beim Booten (wie bei allen *_initcall()), insbesondere beim Ganz am Ende von start_kernel() wird die Kernel-Routine rest_init() aufgerufen, in der als erstes ein Kernel-Thread (kernel_init) mit dem Ziel erzeugt wird, unter anderem um diesen Initcall zu starten (beachte auch, dass add_device_randomness() even vor heißt, aber keine entropischen Daten hinzufügt); und demzufolge wird der Chiffrierstatus des ChaCha20, des Primär- und des Blockierungspools pro Quelle mit Arch_get_random_long() initialisiert, wobei die Anweisung RDRAND in x86-Prozessoren verwendet wird (sofern verfügbar) , und wenn ja, der Kernel warnt Sie darüber). Ich würde nicht sagen, dass es die einzige Quelle ist, die verwendet wird (auch wenn RDRAND verfügbar ist), zumindest weil:

  1. Die Firmware-Zeit wird verwendet und in die Pools gemischt während der Initialisierung (möglicherweise nicht so entropisch, dennoch müsste ein Angreifer den Zeitstempel mit extrem hoher Präzision ableiten);

  2. Es gibt einen weiteren kleinen Pool (einen pro CPU, genannt schneller Pool ), der Entropie von add_interrupt_randomness() sammelt, der IRQs (und theoretisch einen anderen Kernel) verwendet Ereignisse und sogar einige Startwerte, die vom CPU-Hardware-RNG stammen (falls vorhanden), werden alle gemischt und dann in den Eingabe-Pool eingespeist. Das passiert wie jede Sekunde.

Der Prozess des Sammelns von Entropie sowohl aus dem HWRNG als auch aus den anderen Quellen geschieht also alle zusammen; Natürlich dominiert die erste Szene die Szene (da die Entropiequalität definitiv höher ist, handelt es sich um ein echtes RNG) und tritt beim Booten auf, und zwar immer dann, wenn die Pseudozufallsgeräte (oder der Syscall getrandom()) verwendet werden . Im zweiten Fall sind die Pools jedoch bereits initialisiert, und es wird nur der primary_crng (der Chiffrierstatus) neu gesetzt. Und ja, wie Sie bereits bemerkt haben, verbessert das in die CPU integrierte RNG die allgemeine Zufälligkeit.

Abschließend möchte ich hinzufügen, dass die Verwendung von HWRNG insbesondere in eingebetteten Systemen, in denen möglicherweise keine Geräuschquellen (wie Tastaturen, Festplatten usw.) vorhanden sind, erhebliche Auswirkungen haben würde. Und beachten Sie, dass Sie immer gemäß Dokumentation die Kernel-Verwendung von RDRAND deaktivieren können, bevor RANDOM_TRUST_CPU eingeführt wird, wenn Sie sich mit Sicherheit befassen.

5