Secure Onboard Communication (SecOC)

In the chapter on CAN 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 ^[1]. 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 ^[2].

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.

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 ^[3] and RFC 4493 ^[4] 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.

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) ^[5]. 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.

Not every OEM relies on SHE for key management. Some manufacturers use their own cryptographic scheme in which the modules on the network derive a shared key together instead of receiving one from a backend. A talk on OEM SecOC strategies by Jan-Peter von Hunnius explains how such a scheme works and provides lots of other relevant information ^[6].

The Memory Update Protocol

The SHE memory update protocol is used by CMD_LOAD_KEY and CMD_EXPORT_RAM_KEY. It wraps a new key into five messages. The first three (M1, M2 and M3) are sent to the SHE module to perform the update. The last two (M4 and M5) are returned to the backend as proof that the update succeeded.

None of these messages are encrypted with the new key itself. Instead, the backend derives a set of keys from an authentication key ($K_{\text{AuthID}}$) that is already shared with the ECU beforehand. Typically this a unique key per ECU installed during production. The OEM can look up the value of this key in their backend using the ECU's serial number.

The derivation uses the Miyaguchi-Preneel ^[7] one-way compression function built on AES-128. A key is derived by compressing the secret concatenated with a 128-bit constant, so $\text{KDF}(K,C)=\text{AES-MP}(K\Vert C)$. The constants KEY_UPDATE_ENC_C and KEY_UPDATE_MAC_C are fixed values defined in the AUTOSAR SHE standard (section 4.12) ^[5], and pick the encryption and MAC keys respectively:

$K_1$ and $K_2$ come from the authentication key and are used to encrypt the new key and authenticate the update. $K_3$ and $K_4$ come from the new key $K_{\text{ID}}^{\prime }$ and are used to build the verification messages. The five messages are then:

References