Scanners
Comments ▾
Figures ▾

Decrypting — AES, DES & Motorola ADP on P25 (Scanners) · Volume 3

Decrypting — Vol 3: How a Radio Decrypts (and Why a Scanner Can't)

Keyloading, over-the-air rekeying, the TEK/KEK hierarchy, and the receive pipeline

Figure 1 — How a key reaches a radio (a Key Variable Loader over a cable, or a Key Management Facility over the air) and where the radio uses it: reading the clear ALGID/KID/MI, finding the key by …
Figure 1 — How a key reaches a radio (a Key Variable Loader over a cable, or a Key Management Facility over the air) and where the radio uses it: reading the clear ALGID/KID/MI, finding the key by its ID, and regenerating the keystream. Original diagram for this site.

3.1 About this volume

A radio that decrypts a talkgroup is doing something a scanner never does: it is holding a secret. Before any of the receive-side machinery from Vol 2 can run, the key has to have been put into the radio, ahead of time, through a channel that has nothing to do with the voice channel. Understanding how keys get loaded — and how they’re managed across a fleet of hundreds or thousands of radios — is what finally makes the whole subject click, because it explains both why encryption works and where, in the real world, it falls down (which is the subject of Vol 4). It also explains, cleanly and finally, why an SDS100 will never decrypt anything: it has no way to be given a key, by design.

3.2 Getting the key in: the KVL and the keyload cable

The traditional way a key enters a radio is by wire, one radio at a time, from a dedicated device called a Key Variable Loader (KVL) — a Key Fill Device in the standards’ language. Motorola’s are the ones you’ll hear named: the KVL 3000, 4000, and 5000. A technician generates or loads the key material into the KVL, connects the KVL to the radio’s accessory port with a short keyload cable, and transfers the key through a defined key-management message exchange (the cable interface is standardized as TIA-102.AACD). The key is written into the radio’s protected key store, indexed by its Key ID.

It is deliberately a physical, hands-on, one-radio-at-a-time process. That is a feature: the key material only ever travels over a short cable in a controlled setting, never over the air in a form anyone could capture. It is also the operational bottleneck that makes the next method necessary, because keying a thousand radios by cable, and re-keying them every time a key is rotated or a radio is lost, does not scale.

3.3 Over-the-air rekeying: the KMF, OTAR, and the TEK/KEK hierarchy

The answer to that bottleneck is Over-The-Air-Rekeying (OTAR) — distributing and updating keys to radios remotely, over the radio system itself, from a central Key Management Facility (KMF). OTAR is standardized in TIA-102.AACA. (A common mix-up: OTAR is the AACA standard; AACD is the cable keyload standard. It’s an easy pair to swap.)

Sending keys over the air sounds like it should undo the whole point of encryption, and the reason it doesn’t is a two-level key hierarchy that is genuinely elegant:

  • A TEK — Traffic Encryption Key — is the working key that actually encrypts voice. This is the key a Key ID points at on a live transmission.
  • A KEK — Key Encryption Key — exists only to encrypt other keys for safe delivery. When the KMF sends a new TEK to a radio over the air, it wraps that TEK inside the KEK. An eavesdropper hears only the wrapped blob; without the KEK, the TEK inside is unrecoverable.

The KEK itself is loaded the old-fashioned way, by KVL and cable, so that the one key that never goes over the air is the one that protects everything that does. There’s further structure below that — a Unique KEK addressed to a single radio, a Common KEK shared by a group — but the core idea is the load-bearing one: OTAR is secure because the keys it sends are themselves encrypted, under a key that was loaded by wire. It’s keys protecting keys, all the way down to a cable in a locked room.

3.4 Using the key: the receive pipeline

Once the key is in the radio, decryption on a received call is the mirror image of the encryption from Vol 2, and every step depends on the clear metadata:

  1. RF in, and decode. The radio demodulates and decodes the P25 signal into its digital frames — the same work any decoder does, encrypted or not.
  2. Read the Encryption Sync in the clear. From the header (and the re-sent sync in the voice superframes) it reads the ALGID, the KID, and the Message Indicator. None of these is secret; they’re the routing label for decryption.
  3. Find the key by its ID. The radio looks in its key store for the key that the KID names. If it isn’t there — the radio was never given that key — the process stops here. There’s nothing to do.
  4. Regenerate the keystream. Using the key and the MI, it runs the named algorithm in OFB mode to reproduce exactly the keystream the transmitter used.
  5. XOR, and out comes the voice. The keystream XORed against the ciphertext yields the original vocoder frames, which go to the audio stage as speech.

Step 3 is the entire game. The metadata gets you as far as knowing which key you’d need. It never gets you the key. A receiver that doesn’t hold the key indexed by that KID gets precisely nowhere, no matter how perfectly it decoded the signal.

3.5 Why a scanner sits on the “no key” branch forever

Now the scanner answer writes itself. A Uniden SDS or BCD-HP, a Whistler — any consumer scanner — has no key store and no keyload port. There is no KVL cable that plugs into it, no OTAR client inside it, no menu to type a key into. It was never designed to hold a secret, because holding secrets is what turns a receiver into part of a secure system, with all the key-management responsibility that implies. So when a scanner decodes an encrypted call, it reads the same clear ALGID/KID/MI every radio reads, discovers it has no key (because it can hold none), and does the only thing left: shows ENC and mutes.

That is not a limitation that a firmware update or a paid upgrade can lift. The paid mode keys for the SDS and BCD-HP scanners unlock decoders for unencrypted modes — they are not, and cannot be, decryption keys (Vol 1 draws that line in detail). The only place in a typical listening setup where a lawfully held key could actually be applied to a signal is a software-defined-radio setup running OP25, and even there the key has to be one the operator is authorized to have — for a system the operator owns or operates, or a test bench under their control. That’s Vol 5. The scanner, by its nature, stays on the “no” branch of the diagram above, permanently.

Sources

Comments (0)

  1. Loading…

Comments are held for moderation — nothing appears until approved.