Mit der Reform des europäischen Roadworthiness Package wird ein altes Prüfregime in eine neue Welt gezwungen. Periodische technische Inspektionen (PTI) und Roadside Inspections (RSI) sollen nicht mehr nur mechanische Zustände, sichtbare Mängel und klassische OBD-Artefakte abklopfen, sondern zunehmend das prüfen, was moderne Fahrzeuge tatsächlich steuert: elektronische Sicherheitssysteme. In diesem Zuge tauchen „Softwareversion“ und „Software-Integrität“ nicht als nette Zusatzidee auf, sondern als Mangelkriterien in einem digitalisierten Prüfkonzept. Der Effekt ist simpel und brutal: Software-Integrität wird von einer internen Security-Kategorie zu einem öffentlich relevanten Roadworthiness-Merkmal.
Das klingt zunächst nach gesundem Menschenverstand. Schließlich kann ein Fahrzeug technisch „intakt“ aussehen und dennoch über manipulierte oder funktional degradierte Software gefährlich sein. Das Problem beginnt an der Stelle, an der Politik „Integrität“ fordert, aber Technik entscheiden muss, was „Integrität“ überhaupt heißt und wie sie beweisbar wird.
ePTI und elektronische Schnittstelle: Das neue Prüfregime entsteht über einen digitalen Kanal
Die EU-Kommission, der Rat sowie die ETSC setzen erkennbar auf ePTI, also digitalisierte Prüfprozesse, die stärker über strukturierte Daten und standardisierte elektronische Zugänge funktionieren. Der entscheidende operative Hebel ist die Nutzung der elektronischen Fahrzeugschnittstelle für Prüfzwecke. Damit wird faktisch ein offizieller Kommunikationskanal etabliert, über den Prüfer elektronische Sicherheitssysteme beurteilen sollen. Im Textkontext ist das nicht als „Option für Enthusiasten“ gedacht, sondern als Mechanismus, um moderne Systeme überhaupt sinnvoll bewerten zu können.
Aus Cybersecurity-Sicht ist das ein Paradigmenwechsel: Prüfungen werden nicht nur digital, sie werden digital interaktiv. Ein Prüfregime, das sich früher über sichtbare Artefakte und mechanische Logik absicherte, hängt plötzlich an einem Interface, das in jeder Angriffsflächenanalyse ganz oben steht.
Die CSMS-Relevanz: PTI/RSI bringt neue Akteure und neue Angriffsflächen, ohne dass das Auto „mehr Vertrauen“ verdient hätte
Sobald Integrität über PTI/RSI geprüft wird, entsteht eine neue Klasse legitimer Interaktoren. Es gibt dann nicht mehr nur OEM, Werkstatt und Diagnose im „Service“-Sinne, sondern Prüforganisationen, Prüftools, Betreiberketten und eventuell nationale Datenpfade, die im Namen der Verkehrssicherheit systematisch an Fahrzeuge herantreten. Das ist regulatorisch gewollt, sicherheitstechnisch aber ein Geschenk an jede Person, die gerne mit geklonten Tools, gestohlenen Zertifikaten oder manipulierten Prüfpfaden arbeitet.
Gleichzeitig vergrößert sich der Compliance-Beweisraum. Ein CSMS muss nicht mehr nur zeigen, dass Fahrzeuge intern gegen Angriffe robust sind, sondern dass der neue Prüfkanal selbst missbrauchsresistent gestaltet ist und die Prüfaussagen verlässlich sind. Damit landet ein Teil der „Roadworthiness“-Zukunft plötzlich in Threat Modeling, Key Management, Authentisierung und Zugriffskontrolle.
Der zentrale Denkfehler: „Integrität“ ohne Kryptographie ist ein Self-Report, und Self-Reports sind ein Witz
Die Versuchung ist groß, „Software-Integrität“ über Dinge wie Versionsnummern, Konfigurationsstände oder irgendeinen Diagnosestatus abzubilden. Genau das ist jedoch der Punkt, an dem das Ganze in Security-Theater kippt. Sobald ein Angreifer ECU- oder Gateway-Kontrolle hat, lassen sich solche Signale fälschen. Das System behauptet dann seine eigene Unschuld, während es längst kompromittiert ist.
Damit ist die harte Wahrheit ausgesprochen: Eine Integritätsprüfung, die vom potenziell kompromittierten System selbst berichtet wird, ist kein Integritätsnachweis. Sie ist bestenfalls ein Indikator für „ungefähr so, wie es aussieht“, und schlimmstenfalls ein offizieller Stempel für eine sauber gefälschte Realität.
Was stattdessen benötigt wird: Prüfen heißt attestieren, nicht plaudern
Wenn „Software integrity incorrect“ als Mangelkriterium ernst genommen werden soll, braucht es eine Aussage, die nicht auf Vertrauen basiert, sondern auf Verifikation. Das führt direkt zu kryptographischer Attestation. In einem robusten Modell sendet das Prüfgerät eine frische Challenge, typischerweise in Form einer Nonce (einmaliger Zufalls-Token), und das Fahrzeug antwortet mit einem signierten Token, der die Integrität prüfrelevanter Domänen in minimaler Form belegt. Dieser Token muss so aufgebaut sein, dass eine Prüfstelle die Signatur mit einer Trust Chain verifizieren kann, idealerweise auch offline. Der Token muss außerdem sparsam sein, damit keine unnötigen Datenflüsse entstehen, die später als „praktisch“ missbraucht werden.
Die Semantik ist dabei wichtiger als das Buzzword. Es reicht nicht, „irgendetwas“ zu signieren. Relevant ist, dass ein messbarer, manipulationsresistenter Bezug zu sicherheitsrelevanten Softwarezuständen besteht, und dass Replay oder einfache Nachahmung technisch unattraktiv werden. Ohne Freshness und ohne Root-of-Trust-nahe Messkette ist auch Attestation schnell nur ein hübscher Anstrich.
Die Schnittstelle selbst ist das Risiko: Eine staatlich legitimierte Angriffsfläche ist immer eine Angriffsfläche
Sobald ePTI über eine elektronische Schnittstelle funktioniert, ist diese Schnittstelle zwangsläufig attraktiv. Ein CSMS, das hier nicht radikal auf least privilege setzt, baut einen „legalen“ Seiteneingang. Deshalb muss der PTI-Kanal als eng definierter read-only Dienst konzipiert werden, der keinen Pfad in Programmierung, Codierung oder Security-Unlock-Funktionalität besitzt. Es muss außerdem eine klare logische Trennung gegenüber Werkstatt- und OEM-Engineering-Funktionen geben, damit der PTI-Kanal nicht versehentlich zu einem alternativen Steuerungsweg wird. Und weil selbst legitime Kanäle missbraucht werden, sind Rate-Limits, Abuse Detection und manipulationsgeschützte Logs keine Kür, sondern Hygiene.
Das alles ist nicht akademisch. Es ist die Differenz zwischen „TÜV als Sicherheitskontrolle“ und „TÜV als neuer Standard-Angriffspfad“.
Trust für Prüfer: Ohne Authentisierung und Revocation endet das im Chaos
Ein weiteres Problem wird gerne unterschätzt: Wer darf eigentlich prüfen? Wenn der PTI-Kanal offen ist, ist er offen für alle. Wenn er zu restriktiv oder national fragmentiert ist, endet das in Interoperabilitätsfrust und Schattenlösungen, die später sicherheitstechnisch nicht mehr einholbar sind.
Ein tragfähiges Modell muss daher Prüftools und Betreiber eindeutig authentisieren. Es muss autorisieren, welche Daten und Funktionen im PTI-Kontext zulässig sind. Es muss Revocation unterstützen, weil kompromittierte Prüfgeräte oder Schlüssel in der realen Welt kein theoretisches Risiko sind, sondern eine Frage der Zeit. Ohne Revocation ist „Trust“ lediglich eine einmal ausgestellte Einladung zur Daueranwendung.
„Integrity incorrect“ ist ein Incident
Wenn Integrität als Mangelkriterium auftaucht, wird ein Fail-Zustand regulatorisch relevant. Das führt zwingend zu einem Incident-Pfad. Ein Fahrzeug darf bei einem Integritätsbefund nicht gefährlich degradieren oder sich selbst unkontrolliert lahmlegen. Die Kommunikation muss so gestaltet sein, dass sie nicht versehentlich Angriffsdetails liefert. Die Beweissicherung muss funktionieren, weil der Streitfall nicht hypothetisch ist: Er entsteht genau dann, wenn ein Prüfer „nicht okay“ sagt und der Halter oder der Hersteller widerspricht.
Damit wird deutlich, warum das CSMS hier nicht „nur am Rand“ betroffen ist. Es geht um sichere Fail-States, nachvollziehbare Diagnostik im Security-Sinne und forensische Verwertbarkeit, ohne dabei neue Datenschutz- oder Missbrauchsprobleme zu erzeugen.
Der kritische Punkt: Pseudo-Compliance mit echter Angriffsfläche
Die gefährlichste Konstellation ist eine, in der „Integrität“ politisch gefordert wird, aber technisch als Versionscheck implementiert werden darf. Dann entsteht eine neue Schnittstelle, ein neuer Datenfluss und ein neuer Pass/Fail-Mechanismus, während die Aussagekraft gering bleibt und die Missbrauchsfläche steigt. Das ist der Moment, in dem Roadworthiness nicht sicherer wird, sondern nur bürokratisch beruhigt.
Die saubere Schlussfolgerung aus Cybersecurity-Sicht ist unspektakulär, aber zwingend: Eine Integritätsprüfung im PTI/RSI-Kontext muss auf verifizierbarer Attestation basieren. Alles andere ist im Kern ein Self-Report, und Self-Reports sind kein Sicherheitsnachweis.
CSMS: Was in den Scope gehört, wenn Roadworthiness digital wird
Im CSMS gehört PTI/RSI als eigener Actor und eigener Abuse-Cluster in die TARA, inklusive Szenarien wie Rogue Tester, geklonte Tools, Replay, Man-in-the-Middle und gezielte Datenmanipulation. Im Requirements-Set müssen Attestation, Authentisierung, Autorisierung, least privilege, Segregation und Revocation explizit auftauchen. In den Evidence-Artefakten müssen Crypto-Design, Trust-Chain, Key-Management, Abuse-Monitoring und manipulationsgeschützte Logging-Architektur nachweisbar sein. Und operativ muss ein Playbook existieren, das „integrity incorrect“ als Incident behandelt und nicht als kosmetischen Mangelcode.
Das ist keine Überreaktion. Es ist die Mindestantwort auf einen Gesetzgeber, der gerade dabei ist, aus dem TÜV einen softwarebasierten Vertrauensrichter zu machen.
