Was ist Entropie-Injektion?

by Heike Vollmers in

Was ist „Entropie“?

In der Informatik/Kryptographie bezeichnet Entropie die Unvorhersehbarkeit (Zufälligkeit) von Daten, die für sichere Schlüssel, Nonces, Zufallszahlen etc. benötigt wird. Je höher die Entropie, desto schwerer ist es für einen Angreifer, Werte vorherzusagen.

Was bedeutet „Entropie-Injektion“?

Entropie-Injektion = das Hinzufügen (Einspeisen) von zusätzlichen Zufallsdaten in die Entropiequelle eines Systems (z. B. in den Entropiepuffer des Betriebssystems), damit Kryptographieoperationen und Zufallszahlengeneratoren genügend Unvorhersehbarkeit haben.

Warum ist Entropie-Injektion wichtig?

  • Systeme mit zu wenig Entropie erzeugen vorhersagbare Schlüssel/Nonces → Sicherheitsrisiko (z. B. unsichere TLS-Keys, signierte Tokens).
  • Besonders kritisch in Embedded-Geräten, VMs oder beim frühen Booten (noch keine vielen Entropiequellen vorhanden).

Wo kommt Entropie normalerweise her?

Herkömmliche Quellen:

  • Hardwareinterrupt-Timings (Maus, Tastatur, Netzwerk)
  • Festplatten-I/O-Timings
  • Netzwerkpaket-Arrival-Jitter
  • Hardware-TRNGs (True RNGs), z. B. dedizierte Zufallschips oder CPU-Instruktionen (RDSEED / RDRAND)
  • Sensoren/Peripherie (Temperatur, ADC-Rauschen)

Wie wirkt sich das auf Linux / Unix aus?

  • Kernel hält einen Entropiepuffer; Werte können über /proc/sys/kernel/random/entropy_avail geprüft werden.
  • /dev/random blockiert, wenn Entropie knapp ist; /dev/urandom liefert Daten weiterhin (nicht blockierend), wobei die Qualität nach Initialisierung als ausreichend gilt — aber Vorsicht bei sehr frühen Boot-Phasen.

Welche Wege zur Entropie-Injektion gibt es?

  • Hardware-TRNGs: USB/PCIe Zufallsgeräte, On-chip TRNGs.
  • CPU-Instruktionen: RDRAND/RDSEED (Intel/AMD) — als zusätzliche Quelle nutzen, am besten gepuffert/vermengt.
  • Software-Daemons: haveged, rngd (Teil von rng-tools) — generieren / speisen Entropie in den Kernel.
  • Virtuelle Schnittstellen: virtio-rng / qemu-rng — VM kann Entropie vom Hypervisor beziehen.
  • Seed-Dateien: persistente Seeddateien beim Herunterfahren/Boot, z. B. systemd-random-seed oder eigene seeding-Mechanismen.
  • Externe Quellen: Dedizierte HSMs, Krypto-Module, Netzwerk-Seeddienste (Achtung: Vertrauens-/Sicherheitsüberlegungen).

Ist es sicher, CPU-Instruktionen wie RDRAND zu benutzen?

Kurz: Ja, meist, aber am besten nicht als einzige Quelle. Empfehlung: mixen — kombiniere RDRAND/RDSEED mit anderen Entropiequellen (Hash/MAC über mehrere Quellen), sodass ein kompromittierter Einzelpunkt nicht das ganze Ergebnis zerstört.

Was sind Risiken bei Entropie-Injektion?

  • Einspeisung von schwacher/vorhersagbarer „Entropie“ kann Sicherheit verringern.
  • Unsichere oder manipulierte externe Quellen (z. B. Netzwerk-Seed von untrusted Server).
  • Doppelter Gebrauch desselben Seeds führt zu Schlüssel­wiederverwendung.
  • Bei VMs: wenn Host-Entropie identisch für viele VMs geliefert wird → Vorhersagbarkeit.

Best-Practices (Checkliste)

  1. Früh seeden: beim Boot eine persistente Seeddatei verwenden (aber niemals als einzige Quelle).
  2. Mehrere Quellen: hardwarebasiert + softwarebasiert + timing-Quellen mischen.
  3. System-APIs nutzen: getrandom()/getentropy() (Linux / libc) oder sichere Krypto-APIs anstatt /dev/urandom-Managment selbst zu schreiben.
  4. RDRAND/RDSEED sinnvoll nutzen: als zusätzliche Quelle, nicht alleinstehend.
  5. Für VMs: virtio-rng / qemu-rng oder Host-RNG-Gerät korrekt konfigurieren; vermeide Kopieren desselben Seeds in mehrere VMs.
  6. HSM/TPM für besonders hohe Sicherheit (Schlüsselgenerierung, sichere Zufallszahlen).
  7. Monitoring: /proc/sys/kernel/random/entropy_avail überwachen und Alarm bei dauerhaft niedrigen Werten.
  8. Testen: RNG-Tests (Dieharder, ent, rngtest) nutzen, um offensichtliche Probleme zu erkennen.
  9. Nicht selbst mixen, wenn man es nicht richtig macht: bestehende, geprüfte Libraries/Daemons verwenden.

Wie prüfe ich den Entropiestatus auf Linux?

  • cat /proc/sys/kernel/random/entropy_avail — aktueller Schätzwert der verfügbaren Entropie.
  • Tools: rngtest, ent, dieharder (zur Analyse der Ausgabe von Zufallsdaten).

Beispiele

  • Kernel-Entropie prüfen:
cat /proc/sys/kernel/random/entropy_avail
  • haveged installieren und starten (Debian/Ubuntu):
sudo apt install haveged
sudo systemctl enable --now haveged
  • rngd nutzen, wenn ein TRNG vorhanden ist:
sudo apt install rng-tools
sudo rngd -r /dev/hwrng

Häufige Fragen (Schnellantworten)

Q: „Ist /dev/urandom sicher?“
A: Ja für die meisten Anwendungen, nachdem das System initial ausreichend geseed wurde. Bei äußerst sicherheitskritischen Operationen unmittelbar nach Boot (vor Initialisierung) Vorsicht.

Q: „Können VMs Entropie-Probleme haben?“
A: Ja, besonders kurz nach dem Boot. Verwende virtio-rng oder andere Hypervisor-Mechanismen, und seed zusätzlich persistent.

Q: „Soll ich haveged immer einsetzen?“
A: haveged ist praktisch für Systeme ohne Hardware-TRNG. Bei vorhandenen, geprüften Hardware-RNGs ist es nicht zwingend nötig. haveged ist jedoch eine brauchbare Maßnahme in Embedded-/VM-Umgebungen.

Q: „Reicht RDRAND allein?“
A: RDRAND ist ein guter Baustein, aber Experten empfehlen, Zufallsquellen zu kombinieren und RDRAND nicht als alleiniges/allein vertrauenswürdiges Element zu verwenden.

Q: „Wie kann ich testen, ob meine Schlüssel wirklich zufällig sind?“
A: Nutze geprüfte Tools wie dieharder oder ent für statistische Tests; für Schlüssel-Sicherheit ist jedoch auch das richtige Management des Seeding-Prozesses entscheidend.

Wann sollte ich einen Experten hinzuziehen?

  • Erzeugung/Verwaltung von Schlüsseln für große Produktionssysteme, PKI, kritische Infrastrukturen oder wenn gesetzliche/Regulierungsanforderungen bestehen — dann einen Kryptographieexperten oder Security-Engineer einbeziehen.