Making Full Vehicle OTA Updates a Reality: Part Two

In a previous article, I spoke about the importance of Over-The-Air (OTA) updates to cars. I gave an overview of the update flow, the different processes for updating, and how they differ. In this article I will cover securing the OTA update process, the need for a central gateway, and the required microcontroller features to pull it all together.

Security Requirements

The ability to remotely update vehicle firmware opens up a new attack vector for hackers. The two main motivations for hackers will be to use the OTA mechanism to either reprogram 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).

With authenticity checking of the firmware, an OEM can guarantee that only trusted firmware is used in an update process; however, 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 for example lead to IP theft and/or privacy issues. Encryption of the firmware (e.g. using AES) can prevent this.

Furthermore, the communication channel over which the firmware images are received should be protected to prevent commonly used “man-in-the-middle” attacks. Last but not least, the in-vehicle OTA manager, which orchestrates the updates, should be protected against manipulation.

Stay Secure. Learn more about managing cyber security and hacking in the world of smart plants, sensor-rich IoT, and more at Industry 4.0: Smart Manufacturing, part of Atlantic Design & Manufacturing Expo. June 16 in New York. Register here for the event, hosted by Design News’ parent company UBM. Enter promo NY16DN for a FREE Expo pass & 20% off Industry 4.0 Conference.

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 widely 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 ECU present on the vehicle along with the serial number and current firmware version number. This allows it to verify that the update is valid for this vehicle.

In addition, the update files should be end-to-end secured between the OEM server and the target ECU, as explained above. 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 may have secure key storage and hardware accelerated security features. In this case the OTA Manager itself has to authenticate and decrypt the update on behalf of the target ECU and send the plaintext update, over the internal network to the target ECU (optionally an obfuscation method could be used to offer some level of protection). 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 of a risk then the module should not be updatable via OTA until the hardware is updated.

As mentioned above, the OTA manager should check whether an update is valid for the vehicle: not only to guarantee the consistency (compatibility) of all firmware images of the different ECUs in the vehicle, but also to prevent a hacker from being able to install an older firmware version in order 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 is software that is orchestrating the updates of the firmware between the OEM servers and the vehicle’s ECUs. If this is susceptible to being hacked remotely, a hacker potentially could have complete control of the vehicle. It is imperative that this is located somewhere with complete trust by the OEM, isolated from (potentially rogue) third-party software. Some ECUs, such as the infotainment unit, would be considered less trustworthy due to many third-party apps (e.g. music, weather, navigation) being present, with potential backdoors to OEM firmware, making it a less desirable location for the OTA manager. The central gateway on the other hand, which sits central in the vehicle network (acting as the firewall for external and internal networks), typically only runs OEM-trusted software and would be a strong location for the OTA manager.