Key Encryption Key (KEKs) about kfdtool

[duggerd]

Hi Kate,

Support for keyloading with the P25 definition of KEKs over the keyloading interface is tracked under issue #19 - I'm assuming that's what you mean.

The KFDtool hardware isn't anything more than a USB to serial converter that works with the special bidirectional keyloading interface - all the key management messages are generated on the computer in software. Only single bytes are passed over the USB interface. For ease of development and debugging, I've tried to keep as much functionality in the software as possible, and only the bare minimum in the firmware.

You would first need to port a lot of the 3WI/KMM framing code from the software (C#) side to the firmware (C) side before being able to add the 3WI KEK encapsulation to the firmware.

The security model of the KFDtool expects the host computer, adapter, and radio to be trustworthy - there really isn't a way to secure the keys through all the layers of the (KFDtool software, .NET runtime, Windows USB stack, USB host controller driver, etc) with the model of the computer generating the KMMs.

At the end of the day something has to have access to the plaintext keys, as the IVs are random per session - so without a hardened adapter (potted, tamper flex, keys in RAM and micro powered by a supercap, micro designed for crypto use, hardware rng, signed firmware updates, disabled in circuit programming interfaces, etc) it would be trivial to extract the keys by modifying the firmware. Though even then the adapter could be replaced with another with different firmware from the start that could covertly retain the keys.

I do plan on adding KEKs on the software side, as it's required for interoperability with FIPS mode enforced which requires all operations to be encapsulated with encryption. I'd honestly prefer effort be put into adding it to the software first before the firmware, as the added security isn't really much by putting it in the firmware.

Regards,

Daniel

[kategray]

Hello,

That wasn’t quite what I was talking about. I do a fair amount of work with very constrained HSMs, which have just enough memory to store a master key. They offload most of the work to the host (including storage), and decrypt the blobs provided by the host PC when needed to work with them. Generally, firmware updates require clearing all the data, which helps avoid the problem of malicious firmware.

It would absolutely require rewriting the key generation portion of the system.

The main goal would be to protect against the host computer getting infected by keeping all the plaintext keys out of it. If the computer had only encrypted key blobs, and the key was retained in the MSP430 which uses TI’s CryptoBSL, it would be very difficult for a digital-only attacker to accomplish much.

Such a s system is also useful from a department standpoint, as it makes it very easy for a tech to import or program keys, but requires relatively specialized knowledge and/or equipment to obtain the keys and disclose them to others.

[duggerd]

Ah, I see what you mean - sorry for the misunderstanding.

It looks like the CryptoBSL is only available for MSP430FR59xx and MSP430FR69xx FRAM microcontrollers, where the current KFDtool hardware uses a MSP430F5529 flash microcontroller. The FRAM devices aren't a good choice in the overall security objective as the RAM isn't cleared on powerdown automatically like the MSP430F5529 device does with traditional RAM.

The MSP430 bootloader is stored in flash memory with user code, as well as some persistent info like the KFDtool model number, hardware revision number, and serial number. However, some customization of the TI provided BSL could capture the persistent IDs, erase the entire flash, write the BSL/firmware, and then write the persistent IDs once completed. The user would have to inspect the hash of the firmware file to determine if it is trustworthy.

However, with the current hardware, either entering BSL mode through software, or through hardware still puts the device into user code from the last firmware update, which could just report it erased the old firmware where it really did not. I'm thinking a new hardware design with security in mind from the start would be needed. With this being an open source project, I'm reluctant in having a firmware signing key that's kept secret and doesn't allow anyone except from me to sign releases, so that would have to be worked around.

So you would be adding a function in the firmware to import and store a key encryption key internally. Then another function would take the plaintext key from the software, encrypt it with that key encryption key, and return the encrypted key to the software. And then on subsequent keyload operations, the software would transmit the encrypted key to the firmware, which would then decrypt it with the key encryption key, and send it out the keyload interface.

Something that would help with the amount of code needing to be rewritten is the KFDtool software could handle all the keyloading protocol, except when it would normally send the key data, it would send a command to the firmware to send the key bytes, then the software would then go back to handling the rest of the transaction.

Therefore the only new opcodes needed on the firmware side are:

1. Import key encryption key, input plaintext key, output none
2. Encrypt key, input plaintext key, output encrypted key
3. Send key, input encrypted key, output plaintext key over keyload interface

The key encryption key would still pass through the PC, so initially you would still need to trust the PC, as well as when new keys are added. Though the KEK could be generated in the firmware, as well as any new TEKs and not exported for extra security.

This would require some more work for encapsulated operations with P25 KEKs, though it could be similar but the firmware could handle the outer layer encryption in the same way.

I can see how this can help with data at rest, but once the device is activated for keyload, it has to transfer the symmetric TEK to the target device for keyload. Another KFDtool unit in MR emulation mode, or in listen only mode could capture the key. Keyload operations encapsulated in KEKs would only be safe if the monitoring unit didn't know the KEK used. However, the KEKs have to be loaded in plaintext when the radio is first put into service, so there is an opportunity to obtain them there. I suppose the person loading the KEKs would have to be completely trusted, but further loading of TEKs could be done with a unit that is technically contained to only allow TEK keyloading with a KEK. That would allow units to be issued to techs without them being able to to recover the raw TEKs, only load them into targets with KEKs already provisioned.

[kategray]

With this being an open source project, I'm reluctant in having a firmware signing key that's kept secret and doesn't allow anyone except from me to sign releases, so that would have to be worked around.

The HSMs I work with are based on the old Android unlocking security model. The device ships secure (and signed), and you are free to unlock it if you want. Doing so just wipes any stored keys. I rather like this model, as it preserves complete openness, while allowing those who want increased security to have it.