EV Charging Security Testing

EV Charging Security Testing

Electric vehicles are becoming increasingly popular — the German government alone offers a purchase subsidy of up to €6,000 (2026) for new battery-electric vehicles (BEVs). Charging infrastructure has followed: public stations line highways and parking lots, and home wallboxes are now a common sight in residential garages. But when we look at this through a security lens, a different question emerges: what is actually exchanged over that cable the moment you plug in, and can it be tampered with?

In this series of articles, we walk you through the V2G (Vehicle-to-Grid) communication stack and its security architecture, then demonstrate a series of practical attacks against a real open-source EVCC implementation. Some of the attacks we cover require hardware access to the power line; others can be reproduced entirely in software. We will make that distinction clear as we go. This is Part 1 — the protocol and threat model foundation that the rest of the series builds on.

Vehicle-to-Grid (V2G)

V2G is the concept of enabling bidirectional communication between an electric vehicle and the charging infrastructure. The moment you plug in, your car’s dashboard acknowledges the station, and a structured protocol exchange begins: battery status, maximum charging power, billing preferences, and session credentials all travel over the cable before a single watt of electricity is delivered. This exchange is governed by a family of international standards that ensure interoperability between vehicles and chargers from different manufacturers.

At the heart of every charging session, two controllers communicate with each other: - EVCC (EV Communication Controller) — client side, inside the vehicle - SECC (Supply Equipment Communication Controller) — server side, inside the charging station.

Why EV Charging Security Matters

The charging cable is not just a power conduit — it is a bidirectional data channel between the vehicle and external infrastructure. That makes it an attack surface that simply did not exist in conventional vehicles, and one that is exposed every time a driver plugs in at a public station.

Key security concerns: - Authentication and billing: only authorised vehicles should be able to charge, and drivers should only be billed by legitimate stations they actually connected to - Data integrity: charging parameters — energy limits, pricing, session identifiers — must not be modifiable in transit - TLS enforcement: ISO 15118-2 mandates TLS for the application layer, yet real-world implementations vary widely in how strictly they enforce it; some skip certificate validation entirely - Grid-scale impact: a compromised or manipulated fleet of EVs could be instructed to draw or discharge power simultaneously, destabilising grid load in ways that have no precedent in conventional vehicles

These are not theoretical concerns. The attacks we demonstrate later in this article show that a gap between the standard’s requirements and an actual implementation can be exploited with common tools — no specialised hardware required.

EV Charging Architecture

Before diving into protocols and attacks, it helps to understand the broader ecosystem. In this article we focus on the communication link between the EV and the charging station, but that link sits inside a larger chain of actors.

There are also two distinct charging modes — AC and DC — and they differ in where the AC-to-DC conversion takes place. In AC charging, the conversion happens inside the vehicle via an onboard charger. In DC charging, the conversion happens inside the station and DC power is delivered directly to the battery. Each mode has its own connector family.

The Type 2 / CCS Combo 2 combination is the dominant standard in Europe. From a security perspective, the key pins are: - CP (Control Pilot): PWM-based low-level signaling (IEC 61851) with HomePlug GreenPHY PLC signals superimposed on the same wire for ISO 15118 high-level communication - PP (Proximity Pilot): cable connection detection - PE (Protective Earth)

It is the CP line that carries all of the V2G application data — including authentication tokens, session identifiers, and charging parameters — making it the primary attack surface at the physical layer.

Low-Level Communication (Physical Layer)

IEC 61851 defines the low-level electrical interface that must be established before any application-layer messaging can begin. It is responsible for the physical and data-link connection, and it relies on two mechanisms:

• HomePlug Green PHY — physical and data link layer over the power line
• SLAC — link discovery and pairing between the EV and charger

The electrical interface provides two pilot signals:

CP state machine:

Based on the voltage level of the CP signal, both sides can determine the current state of the charging process:

ISO 15118 high-level communication is layered on top of IEC 61851 — both must be present for a complete V2G session.

HomePlug Green PHY (HPGP)

High-level V2G messages travel over the charging cable’s power lines using Power-Line Communication (PLC). PLC is the general technique of transmitting data over electrical cables; HomePlug Green PHY (HPGP) is the specific profile selected for EV charging — it defines the modulation, encoding, and network formation rules in a standardised, low-power form suitable for the constrained power-line environment.

A HPGP modem can operate in either Plug-in Electric Vehicle (PEV) or EVSE (charger) mode. Both sides must form a shared logical network — an AV Logical Network (AVLN) — before any IP traffic can flow. That network formation is where SLAC comes in.

SLAC — Signal Level Attenuation Characterization

SLAC is the mechanism by which an EV selects the physically closest EVSE when multiple chargers may be in range. This matters for security: the EV should pair only with the station it is physically plugged into, not a neighbouring one.

Sequence:

1. EV broadcasts CM_SLAC_PARAM.REQ
2. All EVSEs in range respond with CM_SLAC_PARAM.CNF
3. EV sends a series of SOUNDING packets (CM_START_ATTEN_CHAR.IND)
4. Each EVSE measures received signal strength and replies with CM_ATTEN_CHAR.IND containing its MAC and average attenuation
5. EV selects the EVSE with the lowest attenuation (strongest signal = physically closest)
6. EV sends CM_SLAC_MATCH.REQ to the selected EVSE
7. EVSE responds with CM_SLAC_MATCH.CNF — the NMK (Network Membership Key) is transmitted in cleartext
8. Both sides configure their PLC modems with the shared NMK and form an AVLN

The security implication of step 7 is significant. The NMK is the symmetric key that encrypts all HPGP traffic on that segment. Because it is transmitted without any protection in CM_SLAC_MATCH.CNF, any attacker who can observe that single frame — even a passive sniffer on a shared PLC segment — immediately gains the ability to join the network and decrypt all subsequent PLC traffic, including the ISO 15118-2 application layer above it.

High-Level Communication (HLC)

Once the low-level PLC link is established and the EVSE has been selected via SLAC, the high-level communication begins. This is where the actual V2G application messages are exchanged: protocol negotiation, session setup, authentication, charging parameters, power delivery, and billing. All of this is governed by the ISO 15118 standard family.

HLC relies on several protocols that will be familiar from standard web and network security:

• TCP/IP — reliable transport between EV and charger
• TLS — mutual authentication and encryption of the application channel
• EXI — compressed binary encoding of XML messages
• XML — message structure and schema definition
• V2GTP — the transport wrapper that frames ISO 15118-2 messages over TCP

Because these are general-purpose protocols, the attack classes well known from web and network security — TLS stripping, certificate spoofing, man-in-the-middle, replay attacks— apply here directly.

Mapping to OSI Model

Mapping the full V2G stack to the OSI model makes the layering — and the attack surface at each layer — easier to reason about:

All V2G traffic uses IPv6 link-local addresses — no global routing is required, and the entire session is scoped to the single PLC network segment formed during SLAC.

V2GTP — Vehicle-to-Grid Transport Protocol

V2GTP is a minimal framing protocol defined in ISO 15118-2. It sits directly above TLS/TCP and below the EXI-encoded XML payload. Its sole purpose is to wrap each message with an 8-byte header so the receiver knows how large the payload is and what type it is:

V2GTP does not provide reliability, ordering, or routing — those are handled by TCP. It is intentionally thin: just enough framing for the receiver to parse what follows.

SECC Discovery Protocol (SDP)

Once the PLC link is up, the EVCC needs to find the SECC’s IP address and TCP port before it can open a V2G session. It does this using the SECC Discovery Protocol (SDP): a lightweight UDP-based exchange that runs entirely over the HomePlug GreenPHY network, before any TCP connection is established.

Flow:

The SECC_ResponseMessage contains: - SECC’s IPv6 address and TCP port for the V2G session - SecurityProtocol field: 0x00 = TLS required, 0x10 = no TLS

After SDP, the EVCC opens a TCP connection to the advertised address and port.

The security-critical detail here is that the SDP exchange is entirely unauthenticated and unencrypted — it takes place before TLS is established, and there is no mechanism to verify that the SDP response came from the station the cable is plugged into. Any on-link node that hears the EVCC’s multicast and replies faster than the real SECC can advertise any address, port, and security level it chooses. We exploit exactly this property in the SDP spoofing scenario later.

V2G Message Session Flow

Once the TCP (or TLS) connection is open, the EVCC and SECC follow a fixed request/response sequence:

Session setup:

Charging and teardown:

Each message is wrapped in a V2GTP header before being sent over TCP.

The AuthorizationReq and session setup messages carry the vehicle’s identity and billing credentials. If TLS is not enforced — or is stripped before the session begins — every one of these messages is visible in plaintext to any passive observer on the shared PLC segment.

EXI Encoding/Decoding

All ISO 15118-2 application messages are XML documents, but transmitted in EXI (Efficient XML Interchange) format to minimise size on the constrained power-line channel.

XML Signatures: V2G messages that carry sensitive data (e.g., AuthorizationReq) include an XML digital signature inside the V2GTP payload, providing message-level integrity in addition to transport-level TLS. This means that even if an attacker manages to sit on the data path, modifying signed messages without detection requires breaking the signature — a much harder problem than simply reading them.

EXI decoding requires the XML Schema (XSD) that defines the message structure — without the correct schema, EXI bytes cannot be interpreted. ISO 15118-2 uses: - V2G_CI_MsgDef.xsd — top-level message envelope - V2G_CI_MsgBody.xsd — all request/response bodies - V2G_CI_MsgHeader.xsd — session ID, signature - V2G_CI_MsgDataTypes.xsd — shared data types - V2G_CI_AppProtocol.xsd — SupportedAppProtocol messages.

Overview of the Threat Landscape

With the full communication stack in mind, we can map known attack classes to the V2G protocol layers they target. Many of these are direct analogues of techniques well understood in traditional network security — what is new here is the physical accessibility of the target. Every public charging station is a potential entry point, reachable by anyone with a compatible EV or a PLC adapter.

Attacks in the physical layer (SLAC/HPGP) require a hardware PLC kit and physical proximity to the charging cable or the same power-line segment. Everything from SDP upward can be demonstrated in a software-only lab — which is exactly what we set up next.