SW Updates in Automotive Industry – Part II

How Critical is SW Updates Last Mile Problem?

An immediate consequence of the last mile problem mentioned in part I of this article is that no security patch can be installed on ECUs, thus keeping the vehicle’s critical systems prone to publicly known vulnerabilities. In our research, we show the way of blocking SW update installation on an ECU – in the way that the updating device can detect the update failure. How would it react on the failure? This is a good question. The horror scenario here starts with a remote vehicle exploitation and, leveraging the vulnerable vehicle as a distribution platform, later move to the updating device toward the OEM cloud. Once succeeding to control the updating tool chain – either OEM updating device or OEM cloud, the hacker will be able to spread his attack to many vehicles.

Last Mile SW Update Problem – with Car Update Device

This problem is unique for the automotive industry. Your vehicle is the most complicated connected device you own. Modern cars have about 100M lines of code distributed among 50-100 ECUs, that are manufactured by different vendors and have various HW architectures. Most of ECUs should have SW update capabilities. Hence, we anticipate that this problem will be around for a long time.

Last Mile SW Update Problem – Over The Air (OTA)

Other potential damage scenarios that SW Update Last Mile Problem can cause

Disrupt silently – pretend success
A SW update can be silently disrupted by malicious SW or HW installed in the car. The installed malware can also pretend update success to the updating OEM equipment thus hiding the fact that the update has failed. This way, the infected car can never be detected and fixed.

Record and alter updated SW just before update
The original OEM’s SWfirmware intended for the update might be well protected from tampering andor reverse engineering while it is on the cloud and during downloading to the car GW via encrypted and well authenticated channel. But on the internal car network the SW has to be unpacked and unencrypted – thus prone for reverse engineering and tampering. An attacker can tamper the SW just before the update and inject malicious code into ECUs. He can also ‘emulate’ the ECU update sessions later on – even with other cars, spreading the tampered ECU SW.

What kind of data is transmitted from the vehicle to the server?
In our experiments we discovered significant amounts of data collected by the updating device from various ECUs and delivered to the OEM cloud. We think that this direction can be further investigated since it reveals an interesting attack vector on the OEM cloud infrastructure.

Other Attack Vectors – Service Shops Infrastructure
Service Shops relies on significant IT Infrastructures, including Internet, Wireless and Wired LAN, technician PCsTablets, Path-thru devices, etc. All these infrastructures provide new and convenient attack vectors for SW Updates Last Mile interested attackers.

Short Term Mitigations

OEMs can mitigate the above security risks with introduction of some basic security processes during the vehicle life cycle. These processes can provide some level of security risk mitigation.

Service shops IT infrastructure hardening

Service shops IT infrastructure should be hardened and its lifecycle management, including security patches updates and administrator credentials management controlled by OEMs.

SW Updates Secure Delivery Channel

OEMs should establish SW Updates Secure Delivery Channel directly to the VCI devices. Offline delivery channels (e.g. – USB stick) should be forbidden.

ECUs Must Validate SW

ECUs must validate authenticity of the SW binaries delivered during the update. There are well-known techniques of implementing such a validation using one-way cryptographical hash functions (e.g. SHA256).

VCI (Vehicle Communication interface) Device Authentication

Existing VCI device authentication schemes are based on challenge-response mechanism utilizing pre-shared keys (between ECUs and VCIs). This scheme should be revised to provide stronger, session hijacking prone mechanism.

VCI Device Communication Authentication

Since VCI Device Communication is extremely sensitive, there is a strong need in protecting it from altering by third parties on the way – e.g. Man in The Middle attacks. It can be achieved by signing every VCI sensitive message and signature validation by the relevant ECUs. This process requires significant effort and SW changes of both – ECU and VCI, but provides major security protection layer for VCI Device Communication.

Enigmatos Approach – Security by Design

At Enigmatos, we believe that the life cycle management of vehicles and its surrounding infrastructure should address security risks at early design stage as well as during the implementation and manufacturing phases. With strong and proven Cyber Security expertise, Enigmatos team focuses on vehicle and maintenance infrastructure protection. Enigmatos solution fits today vehicles as well it is ready for coming V2X connectivity threats mitigation. Enigmatos offers a dynamic, multi layered, behavior-based detection and prevention for existing and emerging car architecture. Our approach – DCIP (Deep Car Identity Profiling) ™ – is that each car has its own unique signature. Two cars of the same model that rolled off an assembly line at the same time will have different signatures. We protect the car’s identity by allowing only valid and legal changes to this dynamic signature. The signature is generated by uploading hundreds of car’s communication network parameters to cloud in real time – and then applying our machine learning proprietary algorithms. The signature is then used for rules generation for our in-car CPD platform, functioning as an in car real time IDS engine.

By having 100% visibility into the car’s communication data we can detect any car behavior, HW and topology changes (including SW updates) as well as early anomalies detection and can apply the defined prevention method.