HSM-Test, die Grenze beweisen, nicht nur die Kryptografie.

Um diese Lücke geht es hier. Ein HSM ist nicht wertvoll, weil es AES ausführt. Es ist wertvoll wegen der Grenze, die es durchsetzt: ein Ort, an dem Schlüssel liegen und auf den der Anwendungskern unter dem angenommenen Bedrohungsmodell nicht direkt zugreifen kann, selbst wenn die Anwendungssoftware kompromittiert ist. Die eigentliche Frage beim HSM-Test ist also nicht "funktioniert die Kryptografie". Sie lautet "lässt sich die Kryptografie umgehen". Das sind zwei verschiedene Fragen, und den Angreifer interessiert nur die zweite.

1. Warum der Bus jedem glaubt

Bordnetze wurden für Vertrauen gebaut, nicht für Angreifer. Auf einem klassischen CAN-Bus ist eine wohlgeformte Botschaft per Voreinstellung eine authentische Botschaft. Nichts auf der Leitung muss beweisen, wer gesendet hat. Die Branche hat sich im letzten Jahrzehnt von diesem Vertrauensmodell entfernt, doch viele eingesetzte Architekturen tragen seine Annahmen weiter.

Diebe haben aus dieser Annahme ein Geschäft gemacht. Bei den CAN-Injection-Diebstählen von 2022 und 2023 erreichten Kriminelle die Verkabelung hinter einem Scheinwerfer, klemmten sich auf zwei CAN-Leitungen und injizierten gefälschten Verkehr, der vertrauenswürdige Steuergeräte im Autorisierungsablauf imitierte. Der Bus glaubte ihnen, weil nichts auf ihm je das Gegenteil verlangte. Eine der zentralen vorgeschlagenen Gegenmaßnahmen war Nachrichtenauthentisierung auf Basis hardwaregeschützter Schlüssel. Genau dafür ist ein HSM da.

Die Lehre ist älter. Die ferngesteuerte Kompromittierung eines Jeep Cherokee 2015 sprang auf den CAN-Bus über und löste einen Rückruf von 1,4 Millionen Fahrzeugen aus, weithin als erster Cybersecurity-Rückruf der Branche bezeichnet. Authentisierung auf dem Bus war auch damals die fehlende Maßnahme.

2. Was HSM-Test üblicherweise bedeutet, und wo er aufhört

Die meisten Verifizierungspläne von OEMs und Zulieferern konzentrieren sich darauf, das beabsichtigte Verhalten unter erwarteten Bedingungen nachzuweisen:

• Funktionale Kryptografie: Known-Answer-Vektoren für AES-CMAC, ECC- und RSA-Signieren und -Verifizieren, den Zufallszahlengenerator, die Schlüsselableitung und den Schlüssel-Lebenszyklus aus Provisionierung, Update und isolierter Speicherung.
• Secure Boot: Signaturprüfung in jeder Stufe, Anti-Rollback und das korrekte Verhalten, wenn das Image manipuliert ist.
• SecOC: ein Message Authentication Code (der AUTOSAR-SecOC-Authentikator), gekürzt, um in die CAN-Nutzlast zu passen, plus ein Freshness-Wert. Die Länge ist pro PDU konfigurierbar und selbst ein Sicherheits-Kompromiss, etwa 24 bis 32 Bit, der Fälschungsresistenz gegen Busbandbreite abwägt. Man testet, dass ein gefälschter MAC abgewiesen wird, dass eine wiederholte Botschaft abgewiesen wird und dass Freshness-Desynchronisation behandelt wird.

Ein Detail entscheidet, ob SecOC im Feld hält. Freshness ist ein monoton steigender Wert je Freshness Manager, doch nur seine niederwertigen Bits laufen über den Bus; der Empfänger rekonstruiert den vollen Wert, und der MAC wird über Data ID, Nutzlast und volle Freshness gebildet. Deshalb ist Freshness-Desynchronisation, das Auseinanderdriften der Zähler von Sender und Empfänger, der reale Fehlerfall, den man testen muss, nicht nur ein sauberes Replay.

All das ist notwendig. Nichts davon ist hinreichend. Diese Tests können bestehen, während der Schlüssel weiterhin auslesbar ist, denn funktionale Korrektheit sagt nichts darüber aus, was ein Angreifer mit der Hardware anstellen kann.

3. Was erfüllt sein muss, bevor sich ein HSM lohnt

Ein HSM in ein Design zu setzen macht es nicht sicher. Es ist nur gerechtfertigt, wenn zuvor eine Reihe von Anforderungen erfüllt ist, und jede davon muss man verifizieren, nicht annehmen:

• Eine Bedrohungsanalyse, die den Maßstab setzt. ISO/SAE 21434 beginnt mit einer TARA in Kapitel 15. Die gewählte HSM-Klasse muss zur Bedrohung passen, der sie gegenübersteht. SHE liefert einen festen AES-128-Block (CMAC und CBC) mit wenigen Schlüsselplätzen und Secure Boot, ohne asymmetrische Engine. EVITA Light ist rein symmetrisch für Sensor- und Aktorknoten. EVITA Medium ergänzt eine interne CPU und intern-asymmetrische Verfahren für die Authentisierung zwischen Steuergeräten. EVITA Full ergänzt hardwarebeschleunigte Asymmetrie (ECC oder RSA) und ist für Gateway und V2X dimensioniert. SHE und die EVITA-Stufen sind grob ausgerichtet, nicht identisch. Medium zu wählen, wo das Bedrohungsmodell die Kryptografie für externe Schnittstellen von Full verlangt, ist ein Klassen-Mismatch-Befund; weit über der Bedrohung zu wählen sind Kosten, die sich nicht rechtfertigen lassen.
• Schlüssel, die innerhalb der Grenze bleiben. Langzeitgeheimnisse werden innerhalb des HSM erzeugt, gespeichert und verwendet, jede Exposition außerhalb dieser Grenze wird minimiert und begründet. Der RAV4-Fall zeigt, was "in Software" kostet.
• Eine vollständige Secure-Boot-Kette. Jede Stufe authentisiert die nächste, ohne Lücke, durch die ein unsigniertes Image rutscht, und Anti-Rollback verankert in einem monotonen Hardware-Zähler (Fuse- oder OTP-gestützt) innerhalb des HSM, nicht in einem Wert, den der Anwendungskern überschreiben kann. Sonst liegt die Rollback-Prüfung selbst in der umgehbaren Fläche.
• Eine SecOC-Konfiguration, die die Lücke tatsächlich schließt. Welche Botschaften geschützt sind, die MAC-Länge, das Freshness-Schema und was mit ungeschütztem Verkehr auf demselben Bus geschieht.
• Ein Performance-Budget, das hält. Authentisierung erhöht Latenz und Last, und eine Lenk- oder Bremsbotschaft hat eine Frist. Wenn der sichere Pfad sie unter Worst-Case-Last nicht einhält, scheitert das Design aus einem anderen Grund.
• Unabhängige Absicherung passend zur Risikobehauptung. Wo Produkt oder Markt es verlangen, kann der Nachweis FIPS 140-3 für das Modul, Common Criteria für Widerstand gegen physische Angriffe, SESIP für eine schnellere komponierbare Bewertung des Vertrauensankers oder Gleichwertiges umfassen. Viele Serieneinsätze tragen keines davon; entscheidend ist, den Nachweis an die Behauptung anzupassen.

Jede dieser Anforderungen ist eine Behauptung, die Sie vor einem Assessor verteidigen werden. Genau dort beginnt reines Testen, nicht mehr auszureichen.

4. Die Tests, die den Angreifer wirklich abbilden

• Fehlerinjektion, durch Spannungs- oder Takt-Glitching, EM oder Laser: einen Befehl überspringen, einen Vergleich verfälschen, eine Secure-Boot-Prüfung oder einen Ausleseschutz umgehen. Das ist die RAV4-Technik.
• Seitenkanalanalyse, Strom und EM: einen Schlüssel rekonstruieren, indem man die physische Leckage von Zwischenwerten während einer Krypto-Operation korreliert, etwa CPA oder DPA auf Hamming-Gewicht-Leckage, ganz ohne logischen Fehler. Sie wird nur durch Masking- und Hiding-Gegenmaßnahmen geschlagen, die selbst verifiziert werden müssen.
• Negativtests und Fuzzing der HSM-Befehlsschnittstelle und der Diagnoseschnittstelle: fehlgeformte Längen, unzulässige Schlüssel-Handles, unzulässige Zustandsübergänge, Grenzwerte. Einschließlich Debug- und Fertigungsschnittstellen, die in Serienkonfigurationen zugänglich geblieben sind.
• Penetrationstest: eine durchgängige, gegnerische Bewertung am echten Steuergerät, im Fahrzeug.

In AUTOSAR ist hier die Kette entscheidend. Anfragen laufen durch den Crypto Service Manager, dann das Crypto Interface, dann einen Crypto Driver, und dieser Treiber verteilt entweder an eine Software-Implementierung oder an das HSM. SecOC sitzt über dem Crypto Service Manager für die Busauthentisierung. Die Sicherheitsfrage ist, an welche Treiberinstanz ein gegebener Schlüssel gebunden ist: ein Schlüssel, dessen Schnittstellenkanal auf den Software-Treiber aufgelöst wird, erhält nie Hardware-Isolation, so korrekt der höhere Aufruf auch aussieht. Das ist strukturell der RAV4-Fehler.

Wer nur die funktionale Suite laufen lässt, prüft das Schloss, indem er es mit dem richtigen Schlüssel aufschließt. Wer diese Tests laufen lässt, prüft es so, wie es derjenige tut, der hinein will.

5. Wo die Normen hinzeigen, und wo sie schweigen

ISO/SAE 21434 regelt den Prozess: TARA in Kapitel 15, sichere Produktentwicklung in den Kapiteln 9 und 10 sowie Verifizierung und Validierung über den Lebenszyklus. Sie erkennt Secure Boot und Vertrauensanker als wichtige technische Maßnahmen an. Entscheidend verlangt ihr Validierungsschritt, dass die Erreichung der Cybersecurity-Ziele durch Penetrationstests nachgewiesen und jede gefundene Schwäche in das Schwachstellenmanagement zurückgeführt wird. Mit anderen Worten: die Norm fordert das gegnerische Testen bereits, für das hier argumentiert wird. Sie ist keine Krypto-Test-Spezifikation.

Die Regulierung machte den Prozess verpflichtend, über eine Struktur mit zwei Zertifikaten. UNECE R155 verlangt ein Cyber-Security-Management-System des Herstellers, R156 ein separates Software-Update-Management-System. Jedes wird unabhängig zertifiziert und ist Voraussetzung für die Typgenehmigung. Das CSMS galt für neue Fahrzeugtypen ab Juli 2022 und erstreckt sich ab Juli 2024 in der Wirkung auf neu zugelassene Fahrzeuge der erfassten Klassen, vorbehaltlich nationaler Übergangsregelungen. Das HSM ist die Hardware, die die geforderten technischen Maßnahmen durchsetzbar macht.

AUTOSAR leitet Kryptografie durch einen Stack, der auf einem Software- oder einem Hardware-Treiber landen kann, mit SecOC darüber für die Busauthentisierung. Die Konformitätsverfahren zertifizieren das Modul. Doch keines davon beweist für sich, dass Ihr konkreter Bootvorgang, Ihre konkrete SecOC-Konfiguration und Ihre konkrete Schlüsselisolation auf jedem Pfad halten, auch auf dem Pfad, auf dem ein Fehler im denkbar schlechtesten Mikrosekundenmoment landet.

Breit testen. Die kritischen Eigenschaften beweisen.

Testen tastet Eingaben ab. Ein Angreifer durchsucht den Raum, auf den es ankommt. Ein Glitch in genau einer Mikrosekunde, oder ein Replay bei genau einem Zählerstand, ist ein Zustand, den Ihre Testkampagne nie aufzählen würde. Formulieren Sie die wichtigsten Garantien daher als zu beweisende Invarianten, nicht als auszuführende Fälle:

• Ein Schlüssel verlässt die HSM-Grenze auf keinem Pfad im Klartext.
• Secure Boot weist ein unsigniertes oder zurückgesetztes Image auf jedem Pfad ab.
• SecOC nimmt eine Botschaft nur an, wenn der MAC verifiziert und die Freshness strikt steigt.

Formulieren Sie jede als Sicherheitseigenschaft, "der Schlüssel verlässt auf keinem Pfad das Modul im Klartext", die auf endlichen Ausführungspräfixen prüfbar ist. Modellieren Sie einen Glitch als nichtdeterministischen, gegnerischen Übergang im Zustandsautomaten, sodass der Model Checker die Off-Nominal-Zustände erkundet, die eine gerichtete Kampagne nicht aufzählen kann: Befehl übersprungen, Vergleich verfälscht, Reset mitten im Boot. Der Beweis deckt dann die Fehlerklassen ab, die Sie im Modell explizit dargestellt haben, nicht jeden physischen Glitch im Universum, aber genau die, die ein Testplan immer wieder verfehlt. Das ist dieselbe Disziplin, die wir an den Sicherheits-Zertifizierungstoren anwenden. Sie macht aus "wir haben vierhundert Fälle laufen lassen, und sie bestanden" ein "wir haben bewiesen, dass die Eigenschaft über den modellierten Zustandsraum hält, auch unter den modellierten Fehlern". Auf funktionale Korrektheit testen. Die Grenze beweisen.

6. Wie das Ihre Freigabe verändert

Eine bestandene funktionale HSM-Suite ist der Boden, nicht die Decke. Ergänzen Sie die Tests des Angreifers, Glitch, Seitenkanal und Negativtests, und für die wichtigsten Eigenschaften ergänzen Sie einen Beweis statt einer Stichprobe. Behandeln Sie Schlüsselisolation, Boot-Integrität und Nachrichtenauthentizität als Freigabekriterien, nicht nur als Testergebnisse. Entscheiden Sie bewusst, was in Software läuft und was hinter der Grenze, denn der RAV4-Fall zeigt, was die Software-Entscheidung kosten kann.

Seien Sie ehrlich: Beruhte die HSM-Freigabe in Ihrem letzten Programm auf den Fällen, die Sie getestet haben, oder auf einer Eigenschaft, von der Sie bewiesen haben, dass sie nicht umgangen werden kann?

---

Sie möchten einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Nennen Sie uns die Norm, das Item oder Asset, den Assessor und Ihren Termin. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, auf die obigen Punkte abgebildet — Ihre zum Behalten, ob Sie uns beauftragen oder nicht.

Cyber-Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-06-09.