CRA-Verschlüsselungsanforderungen für Hersteller

Der Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) legt seine Verschlüsselungsanforderung in Anhang I, Teil I (2)(e) fest: Die Vertraulichkeit gespeicherter, übermittelter oder anderweitig verarbeiteter Daten ist zu schützen, beispielsweise durch Verschlüsselung relevanter Daten im Ruhezustand oder bei der Übertragung mithilfe von Mechanismen nach dem Stand der Technik. Post-Quanten-Algorithmen werden nicht genannt. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026, und die Verordnung gilt vollständig ab dem 11. Dezember 2027. Produktteams wählen also bereits jetzt die Kryptografie für Geräte, die noch lange nach diesen Terminen unterstützt werden.

Was die Anforderung besagt und was nicht

Anhang I besteht aus zwei Teilen. Teil I listet die grundlegenden Cybersicherheitsanforderungen an das Produkt selbst auf, darunter das Inverkehrbringen ohne bekannte ausnutzbare Schwachstellen, eine standardmäßig sichere Konfiguration und die Vertraulichkeitsanforderung in (2)(e). Teil II listet die Anforderungen an die Behandlung von Schwachstellen auf, die über den gesamten vom Hersteller angegebenen Supportzeitraum gelten. Der Text ist auf EUR-Lex verfügbar (Regulation (EU) 2024/2847), unsere datierte Zusammenfassung finden Sie auf der Seite zur CRA-Verordnung.

Für ein Produktteam ergeben sich daraus drei Konsequenzen:

• Die Anforderung ist ergebnisorientiert. Sie nennt Vertraulichkeit und Mechanismen nach dem Stand der Technik, nicht RSA, nicht ECDH, nicht ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardisiert in NIST FIPS 203).
• Der Maßstab verschiebt sich. Ein Mechanismus, der bei der Konformitätsbewertung vertretbar ist, kann seine Vertretbarkeit verlieren, während das Produkt noch unterstützt wird.
• Nichts im Text verpflichtet Sie, heute Post-Quanten-Kryptografie auszuliefern. Ebenso rettet nichts ein Design, dessen Kryptografie sich nicht mehr ändern lässt, sobald sich der Stand der Technik weiterentwickelt.

Harmonisierte Normen können später konkretisieren, wie Anhang I zu erfüllen ist, und die Konformität mit einer im Amtsblatt veröffentlichten harmonisierten Norm begründet eine Konformitätsvermutung. Solange eine solche Norm nicht existiert und nicht veröffentlicht ist, ist ihr Inhalt unbekannt: Planen Sie nicht auf Grundlage von Annahmen darüber, was sie zur Kryptografie sagen wird. Die rechtlichen Inhalte hier dienen der Information und stellen keine Rechtsberatung dar.

Die Termine im CRA-Kalender

Für ein Gerät mit mehrjährigem Supportzeitraum ist der Planungshorizont nicht 2027. Er ist der letzte Tag, an dem Sie für kurz vor Supportende verkaufte Einheiten noch Sicherheitsupdates schulden.

Was Stand der Technik über einen Supportzeitraum vernünftigerweise bedeuten kann

Der CRA veröffentlicht keine Algorithmenliste. Der redliche Weg, den Stand der Technik zu bestimmen, besteht daher darin, zu prüfen, was Behörden und Normungsgremien tatsächlich veröffentlicht haben, unter Wahrung ihres jeweiligen Status.

Primärquellen: die EU-Roadmap, BSI TR-02102-1, die PQC-FAQ der ANSSI, NIST IR 8547 ipd und die Migrationszeitpläne des NCSC.

Unsere Interpretation, ausdrücklich als solche gekennzeichnet: Keiner dieser Texte macht Post-Quanten-Kryptografie zu einer CRA-Pflicht, und keine Behörde hat erklärt, dass klassische Kryptografie Anhang I heute nicht erfüllt. Ein Produkt, dessen Supportzeitraum über 2030 hinausreicht, wird jedoch in einen Zeitraum hinein verkauft, für den mehrere Behörden bereits Termine zur Ablösung klassischer Schlüsselvereinbarung veröffentlicht haben. Die vertretbare technische Position ist daher Agilität: die Fähigkeit, Algorithmen über ein reguläres Update zu wechseln, belegt in der Designdokumentation.

Krypto-Agilität in Firmware

Agilität ist eine Eigenschaft der Implementierung, kein Satz in einer Richtlinie. Vier Fragen entscheiden darüber, ob ein ausgeliefertes Gerät dem Stand der Technik folgen kann, und sie lassen sich vor dem Tape-out leichter beantworten als danach. Eine vertiefte Behandlung finden Sie im Artikel zur Krypto-Agilität.

• Aushandlung statt Konstanten. Algorithmenbezeichner, Named Groups und Schlüssellängen stammen aus der Konfiguration oder aus dem Protokoll-Handshake, niemals aus einer einkompilierten Konstante oder einem Puffer fester Größe. ML-KEM-Schlüssel und -Chiffretexte sind deutlich größer als Werte elliptischer Kurven, daher ist eine für 32-Byte-Schlüssel dimensionierte Struktur ein Hindernis auf Hardwareebene.
• Reserven. Planen Sie Flash, RAM und Handshake-Zeit für größeres Schlüsselmaterial ein. Messen Sie auf dem Zielgerät, nicht auf einer Workstation.
• Bibliotheksgrenze. Rufen Sie Kryptografie über eine schlanke interne Schnittstelle auf, damit der Anbieter austauschbar bleibt. Legen Sie die Mindestversion im Build fest: Die ML-KEM-TLS-Gruppen erfordern OpenSSL 3.5 oder neuer.
• Klassischer Fallback. Bevorzugen Sie hybride Schlüsselvereinbarung und halten Sie dahinter eine klassische Gruppe vor, damit ein Gerät auch dann eine Verbindung aufbaut, wenn die Gegenstelle älter ist.

Prüfen Sie auf einem Test-Build, was der Stack tatsächlich anbieten kann und was ein Geräte-Endpunkt aushandelt:

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

Die heute zu bevorzugende hybride Gruppe ist X25519MLKEM768 (IANA-Codepoint 0x11EC), mit SecP256r1MLKEM768 oder SecP384r1MLKEM1024, wo eine NIST-Kurve erforderlich ist; das IETF-Profil für hybride Post-Quanten-Schlüsselvereinbarung mit klassischen Verfahren in TLS 1.3 ist RFC 10024 (August 2026). Vorstandardisierte Kyber-Entwurfsgruppen wie X25519Kyber768Draft00 sind veraltet und sollten aus der Gerätefirmware entfernt werden. Testen Sie in Staging vor der Produktion, und behalten Sie die klassische Gruppe in der Liste.

Management-Ebenen von Geräten verdienen dieselbe Prüfung. OpenSSH 9.9 hat mlkem768x25519-sha256 eingeführt, OpenSSH 10.0 hat es zur Standard-Schlüsselvereinbarung gemacht, und OpenSSH 10.1 warnt, wenn eine Verbindung eine Schlüsselvereinbarung ohne Post-Quanten-Schutz aushandelt, laut den OpenSSH-Release-Notes.

Update-Signierung: der Teil, den Sie später nicht patchen können

Transportschlüssel wechseln mit jeder Sitzung. Ein in Silizium eingebrannter Vertrauensanker nicht. Aufgezeichneter Datenverkehr ist nur durch den Schlüsselaustausch geschützt, weshalb hybride Schlüsselvereinbarung Vorrang hat, während Signaturen später migrieren können; die Update-Signierung ist jedoch der eine Signaturpfad, bei dem eine späte Migration unmöglich sein kann, weil der Verifizierer in unveränderlichem Boot-Code liegt.

Praktische Maßnahmen, nach Nutzen geordnet:

1. Sehen Sie mehr als einen Verifizierungs-Slot oder eine Schlüsselhierarchie vor, damit ein neuer Signaturalgorithmus per Update statt per Rückruf eingeführt werden kann.
2. Entscheiden Sie jetzt, welche Post-Quanten-Signaturfamilie das Produkt akzeptieren könnte: ML-DSA (FIPS 204), SLH-DSA (FIPS 205) oder die zustandsbehafteten hashbasierten Verfahren LMS und XMSS aus NIST SP 800-208, die eine strikte Zustandsverwaltung erfordern, um die Wiederverwendung eines Einmalschlüssels zu vermeiden.
3. Halten Sie Code und Parameter der Signaturprüfung in einer aktualisierbaren Stufe, sofern das Sicherheitsmodell es zulässt, wobei die unveränderliche Stufe nur diese aktualisierbare Stufe verifiziert.
4. Dokumentieren Sie den Schlüsselwechsel: wer die Schlüssel verwahrt, wie ein kompromittierter oder veralteter Schlüssel außer Betrieb genommen wird und wie ein Gerät im Feld den neuen Schlüssel erfährt.

CNSA 2.0 legt bereits Ende 2030 für die ausschließliche Verwendung seiner Algorithmen bei der Signierung von Software und Firmware für US National Security Systems fest. Das ist keine EU-Pflicht, aber ein veröffentlichter Termin für dasselbe technische Problem und ein vernünftiger Anhaltspunkt, wenn Sie begründen, was Stand der Technik für ein über 2030 hinaus unterstütztes Produkt bedeutet.

Zuordnung der Anforderung zu Nachweisen

Nächster Schritt: messen, was Ihr Produkt auf der Leitung zeigt

Bevor Sie eine einzige Zeile CRA-Dokumentation schreiben, ermitteln Sie, was Ihre eigenen Endpunkte und Update-Server heute tatsächlich aushandeln. Sie können Ihre Domain kostenlos mit PQC Status scannen, um die TLS-Versionen, hybriden ML-KEM-Gruppen, Cipher Suites und die Zertifikatskette zu sehen, die ein externer Client beobachtet. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Konformitätsbescheinigung. Nutzen Sie das Ergebnis als erste Zeile Ihres Inventars und arbeiten Sie sich dann nach innen bis zur Firmware vor: Schlüssellängen in Strukturen, Bibliotheksversionen im Build und die Anzahl der Verifizierungs-Slots in Ihrer Boot-Kette.