Securing SMP Service for mcumgr DFU

[Haresh05]

Hello Nordic team,

I'm working with nRF Connect SDK (version 3.1.0) on an nRF54L15 device and using mcumgr for Bluetooth LE firmware updates via the SMP service.

My goal is to protect the SMP service so that only authorized devices can perform firmware uploads/updates.
Specifically, I want to prevent any unauthenticated or unauthorized BLE central from writing to the SMP characteristics and initiating a DFU.

From my search:
- Enabling CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=y sets GATT permissions to require authenticated writes.
- This should force MITM-protected pairing (e.g., passkey or numeric comparison) before allowing SMP access.
- I'm also planning to use MCUboot image signing for additional protection.

Questions:
1. Is CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=y the correct/recommended way to require authenticated pairing for SMP access? Are there any additional configs needed (e.g., bonding, security level in code)?
2. As My device does not have any disply/input option, is this way(CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=y) suitable to protect SMP service?
3. If I want encryption but *not* full authentication (to avoid passkey entry in my case), is there a way to set permissions to BT_GATT_PERM_WRITE_ENCRYPT only?
4. Any other best practices for production-grade security on SMP DFU (e.g., combining with custom handlers or other transports)?

Thanks in advance for your help!

[Vidar Berg]

Hello,

The signature validation of the FW image in the bootloader ensures that only FW updates images signed with your private key can be applied on the device while limiting access to the SMP characteristics can help prevent unwanted update attempts. 

1. Is CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=y the correct/recommended way to require authenticated pairing for SMP access? Are there any additional configs needed (e.g., bonding, security level in code)?
2. As My device does not have any disply/input option, is this way(CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=y) suitable to protect SMP service?

You need support for pairing with MITM to use this security level, but this also requires the device to have I/O capabilities like keyboard or display.

3. If I want encryption but *not* full authentication (to avoid passkey entry in my case), is there a way to set permissions to BT_GATT_PERM_WRITE_ENCRYPT only?

You could patch the SMP service source files to support this, but an unauthorised device may still be able to connect and establish and encrypted connection with your device.

4. Any other best practices for production-grade security on SMP DFU (e.g., combining with custom handlers or other transports)?

I think the question is what you are trying to protect against. As mentioned, the signature validation ensures that only images signed with your key can be updated.

Best regards,

Vidar

[Haresh05]

Hello,

Thank you again for the previous detailed answers.

I have a few follow-up questions regarding a peer-to-device firmware distribution use-case in our product:

Scenario description:
- One device ("source") reads its currently running firmware binary directly from flash.
- This binary is then sent over BLE using SMP DFU / mcumgr to other nearby target devices as a firmware update.
- Goal: Allow controlled field firmware sharing between devices (e.g., one device gets official update → shares with others nearby).

Questions:

1. In this peer-to-device transfer scenario — where the image is the currently running & already-verified firmware from the source device — will the bootloader signature validation on the target devices still be performed and enforced?
In other words: Does the target bootloader always validate the signature of any incoming DFU image (regardless of source — official signed update vs. forwarded from another device)?

2. If signature validation is always enforced:
Does this mean the source device would still need to sign the extracted binary with our private key before sending it?
(We would prefer to avoid having the private key or a signing service on the devices themselves for obvious security reasons.)

Additionally We noticed a big speed difference when comparing:

- DFU using the nRF Connect Device Manager mobile app: It uses a dfu_application.zip package and the entire transfer completes in just seconds
- Our device-to-device method: Reading the binary from flash on the source + sending via SMP DFU takes 2–3 minutes.

3. How exactly does the nRF Connect Device Manager app achieve such fast transfers with the ZIP file?
4. What are the recommended ways to optimize the transfer speed in a custom device-to-device SMP DFU implementation to approach the speed of the official app?

Our main priorities are secure & controlled firmware propagation in the field while keeping the implementation simple (no display/keyboard for advanced pairing) and reasonably fast.

Thank you very much in advance!
Best regards,
Haresh

[Vidar Berg]

Hi Haresh, 

The bootloader on each target devices should validate the signature and integrity of the update yes. You can confirm this by sending an invalid image. Regarding transfer speed, it's hard to say for me what the bottleneck is in your case, but usually when it comes to throughput it is related to the connection parameters.

Best regards,

Vidar