CAN Bus and AUTOSAR SecOC Guide: MACs, Freshness, Keys

A CAN frame carries an identifier and some data but no proof of which electronic control unit (ECU) sent it, so any device spliced into the wiring can send frames that brakes, locks and immobilisers will act on. AUTOSAR Secure Onboard Communication (SecOC) is the industry's main answer: it adds a truncated message authentication code (MAC) and a freshness value to selected messages so receivers can reject forgeries and replays. Getting the design right is hard, because classic CAN frames hold only 8 bytes, MACs are cut down to 24 bits, freshness has to stay synchronised across ECUs that reset and sleep, and keys must be unique per vehicle without making the workshop unworkable. This guide explains how CAN trust works, how SecOC protects a message, how to choose profiles, MAC and freshness lengths, how to manage the keys, what to monitor and where real designs fail. It is for vehicle and ECU security engineers, E/E architects and suppliers, and goes deeper than the Automotive Cybersecurity Guide, which covers the regulatory programme.

Key takeaways

CAN trusts everything on the wire. Arbitration and error handling give reliability, not authenticity; any node that can reach a bus segment can send any identifier.
SecOC authenticates, it does not encrypt. It appends a truncated MAC built over a data identifier, the payload and the full freshness value, so receivers can detect tampering, spoofing and replay. Payloads remain readable.
Freshness is the hard part. A counter or timestamp must be synchronised, sized so it never overflows within a key's lifetime, and recovered safely after resets, or ECUs will either reject good traffic or accept replays.
24-bit MACs are a deliberate trade-off. The AUTOSAR profiles truncate CMAC-AES-128 to 24 bits for bandwidth, while the same specification notes that 64 bits and above is generally considered sufficient against guessing; compensate with attempt limits, monitoring and key scope.
Key management decides the real security. AUTOSAR leaves key distribution to the implementer. Per-vehicle keys held in a hardware security module, provisioned at end of line and replaceable in service, are what stop one extracted key from opening a whole model line.

How CAN trust works and how it is attacked

Controller Area Network (CAN, ISO 11898) is a broadcast, multi-master bus. Every frame carries an 11-bit or 29-bit identifier that doubles as priority (the lowest identifier wins arbitration) and up to 8 data bytes in classic CAN, 64 in CAN FD and up to 2,048 in CAN XL. Every node sees every frame, and receivers decide what to act on purely by identifier. Error confinement counts transmit and receive errors and pushes a persistently faulty node into error passive and then bus-off.

Attack class	What it exploits	Defensive control
Frame injection and spoofing	No sender authentication; receivers trust identifiers	SecOC on safety and security relevant messages; gateway allow lists
Replay	Recorded valid frames remain valid	SecOC freshness value (counter or timestamp)
Bus-off and suppression	Error confinement can be abused to silence a legitimate ECU	Error pattern monitoring; ECU and gateway intrusion detection; physical access hardening
Physical access from outside the cabin	Harnesses reachable from headlights, bumpers and wheel arches	Bus topology design: keep immobiliser and body control buses away from exterior harnesses; authenticate key-related messages
Diagnostic abuse	OBD-II port and UDS services that unlock writes and reflashing	UDS Authentication (0x29) with certificates or per-ECU SecurityAccess (0x27) keys; gateway filtering of diagnostics while driving
Remote pivot	Compromised telematics or infotainment ECU sending on internal buses	Domain separation, gateway allow lists, SecOC so a pivot ECU cannot forge messages it does not own keys for

The point became concrete with the 2023 analysis by Ken Tindell of a Toyota RAV4 theft. Thieves reached the CAN bus through the headlight area, then sent forged messages imitating the smart key receiver, which led to the immobiliser being disabled and the doors unlocked. The gateway copied messages between buses without verifying their origin, and disruption of normal bus communication defeated error handling. The analysis describes the technique as an industry-wide issue and recommends cryptographic authentication of critical messages, a zero trust stance between ECUs, hardware security modules and unique keys per vehicle.

How SecOC protects a message

SecOC is specified in two AUTOSAR documents: the Foundation protocol specification (PRS SecOC, document 969, initial release R20-11) and the Classic Platform software specification (SWS SecOC, document 654, first released in AUTOSAR 4.2.1). This page reflects release R22-11 (published November 2022). The module sits between the PDU Router and the bus interfaces and calls the Crypto Service Manager (Csm_MacGenerate and Csm_MacVerify, or signature services for asymmetric schemes).

The Secured I-PDU

A Secured I-PDU is laid out as: optional Secured I-PDU header (length of the authentic part) | Authentic I-PDU | truncated freshness value (optional) | truncated Authenticator. The Authenticator is a MAC computed over the Data Identifier, the authentic payload and the complete freshness value, even when only a few least significant bits of the freshness value are transmitted. The MAC is truncated by keeping its most significant bits. All SecOC fields use big-endian byte order. In collection mode, the Authentic I-PDU and a separate Cryptographic I-PDU (authentication data plus a message linker) travel as two PDUs in the same cycle, which helps when the payload already fills the frame.

Verification

Parse the Authentic I-PDU, the truncated freshness value and the Authenticator.
Obtain the full freshness value from the Freshness Value Manager, which reconstructs the upper bits from its own state.
Build the data to authenticate (Data Identifier | payload | full freshness value).
Verify the MAC through the Crypto Service Manager using the configured truncation length.
Report the result to the Freshness Value Manager.
Pass the payload to upper layers only if verification succeeded.

Results are SECOC_VERIFICATIONSUCCESS, SECOC_VERIFICATIONFAILURE, SECOC_FRESHNESSFAILURE and SECOC_AUTHENTICATIONBUILDFAILURE. Build and verify attempt counters (SecOCAuthenticationBuildAttempts and SecOCAuthenticationVerifyAttempts) bound retries; when they are exhausted, the message is dropped. SecOC_VerifyStatusOverride lets an integrator force delivery regardless of the result, and the specification warns this can conflict with freshness management. Treat any use of it in production as a security exception with sign-off.

Choosing profiles, MAC length and freshness

AUTOSAR profile	Algorithm	Freshness value	Transmitted MAC	Use and caution
Profile 1 (24Bit-CMAC-8Bit-FV)	CMAC with AES-128	8 least significant bits transmitted	24 bits	Common baseline for classic CAN; needs reliable resynchronisation of the upper counter bits
Profile 2 (24Bit-CMAC-No-FV)	CMAC with AES-128	None	24 bits	Specification says use only when no synchronised freshness is established; gives no replay protection
Profile 3 (JASPAR)	CMAC with AES-128	64-bit counter, 4 bits transmitted, master and slave synchronisation	24 bits in the profile table	Intended for CAN; the R22-11 text and table disagree on MAC length, so confirm with the supplier
Custom profile	CMAC-AES-128 or signatures (no truncation allowed for signatures)	Per design	Per design, ideally 64 bits or more on CAN FD and Ethernet	Use where frame size allows; document the security argument in the TARA

MAC length: a 24-bit tag gives roughly a one in 16.7 million chance per forged frame. That is acceptable only if attempts are bounded and noticed: verification failures are counted, reported and acted on, and the key is unique enough that a successful guess has limited reach. On CAN FD, CAN XL and Ethernet, spend the extra bytes on longer tags.
Freshness source: per-message monotonic counters are simple but need storage and resynchronisation after resets; a trip counter plus message counter scheme (as in JASPAR-style designs) reduces state; timestamps need a trusted, synchronised time base. The specification also allows reusing part of the payload (for example an end-to-end protection counter) as freshness on CAN, which saves bytes but couples safety and security mechanisms.
Counter sizing: SecOCFreshnessValueLength must be large enough that the counter cannot overflow while the same key is in use. Compute it from message rate, vehicle lifetime and planned key changes.
Which messages: authenticate messages whose forgery changes vehicle behaviour or security state: immobiliser and key validation, door and lock commands, torque, braking and steering requests, gear and mode changes, and diagnostic session control. Cyclic status traffic with no actuation effect may not justify the bandwidth.
Bus load and latency: SecOC consumes payload bytes and CPU per frame. Model bus load and worst-case latency before choosing truncation lengths, and use hardware crypto acceleration in the ECU.

Key management for SecOC

The SecOC protocol specification explicitly does not define key management: it only states that keys are inputs, proposes a key length of at least 128 bits and links freshness counter size to key lifetime. Everything below is therefore the vehicle maker's design responsibility, and it is where most real-world weakness lies.

Key scheme	Benefit	Risk	When to use
Global key per model or platform	Simple to provision and replace parts	One extracted key forges messages on every vehicle of that type	Avoid
Per-vehicle key shared by a message group	Compromise limited to one vehicle; manageable key count	Any ECU in the group can impersonate any other	Common baseline
Per-vehicle, per-sender keys	A compromised receiver cannot forge another sender's messages	More keys and more provisioning logic	Safety and immobiliser functions
Asymmetric signatures	No shared secret at receivers	Larger tags (no truncation), more CPU	Ethernet and software update paths rather than classic CAN

Protected storage: hold SecOC keys in a hardware security module or a Secure Hardware Extension (SHE) compatible key store so they cannot be read out over debug or memory dumps. See the HSM Deployment and Operations Guide.
End-of-line provisioning: generate per-vehicle keys in a back-end key management service, inject them in the plant through an authenticated channel, and record which keys went into which vehicle identification number.
Service and replacement: a replacement ECU needs the vehicle's keys. Design an authenticated online provisioning process for workshops rather than a dealer tool holding master keys.
Rotation and revocation: plan how to change keys over the air if a key or ECU is compromised, and how freshness counters reset safely with a new key.
Back-end security: the key management system holding every vehicle's keys is the highest value target in the programme. Apply privileged access controls, dual control and audit. See the Cryptographic Key Management Guide.

Where identity fits

SecOC keys are, in effect, the machine identities of ECUs: whoever holds an ECU's key can speak as that ECU. Treat the per-vehicle key set as an identity inventory with an owner, issuance record, storage location, rotation plan and revocation path, exactly as an enterprise treats service account credentials. Diagnostic tools, end-of-line stations and over-the-air back ends that can inject or change keys are non-human identities with very high privilege and need their own authentication, least privilege and logging. See the Connected and Autonomous Vehicle Security Guide and the Uptane and Vehicle OTA Security Guide.

Implementing SecOC: a phased approach

Start from the TARA: list the damage scenarios that depend on message forgery (theft, unintended actuation, safety function disablement) and derive the message set and required strength. See the Automotive TARA Guide.
Design the architecture: place gateways and domain controllers so exterior-reachable harnesses do not share a bus with immobiliser, body and chassis control; define which ECUs send and receive each authenticated message.
Specify profiles per message: record MAC length, freshness scheme and attempt limits in the communication matrix, and justify any profile without freshness.
Build key management first: back-end key generation, end-of-line injection, workshop provisioning and over-the-air rotation must exist before vehicles are built, not after.
Integrate and test on the bench: verify bus load and latency, power-cycle and sleep and wake behaviour, freshness resynchronisation, ECU replacement and behaviour when verification fails (what does the receiver do, and is it safe?).
Penetration test: include replay, injection at exterior access points, bus-off attempts and key extraction attempts on production-intent hardware.
Roll out with a fallback plan: define degraded modes for persistent verification failure (for example warn and limit function rather than accept unauthenticated commands), and ensure that a diagnostic mode cannot silently disable verification in the field.

Detection and measurement

SecOC produces exactly the signals an in-vehicle intrusion detection system needs: AUTOSAR added security event reporting to the Intrusion Detection System Manager (IdsM) in R20-11, and verification status can be propagated to applications (modes BOTH, FAILURE_ONLY or NONE). Feed these to the vehicle security operations centre. See the Connected and Autonomous Vehicle Security Guide for fleet monitoring.

Verification failures per message identifier and per vehicle, distinguishing MAC failures from freshness failures.
Freshness resynchronisation events and their frequency after power cycles.
Bus error bursts and bus-off events on buses carrying authenticated messages, which may precede injection.
Unexpected identifiers or message rates on a bus segment, and diagnostic sessions opened while the vehicle is moving.

Metrics

Percentage of TARA-identified safety and security relevant messages protected by SecOC with freshness.
Share of vehicles with per-vehicle (not global) keys, target 100% for new platforms.
Verification failure rate per million messages in the field, with a baseline and alert threshold.
Mean time to provision keys to a replacement ECU in service without exposing master keys.
Number of production builds with SecOC verification overridden or bypassed, target zero.

Framework mapping

Control	Automotive standard	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE D3FEND
Message authentication on buses	AUTOSAR SecOC; ISO/SAE 21434 cybersecurity requirements from TARA	SC-8 Transmission Confidentiality and Integrity; SC-23 Session Authenticity	PR.DS-02	D3-BMA Bus Message Authentication; D3-MAN Message Authentication
Key generation, storage and rotation	ISO/SAE 21434 cybersecurity controls; UN R155 CSMS processes	SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection	PR.AA-01	None mapped
ECU and tool authentication	UDS Authentication service (ISO 14229-1)	IA-3 Device Identification and Authentication	PR.AA-01	None mapped
Gateway filtering and domain separation	E/E architecture requirements	SC-7 Boundary Protection	PR.IR-01	D3-NI Network Isolation
In-vehicle intrusion detection	AUTOSAR IdsM	SI-4 System Monitoring	DE.CM-01	D3-NTA Network Traffic Analysis

Common failure patterns

Authenticating the wrong messages: protecting torque and braking but leaving smart key validation and lock commands unauthenticated, which is exactly the path car thieves have used.
Profile 2 in production: using the no-freshness profile because counter synchronisation was difficult, leaving every authenticated message open to replay.
Shared keys across a fleet: one key per model so service is easy. A single extraction from a scrapped ECU then forges messages on every vehicle of that type.
Verification that fails open: receivers that log a SecOC failure but still act on the payload, or a VerifyStatusOverride left enabled from development.
Gateways that bridge everything: a gateway forwarding frames between an exterior-reachable bus and the immobiliser domain without filtering, so physical access anywhere becomes access everywhere.
Freshness that breaks after resets: counters stored only in RAM, or resynchronisation that accepts any value the sender proposes, which turns a reset into a replay window.

Practitioner checklist

Derive the list of SecOC-protected messages from the TARA, including immobiliser, key validation and lock messages.
Use a profile with freshness for every protected message; document any exception with a risk acceptance.
Choose MAC lengths per bus type, using longer tags on CAN FD, CAN XL and Ethernet, and bound verification attempts.
Size freshness counters for the full key lifetime and test resynchronisation across power cycles and ECU replacement.
Store keys in an HSM or SHE key store with per-vehicle keys, ideally per sender for safety and security functions.
Build and secure end-of-line, workshop and over-the-air key provisioning before start of production.
Ensure receivers fail safe, never act on unverified payloads, and that no production build overrides verification.
Filter traffic at gateways between exterior-reachable buses and critical domains.
Report SecOC verification and freshness failures to IdsM and the vehicle SOC, with alert thresholds.

CAN Bus and AUTOSAR SecOC Guide: Authenticating In-Vehicle Messages, Freshness and Keys