Usage of KMU and CC3XX drivers

[pbornerup]

Hi! 

Were are looking to use it for CMAC and AES which should be supported by the CC310 according to https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fcryptocell.html 

Directly use of the KMU for AES is supported through mbedtls_aes_setkey_enc_shadow_key(..). But you can't do much more that that.    

I'm aware this is supported through the psa_crypto APIs, but it does come with some pretty heavy downsides imo.

With PSA crypto:

We are importing a key that should be static throughout the life-time of the device: 

• Importing keys with PSA_KEY_PERSISTENCE_READ_ONLY returns a NOT_SUPPORTED 
• Importing with PSA_KEY_LIFETIME_PERSISTENT works but keys can be destroyed. 
• Unless you get the config just right it just throws an error.
• TF-M can't be pinned to a minimal config. 

While psa_crypto is awesome in many cases I think that some use-cases calls for different crypto APIs. 

- Importing keys requires an ITS partition. I.e. 32kB is currently wasted to store 64bytes worth of keys. 

- Persistent keys cannot be used with the KMU. Or at least they aren't stored in the KMU it seems. Why not just use the KMU as it is designed for this purpose?

- From this post: https://devzone.nordicsemi.com/f/nordic-q-a/100616/using-psa-function-to-persist-key-in-kmu-and-later-restore-it-for-aes-encryption   it was highlighted that CONFIG_TFM_ITS_ENCRYPTED=y was needed to store the keys encrypted. 

In general:

• Any chance that more extended CC3XX drivers will be published? With support for more direct cryptographic operations?  

If no to above:

1. Is CONFIG_TFM_ITS_ENCRYPTED=y still needed?
2. Can PSA Crypto be configured to store PSA_KEY_PERSISTENCE_READ_ONLY in the KMU so we can omit the ITS partition? 
   
3. Can we set keys with nrf_cc3xx_platform_kmu_write_key(...) and reference them later w. psa_crypto APIs?
4. Can the storage backend for psa_import_key(...) be customized? 

 

[ovrebekk]

Hi Peter

I got some input from the crypto experts, and will try to condense their feedback below:

CMAC: 
PSA currently doesn't support CMAC based key derivation. This functionality must be added before we can add PSA crypto drivers for it and give API support:
https://github.com/ARM-software/psa-api/issues/106

This functionality is being worked on both by us and by ARM, but unfortunately it is too early to make any estimates regarding when it is ready. 

AES: 
For the use- case of a KMU key from a PSA driver this lacks a special type of drivers, called "opaque" drivers. There are plans to add this as well, but unfortunately it is not under active development yet. 

The same type of driver support is expected for CMA usage, so once CMAS is supported adding support for AES should be straight forward. 

Missing official support it is possible to build something yourself on top of the nrf_cc3xx_platform library, but this is obviously more work. Below is some more technical input from the experts:

PSA Crypto APIs and drivers available in the current solution expects "transparent keys", which means that they expect the keys to be stored and retrieved through PSA ITS if they are persistently stored. The drivers are called Transparent PSA Crypto drivers for this reason

When you implement an "opaque driver", you actually decide how storage is done. It would be able to do an "import"-operation that is called into an Opaque PSA Crypto Driver, which would execute the call to store the key to the KMU.

In this case ITS doesn't need to be enabled.

Some caveats apply:
- KMU is "write once". You can only erase a key, you won't get the KMU slot back. If you have spent all your slots, you don't have room for more keys
- We only support encrypting 128 bits material (32 bytes)
- There needs to be an MKEK provisioned on the device for the key encryption mechanism
- We only have support for legacy Mbed TLS APIs (mbedtls_ prefixed) for the actual encryption/decryption CMAC etc. So if the you really want to go down this route, you would need to make opaque drivers for AES (cipher and AEAD, if used)

More information about the PSA crypto drivers here. In particular, look for the sections related to opaque drivers. 

Best regards
Torbjørn

[pbornerup]

Thanks! 

Seems like there will be some work to do .. 

As a follow up I looked into the nrf_cc3xx driver in NCS. 

I can more or less do everything I wan't using more low-level driver. 

I.e. nrf_cc3xx_platform_kmu_write_key / mbedtls_aes_setkey_enc_shadow_key / mbedtls_aes_encrypt to do low-ish level operations - just for context we only need 128 bit AES keys, AES-CBC mode. That seems very possible with the existing driver - and we would be able to use the KMU for key-storage.  

Keys are persistent for the lifetime of the device and will only take up 3 slots. 

Basically, we can get 90% of the way already. 

But, I don't think the cc310 driver are anywhere to be found in case we wanted to add additional functionality. I.e. we need to calculate a MAC of some messages (CMAC) using one of the keys in the KMU. Should be supported by the hardware, but I don't see an obvious way to access the functionality. 

Guess we could make a work-around with a derived encryption key and store the key for CMAC somewhere else.. 

[ovrebekk]

Hi 

Unfortunately this is not supported at the moment. There are plans  for both KMU based CMAC support and cipher/AEAD using PSA crypto (opaque) driver support as previously mentioned, but it is too early to provide a schedule for when this might be ready as it is not at the top of the list of priorities. 

You could always keep the CMAC key encrypted in KMU and then decrypt it to regular RAM to make use of it with regular API's, but to an extent this defeats the purpose of using the KMU in the first place. 

Best regards
Torbjørn