Towards firmware updates over LoRa: cryptography and delta updates

11 Oct 2017

Jan, thanks for all the work to get firmware updates working over LoRaWAN!

I have a few questions:

- why do you think that it's still unsecure?

- what would be the best approach without an SD card, while having enough ROM for 2 full binaries? Most of the boards out there are without an SD slot

- would it be a viable alternative to use CoAP+DTLS instead of HTTP+RSA sig? A downside would be that the binary after patching couldn't be verified though

12 Oct 2017

- why do you think that it's still unsecure?

Some reasons:

  1. Memory space between the verification, writing to flash and the application is shared, so a code injection bug could interfere with the signature verification. uVisor with an external MPU or TrustZone would help. External crypto engine for verification could help too.
  2. Also there is zero verification in the bootloader, so if someone manages to inject something in flash, the bootloader will happily flash the application.
  3. No DTLS with certificate pinning implemented, so someone could MITM the update process (actually a problem even in the real world).
  4. Signing of the firmware does not happen on an air-gapped computer.

- what would be the best approach without an SD card, while having enough ROM for 2 full binaries? Most of the boards out there are without an SD slot

The new BlockDevice API in Mbed OS 5.5 allows you to mount a file system (e.g. little-fs or FAT) to any external SPI flash. I'm using AT45 SPI Flash on my board (although not with an external file system at this point, just writing to pages directly). See also spif-driver.

- would it be a viable alternative to use CoAP+DTLS instead of HTTP+RSA sig? A downside would be that the binary after patching couldn't be verified though

It would be CoAP+DTLS+RSA. Transport level security (which we also have on LoRa) is not good enough, as it would require complete trust of the server. If the server is compromised, then so is your update procedure. You want to sign the firmware (preferably on an air-gapped computer) before letting the server deliver it to your device.

A way of delivering this all in one go is to combine the signature + the application in one binary. That's what we do in LoRa. First X bytes are the signature and some metadata, thereafter is the firmware. We then split it up in the device again.