Tag: Videos

The Librem Key Makes Tamper Detection Easy

From the beginning we have had big plans for the Librem Key. When we first announced our partnership with Nitrokey to produce the Librem Key all we could talk about publicly was the standard USB security token features it would have and some of the integration possibilities between the Librem laptop and Librem Key that would make security easier for the average person. What we couldn’t say at the time was that we were also working toward making the Librem Key do something that doesn’t exist anywhere else–integrate it with the tamper-evident Heads BIOS to make it incredibly easy to tell whether your BIOS has been tampered with. In this post I’m going to talk about why we wanted to add this feature, some of the work that went into it, and dive into some of the technologies that are working behind the scenes to help you understand how it works.

Making Heads User Friendly

Heads is an incredibly powerful and cutting edge project that takes the boot-time security protections you get with products like Secure Boot but using free software, reproducible builds, and keys that are fully under your control. We are working toward our goal of having Heads on all of our laptops by default, but when we started working on that effort we realized that the default user interface was definitely aimed more toward security experts. At the time, when you booted into Heads you got a console screen with a text menu. If Heads detected any issues, typically it would dump you to a recovery shell with some technical error output.

Since we think every user would benefit from the protections Heads provides, we have done a lot of work to bring more user-friendly GUI menus to Heads. We started with a console-based GUI and later added our own custom tool fbwhiptail which uses the same syntax as the standard whiptail console menu tool used by Debian but outputs an even more user-friendly GUI on a framebuffer.

Default Heads Boot Menu
Default Heads Boot Menu

As we continued to work toward making Heads more user-friendly, we realized we had an opportunity with the Librem Key to add an incredibly powerful, secure, yet easy to use way to detect tampering that was much better than the default. Before we talk about where the Librem Key fits in, though, it’s important to understand how Heads detects tampering by default.

How Heads Detects BIOS Tampering

Heads uses the TPM in a computer as a standalone, trusted, tamper-proof chip it can use to store BIOS measurements and secrets. In my post Demonstrating Tamper Detection with Heads I walk through the full process but I will highlight some of the relevant points here.

The way Heads protects the BIOS from tampering is that when you first set up Heads, you store the current BIOS’s measurements into special registers in the TPM called PCRs (Platform Configuration Registers). At this time Heads also generates a random string and using the TPMTOTP tool originally created by Matthew Garrett it stores this secret in a special encrypted register in the TPM–this process is called sealing. The TPMTOTP tool also takes this secret and converts it into a QR code it displays on the screen. Then you can use a multi-factor authentication application on your phone to take a picture of this QR code and add this to any other multi-factor authentication secrets you manage.

The next time the system boots, measurements from every executable part of the boot process is sent by Heads to the TPM and stored in PCRs. Then Heads requests for the TPM to unseal the TPMTOTP secret it added previously. The TPM will only unseal that secret if all of the measurements in its PCRs match what it has stored from the valid, un-tampered-with BIOS. Once the secret is unsealed, Heads uses TPMTOTP to combine that secret with the current time and convert it into a 6-digit code. You then open up your multi-factor authentication application on your phone and compare the 6-digit code on your laptop screen with the 6-digit code on your phone. If both codes match, the BIOS hasn’t been tampered with. If the codes don’t match, either the time is off on either device, or someone has tampered with the BIOS or the TPM and generated and stored a new secret to replace the old one.

Improving on TOTP Codes

It’s important to note that Heads does not require you to verify the TOTP (Time-based One Time Password) code on the screen each time you boot. In fact it has no way of knowing whether you have or not–the whole point is that the laptop is authenticating itself to you, not the other way around. So there’s a good chance that your average user may not feel like going to the trouble of getting out their phone, launching an app, and inspecting the code each time they boot. Plus, this process requires that a user must have a smart phone that can run one of these apps. Users might test the code every so often but I imagine many would just hit Enter and boot their system more often than not.

We realized we could make the process more convenient and easier to use by taking the phone out of the equation or at least adding a Librem Key to the equation. While the Librem Key doesn’t have a screen like a phone, it does have a green and red LED. What could be easier than plugging in a USB device, booting the computer, and then inspecting the LED to see whether you are safe? By making it easy, users would be more likely to test their BIOS at each boot.

HOTP to Trot

Since we were working with Nitrokey to produce the Librem Key, we started collaborating with them on this feature. The first step was to think through how this authentication would work. Because the Librem Key doesn’t have a clock of its own, and we don’t want it to trust the clock on the laptop, we decided to use HOTP (HMAC-based One Time Password) instead of TOTP as our authentication protocol.

HOTP and TOTP are very similar to each other. In fact, you can argue that TOTP is just a specific implementation of HOTP. With HOTP both sides have a shared secret and initialize an always-incrementing counter. Each side combines its secret with the current counter value and generates an HMAC (hashed message authentication code) that in this case is converted into a 6-digit code. If the codes match, then one side has proven to the other that it has a copy of the shared secret and both sides will then increment their counter. With TOTP, you just exchange the always-incrementing counter with the current timestamp, typically rounded to 30-second increments.

For this to work we needed not only to change the firmware we were going to use for the Librem Key so that it could accept this special HOTP-over-USB authentication, we also needed a userspace tool that knew how to talk to the Librem Key. The end result after working with Nitrokey was a couple of changes to the firmware and a completely new userspace program called nitrokey-hotp-verification that contains two command-line tools we needed to include in Heads, libremkey_hotp_initialize and libremkey_hotp_verification. The former tool will initialize the a Librem Key with the current HOTP secret and counter value and the latter performs various HOTP functions with the Librem Key including testing a 6-digit HOTP code.

Heads, Meet Librem Key

The next step was to add Librem Key support to Heads. This required quite a few UI changes, modifications to the default tools it used when generating new TOTP secrets, and adding libremkey_hotp_initialize and libremkey_hotp_verification command line tools within Heads itself. Instead of doing away with the TOTP code we are actually using the same exact TPM secret, just in addition to converting it into a TOTP code, we are also combining it with the incrementing counter to generate an HOTP code too. So when you tell Heads that you want to seal a new TOTP secret, if your version of Heads has Librem Key support enabled, in addition to showing you a QR code, it will also prompt you to insert your Librem Key and set up the secret there as well using the libremkey_hotp_initialize program.

The next time you boot, in addition to displaying the TOTP code in the menu as always, it also attempts to communicate with your Librem Key using the libremkey_hotp_verification tool. If the Librem Key isn’t inserted, it gets a specific error and warns the user that the key isn’t plugged in, but it doesn’t stop the user from booting. If the user then plugs in the key and tells Heads to regenerate the code, it can do a second test from the GUI. If you lose your Librem Key or leave it behind somewhere, you can always just fall back to the standard TOTP code + phone approach until you have a new Librem Key to enroll.

After Heads sends the Librem Key an HOTP code, if the code matches what the Librem Key itself generates, it will flash a green LED and return a success code to Heads to display on the laptop screen. If the HOTP codes don’t match, the Librem Key will flash a red LED indefinitely and also send a specific error back to Heads which will cause it to show a red background and error dialog. Note that you shouldn’t trust the Heads UI to display this error, it’s only for convenience. A modified UI could lie to you so you should only trust the Librem Key LED at this phase of the boot process.

Demo Time

Here’s a short demo video of the Librem Key testing a valid BIOS and then one that detects tampering with Heads.

To simulate tampering, I just generate a brand new TOTP/HOTP secret in the TPM with the Librem Key unplugged. Since the Librem Key has the old secret, it will generate a completely different 6-digit HOTP code and take that as an error.

Anti-Interdiction Protection and The Future of Librem Key and Heads Integration

As I mentioned in the Introducing the Librem Key post, having the Librem Key vouch for the integrity of the BIOS opens up a lot of opportunities for more advanced anti-interdiction protection for those customers who are concerned about that risk. The way this would work, we would configure a Librem Key and Librem laptop running Heads before shipping and then ship the two packages separately. The idea here is that it would be more difficult for an attacker to interdict both packages than just one.

Then when you unbox everything, you can immediately test the integrity of your machine before you do anything else. At that point you could also generate completely new secrets between Heads and the Librem Key so there’s not even a chance we could have a copy of your secrets–the keys are under your control. For customers willing to wait, we could even ship the Librem Key first and only ship the laptop after they acknowledge receipt of the Librem Key. With delayed shipping you would have even more assurance that someone wouldn’t be able to modify both the Librem Key and laptop in transit.

If you can’t tell, we are very excited about all of the possibilities the Librem Key opens up to us to better protect you and your secrets, while still keeping security convenient and your keys in your own control. Stay tuned: as we unlock even more features in the Librem Key we’ll be sure to post about it here.

Introducing Calls on the Librem 5

Introduction

Arguably the most critical functionality in a phone is the ability to make and receive calls through the Public Switched Telephone Network (PSTN), that is normal cellular calls using phone numbers. While at Purism we are eager to implement communication systems that enable much greater privacy and security than one can expect from PSTN calls, the PSTN is still the most ubiquitous network and for the time being we can’t very well go around selling a phone that isn’t able to make PSTN calls. Read more

Demonstrating Tamper Detection with Heads

We are excited about the future of Heads on Librem laptops and the extra level of protection it can give customers. As a result we’ve both been writing about it a lot publicly and working on it a lot privately. What I’ve realized when I’ve talked to people about Heads and given demos, is that many people have never seen a tamper-evident boot process before. All of the concepts around tamper-evident boot are pretty abstract and it can be difficult to fully grasp how it protects you if you’ve never seen it work.

We have created a short demo that walks through a normal Heads boot process and demonstrates tamper detection. In the interest of keeping the demo short I only briefly described what was happening. In this post I will elaborate on what you are seeing in the video.

Step One: Normal Boot

The normal boot process for a computer that uses Heads is much like with any other computer, at least from a user experience standpoint. Like with other computers, you can bring up a full menu of different items to boot, but you can also pick one to set as your default. Once you set a boot option as a default, at boot time you can just press Enter and it will boot into your operating system just like with any other system.

Default Heads Boot Menu
Default Heads Boot Menu

Unlike with other systems, Heads is providing extra levels of security during the boot process. At that default boot screen, you will see a 6-digit number above the menu options. That is a TOTP (Time-based One Time Password) code that Heads uses to prove to you that it hasn’t been tampered with and can be trusted. If you’ve ever used a TOTP code in the past, normally it’s so you can authenticate yourself to a website using Two-Factor Authentication. In this case it’s the reverse: the computer (specifically Heads) is authenticating itself to you! If that code matches the code on your phone, you know it’s safe to proceed.

Once you hit Enter during a normal boot, Heads then verifies the signatures of all of its configuration files stored in /boot based on the copy of your public GPG key it has within it. These configuration files include a file that contains sha256 checksums for the rest of the files in /boot. Once it verifies your signature for that file, Heads can trust it hasn’t been modified so it uses it to make sure the rest of the files in /boot haven’t changed. Since all of them match, they weren’t tampered with so Heads proceeds with the boot process.

Step Two: Hack The Computer

Hacking grub.cfg
Hacking grub.cfg

Once the computer boots, I put my black hat on and “hack” my computer by defacing my /boot/grub/grub.cfg file with a comment. This is a benign hack for demonstration purposes, but the attacker could have just as easily modified grub.cfg to boot from an older kernel on your system that has a known security vulnerability, added a single user mode, or otherwise altered the boot process to make it easier to launch another attack.

An attack that changes a plain text configuration file leaves a trail that might be easier for a user to detect if they happened to edit the file themselves. A more sophisticated hacker would put a back door into your default initrd file (the initial file system your kernel uses when it boots) or even replace your kernel with a compromised version. Both of these kinds of attacks are almost impossible to detect without a system like Heads. Because all of these files are stored in /boot, and Heads checks all of them, it is able to detect all of these types of tampering.

Step Three: Detect Tampering

When the system reboots, it returns back to the main Heads boot screen. First I hit Enter to select the default boot option but this time when Heads scans all of the files in /boot, it detects that grub.cfg has been changed! Along with the warning, I also get the option to re-sign all of the files in /boot. This option exists because there are a number of perfectly legitimate reasons why your grub.cfg, initrd, kernel, or other /boot files might change either because you edited them yourself or you updated software that changed them. Otherwise if you don’t want to re-sign files you can return to the main menu.

Tampering detected!
Tampering detected!

If you choose to re-sign all of the files, you will get an additional warning screen that explains what Heads is about to do and another chance to exit out to the main menu. If you did choose to re-sign all of the files you would then insert a USB GPG smart card that held your private keys so you could re-sign the Heads configuration files in /boot.

Since I knew that I didn’t want to keep that “hacked” grub.cfg file, instead of signing the files I returned to the main menu. By default Heads used to error out to a recovery shell if it detected a file was tampered with. The assumption is that the expert user could then investigate and remedy the problem from within that shell. If you aren’t an expert user in this situation you might not know how to recover and would end up being locked out of your computer!

We understand that there are a number of situations where a user might legitimately or accidentally change files in /boot and while it’s not advisable to boot into a system that is actually tampered with by an attacker (because among other reasons, an attacker might be able to get your disk encryption or login passwords), we also don’t want to lock you out. We’ve added an “insecure boot mode” to Heads for these circumstances. When you select that option, Heads will ignore any tamper warnings and present you with a GRUB-style menu of boot options. You can then select a boot option and Heads will boot into your system. To make sure you know that this is an unsafe option, in addition to the warnings in the user interface, we also disable the splash screen and change the console to have a red background.

Insecure boot mode
Insecure boot mode

Step Four: (Optionally) Investigate Tampering

So what should you do if Heads alerts you to tampering? Exactly how you respond to a potentially legitimate tampering alert depends on a number of factors including what kind of user you are. I’ll step through three of the most common categories of Heads user and describe how they might respond to a legitimate tampering alert.

Category 1: Enterprise User

In the event of tampering, enterprise users would just hand the laptop over to their IT team and pick up a replacement while the IT team investigates. Some organizations might want to go a step further and work with us to customize their Heads image with branded and customized warning messages with their custom policies or direct the employee to an internal wiki or other resources. Some enterprises may even want to go even further and remove the ability to boot a machine that sets off tampering alerts. This would also be useful for employees who take their machine overseas to ensure the machine is in a safe state before they reconnect it to the corporate network.

Once the IT team receives the laptop, they can then inspect the laptop for tampering using their in-house tools and procedures, and then reflash the system back to their secure, internal image. For smaller organizations who may not have those capabilities, Purism also provides support services to bring the laptop back to a clean factory state.

Category 2: Expert-level End User

The expert level user will likely want to inspect the system themselves in the event of a legitimate tamper alert. While I demonstrate the insecure forced boot mode in the demo, the expert user would likely use the Heads recovery shell or boot into a USB recovery disk instead (like the PureOS live install disk) to investigate from there. Otherwise, when they boot their compromised system, they will be prompted for their disk decryption passphrase and login password and risk turning those secrets over to the attacker.

While the Heads recovery shell is limited to a small subset of Linux command-line tools, it has enough tools for the expert user to inspect files in /boot including a text editor to inspect grub.cfg and tools to mount the encrypted root file system from a trusted environment. Provided you trust Heads itself hasn’t been tampered with, you could inspect quite a bit just from this recovery shell alone.

If the Heads recovery shell didn’t provide enough tools, the expert user could also boot from a USB disk, mount the /boot partition and inspect the changed files. In the case of a modified grub.cfg they would just use a text editor for this. In the case of a modified initrd they would need to extract the file and inspect the extracted file system. From there they could also decide to mount the root file system and inspect it for rootkits as well. For users who may suspect Heads itself was tampered with, they would be able to use flashrom to pull down a copy of the version of Heads on the system and inspect it directly.

Category 3: Everyone Else

The average user is unlikely to put on their forensics hat and inspect a compromised system. While for the most part any alerts an average user will see will likely be a direct result of package updates or other changes they know they made, there’s a possibility that sometimes they might get an alert they weren’t expecting. For instance, if you took your laptop overseas on a trip and didn’t update it or otherwise change it during the trip, a tampering alert when you got home would be much more suspicious.

So what’s the average user to do? No matter what, you can always fall back to the insecure boot mode so you won’t lose access to their system or files. In that case even if you couldn’t inspect or fix the errors yourself, you could at least backup your personal files and reinstall the OS to get back to a safe state. Alternatively like with enterprise users you could also take advantage of Purism support services to reflash your system to a factory state.

Conclusion

Hopefully watching Heads in action has helped make it a bit more clear just how it will protect you from tampering. In future posts I will walk through other Heads features and workflows including registering a new TOTP code and completely resetting the TPM.

Librem 13 Promotional Video

Let me introduce to you the new Librem 13 video.

Unlike the other videos I have made to promote this beautiful laptop, I decided, this time, to stay away from any 3D computer graphics and to shoot the real device in a studio made for the occasion.

This was pretty challenging as I wanted a black background with a reflective ground along with smooth camera and light movements. We also had to deal with things that don’t exist in the world of computer graphics like dust and fingerprints (what a nightmare that was!).

This video has been shot in 2 days and was entirely edited and color graded with Kdenlive on PureOS 8, all smoothly running on the Librem 13 itself.

This video is released under the CC BY-SA license (by Purism), so feel free to use it and share it as much as you like!