Feature Story

Open, Hardware-Based IoT Security Can Be a Win/Win for Innovation & Regulation

In the last blog post, I discussed how regulators are increasingly setting themselves on a collision course with consumers keen to customize and improve the functionality of their products. The key here is the Internet of Things, which is rapidly turning a new generation of products "smart" by adding computing power, network connectivity, and sophisticated software. From cars to routers and drug infusion pumps to drones, they now offer a wealth of possibilities for tech savvy owners keen to push their device capabilities to the limits. At the same time there are logical reasons why lawmakers and regulators need to lock down certain functionality – for the safety and well-being of their citizens. It's a delicate balance.

The problem is that current IoT systems simply aren't architected in a way which will allow for this kind of granularity. The answer is a new approach outlined in the prpl Foundation's new document: Security Guidance for Critical Areas of Embedded Computing. It describes how open source development; secure boot based on a root of trust anchored in the silicon; and hardware virtualization can keep both regulators and consumers happy.

A new way

This new approach is founded on three main principals:

Open source: Too many proprietary systems rely on 'security-by-obscurity.' But this concept simply doesn't work any longer. Firmware binary code can often be found online, or reverse engineered with debugging tools like JTAG and interactive disassemblers like IDA. Given the increasing complexity of code, we need to get as many eyeballs on it as possible. The focus should be on creating a top quality, highly usable, secure, and robust end product.

Secure boot: The method of updating firmware in embedded systems is fundamentally flawed because this software is typically not cryptographically signed. This means an attacker could reverse engineer the code, modify it, reflash the firmware and reboot to execute arbitrary code. We must ensure IoT systems only boot up if the first piece of software to execute is cryptographically signed by a trusted entity. It needs to match on the other side with a public key or certificate which is hard-coded into the device. Anchoring the "Root of Trust" into the silicon in this way will make it tamper proof.

Hardware-assisted virtualization: Security by separation is one of the fundamental rules of IT security. Yet lateral movement within the hardware is possible on most IoT systems, opening up yet more vulnerabilities to exploit. Hardware-level virtualization will prevent this lateral movement and preserve security by separation. With the help of a secure hypervisor, it can provide a foundation to containerize each software element, keeping critical components secure and isolated from the rest. Secure inter-process communication allows instructions to travel across this secure separation in a strictly controlled mode.

Innovation & regulation

Building security into the hardware of embedded systems in this way will help regulators lock down specific harmful functions while allowing consumers free reign to tweak other parts of their product. It's a win/win for innovation and regulation.

Let's look at the three examples covered in the last blog post again:

1) The FCC is currently looking to regulate the domestic router market in a bid to prevent users adapting their devices to interfere with their Wi-Fi capabilities. But its plans, outlined here, threaten to lock down the entire system. With Linux, radio frequency parameters are controlled in drivers inside the kernel. So the only way to guarantee that a third party – or the router owner – can't modify these is to prevent modification or replacement of the driver. This effectively means restricting modifications to the OS as a whole. It's the equivalent of using a sledgehammer to crack a nut.

This is bad news for consumers and for open source operating systems like OpenWRT. These operating systems can provide home internet users with useful additional functionality like being able to add a print server or parental control application. The FCC's plans would make installation of such an operating system illegal. Where will it end? Laptops, smartphones, and tablets all have similar Wi-Fi functionality. Are their operating systems to be regulated too?

That's why prpl Foundation's guidance makes so much sense. Containerizing separate software components at a hardware level means the FCC could enforce control on the elements which manage radio frequency parameters but allow consumers to play around with other parts of the router. And, crucially, it would allow the public to exercise their consumer rights by installing the OS of their choice.

2) When it comes to connected cars there are some elements that climate change watchdog the Environmental Protection Agency may soon be looking to regulate. More parts of our vehicles are now controlled by computers than aren't. So what happens if a tech savvy car owner decides to reprogram the software related to fuel consumption and engine performance, in a bid to ramp up the horsepower? The effect on emissions could be cause for concern. But once again, how might the agency ban this kind of tampering without locking down the electronics of the entire vehicle?

The answer again lies with prpl's vision for embedded computing security. Hardware virtualization can allow regulators to ban harmful elements whilst allowing the owner to adapt other components as they see fit.

3) It's easy to see a time in the not-too-distant future when the government decides to do something about the hordes of consumer-grade drones invading our skies. If remotely hacked they could be controlled by a malicious third party to cause all sorts of chaos. They could even be manipulated in their hundreds or thousands like a physical bot army to carry out co-ordinated strikes.

How do we stop this happening? Through more robust and secure open source code, and through secure boot capabilities. As outlined by prpl Foundation, by enabling pervasive implementation of cryptographic signing, and ensuring that the public key or digital certificate is anchored in the chip itself, the firmware update system is rendered tamper proof. This means an attacker could not execute arbitrary code by reflashing the firmware and rebooting.

This isn't just a case of preserving consumer rights and ensuring the regulators can do their job of protecting the populace properly. It's also about protecting innovation. Without the freedom to tweak and adapt current technologies how can we expect to make the leaps required to future iterations? Technology advances only if innovation is allowed to thrive. And with our blueprint for an open, hardware-led approach to securing embedded computing, we can finally achieve it.

Return to: 2016 Feature Stories