Seed–Key Security Access and Brute-Force Protection

The problem

Diagnostic services that write configuration or reflash an ECU must be locked behind security access. Weak seed-key schemes with predictable seeds or simple algorithms have been broken in real vehicles, so a robust design needs good randomness, a cryptographic key function and lockout against guessing.

Objectives

• Implement 0x27 request-seed and send-key on top of a UDS and ISO-TP layer.
• Generate unpredictable seeds on an MCU without a hardware random number generator.
• Derive keys with a keyed MAC such as HMAC-SHA-256 or AES-CMAC.
• Protect against brute force with persistent attempt counters and time delays.
• Test with legitimate and attack scenarios and measure timings.

What you need

Key concepts

Seed and key

The ECU sends a random seed; the tester computes a key from it with a secret; the ECU checks the key. Only someone with the secret can answer.

Entropy on the F103

The STM32F103 has no true random number generator. Entropy can be gathered from the least significant bits of ADC noise and timer jitter, then conditioned with a hash and expanded with a deterministic random bit generator.

Brute-force protection

After a number of wrong keys, the ECU refuses further attempts for a delay (negative response 0x36 exceeded number of attempts, then 0x37 required time delay not expired).

Persistent counters

Storing failed attempts in non-volatile memory stops an attacker from resetting the counter by power-cycling the ECU.

Step-by-step guide

1. 1

   Specify the security design

   Write the threat model: an attacker on the bus can request seeds, send guesses, power-cycle the ECU and record legitimate sessions. Specify 16-byte seeds, keys computed as a truncated HMAC-SHA-256 or AES-CMAC of the seed with a shared secret, three attempts before lockout, a ten-second delay after lockout and after every power-up while the counter is set. Agree the parameters with your guide before writing any code.

   Checkpoint: A specification with threat model, parameters and negative response codes.

2. 2

   Set up CAN and the UDS base

   Turn on the CAN, SPI flash, potentiometer, LCD, LED and UART blocks. Configure bxCAN at 500 kbit/s with request and response IDs such as 0x7E0 and 0x7E8 and connect the USB-CAN adapter with 120 ohm termination. Implement or reuse an ISO-TP layer and a UDS dispatcher with sessions (0x10) and a protected service such as WriteDataByIdentifier (0x2E). Confirm the dispatcher returns correct negative responses for unsupported requests.

   Checkpoint: The tester can enter the extended session and receives 0x7F 0x2E 0x33 (security access denied) for the protected service.

3. 3

   Build the entropy source

   Sample a floating or noisy ADC channel and the potentiometer many times, keep the lowest bits, and mix in timer captures of asynchronous events. Feed this into SHA-256 to seed a simple hash-based DRBG, and save a seed value to SPI flash so each boot starts from new state. Test the output on the PC with basic statistical tests, while noting such tests cannot prove unpredictability.

   Checkpoint: Large output samples pass basic frequency and runs tests, and seeds differ across power cycles.

4. 4

   Implement request seed

   Handle 0x27 0x01: if security is already unlocked return a zero seed, if locked out return 0x37, otherwise generate a fresh seed and remember it. A new seed must be generated for every request so a recorded key cannot be reused. Log every seed over UART during development and analyse a few thousand of them on the PC for repeats or patterns. Never expose the shared secret or expected key in debug output, even during development.

   Checkpoint: Seeds from repeated requests are always different and are 16 bytes long.

5. 5

   Implement send key and lockout

   Handle 0x27 0x02: compute the expected key with the keyed MAC, compare in constant time and unlock on a match. On a mismatch, increment the failure counter in SPI flash before replying with 0x35 (invalid key), and after three failures reply 0x36 and start the delay timer. Clear the stored seed after each attempt. Write the counter before replying so a reset cannot skip the increment.

   Checkpoint: Three wrong keys cause lockout, and a power cycle does not reset the counter.

6. 6

   Build the tester and attacker tools

   Write a Python tester that requests a seed, computes the key with the shared secret and unlocks, then writes a protected DID. Write attack scripts: random key guessing, replaying a recorded key, requesting many seeds to look for repeats, and power-cycling between guesses. Run each attack long enough to show that lockout holds over many cycles, and log every request and response with timestamps so the delays can be checked from the logs.

   Checkpoint: The legitimate tester always unlocks; attack scripts never do.

7. 7

   Measure timings

   Measure seed generation and key verification times with the DWT counter, end-to-end unlock time on the PC, and the effective guessing rate the lockout allows. Calculate expected time to guess a key at that rate for your key length. Measure the delay enforcement too: confirm that requests during the delay always receive 0x37 and that the delay restarts correctly after a power cycle. Measure key comparison time for correct and wrong keys to confirm it does not depend on the key.

   Checkpoint: A table of timings and the calculated brute-force time.

8. 8

   Document and review

   Write up the design, entropy approach, protocol, tests and analysis. Discuss limits: a shared secret across all ECUs is risky, and production systems use per-ECU keys or certificate-based authentication. Ask a peer team to try to break your design and include their findings. Include the message sequence for a successful unlock and for a lockout, the entropy test results and the attack results. Present the peer review findings and any fixes you made.

   Checkpoint: A report including an independent review section.

Testing & validation

• Seeds are fresh for each request and differ across power cycles.
• Lockout and delay persist through power cycles.
• Constant-time key comparison checked by timing measurement.
• All attack scripts fail while the legitimate tester succeeds.

Expected results

A working UDS SecurityAccess implementation on the kit with conditioned entropy, cryptographic key derivation and persistent brute-force protection, tested against realistic attack scripts.

Take it further

• Use per-ECU keys derived from the STM32 96-bit unique ID and a master secret.
• Replace seed and key with UDS 0x29 authentication using certificates.
• Log security events with RTC timestamps.
• Evaluate entropy more rigorously with the NIST SP 800-90B tools.

Viva and review questions