SAE WCX 2022: EV Cybersecurity Threats
An eye-opening Q&A with an impressive panel of experts lays out terrifying cyberattack scenarios including weaponizing EVs and region-wide blackouts.
With war in Europe, a waning pandemic and inflationary and supply pressures rampant, you’d think there was plenty to worry about. Those lucky enough to attend the 2022 SAE WCX panel “Cybersecurity – EV Charging Security,” can add a whole new list of potential disasters to fret over, as a new generation of electrified vehicles is grafted onto our lives and the nation’s electrical grid. The panel, ably moderated by John Krzeszewski, Eaton’s Cybersecurity Center of Excellence engineering manager, was catalyzed by a host of his insightful queries. The panel consisted of a shrewd cross-section of cybersecurity expertise that included:
Andre Weimerskirch, vice president for platform software cybersecurity and functional safety at Lear Corporation; Michael Westra, in-vehicle cyber security manager at Ford Motor company; Roland Varriale, cyber security analyst at Argonne National Laboratory; Sarah Hipel, interoperability engineer at Rivian and co-chair of the SAE PKI (public key infrastructure) project ; and Duncan Woodbury, CEO of Liberas, an EV and EVSE (electric vehicle supply equipment, i.e. charging infrastructure) cybersecurity firm. What follows is an edited subset of some of the more interesting and alarming aspects of an enlightening 90-minute panel discussion.
Do EVs offer fundamentally different cybersecurity challenges, and what are those differences?
Weimerskirch: At Lear we do the components – on-road chargers, battery management systems, battery disconnect units, converters, these sort of things – and they add complexity. An electric vehicle has far more hardware chips and software components than an internal combustion engine. More complexity means we need to be more careful around security in general. We have many safety triggers we want to avoid that can put the car into a fail-safe mode, which usually means we turn off the module – charging or driving – or disconnect the powertrain. All EVs have connectivity, and we need to find the right balance between safety and security. But there's also good news. EVs are plugged in usually overnight, so that's an excellent time to update the software in your car.
There's an ISO standard [15118-2] on communications between charging systems and infrastructure. What are the challenges with implementing that standard for EVs?
Westra: Ford was one of the first companies to implement the new standard. The ISO standard set the protocol framework reasonably well, but then as we implemented and started integrating with different charge suppliers, what we found is that each one was doing the PKI a little bit differently. So that depending on what was plugged into, we had to tweak how we responded. That's always going to be a recipe for disaster, part of why we're here today, and the SAE PKI standardization work that we're doing.
Electrical vehicle supply equipment (EVSE) could be used for malicious purposes?
Varriale: We look at EVSEs as the low hanging fruit and pivot points into more sensitive networks. I've found different EVSEs that were exposing remote ports that should not have been exposing remote ports. Talking with the manufacturers, it's just purely a misconfiguration on the user's part, which can be difficult sometimes when fitting devices onto an already existing and possibly secure, possibly unsecure network, and just hoping for functionality to work. And then as soon as you get the correct ports opening, you put a Do Not Touch design on it, not looking at what effects it had on the existing system.
That's eye opening to a lot of people that just think of charging stations as “I plug in my car to this,” instead of looking at, “If I include an EVSE in my shopping mall, could I be exposing some of my financial systems?” You have a lot of due diligence and legwork to do to ensure when you incorporate a device on your network, that it can't be used for malicious purposes to act like a flashlight and illuminate things that maybe people shouldn't be seeing.
How do the dimensions of interoperability impact security planning?
Hipel: From the EVSE to cloud back ends, and then cloud back ends to one another, all these need to be secured. Typically, when people in the industry think of charging controls, they're focused on the control between the EV and the EVSE, without looking at the rest of the system. When we think about ISO 15118-2 , if you decompose the standard into its main function groups, they are the charging controls – like cable, pre-check, pre-charge – there's the PKI portion of it, and then the value-added services that could be parking or whatever.
Part of the SAE PKI project, as Mike was talking about earlier, was to really focus on this PKI portion and to ensure the security is there for the PKI itself, as a standalone function that could be layered on top of charging controls between the EVSE, on top of the OCPP [open charge point protocol] between the EVSE and cloud, and then the OCPI [open charge point interface] between the two cloud back ends.
When we look at this PKI to secure the interfaces, to have trust within the system of interfaces, I want to make sure we're mutually authenticating. I want to make sure that we have interoperability in terms of critical extension checks in the certificate, make sure that we're using the same extensions within the certificates, making sure that the keys are being distributed in a way that's secure, and that the certificates are ending up on end devices in a way that's secure. There's a bit of a difference in the market right now, particularly geographically, for how these certificates are delivered to endpoints and whether these are secure or not.
How can EVs be used as a tool to disrupt or attack other critical infrastructure systems? Should we really be more concerned about potential cyber effects targeting EVs or those targeting infrastructure?
Woodbury: There are many old school folks that will give the spiel, that would give the argument, that the EV can be used as a bomb. But I think more compelling issues center around the ability to affect infrastructure. One Level-3 or Level-4 charger is equivalent to about 850 toasters. If we weaponize a few thousand vehicles charging at max capacity at a Level-4 charger, we can create significant load swings in the grid. These can be used to disrupt grid volatility, used to disrupt reserves. These can also be used to affect economic security and to attack energy markets. These are some of the more obvious or maybe higher-level consequences that can come from widespread coordinated attacks on EV charging infrastructure, the disruption of power markets and the widespread disruption of grids.
This represents the great decentralization of the grid [Woodbury referenced in his opening remarks that “residential charging and the aggregate load of residential charging is projected to exceed the commercial load by 2035.”]. If we think about what happened at [the regional transmission organization] PJM on the east coast , the complete blackout in 2003 was less than five seconds from working perfectly to full blackout. The bar to do this with wide-scale disruption of EV charging infrastructure is not that high.
There's a lot of great work that was led by INL [Idaho National Laboratory] to define a list of high-consequence charge events that can happen through exploitation of a charger, from wide-scale disruptions of grid stability, to the ability to melt a charging cable and affect individuals, to the ability to wage political warfare on a vehicle manufacturer by creating different kinds of incidents.
Weimerskirch: Where you can use cars as a bomb, that they basically start burning, I would very clearly say, no, you cannot. To give an idea about how the design usually works, at least what we do is, there's a component that can disconnect the battery from the charging process, a battery management system. That component is usually sealed inside of the battery pack, and it has hardwired sensors to the battery pack. The second something is off – temperature is too high, voltage is too high, power is too high – it will immediately disconnect and you cannot override this. All of this stuff is hardwired. So, I don't believe in the safety implications that you can have some catastrophic event due to security. I'm far more concerned about adversaries that go for financial incentives like charging on someone else's cost or an availability issue, a denial of service.
How do you balance the ongoing implementation of cybersecurity measures while knowing that new technologies are always emerging that may make current safety measures quickly obsolete?
Weimerskirch: I think it's related to where we really hardwire these things. Who knows what security issues we’ll have in the future. Maybe someone figures out a way of compromising systems in a way that we cannot think of today. But the next thing I would argue is we really need to make EVs updateable over the air [OTA]. It should be a requirement so that even if there's this very surprising future attack, we can respond.
Westra: I'll just second what Andre says, the usual way that the safety process unfolds, where there could be an event, there's usually double or triple redundancy to try to make sure that doesn't happen. And I mean, stuff always does happen. That's where you typically will see a recall. And as OTA proceeds, where software is in that loop, then you can use OTA to solve those issues. And that's where the security and safety compliment, but also are living in different worlds.
Safety has a hundred years of physics and engineering behind it, and cyber tends to deal with an unknown adversary who's constantly trying to outthink you, and they don't always mesh completely. That's why you tend to make the safety pieces isolated from the logic piece, as Andre was indicating. Even in the EVSEs, they have ways of cutting circuits if they're trying to draw too much power if things are overheating. And that is a completely separate subsystem from the chips that are doing the cellular connectivity. Not to say it's impossible, because you can never say that, but they intentionally make sure that those aren't imminently connected to each other.
Varriale: With respect to EVSEs, I don't really want to say this, but it is low maturity across the space and [requires] bolstering security. Putting dedicated security personnel on teams and not people wearing multiple hats, especially when we're talking about a kind of startup culture, pushing functionality out the door as quickly as possible. Including security requirements within the building process will solve a lot of the security/safety-related problems. And like Mike was saying, a lot of the safety things are covered by the physics, and by the design and through the engineering of the EVSEs.
Woodbury: I am much more concerned now with this OT/IT [operational technology/information technology] interaction. From this level it’s much more of a data and a networks problem, where every EV, OEM, charge-point operator, charging-network operator and utility have to have unique custom interfaces because of the lack of interoperability. Largely what we need is both the great work that SAE is working to do with Sarah and Mike, and the other folks on this panel that are involved with creating PKIs that can help us establish shared trust between the ecosystem stakeholders.
Hipel: We're talking about safety and security, but we can also think about the dichotomy between security in cyber-physical systems. Having the infrastructure that has interoperability between providers, whether they're charge-point providers or other OEMs in the market, and types of interoperability between the grid and other elements of the infrastructure. In order to have interoperability across the ecosystem, we have this proliferation of routes in terms of the vehicles and a grid cyber-physical infrastructure, and the PKI standard is the idea behind it.
If you're doing business in Europe, you're going to need to interoperate with the PKI there, whether it's a charge-point provider or as an OEM. I would like to see how the industry comes together in different geographies to really set these types of standards. Whether it's an SAE system or a third-party system or many third-party systems, how will we come together and agree on the standardization for cyber-physical securing of the different endpoints? It definitely feels like an open topic right now in the industry, and one we're very interested in trying to get to the bottom of.