• About
• Latest Posts

Purism

Beautiful, Secure, Privacy-Respecting Laptops, Tablets, PCs, and Phones

Latest posts by Purism (see all)

• PureOS Crimson Development Report: October 2024 - November 14, 2024
• PureOS Crimson Development Report: September 2024 - October 16, 2024
• Quantum Safe Communication with Purism - September 23, 2024

We have been busy on the PureBoot front! Recently we announced “PureBoot Basic Mode” which is a low-security option for PureBoot that disables tamper detection, but leaves you with the robust PureBoot recovery console for debugging boot issues. To balance our last “low security” feature, our most recent PureBoot release, version 23, offers a new high-security feature called Restricted Boot. By default PureBoot will allow you to boot any USB disk you choose, and offers a failsafe boot mode so you can boot into your system even if signatures don’t match. Restricted Boot tightens down boot security so you can only boot trusted, signed boot images. In this post I will describe the thinking and design behind Restricted Boot and how it contrasts with boot restrictions on other platforms.

Balancing Security and Freedom

Restricted Boot came out of a request from a number of customers that PureBoot only boot trusted images, and restrict an attacker from booting an arbitrary OS (in particular a USB disk) on an unattended computer. There are a few different ways you could approach a feature like this, and the most common “best practice” approach is one we had to reject. The reasons why go back to how we approach security to begin with, and how we balance it with freedom and control.

Most approaches to computer security are rooted in a belief that the customer should not be trusted and the vendor deserves absolute trust. The vendor naturally trusts themself and sees no reason why the customer shouldn’t delegate all security decisions and trust to them. This leads to security solutions that move all trust and control over security decisions to the vendor so that the customer becomes dependent upon the vendor for their security. If the customer decides they don’t trust the vendor, or they want to do something the vendor doesn’t allow, generally their only recourse is to disable all security measures and take their chances. So the “best practice” way to stop an attacker from booting arbitrary USB disks would normally involve using Secure Boot to block all boot executables that aren’t signed by the computer vendor (typically Microsoft, Google or Apple).

One of the core design criteria that goes into how we develop PureBoot, is how best to secure someone’s computer without removing their control (and therefore their freedom). We try to design security measures that don’t depend on trust in Purism to succeed, but instead give as much control as possible to the person who actually owns the computer. In the case of PureBoot this means using user-controlled keys to sign files, and to focus on detecting tampering, not preventing it, because approaches that prevent tampering also tend to prevent even more legitimate uses. PureBoot can boot all major modern Linux distributions and they do not require Purism’s approval ahead of time. We are also sensitive to locking someone out of their computer, so even in the case where PureBoot detects tampering, we allow you to ignore the error and boot in a failsafe mode.

At a glance our approach to Restricted Boot might sound similar to Secure Boot. After all, once enabled, Restricted Boot will only allow you boot OSes with valid signatures. The difference here is that the signatures are either provided by you (in the form of signed files in /boot) or the OS vendor (signature files the OS vendor signed that go along with their ISOs). All signatures are under your control and you can change them based on which vendors you trust. Also, anyone, (yes, including an attacker), can disable Restricted Boot and then boot an arbitrary OS, or reflash the system with different firmware, so you are never locked out of your computer. However we have designed Restricted Boot in such a way that it can’t be disabled without triggering our tamper detection. I’ll explain more about how that works in a bit.

Using Restricted Boot

Restricted Boot is off by default, because we want people to have the most flexibility to boot whatever OS they desire, and want easy access to the recovery console and failsafe boot options. To enable it, make sure you are running PureBoot version 23 or greater (if not use our coreboot_util script to update to the latest version). Then, go to the main menu and select Options -> Change Configuration Settings -> Enable Restricted Boot.

Once you enable Restricted Boot, save the current configuration to the running BIOS. After you reboot, you will notice that Restricted Boot has disabled a number of options:

• Failsafe boot (so you can only boot signed kernel images on disk)
• Booting from unsigned USB Disks
• Entering the recovery console (so you can’t bypass it with kexec commands on the command line)

During normal use, when you update your OS while Restricted Boot is enabled, it will behave much like you expect. If your kernel changes, you will be prompted to re-sign files in /boot using your Librem Key and once you do, you will be able to boot into your OS as normal.

Booting from USB

If you want to boot off of a USB disk, you will not be able to use an image that has been imaged directly to a USB disk. Instead you will need to copy the ISO file and corresponding .asc GPG signature file the vendor provides, to a USB thumb drive. PureBoot in Restricted Boot will allow you to boot from ISOs on USB disks, provided their signature matches one of the trusted public keys in its ISO keyring (stored at /etc/distro/keys). By default we include public keys for Arch Linux, Qubes, Tails, and PureOS. If you want to change which vendors you trust within Restricted Boot, for now you will need to modify the source files in initrd/etc/distro/keys and build your own custom PureBoot image. Later on we’d like to add a feature that lets you modify this keyring from within the GUI itself, but that feature didn’t make it for this first release. This also means that you could add your own public key to the keyring and boot ISO files that have your signature with them. If you removed all of the other keys you could even set it up so your system only boots ISOs you have personally signed.

Disabling Restricted Boot

To disable Restricted Boot, go back to the configuration GUI where you enabled it, and select Disable Restricted Boot.

To prevent someone from disabling this without detection, once you select this option a window will pop up warning you that it will be enabled immediately.

Once you proceed, PureBoot will update itself and reboot automatically. It will also erase the TOTP/HOTP secret that is in the TPM, which means at next boot you will be prompted to pair PureBoot with your Librem Key again. This is to ensure that if someone other than the authorized user disables this feature, they can’t do it without the authorized user knowing the next time they boot their computer.

Bypassing Restricted Boot

We have tried to maintain a good balance between providing adequate restrictions during Restricted Boot, without locking legitimate users out of their own system. This is why, for instance, we don’t protect this mode with a PIN or password that could be forgotten. Instead we simply erase the shared secret in the TPM automatically, if you disable Restricted Boot, so it shows up as tampering the next time you boot.

While there are still likely edge cases that will turn up, we have attempted to address all the ways an attacker might try to bypass these restrictions. The main safeguard is the fact that we have disabled the recovery console entirely when in this mode. This includes any fatal errors in scripts that might normally dump to a recovery console. Once you have access to the recovery console, you can not only modify all of the GUI scripts directly, you can use tools like kexec directly on the command line to boot into the OS of your choice.

Another way someone might bypass these restrictions is by disabling the Restricted Boot configuration option in the run-time OS without saving it to the running BIOS. Then they could boot their malicious USB disk and at reboot the system would be back to the Restricted Boot system. This is why we don’t offer a way to exit out once someone has chosen to disable Restricted Boot. Instead we immediately erase the shared secret in the TPM before we reflash the BIOS so you can detect the change.

Even with the restrictions we put in place, we do not attempt to address the threat from an attacker who can remove the bottom case and attach hardware flashing equipment to the BIOS chip and flash arbitrary firmware. Anyone who can do that could take a perfect image of the existing firmware, flash regular coreboot and boot their OS, and then reflash the existing firmware. Of course someone who can remove the bottom case, could just as easily remove the disk and attach it to their own computer and perform tampering that way. To address those kinds of threats we encourage people to invest in hardware tamper detection such as using glitter nail polish on the case screws.

The Future of Restricted Boot

This is only the initial release of this new security feature, so while we believe we have tracked down all the edge cases that might allow an attacker to bypass Restricted Boot, there is a chance there is some edge case we missed. We hope you will file a bug report if you do find a way to bypass it without detection. We also recognize that many people may not trust all of the Linux distributions we have added to the keyring by default. While you can modify this list now by building PureBoot yourself, we want to simplify this and allow you to change this keyring from within the PureBoot GUI. Finally, if there are other restrictions you think we should add to Restricted Boot, please let us know with a feature request.

Purism Products and Availability Chart

	Model	Status	Lead Time
	Librem Key (Made in USA)	In Stock ($59+)	10 business days	Learn More Buy Now
	Librem 5	In Stock ($699+) 3GB/32GB	10 business days	Learn More Buy Now
	Librem 5 COMSEC Bundle	In Stock ($1299+) Qty 2; 3GB/32GB	10 business days	Learn More Buy Now
	Liberty Phone (Made in USA Electronics)	Backorder ($1,999+) 4GB/128GB	Estimated fulfillment February	Learn More Buy Now
	Librem 5 + SIMple (3 GB Data)	In Stock ($99/mo)	10 business days	Learn More Buy Now
	Librem 5 + SIMple Plus (5 GB Data)	In Stock ($129/mo)	10 business days	Learn More Buy Now
	Librem 5 + AweSIM (Unlimited Data)	In Stock ($169/mo)	10 business days	Learn More Buy Now
	Librem 11	In Stock ($999+) 8GB/1TB	10 business days	Learn More Buy Now
	Librem 14	Backorder ($1,370+)	Estimated fulfillment December	Learn More Buy Now
	Librem Mini	Backorder ($799+)	10 business days	Learn More Buy Now
	Librem Server	In Stock ($2,999+)	45 business days	Learn More Buy Now