Encryption Key

[kayn1n32008]

Ya getting mix up in the acronym.
The questions is all about the inherent chicken and egg situation associated with private key distribution and storage.

No worries. In a P25 system, the keys are always securely stored. With in the KMF, The keys are stored in volatile memory, that is designed to detect tampering and when it does, it will erase the key material. When sending the key material over the air during re-keying, the key material is encrypted using the UKEK(a separate encryption key) prior to being transmitted.

At some point the key need to be in the clear for use.

Yes. The key is stored with in the radio in secure and volatile memory, it is also encrypted. The radio will decrypt the key to make use of it with in its own processors and RAM.

There is a great deal of technique and work around in that.

There is also a great deal of development to ensure the keys are not leaked or readable from the subscribers.

For instance the UKEK store the key.

No, the UKEK is an encryption key used to convert the clear text key material to an encrypted text to be sent to the subscriber. It doesn't store anything.

For security reasons I would encrypt the key for transport

That is exactly what the UKEK is used for.

or the key can be extracted from the transport device by anyone gaining access to it.

Again, there are methods to detect those kinds of things, and when it is detected, the keys are erased(zeroized) to prevent the key material from being disclosed in clear text. The KVL, KMF and subscribers are designed to NOT allow keys to be read out in clear text.

Also, physical security of the devices are also a part of keeping the key material from disclosure. Minimizing the number of people that have access to the KMF, KVL and subscribers, having access control to those devices, and having an auditable access list to both the KMF and KVL(S) all make the clear text disclosure of key material as low as possible.

Ok so if the key is encrypted how is the radio access it for use ?

The radio has an encryption key to decrypt the encrypted keys.

Is the operators require to enter a code to unlock the key for operation?

Radios can be configured to require for code to unlock them. If the correct unlock code is not entered in a set number of tries, the keys are zeroized.

Or the key is simply decrypted when transfer from the UKEK to the radio?

the UKEK is not a transfer device. It is an encryption key used to encrypt the TEK for transmission from a KMF to a subscriber radio.

And if it the case how is the key unlock for transfer and by who ?

The KMF is a part of the fixed network infrastructure. It is not physically accessed to use it, but is a part of the network. It is also in a physically secure location owned by the network owner with other fixed network infrastructure.

When the radio is updated with new TEK during OTAR, the new TEK are decrypted by the subscriber radio using the preloaded UKEK, when they are received, then stored with in the radio.

There is no user input in this process, other than initiating the OTAR process. Once initiated, the re-keying process occurs with out further user input.

As I mentioned crypto is a chicken and egg thing.

Ultimately, the UKEK comes first, it will be generated by and stored in the KMF.

Then the UKEK is loaded into a KVL.

Then a radio is programmed with the radio system parameters to make the radio operate on the network. The radio also is provisioned in the KMF to be autorised to receive TEK(s) from the KMF.

Then the subscriber is connected to the KVL and the UKEK is loaded into the subscriber.

The subscriber then, by the technician, initiates OTAR, where the subscriber requests the TEK(s) from the KMF.

The KMF validates the radio, encrypts the TEK(s) using the UKEK and transmits them to the subscriber.

The subscriber receives the encrypted TEK(s), decrypts them using the UKEK and stores them in the radio.

At no point are the TEK(s) in clear text, that they can be captured so long as the key loaded device is not in physical control of someone who desires to have the key material in clear text. If a keyloaded device is lost or stolen, it can be remotely inhibited, and zeroized if it is with in the coverage of the system it is used on.

If the device is turned off, the netowrk operator can send an inhibit amd zeroize command, that will be executed if the radio registers on the network. Keys are stored in volatile memory, and can self erase if the device is with out power. The memory the keys are held in can also self erase if it detects its being tampered with as well.

Is it possible to recover keys? Yes, but the likely hood of it being accomplished is very very low.

If a device is lost or stolen, once the inhibit and zeroize command is sent, the remaining fleet can easily and quickly re-keyed. When the lost or stolen device next registers on the network, it will immediately be inhibited, and all keys erased. It will not be able to be re-keyed, until a new UKEK is loaded by physically being in possession of a authorized technician, that has the correct UKEK in a KVL, and the new UKEK is loaded into the subscriber.

 

[Project25_MASTR]

I think to add to all of this confusion there is one place where one can get items such as UKEKs, KEKs and TEKs...the interface between a KVL and the subscriber radio during the physical keyload process. So if you had a situation where a KVL were compramised you could have a very serious issues as someone being able to keyload a device such as a KFDtool could see the keys in plaintext. That however, is the only place one could get their eyes on the keys in plaintext. As it has already been covered, autokey generation can happen at the KMF (if you have one) or the KVL and no end user gets to see that key (unless they've done as already described).

Further, the KMF can not only keyload radios via OTAR but can physically keyload KVLs (via serial) or remotely keyload KVLs via Ethernet or 54k modem (as anyone who has dialed into CBP's KMF to obtain interop keys is aware of). KVLs are also capable (feature has to be enabled) of a KVL to KVL transfer but again, the plaintext of the key is never revealed during this process though it is present on the 3WI as it would be for a standard keyload operation.

 

[Echo4Thirty]

physical security is just as critical as electronic security.

 

[KevinC]

physical security is just as critical as electronic security.

And if you have a KMF the KVL should be for initial keying ONLY...unlike a certain system where the techs took KVL's in the field for TEK loading and royally screwed up a whole department....or two.

 

[Echo4Thirty]

And if you have a KMF the KVL should be for initial keying ONLY...unlike a certain system where the techs took KVL's in the field for TEK loading and royally screwed up a whole department....or two.

I wonder who that could be.

 

[kayn1n32008]

I think to add to all of this confusion there is one place where one can get items such as UKEKs, KEKs and TEKs...the interface between a KVL and the subscriber radio during the physical keyload process. So if you had a situation where a KVL were compromised you could have a very serious issues as someone being able to keyload a device such as a KFDtool could see the keys in plaintext. That however, is the only place one could get their eyes on the keys in plaintext.

This is why physical security is important, along with having an audit trail to verify who has what, when and for what purpose. Limiting physical access to a key-fill device, limiting the number of people that have access the device(s) to only those that have a legitimate need in the execution of their work. Finally, having a solid vetting process for those employees that are granted physical access to key-fill devices.

 

[mmckenna]

This is why physical security is important, along with having an audit trail to verify who has what, when and for what purpose. Limiting physical access to a key-fill device, limiting the number of people that have access the device(s) to only those that have a legitimate need in the execution of their work. Finally, having a solid vetting process for those employees that are granted physical access to key-fill devices.

And why we snicker when someone with a scanner thinks that an agency is just going to hand out keys to someone who passes a random background check.

 

[Pape]

No worries. In a P25 system, the keys are always securely stored. With in the KMF, The keys are stored in volatile memory, that is designed to detect tampering and when it does, it will erase the key material. When sending the key material over the air during re-keying, the key material is encrypted using the UKEK(a separate encryption key) prior to being transmitted.

Yes. The key is stored with in the radio in secure and volatile memory, it is also encrypted. The radio will decrypt the key to make use of it with in its own processors and RAM.

There is also a great deal of development to ensure the keys are not leaked or readable from the subscribers.

No, the UKEK is an encryption key used to convert the clear text key material to an encrypted text to be sent to the subscriber. It doesn't store anything.

That is exactly what the UKEK is used for.

Again, there are methods to detect those kinds of things, and when it is detected, the keys are erased(zeroized) to prevent the key material from being disclosed in clear text. The KVL, KMF and subscribers are designed to NOT allow keys to be read out in clear text.

Also, physical security of the devices are also a part of keeping the key material from disclosure. Minimizing the number of people that have access to the KMF, KVL and subscribers, having access control to those devices, and having an auditable access list to both the KMF and KVL(S) all make the clear text disclosure of key material as low as possible.

The radio has an encryption key to decrypt the encrypted keys.

Radios can be configured to require for code to unlock them. If the correct unlock code is not entered in a set number of tries, the keys are zeroized.

the UKEK is not a transfer device. It is an encryption key used to encrypt the TEK for transmission from a KMF to a subscriber radio.

The KMF is a part of the fixed network infrastructure. It is not physically accessed to use it, but is a part of the network. It is also in a physically secure location owned by the network owner with other fixed network infrastructure.

When the radio is updated with new TEK during OTAR, the new TEK are decrypted by the subscriber radio using the preloaded UKEK, when they are received, then stored with in the radio.

There is no user input in this process, other than initiating the OTAR process. Once initiated, the re-keying process occurs with out further user input.

Ultimately, the UKEK comes first, it will be generated by and stored in the KMF.

Then the UKEK is loaded into a KVL.

Then a radio is programmed with the radio system parameters to make the radio operate on the network. The radio also is provisioned in the KMF to be autorised to receive TEK(s) from the KMF.

Then the subscriber is connected to the KVL and the UKEK is loaded into the subscriber.

The subscriber then, by the technician, initiates OTAR, where the subscriber requests the TEK(s) from the KMF.

The KMF validates the radio, encrypts the TEK(s) using the UKEK and transmits them to the subscriber.

The subscriber receives the encrypted TEK(s), decrypts them using the UKEK and stores them in the radio.

At no point are the TEK(s) in clear text, that they can be captured so long as the key loaded device is not in physical control of someone who desires to have the key material in clear text. If a keyloaded device is lost or stolen, it can be remotely inhibited, and zeroized if it is with in the coverage of the system it is used on.

If the device is turned off, the netowrk operator can send an inhibit amd zeroize command, that will be executed if the radio registers on the network. Keys are stored in volatile memory, and can self erase if the device is with out power. The memory the keys are held in can also self erase if it detects its being tampered with as well.

Is it possible to recover keys? Yes, but the likely hood of it being accomplished is very very low.

If a device is lost or stolen, once the inhibit and zeroize command is sent, the remaining fleet can easily and quickly re-keyed. When the lost or stolen device next registers on the network, it will immediately be inhibited, and all keys erased. It will not be able to be re-keyed, until a new UKEK is loaded by physically being in possession of a authorized technician, that has the correct UKEK in a KVL, and the new UKEK is loaded into the subscriber.

So the content of the KVL, how is it secure ?
As per my understanding this is where you store the initial key that will unlock all the remaining door for full usage.
Let see if I did understand properly while you tell me if the radio loose power the original key is lost and need to reload for the radio to resume operation ?

 

[KevinC]

And why we snicker when someone with a scanner thinks that an agency is just going to hand out keys to someone who passes a random background check.

What if I have a hi-viz vest and took a CERT class?

 

[kayn1n32008]

And why we snicker when someone with a scanner thinks that an agency is just going to hand out keys to someone who passes a random background check.

Yep, nobody is in possession of key material that is in plain text. once a key is in plain text, it is compromised and of no use any longer.

 

[kayn1n32008]

What if I have a hi-viz vest and took a CERT class?

Not a chance...

 

[Pape]

Yep, nobody is in possession of key material that is in plain text. once a key is in plain text, it is compromised and of no use any longer.

That also apply to any one having the encrypted key and the unlocking material. AKA having the safe and the key to the safe

 

[kayn1n32008]

That also apply to any one having the encrypted key and the unlocking material. AKA having the safe and the key to the safe

Not even close to the same.

The UKEK and TEK are not accessible to be read out of a radio. Or out of the KVL. Or out of the KMF. To sniff the UKEK, you would need physical access to the KVL AND have the tools to access the physical wires in the KVL to radio cable and the tools to capture the data as it was transmitted. If you are not authorized to access the KVL, it isn't happening.

To access the KVL, you would need physical access to the facility the KVL is in, then you would need physical access to the area the KVL is located. That's just for the UKEK.

There would be even more layers of physical security to access the KMF.

 

[N4DES]

Just read this.... https://www.cisa.gov/sites/default/...agement%20Fact%20Sheet_FINAL_05-12-20_508.pdf

 

[Motoflightmedic]

Here is a document from the good ole days on batlabs. I did not write it but it contains some good information for you Pape. It is a little dated as it does not contain any info on the APX series or the KVL 4000 or 5000. These guys have shared some really good info as to how these modern systems handle the encryption stuff.

 

[kayn1n32008]

Just read this.... https://www.cisa.gov/sites/default/files/publications/Encryption%20Key%20Management%20Fact%20Sheet_FINAL_05-12-20_508.pdf

KFD=Key Fill Device=KVL=Key Variable Loader. 2 different names for the same device. I've used KVL in my posts, but it can be intercangeably used with KFD.

KFD should not be confused with the privately developed KFDTool and its derivatives like the KFD Mini or KFD Pico. These do not meet the requirements of FIPS, and keys are not securely stored in any form. The utilize a computer, with software and a USB interface that is in no way secure. They would NEVER be allowed to be used on a system that takes encryption seriously, they would never be allowed to be connected to a KMF.

 

[kc2asb]

And why we snicker when someone with a scanner thinks that an agency is just going to hand out keys to someone who passes a random background check.

So in a nutshell, is the discussion in the thread below mostly wishful thinking? Seems that loading a key into a consumer-grade scanner would pose a security risk.

P.S. - Feel free to snicker if my question is dumb.

Custom Firmware for Encryption

I just found this on FaceBook, after reading this, I have no idea if this is "real" or just a scam. https://github.com/x27/CFT?fbclid=IwY2xjawHhPGNleHRuA2FlbQIxMQABHVPyWam68bg-iHnPkH5Hys5QMSWDF4FNNA3DgJh8ukkNGuM1Jsg1sxhtOA_aem_M0wZMvaf2KFTRNNp0ORqig

forums.radioreference.com

 

[RFI-EMI-GUY]

What if I have a hi-viz vest and took a CERT class?

You would make a better target for a Federal Sniper...

 

[RFI-EMI-GUY]

Synopsis of FIPS-140 levels..

What is FIPS 140-2?

FIPS 140-2 is the federal information processing standard to validate effectiveness of cryptographic hardware. Products with it have been formally validated.

cpl.thalesgroup.com

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

 

[MTL_Emergencies]

So in a nutshell, is the discussion in the thread below mostly wishful thinking?

The firmware actually works on Uniden scanners. You're free to upgrade to it or remain on the official firmware.
It is designed for people who already have encryption keys and want to exploit potential on their scanners.
I would say the bigger security risk would be to use weak encryption algorithms (anything that is not AES basically)