Zusammenfassung
Die wichtigsten Punkte auf einen Blick
- Schlüsselaustausch-Nachrichten werden deutlich größer: ML-KEM-Schlüsselanteile sind typischerweise ~1–2 Größenordnungen größer als elliptische Kurven-Schlüsselanteile (z.B. ML-KEM-768 öffentlicher Schlüssel 1.184 Bytes vs. X25519 32 Bytes). [1][2]
- Zertifikate und Signaturen wachsen ebenfalls: ML-DSA öffentliche Schlüssel und Signaturen liegen im Kilobyte-Bereich, was Zertifikatsketten und Firmware-Signatur-Overhead merklich erhöhen kann. [3]
- Rechenleistung kann auf modernen MCUs praktikabel sein: Optimierter Cortex-M4-Code liefert ML-KEM-Operationen im einstelligen Millisekundenbereich, aber Funknutzlast-Grenzen können die Gesamtkosten dominieren. [4][5]
- Hybridmodi sind die praktische Migrationsstrategie: Die Kombination eines klassischen ECDH-Anteils mit ML-KEM kann Quantenresistenz bieten und gleichzeitig ein Sicherheitsnetz während der Einführung bereitstellen. [6][7]
- Planen Sie für Speicher- und Protokollreibung: Die größten Probleme auf ressourcenbeschränkten Geräten sind oft RAM-/Flash-Budgets, Fragmentierung und Update-Logistik – nicht die reine CPU-Zeit. [5]
Die IoT-Herausforderung: Warum PQC anders trifft
Das NIST hat seine ersten Post-Quanten-Public-Key-Algorithmen im August 2024 als Federal Information Processing Standards (FIPS) standardisiert: ML-KEM für Schlüsselvereinbarung und ML-DSA für Signaturen. [7][3] Diese Standards zielen auf Allzwecksysteme ab, aber das IoT befindet sich am entgegengesetzten Extrem: Mikrocontroller mit ~256 KB Flash, ~64 KB RAM, strengen Energiebudgets und Netzwerkverbindungen mit kleinen maximalen Übertragungseinheiten.
Klassische elliptische Kurven-Kryptographie passt teilweise deshalb gut zu ressourcenbeschränkten Geräten, weil ihre Übertragungsartefakte klein sind. In TLS 1.3 beträgt ein X25519-Schlüsselanteil 32 Bytes und ein P-256-Schlüsselanteil typischerweise 65 Bytes (unkomprimierter Punkt). [2][6] Im Vergleich dazu verwendet ML-KEM-768 einen 1.184-Byte-Kapselungs-öffentlichen-Schlüssel und einen 1.088-Byte-Chiffretext. [1] Die Verschiebung bedeutet nicht nur "größere Zahlen": Sie verändert Handshake-Framing, Puffergrößen und erzwingt oft Fragmentierung auf Links mit niedriger MTU.
Algorithmen im Größenvergleich
| Algorithmus | Öffentlicher Schlüssel | Chiffretext / Signatur | Sicherheitsstufe |
|---|---|---|---|
| ECDH P-256 (TLS 1.3 Schlüsselanteil) | 65 B | — | ~128-Bit |
| X25519 (TLS 1.3 Schlüsselanteil) | 32 B | — | ~128-Bit |
| ML-KEM-512 | 800 B | 768 B | NIST Level 1 |
| ML-KEM-768 | 1.184 B | 1.088 B | NIST Level 3 |
| ML-KEM-1024 | 1.568 B | 1.568 B | NIST Level 5 |
| ECDSA P-256 (X.509/TLS) | 65 B | DER-kodiert (variabel) | ~128-Bit |
| ML-DSA-44 | 1.312 B | 2.420 B | NIST Level 2 |
| ML-DSA-65 | 1.952 B | 3.309 B | NIST Level 3 |
| ML-DSA-87 | 2.592 B | 4.627 B | NIST Level 5 |
Die Tabelle zeigt eine praktische Realität: Allein der Schlüsselaustausch-Datenverkehr kann einige Kilobytes pro Handshake betragen. In ressourcenbeschränkten Netzwerken kann das alles andere dominieren. Beispielsweise hängen die maximalen Anwendungs-Nutzlastgrößen bei LoRaWAN von der Region und Datenrate ab; in EU863–870 zeigt RP002-1.0.3 Nutzlast-Limits von nur 51 Bytes bei den langsamsten Datenraten bis zu 222 Bytes bei höheren Datenraten – daher werden Multi-Paket-Handshakes und sorgfältige Fragmentierung unvermeidlich. [5]
Benchmarks auf realer Hardware
Glücklicherweise ist die Leistungsgeschichte differenzierter. Optimierte Implementierungen, insbesondere solche, die ARMv7-M-DSP-Befehle nutzen, liefern beeindruckenden Durchsatz:
- Cortex-M4 @ 168 MHz (STM32F446, wolfSSL): Kyber768 Schlüsselgenerierung ~6,9 ms, Kapselung ~8,5 ms, Entkapselung ~9,1 ms (Single-Core, -Ofast). [4]
- Gleiche Plattform (wolfSSL, klassische Baseline): ECDHE P-256 Vereinbarung ~18,1 ms; wolfSSL merkt an, dass ein vollständiger NIKE-artiger Austausch die Arbeit an beiden Endpunkten effektiv verdoppelt, was insgesamt ~26,7 ms für den Schlüsselaustausch ergibt. [4]
- Interpretation für IoT: ML-KEM kann rechenleistungstechnisch wettbewerbsfähig sein, aber Nachrichtengröße und Pufferung werden häufig zum limitierenden Faktor bei Links mit niedriger MTU und winzigen RAM-Budgets. [1][5]
Das Timing hängt stark von Implementierungsentscheidungen ab (Constant-Time-Härtung, Speicherlayout und ob optimierter Assembler verfügbar ist). Behandeln Sie veröffentlichte Benchmarks als Richtwerte und messen Sie dann auf Ihrem genauen MCU, Compiler-Flags und Funk-Stack. Für Algorithmusgrößen und Parametersätze sind die stabilsten öffentlichen Referenzen die NIST-FIPS-Dokumente und die Open Quantum Safe-Parametertabellen. [7][1]
Strategien für ressourcenbeschränkte Geräte
1. Wählen Sie die richtige Sicherheitsstufe
NIST Level 1 (ML-KEM-512) kann für kurzlebige Sitzungen oder Sensordaten ausreichen, die innerhalb von Tagen an Wert verlieren. Reservieren Sie Level 3 oder 5 für langfristige Geheimnisse wie Geräteidentitätsschlüssel.
2. Auslagern auf ein Secure Element
Secure Elements können helfen, indem sie langfristige Schlüssel isolieren und gehärtete, gegen Seitenkanalangriffe resistente Implementierungen bereitstellen. Ob sie PQC speziell beschleunigen, variiert stark je nach Hersteller und Generation. Behandeln Sie dies als Roadmap-Punkt: Überprüfen Sie, was tatsächlich in Silizium implementiert ist (und was nur als Host-seitige Software verfügbar ist), bevor Sie architektonische Annahmen treffen.
3. Hybrid-TLS: Das Beste aus beiden Welten
Hybrider Schlüsselaustausch – die Kombination eines klassischen ECDH-Anteils mit ML-KEM – kann Ihnen einen konservativen Migrationspfad bieten: Selbst wenn eine Komponente später schwächer wird, kann der kombinierte Austausch weiterhin Vertraulichkeit bieten. In der Praxis erhöhen Hybridmodi sowohl Nachrichtengrößen als auch RAM-Druck, sodass die Hauptingenieurarbeit oft bei Handshake-Framing, Fragmentierung und Zertifikatsketten-Budgets liegt, nicht allein bei CPU-Zyklen. [6][1]
4. Komprimieren wo möglich
Forschung zu komprimierten Gitter-Darstellungen (z.B. NTRU-basierte Schemata oder zukünftige NIST-Runden) könnte die Nutzlasten weiter verkleinern. Derzeit können Protokollebenen-Komprimierung (CBOR, CoAP-Block-Transfers) und das Caching von Zertifikaten beim Erstkontakt die Bandbreitenprobleme mildern.
Das Firmware-Update-Problem
IoT-Geräte erhalten oft signierte Firmware-Images. Die heutige ECDSA-Signatur ist 64 Bytes groß; ML-DSA-65 erhöht das auf 3,3 KB. Für ein 256-KB-Firmware-Image ist der Overhead handhabbar. Aber für häufige Delta-Updates von wenigen Kilobytes erzeugt eine Signatur, die größer als die Nutzlast selbst ist, Reibung.
Lösungen, die derzeit untersucht werden, umfassen die Verwendung verschiedener Signaturfamilien für unterschiedliche Rollen (z.B. schnelle, kompakte Signaturen für häufige Delta-Updates beibehalten, während schwerere Signaturen für seltene Root-Key-Operationen reserviert werden). Hash-basierte Signaturen wie SLH-DSA (vom NIST standardisiert und auf SPHINCS+ basierend) sind aufgrund ihrer konservativen Annahmen attraktiv, haben aber typischerweise viel größere Signaturen als ML-DSA – sie reduzieren also nicht automatisch den Update-Overhead auf ressourcenbeschränkten Links. [8]
Was Sie heute verifizieren können
- Die Standards sind stabil: Die ML-KEM (FIPS 203) und ML-DSA (FIPS 204) des NIST sind finalisiert und veröffentlicht (August 2024). [7][3]
- Das "Kostenzentrum" ist oft das Netzwerk: LoRaWAN-Nutzlast-Obergrenzen können bei langsamen Datenraten nur wenige zehn Bytes betragen, was Fragmentierung für PQ-Handshakes unvermeidlich macht. [5]
- Messen, nicht annehmen: Veröffentlichte MCU-Benchmarks sind nützlich, aber Leistung und Speicherverbrauch hängen stark von Constant-Time-Härtung und Implementierungsstrategie ab. [4]
Wenn Sie möchten, dass dieser Artikel über die Zeit hinweg genau bleibt, ist die sicherste Praxis, "harte Zahlen" an Primärquellen (FIPS/RFC/Spezifikationen) und an Hersteller-Benchmark-Posts zu verankern, die ihr Testszenario angeben.
Erkenntnisse für Embedded-Ingenieure
- Beginnen Sie jetzt mit der Inventarisierung der kryptographischen Nutzung. Wissen Sie, wo Schlüssel generiert, gespeichert und ausgetauscht werden.
- Prototypen mit liboqs oder pqcrypto-embedded erstellen. Messen Sie die tatsächliche Leistung auf Ihrem Ziel-MCU, bevor Sie sich festlegen.
- Wählen Sie Hybridkonfigurationen für Ihre nächste Produktgeneration – sie sind sicherer und werden zunehmend unterstützt.
- Budget für größere Zertifikate und Handshakes einplanen. Funk-Stack, Stromverbrauch und Latenzschätzungen müssen aktualisiert werden.
- Secure-Element-Roadmaps verfolgen. Hardware-Offload wird der reibungsloseste Weg für stark ressourcenbeschränkte Geräte sein.
Nächster Schritt
Neugierig, wie sich PQC im Vergleich zu Quantum Key Distribution für IoT verhält? Unser Deep-Dive erklärt die Unterschiede und wann welcher Ansatz sinnvoll ist.
Referenzen
- Open Quantum Safe (liboqs): ML-KEM Parametersatz-Zusammenfassung (Größen und NIST-Level)
- RFC 7748: Elliptic Curves for Security (X25519 / X448)
- NIST FIPS 204 (Final): Module-Lattice-Based Digital Signature Standard (ML-DSA)
- wolfSSL: Post-Quantum Kyber Benchmarks (ARM Cortex-M4, STM32F446 @ 168 MHz)
- LoRa Alliance RP002-1.0.3: LoRaWAN® Regional Parameters (Nutzlast-Größentabellen nach Region/Datenrate)
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- NIST FIPS 203 (Final): Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- NIST FIPS 205 (Final): Stateless Hash-Based Digital Signature Standard (SLH-DSA)