Sometimes I like to research ahead of my progress, about the things which will be my pain-point in the future.
I am curious on you experience or knowledge about the Firmware protection.
E.g., for the nrfg52840, we know there’s an APProtect mechanism to secure your application on the nrf52840 SOC from a read-back. There’s quite some documentation on that to explore, but more or less it is clear.
However, how to protect your firmware, while it is, let’s say, stored on the device, in case when the DFU OTA happens from the mobile phone? And here I am not talking about secure and encrypted transfer of the firmware over bluetooth, but about a physical HEX file being stored on the device before it is transferred to the nrf52840 SOC.
Because a malicious actor can just hack your IOS/Android/Windows/MacOs application, or not even hack, but simply find the firmware stored in the application files and copy it.
So, how is the firmware being protected in such cases? Is it possible to use some encryption on the firmware, so no-one can read it and then have the decryption on the nrf52840, so it is possible to install it by the SOC?
I surprised You ask this here but I’ll give you my experience and understanding of it, Take what you will from it and my background and experience. (link in the profile description) LOL , always wanted to say that!
Anyway…
Yes, the nRF52840 can securely store encrypted firmware received via OTA DFU, and decrypt it only within the SOC itself, ensuring full protection even if the file is extracted from a mobile phone or computer. The combination of APPROTECT, Secure Bootloader, Encryption APIs, and Signature Verification makes the nRF52840 a very robust and secure platform.
They demonstrate it on there live stream and in the dev academy course (free workshops), along with the Multi-slot DFU which in it’s self is ridiculously cool, if it fails or crashes It automatically loads and reboots to the old working slot image…WOW!
When it comes to protecting firmware during the OTA DFU process, Nordic Semiconductor has implemented several mechanisms to ensure security during transfer, storage, and application of firmware.
1. APProtect & Secure Boot
APProtect is indeed effective for securing the firmware against read-back from the nRF52840 itself.
When enabled, it prevents unauthorized access to the internal flash memory via the SWD interface.
It’s part of the Access Port Protection (APPROTECT) mechanism which is a hardware feature.
(note worthy: it has been revised, due to some early break in issue found) I think twice Now?
2. Firmware Encryption & Secure DFU
Nordic provides a Secure DFU Bootloader which is part of the nRF5 SDK (Legacy) and also integrated into the nRF Connect SDK (Zephyr-based).
End-to-End Encryption: While you mentioned you are not talking about encrypted transfer, it’s worth mentioning that Nordic’s Secure DFU implements AES-128 encryption during transfer to protect against eavesdropping.
Firmware Integrity Verification:
Uses Elliptic Curve Digital Signature Algorithm (ECDSA) to ensure that only authenticated firmware is installed.
Prevents tampering or man-in-the-middle attacks during DFU.
On-Device Decryption:
If you’re worried about a malicious actor getting the firmware file from a smartphone or computer, it can indeed be encrypted before being transferred to the nRF52840.
The nRF52840 will decrypt the firmware on-device using a pre-shared key or a key derived from a secure boot process.
3. Storing Encrypted Firmware
Storing the firmware encrypted on the phone or other device and only decrypting it on the nRF52840 itself is very much possible and practical.
This approach ensures that even if the firmware file is stolen from the device’s file system, it remains useless without the decryption key which is securely stored on the nRF52840.
I must say too, Unless you have something SO amazing software/firmware wise, even better also to have the proper legal documentation in place by way of copyright & patents,etc. as to Dissuade would be hackers to not bother. But do lock the door and NOT make it easy at least.
Yeah, this is great, thank you! That’s why I’ve posted it here. I was searching the internet and couldn’t find some solid info.
Even the Nordic Dev Zone, is unfortunately has 2 problems:
they are addressing a specific case of each customer
it still has a lot of legacy things, e.g. all the encryption-related topics were around the Legacy SDK
Though, one of the Developer’s posts was mentioning, that unfortunately, for nrf52840, Nordic can’t guarantee the key can’t be stolen from the device. I understand, that the key is not completely secured there on the Chip and is stored in a non-protected area (if I understood it correctly).
On the Keys though:
Do I understand correctly, that it is possible to either:
Store a key in the bootloader (?), which will never be removed during the DFU and therefore the device will always be able to decrypt the firmware
Send the key with the firmware somehow? But then how will the key itself be decrypted? I think I am confused with the " key derived from a secure boot process" phrase.
Hi there,
so I think you are a little confused about how key management and decryption actually work on the nRF52840, so let’s make it ** clear**.
1. Key Storage & Protection on the nRF52840 (Yes, It’s Secure)
The nRF52840 has a built-in Cryptocell-310 hardware-accelerated cryptographic engine, which is capable of securely handling keys and performing encryption/decryption operations.
Now, let’s address the concern:
Keys CAN be protected:
The key used for decryption is NOT stored in a non-protected area.
Nordic’s Cryptocell-310 supports secure key handling using the KMU (Key Management Unit) when configured properly.
By using Secure Boot and Trusted Execution Environments (TEE), keys can be protected from unauthorized access even if someone tries to extract them via physical means.
2. Key Management & Bootloader Handling
Your mixing up concepts here, so let’s untangle them.
Option 1: Key Stored in the Bootloader (Persistent Key Storage)
The key can be embedded in the Secure Bootloader’s code (as a constant) or retrieved from a protected region.
Because Secure DFU uses ECDSA (Elliptic Curve Digital Signature Algorithm), the integrity and authenticity of the firmware are verified before decryption.
Option 2: Key Derived From Secure Boot Process (More Secure)
During the boot process, a key can be derived using device-specific unique identifiers (e.g., FICR - Factory Information Configuration Registers) and a cryptographic key derivation function (KDF). This works and is very effective as a basic tech because each one is unique I used it in some posted code to get the Unique BLE iD and derive the MAC address.
This derived key is not directly stored on the chip but instead generated at runtime using hardware-locked information that cannot be read out via SWD or any external means.
This process ensures that even if someone gets physical access to the device, they cannot obtain the key without breaking the hardware security features of the nRF52840.
3. Why Nordic’s Secure DFU is Safe From your concerens
the complaint about the key not being safe is only valid if:
The firmware developer fails to implement Secure Boot correctly.
The developer does not use the Cryptocell-310 hardware features.
The nRF52840 is fully capable of protecting firmware decryption keys if the developer uses the Cryptocell-310 hardware and Secure Boot properly. Whether the key is hardcoded, stored securely, or derived dynamically during the boot process, the mechanism is robust and follows modern security standards.
So here is a 10,000 foot view of the process, I’m currently working through step 3 on BootLoader and will post the results for others to use on a Xiao also.
It fits under this title, However some of it will fly Above the basic realm.
Also worth noting; what works on the DEV boards works on the actual SOC too.
How to Implement Key Protection Properly on the nRF52840
This approach will cover the following:
Generating & Storing Keys Securely
Using Cryptocell-310 for Key Management
Implementing Secure Boot & DFU
Best Practices for Key Handling & Encryption
1. Generating & Storing Keys Securely
You have two main approaches to consider:
Approach A: Static Key (Simpler but Less Secure)
Store a pre-shared key (PSK) in a secure region of the bootloader.
The key is embedded in the bootloader’s code, compiled and flashed as part of the bootloader image.
Good for quick prototyping, but vulnerable if someone can dump the flash memory.
Approach B: Derived Key (Recommended)
Use the Cryptocell-310 hardware to derive keys from device-unique data (e.g., FICR - Factory Information Configuration Registers).
This key never exists as plaintext in the flash but is dynamically generated during the boot process.
You can use the KMU (Key Management Unit) for additional protection.
2. Using Cryptocell-310 for Key Management
The Cryptocell-310 offers hardware-accelerated AES, ECC, SHA-2, and True Random Number Generation (TRNG).
How to Derive a Key Securely:
Read FICR (Factory Information Configuration Registers) — these are device-unique and immutable.
Combine this data with a salt value using a Key Derivation Function (KDF) like HKDF (HMAC-based Key Derivation Function).
Use AES-128 or AES-256 hardware encryption for the decryption process of firmware.
Example Code (Key Derivation):
#include <nrfx.h>
#include <nrf_cc310.h>
#include <nrf_cc310_bl_ecdsa_verify.h>
#include <nrf_cc310_bl_hash.h>
#include <nrf_cc310_bl_keygen.h>
// Example function to derive a key using device-specific data
void derive_secure_key(uint8_t *output_key, size_t key_size)
{
uint8_t unique_id[16]; // 128-bit unique ID
memcpy(unique_id, (const void*)NRF_FICR->DEVICEID, sizeof(unique_id));
uint8_t salt[] = "YourUniqueSaltValue"; // Custom salt value for added security
// Example key derivation (using HMAC or AES depending on requirements)
nrf_cc310_bl_hash_context_sha256_t hash_context;
nrf_cc310_bl_hash_init(&hash_context);
nrf_cc310_bl_hash_update(&hash_context, unique_id, sizeof(unique_id));
nrf_cc310_bl_hash_update(&hash_context, salt, sizeof(salt));
nrf_cc310_bl_hash_finalize(&hash_context, output_key, key_size);
}
3. Implementing Secure Boot & DFU
The nRF52840 Secure DFU Bootloader with MCUboot is the best approach for secure firmware updates.
Steps to Implement Secure Boot & DFU:
Set up Secure Boot (MCUboot):
Build MCUboot separately with your nRF Connect SDK setup.
Configure your bootloader to expect a signed, encrypted image.
Enable Key Management in MCUboot Configuration (prj.conf file):
The firmware is being encrypted on my PC, for example, using the Private-Key which I store handy.
Then, the nrf52840 will derive its own secure key based on its internal secure algorithms, its own DeviceId and my Salt
Questions raised in my head:
Where is the link between the Private Key on the PC and the Secure Key on the Device? Is it the Salt? Is it ONLY the salt? Otherwise it looks like ANY nrf52840 SOC can generate its own secure key to decrypt any encrypted firmware. But I believe I am mistaken here, as it means that anyone with nrf52840 can run anyone’s secured firmware
Since the DeviceId is unique for each and every nrf52840 SOC, do I understand, that the unique Id used in the secure key generation just as a “random” constant for making the secure key more robust, rather than for “sticking” the firmware update for that device only? What I mean, is that for the same purpose we could use the nrf Macro for creation of the Unique UUIDs, for example. It shouldn’t be the same every time, but it should be unique, correct?
P.S. I will have the next 3 weeks available for this exercise with my freshly arrived nRF52840 USB dongle. I hope I will be able to post some results here.
And thanks again, your posts is a huge ramp up for me in grasping the basic understanding, before I deep dive into the tech documentation. I already have the things being structured in my mind
Yes the Dongle is a cheap way in for sure , probably the one thing I use the most. The swiss army knife of Nordics BLE
The link between the Private Key on the PC and the Secure Key on the Device is established through the process of Key Derivation and Secure Bootstrapping. Here’s how it works:
Firmware Encryption Process (PC Side):
The firmware is encrypted using a Private Key on the PC.
This key is part of an asymmetric key pair or a symmetric key generated and managed by the firmware developer.
Key Storage on nRF52840 (Device Side):
The nRF52840 stores a Device-Specific Secure Key which is kept securely in flash memory.
This key is used to decrypt incoming firmware updates.
How Keys are Linked:
The encrypted firmware contains metadata, including a signature or checksum, validated using a pre-shared key or derived key.
During the decryption process, the nRF52840 uses its internal key to validate and decrypt the firmware.
A common method is to use a Salt (or Nonce) combined with a Secure Boot Key stored on the device to derive a session key for decryption.
This ensures only the target device with the correct key can decrypt the firmware, even if the firmware file is intercepted or copied.
Why This Assumption is Wrong:
Not ANY nRF52840 SOC can decrypt the firmware.
Firmware decryption depends on a unique key or a derivation process that only the intended nRF52840 device knows.
If the firmware was encrypted with a key specific to a device (via a unique device ID or similar mechanism), only that device can decrypt it successfully.
Recommendation for Further Reading:
Nordic Semiconductor’s Secure DFU Bootloader Documentation (if he needs even more details).
Also, reading about the “MCUboot” process and how keys are protected in flash would be helpful.
I can tell you it is a process… I don’t have it all working yet but I’m knocking on the door of success. MCUBoot is the end game to help deliver on " OTA DFU with crash proof upgrading "
GL PJ
The concept of using a simple “Salt” as a standalone protection measure went away long ago in modern cryptographic processes.
What’s Happening Now?
Salt by Itself Is Weak:
Originally, a Salt was just a random value added to the password or key to make brute-force attacks harder.
It was mainly useful against rainbow table attacks on hashed passwords.
Modern Systems Use Stronger Techniques:
Systems now use Key Derivation Functions (KDFs) like PBKDF2, Argon2, HKDF, etc. which include Salt as part of the derivation process but not as a sole protective measure.
These KDFs generate keys from passwords, private keys, or device-specific secrets, ensuring robustness against brute-force attacks.
Secure Boot & Encryption (nRF52840):
When dealing with firmware protection, the Secure Boot process involves validating the firmware using a public-private key pair or a device-specific symmetric key.
Even when Salt or Nonce values are used, they are combined with device-specific keys or pre-shared secrets making them unique to the device and session.
Key Point:
The real protection comes from how the keys are derived, stored, and used, particularly through Secure Boot and Encrypted Firmware Updates.
So, omitting specific language, as I understand now, there will be a specific secure key, that will be generated on PC and used for future firmware encryption. And the same secure key will be initially shared to the device as part of the Secure Bootloader, so the SOC is able to decrypt future firmware updates.
And if the same key is used for 100 devices, all of these 100 devices will be able to receive a secure firmware. Did I get it?
Yes, you’re on the right track! The Secure Bootloader is pre-programmed with the key (or derived key) that matches the one used to encrypt the firmware on the PC. So, when the firmware update is sent to the device, the bootloader can decrypt it.
But let’s clarify one thing:
Yes, if the same key is used across 100 devices, all those devices will be able to decrypt the firmware.
However, a more secure approach is to use a unique key for each device (Device-specific keys). This can be achieved using a Device Unique Key (DUK) that is derived from a master key and a device-specific identifier.
Nordic’s nRF52840 supports mechanisms to secure keys in protected areas, and you can implement solutions where the key is only accessible by the bootloader.
For the best security, you would:
Provision each device with its own unique key during manufacturing. there are flash locations you can have pre programmed, or do it with your own algorithms.
Use a key derivation process to generate per-device keys if using a shared master key.
Implement Secure Boot to ensure firmware authenticity and integrity.
I’ll post an MCUBoot Image soon for Xiao and folks can play with different methods of DFU and Security levels.
1. APProtect & Secure Boot
2. Firmware Encryption & Secure DFU
3. Storing Encrypted Firmware
4. Tools & Documentation for Further Reading
nRF Connect SDK Documentation - Secure Bootloader & DFU
PJ 
Option 1: Key Stored in the Bootloader (Persistent Key Storage)
3. Why Nordic’s Secure DFU is Safe From your concerens
You’ll get a better grip and Check the forum at nordic too they support it in spades.
Final Takeaway:
1. Generating & Storing Keys Securely
