Mender blog

Secure boot support for Debian-derived distributions

Secure Boot is a service offered by the UEFI boot firmware which verifies that all executable code loaded during the boot process is signed by a trusted key. This ensures that none of the privileged software on the device has been tampered with. In a Linux system, this encompasses the boot loader, the kernel, and device drivers.

What is Secure Boot?

When the device starts, the firmware checks the signature of each software component involved in the boot process, including the UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system’s kernel. Most x86 hardware comes from the factory pre-loaded with the Microsoft public certificate. This means the firmware on these systems will trust binaries that Microsoft signs. When you install Windows, all the software involved in the boot process is signed with the Microsoft keys, which is why the firmware will load them.

The Original Equipment Manufacturers (OEMs) can opt for using their own keys instead, in which case they have to take extra steps to load the public certificate into the firmware and sign the software involved in the boot process with the new keys. Please note that the firmware uses the “public certificate” embedded to confirm that the software involved in the boot is signed with the correct “key”. A central Certificate Authority signs trusted boot applications and issues new keys. This works analogously to the PKI infrastructure used for the web. For a setup with custom keys, the OEM is expected to have that infrastructure in place.

How does Secure Boot work on Linux?

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that Microsoft signs. Most modern systems will ship with Secure Boot enabled and won’t run any unsigned code by default. While it is possible to change the firmware’s configuration to either disable the Secure Boot altogether or to enroll extra signing keys, this would require the machine owner to perform additional steps to activate Secure Boot.

A group of Linux developers from different distributions worked together to simplify this process and created shim. This simple software package acts as a first-stage bootloader on UEFI systems. It is standard code that is safe, well-understood, and audited. Therefore, it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only has to worry about signing shim, not all of the other programs that distro vendors might want to support.

The added benefit shim provides is the possibility to act as a second level secure boot check with a different pair of keys. An example might clarify it better:

  1. Firmware a public certificate from Microsoft.
  2. Shim is pre-signed with Microsoft keys; therefore, the firmware will boot shim.
  3. Shim has Canonical’s (Ubuntu) public certificate embedded. The boot application to be loaded after shim (usually the bootloader grub) can now be signed with Canonical’s keys, and shim will allow loading it.

This feature allows Canonical to ship Ubuntu with secure boot working without having to ask Microsoft to sign every new Ubuntu release.

Secure Boot support in mender-convert

Starting from mender-convert version 3.0.0, Mender is compatible and can be used in conjunction with Secure Boot. You can find more detailed information in the Secure Boot page for the System Updates for Debian Family section of our documentation.

Recent articles

The scope of EU Cyber Resilience Act (CRA) compliance

The scope of EU Cyber Resilience Act (CRA) compliance

Explore the scope of the EU Cyber Resilience Act (CRA). Learn about the CRA's scope, and why secure OTA updates are essential for compliance.
An overview of EU Cyber Resilience Act (CRA) compliance

An overview of EU Cyber Resilience Act (CRA) compliance

Learn how the EU Cyber Resilience Act (CRA) enforces stringent cybersecurity requirements for PDEs. Explore compliance essentials in part 1 of a 4-part series.
Challenges in complying with the EU Cyber Resilience Act (CRA)

Challenges in complying with the EU Cyber Resilience Act (CRA)

Discover how manufacturers can achieve Cyber Resilience Act (CRA) compliance by tackling secure updates, SBOM management, and vulnerability tracking with robust OTA solutions.
View more articles

Learn why leading companies choose Mender

Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.

 
sales-pipeline_295756365