TLS credentials secure storing to nrf52840-dk

[Nikos Karamolegkos]

Hello everybody, I am using Zephyr with the nrf52840-dk device. I would like to store the DTLS credentials with a secure way. I don't want to be part of the code and thus to be written raw in flash. Any proposals?

[Einar Thorsrud]

Hi,

The nRF52840 does not have secure flash or a KMU, so you have to store your key in normal flash. You could potentially protect the data using ACL so that it can only be accessed by code running in a specific region (typically in a bootloader, though I am not sure if that makes sense in your use case). You should also protect the flash using APPROTECT so that it cannot be read using a debugger, but then you should be aware of IN-133. Another alternative if you have very high security requirements is to use an external secure element that holds your credentials and handles any crypto operations involving it. That would obviously increase your BOM, though.

[Nikos Karamolegkos]

I can not have an external secure element. Is there any example on how use ACL? I am using zephyr but I can not find something relative. Thus, I have to find something from the nrf SDK or nrf5 SDK and then to integrate in Zephyr. Correct? For this reason a need an example and/or a guideline. Also, could I have two specific region which can have access? (with the bootloader logic I have somehow to "announce" the credentials to the APP partition). Finally, what difference has the ACL with the APPROTECT register? Is there any example using the APPROTECT?

Thank you for the detailed answer

[Einar Thorsrud]

Hi,

Nikos Karamolegkos said:

Is there any example on how use ACL? I am using zephyr but I can not find something relative

You can use the fprotect_area() function. There are a few examples where it is used in nRF Connect SDK.

Nikos Karamolegkos said:

Also, could I have two specific region which can have access? (with the bootloader logic I have somehow to "announce" the credentials to the APP partition).

Yes, you can have multiple regions. But this does not work as I suspect you hope. The ACL will effectively block reading (if that is how it is configured) from the specified region after it is enabled. See ACL for details about how ACL itself works.

Nikos Karamolegkos said:

Finally, what difference has the ACL with the APPROTECT register?

ACL blocks access to parts of the memory from the CPU. APPROTECT blocks debugger access. So they are quite different, though both are features for restricting access to the flash in some way.

Nikos Karamolegkos said:

Is there any example using the APPROTECT?

Yes. With the current nRF devices that is just a matter of writing to the APPROTECT register in UICR during programming. So it does not really have any implications for your firmware itself.

There is one possibility which I did not mention before that you could use to protect your certificate somewhat. You could use a device root key which you provision the CC310 with during boot, and then lock the flash page holding the key using ACL in the bootloader (after provisioning CC310). Then you could use a derived key to decrypt the certificate (which has been encrypted using the derived key during production). See nrf_cc3xx_platform_kmu.h for more. Unfortunately there is no example of this at this point.

[Nikos Karamolegkos]

I am not sure that I understand. Could you explain more why to sections for the ACL is problem? Also, about the device root key idea can you explain more? What is the derived key and how this helps?

[Einar Thorsrud]

Hi,

Nikos Karamolegkos said:

Could you explain more why to sections for the ACL is problem?

Maybe I was unclear. Using multiple sections is not a problem. But You will not be able to read a section (from anywhere) after it is locked. So I am not sure that is what you want?

Nikos Karamolegkos said:

about the device root key idea can you explain more? What is the derived key and how this helps?

Using a device root key gives you a possibility to protect your DTLS credentials in the way that you do not need to store them in raw flash, as you asked for in the original question. But that is not straight-forward, and it is not perfect.

Let me explain the root key idea in more general terms first. The CC310 supports a root key which can be inserted at startup, and held in secure RAM until reset. Then you can subsequently use that to derive keys that you use for crypto operations. So you could do something like this:

1. In the bootloader, insert the root key in CC310. Then lock access to the flash page holding the root key so that it can no longer be read (until next reset, and then the bootloader does the same thing).
2. In your code you can derive a key from the root key. During production you use that to encrypt the DTLS credentials and store them encrypted.
3. In the field you can decrypt the DTLS credentials using the derived key.

As you see from above, the DTLS credentials would not be stored in cleartext in flash. However, the key that is used to encrypt it must be. It could provide a bit more security, and is the best you can do using only the nRF52840 and no other HW.

[Nikos Karamolegkos]

Thank you for the detailed answer again. I understood. Therefore, the derived key will be always the some given the same root key? How can I create the root and thus the derived key? (any examples). Finally, the bootloader is it secure in order to handle all this process? (e.g MCUboot)

[Einar Thorsrud]

Hi,

Nikos Karamolegkos said:

Therefore, the derived key will be always the some given the same root key?

Yes, that is correct.

Nikos Karamolegkos said:

How can I create the root and thus the derived key?

How to create the key is up to you. You could create it on the nRF using the CC310 RND during production. Then load that key into CC310 and derive a key, which you use to encrypt your secret data. As mentioned you must keep the root key in normal flash and should protect it early during boot to prevent application code from reading it.,

There are currently no code examples for this, but the functionality you need was introduced in NCS 1.4. Specifically:

• Use nrf_cc3xx_platform_kdr_load_key() to load the root key in CC310 at every boot.
• Use mbedtls_shadow_key_derive() to obtain the derived key that you use to encrypt/decrypt the data
  • You should make sure to memset the RAM holding the key immediately after use to reduce the attack surface.

Nikos Karamolegkos said:

Finally, the bootloader is it secure in order to handle all this process? (e.g MCUboot)

You could use an tiny immutable bootloader that runs before MCUBoot to handle this (this example immutable bootloader does not do this, but you can use it and add this part). That is the same approach that is used in secure boot. Then you can keep the key in the bootloader page. This B0 bootloader would then essentially do nothing other than loading the KDR key to CC310, preventing read access to itself and starting MCUBoot.

[Nikos Karamolegkos]

Nice, therefore after statring the MCUboot using mbedtls_shadow_key_derive I can take the derived key and decrypt the DTLS credentials. Correct? Also, I assume that I can do the same procedure from to derive the key from the APP partition in order to use the dtls credentials from this section. Is that true?

[Einar Thorsrud]

Yes, that is correct.

[Nikos Karamolegkos]

Hello, again. One more question. This scheme is secure because nobody knows the root key so he can not do the same procedure in order to find the derived key. Correct?

[Einar Thorsrud]

Hi,

It is difficult to say that something is secure, as there will always be limitations (and certainly are in this case). But it will be more secure. But it still remains a fact that the nRF52840 does not have secure flash nor a KMU, so your root key needs to stay in normal flash. There is no way around it. If the security is good enough of not depends on your requirements.

I should also add that with NCS 1.4 you also got the possibility to use derived keys directly in CC310, without actually exposing the derived key in normal RAM. You could do that by using e.g. mbedtls_aes_setkey_enc_shadow_key_derived() to use a derived key based on the root key you loaded with nrf_cc3xx_platform_kdr_load_key().