Tag: Boot and BIOS

Why Freedom is Essential to Security and Privacy

This post is based off of “Freedom, Security and Privacy” a keynote I gave at OpenWest 2018. You can see the full video of the talk here.

Freedom, security and privacy are interrelated. The relationship between these three concepts is more obvious in some cases than others, though. For instance, most people would recognize that privacy is an important part of freedom. In fact, studies have shown that being under surveillance changes your behavior such as one study that demonstrates that knowing you are under surveillance silences dissenting views. The link between privacy and security is also pretty strong, since often you rely on security (encryption, locked doors) to protect your privacy.

The link between freedom and security may be less obvious than the others. This is because security often relies on secrecy. You wouldn’t publish your password, safe combination or debit card PIN for the world to see, after all. Some people take the idea that security sometimes relies on secrecy to mean that secrecy automatically makes things more secure. They then extend that logic to hardware and software: if secret things are more secure, and proprietary hardware and software are secret, therefore proprietary hardware and software must be more secure than a free alternative.

The reality is that freedom, security and privacy are not just interrelated, they are interdependent. In this post I will analyze the link between these three concepts and in particular how freedom strengthens security and privacy with real world examples.

Do Many Eyes Make Security Bugs Shallow?

A core tenet of the Free Software movement is “many eyes make bugs shallow.” This statement refers to the fact that with proprietary software you have a limited amount of developers who are able to inspect the code. With Free Software, everyone is free to inspect the code and as a result you end up with more people (and more diverse people) looking at the code. These diverse eyes are more likely to find bugs than if the code were proprietary.

Some people extend this idea to say that many eyes also make security bugs shallow. To that I offer the following counterpoint: OpenSSL, Bash and Imagemagick. All three of these projects are examples where the code was available for everyone to inspect, but each project had critical security bugs hiding inside of the code for years before it was found. In particular in the case of Imagemagick, I’m all but certain that security researchers were motivated by the recent bugs in OpenSSL and Bash to look for bugs in other Free Software projects that were included in many embedded devices. Now before anyone in the proprietary software world gets too smug, I’d also like to offer a counter-counterpoint: Flash, Acrobat Reader and Internet Explorer. All three of these are from a similar vintage as the Free Software examples and all three are great examples of proprietary software projects that have a horrible security track record.

So what does this mean? For security bugs, it’s not sufficient for many eyes to look at code–security bugs need the right eyes looking at the code. Whether the researcher is fuzzing a black box, reverse engineering a binary, or looking directly at the source code, security researchers will find bugs if they look.

When Security Reduces Freedom

At Purism we not only develop hardware, we also develop the PureOS operating system that runs on our hardware. PureOS doesn’t have to run on Purism hardware, however, and we’ve heard from customers who use PureOS on other laptops and desktops. Because of this, we sometimes will test out PureOS on other hardware to see how it performs. One day, we decided to test out PureOS on a low-end lightweight notebook, yet when we went to launch the installer, we discovered that the notebook refused to boot it! It turns out that Secure Boot was preventing the PureOS installer from running.

What is Secure Boot and why is it problematic?

Secure Boot is a security feature added to UEFI systems that aims to protect systems from malware that might attack the boot loader and attempt to hide from the operating system (by infecting it while it boots). Secure Boot works by requiring that any code it runs at boot time be signed by a certificate from Microsoft or from vendors that Microsoft has certified. The assumption here is that an attacker would not be able to access the private keys from Microsoft or one of its approved vendors to be able to sign its own malicious code. Because of that, Secure Boot can prevent the attacker from running code at boot.

When Secure Boot was first announced, the Linux community got in quite an uproar over the idea that Microsoft would be able to block Linux distributions from booting on hardware. The counter-argument was that a user could also opt to disable Secure Boot in the UEFI settings at boot time and boot whatever they want. Some distributions like Red Hat and Ubuntu have taken the additional step of getting their boot code signed so you can install either of those distributions even with Secure Boot enabled.

Debian has not yet gotten their boot code signed for Secure Boot and since PureOS is based off of Debian, this also means it cannot boot when UEFI’s Secure Boot is enabled. You might ask what the big deal was since all we had to do is disable Secure Boot and install PureOS. Unfortunately, some low-cost hardware saves costs by loading a very limited UEFI configuration that doesn’t give you the full range of UEFI options such as changing Secure Boot. That particular laptop fell into this category so we couldn’t disable Secure Boot and as a result we couldn’t install our OS–we were limited to operating systems that partnered with Microsoft and its approved vendors.

Secure Booting: Now with Extra Freedom

It’s clear that protecting your boot code from tampering is a nice security feature, but is that possible without restricting your freedom to install any OS you want? Isn’t the only viable solution having a centralized vendor sign approved programs? It turns out that Free Software has provided a solution in the form of Heads, a program that runs within a Free Software BIOS to detect the same kind of tampering Secure Boot protects you from, only with keys that are fully under your control!

The way that Heads works is that it uses a special independent chip on your motherboard called the TPM to store measurements from the BIOS. When the system boots up, the BIOS sends measurements of itself to the TPM. If those measurements match the valid measurements you set up previously, it unlocks a secret that Heads uses to prove to you it hasn’t been tampered with. Once you feel confident that Heads is safe, you can tell it to boot your OS and Heads will then check all of the files in the /boot directory (the OS kernel and supporting boot files) to make sure they haven’t been tampered with. Heads uses your own GPG key signatures to validate these files and if it detects anything has been tampered with, it sends you a warning so you know not to trust the machine and not to type in any disk decryption keys or other secrets.

With Heads, you get the same kind of protection from tampering as Secure Boot, but you can choose to change both the TPM secrets and the GPG keys Heads uses at any time–everything is under your control. Plus since Heads is Free Software, you can customize and extend it to behave exactly as you want, which means an IT department could customize it to tell the user to turn the computer over to IT if Heads detects tampering.

When Security without Freedom Reduces Privacy

Security is often used to protect privacy, but without freedom, an attacker can more easily subvert security to exploit privacy. Since the end-user can’t easily inspect proprietary firmware, an attacker who can exploit that firmware can implant a backdoor that can go unseen for years. Here are two specific examples where the NSA took advantage of this so they could snoop on targets without their knowing.

  • NSA Backdoors in Cisco Products: Glenn Greenwald was one of the reporters who initially broke the Edward Snowden NSA story. In his memoir of those events, No Place to Hide, Greenwald describes a new NSA program where the NSA would intercept Cisco products that were shipping overseas, plant back doors in them, then repackage them with the factory seals. The goal was to use those back doors to snoop on otherwise protected network traffic going over that hardware. Update: Five new backdoors have been discovered in Cisco routers during the beginning of 2018, although whether they were intentional or accidental has not been determined.
  • NSA Backdoors in Juniper Products: Just in case you are on Team Juniper instead of Team Cisco, it turns out you weren’t excluded. The NSA is suspected in a back door found in Juniper firewall products within its ScreenOS that had been there since mid-2012. The backdoor allowed admin access to Juniper firewalls over SSH and also enabled the decryption of VPN sessions within the firewall–both very handy if you want to defeat the privacy of people using those products.

While I picked on network hardware in my examples, there are plenty of other examples outside of Cisco, Juniper, and the NSA where because of a disgruntled admin, a developer bug, or paid spyware, a backdoor or default credentials showed up inside proprietary firmware in a security product. The fact is, this is a difficult if not impossible problem to solve with proprietary software because there’s no way for an end user to verify that the software they get from their vendor matches the source code that was used to build it, much less actually audit that source code for back doors.

When Freedom Protects Security and Privacy

The Free Software movement is blazing the trail for secure and trustworthy software via the reproducible builds initiative. For the most part, people don’t install software directly from the source code but instead a vendor takes code from an upstream project, compiles it, and creates a binary file for you to use. In addition to a number of other benefits, using pre-compiled software saves the end user both the time and the space it would take to build software themselves. The problem is, an attacker could inject their own malicious code at the software vendor and even though the source code itself is Free Software, their malicious code could still hide inside the binary.

Reproducible builds attempt to answer the question: “does the binary I get from my vendor match the upstream source code that was used to build it?” This process uses the freely-available source code from a project to test for any tampering that could have happened between the source code repository, the vendor, and you making sure that a particular version of source code will generate the same exact output each time it is built, regardless of the system that builds it. That way, if you want to verify that a particular piece of software is safe, you can download the source code directly from the upstream developer, build it yourself, and once you have the binary you can compare your binary with the binary you got from your vendor. If both binaries match, the code is safe, if not, it could have been tampered with.

Debian is working to make all of its packages reproducible and software projects such as Arch, Fedora, Qubes, Heads, Tails, coreboot and many others are also working on their own implementations. This gives the end user an ability to detect tampering that would be impossible to detect with proprietary software since by definition there’s no way for you to download the source code and validate it yourself.

Freedom, Security and Privacy in Your Pocket

Another great example of the interplay between freedom, security and privacy can be found by comparing the two operating systems just about everyone carries around with them in their pockets: iOS and Android. Let’s rate the freedom, security and privacy of both of these products on a scale of 1 to 10.

In the case of iOS, it’s pretty safe to say that the general consensus puts iOS security near the top of the scale as it often stands up to government-level attacks. When it comes to privacy, we only really have Apple’s marketing and other public statements to go by, however because they don’t seem to directly profit off of user data (although apps still could), we can cut them a bit of a break. When it comes to freedom, however, clearly their walled garden approach to app development and their tight secrecy around their own code gives them a low rating so the end result is:

  • Security: 9
  • Privacy: 6
  • Freedom: 1

Now let’s look at Android. While I’m sure some Android fans might disagree, the general consensus among the security community seems to be that Android is not as secure as iOS so let’s put their security a bit lower. When it comes to freedom, if you dig far enough into Android you will find a gooey Linux center along with a number of other base components that Google is using from the Free Software community such that outside parties have been able to build their own stripped-down versions of Android from the source code. While you have the option to load applications outside of Google’s Play Store, most of the apps you will find there along with almost all of Google’s own apps are proprietary, so their freedom rating is a mixed-bag. When it comes to privacy though, I think it’s pretty safe to rate it very low, given the fundamental business model behind Android is to collect and sell user data.

  • Security: 7
  • Freedom: 5
  • Privacy: 1

Over the long run, the Librem line of products aims to address these concerns.

Why Not All Three?

To protect your own security and privacy, you need freedom and control. Without freedom, security and privacy require the full trust of vendors. However, vendors don’t always have your best interests at heart; in fact, in many cases vendors have a financial incentive to violate your interests, especially when it comes to privacy. The problem is, with proprietary software it can be difficult to prove a vendor is untrustworthy and if you do prove it, it’s even harder to revoke that trust.

With Free Software products, you have control of your trust. You also have the ability to verify that your Free Software vendors are trustworthy. With reproducible builds, you can download the source code and verify it all yourself.

In the end, freedom results in stronger security and privacy. These three concepts aren’t just interrelated, but they are interdependent. As you increase freedom, you increase security and privacy and when you decrease freedom, you put security and privacy at risk. This is why we design all of our products with freedom, security and privacy as strict requirements and continue to work toward increasing all three in everything we do.

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.

Intel FSP reverse engineering: finding the real entry point!

2018-05-10 UPDATE: Intel politely asked Purism to remove this document which Intel believes may conflict with a licensing term. Since this post was informational only and has no impact on the future goals of Purism, we have complied. If you would like the repository link of the Intel FSP provided from Intel, please visit their publicly available code on the subject.

2018-04-23 UPDATE: after receiving a courtesy request from Intel’s Director of Software Infrastructure, we have decided to remove this post’s technical contents while we investigate our options. You are still welcome to learn about reverse engineering in general with my introductory post on the matter, Introduction to Reverse Engineering: A Primer Guide.


Hi everyone, it’s time for another blog post from your favorite Purism Reverse Engineer (that’s me! ’cause I’m the only one…)!

After attending 34C3 in Leipzig at the end of December, in which we (Zlatan and me) met with some of you, and had a lot of fun, I took some time off to travel Europe and fall victim to the horrible Influenza virus that so many people caught this year. After a couple more weeks of bed rest, I continued my saga in trying to find the real entry point of the Intel FSP-S module.

Here’s the non-technical summary of the current situation: I made some good progress in reverse engineering both the FSP-S and FSP-M and I’m very happy with it so far. Unfortunately, all the code I’ve seen so far has been about setting up the FSP itself, so I haven’t actually been able to start reverse engineering the actual Silicon initialization code.

Tamper-evident Boot Update: Making Heads More Usable

We announced not too long ago that we have successfully integrated the tamper-evident boot software Heads into our Librem laptops. Heads secures the boot process so that you can trust that the BIOS and the rest of the boot process hasn’t been tampered with, but with keys that are fully under your control.

Heads is cutting edge software and provides a level of security beyond what you would find in a regular computer. Up to this point though, its main user base are expert-level users who are willing to hardware flash their BIOS. The current user interface is also geared more toward those expert users with command-line scripts that make the assumption that you know a fair amount about how Heads works under the hood.

We want all our customers to benefit from the extra security in Heads so we intend to include it by default in all of our laptops in the future. For that to work though, Heads needs to be accessible for people of all experience levels. Most users don’t want to drop to a recovery shell with an odd error message so they can type some commands if they happen to update their BIOS, and they don’t want to be locked out of their system if they forgot to update their file signatures in /boot after a kernel update.

When we announced that we were partnering with Trammell Hudson to use Heads on our laptops, we didn’t just mean “thanks for the Free Software, see you later!” Instead, we are putting our own internal engineering efforts to the task of not just porting Heads to our hardware, but also improving it–and sharing those improvements upstream.

The Delicious GUI Center

The first of our improvements is focused on making the boot screen more accessible. We started by added whiptail (software that lets you display GUI menus in a console) to Heads so that we can display a boot menu that more closely resembles GRUB. We then duplicated the features of the existing Heads boot menu so that instead of this:

Heads booting on a Librem 13v2
Heads booting on a Librem 13v2

you now see this:

Initial Heads GUI Menu
Initial Heads GUI Menu

If you hit enter, you boot straight into your OS just like with GRUB, only behind the scenes Heads is checking all the files in /boot for tampering. If you hadn’t already configured a default boot option, instead of dumping you back to a main menu with no explanation or existing out to a shell, we decided to provide a GUI so you can decide what to do next:

No Default Boot Set
No Default Boot Set

If you decide to load a menu of boot options from the main menu or from this dialog, we also wrapped a GUI around the Heads boot menu that parses your GRUB config file:

Heads Boot Selection Menu
Heads Boot Selection Menu

In each of the most common workflows, we’ve replaced the console output with an easier-to-use menu that also provides a bit more explanation on what’s happening if something goes wrong. For the most part the average user will just verify the TOTP code and then hit Enter to boot their system so in that way it’s not much different from a standard GRUB boot screen. These extra menus come in only if the user ever needs to deviate from the default and select a different kernel, generate a new TOTP code, or do other maintenance within Heads.

What’s Next

We now have these GUI menus working well in our internal Heads prototypes and we’ve also pushed our changes upstream, where most of them have already been pulled into the Heads project. That said, having a GUI boot menu is only part of what you need to make tamper-evident boot usable. Now that the boot menu is in a good place, our next focus is on making the overall Heads bootstrap and update process, key management, and signature generation easy (if only we had a GPG expert to help us with smart card integration, that would sure make things easier). Keep an eye out for more updates along all these lines soon.

 

Purism Integrates Trammel Hudson’s Heads security firmware with Trusted Platform Module, giving full control and digital privacy to laptop users

Librem devices add tamper-evident features to further protect users from cybersecurity threats by offering users the full control that no mainstream computer manufacturer ever has before

SAN FRANCISCO, Calif., February 27, 2018 — Purism, maker of security-focused laptops has announced today that they have successfully tested integration of Trammel Hudson’s Heads security firmware into their Trusted Platform Module (TPM)-enabled coreboot-running Librem laptops. This integration allows Librem laptop users to freely inspect the code, build and install it (and customize it) themselves, and own control of the secure boot process as Heads uses the TPM on the system to provide tamper-evidence. Read more

Librem adds tamper-evident features, now most secure laptop under full customer control

Protecting customer privacy, security and freedom is so fundamental to Purism’s mission that we codified it in our Social Purpose Corporation charter. We believe that these three concepts of privacy, security, and freedom are not just important by themselves but are also dependent on each other. For example, it’s obvious that by improving your security, we help protect your privacy. What might be less obvious is how dependent your privacy is on your freedom. True privacy means your computer and data are under your control, not controlled by unethical big-tech corporations. When your digital life is under your control you have the freedom to share your data only when you want to. So as we consider ways to improve your security, it can’t be at the cost of privacy or freedom.

As part of our goal to improve security we are excited to announce that we have successfully integrated Heads into our TPM-enabled coreboot-running Librem laptops. This integration effort began in April 2017 with the partnership of Purism and Trammell Hudson’s Heads project, which required hardware design changes, coreboot modifications, and operating system updates to reach where we are with this announcement today. We now have a tamper-evident boot process starting with the BIOS all the way through verifying that the kernel, initrd, and boot configuration files haven’t been changed in any way. Soon Heads will be enabled by default on all our laptops and this critical piece combined with the rest of our security features will make Librem laptops the most secure laptop you can buy where you hold the keys.

In this post we will describe why Heads is such an integral part of our security and how it combines with the rest of our features to create a unique combination of security, privacy and freedom that don’t exist in any other laptop you can buy today.

Heads booting on a Librem 13v2 TPM
Heads booting on a Librem 13 with TPM

Why Tamper-Evident Software Matters

For your computer to be secure, you need to be able to trust that your software hasn’t been modified to run malicious code instead. This is one of many reasons why it’s so important that you can see the source code for all of the software on your system from your web browser to your hardware drivers to the kernel and up to your BIOS. We’ve gone to great lengths to choose hardware that can run with free software drivers, load our laptops with the FSF-endorsed PureOS, use coreboot as our Free/Libre and Open Source BIOS, and have neutralized and disabled the Intel Management Engine.

Unfortunately being able to see the source code isn’t enough. All of the software you run trusts the kernel, and the kernel trusts the BIOS. Without tamper-evident features that start the moment the computer turns on, an attacker can inject malicious code into your BIOS or kernel with no way to detect it. Once started, that malicious software could capture your encrypted disk or login passwords along with any other secrets or other personal information on your computer. By running tamper-evident software at boot, you get peace of mind that your system can be trusted before you start using it. With Purism’s combined approach the first bit loaded into the CPU is measured and signed by the user to prove nothing has been tampered with.

Heads Above the Rest

There are a number of different technologies we could have chosen to protect the boot process, but unfortunately very few of them are Free/Libre and Open Source and almost all of them work by taking control away from you and putting it into a vendor that owns the keys that determine what software you can run at boot. We have witnessed first-hand unethical laptops that ship with “Secure Boot” enabled (a technology that only allows software signed with pre-approved (e.g. paid-for) corporate controlled keys to run at boot). The very limited BIOS on this machine offered no way to disable Secure Boot so it is impossible to install Debian, PureOS or any other distribution that hadn’t gotten the BIOS vendor and Microsoft’s (paid) approval.

Heads has a lot of advantages over all of the other boot verification technologies that make it perfect for Librem laptops. First, it is Free Software that works with the Open Source coreboot BIOS so you don’t have to take our word for it that it is backdoor-free–anybody is free to inspect the code and build and install it (and customize it) themselves.

Second, the way it uses the TPM on your system to provide tamper-evidence puts the keys under your control, not ours. The fact that you retain control over the keys that secure your system is incredibly important. While we intend to make the secure boot process painless, we also don’t think you should have to trust us for it to work–you can change your keys any time.

Enterprise Level Security, Easily

If you manage a fleet of machines, this means with Purism Librem laptops that include TPM and Heads, you now have the ideal platform that you can tailor for your specific enterprise needs with custom features and your own trusted company keys. You can provide a trusted boot environment that protects your users from persistent malware and detects tampering while they travel, while still integrating with your custom in-house laptop images. And you can do this without having to ask us to sign your software.

The IT Security department’s dream of self-signed, tamper-evident, persistent-malware-detecting, laptop computer is now a reality with Purism Librem laptops.

Part of a Bigger Story

Having a secure boot process is the foundation of security on a modern laptop but it’s only part of the reason why Librem laptops are so secure. Here we will review some of the other security features that when combined with Heads puts Librem laptops in a totally different league.

Snitches get Switches

One of the first security features that set us apart was our hardware kill switches. Unlike a software switch that asks the hardware to turn off politely and hopes it listens, our hardware kill switches sever the circuit at the hardware level. This means you don’t have to worry about Remote Access Trojan malware that can disable your webcam LED to spy on you more easily. When you hit the radio kill switch, your WiFi is completely off, and when you hit the webcam/mic kill switch, the webcam is truly powered off–no webcam stickers needed.

 

Extra Security with Qubes

Our laptops default to PureOS because we feel it provides the best overall desktop experience for every type of user while still protecting your privacy, security and freedom. For customers who want an even higher level of security, Qubes uses virtualization features to provide extra security through compartmentalization. In 2015, our Librem 13 (version 1) was the first (and currently only) hardware to have received Qubes certification. Our current line of laptops remains compatible, and we recently announced that our current generation of Librem 13 and 15 laptops now fully work with Qubes 4.0.

We are also investigating ways to incorporate some of the compartmentalization features of Qubes into PureOS so you can still have good security but with an easier learning curve. Disposable web browsers and protected USB ports are just some of the features we are considering.

We Won’t Stop There

When you combine tamper-evident secure booting with Heads, an Open Source coreboot BIOS, a neutered and disabled Intel Management Engine, hardware kill switches, and the advanced security features of Qubes, Librem laptops have a security advantage over any other laptop you can buy. Equally important, they have extra security without sacrificing your privacy, freedom, or control. While we are excited to hit this major milestone, and can’t wait to have Heads on by default for all our laptops, we aren’t stopping there.

A secured boot process opens the possibility for even stronger tamper-evidence that extends further into the file system. From there you can move past tamper-evidence into tamper-resistance or even tamper-proofing in some advanced applications. We are also investigating better ways to incorporate hardware tokens with our products to provide more convenient authentication and encryption while still leaving the keys in your hands.

Ultimately, our goal is to provide you with the most secure computer you can buy that protects your privacy while also respecting your freedom. Since these values are inter-dependent, each milestone that improves one ultimately strengthens them all, and we will continue to work to raise the bar on all of them.

February 2018 coreboot update now available

Hey everyone, I’m happy to announce the release of an update to our coreboot images for Librem 13 v2 and Librem 15 v3 machines.

All new laptops will come pre-loaded with this new update, and everyone else can update their machines using our existing build script which was updated to build the newest image. Some important remarks:

  • Please read the instructions below to make sure the image gets built properly and make sure to select the correct machine type in the menu for the build script.
  • The build script was initially written as a tool for internal use, and therefore isn’t as polished as it could be, so if you want something that just quickly applies updates without building/compiling the whole thing, we hope to provide such a (simpler) script in the future.

What’s new?

This is a follow up from Kyle’s previous blog post, and now that the image has been fully tested, you can all enjoy it and get one of our most requested feature : VT-d support for Qubes 4.0 to work.

The new version is “4.7-Purism-1” and here is the ChangeLog:

  • ​Update to coreboot 4.7
  • Update to FSP 2.0
  • Add IOMMU support
  • Enable TPM support
  • Fixed ATA errors at 6Gbps

While coreboot 4.7 has not been officially released, it was “tagged” on October 31st in coreboot’s git repository, and this release is based on that tag with the IOMMU (VT-d) and TPM support added on top of it.

If your laptop came with the TPM chip installed, you need to update your coreboot image to this version in order to use the TPM hardware.

How to build it?

To build the latest coreboot image :

  1. Download the build script
    mkdir building-coreboot && cd building-coreboot && wget https://code.puri.sm/kakaroto/coreboot-files/raw/master/build_coreboot.sh
  2. Install the required dependencies:
    sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7
  3. Run the script on your Librem machine:
    chmod +x build_coreboot.sh && ./build_coreboot.sh
  4. Follow the instructions on the screen, be sure to select your correct Librem laptop revision (Librem 13v2 or Librem 15v3), and give it time to build the image.
  5. Once done, if everything went according to plan, it will ask you if you want to flash the newly built image
  6. Make sure you are not running on low battery and select Yes
  7. Reboot your machine once the flashing process is done.

For matters specifically related to this build script (not related to how to use a TPM per se), you may also want to check out the main forum thread about our coreboot build script, where discussion and testing has been going on over the past few months.

Verifying the presence of a TPM

If you are unsure whether or not you have a TPM installed on your system, install the tpm_tools package and then run sudo tpm_version to confirm that a TPM is detected on your system.

$ sudo tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.4.40
Spec Level: 2
Errata Revision: 3
TPM Vendor ID: IFX
Vendor Specific data: 04280077 0074706d 3631ffff ff
TPM Version: 01010000
Manufacturer Info: 49465800

If your machine came with a TPM, you can now take advantage of its capabilities, if you already have particular uses planned for it. Enjoy!

New Inventory with TPM by Default, Free International Shipping

In November, we announced the availability of our Trusted Platform Module as a $99 add-on for early adopters, something that would allow us to cover the additional parts & labor costs, as well as test the waters to see how much demand there might be for this feature. We thought there would be “some” interest in that as an option, but we were not sure how much, especially since it was clearly presented as an “early preview” and offered at extra cost.

Well, it turns out that a lot of people want this. We were pleasantly surprised to see that, with orders placed since that time, 98% of customers chose to have a TPM even at extra cost. This proved there is very strong market demand for the level of security this hardware add-on can provide.

2018’s first new batch is in stock—with TPM

Thanks to the investment of those early TPM adopters who voted with their wallets and gave us the necessary “business case” and resources to work it out, we are extremely proud to announce that we now include the TPM chip in all new Librem 13 and Librem 15 orders by default, as a standard feature of our newest hardware revision shipping out this month.

All the rest of the chip specifications remain the same.

It is still costing us money to add the TPM feature, but we decided to eat the cost, as the greater public benefit is more important than profits (and that is in line with our social purpose status and mission). Adding a TPM by default without increasing the base price is a major accomplishment toward having security by default, and paves the way for convenient security and privacy protection for everyone. In addition to the previous announcement, you can read Kyle’s post to understand the security implications.

Wait, there’s more!

  • We are now offering Free International Shipping on all orders. This is essentially a permanent rebate of approximately 100 USD to all new international customers! As we have grown we have been able to leverage more standardized shipping options, and are now in a position to pass on that savings to Purism customers. Please note, however, that shipping insurance, local taxes, customs fees and import duties are still your responsibility as customers.
  • Thanks to popular demand, we are now offering Librem 13 and Librem 15 laptops with the backlit German keyboard layout. They are available for purchase in our store now, and will begin rolling out in mid-March.

Only a few non-TPM laptops remain in stock with the UK keyboard layout, so we are making a sale today to clear out that portion of the inventory. If you were looking for a Librem 13 with the UK physical key layout and no TPM, you can grab one of the few remaining ones and get an additional $99 off the previous no-TPM base price. In other words, instead of paying $1,478 “plus shipping” for the base configuration of the Librem 13 UK, you now pay $1,379 with free shipping!

We would like to thank all our users of Librem laptops and FSF endorsed PureOS, as well as all those that have backed the Librem 5 phone, and of course all those people who support us by feedback, kind words, and spreading the word. It is with this unified education approach that we can change the future of computing and digital rights for the better.

We have more great news in the pipeline. Next month, we hope to announce another major milestone in our inventory management & shipping operations. Stay tuned!

Meltdown, Spectre and the Future of Secure Hardware

Meltdown and Spectre are two different—but equally nasty—exploits in hardware. They are local, read-only exploits not known to corrupt, delete, nor modify data. For local single user laptops, such as Librem laptops, this is not as large of a threat as on shared servers—where a user on one virtual machine could access another user’s data on a separate virtual machine.

As we have stated numerous times, security is a game of depth. To exploit any given layer, you go to a lower layer and you have access to everything higher in the stack.

Meltdown and Spectre are not just hardware exploits, they are the processor and microprocessor exploits. Meltdown is an exploit against the CPU which has a patch in progress, while Spectre is an exploit against the design of microprocessors which has a “possibility to patch upon each exploit as it is identified” in a never ending game of cat-and-mouse.

Protecting from Meltdown and Spectre with PureOS

  • Purism’s PureOS, a Free Software Foundation endorsed distribution, is releasing a patch to stop the Meltdown attack, with thanks to the quick and effective actions of the upstream Linux kernel development team.
  • Like the patch for Meltdown, PureOS will continue to release patches against any Spectre exploits as they are found and fixed, which highlights the importance of keeping up-to-date on software updates.

Countermeasures in Purism Librem hardware

Purism continues to advance security in hardware through a combination of techniques, including the inclusion of TPM in Librem laptops, where we are progressing towards a turn-key TPM+Heads solution. This will allow us to provide Librem users with a strong defensive stance making future exploits less scary.

While these countermeasures are not direct solutions for Meltdown and Spectre, they help work towards a larger scope of measurement and indication of “known good” states. In this case, this would mean only running a Linux kernel version which has good patches applied for Meltdown and Spectre exploits. Flagging or stopping any modifications that could be exploits adds another layer of security to protect users’ devices and sensitive information.

The Future of Secure Hardware

Intel, AMD, and ARM seem to suffer from the same issues that proprietary software suffers from: a lack of transparency that results in an unethical design which shifts us further away from an ethical society. RISC-V is something we are closely following in the hopes that it can create a future where processor hardware can be as ethical as Free Software—meaning that the user is in control of their own hardware and software, not the developer.

Purism, as a Social Purposes Corporation, will continue to advance along the best paths possible to offer high-end hardware that is as secure as possible, in alignment with our strict philosophy of ethical computing.

Measuring the Intel Management Engine to Create a More Secure Computer

A modern computer has many different avenues for attack—ranging from local user-level exploits to root and kernel exploits, all the way down to exploits that compromise the boot loader or even the BIOS—but for over ten years the Intel Management Engine—with its full persistent access to all computer hardware combined with its secretive code base—has offered the theoretical worst-case scenario for a persistent invisible attack. The recent exploit from the talented group of researchers at Positive Technologies moves that worst-case scenario from “theoretical” to reality. While the proof-of-concept exploit is currently limited to local access, it is only a matter of time before that same style of stack smash attack turns remote by taking advantage of systems with AMT (Advanced Management Technology) enabled.

At its core, Purism fights for ethical computing and believes that free software is the best way to protect a user’s freedom, security, and privacy. This belief has meant investing in removing software that fails to provide these protections (due to their proprietary/non-free nature). From the beginning, Purism has seen the ethical issues and potential for abuse in the ME, and fought against the inclusion of the ME in CPUs starting with petitioning Intel for an ME-less design in 2016, then reverse engineering parts of the ME in 2017, to collaborating and cooperating with the other groups cleaning the ME—resulting in Purism being the first manufacturer to disable the Intel ME in modern hardware.

The recent Intel Management Engine exploit has left many wondering how they can protect themselves, not just from this attack but also any future ones that exploit software sitting at such a fundamental level on their computer.

Purism offers one of the most advanced approaches by combining secure hardware, TPM, coreboot, Heads, and the FSF-compliant PureOS in its Librem laptops, helping protect against a wide variety of ME, BIOS, and boot-loader attacks beyond just wiping ME code from the computer. Below we will discuss how Librem laptops can help protect against the current ME exploit and describe some of the limitations of these countermeasures. Read more