SecurityAccess seed/key weaknesses and how to test them

SecurityAccess (UDS service 0x27, ISO 14229-1) is the gate that is supposed to stand between a tester and the dangerous services: flashing, memory access, routines that move actuators. It works as a challenge and response. The tester asks for a seed, the ECU returns a random value, the tester computes a key from it and sends it back. The gate is only as strong as the weakest part of that exchange, and on the bench we regularly see every part fail. This is a description of the test method, not an attack recipe against any one product.

The exchange, byte by byte

tx 27 01            requestSeed, level 1
rx 67 01 3F A2 9C   seed = 3F A2 9C
tx 27 02 11 22 33   sendKey, level 2 (odd = requestSeed, even = sendKey)
rx 67 02            key accepted, level unlocked

A wrong key is rejected with 7F 27 35 (invalidKey). After an already-granted level, a seed request returns 00 00 00, which is correct behaviour and not a weakness.

The weaknesses, and how each one is tested

Constant or low-entropy seed

Ask for a seed several times in a row and compare. If the ECU returns the same value every time, or a value that only increments, there is nothing to guess: an attacker records one seed and the matching key once and replays them forever.

27 01 -> 67 01 3F A2 9C
27 01 -> 67 01 3F A2 9C    identical, constant seed

Test: request the seed many times across fresh sessions and measure the distribution. Flag constant, all-zero, low-entropy or incrementing seeds. No key computation is needed.

Time- or uptime-based seed

Some seeds are derived from a clock or an uptime counter. They look random within one session but become predictable if you know when the ECU booted. The tell is a seed that changes slowly and monotonically, or one that resets after a power cycle.

Test: sample seeds over time and after a reset. A seed that repeats or resets with the ECU points to a predictable source. Because this requires a reset, it is the one check that must be confirmed before it runs.

No attempt counter

A real gate counts wrong keys and locks out. Send a batch of wrong keys and watch the NRC:

27 02 00 00 -> 7F 27 35   invalidKey
27 02 00 00 -> 7F 27 35
27 02 00 00 -> 7F 27 35   ...still 0x35, no lockout

A healthy ECU escalates to 7F 27 36 (exceedNumberOfAttempts) after the configured number of tries. An ECU that answers 0x35 forever has no counter, which means an attacker can brute-force the key space at full speed.

No delay

Even with a counter, the ECU must enforce a delay before the next attempt, answered with 7F 27 37 (requiredTimeDelayNotExpired). Measure the time between a rejected key and the next accepted seed request. A delay of zero, or one that resets on a reset, removes the main defence against brute force.

Short constant or key derivable from the seed

Many weak algorithms are a thin transformation: key = seed XOR constant, key = seed + constant, or a byte rotation. Collect a set of seed and key pairs (from a tool you are entitled to use, or from observing a legitimate tester) and look for a fixed relationship. If the same constant explains every pair, the algorithm is recoverable and the constant is often only a few bytes.

Test: gather seed/key pairs and check for simple XOR, addition, rotation and small lookup relationships. A match means the key can be computed, not guessed.

Default keys and reused keys

Some ECUs ship with a documented or guessable key, or use the same key across every variant in a family. A small catalogue of known default keys unlocks more ECUs than it should.

Test: try a catalogue of default keys, and compare the scheme across variants. The same key working on more than one ECU is a supply-chain weakness, not a single-unit bug.

A sensible order to test in

1. Seed randomness. Cheap, non-destructive, catches the worst cases first.
2. Attempt counter and delay. Send wrong keys, watch for 0x36 then 0x37.
3. Sequence enforcement. Send a key with no prior seed request; the ECU must reject it.
4. Algorithm analysis. Collect pairs, look for a simple relationship, try default keys.
5. Reset predictability. Last, and only with confirmation, because it resets the ECU.

Steps one to three need no valid key at all, and they find most problems. On a power-electronics ECU we tested, the seed was constant across sessions and the lockout never tripped, so the gate added no real protection even though a key algorithm was in place.

What a strong gate looks like

A random seed with full entropy, a key that cannot be derived from the seed without the secret, an attempt counter that trips after a few wrong keys, an enforced delay that survives a reset, and no default or shared keys. AutoST’s SecurityAccess engine runs these checks in order, bounded and non-destructive by default, and reports which part of the gate failed rather than just “locked” or “unlocked”. The point is never to break into a specific ECU, but to show whether the gate would stop anyone who tried.