Firmware security for IoT devices
March 02, 2018
Product
Over the past several years, the Internet of Things (IoT) has been touted as the Next Big Thing as well as the Internet of Crappy Things. Both descriptions are justifiable.
Over the past several years, the Internet of Things (IoT) has been touted as the Next Big Thing as well as the Internet of Crappy Things. Both descriptions are justifiable. Poorly protected IoT devices have been used in numerous Distributed Denial of Service (DDoS) attacks and supposedly helpful and friendly devices have invaded the privacy and exposed the personal information of their users.
I’m sure the developers and manufacturers of these devices are paying attention and, as a result, they will likely fix the obvious problems with authentication/authorization, insecure web interfaces, poor network services, and encryption, and the inability to update the software when security or other flaws are found. What I am concerned about is that they are not paying enough attention to what the traditional computing industry has discovered the hard way.
Once the easy and obvious security flaws have been corrected, the evil doers will move on to other attack surfaces. These other vulnerabilities that computer makers have had to deal with will undoubtedly be the next target of IoT hackers. This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.
Why IoT firmware is an issue
Many in the IoT ecosystem seem to consider their devices as simple, single use, throwaway devices, such as a basic appliance or embedded system that you ship and forget. This perception is problematic, as more and more IoT devices continue to be developed.
- By definition, IoT devices are internet connected. That means a network stack, communications protocol, applications on the device and in the cloud, can take advantage of the data made available by the device and all the attacks implied by this connectivity. This connectivity makes these devices desirable targets and any security flaws open the door for attackers.
- Due to the complexity and scope of IoT devices, in most cases, they must be updateable in the field. The number of these devices and their usage model drives the update capability to be automatic and remotely initiated. This provides another attack vector for those who would change their software to alter their behavior.
Such attack vectors are not a new phenomenon. Network connected computer systems have been dealing with them since the advent of the internet. The problem has been that the developers of IoT devices have seen their gadgets as simple, single purpose devices that are not susceptible to nefarious acts, and therefore, not easily attackable. Well, it turns out the opposite is true. The bad guys can either steal user’s data, use the device to spy on the network infrastructure inside the user’s firewall, or use the device as a launch platform for attacks on other systems.
What to do about it
Fundamentally, the software/firmware of IoT devices must be protected in the same way code must be protected in general-purpose computer systems. This includes the firmware and software that initializes the device’s hardware, loads and starts up the device’s software (system and application), as well as the process in which the IoT device’s firmware and software are updated.
Platform firmware and startup security
Since the early days of computing, platform firmware has been created to initialize the system hardware and load the initial software. For traditional computing platforms, this software was typically an operating system loaded from a disk, but even on embedded platforms without a traditional operating system, software is typically loaded from a slow non-volatile storage into faster RAM memory for normal operations. When IBM created their PCs, they developed firmware called BIOS (Basic Input/Output System) for this task. This original BIOS was cloned and used across many platforms; however, as computing systems became more complex, and it became difficult for processors to emulate the behavior of 1970’s PCs; a new standard was born. While simple embedded and SoC systems moved to monolithic solutions like U-Boot and coreboot, most larger and general-purpose systems looked to the UEFI standard.
The Extensible Firmware Interface (EFI) design was initially created by Intel for a new generation of processors and eliminated most of the architectural limitations of BIOS. Intel tried to socialize EFI as general replacement for BIOS across the industry, but because it was “owned” by a single major industry player there was some resistance to the idea. Instead, Intel contributed the design to the industry and helped found the Unified Extensible Firmware Interface (UEFI) Forum to manage the architecture going forward. Today, the UEFI Forum is made up of over 300 companies and is responsible for development and evolution of the UEFI standards.
One of the initiatives taken on by the UEFI Forum has been the security of systems as they start up, and when inevitably, their firmware/software needs to be updated. It has been shown that if an attacker can get control of a system during the system startup and boot process, they can completely “own” what happens with that system. Ultimately, attackers can then disable protections provided in the software after boot-up and load whatever other programs they so choose. Additionally, they can modify normal software to do their bidding before it has even been started. If the bad guys can get control of the system early enough, that system can be compromised entirely.
The same is true if the code update process is compromised. If a hacker creates their own code and swaps it with the code originally provided by the system manufacturer, then all the bad things listed above can also be accomplished in a system with a compromised system update.
The UEFI specification provides standard interface descriptions and an architecture designed to significantly limit such threats. The two primary technologies used to secure a system from these threats are:
- Secure Boot – Requiring all software components of the system to be cryptographically signed or they will not be allowed to run. This prevents compromised components from being run during system startup, maintaining a root-of-trust that can be continued all the way to the application software itself.
- Capsule Update – This requires all system updates be cryptographically signed and provides facilities to ensure that the system firmware/software cannot be rolled back to a less secure version.
UEFI is the only firmware solution that includes these security features as part of its industry standard. Also, while many security researchers and hackers have been testing its design, no one has been able to find any flaws in the security architecture. A few implementations have been flawed, but not the design.
There are many more security related capabilities provided by UEFI, but they are beyond the scope of this article. I refer you to the http://www.uefi.org website for the specifications, white papers and training materials.
So why isn’t everyone using UEFI firmware?
If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it? I believe there are a couple of major reasons:
- Many IoT developers come from the embedded/SoC space where monolithic boot solutions are prevalent. Despite the limitations of solutions like U-Boot and coreboot, developers tend to use what they know and are comfortable with.
- There are a number of misconceptions and “alternative facts” about UEFI firmware that limit its acceptance in certain communities. Examples of these misconceptions are: it is too slow; it is too big; the architecture is too complex; it is not “open;” etc. These are largely debunked in a UEFI white paper on the uefi.org website.
Where do I go from here?
So, I hope I have convinced you to, at least, consider UEFI as a firmware design alternative for your next IoT device. How do you get started?
Downloading the latest UEFI Specification and trying to read it cover to cover it is probably not the best way to start. First, UEFI is an interface specification, not an implementation. The specification supports many capabilities that you probably will not need in your device, and the size of the specification can seem daunting at first glance (2000+ pages!). Only a handful of basic capabilities are required to be compliant with the specification and you can pick and choose from the others based on your needs. There are many educational materials, books, and presentations on the uefi.org website.
As an interface specification, it does not drive the actual code implementation of the services described. There is an open-source example implementation available at Tianocore.org, along with decent documentation, which include full implementations for several Intel reference platforms as well as code that may be used to create solutions for other platforms. There are also bindings for ARM processors and platforms and the ARM folks have provided a document describing the requirements for UEFI on ARM-based devices. I have even heard that there are implementations of the UEFI interfaces layered on an underlying coreboot code base. It is completely up to you what your implementation looks like and what capabilities are needed and implemented.
There are several independent firmware vendors who would be happy to help you create a custom UEFI implementation just for your device.
Bottom line
IoT devices are true network-connected computing devices with all the attendant risks. An IoT device with weak security not only risks the device itself and its data, but other devices in the local network and the internet at large. As creators of these devices fix their obvious security limitations that some devices have displayed, the bad guys will look for other attack vectors. These attack surfaces will include attacking device firmware and software update mechanisms. To keep your customers and other stakeholders happy, you owe it to yourself to consider an implementation of UEFI for your IoT device.
He has over 30 years’ industry experience in roles from software engineer to director of engineering at companies including Hewlett-Packard, Microsoft, Amazon, Digital Equipment Corp. and others. Professor Wilkins travels extensively to Taiwan, Japan and around the USA to deliver presentations on Cyber Security of computing systems and consults with several multinational companies.
Dr. Wilkins holds a Ph.D. in Computer Science from Nova Southeastern University, Ft. Lauderdale FL; a Masters of Science in Computer Science from the National Technological University, Ft. Collins, CO; and a Bachelor of Arts in Public Administration from Saint Thomas University, Miami, FL.
