Why vehicle security may require a different approach - Embedded.com

Why vehicle security may require a different approach


With more than 152 million vehicles connnected to the Internet by 2020, it’s no surprise that electronic control units (ECUs) are easy targets for attackers and other adversaries. This is supported by published reports on recent attacks on Volkswagen/Audi, BMW, and Tesla vehicles.  And as cars become more connected, this trend will continue to grow.

Hacker Access

There are a number entry points, such as Wi-Fi, Telematics, Bluetooth that hackers can gain access to vulnerable ECUs. In April 2018, Computest reported vulnerabilities in Audi vehicles that enabled hackers to gain access via Wi-Fi to the in-vehicle network (IVN), gain root privilege, execute rough firmware updates and manipulate the gateway. In May 2018, Keen Labs published its research on BMW and demonstrated how they could penetrate the system via the telematics unit and change the gateway policy (among others) in order to gain control of the IVN. They also found code signing vulnerabilities that could be exploited to update the image to a rough image.  And in 2016 and 2017, Keen Labs published their research on vulnerabilities in Tesla vehicles, where in both cases the team attacked the Wi-Fi. This allowed them to manipulate and modify the software or bypass the code signing verification. While this is not an exhaustive list, it demonstrates how many attack vectors are able to gain control over the ECUs and eventually take over commands in the vehicle.

Securing the ECU is challenging

The attackers’ main goal is to persistently manipulate the software that is running in the ECU in order to leverage it even after the system is reset. And, there are several techniques to achieve this goal. The first is to define layers of security to protect the attack vectors and identify or prevent malicious commands. And ultimately, it’s crucial to prevent the attacker from modifying the software.

There are many challenges the industry is facing to secure ECUs including:

  • Not increasing boot time, as in many cases boot time is critical, and it can’t be increased since it is related to time-critical messages in the
  • Securing low end devices with limited processing power that can’t bear additional overhead for security and normally with have very limited hardware security features.
  • Dealing with failure mode. What if the firmware was altered? Should the car stop? What are the next steps? These questions in some cases mean that even if there is possibility to detect the problem, it is not necessarily helpful.
  • Relying on software solutions, even software solutions that provide firmware integrity have their limitations: dependent on the operating system/real-time operating system (OS/RTOS) CPU power from the main feature, and software tends to be comprised more easily than hardware.
  • Expanding protection to the entire memory. Since protecting the memory is done by cryptographic operation, the size of the protected memory is correlated to the time it takes to validate it, which means that only small blocks are being protected, and attackers attack the un-protected blocks.

Taking a Different Approach for Securing the ECU

Protecting ECUs in vehicles is a complicated process and may require a different security approach, such as protecting the memory for all devices.  The firmware resides in the memory, and during boot time, the firmware is fetched from the memory to the processor. What if we could ensure that the firmware can’t be altered in the memory itself? What if sensitive data could be accessed only by an authorized party?

High-end processors or OS features can partially protect data, but attackers are experts in bypassing this and accessing the memory directly.

The solutions must be processor and operating system agnostic and protect from the processor and software from vulnerabilities. It required to work with low-end processors, protect any required size of memory and there is no failure mode, preventing any possible modification.

It is clear to everyone in the industry that the secure update and management of the ECUs is crucial link in the chain – What if firmware over the air (OTA) updates could be securely authorized, managed and updated in the storage level?.

OTA is facing many challenges in our industry, some are operational including:

  • How to deploy the update images?
  • How to guarantee that the images are being delivered to the ECU?
  • How to manage which ones are being updated and which aren’t?

And others are technology-related, including:

  • How to protect the cloud from the rough ECU?
  • How to create root of trust (RoT) with the ECU?
  • How to create unique secure channel with the ECU.

Today OTA solutions are based on software agents in the ECU and cloud services that deploy the updated images. But it raises the challenge – if there is no hardware root of trust (RoT) in the ECUs, there is no assurance.  What is the real image that is stored in the persistent memory?  What if the software was comprised and reported back a rough response?

Moreover, since there is no RoT with the ECU, rough ECUs can be used to attack the cloud. Solutions that provide secured memory deliver OTA and management systems derived from the memory hardware itself. This provides the capability to identify the ECU, create a secure bi-directional channel, guaranteeing the real version that is stored on the ECU’s memory cannot be manipulated. Of course, since it is protected memory storage only authorized cloud services can update the memory and the cloud services can connect only to an authorized ECU.


Solutions must provide a cloud to ECU , all the way to the persistent memory solution with that are able to create a secure channel with the memory device in confidential, authorized and private manner.

It’s critical for connected and autonomous vehicles to better secure their ECUs from malicious actors, as more cars rely on devices to take over basic automotive functions.  After all, consumer safety is at stake.

Yoni Kahana is VP Customers at NanoLock Security, where he leads NanoLock’s business development initiatives and works with NanoLock’s repeatable customers in Asia, the U.S. and Europe. He brings extensive cybersecurity experience, with specific expertise in securing embedded and connected devices in connected vehicles and IoT devices. Prior to joining NanoLock, Yoni was the Product Cybersecurity Group Manager for General Motors in Israel. He also was a Security System Team leader and Security System Product Engineer at Qualcomm. He served as an officer in the Israel Defence Forces (IDF) in an elite unit where he led and developed cybersecurity solutions.

2 thoughts on “Why vehicle security may require a different approach

  1. “Can you imagine that one day people get control of all of these autonomous vehicles because they've managed to hack into the ECUs of the cars? That would seriously be disastrous! It seems like it's a clear-cut way for terrorists to cause massive amounts o

    Log in to Reply
  2. “Is it not true when we say that the digital world is actually a hacker's heaven? The more advanced the infrastructure is, the more advanced the hacker techniques become. I guess the evolvement between these two is often corelated in more ways than one. We

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.