SecOC - Secure Onboard Communication - Automotive Cybersecurity

SecOC AUTOSAR Architecture

SecOC PDU Processing Chain

  Sender side:
  COM (signal values)
    │ trigger: MainFunction or event
    ▼
  SecOC Tx Processing
    ├── Get Freshness Value (FV) from FreshnessManager or NVM counter
    ├── Compute MAC = AES-128-CMAC(key, FV || authentic_PDU_data)
    ├── Truncate MAC to SecOCAuthInfoTruncLength bits (24–64 bits)
    └── Build Secured I-PDU = Authentic_PDU || FV_truncated || MAC_truncated
    ▼
  PduR → CanIf → CAN bus

  Receiver side:
  CAN bus → CanIf → PduR
    ▼
  SecOC Rx Processing
    ├── Extract FV_truncated from Secured I-PDU
    ├── Reconstruct full FV via FreshnessManagement callout
    ├── Verify: computed_MAC == received_MAC? And FV within acceptance window?
    ├── PASS → forward authentic PDU to COM
    └── FAIL → log DEM event; drop PDU; notify via VerificationStatusCallout

SecOC Parameter	Typical Value	Effect
SecOCAuthInfoTruncLength	48 bits (6 bytes)	Collision resistance: 2^48 brute force ≈ 281 trillion guesses
SecOCFreshnessValueLength	64 bits	Full counter length in NVM; prevents counter wrap attacks
SecOCFreshnessValueTruncLength	16 bits	Bits transmitted in PDU; rest reconstructed by receiver from local NVM
SecOCAcceptanceWindow	10 messages	Tolerate up to 10 missed frames before declaring FV sync loss
SecOCReceptionOverflowStrategy	DROP_NEWEST	Under PDU buffer overflow: drop newest to prevent queue attack

MAC Algorithm, Truncation, and Security Margin

Truncated MAC Length	Brute Force Space	Attack Time at 1000 frames/s	Recommendation
24-bit	~16.7 million	~4.7 hours	Insufficient for safety-critical; minimum for body CAN (low-speed, low-risk)
32-bit	~4.3 billion	~50 days	Acceptable for ASIL B, low-impact messages
48-bit	~281 trillion	~9,000 years	Recommended for powertrain and chassis safety-critical PDUs
64-bit	~18.4 quintillion	~585 billion years	Maximum protection; use for ASIL D or when CAN-FD payload allows

⚠️ 24-bit MAC is Insufficient for Safety-Critical CAN Messages

The 2^24 brute force space for a 24-bit truncated CMAC can be exhausted in under 5 hours by an attacker with CAN bus access sending 1000 frames/second. For any PDU with ASIL B or higher impact (steering, braking, powertrain), configure SecOCAuthInfoTruncLength to at least 48 bits. The 6 additional bytes fit comfortably in a CAN-FD frame; if using CAN 2.0 with 8-byte DLC, consider dedicating a separate authentication frame with longer MAC.

Key Provisioning and Management

Csecoc_key_provisioning.c

/* SecOC symmetric key provisioning via SHE (Secure Hardware Extension) */
/* Production EOL: KMS generates M1-M5 for each ECU; provisioning station loads key */

#include "SheDriver.h"
#include "SecOC.h"

/* Key hierarchy: Master Secret → KDF → per-ECU, per-bus, per-direction key */
/* VMS = HKDF(RootKey, VIN)
   ESK_CAN0_TX = HKDF(VMS, ECU_ID || "CAN0" || "TX")  */

Std_ReturnType SecOC_ProvisionKey(const uint8* m1, const uint8* m2,
                                   const uint8* m3, uint8* m4_out, uint8* m5_out)
{
    SHE_StatusType status;

    /* SHE CMD_LOAD_KEY: load AES-128 key into KEY_1 slot using M1-M5 protocol */
    /* M1: ECU_ID + KEY_ID + count (prevents replay of old key) */
    /* M2: encrypted key + flags (AES-128-CBC with MASTER_ECU_KEY) */
    /* M3: authentication (AES-128-CMAC over M1+M2) */
    status = SHE_LoadKey(SHE_KEY_SLOT_1, m1, m2, m3, m4_out, m5_out);

    /* M4+M5 returned by SHE serve as provisioning proof */
    /* Archive M4+M5 in KMS for audit: proves correct key was loaded in this ECU */

    if (status != SHE_STATUS_OK) {
        /* Provisioning failure: ECU cannot authenticate CAN messages */
        /* Log DEM error; ECU enters fail-safe without SecOC */
        Dem_ReportErrorStatus(DEM_EVENT_SECOC_KEY_PROV_FAIL, DEM_EVENT_STATUS_FAILED);
    }

    return (status == SHE_STATUS_OK) ? E_OK : E_NOT_OK;
}

/* Key rotation: new key delivered via UDS WriteDataByIdentifier 0x2E */
/* New key encrypted with current ESK; activated on next ignition cycle */
/* Version counter checked: new_count >= current_count (anti-rollback) */

Gateway SecOC Handling and CAN-FD Adaptation

Scenario	Requirement	Implementation
Cross-bus routing (CAN0 → CAN1)	Strip incoming MAC, verify with source key, re-sign with destination key	Gateway ECU hosts SecOC instance for each bus segment; separate key per bus
CAN 2.0 → CAN-FD upgrade	CAN-FD 64-byte payload allows 64-bit MAC instead of 48-bit	Increase SecOCAuthInfoTruncLength to 64 in CAN-FD SecOC config
CAN-FD → CAN 2.0 downgrade (legacy ECU)	Legacy ECU cannot process MAC → need legacy coexistence mode	PDU Gateway (byte copy) for non-SecOC segments; treat as untrusted; add cross-check
Gateway latency budget	Re-MAC adds one AES-128-CMAC operation ≈ 1–5 µs on HSM	Within 10 ms typical gateway latency budget for ASIL B

Summary

SecOC provides PDU-level authentication for CAN messages using a truncated CMAC appended to each frame. The freshness value prevents replay attacks; the truncated MAC provides collision resistance proportional to its length — use 48 bits minimum for safety-critical PDUs. Gateway ECUs must re-authenticate frames when routing between bus segments, using separate keys per bus. Key provisioning via SHE M1-M5 at EOL production creates an auditable key-loading proof (M4/M5) archived in the KMS.

🔬 SecOC Verification Chain — How Message Authentication Works

SecOC (Secure Onboard Communication) adds a Message Authentication Code (MAC) to PDUs without changing the COM signal model. Understanding the exact verification chain prevents integration failures:

Transmitter side: (1) COM provides the Data PDU (the actual signal content). (2) SecOC retrieves the current Freshness Value from the Freshness Value Manager (FVM). (3) SecOC calls the CSM (Crypto Service Manager) with the concatenated [Key ID | Freshness Value | Data PDU] → MAC is generated (typically CMAC-AES-128 truncated to 24–48 bits). (4) SecOC assembles the Secured PDU = [Data PDU | Freshness Value (partial/full) | MAC] and passes it to PduR/COM for transmission.
Receiver side: (1) SecOC receives Secured PDU from PduR. (2) It reconstructs the full Freshness Value (combining the received partial freshness with the local trip counter). (3) Calls CSM to compute expected MAC. (4) Compares expected MAC with received MAC. If match → PDU accepted, Freshness Value updated. If mismatch → PDU rejected, DEM event incremented, last valid data retained or invalidated based on config.
Freshness Value strategy: Replay protection requires that the Freshness Value increases monotonically and cannot be reused. Two strategies: (a) Trip counter (increments per ignition cycle) + message counter (increments per message): simple but requires NvM persistence across power-off. (b) Pure message counter: simpler but requires a very large counter and careful overflow handling.
Key distribution: The symmetric MAC key (shared between Tx ECU and Rx ECU) must be provisioned in the HSM (Hardware Security Module) at EOL production. Key injection uses Authenticated Key Exchange protocols (e.g., SHE key update protocol or EVITA HSM commands). The key never appears in cleartext in software.

🏭 SecOC in Production CAN Networks

Safety-critical signals: BMW and Mercedes require SecOC on all safety-critical CAN signals (e.g., EPB apply/release, ABS/ESC wheel speed, engine torque limiter). This is now a mandatory OEM network requirement for new platforms.
Performance impact: CMAC-AES-128 on an HS6003 HSM runs at ~50 µs per MAC generation. If 10 signals are SecOC-protected on a 1 ms task, the HSM load is 500 µs/ms — 50% utilisation of the crypto hardware. Projects often use truncated MACs (24 bits) and batched CSM requests to reduce HSM load.
EOL synchronisation: At EOL, all ECUs' Freshness Value trip counters start at 0. The first ignition cycle synchronises them. A mismatch in the initial freshness value (e.g., an ECU flashed with a non-zero initial counter) causes all SecOC messages to fail immediately. This is a common NvM initialisation error on production lines.

⚠️ SecOC Integration Pitfalls

Freshness Value not persisted in NvM: If the Freshness Value counter is reset to 0 on every power cycle, an attacker can replay captured messages from a previous ignition cycle — completely defeating SecOC protection. Trip counter value must be written to NvM before power-off.
Same key used for all ECUs: If one ECU is compromised and its HSM key is extracted, an attacker can forge messages for all other ECUs using the same key. Best practice: unique pairwise keys per ECU-to-ECU communication relationship.
MAC truncation too short: A 16-bit MAC has only 65,536 possible values — an attacker can brute-force guess it in expected 32,768 attempts. AUTOSAR recommends minimum 24-bit MAC for safety-critical signals.
SecOC verification failure not connected to DEM: If a MAC verification failure does not trigger a DEM event, security attacks go undetected in the field. Every SecOC verification failure must increment a DEM counter that can be read during service.

📊 Industry Note

UNECE R155 Annex 5 explicitly lists 'replay attacks via spoofed in-vehicle communication' as a cybersecurity threat that OEMs must mitigate. SecOC is the AUTOSAR-standardised countermeasure. Its correct implementation and verification is an auditable requirement for EU type approval of new vehicles since July 2024.

🧠 Knowledge Check — Click each question to reveal the answer

❓ Why is a Freshness Value required in SecOC in addition to the MAC? What attack does it prevent?

✅ The MAC alone prevents forgery (an attacker cannot generate a valid MAC without the key), but it does not prevent replay attacks. Without a Freshness Value, an attacker could record a valid 'unlock door' or 'apply brakes' SecOC message and replay it later. The Freshness Value is a monotonically increasing counter included in the MAC computation. Since the Freshness Value changes every message, a replayed message from a previous session will have an outdated Freshness Value — the receiver will compute a different MAC and reject the message.

❓ A SecOC-protected ECU is exchanged for a new ECU after repair. What NvM-related problem could occur, and how is it handled?

✅ The new ECU starts with its Freshness Value counter at the NvM default (typically 0 or some provisioning value). The other ECUs on the network have counters much higher than 0 from operational use. The new ECU's messages will be rejected by receivers that have already seen higher freshness values. Solution: At EOL after ECU replacement, a diagnostic routine (UDS 0x31) performs 'SecOC Freshness Synchronisation' — the new ECU's trip counter is set to the current network value via a secure diagnostic channel before re-enabling SecOC protection.

❓ What is the role of the CSM (Crypto Service Manager) in the SecOC workflow?

✅ CSM is the AUTOSAR abstraction layer between SecOC and the actual cryptographic hardware (HSM) or software crypto library. SecOC calls CSM_MacGenerate() with the key handle, input data, and output buffer. CSM routes the request to the correct CRYIF (Crypto Interface) job, which executes on either the HSM hardware accelerator or a software implementation (e.g., AES-CMAC in software). This abstraction allows the MAC algorithm or HSM vendor to be changed without modifying SecOC module code.