It has been estimated that there will be 20 billion embedded systems connected to the Internet by 2020. Everything from industrial machinery to autonomous vehicles, medical devices, and your own refrigerator will have its own address and identity as the Internet of Things (IoT) promises to change the way that the world works.
If there is a downside to all of this active connectivity, it is the potential vulnerability of devices and systems to hackers and security breaches. Mike Hendrick, vice president of engineering at Seattle-based Sequitur Labs, Inc., will present a talk titled, “The Essential Path from Security to Trust” at the Embedded Systems Conference (ESC) in Minneapolis on October 31. Design News spoke with Hendrick to find out more about how future systems can be made safer.
A History of Isolation
“Embedded electronics, IoT, and all of these types of areas have classically been built on unconnected, isolated systems,” Hendrick told us. “So people who build embedded devices have not traditionally worried too much about security because they have been on isolated systems and not connected to a broader network.”
But as things change and more devices connect to the cloud, security has become an issue. “As IoT has come to fruition and more things like medical devices, consumer devices, and even industrial devices become connected up to the cloud and public networks, then they become security risks,” said Hendrick. “They are an entry into the network. They become targets of opportunity for people to pick data up—all kinds of issues,” he explained.
Mike Hendrick, vice president of engineering for Sequitur Labs, Inc., will talk about IoT security and trust at the Embedded Systems Conference in Minneapolis on October 31. (Image source: Sequitur Labs, Inc.)
“Connecting devices securely is not securing connected devices”
Current security technology has concentrated on protecting the connections between devices, but not on the devices themselves. “You can put an SSL tunnel between the embedded device and the cloud, but it doesn’t make the device secure—it just means that the communications can’t be observed while it’s in transit,” noted Hendrick.
Hendrick notes that building a better security system begins with asking a lot of questions: “How do you build trust on these devices so that you can trust the data, that you can trust the devices are authentic? How do you build that trust? How do I boot the system securely? How do I authenticate the software that’s running on it? How do I know that it’s an authentic device?” Hendrick notes that all of those things establish what he calls a ‘trust anchor.’
There is good news to be had when building secure systems. “One of the really nice things about these devices is that there are some industries—like mobile and payment industries, and set-top boxes and the video industry, where they have actually been very concerned with security. The hardware itself has lots and lots of capabilities,” said Hendrick.
The Secure Boot
The starting point is the secure boot. It’s a security standard developed by the PC industry to make sure that a device boots using only software that is trusted by the chip manufacturer. The chip firmware checks the signature of the boot software. If the signatures check out, the PC boots and control goes to the operating system.
Hendrick explained how this security can be further expanded. “When the chip vendor talks about having secure boot, they’re really talking about the hardware—when it first powers on or goes through a reset, it validates the first piece of software that it runs. So the very first piece of code that I come up with, I can attest to the authenticity of it and the integrity of it. However, in most of these systems, that’s not the end of the story because from that initial piece of code, you might be running Linux as the operating system. So to get from that little piece of boot code all the way up into Linux, it has to maintain that level of integrity through the whole chain,” he said.
But security has to go beyond the first level of secure boot. “There is trust in the software that is running on the device. But because these are interconnected, I have to translate that trust back to the backend that I am connecting to. Not only do I have to establish the secure boot—which established the authenticity of my code so that when the device boots, it is running the code that it’s supposed to—but I have to take that and produce identities that I can add to external systems so that I can believe that the information coming from that external system comes from a device that I fundamentally trust,” said Hendrick.