Warum PQC Für Automotive jetzt Thema ist
Vernetzte Fahrzeuge sind längst keine rollenden Inseln mehr. Sie hängen am Backend, nehmen Over-the-Air Updates entgegen, sprechen mit Apps, perspektivisch mit der Verkehrsinfrastruktur und mit anderen Fahrzeugen. Gleichzeitig bleiben sie 10 bis 15 Jahre im Feld. Das ist der zentrale Konflikt. Wir verbauen heute Kryptografie, die unter Umständen im Jahr 2038 nicht mehr sicher ist, das Fahrzeug aber immer noch fährt. Genau hier setzen die Warnungen zu Post Quantum Cryptography (PQC) an. Sicherheitsforscher beschreiben seit Jahren das Szenario “Harvest now, decrypt later”: Angreifer zeichnen heute verschlüsselte Datenströme auf und warten, bis ein ausreichend leistungsfähiger Quantenrechner zur Verfügung steht, um RSA oder ECC zu brechen. Dann sind Backend Protokolle, OTA Manifeste oder Fahrzeugschlüssel nachträglich lesbar. apriorit.com erklärt dieses Vorgehen sehr anschaulich, auch wenn der Fokus dort eher auf klassischen IT Szenarien liegt. Für Automotive gelten allerdings dieselben physikalischen und mathematischen Realitäten, nur eben mit deutlich längerer Lebensdauer.
Damit entsteht eine einfache These für OEMs: Wer im europäischen und nordamerikanischen Markt im Jahr 2035 compliant sein will, muss Funktionen, Architekturen und Lieferketten bereits in den Jahren 2026 und 2027 entsprechend ausrichten. Denn Fahrzeugprogramme, die zwischen 2028 und 2032 SoP haben, stehen in der Typgenehmigung mehrere Jahre vorher fest und gehen bis weit in die 2040er in den Betrieb. Warten auf endgültige Standards bedeutet faktisch verspätete Einführung.
Regulatorischer und politischer Kontext (EU und USA, “2035-Fenster”)
Die EU hat 2024 und 2025 klar gemacht, dass sie einen koordinierten Übergang zu quantenresistenter Kryptografie anstrebt. Die Roadmap der Kommission und die Empfehlung an die Mitgliedstaaten zielen auf einen Abschluss der Migration bis Mitte der 2030er Jahre. (Digitalstrategie Europa)
Die USA verfolgen mit dem National Security Memorandum 10 und den nachgelagerten OMB Vorgaben denselben Zeithorizont. Für Bundesbehörden soll die Migration bis 2035 abgeschlossen sein. Die NIST liefert dazu die notwendigen Bausteine. Das heißt nicht, dass jedes System 2035 automatisch abgeschaltet wird. Es heißt aber, dass Behörden und Betreiber ab jetzt nachweisen müssen, dass sie wissen, welche kryptografischen Abhängigkeiten sie haben und wie sie sie ablösen. (csrc.nist.gov)
Automotive i.S. der Entwicklung eines derivatsbezogenen E/E-System ist typischerweise langsamer als klassische IT Produkte. Ein Cloud-Service kann in Monaten auf PQC umgestellt werden. Ein Fahrzeugprogramm dagegen nicht. Deshalb muss das Automotive Umsetzungsfenster zeitlich vor dem politischen “2035-Ziel” liegen. Hinzu kommt die normative Ebene: Die UN R155 verlangt einen systematischen Umgang mit zukünftigen Bedrohungen. Eine Bedrohung, deren Realisierung der Gesetzgeber selbst für 2035 antizipiert, gehört in die CSMS Betrachtung. PQC lässt sich damit sauber unter die Pflicht zur kontinuierlichen Bedrohungsanalyse und das sich über den gesamten Lebenszyklus des Fahrzeugs erstreckende Risiko Management einordnen. Wer später erklären kann, dass PQC im CSMS als Zukunftsrisiko bewertet, priorisiert und mit Maßnahmen versehen wurde, steht im Audit deutlich besser da, auch wenn 2028 noch nicht jede ECU PQC spricht.
Kryptografische Grundlagen
Klassische asymmetrische Verfahren wie RSA oder Elliptic Curve Cryptography leben von Problemen, die für heutige Rechner sehr schwer zu lösen sind. Ein ausreichend großer, fehlertoleranter Quantencomputer kann diese Probleme mit Shors Algorithmus in praktikabler Zeit lösen. Dann ist aus heutiger Sicht starke Public Key Kryptografie plötzlich schwach. Genau deshalb sprechen Behörden von einer künftigen Kryptoklippe.
Im Fahrzeugumfeld arbeiten wir typischerweise mit einer Kombination aus symmetrischen Schlüsseln, etwa für schnelle ECU zu ECU Kommunikation, und asymmetrischen Verfahren für Identitäten, Verteilung von Schlüsseln, OTA Signaturen oder Backend-zu-Fahrzeug-Kanäle. Symmetrische Kryptografie ist gegen Quantenrechner vergleichsweise robust. Mit verdoppelter Schlüssellänge lässt sie sich weiter nutzen. Das eigentliche Problem liegt in den asymmetrischen Bausteinen, also überall dort, wo wir heute RSA 3072 oder ECDSA P 256 einsetzen.
PQC will genau diesen Teil ersetzen. Statt schwer zu faktorisierender Zahlen werden mathematische Probleme genutzt, die auch für Quantenrechner hart sind, etwa gitterbasierte Verfahren. Deshalb ist PQC kein Styling Feature für Kryptografieabteilungen, sondern eine Notwendigkeit für jede E/E Architektur, die sich auf asymmetrische Verfahren stützt. Automotive tut das praktisch immer.
Geeignete PQC-Algorithmen für Fahrzeuge und OTA
NIST hat die ersten PQC Standards 2024 veröffentlicht. Für Schlüsselaustausch beziehungsweise Key Encapsulation ist CRYSTALS Kyber vorgesehen, für digitale Signaturen CRYSTALS Dilithium, ergänzt durch SPHINCS plus und FALCON für spezielle Anwendungsfälle.
Für Automotive lassen sich daraus recht direkt Nutzungsszenarien ableiten.
- Kyber für den Aufbau sicherer Kanäle zwischen Backend und Fahrzeug. Heute wird dafür oft ein TLS Profil genutzt, das auf ECC basiert. Künftig kann dasselbe Pattern mit PQC realisiert oder in einer hybriden Variante betrieben werden. Hybride Variante bedeutet, dass klassisches ECC und PQC parallel genutzt werden. Fällt eine Seite, bleibt die andere sicher.
- Dilithium für Signaturen von OTA Paketen, Software Manifests und Zertifikaten im Fahrzeug. Die Signaturkette im SUMS Kontext wird damit auch in einem Szenario mit Quantenrechnern verifizierbar bleiben.
Wichtig ist der Hinweis, dass diese Algorithmen aktuell noch Feintuning und Profiling für eingebettete Umgebungen brauchen. NIST liefert Standards. OEMs müssen sie in Profile, Libraries, HSM Implementierungen und Security Middleware gießen, die zu ihren Toolchains und ECU Klassen passen. Das ist der Teil, der nicht bis 2035 warten kann.
Herausforderungen im ressourcenbeschränkten Umfeld
PQC hat einen Preis. Schlüssel werden größer, Signaturen werden größer, Handshakes brauchen mehr Rechenzeit. Das ist in einer Head Unit oder in einem zentralen Zonencontroller beherrschbar. In einer kleinen Body Control ECU mit 1 MB Flash und historisch gewachsenem Bootloader sieht das anders aus.
Daraus ergeben sich mehrere technische Hausaufgaben:
Erstens: OTA Pakete und Manifeststrukturen werden größer. Das belastet Bandbreite und Flash-Zeiten. Wer heute schon an den Grenzen seines OTA-Fensters ist, muss früh planen, ob er Signaturen zentral verifiziert und beim Downstream nur noch kurz validiert.
Zweitens: Speicherlimitierungen. PQC Bibliotheken sind nicht immer schlank. Hier bietet sich Offloading auf Secure Gateways oder zentrale Controller an, die für das Fahrzeug signaturenprüfende Funktionen übernehmen. Kleinere ECUs erhalten dann bereits verifizierte Pakete.
Drittens: Hybride Verfahren in der Übergangsphase. Hybride KEX oder Signaturen erlauben den schrittweisen Umbau der Fahrzeugflotte. Das ist wichtig, weil nicht jede ECU zur selben Zeit ersetzt oder neu geflasht werden kann.
Viertens: Crypto Agility. Wer heute seine Kryptostacks nicht aktualisierbar auslegt, wird später gezwungen sein, kostspielige Redesigns zu machen. Crypto Agility ist exakt das, was PQC Anbieter, ENISA und auch mehrere US Dokumente seit Jahren empfehlen. Man soll austauschen können, bevor man muss. (enisa.europa.eu)
Integration in CSMS und SUMS
Die UN R155 verlangt, dass zukünftige Bedrohungen identifiziert, bewertet und mit Maßnahmen adressiert werden. Quantenfähige Angreifer sind genau das. Es gibt inzwischen öffentliche Dokumente der EU, der USA und der britischen NCSC, die 2035 als Ziel nennen. Damit kann niemand ernsthaft behaupten, die Bedrohung sei spekulativ. (Digitalstrategie Europa)
In der Praxis können OEMs PQC in drei Schritten in ihre CSMS Dokumentation einführen.
Phase 2025 bis 2027: Aufnahme von PQC in die TARA, Bewertung der Assets, die heute abgegriffen und später entschlüsselt werden könnten, Proof of Concepts in Laborumgebungen, Profilierung von Kyber und Dilithium für eigene ECUs, Definition von hybriden Profilen, Anpassung der Security Architektur, Ergänzung der SUMS-Prozessdokumente um PQC fähige Signaturketten.
Phase 2027 bis 2030: Seriennahe Piloten. Konkrete Umsetzung für OTA Signaturen, Backend zu Fahrzeug Kommunikation, PKI Prozesse, HSM Firmware. In dieser Phase sollten erste Typgenehmigungsunterlagen bereits zeigen, dass PQC technisch vorgesehen ist, auch wenn sie noch nicht flächendeckend im Fahrzeug verteilt ist.
Phase 2030 bis 2035: Breiter Rollout, Migration der Flotte, Handling von Legacy ECUs, Aufbau von Werkzeugketten für Zertifikatsverwaltung und Firmware Signaturen. Hier wird es wichtig sein, gegenüber Behörden und technischen Diensten nachzuweisen, dass Fahrzeuge des Modelljahres 2032 kryptografisch nicht im Jahr 2042 nackt im Netz stehen.
Die vorbeschriebene Timeline ist kein Pfad für Cyber-Enthusiasten. Das ist vielmehr die logische Konsequenz aus dem Lebenszyklusgedanken der UN R155 und aus den Vorgaben der EU und der USA. Wer es ignoriert, riskiert in der Marktüberwachung der Aufsichtsbehörden später unangenehme Fragen.
Architektur-Implikationen
Moderne E/E-Architekturen haben einen Vorteil: Sie besitzen zentrale Knoten mit genug Leistung. Genau dort sollte PQC zuerst einziehen – Security Gateways, Domänencontroller für Infotainment oder ADAS, zentrale Kommunikations-Hubs. Sie können PQC Handshakes terminieren, OTA Signaturen prüfen und anschließend an schwächere ECUs verteilen. Damit wandert der PQC Aufwand aus den kleinsten Steuergeräten in die zentralen Bausteine.
Für OTA bedeutet das ein Muster. Das Backend signiert seine Pakete PQC-sicher. Das Fahrzeug verifiziert diese Signatur zentral. Erst danach werden die Pakete im Fahrzeug verteilt. Die kleineren ECUs müssen entweder gar nicht mehr signaturenprüfen oder nur noch mit einem internen, leichteren Verfahren. Das reduziert Entwicklungsaufwand und hält die Bandbreitenkosten im Griff.
Für V2X gilt etwas Ähnliches. Dort hängen wir oft an internationalen Profilen und an Security Credential Management Systemen. Die Community diskutiert bereits, wie PQC-fähige V2X Zertifikate aussehen können. OEMs sollten diese Diskussion beobachten und in ihren Architektur Roadmaps Platz dafür lassen. Wer V2X heute ohne Crypto Agility ausliefert, verbaut sich die PQC Tür der 2030er.
Start small, document early, design for agility
Die unangenehme Wahrheit lautet “Wer auf finale, in allen Gremien abgestimmte PQC Profile wartet, kommt zu spät”. Die Standardisierung ist weit genug, um Architekturen, Updateketten und Toolchains auf PQC vorzubereiten. NIST hat geliefert. Die EU hat eine Roadmap. Die USA haben eine Deadline. Damit gibt es ausreichend Material, um im CSMS die Bedrohung zu benennen, in der TARA zu bewerten und in der Security Architektur einzuplanen. (NIST)
Automotive muss früher liefern als 2035, weil Automotive länger lebt. Sinnvoll ist ein gestaffelter Ansatz: PQC zuerst in zentralen Controllern und im Backend-zum-Fahrzeug-Kanal. Hybride Verfahren einsetzen, solange nicht alle ECUs mitziehen können. Document as you go in CSMS und SUMS, damit Auditoren sehen, dass der OEM die Gefahr nicht verdrängt. Und Crypto Agility als nicht verhandelbare Eigenschaft der nächsten E/E-Generation. Wer das heute einplant, schützt sich vor sehr teuren Nachrüstprojekten ab 2032. Wer es nicht tut, bezahlt später mit Feldaktionen in einer vernetzten, softwaredefinierten Flotte. Keine gute Geschichte.
