wolfSSL package and secure-boot demo

Development archive
1

Dear RIOTers,

I've recently modified PR #10308 to update wolfSSL/wolfCrypt version and include support for single-precision math, in order to improve performance and reduce resource requirements for TLS/DTLS.

We confirm our intention to support and maintain our port in the future, if there is interest from the community to include the package in the RIOT-OS distribution. Please let us know if we can help with the code review process, and/or there are still actions required from our side to finalize the inclusion.

Moreover, we've been working on a off-tree secure-boot and update demo GPL application, using our mcu bootloader (wolfBoot) in combination with RIOT-OS. This demo targets samr21-xpro board, but should be relatively easy to port the full secure boot to other targets as well.

The bootloader is integrated through a set of makefile rules contained in wolfboot.mk. Some automation to re-link the application at the given address has been inspired by the work previously done by Francisco to showcase a similar solution with mcuboot.

Links:

The open PR: https://github.com/RIOT-OS/RIOT/pull/10308

wolfBoot secure bootloader: https://github.com/wolfSSL/wolfBoot

wolfBoot+RIOT-OS demo: https://github.com/wolfSSL/wolfBoot-examples/tree/master/riotOS-samr21

Hope to see (some of) you at FOSDEM next weekend!

Have a nice day,

2

Hi Daniele,

thanks a lot for sharing! Looks very interesting. A propos: I suppose you also have seen this other recent bootloader riotboot [1] fly by?

From what I understand, the applicability and approach are similar, except the HAL itself is provided by a minimal version of RIOT. We used riotboot for our SUIT-based secure firmware update demo over CoAP and low-power radio last summer [2] [3]. A PR in the pipe for the SUIT parser…

Possible next steps I see: extend your demo to also enable the use of CoAP+radio? (and extend the riotboot demo to also enable the use of USB for transport :wink:

Cheers!

Emmanuel

[1] https://github.com/RIOT-OS/RIOT/tree/master/bootloaders/riotboot

[2] https://github.com/suit-wg/Hackathon-Interim-Berlin/blob/master/README.md [3] https://github.com/suit-wg/Hackathon-Interim-Berlin/blob/master/SUIT-Berlin-Hackathon-recap.pdf

3

Hi Emmanuel,

thanks for the feedback. I must admit I had not not noticed riotboot. Thanks for pointing it out.

Glad to hear we have some common goals in this area.

Re: our design:

- one single boot entry point, firmware images are swapped in the flash.

- Signature verification (ed25519 or ecc256) to guarantee authenticity of the firmware image.

- The HAL is minimal/self contained to keep the target-specific calls self contained to speed up the porting process to other targets.

- We do not carry dependencies to a specific OS in order to be portable across different systems and even easy integration in generic bare-metal systems.

- size vs speed: wolfBoot's "small" configuration (ED25519) produces about ~11K in code size. ECC256 DSA allows for boot speed increase of a factor 3 to 23, depending on the assembly optimizations (code size grows to 20K ~ 45K). In all the three cases, there are no dependencies on std libraries or any other components besides wolfCrypt.

- all the memory for the firmware authentication is allocated at compile time for safety reasons, no HEAP allocation is allowed within the bootloader.

- wolfBoot provides in-place image swap (current boot image/update image) using a one-sector swap space. The image swap procedure is fail-safe (the state of the update is kept in a specific area in the flash and the swap operation can be interrupted and resumed at any time)

- wolfBoot is able to revert an image that fails to boot to the older version temporarily stored in the update image

Re: CoAP/radio demo

The demo code was only meant to show all the bootloader functionality for now, and not focused on the update mechanism, due to the lack of time. I did not prepare a remote update using the radio chip, but this is totally possible, and was my goal at the beginning (hence the gnrc/IPv6 modules are included).

If you look at our other demo based on contiki/nRF52[1], there is a full DTLS/UDP/IPv6/6LoWPAN/802.15.4/BLE demo app and a DTLS server running on the host is in charge of transferring the firmware update via radio.

Re: next steps

I'll be happy to prepare more demos in the future. We are especially interested in transferring images via radio using TLS (1.3) or DTLS. Once again, please let us know if we can assist you in any way, while you are considering our wolfSSL/wolfCrypt package for inclusion.

Greetings,