Security experts have filed a proposal with the Internet Engineering Task Force (IETF) that defines a secure framework for delivering firmware updates to Internet of Things (IoT) devices.
Filed on Monday by three ARM employees, their submission has entered the first phase of a three-stage process for becoming an official Internet standard.
Titled "IoT Firmware Update Architecture," their proposal — if approved — puts forward a series of ground rules that device makers could implement when designing the firmware update mechanism for their future devices.
The proposed rules are nothing out of the ordinary, and security experts have recommended and advocated for most of these measures for years.
Some hardware vendors are most likely already compliant with the requirements included in this IETF draft.
Nonetheless, the role of this proposal is to have the IETF put forward an official document that companies could use as a baseline when designing the architecture of future products. This document could also serve as a general guideline for lawmakers who could draft regulations forcing manufacturers to adhere to this baseline.
Below is a summary of the main requirements put forward by the three ARM engineers in their IETF draft:
The draft's authors hope their proposal goes through and IoT device vendors will have a set of rules at their disposal for creating and deploying more secure update mechanisms.
Ken Munro, security researcher for Pen Test Partners, a UK-based penetration testing and cyber-security firm, believes the draft is on the right track.
"It's a good start," Munro told Bleeping Computer via email after reviewing a copy of the draft with his team. "A lot of thought has gone in to it, however there are issues."
"Our main criticism is that, while it mentions payload encryption, it does not require it," Munro said, pointing out the draft's language that leaves payload encryption as optional, at the vendor's choice.
"This could allow someone to still read the firmware in order to find potential security flaws," Munro said. Furthermore, the expert sees some other potential issues.
"Failed firmware updates should ideally cause the device to boot to a stub firmware on the device that allows the owner of the device to re-apply the firmware update. This could be part of the minimal bootloader [...]. This would mitigate issues with having [...] two full copies of the firmware in memory."
Another issue that Munro and the Pen Test crew had a problem with was the wording of "Rollback attacks must be prevented."
"This isn't well defined," Munro said. "Rollback can be really important - let's say that an update causes your vehicle to malfunction. You as the user would want to trigger a rollback to the previous stable firmware so you can drive the car."
"Rollback attacks typically cause the device to roll back to a known insecure firmware version. However, simply preventing rollback [in general] is a bad idea."
One more point of content for the Pen Test crew was the section regarding flash write exhaustion attacks.
"Flash exhaustion is an important point," Munro told Bleeping. "What's missing here is the message that devices should have many times the flash memory available for any conceivable future update. Rollback may require several firmware images to be held on the device, so limiting memory to the minimum required on grounds of cost is a receipe for future disaster."
Last but not least, Munro raised the issue that the IETF draft does not explicitly mention how vendors should interpret the "verify" and "validate" terms.
"Whilst one can figure out what they mean with these terms in the context they are used, this leads to ambiguity," Munro explained. "Ambiguity in RFCs can lead to security issues."
"Generally, the draft RFC is light on detail and specifics. To be honest, it raises more questions than it answers," Munro said, but also added that "it's a good start for an RFC!"