Securing automotive over-the-air updates

Daniel Mckenna, Systems and Applications
engineer at NXP Semiconductor

In-the-field software updates to cars save manufacturers money, enable critical bugs to be patched immediately and allow new features to be added to the vehicle at any time during its lifecycle.

Few vehicles today can receive updates, says Daniel Mckenna, a Systems and Applications engineer at NXP Semiconductor. Even the cars that do support Over-The-Air (OTA) updates are only designed to update the infotainment or telematics systems. If an original equipment manufacturer (OEM) discovers a fault in the firmware that controls a critical function such as the brakes or an airbag – typically driven by Electronic Control Units (ECUs) – then the vehicle must be returned to the dealership.

There are two challenges facing OTA updates. First, car owners will not tolerate vehicle downtime for updates. Therefore, they must take place seamlessly and invisibly in the background. Additionally, the ability to remotely update vehicle firmware introduces a new attack vector for hackers. The two main motivations for hackers will be to use the OTA mechanism to reprogramme critical ECUs to ultimately take control of the vehicle or to steal OEM firmware.

To prevent reprogramming, the authenticity and integrity of the firmware needs to be protected. This ensures that the firmware originates from a trusted source and that it has not been modified. There are several methods of implementing such protection (e.g. HMAC, CMAC, or a digital signature).


Checking the authenticity of firmware guarantees that only trusted firmware is used in an update process but a hacker may still be able to read the plaintext (i.e. source binary) firmware to reverse engineer the source code, or steal data, which may lead to IP theft and/or privacy issues. Encryption of the firmware (for example, using AES) can prevent this.

With integrity checking, the communication channel over which the firmware images are received will be protected to prevent the common “man-in-the-middle” attack.

Finally, the in-vehicle OTA update manager should be protected against manipulation.

In summary, the following countermeasures should be applied:

    • Protect the authenticity and integrity of firmware to prevent a hacker from running modified code
    • Encrypt the firmware to prevent a hacker from accessing code (IP) and data
    • Establish secure end-to-end communication between the vehicle and OEM servers to prevent man-in-the-middle attacks.
    • Ensure a secure, trusted location for the OTA Manager application

Security implementation:

Typically, the connection to the OEM server will be setup by the Telematics Unit. This unit can use Transport Layer Security (TLS), a proven standard used in online banking, to secure the communication over the mobile network.

The (secured) update file is then received by the OTA Manager which will have a table listing each Electronic Control Unit (ECU) present in the vehicle along with the serial number and current firmware version number. This allows it to verify that the update is valid for the vehicle.

If the ECU to be updated supports firmware decryption and authentication, then the file can be sent as is, from the OTA Manager to the target ECU. However, not all ECUs in the vehicle will have secure key storage and hardware accelerated security features. In these cases the OTA Manager must authenticate and decrypt the update on behalf of the target ECU and send the plaintext update, over the internal network to the target ECU.

The lack of a hardware security module on an ECU thus leads to the update being sent unprotected over the in-vehicle network, which is not ideal. However, for this to be hacked, physical access to the vehicle and a knowledge of which wires to access would be required in order to snoop the bus. If this is still considered too high a risk then the module should not be updatable via OTA until the hardware is updated.

The OTA manager should check whether an update is valid for the vehicle: to guarantee the consistency (compatibility) of all firmware images of the different ECUs in the vehicle and to prevent a hacker from being able to install an older firmware version to re-enable a patched exploit.

This requires a secure method for storing the current firmware version number, which can then be checked against the version number of any received update.

The final mitigation strategy for OTA security is the location of the OTA Manager functionality. The OTA Manager software orchestrates the updates of the firmware between the OEM servers and the vehicle’s ECUs. It is critical that this is located somewhere safe and isolated from (potentially rogue) third party software.

The central gateway on the other hand, which sits central in the vehicle network typically only runs OEM trusted software and would be a strong location for the OTA manager.

There are many advantages to over the air updates for both manufacturers and consumers but it will take diligence to ensure that security measures are implemented carefully.

The author of this blog is Daniel Mckenna, Systems and Applications engineer at NXP Semiconductor

Comment on this article below or via Twitter: @IoTNow_ OR @jcIoTnow

Recent Articles

Spike in use of cloud-based security to protect corporate data

Posted on: July 1, 2020

A new survey of UK security practitioners by Exabeam shows a marked increase in the adoption of cloud-based security tools compared to an earlier study carried out in March prior to the COVID-19 lockdown. The latest data shows 88% of recent respondents said the accelerated move to the cloud was driven by the need to

Read more

Telcos must be cautiously aggressive to ‘Roar out of Recession’

Posted on: June 30, 2020

As we approach four months since essentially the entire world went on lockdown, telcos have gone through a very mixed experience.

Read more