Trying out UEFI boot security on a recent Linux system

With Your Own Keys

The following section shows how to install and configure Debian 7.1.0 in a dual Secure Boot environment alongside Windows  8 Pro. The intent is for the Debian system to be operational, independent of certificates by Microsoft, with Secure Boot enabled and without affecting the operability of Windows  8 Pro. We do not want either of the two systems to be able to modify the UEFI certificate store.

Once installation of the operating systems is completed successfully, the bootloader on the Debian system needs to be signed or its hash added to the db certificate store. Signing the installed bootloader, however, would entail a significant disadvantage: When the system updates the bootloader, it does not have a valid signature or the hash is invalid, which means subsequent boot operations will fail. For this reason, we create another bootloader, which we call the Secure Boot preloader. We change the system configuration so that the Secure Boot preloader is executed by the UEFI firmware instead of the bootloader, which is set up during the installation of Debian. The Secure Boot preloader then loads the original bootloader without any further validation. As a result, only the preloader has to be signed. To set up the Secure Boot preloader, you can use the commands in Listing 1.

Listing 1

Creating a Preloader

 

Afterward, you need to sign the Secure Boot preloader with:

sbsign --key db.key --cert db.pem.crt/boot/efi/EFI/debian/secure-boot-preloader.efi

The sbsign tool takes care of signing the bootloader; sbsign comes with the sbsigntools toolbox.

This command assumes the private key used for signing UEFI applications resides in the db.key file and that the associated certificate resides in db.pem.crt. The signing step should not take place on the affected system itself, but in a safe working environment, to keep the private key secure.

After setting up the bootloader, you need to modify the certificate store of the UEFI firmware. We used the EFI tools to modify the certificate store. To this end, you need to create a bootable USB stick containing the efitools package. A suitable image is provided by the author of efitools [2]. You can use the tool dd to copy it to a USB stick then convert both the Microsoft Windows Production PCA 2011 certificate and the keys belonging to your own key material (PK, KEK, db) to a format that the UEFI firmware can process. The cert-to-efi-sig-list command from the EFI Tools handles this conversion.

To make the changes to the certificate store, you now need to switch the Secure Boot system on the platform to Setup mode using UEFI Setup. The exact procedure for switching to Setup mode is platform specific.

After that, boot from the prepared USB stick. In the UEFI shell, enter the following commands to launch KeyTool. KeyTool provides a rudimentary text-based interface for modifying the UEFI certificate store:

fs0:
cd EFI
cd BOOT
KEYTOOL.EFI

The menu item Edit Keys opens a submenu that lets you modify the PK, KEK, db, dbx, and MOK list certificate stores as follows:

  • MOK list – Remove any existing certificates and hashes.
  • db – Remove any existing certificates and hashes; add the Microsoft Windows Production PCA 2011 certificate. Add your own certificate for signing UEFI applications. Alternatively, you can add a hash of the bootloader.
  • dbx – No changes necessary.
  • KEK – Remove any existing certificates and hashes; add your own KEK certificate.
  • PK – Add the certificate for your own platform keys.

Note that the modification of the PK certificate store must be the last step, in that adding a platform key quits Setup mode and changes to User mode. Subsequent manipulation of the certificate store is then only possible using signed updates or deleting the platform keys with UEFI Setup. After this step, you can launch Debian with Secure Boot enabled.

Conclusions

The UEFI implementations of the platforms we investigated faithfully kept to the Secure Boot specification – or at least to the extent we investigated in this article. The Microsoft Windows Production 2011 PCA certificate required by Microsoft as part of Windows Hardware Certification Program and the optional Microsoft Corporation UEFI CA 2011 certificate are provided by all the PC vendors we investigated. The UEFI CA 2011 certificate basically ensures the functionality of operating systems from vendors other than Microsoft with Secure Boot enabled.

Many current operating systems, such as Windows 8 Pro, Ubuntu 13.04, and Fedora 19 already provide support for Secure Boot. The actual security benefit, however differs strongly among the operation systems we investigated. The investigated operating systems that do not natively support Secure Boot  – more specifically, Debian 7.1.0 and Red Hat Enterprise Linux 6.4  – can be talked into running with Secure Boot enabled with very little effort on all investigated hardware platforms.

Secure Boot has the potential to protect a system against unauthorized tampering. Although a number of challenges exist and further measures are needed for complete protection, Secure Boot can still help the owner retain sovereignty over the IT system.

Another strength of Secure Boot is that the owner of the IT system can decide which specific protection measures they want to implement. Users can therefore create custom security solutions and optimize the overhead to security ratio.

One major disadvantage of Secure Boot is that you absolutely need UEFI. Developers currently have very little practical experience with security for UEFI-compatible firmware. Thus, there is a real risk that the potential safety benefits of Secure Boot will be compromised by (intentional or unintentional) implementation errors in the firmware. In particular, the flexible extensibility and the feature scope give manufacturers an easy option for implementing backdoors. Additionally, the success of any potential safety gain depends on the ability to integrate Secure Boot into the operating system. Although Secure Boot is freely configurable on all the platforms we investigated, future implementations might restrict this ability and bind devices to a vendor's software.

Acknowledgement

The study described in this article was conducted as part of a project for Germany's Federal Office for Information Security.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News