Good luck saying 'Sorry I'm late, I had to update my car's firmware'
This is why the IETF's SUITs squad wants to make IoT firmware updates fast and easy
The IETF has noticed how badly Internet of Things firmware is managed, and wants it fixed.
The Software Updates for Internet of Things (SUIT) working group was chartered in December 2017 and given the job of fixing this.
The working group has now published the first fruits of its deliberations, in the form of two Internet-Drafts: this, from a group of ARM engineers led by Brendan Moran; and this, from Huawei engineer Jintao Zhu.
The Moran draft (which updates work from October 2017) focuses on how firmware and manifest are handled, to address the authenticity and confidentiality of a firmware update. Firmware updates, the draft noted, have to be authenticated to defeat malicious code; and the binary kept secret from potential attackers.
The draft also has a handy checklist of the challenges in automating the update process: for example, making sure failed updates are reversible but successful ones are not.
That has to work even though both bootloaders and parsers might be tiny in the IoT environment: so-called “Class 1” devices are specified to have 10 KB or less RAM, and total storage less than 100 KB.
Any firmware distribution is almost certain to touch untrusted storage at some point: an FTP server, a Web server, or even a user's USB stick.
End-to-end encryption covers this requirement, so long as the target device can authenticate the firmware/manifest with a suitable public key scheme (the Moran draft assumes asymmetric encryption, but envisages that a symmetric scheme may be needed in the future, for very constrained devices).
Other requirements in the draft include:
- Firmware distribution has to be agnostic to the medium, whether network, USB, WiFi, and regardless of protocol;
- It should be broadcast-friendly, so the updates should not depend on security of the link layer, network layer, or transport layer;
- Resistant to rollback attacks;
- High reliability – the draft singled out power failure, saying an outage during update must not brick the IoT device (and note, in IETF standard parlance, “must not” means “an absolute prohibition”);
- Update mechanisms must not require changes to existing firmware formats; and
- Permissions have to be robust, so (for example) a firmware author can't push to a device in critical infrastructure, without the operator's authorisation.
Let's update the car …
Zhu's document elaborates on the security aspects of IoT updates, and like the Moran draft, provides a valuable “problem statement”.
A good example is how to update a motor vehicle without driving the driver round the bend. Someone confronted with the choice between installing an update or starting the office commute will probably choose the latter, and when you turn the key to “off”, the electronics also goes dark.
The problem stated in the draft is that update standards like the Open Mobile Alliance's Lightweight M2M, or its firmware update management object (FUMO) assume the target device is in an “idle” state. “In most IoT use cases, the "Idle" status itself is really confused and hard to reach”, Zhu wrote.
Why would this be considered a security issue? Because, Zhu argued, timeliness is important in firmware updates: “firmware with vulnerabilities is very harmful for an IoT device”.
Today, most update mechanisms are negotiated, Zhu's draft stated: the server notifies the client that an update is available and the client decides whether to proceed, but the IoT environment should also support client-initiated updates, and for devices used 24x7 (electricity meters, for example), server-initiated updates. ®