OpenEnergyMonitor Community

EV charger security

The BBC ran a piece on domestic EV charger security: Home car charger owners urged to install updates - BBC News. As always, there’s a lot more info from the horses mouth: Smart car chargers. Plug-n-play for hackers? | Pen Test Partners.

An EmonEVSE wasn’t reviewed, but a wallbox was which contains a Pi compute module. This is what PTP said: “We love the Pi, but in our opinion it’s not suitable for commercial use in public devices as it is very difficult to fully secure it against recovery of stored data.

A couple of other systems also use a Raspberry Pi, which the pen testers weren’t that happy about.

I’m not sure where I’m going with this post, other than to bring to our attention. I think as tinkerers, we’re in a good position because there are more eyes on code and systems. But I guess it always helps to be vigilant.

1 Like

This topic was also brought up on SpeakEV forums. A lot of users took the BBC Click report as “FUD” but IT security issues always need to be addressed for any internet connected device, whether it be EV tech or otherwise.

If we were to look at the EmonEVSE/OpenEVSE products, and break each risk down:

1- Mallicious activity by physical access.
The likelyhood of anyone creeping up onto a driveway to open up a live EVSE box, OpenEVSE based or otherwise is going to be very slim. No bad actor wants to be seen to be sat on your driveway, laptop in tow, trying to do something naughty with an EVSE and risk electrocution in the process! Assuming someone has physically opened up the EVSE. What can they do?

Well, being a modular design, it would be possible to override the contactor to initiate a free charge by applying 230v directly to the coil contactor, working live. You’d be nuts to do that and utterly desperate for a charge. Incredibly unlikely!

Access to home network. If the OpenEVSE/EmonEVSE has an Ethernet connection, you could unplug the onboard Olimex Ethernet board and connect that Ethernet cable to a laptop and, depending on the LAN configuration, access other devices on the network. Again, it would be unlikely to happen as the attacker would easily be spotted doing this. The risk vs reward balance is heavily against the attacker.

If there is an ESP32 WiFi board - I don’t know if the contents of the Flash memory are encrypted or not to gain the WiFi password etc, but in theory it is also possible to Flash new software onto that ESP32 if you are again sat on the driveway, laptop and cable in tow. Very unlikely, as above.

OpenEVSE/EmonEVSEs with a physical button - that button can allow local control to initiate a charge outside the timer schedule for example by someone wanting to “steal electricity” but equally the button can be disabled in software.

2 - Mallicious activity by nearby WiFi access.
If the attacker was nearby and gained access to the WiFi network, then it would be possible to control the EVSE, flash different software to it etc. If an attacker is on your WiFI network, you have bigger problems to worry about than just the EVSE! That’s not the EVSE’s fault.

3 - Remote access from elsewhere on the internet.
The OpenEVSE should only be accessible via the local home network or standing in front of it. I would jolly well hope people are not using port forwarding to access it remotely! Many OpenEVSE users with WiFi or Ethernet access will also have an EmonPi on the network talking to the EVSE, extracting data and maybe using a few HTTP or MQTT commands.

I have no experience using the remote server so cannot comment on that. Anyone else care to chip in on any security thoughts of

All in all, I’m not worried about the security of the EmonEVSE, given the location of the physical device makes it unlikely to be attacked and that it remains on the local network for my intended set up.

The one assumption we make here, is that the EmonEVSE is accessible to anyone who already has WiFi or Ethernet access. The device itself has no password protection to the local web page and (from the version I am running, 3.3.2) is not running https. It would be unsuitable to be left on the same network in a corporate setup unless the EVSE was placed on its own restricted network and used for monitoring energy usage etc for a small staff car park charger perhaps?

1 Like

Interesting articles, in particular the discussion by the security researchers themselves. I will re-read those a couple of times to try and make sure I’ve understood the main points. Im always learning on this subject and its a complex field!

I think our largely decentralised approach to device control helps us quite a bit but Im sure there are many items we can improve on.

@moojuiceuk I think that’s a good summary and reflects my understanding of the main risks. is not currently used to provide a central administration service of EmonEVSE/OpenEVSE chargers. It’s only used by those who choose to link their chargers to the service for data logging, and that link is authenticated using a unique user specific apikey which does not provide wider access to other accounts.

We do mirror the Octopus Agile tariff profile on which can then be used by users using the emoncms demandshaper module running on a emonPi/base installed locally in the home to calculate the best time to charge. If this tariff profile was somehow compromised that could coordinate chargers to start at the same apparently low cost time, though no more than say the Octopus GO tariff currently focuses demand on a particular period. The control approach used by the demandshaper means that there will still be some degree of charge period spread across units, due to different users preferences in terms of charge end times and charge durations.

An emonPi/base could be compromised of course with direct physical access to the SD card, this wont cause any risk to emonPi/base units installed elsewhere in other homes as there are no shared keys. That seems like a very small risk compared to some unknown operating system or application level vulnerability that could be exploited remotely - something that we need to always be careful to guard against.

Always interested to hear others perspectives on this.

Thanks both. I admit on the pen tester’s blog the part that really raised my eyebrows was access to the GraphQL endpoint. Thankfully not a hazard we face!