Truth or myth? Five common assumptions about the implementation of secure boot in embedded Linux-based devices

A PC connected to the internet is vulnerable to attack in a multitude of ways, but the authenticity of the operating system that it runs is not in question. If you switch on a PC and the Windows® logo flashes up on the screen, you can be very confident that the computer is running a safe and valid version of the Windows OS.

You have this assurance because of secure boot, a standard authentication function that runs at power-up to authenticate the OS image before it is launched by the CPU. It means that it is almost impossible for rogue OS software to hijack the PC and take over its operation.

Secure boot is an important link in the chain of security for PCs. But embedded devices based on a Linux® operating environment are equally compromised if a rogue Linux image is permitted to run on them. It might seem surprising, then, that the secure boot function is not today universally implemented in Linux-based embedded devices.

Perhaps this is partly because many embedded developers continue to nurse various assumptions about secure boot – assumptions which in some cases are misleading or even downright false. In the course of MontaVista’s many conversations about security with embedded developers, five of these preconceived ideas about secure boot recur time and again.

Developers commonly question the need for secure boot in devices which are protected by firewalls, encrypted network communication and physical access controls.

Some developers who admit the potential risk that the OS could be compromised will argue that the risk is so small, and the cost of implementing secure boot so great, that the effort is not worthwhile.

The Linux community also often questions the role of Microsoft in providing the security keys which underlie secure boot implementations on x86 hardware. To some, this puts in doubt the open-source nature of any Linux-based system implementation that includes a standard secure boot function.

Others worry about the effect that secure boot will have on the performance of the host system.

The last assumption that is frequently aired is that, once a development project has been started without provision for secure boot, it is too late to add it later.

As this list suggests, there are many, widely held reservations about secure boot – yet in the real world, security breaches of connected devices are happening more and more frequently, and with more devastating effect. Of course, security in embedded devices is a topic with many branches, but for Linux users the first line of defence should be the use of an authentic OS image.

Now a detailed examination of the five assumptions listed above is the subject of an article on secure boot published by MontaVista, in which the risks and costs associated with a breach of boot security are described, as well as the resources and tools available to help with secure boot implementation.

Among those resources are the security technology experts at MontaVista, who are on hand to help if you have questions about secure boot.

Leave a Reply

Your email address will not be published. Required fields are marked *