Tag: IoT

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

V2G EVSE Announce Digi LTE-M Module

Further to the announcement earlier this week of the seed funding from the United Kingdom’s Department for Transport for our “Vehicle to grid controller with modular communications” project we have another exciting announcement to make this afternoon.

First of all please feel free to take a close look at the module that provides our controller with its LTE-M functionality. Note that it is in single antenna mode in the picture, but supports a second antenna if necessary:

V2G-EVSE-Digi-LTE-M

Secondly also bear in mind that, as an eagle eyed reader from Cambridge spotted earlier this week, the module shown above is mounted in what we prefer to refer to as the “V2G EVSE V2x controller with modular communications”.

Next we invite you to read yesterday’s press release from Digi International® headlined “Digi XBee3 Cellular LTE-M Smart Modem and Development Kits Now Available“:

MINNETONKA, Minn., Aug. 8, 2018 – Digi International®, (NASDAQ: DGII, www.digi.com), a leading global provider of Internet of Things (IoT) connectivity products and services, today announced the immediate availability of the Digi® XBee3™ Cellular LTE-M development kits, featuring Digi’s next-generation smart cellular modem.

This LTE-M certification, to be followed by the certification of Digi XBee3 Cellular NB-IoT in October 2018, allows Digi to bring one of the first LPWAN, software-defined technology-agile modems capable of offering Cat-M or NB-IoT on a single, compact footprint. Designed to be customer-configurable, developers can easily standardize and futureproof their IoT designs by simply changing modems and SIMs to leverage different wireless protocols without having to redesign hardware for different regions or applications.

Ushering in a much more simplified way of testing designs and incorporating cellular connectivity into wireless solutions, the new Digi XBee3 Cellular LTE-M smart modem is integrated into the development kit via a 20-pin Digi XBee socket, ultimately allowing for solution connectivity via millions of sockets already deployed around the globe. The module can also be easily configured and controlled from a centralized platform such as the Digi Remote Manager®.

Digi International is an Amazon Web Services (AWS) Advanced Technology Partner in the AWS Partner Network (APN), and the Digi XBee3 Cellular LTE-M is a smart cellular modem supported by AWS IoT Core. With built-in Digi TrustFence® security, the module’s identity and data privacy features use more than 175 controls to protect against new and evolving cyber threats. It also provides the tools to secure connected devices, including data in motion with TLS 1.2 encryption and bi-directional authentication – required for AWS IoT connectivity.

You may well wish to read the Digi press release in full, and I can reveal that we didn’t make use of Digi’s development kit when constructing our controller. However I’m afraid we’ll have to leave you to speculate for a while about how the V2G EVSE V2x controller delivers its NB-IoT functionality.

If you happen to have noticed that we’re based in the UK you may also be speculating about the SIM card plugged into the Digi LTE-M module shown above? If so we can put you out of your misery on that front at least. We paid the carriage across the pond and received this from Hologram in return:

Hologram-SIM

“A single SIM for all of Earth”!

We haven’t tested that claim of course, but it certainly works for us here in sunny South West England

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!