SecOC: Secure Onboard Communication in AUTOSAR

Introduction

Secure Onboard Communication (SecOC) is a security mechanism defined in the AUTOSAR standard to protect in-vehicle network communication. The primary objective of SecOC is to ensure the authenticity and integrity of sensitive data. The SecOC module validates the authenticity and freshness of the PDU messages between ECUs to make sure that the message comes from a known source and contains the correct data and protects against key threats such as message spoofing, message tampering and replay attacks. 

The SecOC concept is commonly used in applications where secure communication is necessary, such as authenticating messages during software updates and safeguarding intra-vehicle communication in safety-critical systems such as braking and steering.

SecOC Message Structure

A SecOC message consists of two parts:

• Authentic Payload: This is the standard raw data exchanged between ECUs such as motor speed, torque requests, and sensor readings etc.
• Authentication Information: On the sender side, the SecOC module creates a secure payload consisting of a truncated CMAC value and a truncated freshness value, positioned based on the module configuration, which is used later on the receiver side. Depending on the message configuration, this information is either appended to the authentic payload and sent as a single message, or sent as a separate message with a dedicated message identifier and link data to ensure that it maps correctly to the authentic payload.

‍

Freshness Values & The FVM

Freshness values are used to ensure that messages are recent and to prevent attackers from using previously valid messages. When a SecOC message is received, the receiving ECU validates the freshness value against the expected bounds and rejects the message if the freshness value is too old, repetitive or outside the acceptance window. The complete Freshness Value is typically constructed by combining a Trip Counter, Reset Counter, Message Counter and a Reset Flag.

‍

The Freshness Value Manager (FVM) is a logical component responsible for managing freshness values across all SecOC-protected messages in a vehicle network. It handles the generation, storage, updating, and validation of freshness values, ensuring they remain consistent even across ECU restarts and different operating modes. 

On the sender side, the FVM retrieves or increments the current freshness value, and hands it over to the SecOC module for MAC (Message Authentication Code) computation. 

On the receiver side, the FVM checks the incoming freshness value against the expected value within a defined acceptance window. If the value falls outside this threshold, the SecOC module rejects the message entirely. Depending on the implementation, this rejection can be reported as a security event or as a diagnostic fault.

Synchronization messages are transmitted periodically to ensure that all ECUs in a vehicle network use the same Trip Counter and Reset Counter values.

Message Authentication Codes (MAC)

A MAC is a cryptographic checksum computed using the SecOC Data ID, payload data, freshness value, and a shared symmetric key which is securely stored on the HSM.

The main purpose of the MAC is to ensure that the payload data and freshness value have not been manipulated, and that the correct data has been received by the ECU. On the receiver side, the ECU independently calculates the MAC using the same inputs and compares it against the received value. If there is any mismatch between these values which could indicate tampered data or an invalid key, the SecOC message will not be processed further.

SecOC Profiles

SecOC profiles are predefined security configurations that specify the cryptographic algorithms and modes to be used for the MAC computation, and defines how truncation is applied to the MAC and freshness value in a SecOC message.  

AUTOSAR specifies three profiles with different truncation sizes for freshness value and MAC. All profiles use the CMAC with AES-128 encryption algorithm.

‍

Processing SecOC Messages

Transmitter

Receiver

‍

Technical Challenges in SecOC Implementation

While implementing the SecOC concept, we encountered three major challenges that we had to work through. Below are the issues we tackled.

Dynamic positioning of linked data

During the early implementation phase, we assumed that the Message Linker data position would be the same for the Authentic I-PDU and the Cryptographic I-PDU within a Secured PDU Collection message. When reviewing the AUTOSAR standard (Specification of Secure Onboard Communication AUTOSAR CP R22-11), we found only a few requirements closely related to the Message Linker, such as [SWS_SecOC_00209] and [SWS_SecOC_00210]. These requirements state that the Message Linker is extracted from the Authentic I-PDU using bit position SecOCMessageLinkPos for a length of SecOCMessageLinkLen bits, and that the Cryptographic I-PDU is constructed by concatenating Authentication Data and Message Linker. However, neither requirement explicitly specifies the Message Linker position in a Cryptographic I-PDU message.

The initial ARXML configuration files we worked with always placed the message linker after the authenticator at the same bit position in the Authentic and Cryptographic PDU message, which reinforced our assumption that it was correct. During testing, however, we discovered that this assumption was incorrect.

We later adjusted our implementation so that for Cryptographic I-PDUs, the linked data is appended after the Truncated Freshness Value and Truncated CMAC fields. Its position is dynamic, depending on the FV and CMAC positions as well as the SecOC profile being used.

Endianness issue with data fields like the Unique Data ID

To protect against message spoofing, SecOC includes several data fields like a unique 2-byte Data Identifier as part of the CMAC computation. This is where we ran into a classic embedded systems issue: depending on the underlying microcontroller's architecture, these values could get byte-flipped, and we ended up having the wrong CMAC values. As a result, all SecOC messages were simply not validated and logged as authentication failures, because the CMAC values on each side no longer matched.

The fix was to enforce MSB / Big Endian format across any SecOC data handling independent from the hardware used, as proposed by the AUTOSAR standard. Making sure that bytes always enter the CMAC computation in correct order.

Format Issues in Freshness Value Construction

To verify SecOC messages on the receiver side, the Freshness Value Manager (FVM) reconstructs the Freshness Value. This starts with determining which format (Format 1, 2, and 3) shall be used, based on the conditions specified in AUTOSAR Standard Table 9, by evaluating the reset flag status, trip counter increments, and lower-end message counter values.

While implementing this format-selection logic, the standard does not clearly define the syntax used to interpret the “Trip counter | reset counter comparison” condition, specifically with the symbol "|". Elsewhere in the standard (Specification of Secure Onboard Communication AUTOSAR CP R22-11), under [SWS_SecOC_00209], "|" is explicitly defined as concatenation. Since Table 9 does not explicitly clarify whether the same convention applies here, it was not clear whether the condition meant testing a concatenated value of the trip and reset counters or testing the trip and reset counter values individually. To get clarity on this, we had to refer to other implementations and available sources, and ultimately concluded that in this particular scenario, "|" indicates that the trip counter and reset counter values are to be tested independently.

Turning this multi-conditional logic into C code was more challenging than we expected. Handling the typical cases like out-of-sequence messages, accurately tracking previously received values across different messages in the network, and managing counter wraps led to frequent logic errors during the initial implementation phase. We had to implement a strict state machine and followed by extensive unit testing to get the transitions between Formats 1, 2, and 3 right without losing any synchronization.

Conclusion

SecOC is not just an optional addition to a vehicle's software stack. UN Regulation No. 155 requires a cybersecurity management system for vehicle type approval, and ISO/SAE 21434 sets the cybersecurity engineering process behind it, which is why authenticating in-vehicle messages has become standard practice. By combining symmetric cryptography with strict freshness synchronization, SecOC authenticates in-vehicle PDUs and closes off message spoofing, tampering, and replay as attack vectors on the bus.

Our team delivers SecOC integration expertise, backed by extensive validation and testing through advanced Hardware-in-the-loop (HIL) test setups.