Lightweight Cryptography for In-Vehicle Networks: Latency and Bus-Load Cost

The problem

Securing in-vehicle networks adds computation and payload overhead to every message. On classic CAN with 8-byte payloads and low-cost ECUs, the choice of algorithm and frame layout decides whether deadlines can still be met. Measured, comparable results on representative hardware are needed to choose well.

Objectives

• Implement and verify several lightweight MAC and authenticated encryption schemes on the Cortex-M3.
• Measure cycles, code size and RAM for each.
• Design secured frame layouts and measure end-to-end latency and bus load for an EV message set.
• Analyse schedulability of the secured message set and identify the best options.

What you need

Key concepts

Lightweight cryptography

Algorithms designed for constrained devices. NIST selected the Ascon family for lightweight authenticated encryption and hashing.

MAC versus authenticated encryption

A MAC proves integrity and origin; authenticated encryption also keeps data confidential. Most CAN control signals need integrity more than confidentiality.

Payload overhead

A MAC and freshness value take bytes from the 8-byte CAN payload, or require extra frames, raising bus load and latency.

Response-time analysis for CAN

A method to compute each message's worst-case latency from priorities, frame lengths and bit stuffing, used to check that secured messages still meet deadlines.

Step-by-step guide

1. 1

   Define the study

   Choose candidate schemes: AES-128-CMAC, Ascon-based MAC and authenticated encryption, SipHash-2-4, and Chaskey. Choose metrics: cycles per message, code size, RAM, latency from send request to verified receipt and bus load. Define an EV message set of 15 to 25 IDs with periods, sizes and deadlines. Fix the compiler and flags so results are comparable. Agree how each scheme will be configured, including tag lengths and nonce handling.

   Checkpoint: A protocol document with schemes, metrics, message set and build settings.

2. 2

   Implement and verify each scheme

   Integrate reference C implementations, adapting only what is needed for the Cortex-M3, and verify each against its official test vectors and against Python libraries where available. Keep key handling identical across schemes so differences come from the algorithms. Record the source and version of each implementation and any change you made for the target. Choose portable C versions rather than assembly-optimised ones at first, then optionally add optimised versions as a separate, clearly labelled comparison.

   Checkpoint: Every scheme passes its test vectors on the target.

3. 3

   Benchmark computation and memory

   Measure cycles with the DWT counter for message lengths from 1 to 16 bytes, including key setup cost separately. Record flash and RAM from the map file and stack usage by stack painting. Repeat each measurement many times and report spread, and note the effect of flash wait states. Run benchmarks with interrupts disabled for clean cycle counts, then repeat with normal interrupt activity to show the variation an ECU would see.

   Checkpoint: Tables of cycles per message length, code size and RAM for each scheme.

4. 4

   Design secured frame layouts

   Design layouts for each scheme: truncated tags of 24, 32 and 64 bits with short freshness counters in one frame, and two-frame layouts for full tags. Calculate frame lengths including worst-case bit stuffing. Discuss the security level each truncation gives. For each layout, also state how many bytes remain for signal data, because some EV messages need all eight bytes and cannot be protected in one frame. Note how the freshness value is resynchronised when frames are lost.

   Checkpoint: A table of layouts with bytes used, tag length and frame bit length.

5. 5

   Set up the two-node testbed

   Connect the kit to a second kit or a USB-CAN adapter at 500 kbit/s with proper termination. Turn on the CAN, UART, SPI flash and LCD blocks. Implement a sender that runs the EV message set with each scheme and a receiver that verifies, timestamping send requests and verified receipts with a shared timer reference or a GPIO marker captured by both nodes.

   Checkpoint: The full message set runs with each scheme with no verification failures.

6. 6

   Measure latency and bus load

   For each scheme and layout, measure end-to-end latency per message ID, its worst observed value and the bus load from the adapter's frame log. Compare with the unsecured baseline. Increase background load to find where deadlines start to be missed. Repeat each configuration several times and report worst observed latency and percentiles as well as averages. Keep the background traffic identical across schemes so the only difference between runs is the security scheme in use.

   Checkpoint: Latency distributions per ID and bus load for every configuration.

7. 7

   Run schedulability analysis

   Apply CAN response-time analysis to the secured message sets in Python, adding computation time at sender and receiver to the end-to-end deadline. Compare predicted worst cases with measurements; any measured value above prediction means a missing effect that must be explained. Include bit stuffing, error frames if you inject them, and the receiver's verification time in the model. Report the schedulable margin as the largest extra load the secured set can take before a deadline is missed.

   Checkpoint: Predicted versus measured worst latency for each scheme, with no unexplained violations.

8. 8

   Analyse trade-offs

   Build plots of security level against latency and bus load for each scheme and layout. Identify which schemes keep the message set schedulable and which give the best margin. Discuss key management and freshness synchronisation costs that apply equally to all schemes. Separate the effect of computation from the effect of payload overhead, since they suggest different fixes. Note which results would change on a microcontroller with hardware AES or on CAN FD.

   Checkpoint: Trade-off plots and a ranked recommendation with reasons.

9. 9

   Prepare publication-quality output

   Release implementations, benchmark firmware, logs and scripts. Write the chapter with methods, results and threats to validity such as compiler choice and single MCU type. Write the chapter with a clear methods section that another researcher could follow on the same kit. Include the message set definition, all benchmark tables, the latency and schedulability results and an honest discussion of limitations, such as a single MCU type, a single compiler and synthetic traffic. Make every figure reproducible from the released logs.

   Checkpoint: A reproducible package and a draft paper-style chapter.

Testing & validation

• All schemes pass official test vectors on the target.
• Cycle counts repeated with reported spread.
• Measured latencies below predicted worst cases.
• Unsecured baseline measured on the same testbed.

Expected results

Measured costs of lightweight cryptography on a Cortex-M3 over classic CAN, with latency, bus-load and schedulability results that show which schemes and frame layouts fit a realistic EV message set.

Take it further

• Add CAN FD layouts analytically for comparison (the kit is classic CAN only).
• Add batch authentication of several frames with one tag.
• Measure energy per message with an external power monitor.
• Study key update and counter resynchronisation under message loss.

Viva and review questions