Using the cryptocell device root key on NRF5240 with Zephyr

RE: Using the cryptocell device root key on NRF5240 with Zephyr

Einar Thorsrud — Fri, 20 Dec 2019 14:05:54 GMT

Hi,

I see your point. I will forward it internally.

RE: Using the cryptocell device root key on NRF5240 with Zephyr

Barry — Thu, 19 Dec 2019 14:48:38 GMT

Ok. This is disappointing. We would like to use the Device Root Key. But if there is no way to now, then I guess that's the way it is. It seems odd to me that you would mention the device root key at all, and how to set it when there is no way to use it. It seems a little misleading. If it were me I would have at least put a statement saying that "While the Device root key can be set, use of the key is not yet implemented and is a future capability that Nordic hopes to implement at some point."

RE: Using the cryptocell device root key on NRF5240 with Zephyr

Einar Thorsrud — Thu, 19 Dec 2019 13:54:39 GMT

Hi,

I have discussed this with R&D, and the current state is simply that the API is not available. We are looking into it, but unfortunately, I do not have a timeline.

RE: Using the cryptocell device root key on NRF5240 with Zephyr

Einar Thorsrud — Tue, 17 Dec 2019 14:19:37 GMT

Hi,

I have to admit I have not looked at this using nrf_cc310_mbedcrypto for this before, so I need to check. I will get back to you with some information as soon as possible.

RE: Using the cryptocell device root key on NRF5240 with Zephyr

Barry — Fri, 13 Dec 2019 18:30:50 GMT

I see that the word at the 0x38 offset that was not equal to 1 is the word that states if the key has been added to the aes context. Ti only gets set if you do a function like mbedtls_aes_setkey_dec() which sets the word I mentioned and adds the key to the second 16 bytes of the aes context.

So it seems like you need to have a function that can add the device root key (Kdr) to a aes context. Although maybe that isn't possible if the key cannot be read from the cryptocell.

In that case I guess you would need to implement an aes function that does not go through mbedtls. Because mbed tls does not have any functions that don't require there to be a key in the context.

Or you have to create an aes function that does not require there to be a key in the context, and then somehow amends the context with the key in the cryptocell.

in cc_aes_defs.h you have and enum CCAesKeyType_t that seems like its sole purpose would be to pass the key type to some aes function that would be able to handle this scenario. But it is not used anywhere that I can see.