Witch of the Wires

The State of EVSE Security in 2024

Edison Electric Institute projects 25 million electric vehicles on the road by 2030. Meanwhile, EVSE (Electric Vehicle Supply Equipment, that is, EV chargers), is projected to grow tenfold, from about 50,000 deployed in 2023 to 500,000 by 2030. As electric vehicles continue to proliferate in response to the ongoing climate crisis, so too do the opportunities for their misuse. In this post, we will examine how contemporary EVSE is vulnerable at both the device and network level, and steps that can be taken to mitigate these risks

At the most fundamental level, the EVSE ecosystem, or EVSEcosystem, consists of four parts –

The EV is plugged into the EVSE; if all goes well, the EVSE will soon send a direct current signal to the EV that it can use to steadily charge. The EVSE is responsible for generating this signal from the alternating current signal that it receives from the grid.* Meanwhile, EVSE communicates with a Charging System Management Solution in the cloud that is responsible for collecting drivers’ payment information from the EVSE and authorizing a charge session.

When I refer to ‘the grid’ above, I mean the transmission tower and buildings inside the box labeled ‘Utility and Building/Facility Management’. These represent the local Electric Transmission and Distribution provider, as well as the Building Management System at the location where the EVSE is installed. Note that the Electric T&D provider only communicates with the cloud CSMS and the BMS, and only sends AC power to the BMS.

That is, from the point of view of electric grid operators, EVSE is just another high-power appliance like a washer or central AC. No direct traffic should be observed between grid assets and EVSE, T&D providers typically have no ability to administer devices, and devices are typically not administered via OT protocols such as Modbus or DNP3. EVSE Security is better understood as an IIoT problem rather than an OT problem (Industrial Internet of Things vs Operational Technology), and it is the responsibility of EVSE owners/operators to secure this equipment. If not…

The ChargePoint HomeFlex/CPH50 is a typical example of EVSE. This is a Level 2 charger with max power output 12kW, which is equivalent to a dishwasher or central air conditioning. A L2 charger can charge a vehicle to travel 200 miles in about 8 hours.** It’s a consumer-grade charger designed for home use and will cost you $550 as of Sep 2024.

Internally, the CPH is powered by the Atmel AT91SAM9N12, a 32-bit ARM9 processor. In addition to chips for RAM and flash memory, it has a Inventek ISM43340 to provide Wi-Fi and Bluetooth connectivity. All these chips are on the main control board – additionally, there is a second board for measuring power characteristics, and this board is powered by a TI MSP430F67651A, whose datasheet lists it as a polyphase metering system-on-a-chip.

Front and back of a printed circuit board, which is the control board for the CPH50 EV charger

Front and back view of the CPH control board

Front view of the CPH metrology board

The photos and internal configuration of the CPH board were provided by Zero Day Initiative as part of the January 2024 Pwn2Own Automotive competition held in Tokyo. This was the first year for this competition, and EVSE wasn’t ready for the big leagues – every piece of EVSE at the competition was targeted at least once, and the results were devastating. As Dean Keuper put it –

It was very clear from the start that security played no role in designing these products. They were not designed to withstand even the most common types of attacks

Most participants held their findings close to their chest until Hacker Summer Camp BlackHat/DEFCON, where we got a treasure trove of attacks and exploits. In no particular order –

For the purposes of this post, let’s take a look at some of the vulnerabilities found in a friendly CPH50. There’s not too much here compared to some other devices, just

  • Command injection via the WiFi password field (CVE-2024-23921)
  • Failure to properly validate the CSMS certification, enabling MitM (CVE-2024-23970)
  • Remote code execution via bug in OCPP message handling (CVE-2024-23971)
  • An SSH vendor backdoor over 343 (this was likely the tunnel ChargePoint closed the day before the competition)
  • Exposed S3 buckets accessible with AWS creds available on device

You know, just standard stuff. The kind of vulnerabilities you find in any EVSE, really. Just normal easily-exploitable critical-impact vulns.

Moving onto the network horrors…

The Open Charge Point Protocol is the primary communications protocol between EVSE and its associated CSMS. As we can see, it is just one of several protocols designed to facilitate a seamless charge session for the driver –

This is an elaboration on the network diagram presented above, with EVSE not listed, the utility and BMS separate, and a new entity, the Grid Services Aggregator, added. This should further reinforce the observation that there is no direct traffic between the utility and the EVSE. Instead, the utility communicates with the BMS and GSA over one of two automated demand response protocols, IEEE 2030.5 or OpenADR 2.0. These are outside the scope of this post, but they exist to facilitate the integration of distributed energy resources such as wind and solar. Meanwhile, the EVSE is available to communicate over WAN/Cellular to the CSMS in the cloud, as well as with any EVSE network operator designed to facilitate management of multiple EVSE sites. Although the diagram only lists OCPP traffic from the CSMS to the ENO, OCPP is also used when communicating with individual EVSE or individual sites.

That’s a lot of acronyms! Fortunately, to secure the EVSE network, you just have to remember two things –

  • OCPP is the main EVSE control protocol used to start/stop sessions and update device firmware, among other things
  • OCPP 1.6 is the most popular version in the field, and it’s does everything over plaintext, making it trivial to MitM. The current version, OCPP 2.0, addresses this and other security concerns.

Elmo et al. (2023) have demonstrated that the plaintext nature of OCPP 1.6 makes it trivial to load malicious firmware onto the system. In the attack illustrated below, they utilize log4shell as the local remote code execution vulnerability to be exploited. This is a reasonable assumption given the reliance of EVSE on the open source community, as well as the sheer magnitude of initial log4shell exposure at the end of 2021. Any one of the vulnerabilities discussed above can also be used, and more will certainly be made available in the coming months and years. The only requirement for this attack is that the adversary is on the same network as the EVSE to be attacked and capable of sniffing/injecting traffic.

In short, OCPP 1.6 should be considered as secure as WEP for WiFi or ECB for cryptography – it’s a gaping vulnerability, and asset owners should configure the device(s) to explicitly use a more secure protocol (OCPP 2.0) as soon as technically and organizationally feasible.

Today, experts estimate that if every single piece of EVSE across the country were rolled into a botnet and turned on/off in unison, they would still represent a small enough portion of total demand for electricity to be unable to significantly impact grid reliability.*** However, as EVSE continues to proliferate and XFCs become more widespread, this dynamic could very easily change.

An EVSE botnet capable of impacting grid reliability would be devastating, especially given the ease of attacks listed above. However, this is still just a future hypothetical, and we can take steps today to keep it that way. Owners and operators of EVSE can follow some basic steps to drastically reduce the attack surface for their devices –

  • Ensure that your asset inventory contains, at minimum:
    • all EVSE (model number, firmware version), 
    • all network gear used by EVSE, 
    • all authorized users of EVSE, 
    • all user accounts on EVSE
  • For all user accounts previously identified:
    • ensure password is securely set and stored in credential management solution. 
    • ensure procedures to update password(s) are in place and executed regularly.
  • Ensure EVSE is routinely patched to latest firmware and a process exists to regularly check for/install security updates
  • Ensure device is on secure subnet (i.e. don’t put EVSE on guest wifi)
  • For those ready to take the next step and create an explicit EVSE security program, NIST 8473 has excellent guidelines on doing so – https://nvlpubs.nist.gov/nistpubs/ir/2023/NIST.IR.8473.pdf

The alarming number of vulnerabilities discovered in EVSE, along with the fact that most EVSE in the wild uses the OCPP 1.6 protocol over plaintext, combine to make EVSE a key target in the evolving digital landscape. Using the vulnerabilities and attacks described above, it is trivial for an attacker to start and stop charging sessions, install malicious firmware on devices, examine exposed endpoints in the CSMS cloud, and more. Although the most frightening scenario, disruptions to the electric grid caused by EVSE, is not feasible today, this could easily change as EVSE and XFCs proliferate in the coming years.

Fortunately, just as these attacks are well understood, so are the defenses against them. EVSE owner/operators who follow the above guidance can frustrate potential attackers and create peace-of-mind for themselves and the users. Although the risk of attack can never be completely removed, it is possible to mitigate it to the point where an attacker throws up their hands and says “screw it, I’m looking for another attack vector”. Through diligence, ingenuity, and, most importantly, collaboration, we might just be able to frustrate them away from trying to hack this newly critical infrastructure altogether.

*For those interested in the electronics of how this is done, MIT offers a free graduate-level power electronics course at https://ocw.mit.edu/courses/6-622-power-electronics-spring-2023/.

** Much more powerful EVSE is coming – the 140 kW Tesla Supercharger can charge 200 miles in about 37 minutes, and 350 kW Extreme Fast Chargers (XFCs) can do this in just 15.

*** This was from an EPRI FAQ that I read alongside the documents that ultimately went into NIST 8473. If I find this reference again I will add it here.

All constructive feedback is greatly appreciated, thank you.

witchofthewires

, , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *