Automotive hardware attacks get clearer risk analysis and rating system
Automotive Hardware Attacks: An Architect's Guide to TARA
Cryptography and Security
Summary
Cars today use complex hardware that can be attacked in different ways to cause problems or steal data. Current safety standards don’t handle physical hardware attacks very well, often rating them too low or inconsistently. The authors present a better way to analyze these attacks by considering hardware details like side-channel leaks, fault attacks, and debug access. Their method improves how attackers’ access and knowledge influence attack ratings and helps decide when hardware resistance must be proven or documented. They tested their approach on real automotive gateway designs and past attacks to show its practicality.
What this means in practice
- •For automotive security teams: Improve vehicle hardware attack risk ratings and documentation with a method that clarifies when to verify security resistance or just document it.
- •For hardware security engineers: Use the hardware-aware attack potential model to more consistently assess physical attacks like side-channel or fault-injection in complex systems.
Authors
Jakub Breier, Xiaolu Hou
Abstract
Threat analysis and risk assessment (TARA) according to ISO/SAE 21434 treats implementation-level hardware attacks inconsistently. We show that two of the three attack-feasibility approaches exemplified in the standard rate every attack path that requires physical access as very low by construction, independent of the implementation, while the third can assign the same path any of the four ratings, depending on the assumed state of attacker knowledge and on the attacker profile. This paper presents a hardware-aware extension of the TARA that covers side-channel analysis (SCA), fault-injection attacks (FIA), and abuse of debug and test interfaces. It adds an attacker model for physical access over the vehicle lifecycle; a path-dominance relation on the attack-potential factors that identifies when a simpler path makes a sophisticated one irrelevant; a three-level hardware relevance gate (H0 to H2) with an explicit decision rule that fixes whether resistance of a hardware step may be argued, must be documented, or must be demonstrated by test; and a rating rule under which a hardware step receives no credit for implementation-specific resistance until the required evidence exists. The gate is positioned relative to cybersecurity assurance levels and targeted attack feasibility. The method is applied to a reference gateway architecture, and its structural inputs are examined on ten published attacks on automotive components. In seven of the ten studies, the demonstrated attack included a debug, programming, boot, diagnostic, or update mechanism, whereas only four studies included an attack on a cryptographic computation.