SecOC (Secure Onboard Communication)
SecOC is the AUTOSAR mechanism that authenticates in-vehicle messages with a MAC and a freshness value. How it works on CAN and what a bus test can check.
Updated This page as Markdown
In short
SecOC (Secure Onboard Communication) is the AUTOSAR module that protects selected in-vehicle messages against spoofing and replay. It appends a message authentication code (MAC) and a freshness value to a protected message, so a receiver can check that the sender held the shared key and that the message is not a replay. It does not encrypt the payload. On CAN the small frame limits how many MAC and freshness bytes fit, which shapes most real designs.
What is SecOC?
SecOC is an AUTOSAR module that sits between the application and the communication stack and adds authentication to the messages a project marks as protected. For such a message it computes a MAC over the message and a freshness value with a shared symmetric key, then transmits the message together with (part of) the freshness value and a (usually truncated) MAC. The receiver recomputes the MAC, compares it and checks the freshness, and drops the message if either fails.
On CAN a protected signal typically looks like payload bytes, a few freshness bits and a truncated MAC packed into the same 8-byte frame, or into a companion frame when there is no room. CAN FD, with up to 64 bytes, makes a full-length MAC practical.
Where is it defined?
AUTOSAR specifies SecOC in the Classic Platform (Specification of Secure Onboard Communication) and in the Adaptive Platform. The cryptography underneath comes through the Crypto Service Manager and is usually backed by an HSM or SHE. SecOC addresses several threats that UN R155 Annex 5 lists for in-vehicle communication, in particular spoofing and replay of messages.
What it means in practice
SecOC changes the bus from one where any node can send any identifier to one where protected messages carry proof of origin. That matters for safety-relevant signals that used to be trivially spoofable. The trade-offs are the freshness management (counters that must not drift, resynchronisation after reset), the truncation length and which messages are protected at all, because protecting every message is rarely affordable.
On the bench the observable questions are whether a receiver actually rejects a protected message with a wrong or missing MAC, whether an old captured message is replayed successfully, and whether an unprotected copy of a safety signal still exists. Attacking the key or the MAC algorithm itself is cryptographic and firmware work.
How AutoST tests it
AutoST works at the bus and diagnostic level. During CAN and CAN FD testing it records which identifiers carry protected messages and can send frames with altered or absent authentication bytes to observe whether the receiving ECU rejects them. It does not recover keys, break the MAC algorithm or verify the freshness scheme cryptographically; that is penetration-test and firmware work.
Common misunderstandings
SecOC is authentication, not encryption, so a protected signal is still readable. A short MAC is a bandwidth choice, not a flaw by itself, but it narrows the security margin. And SecOC only protects the messages a project chose to protect; an unprotected duplicate undoes the point.
FAQ
Frequently asked questions
Does SecOC encrypt messages?
No. SecOC authenticates, it does not keep data confidential. It adds a MAC and freshness so a receiver can verify origin and reject replays, but the payload stays readable on the bus. Confidentiality needs a separate mechanism such as TLS on Ethernet links.
What is the freshness value for?
It stops replay attacks. Without freshness, an attacker could record an authenticated message and send it again later, and the MAC would still verify. The freshness value, usually a counter or a time-based value, makes each authenticated message unique, and both sides must keep it in sync.
Why are the MAC and freshness often truncated on CAN?
A classic CAN frame holds only 8 bytes, most of which the payload needs. Designs therefore send only the lower bits of the freshness value and a truncated MAC, often 24 or 28 bits. That is a deliberate trade-off, and how many bits are used is a design parameter worth checking.
Sources
Related pages
- GlossaryCAN Bus (Controller Area Network)CAN (ISO 11898) is the broadcast bus most ECUs share: identifiers, arbitration, error handling. Why any node can send any frame and what that means for security testing.
- GlossaryHSM (Hardware Security Module)An automotive HSM is a protected core inside a microcontroller that stores keys and runs crypto for SecOC, secure boot and diagnostics. What a bench test can see.
- GlossarySecure BootSecure boot verifies an ECU firmware image before it runs, so unsigned or modified software does not start. How it works, the HSM role and what a bench test can observe.
- InsightsSecOC testing from the bus side: what a tester can checkHow to test AUTOSAR SecOC without the keys: freshness and MAC on the wire, replay and reorder behaviour, truncated MAC length, and what each result means.
- PlatformSpeaks the buses your ECUs speak.AutoST supports CAN, CAN FD, ISO-TP, UDS, XCP, CCP, DoIP and SOME/IP, with SocketCAN, Vector XL and comma.ai Panda adapters on Windows and Linux.
