At the IoT Evolution 2016 conference in Las Vegas, a group of industry experts gathered to discuss security for the Internet of Things, with a focus on embedded devices.
Moderated by Art Swift, President of the prpl Foundation, the group also included:
- Phil Attfield, Co-Founder and CEO of Sequitur Labs
- Lubna Dajani, Chief Strategy Officer at Intercede
- Pim Tuyls, Founder and CEO, Intrinsic‑ID
Swift kicked off the conversation by saying that the folks at prpl see the IoT as the Internet of Broken Things. He pointed to recent hacking attacks such as the widely publicized Chrysler‑Jeep, insulin pumps, and 737s. Regardless of whether these hacks were malicious or simply done in the name of research, the fact is that it is possible today to hack into just about any connected device. Across all of these products, says Swift, hackers can reverse engineer, exploit a weak implementation, modify or reflash the firmware, and then move laterally across the system.
“Given this backdrop of Internet of Broken Things where lives are really at risk now… It’s not just money, it’s not just financial pain, it’s not company reputation, but in the IoT it could really be life.”
Swift said that at the prpl Foundation they believe the answers to securing the Internet of Broken Things can be found in:
- Open source implementations where more eyes looking at a set of code generally makes it more secure
- Interoperability and open standards such that all of us can work together
- Having a root of trust embedded in the devices
- The heavy use of virtualization
The panel discussion covered all of these topics – you can view the entire 35-minute discussion here. Below I share some thought-provoking comments from each of the panelists.
“Almost all security problems start with lack of authentication… in IoT often it will be about communication between two chips, two machines or a sensor to a computer. The computer will autonomously take decisions based on the information it gets from the sensor. That means that it has to be sure that that information is trustworthy – it has not been changed and that the sensor is trustworthy, the sensor wasn’t counterfeit, the sensor was not replaced…”
“Based on a hardware root of trust, inherently present in the chips, you can guarantee indeed that communication is authentic and the components are authentic. You can put good, strong authentication and identification in place and you can start building a trustworthy system.”
“Security by obscurity doesn’t work… It’s known for quite some time that if you are not open about what you’re doing and you don’t let experts review how your stuff works, in security that’s a bad idea. It’s as simple as that. Things have been broken because of that. There are numerous examples out there where people thought nobody will crack this because they don’t know what we put inside. How can they figure it out? Those guys figured out. The guys that figure out have time enough, usually have money enough to sit through it and to figure out how the system works. If it’s not well designed you will lose anyway.”
“We all know that pure software security is flawed. The question is really, how much hardware do you need?”
“I’m optimistic we are going to build more secure systems because we’ll have to. That I’m certainly optimistic about. Closing the full gap… will be impossible in the short term because a lot still has to happen. We need more hooks in the hardware.”
“The bad news is there are companies that are not going to make it through the gap. Their products will fail, then they lose their brands, those companies will go down… either they deliberately made a decision not to do something or they possibly just didn’t because they didn’t know any better.”
“Even with a hardware root of trust, if there’s no hardware mechanism for isolating boundaries between execution environments, some hardware‑enforced mechanism is required. Without hardware separation and without an enforcement mechanism at that interface ‑‑ it’s like a lock on a door that is left unlocked. Without an access/authorization policy and an enforcement mechanism, you really don’t have any security either, because you can just transition through to what’s supposed to be secure and stomp all over it. Related to authentication, authorization governs resource-access entitlement. Similar to “root”, authentication without granular authorization is ineffective. Both ‘As’ must go together.”
“The objective in security is really to create a boundary and enforce that. Security enforcement happens at a discontinuity. It can be physical separation, it can be a bus; it can be different peripherals. The objective is to enforce the separation somehow, so whether that’s a security state up of a processor, whether it’s a separate processor with a transaction going between processors on a bus or whether it’s an MMU changing state, the objective is to leverage hardware to lock up physical resources. The hardware and software implementations are different but can achieve the same separation and control objectives.”
“I’m actually quite optimistic… At the same time, we’ll never achieve perfection. There will be bugs in hardware. There will be bugs in software. We just have to keep marching forward and raising the bar at every step. We have no choice because what works today eventually will get broken tomorrow by a $10,000 piece of equipment from Ebay that used to cost 20 times that. We have to stay current with hardware feature evolution. Assumptions and architectures from the past and the resulting add-ons that do not take advances into consideration will continue to fail going forward. Systems and design must evolve and move forward.”
“Anything that you can make, if we can make it, somebody can break it. That’s why I think it’s very, very important to establish security at the hardware level.”
“It’s essential to be able to authenticate not just an individual against a service, but a service against a service, a service against a device, a device against… at any two points of communication there has to be authentication at each point.”
“We’re big supporters of open source. We think it’s very important that the communication protocols are open such that you can enable access. We’re a big believers in innovation through collaboration and in collaborating on the basics and then you can compete on value add. Compete on what’s in the black boxes in each of the links in the chain of trust. The communication protocols need to be open so that you can customize what you need, retain control and by the same time having security and privacy because sometimes they end up sitting on the opposing sides of the table.”
“At the end of the day, you have to ensure that it’s open, accessible, scalable and secure down to the level of hardware with manageable control, so that not one entity or a few entities ‑‑ I don’t care if it is government or corporates ‑‑ that will control the end‑to‑end because you will then lose who you are in the process.”
“If there’s too much control, there’s not enough oversight, but I think if you collaborate on the basics and compete on the value add, you have the formula which is again why we’re very excited about prpl.”
The Imagination Connection
We’re really excited about the momentum of the prpl Foundation, and the leading role it is taking in driving embedded security. Take a look at prpl’s Security Guidance for Critical Areas of Embedded Computing that lays out a vision for a new hardware-led approach based on open source and interoperable standards.
Imagination’s OmniShield technology aligns closely with the prplSecurity™ framework. With our OmniShield ready processors across our product lineup, we’re helping customers build trust into their devices. This is one of the key reasons that we are seeing growing traction for OmniShield-ready CPUs like the MIPS I-class I6400 CPU – check out this recent blog post on how it is finding its way into applications including ADAS, datacenter and HPC.
What do you think of the role of open standards in IoT security? Let us know in the comments below.