How to encrypt data before storing to flash without exposing the encryption key?

RE: How to encrypt data before storing to flash without exposing the encryption key?

ahmedwahdan — Sat, 15 Apr 2023 17:42:52 GMT

You are right. The error I got because I tried to use the bootloader example as standalone not as a sub image.

RE: How to encrypt data before storing to flash without exposing the encryption key?

Einar Thorsrud — Sat, 15 Apr 2023 14:14:12 GMT

Hi,

The flash layout is generated by the partition manager. This works out of the box unless you neeed to tailor it, though.

Regarding example, the Hardware unique key sample includes the immutable bootloader as a sub image (as it has CONFIG_SECURE_BOOT=y). So this demonstrates everything out of the box. If you need to learn more about the bootloader architecture in the nRF Connect SDK you can refer to Bootloaders and Device Firmware Updates.

RE: How to encrypt data before storing to flash without exposing the encryption key?

ahmedwahdan — Sat, 15 Apr 2023 04:23:53 GMT

I tried the example "bootloader" but it seems the slots are not defined (I'm still trying to understand the process here)

S0 and S1 are set to 0xFFFFFFFF and the example keep restarting due to accessing invalid memory address.

Should I add something to the example?

RE: How to encrypt data before storing to flash without exposing the encryption key?

ahmedwahdan — Fri, 14 Apr 2023 21:24:40 GMT

Thanks Einar.
"By letting the immutable bootloader load the key, and then prevent further read access to the flash page, the key is not accessible to the application." This can be effective for internal flash, but for external flash this wouldn't be effective, as external flash can be directly accesses(Hacked externally), right?

Any examples for implementing the immutable bootloader with the hardware unique key?

RE: How to encrypt data before storing to flash without exposing the encryption key?

Einar Thorsrud — Fri, 14 Apr 2023 12:58:37 GMT

The nRF52840 does not have a KMU, but it is possible lo push a key to cryptocell that is never exposed, but can be used to derive other keys. This will stay in volatile memory inside CrytpoCell, so it needs to be loaded at every boot, though. By letting the immutable bootloader load the key, and then prevent further read access to the flash page, the key is not accessible to the application. See the Hardware unique key sample.

With this, you can use the derived key to encrypt the data before storing to flash, and decrypt it after retreaving it. The derived key that you use to encrypt/decrypt will be accessible when you have derived it before you wipe it from memory, but the attack window is minimized.

To get a higher level of security you would need a form of security by separation, which is provided by TrustZone and TF-M in the nRF5340, for instance, but that is not possible on the nF52840.