AD-21 — Automotive Cybersecurity: ISO/SAE 21434, TARA and UNECE R155/R156

ASSUMPTION — This lesson assumes familiarity with the basic principles of symmetric/asymmetric cryptography, in-vehicle CAN/Ethernet communication protocols, and ISO 26262 (AD-19) functional safety concepts.

In AD-19, we examined risk arising from faults (“what happens if something breaks?”); in AD-20, from functional insufficiencies (“what happens if a wrong decision is made without anything breaking?”). In this lesson we turn to the third and final hazard lens: deliberate, malicious interference (“what happens if an attacker deliberately targets the system?”). We’ll see how the very same braking and steering systems can become the target not of a random fault, but of a planned attack.

In this lesson, you will learn:

1. The New Attack Surface of Connected Vehicles — V2X, OTA channels, cellular/Wi-Fi/Bluetooth, and the CAN bus’s historical lack of authentication.
2. Landmark Case: The 2015 Jeep Cherokee Remote Hack — the real-world evidence that catalyzed regulatory response.
3. ISO/SAE 21434 and TARA — cybersecurity’s direct counterpart to HARA.
4. UNECE R155 and R156 — the legal mechanism that makes the technical standard mandatory.
5. In-Vehicle Security: SecOC and HSM — bringing authentication to the CAN bus.
6. Resilient OTA Architecture — end-to-end signing and A/B rollback.
7. Synthesizing the Three Lenses: Fault, Insufficiency, Malice — how AD-19/20/21 together form a single safety case.

---

1. The New Attack Surface of Connected Vehicles

Connected and Autonomous Vehicles (CAVs) are complex distributed computing platforms running hundreds of millions of lines of code while maintaining persistent communication with the outside world. This connectivity creates an attack surface that simply did not exist in a conventional vehicle:

Channel	Description	Typical Risk
V2X (Vehicle-to-Everything)	Vehicles wirelessly communicate with infrastructure and other vehicles	Spoofed message injection, fake traffic/collision warnings
OTA Update Channel	Software updates delivered over cellular connectivity	Unsigned/malicious firmware injection (see §6)
Cellular (4G/5G) Telematics	Fleet tracking, remote diagnostics, emergency call (eCall)	The telematics unit is a pivot point into the in-vehicle network
Wi-Fi / Bluetooth	Driver phone pairing, wireless diagnostics	Short-range wireless exploits, malicious pairing
CAN Bus (internal)	Real-time control messaging between ECUs	No authentication — see below

CRITICAL — The classic Controller Area Network (CAN) protocol was designed in the late 1980s under the assumption of a closed, physically isolated in-vehicle network: messages carry neither encryption nor sender authentication. Any ECU can broadcast a message onto the bus claiming “I am the brake control unit,” and every other node on the bus accepts it without question. That assumption was a reasonable engineering trade-off before vehicles were connected to the outside world — today, compromising a single exposed entry point (the telematics unit, a cellular modem) can, if that entry point can traverse the CAN gateway, open the door for an attacker to spoof braking or steering commands.

This makes automotive cybersecurity a direct prerequisite for functional safety (AD-19): ISO 26262’s goal of “reliable enough not to fault” and SOTIF’s (AD-20) goal of “robust enough not to fall short” become meaningless if the system can simply be deliberately compromised.

---

2. Landmark Case: The 2015 Jeep Cherokee Remote Hack

EXAMPLE — In 2015, security researchers Charlie Miller and Chris Valasek publicly demonstrated that they could remotely compromise a Jeep Cherokee’s telematics/infotainment system (Uconnect) over cellular connectivity — from miles away, with no physical access to the vehicle. By pivoting from the infotainment system into the in-vehicle CAN gateway, the researchers showed they could remotely control climate control, the radio, the windshield wipers, and ultimately transmission and braking functions while the vehicle was traveling at highway speed. This demonstration became the concrete, widely publicized proof that “the in-vehicle network cannot be assumed isolated from the outside world.”

ASSUMPTION — The high-level facts of this event (the researchers’ identities, remote access via cellular connectivity, and the large-scale recall campaign that followed) are widely documented; however, the exact technical steps of the exploit chain, the precise number of affected vehicles, and the full scope of the recall are not asserted with precision in this lesson — consult the original research publication and manufacturer/regulatory statements for current, exact figures.

This case is widely cited as evidence not merely of a single vulnerability but of a systemic architectural gap: there was insufficient network segmentation (hardware firewalling, gateway filtering) between a low-criticality, externally exposed component (infotainment) and high-criticality components (braking, steering). This incident and others like it are commonly cited as concrete drivers that accelerated the emergence of the UNECE R155/R156 regulations covered below.

---

3. ISO/SAE 21434 and Threat Analysis & Risk Assessment (TARA)

ISO/SAE 21434 defines cybersecurity engineering across the full automotive product lifecycle (concept, development, production, operation, maintenance, decommissioning). At its center is TARA (Threat Analysis and Risk Assessment) — the direct cybersecurity counterpart to HARA (AD-19): where HARA asks “how dangerous is this fault,” TARA asks “how feasible and how damaging is this threat.”

+--------------------------------------------------------------------------+
|                     ISO/SAE 21434 TARA WORKFLOW                          |
+--------------------------------------------------------------------------+
|  1. Asset Identification                                                  |
|     - Confidentiality, Integrity, Availability (CIA) properties          |
+--------------------------------------------------------------------------+
                                    |
                                    v
+--------------------------------------------------------------------------+
|  2. Threat Scenario Identification                                       |
|     - e.g., CAN bus spoofing, radar false-echo injection                 |
+--------------------------------------------------------------------------+
                                    |
                                    v
+--------------------------------------------------------------------------+
|  3. Impact Rating (SFOP)                                                  |
|     - Safety, Financial, Operational, Privacy                            |
|       -> [Negligible / Moderate / Major / Severe]                        |
+--------------------------------------------------------------------------+
                                    |
                                    v
+--------------------------------------------------------------------------+
|  4. Attack Path Analysis and Feasibility                                 |
|     - Elapsed Time, Expertise, System Knowledge,                         |
|       Window of Opportunity, Equipment                                    |
|       -> [Very Low / Low / Medium / High]                                |
+--------------------------------------------------------------------------+
                                    |
                                    v
+--------------------------------------------------------------------------+
|  5. Risk Determination and Treatment Decision                             |
|     - Risk Value: 1 (Negligible) to 5 (Critical)                         |
|     - Decision: Mitigate / Transfer / Retain / Avoid                     |
+--------------------------------------------------------------------------+

FACT — The mere existence of a vulnerability does not by itself constitute risk. Risk is the composite of a threat scenario’s Attack Feasibility and its Impact Rating — just as, in HARA, Exposure × Controllability × Severity determines the ASIL, here Feasibility × Impact determines the risk score.

TARA’s “Safety” impact dimension maps directly onto ISO 26262’s ASIL classification: if a cyber threat’s safety impact is rated “severe” and the function it targets serves an ASIL D Safety Goal, mitigation priority is escalated to the highest tier.

---

4. UNECE R155 and R156 Regulatory Mandates

Regulations R155 and R156, issued by the United Nations Economic Commission for Europe (UNECE), have become a mandatory type approval requirement for new vehicles registered across the EU market and numerous other jurisdictions.

INTERPRETATION — The relationship between R155/R156 and ISO/SAE 21434 is conceptually similar to the relationship between ISO 26262 and functional safety regulation covered in AD-19: the standard answers the technical “how”; the regulation imposes the legal “you must.” An OEM could, in principle, apply ISO/SAE 21434 purely as an engineering/quality choice — but to sell in markets covered by R155/R156, it must demonstrate CSMS/SUMS certification, and in practice the most common way to demonstrate that is by showing compliance with ISO/SAE 21434.

1. UNECE R155 (Cybersecurity Management System — CSMS):

   • Certifies that the OEM operates an organizational cybersecurity management system.
   • Mandates that cybersecurity requirements be managed across the supply chain (Tier-1, Tier-2).
   • Requires continuous post-production fleet-wide cybersecurity threat monitoring (a VSOC — Vehicle Security Operations Center) and structured incident response processes — meaning the requirement isn’t just “design securely at development time,” but that the vehicle remain monitorable and responsive throughout its entire lifecycle.

2. UNECE R156 (Software Update Management System — SUMS):

   • Guarantees that software updates delivered to vehicles are secure, verifiable, and traceable — ensuring the OTA process itself does not become a new attack vector (see §6).
   • RxSWIN (RegulationX Software Identification Number): Uniquely identifies the software version of type-approval-relevant ECUs (e.g., braking or automated driving software) to regulatory authorities.

Standard / Regulation	Scope	Mandate / Audit	Primary Output
ISO/SAE 21434	Engineering process standard	International OEM & supplier baseline	TARA reports, Cybersecurity Case
UNECE R155	Legal type approval regulation	Mandatory for new registrations (EU and aligned markets)	CSMS certificate, type approval
UNECE R156	Software update regulation	Mandatory for update-capable vehicles	SUMS certificate, RxSWIN tracking

ASSUMPTION — The precise enforcement timeline and the exact list of markets where R155/R156 are mandatory can vary by region and vehicle segment; the “mandatory for new registrations in the EU and aligned markets” statement given here is a general summary — consult the relevant type approval authority’s current documentation for exact effective dates.

---

5. In-Vehicle Security: SecOC and Hardware Security Modules (HSM)

As noted in §1, classic CAN bus messages are unencrypted and carry no sender authentication. This can allow malicious hardware with bus access (via an OBD-II port, or a compromised telematics unit) to inject spoofed braking or acceleration commands.

SecOC (Secure Onboard Communication — AUTOSAR)

SecOC appends a Message Authentication Code (MAC) and a Freshness Value to critical messages, preventing replay attacks and message spoofing:

$\mathrm{MAC} = \mathrm{Truncate}_{m}\Big(\mathrm{AES\text{-}CMAC}_{K}\big(\mathrm{Data} \parallel \mathrm{FreshnessValue}\big)\Big)$

Where:

• $K$: A symmetric key securely pre-shared between the transmitting and receiving ECUs.
• $\mathrm{FreshnessValue}$: A monotonic counter incremented with every message (prevents replay attacks — a valid message cannot be captured and resent later).
• $m$: The truncated MAC bit-length (typically 24 to 64 bits), which balances cryptographic collision resistance against bus bandwidth constraints.

HSM (Hardware Security Module)

Modern automotive microcontrollers (e.g., Infineon AURIX TC3xx/TC4xx, the Renesas RH850 family) integrate an HSM: an isolated core with dedicated RAM/ROM and hardware cryptographic accelerators (AES, SHA, ECC/RSA):

• Secure Boot: At power-up, the cryptographic hash (e.g., SHA-256) of the firmware in flash memory is verified. If the digital signature (RSA/ECC) cannot be validated, the microcontroller halts execution and enters a safe state.
• Cryptographic Key Isolation: Private keys never enter the Host CPU’s memory space; cryptographic operations execute exclusively within the HSM — preventing an application-level buffer overflow exploit from directly exposing the keys.

WARNING — Cybersecurity measures add latency. When SecOC verification is added to a torque control message running on a 10 ms cycle, HSM cryptographic compute time and total bus load (CAN bus load) generally must be budgeted to stay below a 70% saturation ceiling — otherwise the cryptographic overhead can consume the FTTI budget we saw in AD-19, putting functional safety itself at risk. This is a concrete example of why cybersecurity and functional safety must be co-optimized at the design level.

---

6. Resilient OTA (Over-the-Air) Update Architecture

Automated driving software requires large model weight and system updates; this update channel itself must not become the new attack vector that UNECE R156 is specifically concerned with. Two layers are mandatory in a secure OTA architecture:

1. End-to-End Cryptographic Signing: The update package is signed with a private key at the OEM’s secure build infrastructure. The vehicle’s Telematics Control Unit (TCU) acts strictly as a transport carrier; package integrity is verified directly by the target ECU’s HSM using the OEM’s factory-embedded public key — even if the TCU itself is compromised, a spoofed package cannot execute on the target ECU.
2. A/B Dual-Bank Flash Architecture: New firmware is staged into the dormant Bank B while the vehicle continues operating on active Bank A. Activation occurs only during safe, stationary states (parked, ignition off). If verification fails, or if a runtime integrity check mismatches, the system instantly rolls back to Bank A.

Secure OTA Flow:

  OEM Backend            TCU (Carrier)           Target ECU + HSM
  ────────────           ──────────────          ─────────────────
  Sign package    ──►    Download package  ──►    HSM verifies signature
  (private key)          (performs NO                (against factory
                          verification)               public key)
                                                          │
                                       Signature valid?    │
                                    ┌─────────────────────┴────────────────┐
                                    ▼ Yes                                   ▼ No
                            Write to Bank B,                        Reject package,
                            activate at next                        remain on Bank A
                            park/ignition-off
                                    │
                            Runtime integrity mismatch?
                                    │ Yes
                                    ▼
                            Instant rollback to Bank A
                            (automatic rollback)

---

7. Synthesizing the Three Lenses: Fault, Insufficiency, Malice

Across these three lessons (“Was it a fault? A limitation? Malice?”), we’ve examined the same physical component — say, an electronic power steering (EPS) system — through three different lenses:

Lesson	Question	EPS Example	Standard
AD-19 (Functional Safety)	What happens if a component fails on its own?	The torque sensor short-circuits, and the EPS motor produces a random torque	ISO 26262
AD-20 (SOTIF)	What happens if the system makes a wrong decision with nothing broken?	The lane-following algorithm misinterprets a faded lane marking on wet asphalt and produces a mild, incorrect torque command	ISO 21448
AD-21 (Cybersecurity)	What happens if an attacker deliberately targets the system?	A compromised telematics unit traverses the CAN gateway and injects a spoofed, deliberate torque command into the EPS	ISO/SAE 21434, UNECE R155/R156

CRITICAL — These three are complementary, not alternatives. A complete safety-and-security case acknowledges that the same Safety Goal can be threatened through all three lenses, and designs distinct but coordinated mitigations for each. TARA’s “Safety” impact dimension mapping directly onto ASIL (§3) is concrete evidence of how these three disciplines converge, in practice, at the same engineering team’s table.

---

Frequently Asked Questions (FAQ)

Q: How do ISO 26262 (Functional Safety) and ISO/SAE 21434 (Cybersecurity) work together?

FACT — The two standards complement each other. ISO 26262 addresses random hardware faults and systematic software bugs, while ISO 21434 addresses deliberate, malicious external interference. A cybersecurity breach that defeats security can violate a Safety Goal. TARA’s “Safety Impact” dimension maps directly to ISO 26262’s HARA classification (the ASIL rating).

Q: Why is RxSWIN so critical to UNECE R156 compliance?

FACT — A parameter change in automated driving software can alter the vehicle’s braking distance or object detection capability. RxSWIN records the type-approved software version. When an OEM issues an update that affects regulatory test results, it must apply to the relevant authority to update the type approval.

Q: Does directly spoofing a sensor physically fall under cybersecurity?

FACT — Yes. Directing a laser at a camera lens (camera dazzling), spoofing GPS signals, or injecting fake echo signals into radar (radar jamming/ghosting) are physical-layer cyberattacks, and they are examined within TARA’s attack tree under ISO/SAE 21434.

Q: Is SecOC applied to every single CAN message?

INTERPRETATION — No, not in practice. Because SecOC carries compute and bandwidth cost (§5), it’s typically applied only to safety-critical messages (braking, steering, propulsion torque commands); low-criticality comfort messages (e.g., seat position) are generally left out of scope. Which messages require SecOC is derived from TARA’s risk assessment output.

---

Safety and System Boundaries

• Cryptographic algorithms must remain agile against the post-quantum era; key lengths that may weaken in the future must be designed to be updatable via OTA.
• The vehicle must not perform an abrupt emergency stop the moment a cyberattack is detected; even mid-attack, minimal controllability (fail-operational behavior) must be preserved, executing a safe Minimal Risk Maneuver (MRM) — this is the cybersecurity-context counterpart to the fail-safe/fail-operational distinction from AD-19.

---

Summary

• Connected vehicles carry an attack surface that never existed in conventional vehicles, owing to V2X/OTA/cellular/Wi-Fi/Bluetooth interfaces and a CAN bus that historically lacks authentication.
• The 2015 Jeep Cherokee remote hack demonstration is widely cited as the landmark case proving this risk was not theoretical, and it accelerated regulatory response.
• TARA is HARA’s (AD-19) direct cybersecurity counterpart: asset identification, threat scenario identification, impact rating (SFOP), attack feasibility, and risk treatment decisions.
• UNECE R155 (CSMS) and R156 (SUMS/RxSWIN) are the legal mechanisms that make ISO/SAE 21434’s technical practices mandatory for market access — the standard represents the “how,” the regulation represents the “you must.”
• SecOC (MAC + freshness value) and HSM (secure boot + key isolation) bring concrete technical mitigation to a historically unauthenticated CAN bus; a secure OTA architecture, through end-to-end signing and A/B rollback, keeps the update channel itself from becoming an attack vector.
• Faults (AD-19), functional insufficiencies (AD-20), and malicious interference (AD-21) are three distinct, complementary lenses threatening the same component.

Sources and Verification Note

This lesson is grounded in ISO/SAE 21434:2021 (Road vehicles — Cybersecurity engineering), the UNECE R155 and R156 regulations, and their complementary standards ISO 26262 and ISO 21448. The TARA workflow and SFOP impact dimensions are an educational reconstruction of the standard’s general structure. The high-level facts of the 2015 Jeep Cherokee case (the researchers, remote cellular access, and its subsequent regulatory impact) are widely documented, but the exact technical details of the exploit chain and precise recall figures are marked ASSUMPTION in this lesson. The regional enforcement scope of R155/R156 is likewise marked ASSUMPTION — consult the original standard and regulation texts and the relevant type approval authority’s documentation for current, exact information.

Next Lesson

• AD-22 — Verification and Validation: MIL, SIL, HIL, VIL, Track and Simulation: how the three safety/security lenses defined in AD-19/20/21 — fault, insufficiency, and malice — are systematically tested and verified; the validation chain running from Model-in-the-Loop through to real-world track testing.