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:

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().

[Nikos Karamolegkos]

If it is possible to make a flash address (or sector) not readable (as you propose for the root key) why not to store there the encryption/decryption key (generated by the server during production) directly in this sector and then to make this sector unreadable. It may be stupid question

[Einar Thorsrud]

You can do that. But then you can only use it up to the point where you make the flash page accessible. If that works in your use case that is no problem, but if you need access to this at a later stage it will not work.

[Nikos Karamolegkos]

Thank you again. I am not expert in security for this reason I have so many question. So your idea is based that the root key is saved in normal flash but the first stage boot loader (B0) reads it and make the flash un-readable immediately so  nobody can read the root key from this point. But with this method can you avoid: 1) that somebody can read the flash without power on the device and start the B0 (is it really a thing? -I have no idea-) so the B0 is not started to protect the root key area?  2) that the B0 will start but the malicious will have time to block (somehow) B0 to prevent protect the root key area.

Sorry for in details questions. I am not looking for the perfect solution, I just want to understand if the overhead of implementing secure credentials storing with this way worth it.