The moral of the story you’re about to read is that there are two ways to implement Secure Boot in an embedded device running a Linux® operating system: the really hard way, or a much easier way.
Many developers have discovered how hard the really hard way is through bitter experience. This is an important reason why a Secure Boot function is rarely implemented in embedded devices today, despite its importance in protecting physical hardware from attacks: it just costs too much time and developer resources.
As we’ll see, users of the FoundriesFactory cloud software platform for embedded devices have a much smoother path to Secure Boot implementation – but let’s not get ahead of ourselves. First, it’s important to understand the importance of Secure Boot by putting it in context with other methods for securing a new, connected embedded device.
The concentric rings model of security
When designing a security framework for a device, it makes sense to conceive of protection in terms of a series of concentric rings, like the walls surrounding an ancient castle’s keep. An attacker must breach each outer ring in turn before reaching the device’s core, where the application resides.
In the embedded world, the outer rings are the physical barriers protecting the hardware: these include Secure Boot and secure key storage, which are meant to prevent an attacker from gaining access to the operating system and firmware. Inner rings protect data and application code running on the OS.
If these inner rings are breached and a vulnerability is exploited, then a patch embedded in a software update can close the loophole. This is why, if a development team only has time or resources to implement a single security feature, it should be an over-the-air (OTA) software update capability, to ensure that a device’s exposure to a known threat can be quickly eliminated. OTA is a core function of the FoundriesFactory platform.
But comprehensive protection starts with the outer rings, protecting the physical hardware. And of these rings, Secure Boot is the most important.
Secure Boot: the ingredients need a recipe
The purpose of Secure Boot in an embedded device is to ensure that on start-up the device uses only trusted software, including the Linux OS image. Secure Boot is such a potentially valuable part of a device OEM’s armoury that today, almost every SoC and microprocessor is marketed as ‘supporting’ it. But what is the nature of this ‘support’ for device developers working in a Linux environment?
What it emphatically does not mean is that implementation of Secure Boot will be quick, easy or intuitive. This might be surprising to developers who have worked in the Windows environment with processors based on the Intel x86 architecture. Here, the standardization engendered by the Wintel ecosystem has enabled the development of standard hardware and software components and processes for implementing Secure Boot in a computer’s BIOS. Implementing Secure Boot in Windows is a matter of simply pressing the buttons which Intel and Microsoft provide.
The Linux environment, by contrast, is much more fragmented and heterogeneous. There is no single version of Linux, and no SoC manufacturer dominates the market in the way Intel dominates the x86 world, so no single Secure Boot solution can be applied.
Instead, each SoC manufacturer provides a unique set of components for implementing Secure Boot on each of its hardware platforms, and tooling for programming in the components. But the task of adapting these components for any individual flavor of Linux is left to the device developer. Even those Secure Boot components which are provided are optimized for the SoC manufacturer’s own development board. As soon as development migrates to the OEM’s custom hardware, these components must be ported to the new hardware – they will not work out-of-the-box.
The situation is like being abandoned in an unfamiliar kitchen with a large box of ingredients and a menu to be served to diners, but with no recipe to show how to make the dishes on the menu.
And in fact, implementing Secure Boot is quite complex – it involves a multi-stage transfer of root-of-trust authority to bridge from a hardware security module to the processor’s or SoC’s BIOS, at each stage securely authenticating the signatures of the components on each side of the transfer. Figuring out the recipe from scratch, relying only on the ‘support’ provided by the SoC manufacturer, takes many months of developer time and great effort. It is hard.
On some estimates, as few as 5% of all new embedded devices today are shipped to the customer with a proper Secure Boot function, and the difficulty in implementing it has much to do with this low rate of adoption.
The recipe, and the tools to implement it
There is, however, a different option for device developers: they do not have to rely on the provision for Secure Boot made by SoC manufacturers. The FoundriesFactory platform from Foundries.io is a complete Linux-based platform for the development, security provision and maintenance of embedded devices. Built into the platform is a full-featured Secure Boot module, optimized for the Foundries.io Linux distribution.
It includes not only the ingredients for implementing Secure Boot but also a recipe for putting them together, integrated into the security toolkit at the heart of the platform. And the ingredients can be programmed with dedicated tooling for any supported SoC, all operating within the familiar FoundriesFactory workflow and development environment.
The FoundriesFactory environment makes Secure Boot as simple to implement as it is possible to be. And if the developer encounters a problem with Secure Boot or the wider security environment, the entire platform is backed by Foundries.io’s friendly and helpful technical support service. So this is why there is a stark choice when it comes to implementing Secure Boot: it is either really hard, or much, much easier. And FoundriesFactory is ready and waiting for you if the easier road is the one you choose to travel.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.