Saving root key on battery powered devices

[bperrin2]

Hi,

On battery powered devices, how is it possible to retain a root key when changing batteries? 

The crypto cell has an Always On power domain for retaining device secrets but it seems to work when crypto cell is disabled for power saving reasons. However, it doesn’t seems to retain keys when not powered. Or are the keys stored in flash zone only readable by the crypto cell?

If not what will be the proposed solution by Nordic?

Thanks in advance for your support.

Bernard

[Einar Thorsrud]

Hi,

You cannot retain the root key within CryptoCell, and the nRF52840 does not have any secure flash, so you have to store it in (normal) flash. You are still able to keep the key in a reasonably secure manner using something like the following strategy:

• Store the key in a reserved flash region.
• Enable read-back protection using Control access port. This prevents a debugger from accessing the flash (the only way to disable it is to first do a full chip erase).
• In the bootloader:
  • Read the key from flash and copy it to CryptoCell (secure always on RAM).
  • Enable ACL to protect the key so that it cannot be accessed by the application.

The above procedure should keep the root key safe against most kinds of attacks, but it does not provide protection against decapping. If you need that, then the only option is to use an additional device, such as for example the OPTIGA Trust X instead.

[bperrin2]

Thank you for your clear answer.

If we consider decapping as a possible attack: is the solution to have an extra chip safe? I guess it will be possible to sniff the communication lines between the Infineon and the nRF chips when it try to get the master key. The exchange could be encrypted with a key but this will require to store this key somewhere starting with a chicken and egg problem. Am i wrong?

I have another question concerning the JTAG: is it possible to connect / disconnect it by software. For example, we would like to have it disconnected by default and reconnected when a demand is done by the smart device via a secure connection (with a second level of security above BLE). This could be required for example during maintenance operations.

If this is possible, I would be very happy to get a pointer to a coding example.

Bernard

[Einar Thorsrud]

Hi,

The point with using the OPTIGA Trust X in this case is that it provides secure key storage. You can only write keys to the Trust X, never read it back. The key is safe there and is never communicated to the nRF52840. Instead, any data that needs to be encrypted or decrypted must be sent back and forth to the Trust X, as this has the key(s).

You cannot activate the debug interface from firmware once it has been deactivated. The only way is to do a full chip erase (see Control access port). (Note that the nRF device only has SWD, not JTAG).

[DamianV]

Hi Einar,

I am following this post and I am trying to understand the situation:

Wouldn't this make the Cryptocell inside the nRF52840 obsolete? Because it seems that if use the OPTIGA Trust X to store the keys, all crypto operations will have to be done within it, right?

Thanks in advance

Damian

[Einar Thorsrud]

Hi Damian,

Yes, you are right. Crypto operations using a key stored within the OPTIGA Trust X has to be handled by the Trust X. You could of course use the CryptoCell for other operations as it may be faster in some cases, but generally CryptoCell is not an important feature if you anyway use a OPTIGA Trust X. However, CryptoCell can be very useful in other situations, and I would argue that the security level you can get using only a nRF52840 is good enough for most applications.