Inadequate IoT Security is Setting Regulators on Collision Course with the Entire Open Source Movement
March 16, 2016 2 Comments
It was Charles Dickens’ much celebrated novel Oliver Twist that first popularized the phrase “the law is an ass.” It resonated far and wide for people who viewed the British legal system of the time as unjust and at odds with common sense. Now, no one is suggesting that the highly evolved legal and regulatory system we have in the modern United States is anything like the situation Dickens described 177 years ago. But it remains that rules set by regulators and lawmakers have consistently failed to keep up with the pace of technological change – and there’s a real danger they could now threaten the development of the Internet of Things (IoT) and embedded computing.
More specifically, in the process of trying to regulate some of the functionality in embedded systems, new rules could undermine consumer rights, innovation and even the viability of open source software.
Over the next couple of blog posts I’ll provide some examples of industries where a heavy regulatory hand could cause damage. And how the fresh approach to embedded security outlined in prpl Foundation’s new document, Security Guidance for Critical Areas of Embedded Computing, can help us have the best of both worlds – more secure devices and more granular compliance requirements.
Our products, our rights
I think we all understand pretty well that the primary goal of the proprietary technology maker is commercial, not user-focused. If you’re in any doubt, just consider Microsoft’s Xbox One, which when it launched two years ago featured no backwards compatibility with Xbox or Xbox 360 games. The result? Parents all over America were forced to buy their kids the latest iteration just so their little ones could play online with their friends.
Let’s be clear – tech vendors are after profits first. The user comes a distant second, so it’s no surprise that consumers have taken to tweaking the technology they buy to enhance its functionality. In the iOS world it’s called “jailbreaking,” while Android users need to “root” their devices. You might invalidate the warranty but it’s entirely legal – despite Apple’s best efforts to argue otherwise. After fiddling with the firmware of the tech product you legally own, it can open up a whole new world of possibilities. This is ultimate consumer power: going out and grabbing for yourself the functionality that for whatever reason your vendor has decided not to build into the product. With jailbreaking, you could do things like add icons to your iPhone lock screen; download banned apps; customize the Control Center and much more.
But there is a problem. As the Internet of Things works its way into an ever more diverse range of devices and systems, so regulators are finding it necessary to step in and create new rules for how these systems can be used. These rules effectively work to lock down the firmware on these devices so it can’t be altered, sending the regulators on a collision course with consumers. So far, there’s been little in the way of technology innovation to address this conundrum, until the prpl Foundation set out its advice in the new guidance document.
To highlight the problem, let’s briefly look at three examples:
The FCC is looking at regulating to mandate that the firmware in domestic Wi-Fi routers can’t be replaced, as prpl explains in detail in this blog post. Why? It’s doing this for a rational reason: spectrum is a finite resource and it’s the FCC’s job to provide rules for managing it. There are effectively only 11 channels in the US available to domestic Wi-Fi networks – only three of which don’t overlap. Each channel can have more than one network on it but these networks must share bandwidth. So if any individuals were able to tamper with their devices to increase power levels, they would gain range and speed at the expense of their neighbours, who would be left with no connectivity.
The problem is that the FCC’s solution may also effectively prohibit users from tweaking their routers for legitimate purpose, such as installing security patches or new open source operating systems – more of which in part 2 of this blog.
We all know that our automobiles are getting smarter. In fact, it’s an industry further down the IoT road than many others. Smart sensors control a range of functions inside automobiles from emissions to the in-vehicle entertainment system, brakes and even steering on some advanced models. It was just such a reliance on embedded technology which researchers Miller and Valasek demonstrated could be exploited by remote attackers to take control of a vehicle.
Tech savvy drivers might want to tweak the software inside their car to play around with entertainment systems and the like, and shouldn’t be prevented from doing so – after all they’ve probably paid a lot of money to own the vehicle. But what happens when a regulator wants to control vehicle emissions? How can they lock down the firmware in a way which doesn’t also make the embedded systems in the automobile impossible to alter for the driver?
Look in the stores and you’ll see unmanned aerial vehicles everywhere. I’m not talking about military grade drones here, more like tiny flying machines you can attach cameras and control with a smartphone. As of now they’re not regulated. But the potential for these flying consumer electronics products to cause serious harm to others is undeniable. Just think about the havoc that one could cause if it were dropped onto a freeway, or flown into a plane on take-off. Are we confident they can’t be hacked? No – especially as systems with far more R&D spend like connected cars, smart rifles and aircraft guidance systems – have already been hacked by researchers.
Once again we are presented with the challenge: how do regulators impose their control on the software to make it safe, whilst protecting the consumer’s rights?
* * *
In the next post I’ll explain how prpl Foundation’s hardware-led approach based on open source, secure boot and chip-level virtualization can give us the best of both worlds.
* * *
prpl Security Guidance for Critical Areas of Embedded Computing is available for download at http://prpl.works/security-guidance/