Cryptography

Below is a practical, ISO/SAE 21434-aligned description of how cryptography is used in an automotive ECU across the full lifecycle, clearly distinguishing Tier-1 vs OEM responsibilities. This is written in the way assessors, auditors, and OEM cybersecurity teams expect to see it.

1. Concept Phase (Item Definition & Threat Analysis)

Purpose of Cryptography

At this phase, cryptography is not yet implemented, but strategically defined to mitigate threats identified in TARA.

Typical Cryptographic Objectives

• Prevent unauthorized software execution

• Ensure authenticity of ECUs and vehicle networks

• Protect sensitive data (keys, firmware, personal data)

• Enable secure diagnostics and updates

Standards Driving Decisions

• ISO/SAE 21434

• UNECE UN R155

• OEM internal cryptographic policy (algorithms, key lengths, PKI model)

OEM Responsibility

• Define cryptographic strategy:

  • Symmetric vs asymmetric crypto

  • PKI vs shared secrets

  • Root of Trust concept

• Define Cybersecurity Goals & Claims

• Define Vehicle PKI (VPKI) concept

• Define lifecycle key ownership

Tier-1 Responsibility

• Provide feasibility input

• Propose crypto-capable HW (MCU, HSM)

• Identify performance & cost impacts

2. System & Architecture Design Phase

Cryptography Gets Architected

Key Design Elements

• Root of Trust (RoT)

• Secure key storage

• Cryptographic services partitioning

• Trust boundaries

Typical Mechanisms

Area	Cryptography Used
Secure Boot	Asymmetric signatures (RSA/ECC)
In-vehicle comms	MACs, symmetric encryption
Diagnostics	Challenge-response
OTA	Firmware signing + encryption
Identity	ECU certificates

OEM Responsibility

• Approve:

  • Algorithms (e.g. AES-128/256, ECC-P256)

  • Certificate hierarchy

  • Key lifetimes

• Define security interfaces (Diag, OTA, CAN, Ethernet)

• Define key provisioning model

Tier-1 Responsibility

• Design ECU security architecture

• Integrate:

  • AUTOSAR Crypto Stack

  • Hardware Security Module (HSM)

• Define crypto APIs and isolation

3. Detailed Design & Implementation Phase

Cryptography Is Implemented in ECU Software & Hardware

Common Implementations

• Secure Boot chain:

  • Boot ROM → Bootloader → Application

• Secure Flashing:

  • Signed & optionally encrypted firmware

• Secure Communication:

  • CAN/Ethernet message authentication

• Secure Diagnostics:

  • Certificate-based or key-based access

Tier-1 Responsibility (Primary Owner)

• Implement cryptography:

  • Crypto libraries

  • Key handling logic

• Ensure:

  • Keys never leave secure boundary

  • No hard-coded secrets

• Perform:

  • Secure coding

  • Static analysis

  • Crypto misuse checks

OEM Responsibility

• Audit:

  • Crypto design compliance

  • Algorithm compliance

• Approve key lengths, curves, modes

• Review misuse risks (weak randomness, reuse)

---

4. Integration, Verification & Validation

What Is Verified

• Correct cryptographic behavior under attack conditions

• Proper key isolation

• Secure failure handling

Typical Tests

• Secure boot bypass attempts

• Invalid signature injection

• Replay attacks

• Diagnostic brute-force attempts

Tier-1 Responsibility

• ECU-level crypto testing

• Pen-testing of ECU interfaces

• Provide test evidence

OEM Responsibility

• Vehicle-level cybersecurity validation

• Independent penetration testing

• Final approval for SOP

---

5. Production & Manufacturing Phase

Cryptography Becomes Operational

Key Activities

• ECU identity creation

• Key injection

• Certificate provisioning

OEM Responsibility

• Operate PKI

• Own:

  • Root CA

  • Intermediate CAs

• Control:

  • Key generation

  • Revocation

• Approve manufacturing security

Tier-1 Responsibility

• Secure manufacturing environment

• Inject:

  • ECU certificates

  • Initial secrets

• Prevent:

  • Key leakage

  • Over-provisioning

---

6. Operation & Maintenance Phase (Vehicle in Field)

Cryptography Protects Live Vehicle

Usage Examples

• Secure diagnostics at workshops

• Secure OTA updates

• Secure backend-to-vehicle communication

• ECU authentication on vehicle network

OEM Responsibility

• Operate backend systems

• Manage:

  • Certificate renewal

  • Revocation lists (CRL)

• Incident response (CSMS)

Tier-1 Responsibility

• Support:

  • Crypto updates

  • Patch compatibility

• Provide root cause analysis for crypto incidents

---

7. End-of-Life (EOL) Phase

Cryptography Is Decommissioned

Activities

• Disable backend access

• Revoke certificates

• Prevent reuse of ECUs

OEM Responsibility

• Define EOL crypto policy

• Ensure backend revocation

• Compliance with UN R155 CSMS

Tier-1 Responsibility

• Support secure decommissioning

• Provide EOL documentation

---

Summary: Tier-1 vs OEM Responsibilities

Area	OEM	Tier-1
Crypto strategy	✅	◐
PKI ownership	✅	❌
ECU crypto implementation	❌	✅
Key injection	Governance	Execution
Secure boot & comms	Approval	Implementation
OTA crypto	Backend	ECU side
EOL revocation	✅	Support

Cryptography Checklist for ECU Projects

1. Planning / Concept Phase (Item Definition & TARA)

Governance & Strategy

• ☐ Cryptographic policy received from OEM (algorithms, key sizes, curves, modes)

• ☐ Regulatory alignment confirmed (ISO/SAE 21434, UN R155)

• ☐ Cryptography included in Cybersecurity Goals & Claims

• ☐ Cryptography mapped to threat scenarios in TARA

• ☐ Clear Tier-1 vs OEM responsibility split defined

High-Level Design Decisions

• ☐ Root of Trust (RoT) concept defined

• ☐ PKI vs symmetric key strategy decided

• ☐ Secure boot required? (Yes/No – justification)

• ☐ Secure diagnostics required? (Yes/No)

• ☐ Secure OTA/update requirement confirmed

---

2. System & Architecture Design Phase

Architecture & Trust Boundaries

• ☐ Secure boot chain defined (ROM → Bootloader → App)

• ☐ Trust boundaries documented (HW, SW, backend)

• ☐ Secure storage location for keys identified

• ☐ Hardware security capability confirmed (HSM/TPM/TEE)

Algorithms & Mechanisms

• ☐ Approved algorithms selected (e.g., AES, ECC, SHA-2)

• ☐ Random number generation source defined (TRNG/DRBG)

• ☐ Message authentication vs encryption decision justified

• ☐ Certificate hierarchy defined (Root, Intermediate, ECU)

Interfaces

• ☐ Cryptography applied to:

  • ☐ In-vehicle communication (CAN/Ethernet)

  • ☐ Diagnostics (UDS/DoIP)

  • ☐ Flashing / OTA

• ☐ Secure failure behavior defined (no silent bypass)

---

3. Detailed Design Phase

Key Management Design

• ☐ Key types identified (root, boot, session, diagnostic)

• ☐ Key lifetimes defined

• ☐ Key rotation strategy defined

• ☐ Revocation mechanism designed

• ☐ No shared keys across ECUs (unless justified)

Software Design

• ☐ Crypto services isolated from application logic

• ☐ Use of standard crypto stack (e.g. AUTOSAR Crypto)

• ☐ No custom crypto algorithms

• ☐ No hard-coded secrets

• ☐ Side-channel considerations documented

---

4. Implementation Phase

Secure Coding

• ☐ Certified or OEM-approved crypto library used

• ☐ Proper key zeroization implemented

• ☐ Secure memory access enforced

• ☐ Error handling does not leak sensitive info

• ☐ Debug/test backdoors removed or protected

Secure Boot & Flashing

• ☐ Firmware authenticity verified before execution

• ☐ Rollback protection implemented

• ☐ Flashing requires cryptographic authorization

• ☐ Integrity check covers full image

---

5. Integration & Verification Phase

Functional Verification

• ☐ Secure boot verification tested (valid/invalid images)

• ☐ Secure flashing tested (authorized/unauthorized)

• ☐ Diagnostic authentication tested

• ☐ Communication authentication/encryption tested

Security Testing

• ☐ Replay attack resistance verified

• ☐ Brute-force resistance verified

• ☐ Fault injection behavior checked

• ☐ Pen-test findings addressed

Evidence

• ☐ Cryptography test reports available

• ☐ Traceability to cybersecurity requirements complete

---

6. Production & End-of-Line (EOL – Manufacturing)

Key Injection & Provisioning

• ☐ Secure key injection process approved by OEM

• ☐ Keys generated in secure environment

• ☐ ECU identity (certificate/ID) provisioned

• ☐ Manufacturing access protected with crypto

Manufacturing Security

• ☐ No master keys exposed to operators

• ☐ Logging of key provisioning events enabled

• ☐ Separation of test vs production keys enforced

• ☐ Secure erase of temporary secrets completed

---

7. Operation & Maintenance (Vehicle in Field)

Live Cryptographic Operations

• ☐ Secure diagnostics enforced in workshops

• ☐ OTA updates cryptographically protected

• ☐ Backend authentication enforced

• ☐ Certificate validity monitored

Incident Handling

• ☐ Certificate/key revocation supported

• ☐ Crypto updates supported without ECU replacement

• ☐ Incident response procedure defined (CSMS)

---

8. End-of-Life (Vehicle & ECU Decommissioning)

Decommissioning

• ☐ Backend access revoked

• ☐ Certificates invalidated

• ☐ OTA disabled

• ☐ Diagnostic access restricted or disabled

Reuse & Disposal

• ☐ ECU reuse prevention strategy defined

• ☐ Secure wipe procedure supported (if required)

• ☐ EOL compliance evidence available (UN R155)

---

Final OEM / Tier-1 Ownership Snapshot

Area	OEM	Tier-1
Crypto policy & PKI	✅	❌
ECU crypto architecture	Approval	✅
Crypto implementation	❌	✅
Manufacturing keys	Governance	Execution
Field operations	✅	Support
EOL revocation	✅	Support