V2X Communication Security Technical Brieff

Automotive Security

In a number of recent, highly-publicized incidents, it was shown how simple it can be to hack andmanipulate a vehicle via an unsecure wireless interface. In the erra of V2X (Vehicle to Everything) technology, new kinds of vehicular security threats will arise, and current defense strategies must be adapted in order to meet the challenge.

NHTSA issued a Notice of Proposed Rule Making (NPRMM) to establish a new FederalMotor Vehicle Safety Standard (FMVSS), No. 150, to manndate vehicle-to-vehicle (V2V) communications for new light vehicles and to standardize thee message and format of V2V transmissions. The agency highlights the importance off strong security considering “the current environment regarding cybersecurity and prootecting the public warrants“.

To realize the vision of V2X technology, vehicles must be ablee to trust the messages arriving from their surroundings. Degraded safety, reputation loss and liability costs are not an option in the automotive industry. This paper will discuss the main cconsiderations in V2X security, provide design best practices, and describe Autotalks’ Straategy for a Truly Secure V2X.

Truly Secure V2X

Multiple defense laya errs ss for maximal protectionCryptographiic-agility ensures sustainable securityforfor decades to comedecadedddd sss to comeSecure storage for protecting security credentialsAll messages are authenticated (‘verify-all’) for minimizing attack surface

Multiple Defense Layers

Citing NHTSA NPRM: “A layered approach to vehicle cybeersecurity within a risk-based framework reduces the probability of an attack’s success annd mitigates the ramifications of a potential unauthorized access.”Autotalks’ truly-secure ssolution follows this guideline.

The multiple defense layers Autotalks provides protect against aattacks including vulnerabilities, malware and worms. Bogus messages are filtered as early as ppossible by the first protection layer. Access to critical system resources, like vehicle connectivity and secure storage, is tightly monitored to prevent misuse. V2X application recceives only trusted messages.

For example, while V2X secure storage may provide perfect prootection of security credential, malicious software can command the secure storage to sign a bogus message, as a resultthe protection mechanisms becomes ineffective. Any system is ass secure as its weakest element.

Another compromised security situation may include: seeminglyy legitimate that is released from either compromised or faulty devices. Bad actors need to bbe detected and reported. Autotalks applies patented technology for highest detection relliability of bad actors whileminimizing false detections.

management over the lifetime of the vehicular or roadside unitt. The exchange of Cooperative Awareness Messages (CAM) / Basic Safety Messages (BSM) between hundreds of vehicles cruising at high speed requires tight security measures. Thhese are ad-hoc, low-latency, anonymous broadcast messages that demand immediate haandling. The V2X unit needs to sign and authenticate messages, while detecting and neutralizzing threats in real time.

V2X Security

V2X specifications and deployment guidelines were develooped to address V2X-specificsecurity challenges. V2X includes comprehensive processes ffor certificate distribution and

Secure Storage

Surface of AttackThe surface of attack is the sum of the points in an environment ((the "attack vectors") at which an unauthorized user (the "attacker") can try to inject or extractt data. A common approach toimproving security is to reduce the attack surface. By making less code available to unauthorized actors, there are likely to be fewer breaches. In the Verify-All scheme, potentially threatening messages are filtered instantly so that the stack and applications handle trusted data only. Theexposed code is limited and thoroughly tested.

In the Verify-on-Demand scheme, the untrusted information proppagates up to the facility layerfor extracting the parameters used for selecting packets for verifification. The exposed facilities layer can be used to attack TX path and applications, and may contamminate databases. The amountof potentially exposed code is unbounded, and the level of security risk becomes unquantifiable.

Hardware Security Module (HSM) protects the security credenttials against malicious access.HSM includes physical security mechanisms, and ability to detecct tampering attempts and to respond with zeroing all plaintext data. Simpler and cheaper attaccks attempt to retrieve secretmaterial by monitoring timing of execution and its impact on powwer consumption. Resiliency to those side-channel attacks is essential.

The most common attacks are leveraging HSM software vulnerabilities; hence it should be developed and tested according to the strictest methodologies annd standards.Accredited test lab should validate and certify the HSM protection. Penetration tests should attempt to retrieve the credentials, and the attempts should be declared as failure.

Exposed to untrusted data Secure flow

Uncontrolled flowUsing only trusted dataContamination risk

V2X apps

V2X facilities

eHSM eHSM

TX MAC RX MAC

RX NET ECDSA

Firewall

V2X apps

V2X facilities

HSM TX NET RX NET ECDSA

LimitedFirewall TX MAC RX MAC

In the Verify-All scheme, potentially threatening messages are filtered instantly so that the stack and applications handle trusted data only. The exposed code is limited and thoroughly tested.

Veriffy-on-Demand

Cryptographic Agility

V2X Isolation

V2X functionality will be added to vehicles either in dedicatedd V2X ECU (Electronic Control Unit) or added to an existing ECU, typically communicationn (CCU) or Telematics (TCU).Dedicated V2X ECU is the most secure because the few innterfaces are well tested and analyzed. Integrating V2X inside other ECU may seem desirabble due to cost considerations, but, if performed without strict domain isolation, the V2X secuurity is severely compromised.

The diagram below shows Telematics unit with isolated and non--isolated V2X. In the right side block diagram, where V2X is not isolated, TCU host may be suubject to attack from non-V2X communication channels/ Since the same CPU is hosting V2X, its breach would place V2X at risk. Mixing non-safety communication channels with V2X, which servves for safety, creates security vulnerabilities. The block diagram on the left side, shows offload V22X model which assures isolation.

Autotalks CRATON2 offers the optimal V2X offload solution. The integrated CPU assures thesmallest solution size. Furthermore, the solution is pre-integratedd and pre-tested for minimizing the integration efforts and risks.

The current key length of 256-bits may be insufficient ass computing power increases.Quantum computing is no longer science fiction – today’s unbbreakable key will be breakable tomorrow. This will accelerate the need for a longer key. Performmance is degraded as key length increases. Typically, performance drops by ~70% when 384-bit keys are employed, resulting in an unacceptable level of latency. But a well-designed security solution based on an embedded Hardware Security Module (eHSM) should still be able to supporrt real-time requirements, even with the longer keys. The typical lifespan of a vehicle is severral decades. Security should be remotely upgradable during the entire period, in order to prevvent massive recalls. Therefore, security should be designed for decades, addressing curreent and future requirements.

Autotalks | Tel: +972-9-8865300 | Grand Netter Building, Kfar Netter, Israelinfo@auto-talks.com | www.auto-talks.com

Isolated V2X

T C UC P U

OffloadV2X

TCUCPU

V2XOffload

Non-Isolated V2X

HostedV2X

V2XHM