I’ve just noticed an interesting piece of work from Microsoft last year which both (a) identifies a minimum useful set of security properties for Internet-connected devices and (b) develops a working prototype with MediaTek to demonstrate how little change to an existing microcontroller is required to make this work.
The selected set of properties feels about right:
- Hardware-based Root of Trust: Does the device have a unique, unforgeable identity that is inseparable from the hardware?
- Small Trusted Computing Base: Is most of the device’s software outside the device’s trusted computing base?
- Defense in Depth: Is the device still protected if the security of one layer of device software is breached?
- Compartmentalization: Does a failure in one component of the device require a reboot of the entire device to return to operation?
- Certificate-based Authentication: Does the device use certificates instead of passwords for authentication?
- Renewable Security: Is the device’s software updated automatically?
- Failure Reporting: Does the device report failures to its manufacturer?
ISOC-OTA’s IoT Trust Framework already covers some of this. Should capabilities of this type become generally available in microcontrollers, they might be appropriate inclusions in a future revisions of the framework. Note of course that the mere presence of the capability in a device doesn’t mean that the manufacturer will wield it correctly, but this is still streets ahead of the hopeless position of most existing devices where even the physical support for secure operation has been excluded in the interests of cost and power consumption.
Related thoughts:
- It is an interesting detail that the changes include inserting an MMU. Not only do MMUs - in combination with instruction restart - provide the basis for virtual memory (paging to/from disk), they also provide the basis for limiting the actions of hostile code. It is arguably the case that where we currently draw the line between microcontrollers (initially conceived as control components of single-function devices which control washing machines or similar and do little else) and microprocessors (as in PCs, etc.) is approximately the inclusion of an MMU
- “A device without renewable security is a crisis waiting to happen” (page 4 of the paper). The renewable security and failure reporting capabilities are somewhat comparable to Curious Blue (minus the worm), which was more or less Brandon Wiley’s point: complicated, network-connected, mass-market devices can’t generally be protected competently by their owners; dependence upon specialists is largely unavoidable.
- Securing Internet-connected devices in this fashion is compelling, but it creates side-effects that are themselves harmful. For a related example around spectrum use, there is already tension with respect to the firmware in 5GHZ WiFi devices which is used to prevent interference with other services (radar in particular). The FCC proposed banning changes to such firmware, which would make aftermarket (non-manufacturer) “open source only” firmware illegal, limit the ability of amateur radio licensees to modify commercial equipment for their own purposes, and because economics tends to drive cost reduction and therefore the tendency to put both the 5GHz firmware and all of the other firmware on the same CPU, potentially eliminate both open source and amateur tinkering with entire devices, not merely the 5GHz radio firmware. This is not quite the same situation as the approach described above, but the forces at work are similar, and similar harmful side-effects appear likely.