Before this:Encryption & authentication
OTAR & key management
Key takeaways Encryption is only as practical as its key distribution. A key is a secret number; each call tags — in the clear — which algorithm ID (ALGID) and which key ID (KID) it used, so the right radio can decrypt. Loading keys by hand with a keyloader doesn’t scale, so big fleets use OTAR (over-the-air rekeying) to distribute and rotate keys remotely from a key management facility. Keys change on a schedule — the crypto period — which limits exposure if one leaks. None of this lets a scanner hear the audio: you can read the KIDs and ALGIDs, but never the key. See encryption & authentication.
The previous lesson covered how trunked voice is encrypted and how a decoder can see that a call is protected without being able to hear it. This one answers the question that raises: with thousands of radios in a fleet, how do they all get the same secret key — and change it — without a technician touching every handset? That logistics problem, key management, is where OTAR comes in.
Keys, key IDs and algorithm IDs
A key is just a secret number, shared between the radios allowed onto a secure talkgroup. The cipher mixes that number into the voice bits so only a radio with the matching key can recover audio. Two labels ride in the clear on every encrypted call:
- the algorithm ID (ALGID) — which cipher: AES-256, DES-OFB, ADP (an RC4-based option), a proprietary mode, or a value meaning clear (unencrypted); and
- the key ID (KID) — which key of the several a radio may hold.
These tags exist so a receiving radio knows how to handle the call — which algorithm to run and which stored key to apply. Because they travel unencrypted alongside the payload, a scanner reads them too. The crucial asymmetry: the KID names the key, it is not the key. Knowing that a call used key 3 under AES-256 tells you nothing about the secret itself.
Loading keys: keyloaders vs OTAR
Traditionally, keys were loaded by hand. A keyloader — often a KVL (key variable loader), a small handheld device — is physically touched to each radio’s connector, and the key is transferred over that wire. For a handful of radios this is fine. For a fleet of hundreds or thousands spread across a region, it is a logistics nightmare: every rekey means rounding up every radio, and a unit in the field or on a distant shift is easily missed.
OTAR (over-the-air rekeying) solves this by sending keys over the air instead. A central key management facility (KMF) distributes and updates keys remotely, so a fleet can be rekeyed without anyone physically handling a radio. Keyloading and OTAR often coexist: a keyloader may plant an initial key-encryption key, after which OTAR handles the routine traffic keys.
How OTAR works (at a high level)
The KMF sends rekey messages addressed to individual radios or to groups. These messages are themselves encrypted — a new traffic key is wrapped under a key the target radio already holds — so the new key is never exposed on the air. Through this channel the KMF can:
- add a new key to a radio,
- change or update an existing key, and
- zeroize (erase) keys remotely — useful if a radio is lost or stolen.
Radios can also acknowledge and, in some systems, request rekeys, letting the KMF track who is current. The mechanism is standardized in P25 (TIA-102), and comparable over-the-air key management exists in DMR and TETRA in their own forms. The common thread: keys move between authorized radios only, wrapped so that a monitor sees rekey activity but never the key material.
Crypto periods & key rotation
Keys don’t live forever. Operators rotate them on a schedule called the crypto period — daily, weekly, monthly, or tied to an event or shift. The reason is exposure: if a single key were somehow compromised, a short crypto period limits how much traffic that key ever protected. Rotating regularly also retires keys before they’ve encrypted enough material to be worth attacking.
OTAR is precisely what makes frequent rotation practical — pushing a new key to a whole fleet over the air costs the operator almost nothing, whereas hand-loading every radio each week would be unworkable. To a monitor, a rotation is quietly visible: the same talkgroup keeps running, the same ALGID stays in place, but the KID changes to the new key. That’s the signature of a fresh crypto period.
What a scanner can and can’t see
Put plainly, a scanner can:
- log KIDs and ALGIDs per call and watch them over time,
- tell encrypted from clear — the ALGID distinguishes AES-256 or DES-OFB from a clear call, and
- map which talkgroups are secure and spot a rotation when a KID changes.
What it cannot do is recover audio without the key. That isn’t a GopherTrunk limitation; it’s the whole point of the design — modern ciphers like AES-256 are built to resist exactly that, and OTAR is engineered so keys reach authorized radios and no one else.
It’s worth being clear about the line this lesson stays on. Understanding the signaling — what an ALGID or KID means, what a rekey looks like from outside — is ordinary radio literacy and is what a decoder like GopherTrunk reports. Defeating encryption to recover protected audio is a different thing entirely, and it is neither the goal here nor something GopherTrunk attempts. See encryption & authentication for where that wall sits.
Per-system notes
The idea is universal; the details differ by standard.
- P25 — key management is standardized in TIA-102, with a KMF performing OTAR: rekey, key updates, and zeroize, addressed to individual radios or groups. This is the most fully specified of the three. See P25 Phase 1.
- DMR — ranges from basic/enhanced privacy (lightweight, often symmetric scrambling) up to AES, with over-the-air key management offered largely through vendor implementations rather than one universal scheme. See DMR Tier 2/3.
- TETRA — layers protection: the TEA air-interface encryption family secures the radio link, and separate end-to-end encryption can protect the payload across the whole path, each with its own key handling. See TETRA.
Across all three, the takeaway for a monitor is the same: you’ll see the algorithm and key identifiers in the clear, and you won’t see the keys.
Quick check: a talkgroup you watch suddenly shows a new key ID but the same ALGID. What happened?
Recap
- A key is a secret number; every call tags its ALGID (which cipher) and KID (which key) in the clear so the right radio can decrypt.
- Keyloaders (a KVL touched to each radio) don’t scale; OTAR distributes and updates keys over the air from a key management facility (KMF).
- OTAR sends wrapped rekey messages to radios or groups, and can add, change, or zeroize keys remotely — standardized in P25 (TIA-102), with variants in DMR and TETRA.
- Keys rotate on a crypto period to limit exposure; to a monitor a rotation looks like the same talkgroup and ALGID with a new KID.
- A scanner can log KIDs/ALGIDs and tell secure from clear, but cannot recover audio without the key — that’s the design working as intended.
Next up: the other things a trunked system carries besides voice — data services: GPS, text & registration.
Frequently asked questions
What is OTAR?
OTAR stands for over-the-air rekeying. Instead of a technician touching each radio with a keyloader, the system sends encrypted rekey messages over the air from a key management facility (KMF), so keys can be added, changed, or zeroized remotely across a whole fleet. It is standardized in P25 (TIA-102) and exists in different forms on DMR and TETRA.
Can a scanner decode an OTAR or encrypted system?
No. A scanner can read the clear-text tags a call carries — the algorithm ID (ALGID) and key ID (KID) — so you can see which talkgroups are secure and which algorithm and key are in use. But without the actual key the voice payload stays unintelligible, and OTAR only moves keys between authorized radios; it never exposes them to a monitor.
What is a key ID?
A key ID (KID) is a short number that names which key a call was encrypted with, without revealing the key itself. It rides in the clear alongside the algorithm ID so the receiving radio knows which stored key to apply. When a system rotates keys, the ALGID usually stays the same while the KID changes.
How often do keys change?
On a schedule set by the operator called the crypto period — it might be daily, weekly, monthly, or tied to an event. Shorter periods limit how much traffic a single compromised key could expose. OTAR is what makes frequent rotation practical, since no one has to visit each radio to load the new key.