Field Guide · algorithm

Also known as: DMR privacy, Enhanced Privacy, DMR link-layer encryption

DMR encryption is the link-layer privacy that scrambles voice on a DMR channel by XORing a keystream onto the coded voice frames.1 Several schemes exist. The cipher cores are standard — Motorola “Enhanced Privacy” is RC4, and the DMRA algorithm identifiers map to DES, triple-DES, and AES — but the key and IV derivation from the air interface is proprietary, reverse-engineered, and differs between Motorola and Hytera.2 For a monitoring tool this splits the problem cleanly: the standard cores are straightforward to implement, and the hard, vendor-specific part is recovering the key, which no amount of decoding the signalling accomplishes on its own.

key IV cipher coreRC4 / OFB block keystream ⊕ cipher voice clear AMBE
Whatever the algorithm, DMR privacy reduces to a keystream XORed onto the voice frames; recovering the clear payload needs the correct key and IV, which the standard cipher cores cannot supply on their own.

The algorithms

GopherTrunk’s assessment harness realises the standard cores keyed with material an analyst supplies. The DMRA algorithm identifiers it recognises:

algid Algorithm Key size Core
0x21 RC4 (Enhanced Privacy) ~40 bits (variable) RC4 stream cipher
0x22 DES-OFB 8 bytes DES in OFB
0x23 Triple-DES 24 bytes 3DES in OFB
0x24 AES-128 16 bytes AES in OFB
0x25 AES-256 32 bytes AES in OFB

Motorola’s product line also includes a lighter “Basic Privacy” — a short-key scrambler rather than a real cipher — but the Enhanced Privacy tier and the DMRA block-cipher options are the ones with standard cores worth implementing.

How the keystream is built

For RC4, the supplied key and the frame’s IV bytes are concatenated and used directly as the RC4 key — the common Enhanced-Privacy model — and, unlike P25’s ADP, no warm-up keystream bytes are discarded before use. The RC4 core accepts a variable key length; the 40-bit size is the common Enhanced-Privacy default used for the weak-key dictionary.

For the block ciphers, the scheme runs the cipher in output-feedback (OFB) mode: the IV seeds OFB directly and the cipher generates a continuous keystream independent of the ciphertext, which is exactly the additive-keystream shape the voice XOR needs. The IV is left-justified into a full cipher block, and each algorithm requires its exact key length. In every case the resulting keystream is XORed onto the coded voice frames — the AMBE+2 payloads — so decryption is the same XOR applied with the same keystream.

Crucially, the package implements only the cores; it does not fabricate a vendor key schedule. The key and IV derivation from the air interface is the proprietary part, and it differs between Motorola and Hytera. An analyst who has already recovered the key can decrypt, but nothing here claims to derive that key from the signalling — the honest boundary between a standard cipher and a reverse-engineered protocol.

Relevance to SDR

internal/cryptolab/engine/dmrcrypto/keystream.go exposes Keystream(algid, key, iv, n), which dispatches to RC4 or an OFB block cipher and returns n keystream bytes for the caller to XOR onto the frames, plus KeySize, AlgName, Supported, and a small DefaultKeys dictionary (all-zero, all-ones, and an incrementing pattern) for trying weak or test keys. Keeping this in the crypto lab — as a keystream generator keyed with analyst-supplied material, deliberately without any key recovery — mirrors how the P25 crypto path is structured and makes the tool’s capabilities and its limits explicit.

Sources

  1. Digital mobile radio — Wikipedia, on DMR and its optional link-layer privacy features. ↩

  2. RC4 — Wikipedia, on the stream cipher underlying Motorola Enhanced Privacy. ↩

See also