Tag: Security

OCPP 2.0.1 Released

We have been waiting a long time for this announcement from the Open Charge Alliance:

The full and official version of OCPP 2.0.1 is released and open to the public. OCPP 2.0.1 replaces OCPP 2.0 and features several bug fixes and improvements based on experiences in the field. As some of these improvements are on message level, the version number of OCPP has been increased to 2.0.1.

OCPP 2.0.1 incorporates improvements for things found in the first implementations of OCPP 2.0 during our Plugfests and in the field. Improvements have been made in the area of Security, ISO 15118, Smart Charging and the extensibility of OCPP. A better explanation of the Device Model has been added as well as several other improvements. No new functionality is added to this release.

However it appears as though the wait has been largely in vain from our particular perspective, since the announcement makes no mention of “smart discharging”,  more popularly referred to as V2G.

These Renault ZOE’s, pictured in Utrecht last year, do support vehicle-to-grid operation and the ISO 15118 protocol between the charging station and EV. However that is achieved by using non-standard extensions to OCPP 1.6:

The OCA have made another announcement recently as well. Here it is:

The Open Charge Alliance (OCA) has noticed that there is an increasing interest in the activities of the alliance and that companies are eager to take the next step with OCPP. Although we cannot meet face-to-face due to the worldwide COVID-19 virus, the OCA wants to share knowledge and help everyone with their implementations and innovative ideas. Therefore we are happy to announce that we will be organizing a short series of webinars about OCA’s activities parallel to the Online OCPP 2.0.1 Plugfest on April 20th and 21st.

These webinars are free and open to everyone. You don’t have to be a member of the Open Charge Alliance or have in depth knowledge about the topics.

I’ve already signed up for the “OCPP 2.0.1 tutorial” option. The other available topics are:

  • What is the Open Charge Alliance?
  • OCPP 1.6 certification program.
  • OCPP 1.6 Compliance Testing Tool.

You can get your own copy of the OCPP 2.0.1 specification via the download section of the OCA website.

Open Charge Alliance Enhances OCPP 1.6 Security

The Open Charge Alliance announced today that they have published a new security white paper. According to the news release:

Secure communication and operation is a critical aspect of Electric Vehicle Charging Infrastructure. In the latest release of OCPP version 2.0 security features such as secure connection setup, security events/logging and secure firmware update, have been added to the specification. For OCPP 1.6 however, the security measures have up until now been designed by individual implementers of OCPP. To further assist the industry the Open Charge Alliance now publishes a white paper to describe a standard way to address security using OCPP 1.6-J. Security requirements are included, on security measures for both Charge Point and Central System, to help developers build a secure OCPP implementation.

This white paper contains the following security enhancements:

  • Secure connection setup
  • Security events/logging
  • Secure firmware update

The OCPP 1.6 Security Whitepaper is also added to the OCPP 1.6 zip file that can be found on the download page of the OCA website.

I’m travelling at the moment, and haven’t had a chance to look through the document in detail. However it certainly sounds as though the OCA has ported the new security features in Open Charge Point Protocol 2.0 back into version 1.6. They are perhaps long overdue, since only a few days ago Kaspersky Lab revealed that “electric vehicle chargers supplied by a major vendor carry vulnerabilities that can be exploited by cyber-attackers” had just been patched.

Watch this space!

Vulnerabilities in Connected EV Chargers Could Damage Home Networks?

Yesterday cybersecurity company Kaspersky Lab published a press release which claims that:

Kaspersky Lab experts have discovered that electric vehicle chargers supplied by a major vendor carry vulnerabilities that can be exploited by cyber-attackers, and the consequences of a successful attack could include damage to the home electricity network. While modern electric vehicles are tested constantly for vulnerabilities, this research reveals that some of their essential accessories, such as battery chargers, may remain at risk.

For more information on the electric vehicle charger vulnerabilities discovered by Kaspersky Lab, read the full report on Securelist.com.

The “major vendor” referred to is not identified in the press release, but the full report on Securelist reveals that ChargePoint, Inc. is the company in question.

Kaspersky continue:

The researchers found a way to initiate commands on the charger, to either stop the charging processor or set it to the maximum current possible. While the first option would only prevent a person from using the car, the second one could potentially cause the wires to overheat on a device that is not protected by a trip fuse. If compromised, the connected charger could therefore cause a power overload that would take down the network to which it was connected. This could result in significant financial impact and, in the worst-case scenario, damage to other devices connected to the network.

To change the amount of electricity being consumed, all that an attacker would need to do is obtain access to the Wi-Fi network that the charger is connected to. Since the devices are designed for home users, security for the wireless network is likely to be limited. This means that attackers could easily gain access, for example, by bruteforcing all possible password options – a common method of attack. According to Kaspersky Lab statistics, 94 percent of attacks on IoT in 2018 came from Telnet and SSH password bruteforcing. Once inside the wireless network, the intruders can easily find the charger’s IP address, which, in turn, will allow them to exploit any vulnerabilities and disrupt operations.

All the vulnerabilities discovered by Kaspersky Lab researchers were reported to the vendor and have now been patched.

The final paragraph is a relief, but here are Kaspersky Lab’s suggestions for avoiding similar problems in the future:

To protect your smart devices, including electric vehicle accessories:

  1. Regularly update all your smart devices to the latest software versions. Updates may contain patches for critical vulnerabilities, which, if left unpatched, could give cybercriminals access to your home and private life.
  2. Do not use the default password for Wi-Fi routers and other devices. Immediately after install, change it to a strong password, and do not use the same password for several devices.
  3. It is recommended to isolate the smart home network from the network used by your or your family’s personal devices for basic internet searching. This is to ensure that if a device is compromised with malware, your smart home system will not be affected.

What Are The Top IoT Platform Requirements?

Our regular readers will be aware that we have been discussing our Internet of Things platform requirements with Digi International for quite some time now. At long last Digi have revealed what they see as their top 5 IoT requirements. Brad Cole, Digi’s Enterprise Software Product Manager, explains their view of such things in this newly released video:

I don’t know about you, but I quite like the sound of this bit:

It should provide a central aggregation service to which all remote gateways and devices attach, and it should do so securely with automated detection and self healing. Devices then utilise a secure integration protocol to send and retrieve data in a variety of ways.

What should you be looking for in an IoT platform? What are the top 5 “must have” requirements? First and foremost, security is key!

With all that in mind we’ve had one of Digi’s new XBee3 Cellular LTE-M/NB-IoT Global modules in our possession since before they announced it. However here in the UK LTE-M is conspicuous only by it’s absence, so we’ve been anxiously awaiting Digi’s promised “certification of Digi XBee3 Cellular NB-IoT in October 2018”. It’s still September and Digi haven’t issued another press release yet, but nevertheless we have already managed to upgrade our XBee3 module to firmware revision C. According to the accompanying release notes:

### Release Version

1140C – XBee3 Cellular LTE-M/NB-IoT Global

### Release Date

  • September 2018

### New Features:

  • NB-IoT Support
  • Support for European and U.S. Carriers.
  • Important: Conditionally approved for use on T-Mobile NB-IoT network for evaluation and development purposes. Full certification will be completed with an upcoming cellular component firmware update (SARA-R410M-03B).
  • Added new option 1 to CP command for network configuration.
  • Added new commands BM, BN to select band mask.
  • Added new command N# to select network preference.

For some strange reason Digi neglected to mention the “upcoming cellular component firmware update” back in August. However it does sound as though their new module is now fully certified for use on Vodafone’s NB-IoT network. Digi have also just updated their XBee3 Cellular LTE-M/NB-IoT Global module specification sheet, which now reads as follows:

  • OPERATING MODES (LTE-M) Transparent and API over serial, PPP over USB or serial
  • OPERATING MODES (NB-IoT) Transparent, API, UDP

Digi’s technical support team assure me that:

Currently the updated U-Blox code is not scheduled to be certified till around Q2 of 2019.

Better late than never I guess? They have also clarified the issues involved in updating the u-blox SARA R410M module firmware once rev 3B is eventually issued:

You will not be able to perform the firmware update via the old XBIB-U-DEV board you have. It will require the use of a new board that is still in development which will provide USB direct access to that U-Blox chip.

When the new board is released, you will have access to the USB direct pins. One will place the module in USB direct mode which also puts it in bypass mode. If you are using Linux, your Linux modem manager or other options will be able to talk directly to the U-Blox chip.

Personally I cannot wait for that glorious day, because that will allow me to tick one more of the boxes on V2G EVSE’s checklist of top IoT platform requirements. To summarise, here are the top 6 entries on our current IoT platform leaderboard:

  1. LTE-M and NB-IoT global certifications
  2. Security
  3. Reliability
  4. Scalability
  5. Flexibility
  6. Simplicity

eHealth, Infrastructure, Security, Regulation and Research

The first article on the V2G EVSE blog is also the first in an occasional series of articles that are not directly related to electric vehicle charging infrastructure! The topic under discussion at the Penryn Campus of the Universities of Exeter and Falmouth yesterday was eHealth. Quoting from the Wikipedia article on the subject:

eHealth (also written e-health) is a relatively recent healthcare practice supported by electronic processes and communication, dating back to at least 1999. Usage of the term varies. A study in 2005 found 51 unique definitions. Some argue that it is interchangeable with health informatics with a broad definition covering electronic/digital processes in health while others use it in the narrower sense of healthcare practice using the Internet. It can also include health applications and links on mobile phones, referred to as mHealth or m-Health. Since about 2011, the increasing recognition of the need for better cyber-security and regulation may result in the need for these specialized resources to develop safer eHealth solutions that can withstand these growing threats.

As I mentioned at one point during the proceedings, I had been “parachuted into the event from the smart grid” because I had the good fortune to bump into Mael and Darren from the Smartline Project at a Software Cornwall event on a snowy day in St. Austell at the beginning of February:

Yesterday I learned much more about the Smartline Project’s Low Power Wide Area Network (LPWAN for short). Darren said that by the end of March 350 “LoRa but not WAN” gateways and lots of associated sensors will have been installed in social housing across the Camborne/Redruth area of Cornwall. I clarified his remark in the question and answer session:

Somewhat earlier in the proceedings Anna Mankee-Williams had (somewhat tongue in cheek?) set the scene by playing the first part of a video entitled “How IoT Will Destroy Us All”!

Anna summed up her point up by saying:

The Internet of Things is being “pushed” by big business. It’s more like “the Internet of Everything” these days. Who actually NEEDS an Amazon Echo?

I cannot help but agree, since I don’t possess even a single incarnation of Alexa! Does that make me a modern day Luddite?

I expect I’ll have more to say on the Smartline Project’s use of IoT devices when Anna has sent me the slides from the event, but for now I’ll focus on a couple of the exercises Anna asked us to do. The first was to discuss how an omniscient CIO could start to fix the many things that are broken. Having parachuted in from the vehicle-to-grid space I suggested breaking down lots of silos. In my example Transport v Energy v Infrastructure v Buildings v a few more. I was dismayed to learn from the IT expert sat next to me that matters are far worse in the NHS! Apparently it’s nigh on impossible to acquire and compare data from different primary care trusts. Likewise from different hospitals within a single trust. Likewise between different departments within a single hospital.

Suitably chastened I subsequently ate my traditional tin miner’s lunch:

After that we divided into breakout groups. As alluded to above, both the “research” group and my “infrastructure” group decided the top eHealth priorities were:

1) All concerned should have access to a basic minimum level of communications technology. Half of the 350 recipients of a sensor studded social house didn’t previously have internet access and were therefore provided with tablets as part of the Smartline Project, and

2) In order to achieve #1 “regulations” needed to change. In my smart grid (AKA the “Internet of big things“) analogy the UK Government is already “committed” to ensuring that every new build will be fitted with big enough wires to allow the charging of an electric vehicle at some point in the indeterminate future. Why not do the same with Cat 6 cabling and/or a sprinkling of adequately wirelessly connected IoT style sensors?

There had been lots of discussion about these and other issues over lunch:

2018-03-09_13-12-43_165

However I’m pretty sure that all the questions haven’t been answered and all the problems solved just yet!