Internet of Things

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.

Proposed IETF draft could serve as a baseline

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.

Standard includes some common sense requirements

Below is a summary of the main requirements put forward by the three ARM engineers in their IETF draft:

The update mechanism must work the same even if the firmware binary is delivered via Bluetooth, WiFi, UART, USB, or other mediums.
The update mechanism must work in a broadcast type of delivery, allowing updates to reach multiple users at once.
End-to-end security (public key cryptography) must be used to verify and validate firmware images.
Rollback attacks must be prevented.
All information necessary for a device to make a decision about the installation of an update must fit into the available RAM of a constrained IoT device. This prevents flash write exhaustion.
A power failure at any time during the update process must not cause a failure of the device.
The firmware update mechanism must not require changes to existing firmware file formats.
The new firmware update mechanism must be able to operate with a small bootloader, specific to most IoT devices.
The update mechanism must account for multiple permissions. For example, a firmware update for critical infrastructure equipment will have to be signed by both the firmware author and the equipment's owner/operator.
The new IoT firmware update architecture must support manifest files. This file must contain information such as:
   -  information about the device(s) the firmware image is intented to be applied to,
   -  information about when the firmware update has to be applied,
   -  information about when the manifest was created,
   -  dependencies to other manifests,
   -  pointers to the firmware image and information about the format,
   -  information about where to store the firmware image,
  -  cryptographic information, such as digital signatures.

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.

IoT security experts weigh in

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."

Munro: Not perfect, but a good starting point

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!"