Secure Onboard Communication is the AUTOSAR basic-software mechanism that protects in-vehicle communication against spoofing, tampering, and replay. It works per protected PDU: the sender computes a Message Authentication Code — typically AES-CMAC — over the data identifier, the payload, and a freshness value (a monotonic counter or synchronised timestamp), then appends a truncated freshness value and truncated MAC to the frame; the receiver reconstructs the full freshness value, recomputes the MAC, and discards the frame if authentication or freshness verification fails. Truncation is what makes SecOC practical on classic CAN, where an 8-byte frame leaves few spare bytes; CAN FD and automotive Ethernet leave room for longer authenticators. Key material is provisioned per vehicle or per ECU group and normally lives in a Hardware Security Module, with the AUTOSAR Crypto Stack (CSM, CryIf, and the crypto driver) executing the MAC operations. The hard engineering problems are freshness management — keeping counters synchronised across resets and lost frames without opening a replay window — and budgeting the bus load and latency the added bytes cost on safety-relevant signals. Which PDUs to protect is a TARA outcome: signals whose spoofing leads to safety-relevant damage scenarios are protected first. SecOC is specified by the AUTOSAR consortium for both Classic and Adaptive platforms, implements the message-authenticity mitigations UNECE R155 Annex 5 expects for in-vehicle network threats, and is verified in practice during system integration testing, where MAC failure handling, freshness resynchronisation, and fault injection are exercised on the bench.
Why it matters
SecOC is the AUTOSAR-standard defence against spoofing and replay on in-vehicle networks, and assessors increasingly expect it on safety-relevant signals. Specifying SecOC, its freshness scheme, and HSM-backed keys during the cybersecurity concept — not after integration — is what keeps the resulting evidence coherent under review.