By: Onn Haran, Autotalks’ Founder and CTO
A couple of weeks ago, a new United Nations regulation on vehicle cybersecurity was approved. UNECE WP.29 will make cybersecurity a prerequisite for the type approval of vehicles. Meaning, a vehicle can be sold only if proven to be cybersecure. The regulations are set to start implementation in the EU, Japan, and Korea in January 2021 and will reach full implementation by mid-2022.
Until now, the V2X cybersecurity certification scope was very narrow and limited, including only compliance with regional standards for the Hardware Secure Module (HSM) which is used to securely store the private keys and certificates for signing outgoing messages. That’s all. There was no certification at all for other security-critical system components.
Six years back, we worked hard to convince the industry that there is a need for line-rate verification to authenticate all received messages. Today, all OEMs and Tier1s are demanding that, although it is not part of any formal certification requirement.
Three years back, we started to raise awareness about protecting the V2X system as a whole, instead of just focusing on security primitives, signing and verification. We highlighted the importance of minimizing the surface of attack and assuring controlled access to security assets. The message resonated well but was not translated into a concrete requirement or design principle. This is about to change.
The impact of the new regulation is dramatic. The OEMs have to carefully analyze vulnerabilities and attack methods related to the threats of the vehicle’s communication channels. The requirements describe desired system behavior, for example “vehicle will prevent spoofing of messages” instead of a specific (and narrow) implementation, which in this example, would be “ECU should include a hardware verification engine”.
All threats should be addressed. For this example, assuring that the hardware verification engine cannot be bypassed or its results cannot be manipulated.
Similarly, it is not enough just to require HSM. Analysis of the desired behavior would require prevention from using an HSM to sign malicious messages.
The regulation also requires an analysis if unknown software bugs can lead to exploitable vulnerabilities. Because V2X by nature deals with safety, system design must account for risks that other communication systems are less exposed to. Today V2X alerts the driver of potential road dangers; in the future V2X will influence automatic vehicle braking. Potentially exploitable V2X vulnerabilities may therefore impose high risk. On the other hand, other communication interfaces, such as cellular network, are not related at all to vehicle braking. For this reason, the risk severity of potentially exploitable Telematics vulnerabilities is much lower than that of V2X.
But what happens when Telematics and V2X functionalities are mixed together? When there is no clear provable isolation between the two? The answer is that Telematics vulnerabilities can no longer be considered to impose low risk. Any attack on Telematics may compromise vehicle safety. Risk assessment and mitigation are far more complicated.
