# SecurityAccess seed/key weaknesses and how to test them The common ways a UDS SecurityAccess (0x27) gate fails: constant seeds, no lockout, keys derivable from the seed, and a non-destructive method to test each one. Source: https://auto-st.com/insights/security-access-seed-key-weaknesses ยท Updated: 2026-10-07 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. ## FAQ **What makes a SecurityAccess seed/key scheme weak?** A constant or time-based seed, no attempt counter or delay after wrong keys, a short constant in the algorithm, or a key you can derive from the seed with a simple transformation. Any one of these turns the gate into a formality an attacker can pass. **Can you test SecurityAccess without the key algorithm?** Yes. Seed randomness, the attempt counter, the delay and the sequence can all be checked by observing responses, without ever computing a valid key. Those checks alone catch most of the weaknesses we see. **Is testing SecurityAccess destructive?** The core checks are bounded and non-destructive. The one exception is the reset-predictability check, which resets the ECU to see whether the seed repeats, so it is gated behind an explicit confirmation. ## Sources - [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer](https://www.iso.org/standard/72439.html) - [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering](https://www.iso.org/standard/70918.html) ## Related - [NRC (Negative Response Code)](https://auto-st.com/glossary/nrc) - [Does your seed/key actually hold?](https://auto-st.com/security-access-testing) - [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing) - [UDS enumeration explained: how to map an ECU safely](https://auto-st.com/insights/uds-enumeration-explained) --- AutoST by Zyberum. Canonical page: https://auto-st.com/insights/security-access-seed-key-weaknesses