Secure Onboard Communication (SecOC) for ADAS Signals on CAN

The problem

Classic CAN has no authentication, so any node, or an attacker with access to the bus, can send frames that look legitimate. SecOC adds a message authentication code and freshness value to protected PDUs, which lets receivers reject forged and replayed frames. It costs payload bytes, computation and key management effort. This project implements SecOC on real CAN hardware and measures both its protection and its cost.

Objectives

• Explain SecOC: authentic PDU, secured PDU, freshness value, MAC and truncation.
• Design a secured PDU layout for ADAS signals within 8-byte classic CAN frames.
• Implement CMAC-AES generation on the STM32 and verification on Linux.
• Implement freshness management with counters and resynchronisation.
• Test spoofing, replay and tampering attacks and measure overhead.

What you need

Key concepts

Secured PDU

The authentic payload followed by a truncated freshness value and a truncated MAC. On classic CAN the authentic payload must shrink to leave room for them.

CMAC

A message authentication code based on a block cipher such as AES-128. It proves the sender knew the shared key and the data was not changed.

Freshness value

A counter or time value included in the MAC calculation so an old frame replayed later fails verification.

Truncation

Only part of the MAC and freshness are sent to save bytes. Shorter MACs raise the chance an attacker guesses a valid one, so length is a security trade-off.

Step-by-step guide

1. 1

   Define the protected signals

   Choose a safety-relevant frame: a BrakeRequest from an ADAS ECU with requested deceleration (from the potentiometer) and a request flag, sent every 20 ms. Define threats from a prior TARA: spoofed brake requests, replayed requests and modified values. Set requirements for detection, acceptable added latency and the number of consecutive verification failures before the receiver reports an attack. Keep the threats in a short table with the expected receiver reaction for each.

   Checkpoint: A requirement list with threats, detection and latency targets for the protected frame.

2. 2

   Design the secured PDU layout

   Fit everything into 8 bytes: for example 3 bytes of authentic payload, 1 byte of truncated freshness and 4 bytes of truncated MAC. Define the full freshness counter (for example 32 bits) kept on both sides, with only the lowest byte sent, and the data used for the MAC: data ID, full freshness and authentic payload. Discuss the security level of a 32-bit MAC against online guessing at 50 frames per second.

   Checkpoint: A byte-level layout diagram and a written justification of MAC and freshness lengths.

3. 3

   Model the sender component

   In Simulink with AUTOSAR Blockset, create a sender software component that reads the potentiometer value, forms the BrakeRequest signal and sends it through a sender port. Map it to AUTOSAR and export ARXML, then inspect the generated description for the port interface and data element. Describe in the report where a SecOC module and secured I-PDU would be configured in a full Classic stack.

   Checkpoint: Exported ARXML that shows the component, port and data element for BrakeRequest.

4. 4

   Implement CMAC on the STM32

   Add a small, well-tested software AES-128 and CMAC implementation to the firmware, since the STM32F103 has no crypto accelerator. Verify it against the published CMAC test vectors for AES-128 before using it. Store a test key in flash and mark it clearly as a lab key. Measure CMAC computation time with the DWT cycle counter. Keep the key in one place in the code so it can be replaced easily.

   Checkpoint: CMAC output matches the published test vectors, with measured cycles per MAC.

5. 5

   Build the secured sender

   Every 20 ms, increment the freshness counter, compute the CMAC over data ID, full counter and payload, truncate it and pack the secured PDU into the CAN frame. Persist the counter's upper bits to flash periodically so it never repeats after reset, and start each power cycle beyond the last stored value. Show the counter and request on the LCD and stream debug data over UART.

   Checkpoint: candump shows secured frames at 20 ms with an incrementing freshness byte and changing MAC.

6. 6

   Build the receiver verification

   In Python with python-can and the cryptography library, receive the frame, reconstruct the full freshness value from the received low byte and the receiver's last accepted counter within an acceptance window, compute the CMAC and compare the truncated values. Accept only if the MAC matches and the counter is greater than the last accepted one. Log results and count consecutive failures.

   Checkpoint: The receiver verifies every legitimate frame over a 10-minute run with no false rejections.

7. 7

   Test attacks

   From a second SocketCAN script acting as attacker, send forged BrakeRequest frames with random MACs, replay recorded legitimate frames, and modify the payload of captured frames while keeping the MAC. Run each attack while the legitimate sender is active. Confirm the receiver rejects every attack frame and raises an attack report after the configured number of failures. Do this only on the isolated bench bus.

   Checkpoint: An attack test table showing all forged, replayed and modified frames rejected.

8. 8

   Test freshness resynchronisation

   Reset the sender, disconnect it for a period, and drop frames on purpose to test the acceptance window. Check that the receiver resynchronises after gaps smaller than the window and rejects frames beyond it. Measure how many frames are lost during resynchronisation and decide whether a separate resynchronisation message is needed. Record behaviour if the sender's stored counter is lost.

   Checkpoint: Resynchronisation results for reset, disconnection and dropped-frame cases.

9. 9

   Measure overhead

   Measure CMAC time on the STM32 per frame and as a share of CPU at 50 frames per second, receiver verification time, and added end-to-end latency compared with an unprotected version of the same frame. Calculate bus load for the unprotected and protected designs, including the lost payload bytes. Extrapolate how many protected frames the STM32 could handle per second.

   Checkpoint: An overhead table with CPU share, latency, bus load and maximum protected frame rate.

10. 10

    Report

    Document requirements, PDU layout, ARXML, firmware and receiver design, attack and resynchronisation tests and overhead. Discuss key management, which this project simplifies with a lab key: production systems need secure key storage, key distribution and update. State limits: software crypto, one protected frame and a bench bus. Relate the design to SecOC and CAN FD, where larger payloads ease truncation trade-offs.

    Checkpoint: A report with attack results, overhead figures and a clear key management discussion.

Testing & validation

• CMAC implementation matches published test vectors.
• No false rejections of legitimate frames over long runs.
• All forged, replayed and modified frames rejected on the bench bus.
• Correct resynchronisation within the acceptance window.
• Measured CPU, latency and bus-load overhead.

Expected results

A working SecOC-style protected CAN frame between the kit STM32 and a Linux receiver, shown to reject spoofing, replay and tampering, with measured computation, latency and bus-load costs.

Take it further

• Move to CAN FD and compare MAC length choices.
• Add a freshness value manager that broadcasts a synchronised time counter.
• Protect several frames with different keys and measure scheduling impact.
• Compare with an intrusion detection approach on the HCRL Car-Hacking dataset.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.