Sicherheitstests für EV-Ladesysteme

Dieser Beitrag wurde aus dem Englischen übersetzt. Zum Originalbeitrag.

Sicherheitstests für EV-Ladesysteme

Elektrofahrzeuge werden immer beliebter — allein die deutsche Regierung gewährt 2026 einen Kaufzuschuss von bis zu 6.000 € für neue batterieelektrische Fahrzeuge (BEVs). Parallel dazu ist auch die Ladeinfrastruktur gewachsen: Öffentliche Ladestationen säumen Autobahnen und Parkplätze, und Wallboxen zu Hause gehören in vielen Garagen längst zum Alltag. Betrachtet man das aus der Sicherheitsperspektive, drängt sich jedoch eine andere Frage auf: Was genau wird in dem Moment über dieses Kabel ausgetauscht, in dem Sie ein Fahrzeug anschließen — und lässt sich das manipulieren?

In dieser Artikelserie führen wir Sie durch den V2G-Kommunikations-Stack und seine Sicherheitsarchitektur und demonstrieren anschließend eine Reihe praxisnaher Angriffe auf eine reale Open-Source-Implementierung eines EVCC. Einige der Angriffe erfordern Hardware-Zugriff auf die Stromleitung, andere lassen sich vollständig in Software nachstellen. Auf diesen Unterschied weisen wir jeweils klar hin. Das hier ist Teil 1 — die Grundlage zu Protokollen und Bedrohungsmodell, auf der die weiteren Teile der Serie aufbauen.

Vehicle-to-Grid (V2G)

V2G beschreibt das Konzept einer bidirektionalen Kommunikation zwischen einem Elektrofahrzeug und der Ladeinfrastruktur. In dem Moment, in dem Sie das Fahrzeug anschließen und das Dashboard die Station erkennt, beginnt ein strukturierter Protokollaustausch: Batteriestatus, maximale Ladeleistung, Abrechnungspräferenzen und Sitzungsdaten werden über das Kabel übertragen, noch bevor ein einziges Watt Strom fließt. Geregelt wird dieser Austausch durch eine Familie internationaler Standards, die die Interoperabilität zwischen Fahrzeugen und Ladegeräten unterschiedlicher Hersteller sicherstellen.

Im Zentrum jeder Ladesitzung kommunizieren zwei Steuergeräte miteinander:

• EVCC (EV Communication Controller) — Client-seitig im Fahrzeug

• SECC (Supply Equipment Communication Controller) — Server-seitig in der Ladestation

Why EV Charging Security Matters

Das Ladekabel ist nicht nur ein Leiter für Energie — es ist ein bidirektionaler Datenkanal zwischen Fahrzeug und externer Infrastruktur. Damit entsteht eine Angriffsfläche, die es bei konventionellen Fahrzeugen so nicht gab und die jedes Mal exponiert ist, wenn Fahrer:innen an einer öffentlichen Station laden.
Zentrale Sicherheitsaspekte:

• Authentifizierung und Abrechnung: Nur autorisierte Fahrzeuge sollten laden dürfen, und Fahrer:innen sollten nur von legitimen Stationen abgerechnet werden, mit denen sie tatsächlich verbunden waren.
• Datenintegrität: Ladeparameter — Energielimits, Preise, Sitzungskennungen — dürfen während der Übertragung nicht veränderbar sein.
• TLS-Durchsetzung: ISO 15118-2 schreibt TLS für die Applikationsschicht vor. In realen Implementierungen unterscheidet sich jedoch stark, wie konsequent das umgesetzt wird; manche prüfen Zertifikate überhaupt nicht.
• Auswirkungen auf das Stromnetz: Eine kompromittierte oder manipulierte EV-Flotte könnte angewiesen werden, gleichzeitig Strom zu beziehen oder zurückzuspeisen — mit potenziell netzinstabilisierenden Lastspitzen, für die es bei konventionellen Fahrzeugen kein vergleichbares Szenario gibt.

Das sind keine rein theoretischen Risiken. Die Angriffe, die wir später in diesem Artikel zeigen, belegen, dass sich die Lücke zwischen Standardanforderungen und realer Implementierung mit gängigen Werkzeugen ausnutzen lässt — ohne spezialisierte Hardware.

Architektur von EV-Ladesystemen

Bevor wir in Protokolle und Angriffe einsteigen, lohnt ein Blick auf das Gesamtsystem. In diesem Artikel konzentrieren wir uns auf den Kommunikationslink zwischen Fahrzeug und Ladestation — dieser Link ist jedoch Teil einer größeren Kette von Akteuren.

Darüber hinaus gibt es zwei unterschiedliche Lademodi — AC und DC — und sie unterscheiden sich darin, wo die AC/DC-Wandlung stattfindet. Beim AC-Laden erfolgt die Umwandlung im Fahrzeug über das Onboard-Ladegerät. Beim DC-Laden findet die Umwandlung in der Ladestation statt, und Gleichstrom wird direkt an die Batterie geliefert. Jeder Modus hat seine eigene Steckverbinderfamilie.

Die Kombination aus Typ 2 und CCS Combo 2 ist in Europa der dominierende Standard. Aus Sicherheitssicht sind vor allem diese Pins relevant:

• CP (Control Pilot): PWM-basierte Low-Level-Signalisierung (IEC 61851) mit überlagerten HomePlug-GreenPHY-PLC-Signalen für die High-Level-Kommunikation nach ISO 15118

• PP (Proximity Pilot): Erkennung des angeschlossenen Kabels

• PE (Protective Earth): Schutzleiter

Über die CP-Leitung wird der gesamte V2G-Anwendungsdatenverkehr transportiert — einschließlich Authentifizierungstoken, Sitzungskennungen und Ladeparametern. Damit ist sie die primäre Angriffsfläche auf der physikalischen Ebene.

Low-Level-Kommunikation (physikalische Schicht)

IEC 61851 definiert die elektrische Low-Level-Schnittstelle, die aufgebaut sein muss, bevor überhaupt Anwendungskommunikation möglich ist. Sie ist für die physikalische Verbindung und die Datenverbindungsschicht verantwortlich und nutzt dabei zwei Mechanismen:

• HomePlug Green PHY — physikalische Schicht und Datenlink über die Stromleitung
• SLAC — Link Discovery und Pairing zwischen EV und Ladegerät

Die elektrische Schnittstelle stellt zwei Pilotsignale bereit:

CP-Zustandsmaschine:

Anhand des Spannungspegels des CP-Signals können beide Seiten den aktuellen Zustand des Ladevorgangs bestimmen:

Die High-Level-Kommunikation nach ISO 15118 liegt auf IEC 61851 auf — für eine vollständige V2G-Sitzung müssen beide Ebenen vorhanden sein.

HomePlug Green PHY (HPGP)

Die High-Level-V2G-Nachrichten werden per Power-Line Communication (PLC) über die Stromleitungen des Ladekabels übertragen. PLC ist das allgemeine Verfahren, Daten über elektrische Leitungen zu senden; HomePlug Green PHY (HPGP) ist das speziell für EV-Laden ausgewählte Profil — es definiert Modulation, Kodierung und Netzwerkbildung in einer standardisierten, energiearmen Form, die für die begrenzte Powerline-Umgebung geeignet ist.

Ein HPGP-Modem kann entweder im PEV-Modus oder im EVSE-Modus arbeiten. Beide Seiten müssen zunächst ein gemeinsames logisches Netzwerk bilden — ein AV Logical Network (AVLN) — bevor IP-Verkehr möglich ist. Genau an dieser Stelle kommt SLAC ins Spiel.

SLAC — Signal Level Attenuation Characterization

SLAC ist der Mechanismus, mit dem ein EV die physisch nächstgelegene EVSE auswählt, wenn mehrere Ladegeräte in Reichweite sind. Das ist sicherheitsrelevant: Das Fahrzeug sollte sich nur mit der Station koppeln, an die es physisch angeschlossen ist — nicht mit einer benachbarten.

Ablauf:

1. Das EV sendet ein Broadcast CM_SLAC_PARAM.REQ.

2. Alle EVSEs in Reichweite antworten mit CM_SLAC_PARAM.CNF.

3. Das EV sendet eine Reihe von SOUNDING-Paketen (CM_START_ATTEN_CHAR.IND).

4. Jede EVSE misst die empfangene Signalstärke und antwortet mit CM_ATTEN_CHAR.IND, das ihre MAC-Adresse und die mittlere Dämpfung enthält.

5. Das EV wählt die EVSE mit der geringsten Dämpfung aus (stärkstes Signal = physisch am nächsten).

6. Das EV sendet CM_SLAC_MATCH.REQ an die ausgewählte EVSE.

7. Die EVSE antwortet mit CM_SLAC_MATCH.CNF — der NMK (Network Membership Key) wird dabei im Klartext übertragen.

8. Beide Seiten konfigurieren ihre PLC-Modems mit dem gemeinsamen NMK und bilden ein AVLN.

Die sicherheitsrelevante Bedeutung von Schritt 7 ist erheblich. Der NMK ist der symmetrische Schlüssel, mit dem der gesamte HPGP-Verkehr auf diesem Segment verschlüsselt wird. Da er in CM_SLAC_MATCH.CNF ungeschützt übertragen wird, kann jeder Angreifer, der diesen einzelnen Frame beobachtet — selbst als passiver Sniffer auf einem gemeinsam genutzten PLC-Segment — dem Netzwerk sofort beitreten und den nachfolgenden PLC-Verkehr entschlüsseln, einschließlich der darauf aufsetzenden ISO-15118-2-Kommunikation auf der Applikationsebene.

High-Level Communication (HLC)

Sobald die Low-Level-PLC-Verbindung aufgebaut ist und die EVSE per SLAC ausgewählt wurde, beginnt die High-Level-Kommunikation. Hier werden die eigentlichen V2G-Applikationsnachrichten ausgetauscht: Protokollverhandlung, Sitzungsaufbau, Authentifizierung, Ladeparameter, Energieübertragung und Abrechnung. All das wird durch die Normenfamilie ISO 15118 geregelt.

Die HLC nutzt mehrere Protokolle, die aus klassischer Web- und Netzwerksicherheit bekannt sind:

• TCP/IP — zuverlässiger Transport zwischen EV und Ladegerät
• TLS — gegenseitige Authentifizierung und Verschlüsselung des Anwendungskanals
• EXI — komprimierte Binärkodierung von XML-Nachrichten
• XML — Nachrichtenstruktur und Schemadefinition
• V2GTP — Transport-Wrapper für ISO-15118-2-Nachrichten über TCP

Da es sich um allgemeine Protokolle handelt, lassen sich bekannte Angriffsklassen aus der Web- und Netzwerksicherheit direkt übertragen — etwa TLS Stripping, Zertifikatsspoofing, Man-in-the-Middle-Angriffe oder Replay-Angriffe.

Zuordnung zum OSI-Modell

Die Einordnung des vollständigen V2G-Stacks in das OSI-Modell erleichtert das Verständnis für die Schichten — und die jeweilige Angriffsfläche.

Der gesamte V2G-Verkehr nutzt IPv6-Link-Local-Adressen — globales Routing ist nicht erforderlich, und die gesamte Sitzung bleibt auf das einzelne PLC-Netzsegment beschränkt, das während SLAC aufgebaut wird.

V2GTP — Vehicle-to-Grid Transport Protocol

V2GTP ist ein minimales Framing-Protokoll, das in ISO 15118-2 definiert ist. Es sitzt direkt oberhalb von TLS/TCP und unterhalb der EXI-kodierten XML-Nutzlast. Sein einziger Zweck besteht darin, jede Nachricht mit einem 8-Byte-Header zu versehen, damit der Empfänger weiß, wie groß die Nutzlast ist und welchen Typ sie hat:

V2GTP stellt weder Zuverlässigkeit noch Reihenfolge oder Routing bereit — das übernimmt TCP. Das Protokoll ist bewusst schlank gehalten: gerade genug Framing, damit der Empfänger die folgenden Daten korrekt interpretieren kann.

SECC Discovery Protocol (SDP)

Sobald der PLC-Link steht, muss der EVCC die IP-Adresse und den TCP-Port des SECC ermitteln, bevor er eine V2G-Sitzung aufbauen kann. Dafür nutzt er das SECC Discovery Protocol (SDP): einen leichtgewichtigen, UDP-basierten Austausch, der vollständig über das HomePlug-GreenPHY-Netz läuft, bevor überhaupt eine TCP-Verbindung existiert.

Ablauf:

Die SECC_ResponseMessage enthält:

• die IPv6-Adresse und den TCP-Port des SECC für die V2G-Sitzung

• das Feld SecurityProtocol: 0x00 = TLS erforderlich, 0x10 = kein TLS

Nach dem SDP öffnet der EVCC eine TCP-Verbindung zu der beworbenen Adresse und dem angegebenen Port.
Der sicherheitskritische Punkt dabei: Der gesamte SDP-Austausch ist weder authentifiziert noch verschlüsselt. Er findet statt, bevor TLS aufgebaut wird, und es gibt keinen Mechanismus, um zu überprüfen, ob die SDP-Antwort tatsächlich von der Station stammt, an die das Kabel angeschlossen ist. Jeder Knoten auf dem Link, der den Multicast des EVCC hört und schneller als der echte SECC antwortet, kann eine beliebige Adresse, einen beliebigen Port und ein beliebiges Sicherheitsniveau bewerben. Genau diese Eigenschaft nutzen wir später im Szenario SDP Spoofing aus.

Nachrichtenfluss einer V2G-Sitzung

Sobald die TCP- oder TLS-Verbindung steht, folgen EVCC und SECC einer festen Request-/Response-Sequenz.

Sitzungsaufbau:

Laden und Beenden der Sitzung:

Jede Nachricht wird vor dem Versand über TCP in einen V2GTP-Header eingekapselt.

Die Nachrichten AuthorizationReq und SessionSetup transportieren die Identität des Fahrzeugs und die Abrechnungsdaten. Wenn TLS nicht erzwungen wird — oder vor Sitzungsbeginn entfernt wird — sind all diese Nachrichten für jeden passiven Beobachter auf dem gemeinsam genutzten PLC-Segment im Klartext sichtbar.

EXI-Codierung/-Decodierung

Alle ISO-15118-2-Applikationsnachrichten sind XML-Dokumente, werden aber im EXI-Format (Efficient XML Interchange) übertragen, um die Größe auf dem begrenzten Powerline-Kanal zu minimieren.

XML-Signaturen: V2G-Nachrichten mit sensiblen Daten (z. B. AuthorizationReq) enthalten innerhalb der V2GTP-Nutzlast eine digitale XML-Signatur und bieten so zusätzlich zur Transportsicherheit per TLS auch Integrität auf Nachrichtenebene. Selbst wenn es einem Angreifer gelingt, sich in den Datenpfad einzuklinken, ist das unbemerkte Manipulieren signierter Nachrichten damit deutlich schwieriger, als sie lediglich mitzulesen.
Für die EXI-Decodierung wird das XML-Schema (XSD) benötigt, das die Nachrichtenstruktur definiert — ohne das passende Schema lassen sich EXI-Bytes nicht interpretieren.

ISO 15118-2 verwendet:

• V2G_CI_MsgDef.xsd — oberste Nachrichtenhülle

• V2G_CI_MsgBody.xsd — alle Request-/Response-Bodies

• V2G_CI_MsgHeader.xsd — Session-ID, Signatur

• V2G_CI_MsgDataTypes.xsd — gemeinsame Datentypen

• V2G_CI_AppProtocol.xsd — SupportedAppProtocol-Nachrichten

Überblick über die Bedrohungslage

Mit dem vollständigen Kommunikations-Stack vor Augen lassen sich bekannte Angriffsklassen den jeweiligen V2G-Protokollschichten zuordnen. Viele davon sind direkte Analoga zu Verfahren, die aus der klassischen Netzwerksicherheit bekannt sind — neu ist hier vor allem die physische Zugänglichkeit des Ziels. Jede öffentliche Ladestation ist ein potenzieller Einstiegspunkt, erreichbar für jede Person mit einem kompatiblen EV oder einem PLC-Adapter.

Angriffe auf der physikalischen Ebene (SLAC/HPGP) erfordern ein Hardware-PLC-Kit und physische Nähe zum Ladekabel oder demselben Stromleitungssegment. Alles ab SDP aufwärts lässt sich in einem rein softwarebasierten Labor demonstrieren — genau dieses Setup bauen wir als Nächstes auf.