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
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