Standards for keeping devices' security up-to-date

Question

With IoT devices typically being built with low profit margins and low power specifications, functionality is typically limited to that which is needed. But for a device that is expected to last a number of years, there will be security vulnerabilities and issues that need fixing (see the Mirai botnet as an example)

As an IoT manufacturer, how can I enable patching or upgrading of encryption algorithms or security protocols remotely, or simply ensure that the device is kept secure? What standards should I follow?

Answer 1

How do IoT manufacturers enable patching or upgrading of encryption algorithms or security protocols remotely or simply to ensure that the device is kept secure?

A large number of IoT manufacturers have a simple solution to this: "don't bother". These tend to be the same developers who add default (or even unchangeable) passwords to their devices, which led to Mirai in the first place.

As mentioned in Rory's answer, there are sizeable costs to providing both the mechanisms and the actual development time to design and deploy the fixes. I strongly suspect that without regulatory pressure (or consumer demand, which doesn't seem to be the case), there will be no incentive for a manufacturer to raise their product's prices for added security. Australia seems to be taking this step by considering a mandatory security rating system for all IoT devices.

I think that for most manufacturers, the best idea is to get someone else to handle security. Just as most web developers use established frameworks like Django and Ruby on Rails to avoid making the same mistakes over and over, IoT developers should do the same. There are several options, depending on the complexity of your device:

• Higher-end devices could use operating systems like Ubuntu IoT or Windows 10 IoT Core where security updates are done by the OS developer and pushed automatically. Much of this isn't IoT-specific, but it is far preferable to each IoT device using a custom, in-house operating system that is unlikely to receive any maintenance.

• Low-end devices such as ESP8266 modules are perhaps more limited, as they aren't able to run such complex operating systems and tend to run code developed specifically for that device. There are still options such as Mongoose OS which offer over-the-air firmware updates

IoT manufacturers generally should take advantage of existing solutions where available. Web developers don't usually recreate a web framework for each new website, so why should IoT be substantially different? Rory's answer offers an excellent list of features that should be implemented by a good operating system for the IoT, and just using an "IoT OS" won't fix all your problems. As this Windows IoT guide explains, one must take steps to ensure the hardware and firmware are secured as well as the OS itself. The ideas in Rory's answer are pretty comprehensive in this regard.

Here are some examples from the operating systems I suggested about what systems they use to upgrade security:

• Windows IoT:

  • Automatic feature and security updates when connected to the Internet
  • With Azure IoT Suite, each device has an X.509 certificate to authenticate to the hub. This also ensures that if one device is compromised, others are not affected

• Ubuntu Core:

  • Unattended automatic updates for security
  • "Transactional over-the-air updates — with full rollback features"

Answer 2

Moran posted this IETF draft titled A Firmware Update Architecture for Internet of Things Devices on the 30th of October 2017.

A key summary outlined over at Bleeping computer is

• 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 is very much a draft, as this is a new area. My expectation is that it will be driven more by regulation than by consumer demand, as consumers really don't care about updates or security unless they directly impact them. Any improvements in this area will impact the cost of devices.

Answer 3

If the firmware of your device can be made less complex than the bootloader required for a secured remote update, then do not implement remote update.

I know the consensus is to have a secured and robust bootloader, with strong public crypto authentication, safe rollover mechanisms, maybe a basic network stack, and then put on top of that a RTOS, with a full IP+TLS network stack, then add on top of that your application. This is pure insanity for a low-cost low-power device. IMHO, this leads to products that are updated every week or so, which tend to bother users because sometimes updates start at the wrong moment, fail or break something. Updates drain a lot of power too, so user have to charge more often. And security is still far from guaranteed as the attack surface is large.

Your device is doing basic sensing/actuating, maybe some local triggering/displaying but not much? Skip all that.

Write bare metal code, use a very basic stack, audit it thoroughly, do some formal verification if possible. And then you can be relatively confident that your device will not have security issues for the next decade.

If all you have is a hammer, everything looks like a nail. And that's why most coder try to write code to secure their unsecured existing code. Writing less code doesn't always come naturally.