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

[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.

[Einar Thorsrud]

Hi,

Nikos Karamolegkos said:

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?

No, you cannot. The nRF52840 is not a hardened device. For instance, If you get debug access in some manner, you can dump the entire flash. 

Nikos Karamolegkos said:

2) that the B0 will start but the malicious will have time to block (somehow) B0 to prevent protect the root key area.

B0 is by nature the first FW that runs, so nothing else should be able to do that. And the B0 should write protect itself using ACL before starting the next stage bootloader or app, so that it cannot be modified.

[Nikos Karamolegkos]

Einar Thorsrud said:

not started to protect the root key area?

No, you cannot. The nRF52840 is not a hardened device. For instance, If you get debug access in some manner, you can dump the entire flash. 

So it is possible somebody to read the flash without power on the device? For the debug access as you suggest I can prevent it using the APPROTECT register.

[Einar Thorsrud]

Hi,

Nikos Karamolegkos said:

So it is possible somebody to read the flash without power on the device?

Not without decapping and probing it. And that is a destructive operation, so as long as you use unique credentials for each device, then this is no practical problem.