Post-Quanten-Kryptografie für vernetzte Geräte

Vernetzte Produkte bleiben 10, 15 oder sogar 20 Jahre im Einsatz, während die Kryptografie in ihrem Inneren lange vor der Auslieferung festgelegt wurde. Damit ist Post-Quanten-Kryptografie mehr als ein IT-Upgrade: Sie müssen wissen, welche Algorithmen, Bibliotheken, Zertifikate, Schlüssel und Protokolle in der Firmware stecken und ob Sie sie sicher ersetzen können.

Dieser Beitrag erklärt das Quantenrisiko, die NIST-Standards, die neuen US-Bundesfristen für 2030 und 2031 sowie die praktischen Schritte zu krypto-agilen Embedded-Produkten.

Was ist Post-Quanten-Kryptografie (PQC)?

Post-Quanten-Kryptografie, kurz PQC, bezeichnet Verfahren, die Angriffen durch klassische und durch ausreichend leistungsfähige Quantencomputer widerstehen sollen. Im Zentrum steht die asymmetrische Kryptografie, denn ein kryptografisch relevanter Quantencomputer könnte weit verbreitete Verfahren wie RSA und Systeme auf Basis elliptischer Kurven aushebeln.

PQC ersetzt angreifbare mathematische Verfahren durch Algorithmen, deren zugrunde liegende Probleme auch für Quantencomputer als schwer gelten. Das NIST empfiehlt Organisationen inzwischen, mit dem Umstieg auf die finalisierten quantenresistenten Standards zu beginnen und nicht auf das Erscheinen dieses Rechners zu warten.

In Embedded-Produkten muss quantenresistente Kryptografie mit begrenztem Speicher, begrenzter Rechenleistung, begrenzter Bandbreite, dem Secure-Boot-Design und den Update-Mechanismen zurechtkommen. Ein einzelnes Firmware-Image kann TLS-Bibliotheken, SSH-Komponenten, Prüfungen von Code-Signaturen, Gerätezertifikate, Logik für sichere Updates und kryptografische Abhängigkeiten von Drittanbietern enthalten.

Ein Migrationsplan, der nur Server im Unternehmen betrachtet, übersieht Kryptografie, die jahrelang in Geräten im Feld bleibt. Quantensichere Kryptografie führt deshalb zu der Frage, ob ein Produkt über seine gesamte Supportphase sicher und aktualisierbar bleibt, während das Quantencomputing voranschreitet.

Warum das Thema jetzt zählt: Harvest now, decrypt later

Der Zeitpunkt des Quantenrisikos ist unsicher, ein Teil der Exposition besteht aber bereits heute. Bei einem Angriff nach dem Muster „harvest now, decrypt later“ sammelt ein Angreifer verschlüsselten Datenverkehr oder gespeicherte Chiffrate und bewahrt sie auf, bis ein künftiger Quantencomputer den asymmetrischen Schutz der Schlüssel brechen kann. Produktdaten können Konstruktionsunterlagen, Servicezugänge, medizinische Informationen, industrielle Telemetrie oder Kommunikation enthalten, die über Jahre sensibel bleibt. Das Weiße Haus hat dieses Sammelrisiko in seiner Executive Order zu fortgeschrittenen kryptografischen Angriffen vom Juni 2026 ausdrücklich benannt.

Das Problem betrifft außerdem Vertrauen und Authentizität, denn künftige Quantenangriffe könnten digitale Signaturen für Software-Updates, Geräteidentitäten, Zertifikate und authentifizierte Kommunikation entwerten. Ein Gerät, das kein neues Signaturverfahren annehmen kann, wird schwer wartbar, selbst wenn die übrige Software noch funktioniert. Ihre Planungsfrage sollte deshalb weiter reichen als „Wann brechen Quantencomputer RSA?“. Fragen Sie, wie lange Produkte und Daten exponiert bleiben und wie lange Bestandsaufnahme, Tests, Abstimmung mit Zulieferern und Migration dauern.

NIST-Standards: ML-KEM, ML-DSA, SLH-DSA und die Fristen 2030 und 2031

Das NIST hat seine ersten drei zentralen PQC-Standards im August 2024 finalisiert: FIPS 203, FIPS 204 und FIPS 205. Sie decken Schlüsselaustausch und digitale Signaturen ab, und das NIST empfiehlt, sie schon jetzt anzuwenden. Der Umstieg auf quantenresistente Kryptografie ist damit eine laufende Migrationsaufgabe und keine reine Forschungsfrage.

Was die drei NIST-Standards leisten

Die drei Standards sind nicht austauschbar. ML-KEM erzeugt gemeinsame Geheimnisse, ML-DSA und SLH-DSA liefern digitale Signaturen. Wegen der unterschiedlichen Performance und Ausgabegrößen müssen Sie sie auf realer Hardware, in realen Protokollen, in der Firmware und in den Update-Pfaden testen.

ML-KEM ist in drei Parametersätzen verfügbar und der zentrale standardisierte Mechanismus des NIST für die Schlüsselkapselung. ML-DSA beruht auf Gittern, SLH-DSA ist ein zustandsloses hashbasiertes Signaturverfahren, das von SPHINCS+ abgeleitet ist. Das NIST standardisiert weitere Algorithmen. Auch deshalb bleibt Krypto-Agilität nach der ersten Migration wichtig.

Was die Fristen 2030 und 2031 für Produktteams bedeuten

Die Jahre 2030 und 2031 sind konkrete Meilensteine der US-Bundesverwaltung, aber keine einheitliche gesetzliche Frist für jedes kommerzielle vernetzte Gerät. Die Executive Order 14412 verlangt, dass hochwertige und besonders kritische Systeme des US-Bundes den Schlüsselaustausch bis zum 31. Dezember 2030 und digitale Signaturen bis zum 31. Dezember 2031 auf PQC umstellen. Sie beauftragt zusätzlich Arbeiten an Beschaffungsregeln und an der Migration kritischer Infrastruktur. Diese Vorgaben wirken auf Zulieferer, die in Behörden und regulierte Lieferketten verkaufen.

Das OMB-Memorandum M-26-15 legt einen Stufenplan fest: Bestandsaufnahme und Planung 2026 bis 2027, Pilotprojekte 2027 bis 2028, priorisierte Migration des Schlüsselaustauschs bis 2030, Signaturmigration 2031 und breiter Abschluss bis 2035. Es empfiehlt Behörden zudem, das Kryptografie-Inventar zu automatisieren und wo möglich ein zentrales CBOM zu führen. Kundenanforderungen können schneller kommen als allgemeine Gesetzgebung. Sie sollten deshalb wissen, ob neue Produkte quantensichere Kryptografie unterstützen, bevor das zur Vertragsbedingung wird. Behandeln Sie 2030 als Planungshorizont, nicht als Grund, bis 2029 zu warten.

Das Problem in IoT, OT und Embedded: lange Lebenszyklen, schwer patchbare Kryptografie

Die PQC-Migration ist in vernetzten Produkten schwieriger, weil Kryptografie an physische Geräte gebunden ist. RAM, Flash, CPU-Leistung, Bandbreite oder Batterie können knapp sein, während Bootloader und Secure Elements kaum zu verändern sind. Alte Toolchains, Hersteller-SDKs, vorkompilierte Bibliotheken und Zulieferkomponenten verbergen zusätzlich kryptografische Abhängigkeiten.

Ein Cloud-Dienst kann eine Bibliothek zentral aktualisieren, eine Embedded-Flotte umfasst dagegen viele Firmware-Zweige und Hardwarerevisionen.

PQC-Algorithmen stellen andere Anforderungen an Schlüssel, Signaturen, Speicher und Bandbreite. Sie müssen Boot-Verifikation, Update-Pakete, Handshakes, Zertifikate, Speicherung und Interoperabilität auf echter Hardware testen.

Analysieren Sie außerdem das ausgelieferte Binary, denn Repositories übersehen statisch gelinkten oder übernommenen Code. Ein automatisiertes Schwachstellenmanagement hält Firmware-Funde mit den realen Produktversionen verbunden. Ein Gerät, das 2027 mit zwölf Jahren Support startet, läuft möglicherweise über die Bundesfristen 2030 und 2031 sowie über den breiteren NIST-Horizont 2035 hinaus. Einen Update-Pfad jetzt zu bauen ist leichter, als später festzustellen, dass ein ausgeliefertes Produkt keine neuen Algorithmen annehmen kann.

Krypto-Agilität und das Cryptographic Bill of Materials (CBOM)

Krypto-Agilität ist die Fähigkeit, kryptografische Algorithmen, Protokolle, Schlüssel, Zertifikate und Implementierungen zu ersetzen oder umzukonfigurieren, ohne das gesamte Produkt neu zu entwerfen. Sie hilft, wenn Standards sich ändern, ein Algorithmus schwächer wird, eine Bibliothek das Supportende erreicht oder ein Kunde ein neues Profil verlangt. PQC macht das dringend, denn die Migration erfolgt in Stufen und nicht als einmaliger Wechsel.

Warum Krypto-Agilität in der Firmware zählt

Ein krypto-agiles Design trennt kryptografische Entscheidungen so weit wie möglich vom übrigen Produkt. Abstraktionsschichten, konfigurierbare Algorithmus-Suiten, aktualisierbare Trust Stores und austauschbare Bibliotheken erleichtern kontrollierte Änderungen. Hardware setzt weiterhin feste Punkte. Erfassen Sie deshalb, welche Entscheidungen in Secure Boot, Bootloadern, Betriebssystemen, Anwendungen, Cloud-Diensten und Zulieferkomponenten verankert sind. Versteht ein Secure-Boot-ROM nur ein Signaturverfahren, reichen Softwareänderungen darüber nicht aus.

Die OMB-Vorgaben von 2026 fordern für Bundessysteme ebenfalls kryptografisch agile Architekturen und eine agile Schlüsselverwaltung. Sie empfehlen Algorithmus-Verhandlung, gleichzeitig aber Schutz vor Downgrade-Angriffen. Für Teams in der Produktentwicklung heißt das: Migrationspfade planen, bevor alte Kryptografie nicht mehr akzeptabel ist.

Erst das CBOM, dann die Migrationsplanung

Sie können keine Kryptografie migrieren, die Sie nicht sehen. Ein Cryptographic Bill of Materials (CBOM) erfasst kryptografische Assets und ihre Verwendung, also Algorithmen, Bibliotheken, Protokolle, Schlüsseltypen, Zertifikate, Implementierungen sowie die Produkte und Komponenten, die davon abhängen. Das OMB beschreibt ein laufend aktualisiertes Kryptografie-Inventar als Grundlage der Migrationsplanung und empfiehlt, diese Daten in ein zentrales CBOM zu überführen.

Ein nützliches CBOM sollte Fragen wie diese beantworten:

• Welche Produkte und Firmware-Versionen nutzen RSA, ECC, Diffie-Hellman oder andere quantenanfällige Verfahren, einschließlich Code aus älteren Releases?
• Welche Bibliotheken implementieren diese Algorithmen, welche Versionen sind im Feld, und wer verantwortet den Update-Pfad je Abhängigkeit?
• Wo werden sie eingesetzt: Secure Boot, Updates, TLS, VPNs, SSH, Zertifikate, Geräteidentität, Produktion oder Servicezugang?
• Welche Implementierungen liegen beim Zulieferer, und welche Nachweise hat jeder Zulieferer zu PQC-Unterstützung und künftiger Pflege geliefert?
• Welche Produkte nehmen kryptografische Updates ohne Hardwaretausch an, und welche brauchen einen neuen Bootloader, ein neues Secure Element oder eine neue Plattform?
• Welche Datenflüsse müssen lange vertraulich bleiben und tragen ein hohes Risiko nach dem Muster „harvest now, decrypt later“, und wie lange muss dieser Schutz halten?

Ein SBOM-Management-Tool liefert das Softwareinventar, SBOM und CBOM beantworten aber unterschiedliche Fragen. Das SBOM sagt Ihnen, welche Softwarekomponenten vorhanden sind. Das CBOM richtet den Blick auf die kryptografischen Fähigkeiten und Abhängigkeiten, aus denen Migrationsaufwand entsteht. Sie brauchen beide Sichten, denn ein Bibliotheksname allein verrät nicht, welcher Algorithmus in einem konkreten Firmware-Image aktiv ist.

PQC Readiness Assessment: wie ONEKEY Kryptografie in Firmware-Binaries findet

Ein Post-Quantum-Cryptography-Readiness-Assessment sollte bei den Produkten beginnen, die Sie tatsächlich ausliefern. ONEKEY analysiert Firmware-Binaries automatisiert und ohne Quellcode und kann kryptografische Algorithmen, Bibliotheken und konkrete Implementierungen erkennen. Über die Query Language durchsuchen Sie größere Datenbestände nach Produkten, die etwa RSA verwenden. Die Binäranalyse ist wichtig, weil Zulieferpakete, statisch gelinkte Bibliotheken und vorkompilierte Module Kryptografie einbringen, die eine Suche auf Quellcode-Ebene übersieht. Aus einem breiten Zukunftsthema wird so eine Arbeitsliste auf Produktebene.

ONEKEY behauptet nicht, dass die Branche die vollautomatische Erstellung eines Crypto-SBOM gelöst hat. Sie können die Krypto-Erkennung mit einem SBOM-Audit verbinden, um Firmware-Nachweise mit Softwareinventar und Zulieferangaben zu vergleichen. PSIRT, Entwicklung, Produkt und Compliance erhalten damit eine gemeinsame Grundlage für die Priorisierung. Ergänzend zeigt ONEKEYs Webinar zum PQC Readiness Assessment auf Abruf, wie die Firmware-Analyse kryptografische Bibliotheken sichtbar macht und die frühe Migrationsplanung stützt.

Checkliste für die PQC-Migration

Bestandsaufnahme, Architektur, Tests und Lebenszyklusplanung müssen zusammen laufen. Sie müssen nicht jeden Algorithmus gleichzeitig ersetzen, brauchen aber ein Inventar, das zeigt, wo Risiken liegen und welche Produkte am schwersten zu ändern sind. Das NIST empfiehlt, jetzt mit der Migration zu beginnen, die US-Bundespolitik betont Inventar, stufenweise Umsetzung und Krypto-Agilität.

• Produktumfang und Verantwortung festlegen. Erfassen Sie Produktfamilien, Firmware-Zweige, Hardwarerevisionen, Abhängigkeiten, Märkte und Supportzeiträume. Benennen Sie Verantwortliche in Security, Entwicklung, Compliance und Zuliefermanagement, damit jede Migrationsentscheidung ein zuständiges Team hat.
• Kryptografie in der ausgelieferten Firmware erfassen. Scannen Sie echte Binaries und ordnen Sie Algorithmen, Bibliotheken, Protokolle, Zertifikate, Schlüssel und Signaturfunktionen zu. Gehen Sie nicht davon aus, dass Repositories das ausgelieferte Inventar vollständig abbilden, besonders wenn Zulieferer vorkompilierte Komponenten liefern.
• Ein Cryptographic Bill of Materials (CBOM) erstellen und pflegen. Verknüpfen Sie Funde mit Produktversionen und aktualisieren Sie das Inventar bei jeder Firmware-Änderung. Nutzen Sie es, um quantenanfällige Abhängigkeiten, Verantwortliche, Bearbeitungsstatus und prüfungsbedürftige Produkte zu identifizieren.
• Nach Daten- und Produktlebensdauer priorisieren. Lange schutzbedürftige Daten brauchen früh Aufmerksamkeit, weil das Risiko „harvest now, decrypt later“ hier am größten ist. Geräte mit eingeschränkten Update-Pfaden brauchen ebenfalls frühe Entscheidungen, gerade wenn Kunden Support über die aktuelle Hardwaregeneration hinaus erwarten.
• Jede kryptografische Verwendung klassifizieren. Trennen Sie Schlüsselaustausch, Verschlüsselung, Signaturen, Secure Boot, Update-Verifikation, Authentifizierung, Geräteidentität und Zertifikatsfunktionen. Der Austausch- und Testplan hängt davon ab, was die Kryptografie leistet und welche Folgen ein Ausfall für das Produkt hätte.
• Krypto-Agilität vor der Algorithmenwahl bewerten. Prüfen Sie, ob Firmware, Bootloader, Secure Elements, Protokolle, Schlüsselverwaltung und Backend-Dienste neue Verfahren tragen. Halten Sie fest, was fest verdrahtet, zulieferseitig kontrolliert oder hardwareseitig begrenzt ist, und schätzen Sie ein, ob die Lösung Software, Hardware oder beides erfordert.
• Auf standardisierte Algorithmen planen. Bewerten Sie ML-KEM für den Schlüsselaustausch und ML-DSA oder SLH-DSA für die jeweiligen Signaturanwendungen auf Basis der NIST-Standards und protokollspezifischer Empfehlungen. Vermeiden Sie proprietäre „quantensichere“ Konstruktionen, wenn standardisierte Verfahren verfügbar sind, und begründen Sie jede Algorithmenwahl für den Einsatzfall.
• Auf repräsentativer Hardware prototypisch testen. Messen Sie Bootzeit, Latenz, RAM, Flash, Bandbreite, Signaturgröße, Energiebedarf und Update-Verhalten. Testen Sie die gesamte Kette und nicht nur die kryptografische Bibliothek.
• Interoperabilität und Downgrade-Schutz prüfen. Verifizieren Sie Gateways, Cloud-Dienste, Zertifikate, Management-Werkzeuge und Peer-Geräte unter realistischen Netzbedingungen. Wenn Sie hybride oder verhandelte Verfahren nutzen, stellen Sie sicher, dass ein Angreifer kein inakzeptables älteres Verfahren erzwingen kann.
• Zulieferer und Beschaffung einbinden. Fragen Sie, welche Kryptografie Zulieferer bereitstellen, wie sie PQC unterstützen wollen und ob ihre Bibliotheken oder Hardware aktualisierbar sind. Nehmen Sie Anforderungen zur Krypto-Agilität in künftige Bewertungen, Verträge, Sicherheitsfragebögen und Auswahlkriterien auf.
• PQC mit dem Produktsicherheitsbetrieb verbinden. Verfolgen Sie Migrationsaufgaben gemeinsam mit Firmware-Risiken, SBOM-Änderungen, PSIRT-Arbeit und Schwachstellenmanagement. Ein wiederholbares PQC Readiness Assessment sollte in diese Arbeit einfließen und nicht als einmalige Tabelle enden. Bewahren Sie Nachweise auf, damit künftige Releases und Audits belegen können, warum ein Produkt priorisiert oder zurückgestellt wurde.
• Eigene Meilensteine setzen, bevor externe Fristen sie erzwingen. Nutzen Sie 2030, 2031 und 2035 als Referenzpunkte der US-Bundespolitik und des NIST, mit früheren Terminen, wo Datenlebensdauer oder Produktlebenszyklus es erfordern. Überprüfen Sie die Roadmap, wenn sich Standards, Zulieferunterstützung, Protokollprofile oder die Forschung zum Quantencomputing verändern.