This was submitted two years ago, but given current events I figured it’s worth resubmitting.
Thanks @sangy for invite, and @pl for posting!
A former TUF researcher / developer here, please let me know if you have questions!
This is the second time I’ve seen a reference to TUF. This time I’m actually reading through all the material on the site; previously id meant to but never got around to it.
Is it possible the project could lead with an elevator pitch, then maybe some examples? It’s not immediately obvious how relevant TUF is. Also putting the big names front and centre might help indicate how important it is.
Thanks for your suggestions — I have forwarded them to our team!
Jack Ganssle’s The Embedded Muse did a survey of how embedded people were handling firmware updates. You might find their replies interesting in Issue 288 and Issue 289.
Thanks! Would you mind briefly summarizing them?
The eCosPro people (Daniel Morris answering) have Robust Boot Loader. It extends RedCode with mirroring. He says, “A fresh image is loaded into a redundant area, validated, started, re-validated and then once we’re happy the “old” image’s space becomes the reservoir for assembling a new update. Image integrity is critical, as was testing to ensure that the system was resilient if (for example) the power failed/was disconnected during the reprogramming stage. Versioning is managed to make sure that previous updates aren’t written over a newer installed image, unless the application developer really, really, really wants to!” A tradeoff is it needs double the space.
Daniel Morris said they have eCosPro-Bootup for smaller devices. It runs on boot, pulls in any updates if necessary, loads the system, and deletes itself after loaded to not take up space.
Several others use OpenBLT. Frank Voorburg said it works as follows: erase the existing flash memory; pull in update in small chunks; 16-bit checksum at a fixed location is checked but for vector table to ensure firmware was completely programmed (???); new software is started. Chris Maier adds “It supports SD card, UART, CAN, TCP/IP, and USB.”
Dan Swiger divides his stuff into three parts: boot-check, factory bootload, enhanced bootload, and runtime. The boot-check turns processor on before scanning flash to see what’s available. He said it needs to be bullet-proof. Run-time is your application. Factory bootload has enough code to “interface with outside world” for downloading updates. He uses stripped version of Run-Time for this. The enhanced bootload is an empty area to extend and/or fix factory bootload. Boot-Check tries to load Run-Time, then Enhanced Bootload, and then Factory-Bootload in that order. Uses checksums. Erases flash before downloading new run-time code. If a Linux distro, he upgrades it altogether with a upgrade.tar.gz file he downloads with FTP/SCP and checksums.
Ah, interesting, thanks! Uptane (a version of TUF for automobiles) seems to share many features that Robust Boot Loader.
The overview page for TUF lists three classes of software update systems. There is a fourth which perhaps different enough to warrant its own entry in the list - the whole system update. Chrome OS uses this with an A/B partitioning scheme where an updated system image is downloaded and installed to the partition not currently in use. The next boot will boot into that image. Images are signed and a TPM verifies the signature on boot.
There is an open source project called mender (https://mender.io) that implements this scheme for use in IoT devices. I’m not sure how many IoT devices have TPM support, and for those that don’t, what the attack vectors look like. It looks like it could be an interesting area for research with the huge proliferation of IoT devices and the apparently poor security record. Something like TUF and mender as a system that vendors can use could go a long way to help securing the internet-of-things.