Question for the OTAR savy on generating key-loss key.

[immelmen28]

below is a cut and paste of the help page from CPS and I feel like Im missing something going on here....

OTAR Generate Key-Loss Key
(Secure Configuration, General)

Definition
Enables the radio to automatically transmit a Key-Loss Key signal notifying the ASTRO OTAR or the MDC OTAR Key Management Facility (KMF) that a new encryption key is needed for the current radio. This new encryption key is used for encrypting OTAR (Over-The-Air-Rekeying) messages. Once the KMF receives the Key-Loss Key signal, a new encryption key is transmitted to the radio for the purpose of receiving additional encryption keys.

Important Note
When disabled, if the radio loses all of its keys, it is then not possible to rekey the radio over the air.

Whats got me thinking is the "important note". When they say "the radio loses all of its keys" it sounds to me like they mean ALL of the keys, not just TEKs but also all the KEKs as well and this is a request for the KMF to send a new KEK to facilitate re-keying the TEKs. Otherwise, if the KEKs were still present than OTAR would still be possible with a simple re-key request and this exchange would not be necessary.

My question is what exactly is going back and forth between the subscriber and the KMF in the Key-loss key signal exchange if the radio now has no KEKs in it to decode inbound KMF messages? The key-less radio is obviously saying "I need a new KEK" but how is the KMF getting the new KEK back to the radio without sending it in the clear, or is it doing just that?

Thanks for any insight.

[tvsjr]

I think this is just another example of good Moto writing. My understand is that, once the KEK is gone (zeroized, radio disabled, etc.), you can't do anything over the air. If you could generate a new KEK over the air, then compromising a KMF would be easy.

[immelmen28]

I think this is just another example of good Moto writing. My understand is that, once the KEK is gone (zeroized, radio disabled, etc.), you can't do anything over the air. If you could generate a new KEK over the air, then compromising a KMF would be easy.

This was always my understanding as well. If this is bad Moto writing, its got to be some of the worst I have seen. First, if the radio still has a KEK in it, I would think this feature is completely redundant of a regular re-key request via the radio menu. Further, with regard to the "important note" If the assumption is there still must be a KEK in the radio for anything rekeying related to happen over the air, including this option to function, then why would a rekey over the air with the rekey menu option not be possible if this option is disabled but the KEK is still in the radio?

If the assumption is there must still be a KEK in the radio for this to function, then the way that note is written it makes it sound like this option is a deal breaker if you lose your traffic keys and completely disables OTAR including the rekey menu option if not selected.

scratching head....

[tvsjr]

I don't know. Without some other knowledge of the radio (you could do something with the burned-in ESN, for instance...) I can't think of any way to securely deliver a new KEK to a radio over the air and then complete an OTAR request. What would the security be based on - MDC or ASTRO ID? So, you just clone up a radio with a matching ID, hit the button, and poof you get a new KEK and then TEKs?

/me scratches head...

[sheldon]

/\/\otorola manuals = Jiberish

[mr.syntrx]

KLK is a braindead Motorola invention.

When you a fill a KEK into the radio, the radio encrypts the KEK with itself and stores it in nonvolatile memory as the KLK. The KLK hangs around even after a zeroize operation or tamper event, thereby defeating the purpose of zeroizing the radio because with one poorly validated OTAR request, your "zeroized" radio suddenly has a new KEK and TEKs.

Smart, huh?

[batdude]

just as a point of reference, the KVL kept at most Moto shops for working on fed agency radio installs only has the KLK/KEK loaded into it.

if memory serves, the KMF back in the day was a MDC1200 based system.

this is how it worked:

tech works on radio
tech blasts radio with KEK
tech calls dispatch (regional these days) with radio ID
tech sends KEY REQ
dispatch sees KEY REQ, sends new TEKs, encrypted with the KEK to the requesting MDC unit ID


that was it



d

[mr.syntrx]

That's common practice for a lot of government cryptographic equipment, even beyond the radio sphere.

Apart from being the epitome of bad COMSEC practice, having KLK generation enabled also breaks FIPS 140 compliance, if that's important to you.

[immelmen28]

KLK is a braindead Motorola invention.

When you a fill a KEK into the radio, the radio encrypts the KEK with itself and stores it in nonvolatile memory as the KLK. The KLK hangs around even after a zeroize operation or tamper event, thereby defeating the purpose of zeroizing the radio because with one poorly validated OTAR request, your "zeroized" radio suddenly has a new KEK and TEKs.

Smart, huh?

Thank you, that answers my question about what appeared to be a big hole in OTAR security but raises another....If the KLK can survive a zeroiez command or a tamper situation, is there anything that can wipe it out of the subscriber hardware or are all these radios/UCMs hitting the used market with the KLK still in them?

I always wondered why in the 21st century we still have to pull paper tapes to rekey the crazy10, but this explains why OTAR is a no-go with the Type-1 stuff.

having KLK generation enabled also breaks FIPS 140 compliance, if that's important to you.

what prompted my question in the first place was seeing this enabled in a radio that belongs to Uncle Sam.

[tvsjr]

what prompted my question in the first place was seeing this enabled in a radio that belongs to Uncle Sam.

Not every entity has the same level of paranoia. Infinite key retention is a pretty common feature to see enabled as well.