Skip to main content
emobility.academy
M.TechDiagnostics & cybersecurityAdvanced About 9 weeksKit + add-ons

CAN Intrusion Detection by Message Timing Analysis

You build a CAN intrusion detector on the kit's STM32 that learns the normal timing of periodic messages and flags injection, flooding and suspension attacks from changes in inter-arrival times. Attacks are replayed from a PC through a USB-CAN adapter.

Uses: CAN · UART

The problem

Most in-vehicle CAN traffic is periodic, and attackers who inject or suppress frames disturb that timing. Timing-based detection needs no changes to existing messages, so it can protect classic CAN networks that cannot be redesigned for cryptographic authentication.

Objectives

  • Capture or synthesise realistic periodic CAN traffic with several IDs and periods.
  • Implement per-ID timing statistics on the STM32 using bxCAN receive timestamps.
  • Detect injection, flooding and suspension attacks with timing rules and a CUSUM detector.
  • Measure detection rate, false alarms and detection delay against a baseline.

What you need

From the EV Embedded Development Kit

  • STM32F103C8T6 microcontroller unit (Arm Cortex-M3)
  • CAN bus interface
  • 16×2 LCD
  • RGB LEDs and a buzzer
  • Serial UART interface
  • SPI flash memory

Software

  • STM32CubeIDE
  • Embedded C with HAL drivers
  • Python with python-can, pandas, NumPy and matplotlib
  • Optional: a public CAN intrusion dataset such as the HCRL Car-Hacking dataset for replay

Extra parts

  • A USB-CAN adapter — The PC replays normal traffic and attacks onto the bus; the kit has a single CAN node and needs another to generate traffic.

Key concepts

Inter-arrival time
The time between two frames with the same ID. For a periodic message it clusters tightly around its period, with jitter from bus arbitration.
Injection, flooding and suspension attacks
Injection adds forged frames of an existing ID, which shortens inter-arrival times; flooding sends high-priority frames to block others; suspension stops a message, which lengthens them.
CUSUM
A cumulative-sum detector that adds up small deviations from the expected mean and alarms when the sum crosses a threshold, catching sustained small changes.
Hardware timestamps
bxCAN can capture a 16-bit timer value at the start of frame reception in time-triggered mode; otherwise a timer read in the RX interrupt gives timestamps with some interrupt latency.

Step-by-step guide

  1. 1

    Build the traffic model

    Define a set of 10 to 20 CAN IDs with periods from 10 ms to 1 s, modelled on an EV: BMS status, motor speed, throttle, charger and dashboard messages. Write a Python generator with python-can that sends them through the USB-CAN adapter with realistic jitter. Optionally replay normal traffic from a public dataset such as the HCRL Car-Hacking dataset, scaled to 500 kbit/s.

    Checkpoint: Normal traffic plays for an hour with stable periods, checked from the adapter's log.

  2. 2

    Set up CAN reception on the kit

    Turn on the CAN, LCD, LED, SPI flash and UART blocks. Configure bxCAN at 500 kbit/s with filters accepting all IDs (mask zero) into both FIFOs. Run a free-running timer at 1 MHz and timestamp each frame in the RX interrupt using HAL_CAN_GetRxMessage, or enable time-triggered communication mode for hardware timestamps. Ensure the bus has 120 ohm termination at both ends.

    Checkpoint: The kit receives every frame with no FIFO overruns at full traffic, checked by per-ID counters against the sender.

  3. 3

    Learn normal timing

    In a training phase, compute for each ID the mean and standard deviation of inter-arrival time and the minimum and maximum seen, using integer microseconds and running sums. Store the learned profile in SPI flash so it survives restarts. Use a hash table or a sorted array with binary search for ID lookup, since RAM is limited to 20 KB.

    Checkpoint: Learned periods match the generator's settings within the measured jitter.

  4. 4

    Implement detectors

    Implement three rules: an unknown-ID detector, a too-early detector that flags inter-arrival times well below the learned minimum, and a too-late detector for suspension. Add a per-ID CUSUM on normalised timing deviations for small sustained changes. Add a bus-wide frame-rate monitor as the simple baseline. Keep detection work in the interrupt short, deferring heavy work to the main loop. Document each detector's parameters and the reasoning behind their initial values.

    Checkpoint: Each detector fires on a hand-crafted test case and stays silent on normal traffic.

  5. 5

    Create attack scenarios

    Write Python attack scripts: injection of an existing ID at its own rate and at higher rates, flooding with ID 0x000, suspension of one ID by stopping it in the generator, and a masquerade where an attacker replaces a message while keeping its period. Label start and end times for every attack. Vary attack rates and durations, and include short attacks of a few frames, since these are the hardest for statistical detectors to notice.

    Checkpoint: A labelled set of at least 50 attack runs of each type with ground-truth times.

  6. 6

    Run detection experiments

    Run all attack scenarios with the kit detecting live. Log each alarm over UART with ID, detector and timestamp, and show alarms on the LCD and LEDs. Align alarms with ground truth on the PC to compute detection rate, false alarms per hour and detection delay per attack type. Repeat each scenario several times with different random seeds in the generator, so results reflect variation in timing jitter and attack start points rather than a single run.

    Checkpoint: Results tables per attack type and detector.

  7. 7

    Tune and compare

    Vary thresholds and CUSUM parameters and plot detection rate against false alarms (ROC-style curves). Compare with the frame-rate baseline. Expect timing detection to miss the masquerade attack, which keeps timing normal, and report that honestly as a limit of timing-only methods. Tune only on a separate set of attack runs and evaluate on the rest, so the final results are not optimistic. Report the parameters used for each detector in a table that another researcher could apply directly.

    Checkpoint: Trade-off curves and a justified final configuration.

  8. 8

    Measure embedded cost

    Measure cycles per received frame with the DWT counter, RAM used by the profile and CPU load at full bus traffic. Check the worst case: at 500 kbit/s with short frames the bus can carry several thousand frames per second, and the IDS must keep up without overruns. Also report how the cost grows with the number of IDs monitored, since a real vehicle network can carry far more IDs than the test traffic model used here.

    Checkpoint: CPU load at full bus load measured and below a safe margin, with no FIFO overruns.

  9. 9

    Write up

    Document the traffic model, detection methods, attacks, results and costs. Discuss threats to validity: synthetic traffic, the generator's own timing jitter and the masquerade gap. Release scripts and logs. Structure the chapter around detection performance per attack type, embedded cost and limitations. Include the ROC-style curves, the final parameter table and example traces showing an attack being detected. Explain clearly which conclusions depend on synthetic traffic and which were confirmed with public dataset replay.

    Checkpoint: A thesis chapter draft and a reproducible package.

Testing & validation

  • No frame loss at full traffic, checked with per-ID counters.
  • Detection rate, false alarm rate and delay per attack type.
  • Comparison with a frame-rate baseline.
  • CPU load and memory measured at full bus load.

Expected results

A real-time timing-based CAN IDS on the STM32 with measured detection performance across attack types, its limits against masquerade attacks, and its CPU and memory cost.

Research angle for your M.Tech thesis

Research questions: how well do lightweight timing detectors catch injection, flooding and suspension on classic CAN when run on a constrained ECU, and what is the detection delay versus false alarm trade-off? Metrics: detection rate, false alarms per hour, detection delay, cycles per frame, RAM. Baselines: frame-rate thresholds and published timing detectors re-implemented on the same data. Datasets: synthetic EV-style traffic and public sets such as HCRL Car-Hacking. A strong result is an on-target evaluation with clear analysis of what timing alone cannot detect.

Take it further

  • Add payload checks such as range and rate of change of signals.
  • Add clock-skew fingerprinting of senders.
  • Add a machine-learning detector and compare.
  • Store alarm records with RTC timestamps for forensic analysis.

Viva and review questions

Why does injection change timing?

An attacker's frames of an existing ID interleave with the genuine ones, so the receiver sees that ID more often and inter-arrival times shorten.

What attack does your IDS miss?

A masquerade attack where the attacker silences the real sender and sends its own frames at the same period. Timing stays normal, so payload or authentication checks are needed.

How do you avoid losing frames at high bus load?

The RX interrupt only timestamps and queues frames, both FIFOs are used, and heavier detection runs in the main loop. We confirmed no overruns at full load.

Related EV projects

All 100 EV projects