PaperlayerView exact revision on arXiv

Source-linked AI summary

Automotive Hardware Attacks: An Architect's Guide to TARA

Jakub Breier, Xiaolu Hou

arXiv:2610.09697v1cs.CR

TL;DR

ISO/SAE 21434's example feasibility approaches treat physical-access hardware paths inconsistently, while guidance on when such paths need dedicated evidence or testing is limited. The paper extends TARA with lifecycle attacker profiles, path dominance, a hardware relevance gate, and evidence-dependent rating rules. Its application to a reference architecture and ten published attacks finds that seven studies involved debug or lifecycle mechanisms rather than cryptographic computation.

  • Problem

    The three example feasibility approaches rate physical-access hardware paths inconsistently, and TARA provides little guidance on when they warrant dedicated evidence or testing.

    Source: C. Consequence for the TARA · p. 5

  • Method

    The extension adds lifecycle attacker profiles, path dominance, an H0–H2 evidence gate, and rating rules that withhold implementation-resistance credit until required evidence exists.

    Source: §IX · p. 13

  • Results

    Seven of ten examined attacks used debug, boot, diagnostic, or update mechanisms rather than a cryptographic computation, and the reference architecture led to treatment or evaluation of five paths rated risk 1 or 2 by two example approaches.

    Source: §IX · p. 13

  • Takeaways & Limitations

    The findings support checking debug and lifecycle configuration and inventorying shared secrets before specialist SCA or FIA evaluation.

    Source: §IX · p. 13

    The method is qualitative, analyst consistency was not measured, the application uses a representative rather than production TARA, and the retrospective attack set is purposive and limited to published successful attacks.

    Source: D. Limitations · p. 13

Abstract

from arXiv · show

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.

I. INTRODUCTION

Automotive TARA connects assets and damage scenarios to threat scenarios, attack paths, feasibility and impact ratings, and risk-treatment decisions, but its methods mainly address architecture, software, and network threats. This paper addresses the inconsistent treatment of implementation-level hardware paths and the lack of guidance on when they require dedicated evidence or testing.

I. INTRODUCTION

  • Automotive TARA methods operate mainly at the architecture, software, and network levels, while implementation-level hardware attacks target assumptions about key confidentiality and boot or update decisions.SCA observes physical leakage, FIA perturbs computation or storage, and debug or test interfaces can expose memory and execution.Source: §I · p. 1, Figure 1 · p. 2
  • Two example feasibility approaches rate every physical-access path very low, while the third can assign any of four ratings, leaving both rating and evidence decisions unresolved.Testing every ECU against every physical attack is not economically realistic, while excluding all paths requiring physical access conflicts with published attacks and regulation.Source: §I · p. 1
  • The paper analyzes the three Annex G approaches, finding structural caps in the attack-vector and CVSS approaches and sensitivity to inputs unrelated to implementation in the attack-potential approach.The approaches are based respectively on attack vector, CVSS, and attack potential.Source: §I · p. 2
  • The proposed extension models lifecycle physical access, keeps SCA, FIA, and debug abuse as attack methods, and uses path dominance to identify when a simpler path makes specialist evaluation irrelevant.Its H0–H2 gate sets whether resistance may be argued, documented, or demonstrated, and hardware steps receive no implementation-specific resistance credit before required evidence exists.Source: §I · p. 2
  • The method is applied to a reference gateway architecture and its structural inputs are examined across ten published attacks on automotive components.The gate and rating rule are positioned relative to cybersecurity assurance levels and targeted attack feasibility.Source: §I · p. 2

A. TARA in ISO/SAE 21434

  • TARA identifies assets and damage scenarios, derives threat scenarios and attack paths, rates feasibility and impact, then informs risk treatment and cybersecurity requirements.When multiple paths realize one threat scenario, the standard gives assigning their maximum feasibility rating as an example.Source: A. TARA in ISO/SAE 21434 · p. 2

B. Implementation-Level Attack Classes

The paper considers passive leakage analysis, active fault injection, and abuse of debug or test interfaces, with physical access shaped by attacker profiles over the vehicle lifecycle. Supply-chain attacks are relevant TARA threats but lie outside the proposed gate.

B. Implementation-Level Attack Classes

  • SCA infers sensitive information from physical leakage, whereas FIA perturbs data, control flow, or security decisions and a single successful fault can defeat a dependent control.Examples of fault sources include voltage or clock glitches, electromagnetic pulses, and lasers.Source: B. Implementation-Level Attack Classes · p. 2
  • Debug and test interfaces needed during development, manufacturing, and service can expose firmware, memory, or execution in production, and fault injection can defeat their access controls.Debug access is treated as an attack method in its own right, not merely as a precondition for SCA or FIA.Source: B. Implementation-Level Attack Classes · p. 2
  • Some software-mediated attacks use on-chip resources for observation or fault induction, but their relevance to an ECU depends on whether compromised software can reach those resources.Examples include ADC observations correlated with computation and DVFS-induced faults; the cited effects have mostly been shown on non-automotive platforms.Source: B. Implementation-Level Attack Classes · pp. 2–3

C. Attacker Profiles Over the Vehicle Lifecycle

  • The paper models physical-access credibility by who can access a component, for how long, and whether the unit must remain functional.The owner and donor-unit profiles have an unlimited window of opportunity under the stated conditions.Source: C. Attacker Profiles Over the Vehicle… · p. 3

D. Scope

  • The gate excludes hardware Trojans, counterfeit or substituted components, and malicious fabrication or assembly modifications, which remain broader TARA branches.The proposed gate addresses attack paths against legitimately manufactured ECUs.Source: D. Scope · p. 3

A. Automotive TARA Methods

The paper situates its extension among automotive TARA methods, feasibility-rating critiques, assurance levels, and published hardware attacks. Its analysis of example ISO/SAE 21434 approaches finds that physical access can determine ratings independently of implementation resistance.

A. Automotive TARA Methods

  • Automotive TARA frameworks cover attack trees, damage scenarios, attack-surface assessment, and related methods, but generally operate at architecture, software, or network levels.Where hardware attacks appear as generic building blocks, ThreatSurf assigns very low feasibility to hardware extraction independently of implementation.Source: A. Automotive TARA Methods · p. 3

B. Attack Feasibility Rating

  • Prior work reports inconsistent attack-potential ratings and disagreement over the window-of-opportunity factor, but does not examine how Annex G approaches rate implementation-level paths.The cited smart-card guidance separates effort to identify an attack from effort to exploit it on another instance, a distinction ISO/SAE 21434 does not make.Source: B. Attack Feasibility Rating · p. 3

C. Assurance Levels

  • CAL scales the rigor of cybersecurity activities for a component or goal, while targeted attack feasibility describes feasibility sought after controls are applied.The paper relates its hardware relevance gate to CAL and TAF.Source: C. Assurance Levels · p. 3

D. Hardware Attacks on Automotive Components

  • Ten published automotive-component attack studies demonstrate feasible paths but do not translate them into damage scenarios, competing-path reasoning, or supplier-evidence and testing decisions.The proposed method addresses this interface between demonstrated attack paths and generic TARA methods.Source: D. Hardware Attacks on Automotive… · pp. 3–4

IV. PHYSICAL ATTACK PATHS UNDER THE ANNEX G APPROACHES

  • The comparison uses example values from Annex G, the Annex H risk matrix, and the Annex E CAL determination of ISO/SAE 21434:2021.Under both attack-vector and CVSS approaches, an open debug port and a key inside an evaluated secure element receive the same rating and risk value.Source: §IV · p. 4, A. Attack-Vector-Based and CVSS-Based… · p. 4

A. Attack-Vector-Based and CVSS-Based Approaches

  • Every path with a physical vector receives very low feasibility under the attack-vector approach, and CVSS likewise rates physical paths very low under its example weights.A typical hardware path with high complexity, no privileges, and no user interaction gives E = 0.52.Source: A. Attack-Vector-Based and CVSS-Based… · p. 4

B. Attack-Potential-Based Approach

The attack-potential approach can represent implementation differences, but hardware ratings are sensitive to assumptions about attacker knowledge and profile. The paper identifies a need for rules governing when implementation resistance can be claimed and how to rate a step before evidence exists.

B. Attack-Potential-Based Approach

  • The attack-potential sum is uncapped for physical paths, but its hardware-step ratings can be dominated by inputs unrelated to the implementation.The assumed state of knowledge and attacker profile affect elapsed-time, expertise, and window-of-opportunity ratings.Source: B. Attack-Potential-Based Approach · p. 4

C. Consequence for the TARA

  • Three of four hardware steps change rating across attacker assumptions, and electromagnetic fault injection spans all four ratings; for major impact, the same path’s risk value ranges from 1 to 4.The example factors use public knowledge throughout, while attacker profile changes the window of opportunity and assumed knowledge changes elapsed-time and expertise ratings.Source: B. Attack-Potential-Based Approach · p. 4, Table III · p. 5
  • Without implementation evidence, a hardware-step rating can imply strong resistance even though the team has not checked it.The method adds rules for when resistance may rest on argument, documented evidence, or test results, and how to rate the step while evidence is unavailable.Source: C. Consequence for the TARA · p. 5

V. HARDWARE-AWARE TARA METHODOLOGY

  • The extension adds attacker profiles and inventories, hardware-assisted paths and a dominance check, a hardware relevance gate, and hardware-step rating rules to the existing TARA workflow.The gate applies to each hardware-assisted path, with results collected per component because evidence requests and tests are planned per component.Source: §V · p. 5

A. Step 1: Assets, Properties, and Attacker Profiles

The method scopes hardware analysis to assets whose protection depends on implementation behavior, records the properties and inventories needed for path analysis, and keeps damage impact separate from attack technique. SCA, FIA, and debug-interface abuse are modeled as attack methods within paths, while STRIDE organizes threat scenarios.

A. Step 1: Assets, Properties, and Attacker Profiles

  • Hardware analysis starts with assets that could leak, be faulted, or be reached through debug or test interfaces, then records required properties and key and decision inventories.The key inventory records whether secrets are unit-unique or shared and where they are stored and used; the decision inventory records where authorizations occur and which controls depend on them.Source: A. Step 1: Assets, Properties, and… · p. 5

B. Step 2: Damage Scenarios and Impact

  • Damage scenarios describe vehicle- or stakeholder-level consequences independently of attack technique, and impact is rated from the consequence rather than the technique’s perceived severity.A key disclosure has safety impact only if the key enables a path to a safety-relevant function.Source: B. Step 2: Damage Scenarios and Impact · p. 5

C. Step 3: Threat Scenarios

D. Step 4: Attack Paths and Path Dominance

The method represents each attack path as an ordered sequence from entry condition to asset violation and models hardware attacks as steps within those paths. It compares paths by consequences and attack-potential factors so that dominated paths need not drive the analysis while a simpler path remains.

D. Step 4: Attack Paths and Path Dominance

  • A hardware-assisted path is an ordered sequence from an entry condition to an asset violation, with SCA, FIA, or debug/test-interface steps treated as hardware steps.Examples include access followed by SCA and key disclosure, access through a debug or boot interface to firmware or keys, and remote compromise followed by leakage or fault.Source: D. Step 4: Attack Paths and Path… · p. 6
  • A path dominates another when it can cause at least the same damage scenarios with no higher attack-potential level in any factor.This ordinal comparison can be made before rating, and a dominated path cannot raise the risk of a damage scenario while its dominating path exists.Source: D. Step 4: Attack Paths and Path… · p. 6
  • Remediable dominance means an in-scope control can remove the dominating path or raise its factor levels; otherwise dominance is inherent.An open debug port exposing the same key as an SCA path dominates it remediably, while a reset-only fault attack can be inherently dominated by CAN flooding when the consequences match.Source: D. Step 4: Attack Paths and Path… · pp. 6–7

E. Step 5: Hardware Relevance Gate

The hardware relevance gate determines what evidence must support resistance of a hardware step before the feasibility rating can rely on it. It uses baseline facts and five path-specific inputs to decide whether the path needs dedicated evidence.

1) Baseline:

  • Three low-cost baseline facts are established for each in-scope ECU: key inventory, decision inventory, and production state of debug, test, programming, and boot-mode interfaces.The interface state is checked for each production-relevant ECU variant and lifecycle configuration.Source: 1) Baseline · p. 7

2) Inputs:

  • Five inputs are determined for each hardware-assisted path: exposure, dominance, threat impact, leverage, and whether a comparable attack is known.Exposure requires access, a usable trigger, and the ability to observe leakage, use a fault effect, or activate an interface.Source: 2) Inputs · p. 7
  • Leverage is extended when the result scales across units or defeats a trust anchor; otherwise, it is local.A known attack supports exposure only when its demonstrated access and trigger conditions match an in-scope profile and configuration.Source: 2) Inputs · p. 7

3) Decision rule:

The decision rule assigns a hardware relevance level from exposure, dominance, impact, leverage, and known attacks. The level determines what evidence supports the feasibility rating, while the rating rules withhold credit for implementation-specific resistance until that evidence exists.

3) Decision rule:

  • Unexposed or inherently dominated paths are H0; remediably dominated paths are deferred until the dominating path is treated, while other paths receive a level based on impact and leverage.A known attack raises H1 to H2; the default mapping may be calibrated, but levels must not fall as impact or leverage rises.Source: 3) Decision rule · pp. 7–8

4) Levels and evidence:

  • H0 records why dedicated evidence is unnecessary and what assumption would reopen the question; H1 and H2 mean assumed resistance is insufficient.E1 documents an evaluation summary applicable to the specific primitive and configuration; E2 requires reviewable test results for production-representative hardware, firmware, and lifecycle state. A countermeasure description alone earns no credit.Source: 4) Levels and evidence · p. 8

F. Step 6: Feasibility Rating of Hardware Steps

  • For H1 or H2 physical paths, attack-potential rating is used when attack-vector or CVSS methods fix the result; no credit is given for resistance until required evidence exists.Rating rules use a follower for known attacks, the widest-access profile's window, and evidence-supported factor levels when evidence is available.Source: F. Step 6: Feasibility Rating of… · p. 8
  • Obscurity is not resistance, while fault repeatability and SCA trace counts enter through elapsed time; scalability is reflected through leverage and the opportunity window, not added again to impact.Treatment options include architectural changes and attack-specific countermeasures for SCA, FIA, and debug interfaces.Source: F. Step 6: Feasibility Rating of… · p. 8, G. Step 7: Risk Treatment and Evidence… · p. 8

G. Step 7: Risk Treatment and Evidence Plan

  • H1 evidence is requested from suppliers, H2 evaluations are planned as verification and validation, and H0 rationales are recorded as cybersecurity claims.Architecture or profile changes, new inventory entries, and publication of a relevant attack can reopen a decision; attack monitoring continues through the support period.Source: G. Step 7: Risk Treatment and Evidence… · p. 8

H. Relation to CAL and TAF

H-levels specify evidence for one hardware step on one attack path, whereas CALs scale the rigor of cybersecurity activities and TAF expresses a resistance target. The reference example applies the gate to a representative gateway architecture under stated assumptions.

H. Relation to CAL and TAF

  • An H-level fixes the evidence needed for a hardware step's feasibility rating; CAL applies to a component or goal and scales cybersecurity activity rigor, while TAF states a resistance target.An H2 path can require hardware testing even when an attack-vector-derived CAL is low.Source: H. Relation to CAL and TAF · p. 8, Table VI · p. 9, Table VII · p. 9

A. Item and Assumptions

  • The reference item is a representative gateway ECU, not a specific product, routing among vehicle domains and using an HSM, SecOC, verified firmware, diagnostics, and reprogramming.Its paths include a case beginning with compromised software on the telematics unit.Source: A. Item and Assumptions · p. 9, Figure 5 · p. 9
  • The diagnostic secret is assumed shared across vehicles and embedded in gateway firmware, while SecOC keys are unique per vehicle and confined to the HSM with supplier leakage evidence.Diagnostic authorization uses a challenge-response protocol and software encryption.Source: A. Item and Assumptions · p. 9
  • The assumptions include no supplier statement on boot fault resistance, published comparable bootloader and PCM password-check attacks, and an unverified production debug-port state.The gateway also lacks software-controlled clock or voltage regulation and an analog input sharing the HSM supply.Source: A. Item and Assumptions · p. 9
  • All five attacker profiles are in scope, and impact ratings are illustrative assumptions using the example risk matrix of Annex H.Source: A. Item and Assumptions · p. 9

B. Results

The reference gateway results contrast the unextended TARA ratings with the hardware-aware extension's evidence and treatment decisions. The paper also examines structural inputs across ten selected published automotive-component attacks without reproducing their TARAs or assigning risk values.

B. Results

  • For T1, an open debug port remediably dominates two other paths to the shared diagnostic secret; the extension treats the port first, then removes the secret through certificate-based authentication.The no-credit rating for the remaining paths is high feasibility with risk value 4.Source: B. Results · p. 10
  • For T2, applicable supplier leakage evidence supports very-low feasibility and risk value 2; without it, the no-credit outcome is high feasibility and risk value 5.A published SCA attack on the HSM family would raise the gate level to H2, beyond the summary evidence used in this example.Source: B. Results · p. 10
  • For T3, a known comparable attack on the secure-boot trust anchor yields H2; absent fault-resistance evidence, the owner-profile rating is high feasibility with risk value 5.Treatment combines redundant fail-secure verification with evaluation on a production-representative gateway.Source: B. Results · p. 10
  • T4 receives H0 because its moderate-impact, local path is inherently dominated; software-mediated T2 paths are also H0 because the assumed design exposes no measurement or perturbation resource.T4's rationale assumes no shared secret or authority beyond lighting; the software-path assumption is to be revisited if the microcontroller changes.Source: B. Results · p. 10
  • T5 receives H2 because a comparable boot-mode password attack is published and the password protects flash contents as a trust anchor; its no-credit rating is high feasibility with risk value 4.Source: B. Results · p. 10

C. Comparison With the Unextended TARA

  • All seven physical paths receive very-low ratings and risk values of 1 or 2 under attack-vector or CVSS approaches; the extension sends four paths to treatment or evaluation at risk 4 and one at risk 5.One path is closed by reviewed supplier evidence and two are excluded with recorded assumptions.Source: C. Comparison With the Unextended TARA · p. 10

A. Procedure

  • The ten-attack study is purposive and not exhaustive; missing item definitions and impact ratings prevent reproducing TARAs or assigning risk values.It examines exposure, attacked asset or decision, leverage, and competing paths, with the gate considered at design time with k = 0.Source: A. Procedure · p. 10

B. Results

In the ten published attacks examined, physical access was available on researchers’ units, and seven attacks used debug or lifecycle mechanisms rather than cryptographic computation. The results illustrate how the gate evaluates evidence needs while treating physical access as a feasibility factor, not an automatic reason to exclude a path.

B. Results

  • All ten studies performed the hardware step on units held by researchers, with access, trigger, and observation available without accessing a third party’s vehicle in use.This corresponds to the owner or donor-unit attacker profiles.Source: B. Results · pp. 10–11
  • Seven of ten studies obtained code or privileged execution through debug, programming, boot, diagnostic, or update mechanisms, while three recovered keys from cryptographic computations using SCA.The authors describe the study set as purposive, so these counts do not estimate attack prevalence.Source: B. Results · p. 11
  • In, firmware extracted by faulting read-out protection exposed key-diversification weaknesses, while profiled SCA of key loading remained possible without those weaknesses.Source: B. Results · p. 11
  • Eight studies yielded a class-wide secret or firmware, or defeated a trust anchor; in the other two, leverage depended on key sharing across vehicles.In and, a manufacturer or master key enabled cloning from one or two eavesdropped messages.Source: B. Results · p. 11
  • Under an assumed impact of at least major, the gate requires demonstrated evidence for eight paths and documented evidence for two, while the other two approaches rate all ten paths very low.The assumed impact is considered plausible for consequences including vehicle theft, persistent unauthorized code, or trust-anchor compromise.Source: B. Results · p. 11
  • Because all ten studies report successful attacks, the analysis can identify missed evidence requests but cannot assess over-classification; production TARAs are needed to determine whether the gate asks for too much.Under the stated impact assumption, the analysis found no successfully attacked path for which the gate would not request evidence.Source: B. Results · p. 11

A. Physical Access as an Exclusion Criterion

  • Physical access is a feasibility factor, not a reason by itself to remove a threat; a hardware-assisted path is excluded only when it is unexposed for every in-scope profile or inherently dominated.The complete path, follower effort, and leverage matter; demonstrated constraints such as narrow timing windows or destructive preparation can raise factor levels.Source: A. Physical Access as an Exclusion… · p. 12

B. Supplier Interface

The method turns TARA outcomes into evidence requests across the supplier chain and sets review criteria for modeling hardware-assisted paths. Its reference-architecture application and retrospective attack analysis illustrate the gate’s decisions, while the authors identify qualitative calibration and validation as limitations and future work.

B. Supplier Interface

  • An H1 or H2 outcome translates into evidence questions for suppliers about secrets outside security modules, SCA or FIA resistance, production debug states, shareable evaluations, key uniqueness, and fail-secure fault reactions.The evidence requests follow the supplier chain from vehicle manufacturer through Tier-1 supplier to semiconductor vendor.Source: B. Supplier Interface · p. 12

C. Review Criteria

  • Reviews should model SCA, FIA, and debug entry as attack methods tied to an asset property, declare owner and donor-unit profiles, inventory keys and decisions, verify production debug state, and check simpler paths first.Source: C. Review Criteria · p. 12

D. Limitations

  • The method is qualitative, its reference values are defaults derived from cited attacks, and analyst consistency has not been measured; the application uses a representative architecture rather than a production TARA.Source: D. Limitations · p. 13

IX. CONCLUSION

  • The hardware relevance gate uses exposure, dominance, impact, leverage, and known attacks to decide whether resistance may be argued, documented, or demonstrated; rating rules grant no resistance credit before evidence exists.Source: §IX · p. 13
  • Five reference-architecture paths rated at risk value 1 or 2 by the attack-vector-based and CVSS-based approaches led to treatment or evaluation; one path closed with supplier evidence, and two were excluded with recorded assumptions.Source: §IX · p. 13
  • Among ten published attacks, seven used debug, boot, diagnostic, or update mechanisms and not cryptographic computation, while eight had extended leverage.Source: §IX · p. 13
  • Future work includes a consistency study with independent analyst teams and application to a production TARA.Source: §IX · p. 13
Loading 2610.09697v1…