The properties of secure IoT devices

At Open Source Summit North America 2019, David Tarditi from Microsoft gave a talk on seven different properties for highly secure Internet of Things (IoT) devices. The properties are based on a Microsoft Research white paper [PDF] from 2017. His high-level summary of the talk was that if you are creating a device that will be connecting to the internet and you don't want it to get "owned", you should pay attention to the properties he would be describing. Overall, it was an interesting talk, with good analysis of the areas where effort needs to be focused to produce secure IoT devices, but it was somewhat marred by an advertisement for a proprietary product (which, naturally, checked all the boxes) at the end of the talk.

Internet connected

He set the stage by noting that there are nine billion microcontroller-based devices deployed every year—many of which will be connected to the internet. He showed a microcontroller from 2014 ("forever ago") that had radios on the die with the CPU. He believes that most devices will be connected to the internet in the coming years and that it will lead to a "profoundly better experience" for users.

He gave the example of an internet-connected refrigerator, which would allow better prediction and diagnosis of compressor problems. Instead of a customer detecting that the compressor has broken by finding spoiled food or melted ice cream, the manufacturer could proactively alert the owner that a problem was imminent. Because the performance of a large number of compressors in the field can be monitored, the manufacturer can observe patterns that indicate an upcoming failure in the field.

But, the internet is a "cauldron of evil", as Dr. James Mickens put it, so there are real dangers when devices get connected to the internet. He noted a bunch of different headlines regarding IoT security but, "to make it more concrete", spent some time describing the Mirai botnet.

In October 2016, the Mirai malware infected a bunch of web cameras, baby monitors, and other devices running Linux. It turned them into a botnet that more or less shut down the internet on the east coast of the US for a day. That attack only involved around 100K devices and exploited a well-known weakness (default administrative passwords). But there was no early detection of the attack and, worse yet, there was no remote update capability for the devices, he said.

Mirai highlighted some of the risks of internet-connected devices, but it also showed that the effects are more than just technical. Tarditi noted that Mirai appeared in the New York Times, on the "Technology" page for the first day, but on the "Politics" page on day two. Device security is a socioeconomic concern; governments will be paying more attention to these issues going forward.

In addition, the Mirai attack was just a small taste; future attacks could be much larger (imagine 100-million devices, he said) or could have much worse effects (e.g. "bricking" an entire product line or attacking critical infrastructure). Connecting a device to the internet is a "serious and challenging issue". There is a moral issue there too, he said, because people could get hurt; this isn't "turn off your PC and reboot, this is more serious".

Building a secured device

Microsoft has been on the front line for more than 25 years in terms of protecting customers and their devices, Tarditi said. In his slides [PDF], he had a timeline of some developments in internet attacks against computers, along with Microsoft projects and initiatives to combat them. He said that Windows has long been a target for attackers. He believes that attackers find Windows 10 to be a pretty difficult target these days.

Over that time period, the company has learned some lessons. The first is that "your code is going to have bugs". It is "really easy to get code wrong", Tarditi said. Also, "your device will be hacked"; attackers are smart, creative, and persistent so they will get through the defenses. It is important to recognize that "security is foundational"; it must be built in from the start, not grafted on later as an afterthought.

There are some concrete things you can do to ensure that a device is highly secured, rather than simply having some security features. There are seven properties that the white paper identifies as being crucial to that process. If anyone has another property that should be added to the list, he is interested in hearing about it. The properties are:

• A hardware root of trust: Using cryptographic keys that cannot be forged will protect the identity of the device. Storing private keys in the hardware means that an attacker needs to mount a physical attack in order to subvert the root of trust. That can provide a secure boot process to ensure that only trusted software is being run on the device and can be used to attest to the integrity of the software running on the system to remote servers.
• A small trusted computing base: The trusted computing base is the software that ensures the security of the system, so it should be as small as possible to reduce its attack surface. A complex kernel (e.g. Linux) should run atop a much smaller security monitor or hypervisor.
• Dynamic compartments: Providing hardware-enforced boundaries between components in the system in order to isolate them and limit the damage a successful attack can do.
• Defense in depth: Tarditi showed a photo of a castle as the prototypical illustration of defense in depth. The castle has many layers to its defense: multiple walls, moats, gates, and so on. For IoT devices this means having multiple mitigations in the system: firewalls on internal buses and on the network, no-execute protection of memory, address-space-layout randomization (ASLR), etc.
• Certificate-based authentication: Passwords have multiple problems, they can be stolen and they require someone to handle their administration (e.g. set a good password for the device). With a hardware root of trust and remote attestation, the device identity and integrity is known. Certificates can be issued to the device that will allow it to access services; those certificates can be short-lived, so that a compromise only has a limited time to operate.
• Failure reporting: Gathering information from many devices in the field can help detect when an attack is starting or something else is going wrong. Unknown attacks using zero-day flaws can be detected early because they cause crashes in some devices. Those crashes are an indication that something is wrong, so if that information is gathered centrally, it can be analyzed to help determine where the problem lies.
• Renewable security: There is a need to be able to provide software updates from the cloud and for the device to be able to apply those updates to protect itself against vulnerabilities. It is also important to have a hardware mechanism to prevent rollback attacks, where a device is tricked into installing a previous signed update with known vulnerabilities.

Achieving those seven properties is challenging, he said. The security of the system is only as good as the weakest link, however. Threats evolve over time, so it is important to be able to recognize and react to those threats when they occur. And, in order to reduce the effectiveness of those attacks, device makers need infrastructure that can get updates to the devices in short order.

Ad time

At that point, Tarditi launched into a thinly veiled advertisement for the project he works on at Microsoft: Azure Sphere. While Azure Sphere is meant to provide an end-to-end solution for device makers that embodies the seven principles, it is a proprietary product that simply uses the Linux kernel as part of its Azure Sphere OS. Certainly "open source" was not a major component of the sales pitch, which was rather surprising at a conference called "Open Source Summit".

Beyond that, Tarditi did not address an elephant in the room with regard to devices that operate under the seven principles. Those devices may well be highly secured, but they are also completely controlled by the device vendor, not the putative owner of the device. Software updates can (and presumably will) fix security flaws, but they can also take away features that users want, add anti-features that users don't want, and, effectively, cause the device to act in ways that are directly contrary to the best interests of the person who paid for it, installed it, and runs it. Balancing between security and ownership needs is a difficult, largely unsolved problem, but it does seem like something that should at least be mentioned in a talk of this type at an open-source conference.

This kind of semi-infomercial talk is all too common at many conferences in our industry, but it is decidedly uncommon at open-source technical conferences. It may be that companies chafe at that restriction, but it seems like ground we don't really want to cede, at least for the technical side of our conferences. There are other outlets at some events, keynotes for example, where sponsors can pay to present their commercial solutions to a, seemingly, receptive audience. Keeping that kind of talk out of the main tracks of a technical conference is something worth pursuing. Or so it seems to me.

Interested readers can check out the video on Vimeo.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to attend Open Source Summit in San Diego.]