Encrypted DFU?

[JPHutchins]

I feel like this might be one last thing missing for embassy boot? I'd love to recommend embassy but generally all my projects will want encrypted DFU.

I am a regular MCUBoot user so I can see how it wouldn't be so hard to use MCUBoot to load an embassy app.

I am curious if there is a roadmap for encrypted DFU?

Thanks!
JP

Also - the docs seem to suggest that DFU can be performed from within embassy-boot. In this scenario, a dual slot is not required, which can create a cost savings. Further, mention of the NRF soft device implies that a BLE DFU could be performed from within embassy-boot, something that Nordics own SDK can't do since the switch to Zephyr. Is it possible to have 3 regions: bootloader, soft device, and app (single slot)? And then the bootloader and app share the soft device - the bootloader for app DFU and the app for regular operation. Obviously the soft device would not be upgradable in this scheme. At least not without some magic.

[lulf]

Embassy boot works by having the application responsible for receiving and writing the DFU data, which in turn means the app is also responsible for encryption/description and verification(the firmware update type supports some signature checks which you can use)

On the bootloader side, it is intended to be as simple as possible, only doing the firmware swap, because it is not self-updatable and should do as little as possible.

It does support bootloading via nrf softdevice mechanism, but as you point out, it cannot update softdevice itself. Since softdevice is anyway phased out, have a look at nrf-sdc and trouble for an alternative that doesnt require softdevice.

That being said, for more advanced use cases, consider embassy boot more like a helper lib to build your custom mechanism rather than a full fledged bootloader like mcuboot.

[lulf]

That being said, PRs are always welcome. There is however no plans on the roadmap.

[JPHutchins]

Thanks, I think these are good design choices! And I think it's fine for the majority of cases wherein the secondary is located on the built in flash, which is lockable.

The issue comes where the secondary is located on an external SPI flash. In this arrangement, an attacker can read the chip directly or record the SPI lines during swap. MCUBoot mitigates this by decrypting AND encrypting during swap.

Re: design choices... I have an MCUBoot build on one project that is ~90K - a lot going on there!

OK to move to discussion.

[lulf]

Thanks, I think these are good design choices! And I think it's fine for the majority of cases wherein the secondary is located on the built in flash, which is lockable.

The issue comes where the secondary is located on an external SPI flash. In this arrangement, an attacker can read the chip directly or record the SPI lines during swap. MCUBoot mitigates this by decrypting AND encrypting during swap.

Ah, that's interesting. Yeah, it's all about design choices, and embassy-boot just haven't had the need to support it. It does sound like a useful feature, contributions are always welcome, it's just not something that's happening until someone has the time.

I think keeping the issue open is fine, will label it accordingly.