TDA4VM ADAS ECU Cybersecurity Requirements

Secure Communication Requirements (incl. AUTOSAR SecOC) - TDA4VM ADAS ECU

This doc covers the full in-vehicle and off-board secure communication stack: per-PDU authenticity and freshness protection using the AUTOSAR SecOC pattern (truncated freshness value + MAC appended to an Authentic PDU to form a Secured PDU), confidentiality-protected channels for sensitive payloads (SA2UL AES-GCM), off-board (cloud/backend) TLS/mTLS sessions, and the shared key/session management underlying all three.

1. Functional Security Concept

1.1 Cybersecurity Goals (CSG)

1.2 Functional Security Concept (FSC)

1.3 Functional Security Requirements (FSR)

2. System Requirements and System Static Architecture

2.1 System entities

2.2 Trust boundaries and interfaces

graph LR
  App[Sender Application] --> Tx[SecOC TX Module]
  Tx --> Csm[CSM/SA2UL Crypto Boundary]
  Csm --> Rx[SecOC RX Module]
  Rx --> AppR[Receiver Application]
  Key[Key/Session Manager] --> Tx
  Key --> Rx
  Rx --> Log[Secure Logging]
  App --> Conf[Confidentiality Encryptor/Decryptor]
  Conf --> AppR
  Key --> Conf
  App --> OB[Off-board Cloud/Service Endpoint]
  Key --> OB

2.3 System Requirements (SYSR)

3. Technical Security Concept

3.1 Technical Security Concept (TSC)

3.2 Technical Security Requirements (TSR)

4. Hardware Requirements and Hardware Static Architecture

4.1 Hardware elements

graph LR
  TX[SecOC TX Software Stack] --> SA2UL[SA2UL AES-128-CMAC Engine]
  RX[SecOC RX Software Stack] --> SA2UL
  SA2UL --> DMSC[DMSC/TIFS Key Handle Provisioning]
  TX --> FCTR[Freshness Counter Register/NvM]
  RX --> FCTR
  TX --> NETIF[CAN-FD/Ethernet DMA Peripheral]
  NETIF --> RX
  CONF[Confidentiality Software Stack] --> GCM[SA2UL AES-GCM Engine]
  GCM --> DMSC
  OB[Off-board TLS/mTLS Session] --> CERT[eFuse-Anchored X.509 Identity]

4.2 Hardware Requirements (HWR)

5. Software Requirements and Software Static & Dynamic Architecture

5.1 Software blocks

graph LR
  App[Sender Application] --> Pol[Communication Policy Engine]
  Pol --> Tx[SecOC TX Module]
  Pol --> ConfTx[TX Confidentiality Wrapper]
  Tx --> FVMTx[Freshness Value Manager Tx]
  Tx --> Csm[CSM/SA2UL Abstraction]
  Tx --> PduR[PduR]
  PduR --> Rx[SecOC RX Module]
  Rx --> FVMRx[Freshness Value Manager Rx]
  Rx --> Csm
  Rx --> AppR[Receiver Application]
  Rx --> Log[Secure Logging Connector]
  ConfTx --> ConfRx[RX Confidentiality Wrapper]
  ConfRx --> AppR
  ConfRx --> Log
  Key[Key/Session Manager Client] --> Csm
  Key --> ConfTx
  Key --> OBM[Off-board TLS/mTLS Session Manager]

5.2 Software Requirements (SWR)

5.3 SecOC-protected Authentic PDU authentication and freshness verification flow, plus confidentiality/off-board paths

SecOC-protected Authentic PDU authentication and freshness verification flow, plus confidentiality/off-board paths

Mermaid source (for editing/regeneration) 
sequenceDiagram
  participant App as Sender Application
  participant Tx as SecOC TX Module
  participant FM as Freshness Value Manager Tx
  participant Csm as CSM/SA2UL AES-128-CMAC
  participant Bus as CAN-FD/Ethernet
  participant Rx as SecOC RX Module
  participant FMR as Freshness Value Manager Rx
  participant AppR as Receiver Application
  participant L as Secure Logging
  participant Conf as Confidentiality Wrapper
  participant Gcm as SA2UL AES-GCM
  participant OB as Off-board TLS Session

  App->>Tx: Authentic PDU, Data ID D, payload
  Tx->>FM: Get current Tx Freshness Value for Data ID D
  FM-->>Tx: Freshness value, full and truncated wire form
  Tx->>Csm: Compute MAC over Data ID D, payload, freshness, using key handle
  Csm-->>Tx: Truncated MAC, configured length
  Tx->>Bus: Secured PDU, payload, truncated freshness, truncated MAC
  Bus->>Rx: Deliver frame
  Rx->>FMR: Reconstruct full freshness for Data ID D from truncated value and local window
  alt Freshness outside acceptable window
    Rx->>L: Drop, replay/freshness violation for Data ID D
  else Freshness in window
    Rx->>Csm: Recompute expected MAC using same key handle and Data ID D
    Csm-->>Rx: Expected MAC
    alt MAC mismatch
      Rx->>L: Drop, authentication failure for Data ID D
    else MAC match
      Rx->>AppR: Deliver payload, verified and fresh
    end
  end

  Note over Conf: Independent confidentiality-classified payload path
  App->>Conf: Sensitive payload for confidentiality-classified channel
  Conf->>Gcm: Encrypt payload with session key, AES-GCM
  Gcm-->>Conf: Ciphertext plus authentication tag
  Conf->>Bus: Confidentiality-protected frame
  Bus->>Conf: Deliver frame to receiver-side wrapper
  Conf->>Gcm: Decrypt and verify authentication tag
  alt Tag verification failure
    Conf->>L: Drop, confidentiality-channel authentication failure
  else Tag verification success
    Conf->>AppR: Deliver decrypted payload
  end

  Note over OB: Independent off-board path
  OB->>OB: TLS 1.2+/mTLS session using eFuse-anchored device X.509 identity
  OB->>L: Session establishment/failure logged separately from in-vehicle paths

5.4 Behavioral requirement focus

6. Hardware-Software Interface (HSI)

6.1 HSI elements

6.2 HSI Requirements (HSI)

Interview Appendix: Expert Q&A (20 Questions)

The following expert-level Q&A set is intended for interview practice and design review on this topic.

# Question Difficulty Detailed answer Evidence
1 Why is SecOC not just “encrypt the bus”? L1 SecOC is specifically about authenticity and freshness for in-vehicle communication, not just confidentiality. A message can be encrypted but still be replayed or modified if the bus allows a stale frame to be accepted. The design therefore verifies both the message identity and recency before the payload is trusted. SecOC requirements, AUTOSAR SecOC principle
2 What is the difference between authenticity and freshness in SecOC? L2 Authenticity answers the question “who sent this?” while freshness answers “is this current or is it a replay?” A message can be authentic but still stale; a message can also be fresh but untrusted if the MAC or signature is invalid. SecOC is designed to reject both categories before a payload reaches the application logic. CSG-SECOC-1, CSG-SECOC-2, FSR-SECOC-2
3 Why does SecOC use a truncated freshness value on the wire? L2 The wire format needs a compact freshness indicator, but the ECU still needs the full semantic value to check its validity relative to a counter or synchronization window. Truncation reduces bandwidth while allowing the receiver to reconstruct the full state and validate the newest acceptable value. This is a tradeoff between efficiency and anti-replay strength. SecOC freshness design
4 What is the practical impact of a replayed valid SecOC frame? L2 A repeated frame can cause the receiving module to act on stale data, such as an old command or outdated sensor value. That is problematic because replay may not be immediately visible to the application and may cause a wrong state transition. Freshness checks are designed to explicitly reject these old frames before the receiver acts on them. CSG-SECOC-2, freshness requirement
5 Why is the MAC check done after freshness validation in the receiver flow? L2 Freshness is an early guard against replay attacks. If a frame is stale, the system should drop it before spending a MAC-verify computation or application processing cycle. This is a practical design choice that reduces attack surface and keeps the receiver fail-closed when the frame is not current. FSR-SECOC-2, SecOC behavioral focus
6 Why is per-PDU authentication useful in a mixed-criticality automotive bus? L3 Not all PDUs need the same security treatment. Safety-critical and high-value messages deserve strong authenticity and freshness checks, while lower-risk traffic may be handled more efficiently. Per-PDU policy allows the system to apply security where the risk is greatest rather than adopting a single global policy for everything on the bus. SecOC policy design
7 What is the purpose of the Key/Session Manager in the SecOC design? L1 The Key/Session Manager centralizes the handling of security material such as MAC and confidentiality keys and keeps them behind a controlled interface. That reduces direct key exposure in software and ensures the SecOC stack works with handles rather than raw secret values. CSG-SECOC-5, TSR-SECOC-5, SWR-SECOC-3
8 Why can a compromise of raw key material in software be more dangerous than a compromise of a key handle? L3 A raw key in application memory is easier to read, leak, or misuse, because it is now part of the ordinary execution environment. A key handle narrows the secret to a protected layer and makes the software responsible for the key reference rather than the actual secret. This is a major design principle for secure communication stacks. HSI-SECOC-1, HSI-SECOC-4
9 What role does SA2UL play in SecOC? L1 SA2UL provides the hardware acceleration for the cryptographic operations used by SecOC, such as CMAC and AES-GCM calculations. This reduces the risk that sensitive key material is exposed to general-purpose software and keeps verification in a more constrained execution domain. SA2UL, HSI-SECOC-1, HSI-SECOC-4
10 How does confidentiality differ from authenticity in the SecOC picture? L2 Confidentiality protects the content of sensitive messages from unauthorized disclosure, while authenticity protects the receiver from being tricked by a forged or tampered message. The repo separates these concepts so they can be applied where needed rather than assuming all traffic requires the same treatment. This allows a more tailored and performance-aware design. SecOC requirements, confidentiality wrapper
11 Why is AES-GCM used for sensitive payload confidentiality? L2 AES-GCM provides confidentiality and authentication at the same time, which is ideal for a protected payload path. It allows the receiver to both decrypt the message and verify that it has not been modified. This reduces the number of separate cryptographic operations for sensitive payloads and keeps the design efficient while maintaining security. SecOC confidentiality wrapper, AES-GCM design
12 What is the risk if the Key/Session Manager allows both old and new keys to remain valid too long? L3 That creates a migration window in which an attacker can exploit a stale or old key path to send valid-looking traffic. The design therefore requires a coordinated key rotation model with explicit transition rules. This is important because replay and impersonation attacks often exploit mixed key states. CSG-SECOC-8, FSR-SECOC-7
13 Why should the receiver reject a PDU before it reaches the application buffer? L2 The application buffer is a higher-level interface where trust assumptions are often stronger and user-facing services may process the payload without realizing it was not authenticated. By failing closed at the interface, the system keeps unverified data out of the application domain. This is a key design principle in security engineering. HSI-SECOC-3, fail-closed policy
14 What is the security advantage of a separate off-board TLS/mTLS path? L2 Off-board communication follows a different trust model than in-vehicle bus traffic. Vehicle-to-cloud or backend communication may require certificate-based identity and session protection that is independent from internal SecOC. Separating the paths helps prevent one transport model from being mistaken for the other and keeps trust boundaries explicit. CSG-SECOC-6, TSR-SECOC-7
15 Why does the repo treat the off-board path as distinct from the in-vehicle path? L3 The trust anchors, interfaces, and risk models are different. In-vehicle communication uses SecOC-style authenticity and freshness; off-board communication uses TLS or mTLS with a device identity anchored to hardware identity. Mixing them would hide the real trust boundary and create confusion about where the root-of-trust is established. off-board TLS path, eFuse identity requirement
16 What is the main security reason for a per-Data-ID freshness value? L2 Different PDUs can have different replay risks and different time semantics. A single global freshness value could be too coarse or too operationally restrictive, while a per-Data-ID freshness model allows each signal or message class to be tracked appropriately. That makes the anti-replay policy more precise and less prone to false positives or false negatives. SecOC freshness design, HSI-SECOC-2
17 Why is failure logging important for SecOC events? L1 Logs provide evidence that a message was rejected because of freshness, MAC mismatch, or confidentiality tag failure. Without logs, a failed verification event may be invisible to the site engineer or security team, making it harder to diagnose a replay or tampering attempt. secure logging integration, fail-closed logging
18 How would a malicious actor try to bypass SecOC in practice? L3 They would try to replay an old valid frame, forge a valid-looking MAC with a stale key, or exploit a mixed-key rotation window. They could also attack the confidentiality path by tampering with the AEAD tag or modifying the freshness value while leaving the payload intact. The design works to block these by verifying freshness, MAC, and confidentiality tags before delivering the data. SecOC attack paths, key rotation, anti-replay design
19 What is the central idea behind the policy engine in the SecOC design? L2 The policy engine determines which messages are routed to which security path based on their nature and sensitivity. That reduces accidental misclassification and keeps high-value traffic under stricter protection. The routing logic is part of the security design because it ensures the correct control is applied to the correct message class. SecOC communication policy engine
20 If you had to summarize the whole SecOC design in one sentence, what would it be? L1 SecOC is a fail-closed, per-PDU authenticity and freshness model backed by hardware-assisted cryptography, explicit key handling, and separate confidentiality paths that reject replayed or tampered traffic before it can reach application logic. SecOC requirements, HSI-SECOC-1 to HSI-SECOC-5