if (!isset($meta_desc)) { $meta_desc = "Leavitt Communications is a full-service international marketing communications and public relations agency established in 1991"; } ?>
Feature Story
More feature stories by year:
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Return to: 2016 Feature Stories
CLIENT: PRPL FOUNDATION
Feb. 25, 2016: IEEE Computing Now
IEEE Computing Now, Feb. 25 - by Art Swift
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. But 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.
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.
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.
Building security into the hardware of embedded systems in this way will help regulators lock down specific harmful functions whilst 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:
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 OS 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.
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.
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.
* * *
prpl Security Guidance for Critical Areas of Embedded Computing is available for download at http://prpl.works/security-guidance/
Return to: 2016 Feature Stories