Vehicle Networks & Protocols · Chapter 7

Secure Onboard Communication (SecOC)

In the previous chapter a few different checksum algorithms were discussed. Most of these checksum algorithms are meant to detect accidental changes to the message. Some of them try to include some secrets in their computation to make it harder to forge a message. However, this is mostly security by obscurity, as the algorithm can be reverse engineered by obtaining the firmware.

AUTOSAR introduced SecOC in the 4.2.1 release series. The goal of this standard is to provide a cryptographically secure way to verify the integrity of a message, while keeping the overhead low to retain some amount of usable space in a standard 8-byte CAN message.

A similar standard was introduced by JASPAR under ST-CSP-6 Requirements Specification for Message Authentication.

Block diagram of SecOC adding a (truncated) MAC and counter to a message.

Freshness Value

To prevent rollback-based attacks, it's important that a monotonically increasing counter is included in the message and MAC computation. Even across multiple drives, this counter should not repeat itself. Otherwise, an attacker could collect a lot of data from a specific vehicle to forge messages.

This counter is called the Freshness Value (FV). The exact construction is profile- and configuration-dependent, but one common construction combines the following counters.

Trip Counter — Incremented each time the vehicle is started. This counter is managed by a single designated node, and is broadcast to the rest of the network as part of the synchronization message.
Reset Counter — A counter that increments at a fixed interval. This counter is also part of the synchronization message.
Message Counter — A counter that increments each time a message is sent. It's reset when the Reset Counter is incremented.
Reset Flag — The few least significant bits of the reset counter. These are added to the FV again, ensuring that if the FV is truncated it contains both the least significant bits of the reset counter and the message counter.

Construction of the Freshness Value from the different counters.

Synchronization Message

To ensure that all nodes in the network use the same trip counter and reset counter, a synchronization message is sent periodically by a designated SecOC sync node (typically the gateway). This message contains the full trip counter and reset counter. The synchronization message is also protected by a MAC.

MAC Computation

The first step of computing the MAC is to build the data that is used for authentication. This data is constructed by concatenating the message ID, the payload, and the FV.

The MAC itself is computed through the AUTOSAR cryptographic services. AES-CMAC is a common choice; refer to NIST SP 800-38B and RFC 4493 for details on that algorithm.

After computing the MAC, the message that will be sent out over the network has to be constructed. This is done by concatenating the payload, a few of the lower bits of the FV, and the upper bits of the MAC.

By adding the lower bits of the FV, the receiving nodes receive both the lower bits of the reset counter and the message counter. By combining this with the internal state of the receiver, this should be enough to construct the full FV of the transmitter. After the FV is reconstructed, the MAC can be computed and compared to the MAC that was sent with the message.

Combination of the payload, truncated FV, and MAC that's sent out over the network.

Key Management

As the AES cryptography involved in computing the MAC is based on symmetric cryptography, it's important that these keys cannot be easily recovered by the attacker.

Key management is part of a different AUTOSAR standard, the specification of SHE (Secure Hardware Extension). This is meant as an API for a hardware security module that can be used to store keys and handle the computation of the MAC. However, if the microcontroller does not have a hardware security module, it's also possible to implement this in software.

Key management also includes the ability to update a key whenever a new component is installed in the car by a workshop. In this case, the whole network has to be provisioned with a new key such that all ECUs can talk to each other again.

Because an attacker could simulate the installation of a new ECU, it's important that the key cannot be obtained by observing this rekeying operation. Therefore, the SHE standard also specifies a way to securely distribute the key to the new ECU.

The most important takeaway from this process is that the new key is encrypted using one of the keys already present in the ECU. This way, the new key can be distributed to the ECU without the attacker being able to obtain the key. For more information, refer to the AUTOSAR SHE standard.