Help with security for Ethernet application: secure certificate storage etc on nRF52840

[Glen M]

Hi,

Now that I've got my board with an external MAC/phy working with my nRF52840 to do a TLS-secure http_get from google.com, I'm trying to learn about how to do proper security for my IoT device.

I need to figure out how to load (and in the future, update) certificates to my device and store them securely - preferably with EC encryption, and just in general I could use a lesson on how security works with embedded devices these days. What happens when a certificate expires - does every user have to figure out how to hook up a terminal program and put on new certificates, or is there some way to update them remotely via some kind of bootload? I'm afraid I don't even know what questions to ask. I'm an experienced embedded developer but security stuff like this just hasn't come up much until now.

It looks like the nRF52840 does not have a KMU. I did find a graphic in the nRF52840 datasheet v1.7 (Figure 44: Block diagram for CRYPTOCELL) that shows a CRYPTOCELL library interface to the flash - maybe there's a secure way to store things in an encrypted way via CRYPTOCELL?

I'd appreciate both general info about security in IoT devices and specific help with my hardware/application if possible.

Thanks!

Glen

[Sigurd Hellesvik]

Hi Glen,

Short answer: As far as I know, when using TLS for the nRF52840, TLS Certificates are usually stored in normal unencrypted flash.

Long answer:

What happens when a certificate expires - does every user have to figure out how to hook up a terminal program and put on new certificates, or is there some way to update them remotely via some kind of bootload?

I have queried our developers to find out if we have any docs to describe updating certificates.
In the meantime, here is how I think it works:

You can download certificates from the internet. You will have to download the next certificate before the old one expires, as you need a certificate to access the internet securely.

As far as I know, downloading certificates would not be handled in any special way. For example, using HTTPS.
Since you use TLS when downloading the new certificate, it is already encrypted when sent.
If you need more security to this, you can always use symmetric encryption to encrypt the data before sending the cert. This would mean that you need to have either:

1. Store the same key for symmetric encryption on all. I would not recommend having the same key on all devices.
2. Have a cloud backend to keep track of all devices and their specific symmetric keys. Could be done for a few devices, but does probably not scale well.

Keep in mind that these solutions will increase the complexity of your application.

or is there some way to update them remotely via some kind of bootload?

Now that the certificates have been sent to the device, they must be written to the correct location.
This writing method really depends on where the certs are stored:

• For the nRF9160, AT CMNG is used to write certificates.
• If the certs are stored in normal flash on an nRF52840, they would be written using flash write.
  
  • If the flash for the certificates is locked using the ACL, the bootloader probably must have some writing mechanism to write new certs before locking the flash.

In other words: As far as I know, you have to implement a certificate update procedure yourself.

It looks like the nRF52840 does not have a KMU. I did find a graphic in the nRF52840 datasheet v1.7 (Figure 44: Block diagram for CRYPTOCELL) that shows a CRYPTOCELL library interface to the flash - maybe there's a secure way to store things in an encrypted way via CRYPTOCELL?

It is possible to store the certificates encrypted, yes.
CryptoCell has a Device Root Key which the application can not access, which can be used as an encryption key for the certificates in storage.

When it comes to the nRF52840 and TLS, the first thing to notice is that while the CryptoCell peripheral supports different cyphers, it does not have full TLS support in itself.
This means that parts of the TLS protocol have to be handled by the application.

Since the TLS protocol has to be handled by the application, the data TLS needs must be in the stack or heap.
So no matter what security you add to certificate storage, the certs will have to be on the stack or heap at some time.
It is still safer to have this data in the stack or heap for a limited time when used than in flash at all times.

For reference: The nRF9160 has a modem. This modem has its own TLS driver and certificate storage inside, making TLS separate from the application.
Also for reference: The nRF5340 has Trusted Firmware-M, where you can run TLS inside the SPE, making it safer.
None of these references is what you ask for, but I figure it is good to know about for a full picture.

All that being said:

When you design your application, you will make sure that your application is as secure as possible, for example, with features such as Access port protection.
It can be an option to trust that the nRF52840 is secure enough as is.
In general, the certificates on your nRF chip should be unique per device, making it so that if one of your devices becomes compromised, it only affects that device.

If you need even more security than this, I know there exist secure elements with support for TLS which you can connect to the nRF chip to store certificates and do TLS communication.
I can not recommend any specific, and I do not think we have any example for these.

This was a lot of text, but I hope that it provided some clarity on the subject.
Let me know if you have any questions.

I will ask some of our security experts to have a quick look at what I wrote to make sure I am not wrong on anything, so stay tuned for an update on this in ca a week.

Regards,
Sigurd Hellesvik

[Glen M]

Thanks for the detailed response, Sigurd - we'll discuss the best path forward and look for any updates you might post

[Sigurd Hellesvik]

Hi, again Glen,

I heard back from our experts on this, and I realize that in my answer I have assumed that your device will act as both a Server and a Client.

To give you a bit more accurate information:
Will your device only act as a client, or server also?

Regards,
Sigurd Hellesvik

[Glen M]

My device will just be a client.

[Sigurd Hellesvik]

In that case, you do not have a private device-specific certificate to protect.
The main goal is to prevent the certificate from being overwritten or changed.

To quote our security expert on this:

"We have ACL-protectable flash storage on the nRF52840. I would just put the certificates in regular flash (together with the firmware code), and updating it by a firmware upgrade before it expires. If it part of the code image (not generic data storage), you would have the additional assurance that the certificate isn't erased. You will also be sure that only valid new certificates are introduced to the device based on the signature validation of the firmware upgrade, and that is already 'built in'. This means you don't need to do a protocol addition for the updates, which might be very convenient for the end-customer "

Does this make sense?

Regards,
Sigurd Hellesvik