SecOC in AUTOSAR Classic: Message Authentication at Bus Level

Why Secure Onboard Communication exists

The CAN protocol predates automotive cybersecurity by two decades. Its frame format authenticates nothing — any node electrically attached to the bus can transmit any arbitration ID, and every other node accepts the message as legitimate. That design choice was reasonable when ECUs lived in a sealed vehicle without remote interfaces; it became indefensible the moment infotainment heads, telematics units, and OTA gateways shared the same physical and logical buses as powertrain and chassis controllers.

The 2015 Jeep Cherokee disclosure remains the canonical illustration. Researchers pivoted from a remote interface to the internal CAN network, then sent spoofed arbitration IDs that legitimate ECUs accepted as commands. The protocol behaved exactly as designed; the architecture had no authenticity property to violate. AUTOSAR Secure Onboard Communication, introduced in Classic Platform 4.2, is the standardised counter to that class of attack: every cybersecurity-critical PDU carries a Message Authentication Code over its payload and a monotonic freshness value, and receivers reject anything that does not verify.

Architecture: where SecOC sits in the stack

Secure Onboard Communication is a Basic Software module that wraps the PDU Router and intercepts traffic on either side of the communication path. On the transmit side, the SecOC authenticator reads a freshness value, requests a MAC from the Crypto Service Manager, and assembles a Secured I-PDU consisting of the original payload plus a freshness fragment and a MAC. On the receive side, the verifier extracts the MAC and freshness fragment, reconstructs the full freshness from local state, recomputes the MAC, and compares. PDUs that fail verification are dropped before the Receiver Software Component ever sees them.

The module configuration ties three identifiers together: an authentic PDU (the original signal payload), a secured PDU (what actually traverses the bus), and a cryptographic PDU (a compact transport for sync messages and keys). The mapping from authentic to secured to cryptographic is set at configuration time and immutable at runtime.

Freshness management: where most projects stumble

Freshness is the property that makes SecOC resistant to replay. Each PDU carries a freshness value — a monotonically increasing counter, derived from a counter, or anchored to a synchronised time base — and the MAC binds payload and freshness together. Replaying a previously valid frame fails verification because the receiver's freshness pointer has moved past the captured value.

AUTOSAR provides a Freshness Manager that supplies counters to the SecOC module on demand. Profile choices range from SecOCFreshnessValueLength of 64 bits down to small vendor-specific sizes; the longer the counter, the longer the time to wraparound and the smaller the truncation relative to the full value. Sender and receiver must agree on the upper bits of the counter even though only the lower bits travel on the wire — this is the synchronisation problem.

Three patterns avoid the failure mode that reaches production most often: periodic broadcast of an authenticated freshness sync message; a sync request the receiver issues when it sees repeated MAC failures; and an idle-cycle write of the current upper-FV bits to non-volatile storage so that power-cycle drift is bounded. The default AUTOSAR integration provides hooks for all three, but the configuration values matter — a 4-frame tolerance window may be fine on a 100 ms cycle and indefensible on a 1 ms cycle.

MAC algorithms and truncation tradeoffs

Two MAC primitives dominate Secure Onboard Communication deployments: CMAC-AES128 per NIST SP 800-38B, and HMAC-SHA256 per FIPS 198-1. CMAC is the more common choice for two reasons: it reuses the AES engine that the Hardware Security Module already provides for SecOC and other crypto, and its throughput on dedicated AES hardware comfortably meets control-loop budgets. HMAC-SHA256 is more common where SHA-2 is already a hot path for signature verification or where the higher security margin of a 256-bit MAC is desired on Ethernet links with no truncation pressure.

Truncation is where engineering judgement bites. The truncated MAC is the lower bound on attacker work: with N MAC bits, a forgery attempt succeeds with probability 1 / 2^N. A 16-bit MAC gives 1 in 65,536 per attempt, which an unfiltered attacker on the bus can exhaust in seconds; a 24-bit MAC raises that to 1 in 16,777,216; a 28-bit MAC to 1 in 268,435,456; a 32-bit MAC to 1 in 4,294,967,296. Bus monitoring that rate-limits or alarms on repeated MAC failures pushes effective attacker cost up further.

MAC verification flow

The receive-side path is where the integration earns its keep. The numbered sequence below traces a single inbound frame from wire to Software Component:

Key management for Secure Onboard Communication

SecOC operates against a shared symmetric key per communication relationship. In production, that key never touches application memory: it is provisioned into the Hardware Security Module at end of line, exposed to SecOC only through a key-slot identifier, and exercised through the AUTOSAR Crypto Stack. Per-ECU diversification is implemented through key derivation functions (HKDF, KDF in counter mode) anchored to a long-term root key plus an ECU-specific salt; the derived key for a given session lives in volatile HSM storage and disappears on power down.

Key rotation is the procurement question that exposes weak CSMS submissions. R155 assessors will ask how a SecOC key is rotated after a known compromise. Defensible answers involve a Key Manager-driven flow: KeyM revokes the affected key element, requests a fresh derivation from backend PKI through an authenticated channel, and updates the SecOC key slot atomically. Designs that rely on flashing every ECU to rotate a SecOC key fail this question because they do not survive a fleet-wide event.

Secure Onboard Communication across bus types

The default 4-bit-FV / 28-bit-MAC profile makes sense only on Classical CAN. On other buses the tradeoffs invert:

• Classical CAN (8-byte payload). Truncation pressure is severe. Default profile is the pragmatic compromise; safety-critical PDUs should be lifted to CAN-FD where possible.
• CAN-FD (up to 64-byte payload). Comfortable room for a 64-bit MAC plus a 32-bit freshness fragment. This is the default sweet spot for new designs.
• Automotive Ethernet (100/1000BASE-T1). No truncation pressure at all; full 128-bit MAC and full 64-bit freshness counter are routine. SecOC may be paired with TLS or IPsec for confidentiality.
• LIN. Typically out of SecOC scope. LIN is segmented behind a domain gateway that enforces authenticity at its CAN or Ethernet egress.
• FlexRay. SecOC is supported but rare in new designs as FlexRay itself is sunsetting in favour of CAN-FD and Ethernet.

Performance and integration with the Crypto Stack

The CMAC-AES128 round trip from SecOC verifier through Csm and CryIf to a hardware AES engine and back is typically dominated by the asynchronous job latency, not the AES core. On a typical Cortex-R52 platform with a dedicated AES engine and a 4-byte authentic payload, full round-trip verification routinely fits inside 1 ms; on processors without hardware AES, software CMAC may push that into the 5–10 ms range, which is incompatible with most chassis control loops.

The integration point is the Crypto Service Manager. The SecOC module submits MAC and verify jobs; the Crypto Interface routes them through the configured Crypto Driver Object to either the Hardware Security Module or the software fallback. For a layered walkthrough of how Csm, CryIf, the Crypto Driver, and KeyM cooperate, see the companion guide to the AUTOSAR Crypto Stack.

Implementation pitfalls and mitigations

SecOC in ISO/SAE 21434 and UNECE R155 context

At the Work Product level, Secure Onboard Communication produces direct evidence for ISO/SAE 21434 WP-10-01 (cybersecurity specification) and WP-10-04 (integration and verification report). The MAC matrix, freshness configuration, key-slot allocation, and verification counters are all auditable artefacts. UNECE R155 Annex 5 maps SecOC mitigations to the back-end and communication channel threat categories — specifically the message-injection and replay sub-entries that any defensible TARA must address. The relationship between ISO/SAE 21434 and UNECE R155 is laid out in the companion comparison post on ISO/SAE 21434 vs UNECE R155.

SecOC is necessary, not sufficient. A vehicle with perfectly implemented SecOC on every bus is still vulnerable to a remote pivot through a head unit that legitimately sits inside the SecOC trust boundary, which is precisely how the 2015 Jeep attack played out. Bus authentication closes the bus-level injection vector; it does not substitute for secure boot on every ECU, defence in depth at gateways, or the Hardware Security Module-anchored key hierarchy that backs both.

Take-aways for an architect-grade SecOC programme

SecOC is a mature, standardised control with a well-trodden integration path. The bugs that delay programmes are not in the protocol; they are in freshness handling at startup, in the key lifecycle that spans factory through fleet, and in the SecOC matrix that translates a TARA into per-PDU scope. Get those three right and SecOC becomes an asset on the cybersecurity case. Get them wrong and the resulting evidence will not survive R155 assessment, no matter how much MAC computation the ECU performs.

Agnile Technologies provides AUTOSAR Cybersecurity Engineering for global OEMs and Tier-1 suppliers. Engage us early on the SecOC matrix — before the communication database is frozen — and we will help you get the freshness, MAC sizing, and key lifecycle right the first time.