Safety & Security Co-Engineering - Standards & Compliance

Safety-Security Conflict Identification

Common Safety-Security Conflict Patterns

  Pattern 1: Security adds latency → safety deadline miss
  Security measure: AES-128 CAN PDU encryption (50 µs overhead)
  Safety impact: ASIL C steering torque PDU deadline 500 µs → 450 µs available
  Resolution: Hardware crypto offload (HSM), Profile-based selective encryption

  Pattern 2: Safety mechanism creates security vulnerability
  Safety measure: Unauthenticated watchdog reset (triggers immediately on fault)
  Security impact: Attacker exploits reset to bypass secure boot, enter debug mode
  Resolution: Authenticated reset request (HMAC) + rate-limiting on reset API

  Pattern 3: Security update disrupts safety availability
  Security measure: PKI certificate rotation (ECU offline 30 s)
  Safety impact: ASIL B function unavailable for 30 s → exposure window
  Resolution: Scheduled rotation during vehicle parked (ignition off) + staged rollout

  Pattern 4: Safety partition weakens security isolation
  Safety measure: Memory-protected ASIL partition writes to shared buffer
  Security impact: Shared buffer exploitable as cross-partition attack vector
  Resolution: Asymmetric shared memory (safety writes, QM reads only)

Joint TARA+HARA Workshop Process

Pythontara_hara_joint_analysis.py

#!/usr/bin/env python3
# Joint TARA+HARA co-engineering record template

co_engineering_records = [
    {
        "id": "CSSR-001",
        "scenario": "Malicious firmware flash via OBD diagnostic port",
        "hara_hazard": "ASIL D — wrong brake control code controls brake actuators → collision",
        "tara_threat": "STRIDE-T Tampering — UDS 0x34/0x36 write arbitrary flash pages",
        "conflict": None,  # Both frameworks agree: mitigate
        "mitigations": [
            "ISO 26262: ASIL D software integrity check on every power cycle (SW signature verification)",
            "ISO/SAE 21434: Secure boot HSM-based signature verification; programming session requires OEM key",
            "Combined: Secure boot satisfies both — counts as safety measure AND security control",
        ],
        "residual_risk": "Both safety and security risk accepted as ALARP after HSM secure boot"
    },
    {
        "id": "CSSR-002",
        "scenario": "DoS attack floods CAN bus → safety-critical messages delayed",
        "hara_hazard": "ASIL C — ESC torque request missing for > 20 ms → loss of stability control",
        "tara_threat": "STRIDE-D Denial of Service — CAN bus flooded with high-ID frames",
        "conflict": "No single mitigation satisfies both: bus-off recovery (26262) vs. attack detection (21434)",
        "mitigations": [
            "ISO 26262: Bus-off recovery with 1.4 ms recovery time (128 × 11 recessive bits)",
            "ISO/SAE 21434: CAN Intrusion Detection System detects ID flooding; isolates source node",
            "Combined: CIDS limits flood duration; bus-off ensures recovery within ASIL C timing",
        ],
        "residual_risk": "Accepted: CIDS + bus-off combined response time < 5 ms; within ASIL C deadline"
    },
]

for rec in co_engineering_records:
    print(f"[{rec['id']}] {rec['scenario']}")
    print(f"  26262 Hazard: {rec['hara_hazard']}")
    print(f"  21434 Threat: {rec['tara_threat']}")
    if rec['conflict']: print(f"  CONFLICT: {rec['conflict']}")
    print(f"  Residual Risk: {rec['residual_risk']}")
    print()

Secure Boot vs Safety Startup Timing

ECU Type	Startup Requirement	Secure Boot Time	Resolution
Airbag ECU	< 100 ms to functional	150–300 ms (full hash)	Safety-first: airbag activatable in 100 ms; attestation runs async; ECU flags 'unverified' until complete
ESC ECU	< 200 ms to first ESC calculation	100–200 ms (hash + cert chain)	Parallel: ESC initialises from ROM shadow; secure boot verifies async; fault flag if boot fails
ADAS Gateway	< 500 ms to first sensor fusion	150–300 ms	Sequential: full secure boot before ADAS enables; 500 ms budget accommodates secure boot
Infotainment Head Unit	< 3 s to UI ready	300–500 ms	Sequential: no safety timing constraint; full secure boot before any function

OEM-Supplier Safety-Security Interface Agreement (SSIA)

Responsibility	OEM	Tier 1 Supplier
PKI and Certificate Authority	OEM operates vehicle PKI; issues ECU certificates	Supplier integrates certificate into ECU; implements TLS/DTLS client
Key injection at EOL	OEM provides key injection station and keys	Supplier implements HSM key loading API; provides EOL test procedure
Security testing scope	OEM pen-tests vehicle-level attack surfaces	Supplier pen-tests ECU-level: DMA, debug port, CAN, UDS
Secure boot implementation	OEM specifies boot chain requirements	Supplier implements HSM-based secure boot per OEM spec
Vulnerability response	OEM coordinates field patch deployment	Supplier provides root cause analysis and patch within SLA (30 days critical)

Summary

Safety-security co-engineering is not optional — it is required by both ISO 26262 (which must consider all sources of hazard, including malicious attack) and ISO/SAE 21434 (which must consider safety-critical systems as high-value targets). The joint TARA+HARA workshop is the most efficient mechanism: identify shared scenarios once, apply both frameworks simultaneously, and document the combined mitigation in one co-engineering record. The SSIA clearly divides responsibilities before development starts, preventing costly rework when 'who does the key injection?' is discovered at PPAP.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.