Tag: Privacy

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.

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 Partners with Cryptography Pioneer Werner Koch to Create a New Encrypted Communication Standard for Security-Focused Devices

Koch’s GnuPG and Smartcard encryption innovations popularized by Edward Snowden to be implemented in Purism’s Librem 5 smartphone and Librem laptop devices.

SAN FRANCISCO, California — March 8th, 2018 — Purism, maker of security-focused laptops has announced today that they have joined forces with leading cryptography pioneer, Werner Koch, to integrate hardware encryption into the company’s Librem laptops and forthcoming Librem 5 phone. By manufacturing hardware with its own software and services, Purism will include cryptography by default pushing the industry forward with unprecedented protection for end-user devices. Read more

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.

Dark Caracal: State-Sponsored Spyware for Rent

Spyware has long been a privacy and security risk for personal computers and has been used by a number of groups—ranging from creeps who spy on and blackmail people through Remote Access Trojans, to marketers who want ever more data about you for targeted ads (such as through the Superfish malware we’ve seen preinstalled on some “big brands” computers), to government intelligence agencies.

The Register recently reported on an investigation by the EFF and Lookout into the “Dark Caracal” spyware network. According to the EFF, this spyware has already captured hundreds of gigabytes of data. More troubling, this spyware network is being rented out to nation states that may not be able to develop this capability in-house. Who knew government spies had their own international app store?

The Dark Caracal toolkit contains malware that targets Windows and Android platforms. In particular, Lookout discovered that Dark Caracal uses a particular piece of Android malware called Pallas that disguises itself as a legitimate Signal or WhatsApp app and tricks the unsuspecting user into installing it. Instead of relying on a rootkit, it just uses the fact that chat apps usually have access to a wide variety of permissions on your phone, so most people don’t question all the permissions the malware wants. Once installed, it uses those permissions to get audio, text messages, files, and other data via completely legitimate means and uses the network connection to send it back to the attacker.

Purism, Post-Its and Personal Privacy

Dark Caracal relies on Windows and Android malware, so you might wonder why I’m writing about it at Purism given not only is our Librem 5 phone not out yet, but PureOS is a completely different platform and isn’t vulnerable to this spyware toolkit. What makes spyware like this relevant is that we have focused on protecting customer privacy from the beginning (it’s even part of our corporate charter). Stories like this give us an opportunity to audit the privacy and security protections we put in our products to see how they’d fare if we had been a target.

By performing a tabletop thought exercise against spyware in the wild even if we aren’t vulnerable ourselves, we can rate the protections we have in place against a real-world attack and proactively harden things further based on any gaps we might find. It’s always easier if you start with security as a focus from the beginning instead of tacking it on at the end, so this exercise is not just useful for our existing Librem laptops but is particularly helpful as we develop the Librem 5.

Software Delivery

The first thing to examine is the software delivery mechanism. Malicious lookalike applications are a constant problem in mobile app stores, even more so if you add third party stores into the mix. One advantage GNU/Linux distributions have long had against other operating systems is that all of a particular distribution’s applications come from its own official repository and are signed by its developers. It’s much more difficult for a malicious application to end up in the official repository and pass the signature check, so when you use your distribution’s tool to install LibreOffice, you can be assured you are getting the real thing.

We get an additional advantage due to our dedication to Free Software. Like with other GNU/Linux distributions, all applications in PureOS come from a central PureOS repository and are signed with official PureOS keys. Unlike many GNU/Linux distributions, PureOS is a FSF-endorsed distribution so all of the software in PureOS must be Free Software. PureOS doesn’t include packages that download proprietary codecs, unsigned Flash plugins or any other binary-only code from elsewhere on the Internet. This means you can examine the source for every package in PureOS to check for malware or backdoors.

This is why it’s important to be extra careful when adding third-party repositories or installing software with curl | sh because you bypass trusted code signing and lose many of the protections built into a GNU/Linux distribution’s native packages. Fortunately, because PureOS is derived in part from Debian, it can take advantage of the vast number of packages available in Debian’s free repository, so you are much less likely to need to install software from a third party.

Hardware Privacy Protections

For most vendors you would focus only on software protections against spying because that’s your only option. Fortunately we can go one step further because we also build privacy protections into the hardware itself in the form of kill switches. Purism devices include hardware switches that allow you to cut power to radio hardware (WiFi) and to the webcam and microphone. Unlike a software hot key, these hardware switches disconnect power from the hardware so it can’t be bypassed by malicious software. Dark Caracal attacked both desktops and phones and so we should consider what effect our hardware privacy features would have on the spyware in both cases.

Desktop Protections

On a traditional laptop infected with Dark Caracal, the attacker would be able to stream video from the webcam. Depending on the sophistication of the spyware, it could possibly capture video with the LED light off, a phenomenon that has been demonstrated multiple times in recent years. Even if the victim added the high-tech spying countermeasure of covering the webcam with tape, the attacker could still capture audio off of the microphone and stream it along with the rest of the data over the WiFi connection.

On Librem laptops, the radio kill switch disables WiFi and the webcam/mic kill switch—you guessed it—disables the webcam and microphone together. We recommend users take advantage of the kill switches, in particular the webcam/mic switch, to disable the hardware when you aren’t using it. With the webcam/mic kill switch, even if spyware found its way on your machine, the attacker wouldn’t be able to capture any video or audio from the machine as long as the switch was off.

Customers especially concerned about their privacy or in a high-risk environment could take the additional precaution of using the radio kill switch to keep WiFi powered off and only turning it on briefly when they needed a network connection. In that case the attacker would have to wait until a network connection showed up and use that limited window to upload the data.

Phone Protections

Like with the Librem laptops, the Librem 5 phone will have kill switches, but as you’ll see, they impact a phone’s privacy even more dramatically than on a laptop. For example, the webcam/mic kill switch will protect you in much the same way as in a laptop, but unlike with a laptop, it gives you spyware protection you just wouldn’t have with a traditional phone because most phones just don’t have a good way to disable the microphone (in fact they rely on it being always on for voice commands). While you could tape over the camera like in a laptop, almost no one does. With a kill switch, you can leave your camera and mic off and conveniently turn it on when you need to take a selfie or make a call.

The radio kill switch would protect you in a similar way as on a laptop, but the Librem 5 also has an additional baseband kill switch. This switch powers off the cellular radio completely, not using software like in traditional airplane mode but using hardware so you know for sure it’s off. With the baseband off, you also prevent spyware from using your cellular beacon to track your location or your cellular network to send out your personal data and rack up a large cellphone bill.

Conclusion

It’s hard to add security and privacy protections after the fact—even harder if your company relies on customer data for its revenue. Because we value customer privacy, we continually work to increase privacy protections in our products not just in a reactive way based on a specific threat but in a proactive and general-purpose way that applies to all kinds of threats. Even though Purism products weren’t vulnerable to Dark Caracal, you can see how some of the additional protections we put in place would help keep you safer even if they were.

While this government-sponsored spyware was interesting because of its scope and because it was rented out to other governments, spyware like it is sadly not unique. Everyone from governments to tech companies to hackers to creepy stalkers all want a piece of your personal data and they all use different kinds of spyware to get it. Some of the greatest minds in our generation are focused on the problem of how to capture and store more and more of your data. At Purism we recognize that this data is your data, and we work every day to protect it.

Purism Attends Chaos Communication Congress

Chaos Computer Club hosts the CCC

We are attending the Chaos Communication Congress between December 27th – 30th in Leipzig, Germany. This is one of the largest gatherings of people who are interested in computer security, cryptography, privacy, and free speech in the world.

Two of our staff will be attending the event. Youness Alaoui and Zlatan Todoric hope to connect with those going or who are interested in learning more about the Congress. Please contact them on #Purism IRC channel on Freenode. Zlatan’s handle is zlatan, and Youness’ handle is KaKaRoTo.

They can’t wait to meet you at the Chaos Communication Congress!

Purism Librem Laptops Completely Disable Intel’s Management Engine

SAN FRANCISCO, Calif., October 19, 2017 — Purism’s Librem Laptops, running coreboot, are now available with the Intel Management Engine completely and verifiably disabled.

“Disabling the Management Engine, long believed to be impossible, is now possible and available in all current Librem laptops, it is also available as a software update for previously shipped recent Librem laptops.” says Todd Weaver, Founder & CEO of Purism.

The Management Engine (ME), part of Intel AMT, is a separate CPU that can run and control a computer even when powered off. The ME has been the bane of the security market since 2008 on all Intel based CPUs, with publicly released exploits against it, is now disabled by default on all Purism Librem laptops.

Disabling the Management Engine is no easy task, and it has taken security researchers years to find a way to properly and verifiably disable it. Purism, because it runs coreboot and maintains its own BIOS firmware update process has been able to release and ship coreboot that disables the Management Engine from running, directly halting the ME CPU without the ability of recovery.

“Purism Librem laptops were already the most secure current Intel based computers available on the market today, but disabling the management engine solidifies that statement clearly.” says Zlatan Todoric, CTO of Purism.

The Librem 13 and Librem 15 products can be purchased today and will arrive with the Management Engine disabled by default, and it can be verified to be disabled with the source code released to confirm the disablement is accurate. Showing “ME: FW Partition Table : BAD; ME: Bringup Loader Failure : YES”

“Purism, in the long-term pursuit of liberating hardware at the lowest levels, still has more work to do. Removing the management engine entirely is the next step beyond just disabling it. Coreboot also includes another binary, the Intel FSP, a less worrisome but still important binary to liberate, incorporating a free vBIOS is another step Purism plans to take. The road to a completely free system on current Intel CPUs is not over, but the largest step of disabling the Management Engine is arguably the largest milestone to cross.” says Youness Alaoui, Hardware Enablement Developer at Purism.

See also: our technical write-up on disabling the Management Engine on Purism laptops.


About Purism

Purism is a Social Purpose Corporation devoted to bringing security, privacy, software freedom, and digital independence to everyone’s personal computing experience. With operations based in San Francisco (California) and around the world, Purism manufactures premium-quality laptops, tablets and phones, creating beautiful and powerful devices meant to protect users’ digital lives without requiring a compromise on ease of use. Purism designs and assembles its hardware in the United States, carefully selecting internationally sourced components to be privacy-respecting and fully Free-Software-compliant. Security and privacy-centric features come built-in with every product Purism makes, making security and privacy the simpler, logical choice for individuals and businesses.

Media Contact

Marie Williams, Coderella / Purism
+1 415-689-4029
pr@puri.sm
See also the Purism press room for additional tools and announcements.
 

Deep dive into Intel Management Engine disablement

Starting today, our second generation of laptops (based on the 6th gen Intel Skylake platform) will now come with the Intel Management Engine neutralized and disabled by default. Users who already received their orders can also update their flash to disable the ME on their machines.

In this post, I will dig deeper and explain in more details what this means exactly, and why it wasn’t done before today for the laptops that were shipping this spring and summer.

The life and times of the ME

Think of the ME as having 4 possible states:

  1. Fully operational ME: the ME is running normally like it does on other manufacturers’ machines (note that this could be a consumer or corporate ME image, which vary widely in the features they ‘provide’)
  2. Neutralized ME: the ME is neutralized/neutered by removing the most “mission-critical” components from it, such as the kernel and network stack.
  3. Disabled ME: the ME is officially “disabled” and is known to be completely stopped and non-functional
  4. Removed ME: the ME is completely removed and doesn’t execute anything at any time, at all.

In my previous blog post about taming the ME, we discussed how we neutralize the ME (note that this was on the first generation, Broadwell-based Purism laptops back then), but we’ve taken things one step further today by not only neutralizing the ME but also by disabling it. The difference between the two might not be immediately visible to some of you, so I’ll clarify below.

  • A neutralized ME is a ME image which had most of its code removed.
    • The way the ME firmware is packaged on the flash, is in the form of multiple modules, and each module has a specific task, such as : Hardware initialization, Firmware updates, Kernel, Network stack, Audio/Video processing, HECI communication over PCI, Java virtual machine, etc. When the ME is neutralized using the me_cleaner tool, most of the modules will be removed. As we’ve seen on Broadwell, that meant almost 93% of the code is removed and only 7% remains (that proportion is different on Skylake, see further below).
    • A neutralized ME means that the ME firmware will encounter an error during its regular boot cycle; It will not find some of its critical modules and it will throw an error and somehow fail to proceed. However, the ME remains operational, it just can’t do anything “valuable”. While it’s unable to communicate with the main CPU through the HECI commands, the PCI interface to the ME processor is still active and lets us poke at the status of the ME for example, which lets us see which error caused it to stop functioning.
  • When the ME is disabled using the “HAP” method (thanks to the Positive Technologies for discovering this trick), however, it doesn’t throw an error “because it can’t load a module”: it actually stops itself in a graceful manner, by design.

The two approaches are similar in that they both stop the execution of the ME during the hardware initialization (BUP) phase, but with the ME disabled through the HAP method, the ME stops on its own, without putting up a fight, potentially disabling things that the forceful “me_cleaner” approach, with the “unexpected error” state, wouldn’t have disabled. The PCI interface for example, is entirely unable to communicate with the ME processor, and the status of the ME is not even retrievable.

So the big, visible difference for us, between a neutralized and a disabled ME, is that the neutralized ME might appear “normal” when coreboot accesses its status, or it might show that it has terminated due to an error, while a disabled ME simply doesn’t give us a status at all—so coreboot will even think that the ME partition is corrupted. Another advantage, is that, from my understanding of the Positive Technologies’s research, a disabled ME stops its execution before a neutralized ME does, so there is at least a little bit of extra code that doesn’t get executed when the ME is disabled, compared to a neutralized ME.

Kill it with fire! Then dump it into a volcano.

In our case, we went with an ME that is both neutered and disabled. By doing so, we provide maximum security; even if the disablement of the ME isn’t functioning properly, the ME would still fail to load its mission-critical modules and will therefore be safe from any potential exploits or backdoors (unless one is found in the very early boot process of the ME).

I want to talk about the neutralizing of the Skylake ME then follow up on how the ME was disabled. However, I first want you to understand the differences between the ME on Broadwell systems (ME version 10.x) and the ME on Skylake systems (ME version 11.0.x).

  • The Intel Management Engine can be seen as two things; first, the isolated processor core that run the Management Engine is considered “The ME”, and second, the firmware that runs on the ME Core is also considered as being “the ME”. I often used the two terms interchangeably, but to avoid confusion, I will from now on (try to) refer to them, respectively, as the ME Core and the ME Firmware, but note that if I simply say the ME, then I am probably referring to the ME Firmware.
  • The ME Firmware 10.x was used on Broadwell systems which had an ARC core, while the ME Firmware 11.0.x used on Skylake systems uses an x86 core. What this means is that the architecture used by the ME core is completely different (kind of like how PowerPC and Intel macs used a different architecture, or how most mobile devices use an ARM architecture, the Broadwell ME Core used an ARC architecture). This means that the difference between the 10.x and 11.0.x ME firmwares is major, and the cores themselves are also very different. It’s a bit like comparing arabic to korean!
  • As the format of the ME firmware changed significantly, it took a while to figure out how to decompress the modules and understand how to remove the modules without breaking anything else. Nicola Corna, the author of the me_cleaner tool, recently was able to add support for Skylake machines by removing all the non essential modules.

In my last ME-related post, I gave everyone a rundown of the modules that were in the ME 10.x firmware and which ones were remaining after it was neutered, so, for Skylake, here is the list of modules in a regular ME 11.0.x firmware:

-rw-r--r-- 1 kakaroto kakaroto 184320 Aug 29 16:33 bup.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 busdrv.mod
-rw-r--r-- 1 kakaroto kakaroto  32768 Aug 29 16:33 cls.mod
-rw-r--r-- 1 kakaroto kakaroto 163840 Aug 29 16:33 crypto.mod
-rw-r--r-- 1 kakaroto kakaroto 389120 Aug 29 16:33 dal_ivm.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 dal_lnch.mod
-rw-r--r-- 1 kakaroto kakaroto  49152 Aug 29 16:33 dal_sdm.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 evtdisp.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 fpf.mod
-rw-r--r-- 1 kakaroto kakaroto  45056 Aug 29 16:33 fwupdate.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 gpio.mod
-rw-r--r-- 1 kakaroto kakaroto   8192 Aug 29 16:33 hci.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 heci.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 hotham.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 icc.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 ipc_drv.mod
-rw-r--r-- 1 kakaroto kakaroto  11832 Aug 29 16:33 ish_bup.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 ish_srv.mod
-rw-r--r-- 1 kakaroto kakaroto  73728 Aug 29 16:33 kernel.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 loadmgr.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 maestro.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 mca_boot.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 mca_srv.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 mctp.mod
-rw-r--r-- 1 kakaroto kakaroto  32768 Aug 29 16:33 nfc.mod
-rw-r--r-- 1 kakaroto kakaroto 409600 Aug 29 16:33 pavp.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 pmdrv.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 pm.mod
-rw-r--r-- 1 kakaroto kakaroto  61440 Aug 29 16:33 policy.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 prtc.mod
-rw-r--r-- 1 kakaroto kakaroto 167936 Aug 29 16:33 ptt.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 rbe.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 rosm.mod
-rw-r--r-- 1 kakaroto kakaroto  49152 Aug 29 16:33 sensor.mod
-rw-r--r-- 1 kakaroto kakaroto 110592 Aug 29 16:33 sigma.mod
-rw-r--r-- 1 kakaroto kakaroto  20480 Aug 29 16:33 smbus.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 storage.mod
-rw-r--r-- 1 kakaroto kakaroto   8192 Aug 29 16:33 syncman.mod
-rw-r--r-- 1 kakaroto kakaroto  94208 Aug 29 16:33 syslib.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 tcb.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 touch_fw.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 vdm.mod
-rw-r--r-- 1 kakaroto kakaroto  98304 Aug 29 16:33 vfs.mod

And here is the list of modules in a neutered ME :

-rw-r--r-- 1 kakaroto kakaroto 184320 Oct  4 16:21 bup.mod
-rw-r--r-- 1 kakaroto kakaroto  73728 Oct  4 16:21 kernel.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Oct  4 16:21 rbe.mod
-rw-r--r-- 1 kakaroto kakaroto  94208 Oct  4 16:21 syslib.mod

The total ME size dropped from 2.5MB to 360KB, which means that 14.42% of the code remains, while 85.58% of the code was neutralized with me_cleaner.

The reason the neutering on Skylake-based systems removed less code than on Broadwell-based systems is because of the code in the ME’s read-only memory (ROM). What this “ROM” means is that a small part of the ME firmware is actually burned in the silicon of the ME Core. The ROM content is the first code executed, loaded internally from the ROM, by the ME core, and it has the simple task of reading the ME firmware from the flash, verifying its signature, making sure it hasn’t been tampered with, loading it in the ME Core’s memory and executing it.

  • On Broadwell, there is about 128KB of code burned in the ME Core’s ROM. That 128KB of code contains the bootloader as well as some system APIs that the other modules can use.
  • On Skylake, the ROM code was decreased to 17KB, leaving only the basic bootloader, and moving the system APIs to a module of their own inside the ME firmware.
  • This means that the total amount of code remaining, including the ROM is 360+17KB out of 2524+17KB = 377/2541 = 14.84% for Skylake, while on Broadwell, it’s 120 + 128KB out of 1624+128KB = 248/1752 = 14.15% of code remaining. The difference is much smaller now when we account for the code hidden in the ROM of the processor.

The problem with the code in the ROM is that it cannot be removed because it’s inside of the processor itself and, well, it’s Read-Only Memory—it cannot be overwritten in any way, by definition. On the bright side, it is nice to see that most of the code that was previously in the ROM has now been moved to the flash in Skylake systems.

The ME firmware itself has multiple “partitions”, each containing something that the ME firmware needs. Some of those partitions will contain code modules, some will contain configuration files, and some will contain “other data” (I don’t really know what). Either way, the ME firmware contains about a dozen different partitions, each for a specific purpose, and two of those partitions contain the majority of the code modules.

Schrödinger’s Wi-Fi

I’ll now explain what has been done to get to this point in the project. When I was done with the coreboot port to the new Skylake machines, I tried to neutralize the ME, thinking it would be a breeze, since me_cleaner claimed support for Skylake. Unfortunately, it wasn’t working as it should and I spent the entire hacking day at the coreboot conference trying to fix it.

The problem is that once the ME was neutralized with me_cleaner, the Wi-Fi module on the Librem was unpredictable: it sometimes would work and sometimes wouldn’t, which was confusing. I eventually realized that if I reboot after replacing the ME, the wifi would keep the same state as it was in before:

  • if I neutralized the ME and reboot, it would still work, but after powering off the machine and turning it on, the wifi would stop working;
  • if I restored a full ME (instead of a neutralized one) and rebooted, the wifi would remain dead;
  • …but if I power off the machine and turn it back on, the wifi would finally be restored.

I figured that it has something to do with how the PCI-Express card is initialized, and I spent quite some time trying to “enable it” from coreboot with a neutralized ME. I’ll spare you the details but I eventually realized that I couldn’t get it to work because the PCIe device completely ignored all my commands and would simply refuse to power up. It turns out that the ME controls the ICC (Integrated Clock Controller) so without it, it would simply not enable the clock for the PCIe device, so the wifi card wouldn’t work and there is nothing you can do about it because only the ME has control over the ICC registers. I tried to test a handful of different ME firmware versions, but surprisingly, the wifi module never worked on any of those images, even when the ME was not neutralized. Obviously, it meant that the ME firmware was not properly configured, so I used the Intel FIT tool (which is used to configure ME images, allowing us to set things like PCIe lanes, and which clocks to enable, and all of that). Unfortunately, even when an image was configured the exact same way as the original ME image we had, the wifi would still not work, and I couldn’t figure out why.

I shelved the problem to concentrate on the release of coreboot and eventually on the SATA issues we were experiencing. The decision was made to release the Librem 13 v2 and Librem 15 v3 with a regular ME until more work was done on that front, because we couldn’t hold back shipments any longer (and because we can provide updates after shipment). Also note that at that time, the support for Skylake in me_cleaner was very rough—it was removing only half of the ME code because the format of the new ME 11.x firmware wasn’t fully known yet.

A few weeks later, I saw the release of unME11 from Positive Technologies and a week later, Nicola Corna pushed more complete support for Skylake in a testing branch of me_cleaner. I immediatly jumped on it and tested it on our machines. Unfortunately, the wifi issue was still there. I decided to debug the cause by figuring out what me_cleaner does that could be affecting the ME firmware that way.

As I mentioned earlier in this post, the ME firmware is made up of a dozen of partitions, some of those containing code modules, and me_cleaner will remove all the partitions except one, in which it will remove most of the modules and leave only the critical modules needed for the startup of the system. Therefore, I started progressively whitelisting more modules so me_cleaner wouldn’t remove them, and testing if it affected the wifi module. This was annoying to test because I’d have to change me_cleaner, neutralize the ME firmware, then copy the image from my main PC to the Librem then flash the new image, poweroff, then restart the machine, and if the Wifi wasn’t working, which was 99% of the time, I had to copy the files through a USB drive. I eventually restored all of the modules and it was still not working, which made me suspect the cause might be in one of the other partitions, so I gradually added one partition at a time, until the Wifi suddenly worked. I had just added the “MFS” partition, so I started removing the other partitions again one at a time, but keeping the “MFS” partition, and the Wifi was still working. I eventually removed all of the code modules (apart from the critical ones) but keeping the MFS partition, and the wifi was still working. So I had found my fix: I just need to keep the “MFS” partition in the image and the wifi would work.

So many firmwares, so little time

So, what is this mysterious “MFS” partition? There’s not a lot of information about it anywhere online, other than one forum or mailing list user mentioning the MFS partition as “ME File System”. I decided to use a comparative approach.

The fun thing  when comparing ME firmware images: not only are there multiple versions (ex: 10.x vs 11.x), for each single ME version there are multiple “flavors” of it, such as “Consumer” or “Corporate”, and there are also multiple flavors for “mobile” and “desktop”.

  • When I extracted and compared all the partitions of all the variants and flavors, the only difference between a mobile and a desktop image is in the MFS partition, as every other partition shares the same hash between two flavors of the same version.
  • I then compared the various partitions between a configured and a non configured ME firmware, and noticed that what the Intel FIT tool does when you change the system’s configuration is to simply write that configuration inside of the MFS partition.
  • This means that the MFS partition, which doesn’t contain any code modules, is used for storage of configuration files used by the ME firmware. This is somewhat confirmed by the fact that the MFS partition is marked as containing data.

After modifying me_cleaner to add support for the Librem, which allows us to neutralize the ME while keeping the Wifi module working, I discussed with Nicola Corna how to best integrate the feature into me_cleaner. We came to the conclusion that having a new option to allow users to select which partitions to keep would be a better method, so I sent a pull request that adds such a feature.

Unfortunately, while the wifi module was working with this change, I also had an adverse side-effect when adding the MFS partition back into the ME firmware: my machine would refuse to power off, for example, and would have trouble rebooting.

  • The exact behavior is that if I power off the machine, Linux would do the entire power off sequence then stop, and I would have to manually force shutdown the Librem by holding the power button for 5 seconds. As for the rebooting issue, instead of actually rebooting when Linux finishes its poweroff sequence, the system will be frozen for a few seconds before suddenly shutting itself down forcibly, then turning itself back on 5 seconds later, on its own. This isn’t the most critical of issues, but it would be very annoying to users, and unfortunately, I couldn’t find the cause of this strange behavior. All I knew was that if I remove the MFS partition, coreboot says the ME partition is corrupted, and the wifi module doesn’t work, and if I keep the MFS partition, coreboot says the ME partition is valid, the wifi module works, but the poweroff/reboot issues automatically appear.
  • The solution for these issues turned out to be unexpectedly simple. After another of our developers said he was ready to live with the poweroff/reboot issues, and I sent him a neutralized ME for his system, I was told that his machine was working fine with no side-effects at all. I didn’t know what the difference between his machine and mine was, other than the fact that my machine is a prototype and his was a “production” machine. I then tested my neutralized ME on the “production” Librem 13 unit I had on hand, and I didn’t have any side effects of the neutralizing of the ME firmware. I then updated my coreboot build script to add the neutralization option and asked users on our forums to test it, and every one who tested the neutralized ME reported back success with no side-effects. I then realized the problem is probably only caused by the prototype machine that I was using. Well, I can live with that.

Disabling the ME

The next step for me was to start reverse-engineering the ME firmware, like I had done before. This is of course a very long and arduous process that took a while and for which I don’t really have much progress to show. One thing I wanted to reverse-engineer was the MFS file system format so I could see which configuration files are within it and to start eliminating as much from it as possible. I started from the beginning however, by reverse engineering the entry point in the ROM. I will spare you much of the detail and the troubles in trying to understand some of the instructions, and mostly some of the memory accesses. The important thing to know is that before I got too far along, Positive Technologies announced the discovery of a way to disable the Intel ME, and I needed to test it.

Unfortunately, enabling the HAP bit which disables the ME Core, didn’t work on the Librem: it was causing the power LED to blink very slowly, and nothing I could do would stop it until I removed the battery. I first thought the machine was stuck in a boot loop, but it was just blinking really slowly. I figured out eventually that the reason was that the “HAP” bit was not added in version 11.0.0, but rather in version 11.0.x (where  x > 0). I decided to try a newer ME firmware version and the HAP bit did work on that, which confirmed that the ME disablement was a feature added to the ME after the version the Librem came with (11.0.0.1180). So now I have a newer ME (version 11.0.18.1002) that is disabled thanks to the HAP bit, but… no Wi-Fi again.

I decided to retry using the FIT tool to configure the ME with the exact same settings as the old ME firmware. I went through every setting available to make sure it matches, and when I tried booting it again, the ME Core was disabled and the Wifi module was working. Great Success!

Obviously, I then needed to do plenty of testing, make sure it’s all working as it should, confirm that the ME Core was disabled, test the behavior of the system with a ME firmware both disabled and neutralized, and that it has no side effects other than what we wanted.

My previous coreboot build script was using the ME image from the local machine, but unfortunately, I can’t do that now for disabling the ME since it’s not supported on the ME image that most people have on their machines. So I updated my coreboot build script to make it download the new ME version from a public link (found here), and I used bsdiff to patch the ME image with the proper configuration for the WiFi to work. I made sure to check that the only changes to the ME image is in the MFS partition and is configuration data, so the binary patch does not contain any binary code and we can safely distribute it.

Moving towards the FSP

The next step will be to continue the reverse-engineering efforts, but for now, I’ve put that on hold because Positive Technologies have announced that they found an exploit in the ME Firmware allowing the executing of unsigned code. This exploit will be announced at the BlackHat Europe 2017 conference in December, so we’ll have to wait and see how their exploit works and what we can achieve with it before going further. Also, once Positive Technologies release their information, it might be possible for us to work together and share our knowledge. I am hoping that I can get some information from them on code that they already reverse engineered, so I don’t have to duplicate all of their efforts. I’d also like to mention that, just as last time, Igor Skochinsky has generously shared his research with us, but also getting data from Positive Technologies would be a tremendous help, considering how much work they have already invested on this.

Right now, I have decided to move my focus to investigating the FSP, which is another important binary that needs to be reverse-engineered and removed from coreboot. I don’t think that anyone is currently actively working on it, so hopefully, I can achieve something without duplicating someone else’s work, and we can advance the cause much faster this way. I think I will concentrate first on the PCH initialization code, then move to the memory initialization.

Purism Partners with Nextcloud to Build and Include End-to-End Encrypted Storage Products and Services

Purism Partners with Nextcloud to Build and Include End-to-End Encrypted Storage Products and Services

SAN FRANCISCO, Calif., October 18, 2017 – Purism, maker of security-focused computing devices, is partnering with Nextcloud for a series of products and services. Nextcloud, author of a popular open-source self hosted, privacy-focused file sync and share solution, is looking to expand and become a default on Purism’s mobile and desktop computing products.

Purism, fresh off of successfully meeting their crowdfunding goal of $1.5 million to build and deliver the Librem 5, adds another partner in Nextcloud, fresh off the announcement of new end-to-end encryption upgrades in Nextcloud 13. This partnership adds to Purism’s roster of open-source partners that will aim to make the Librem 5 the most comprehensive free open-source smartphone to ever hit the market.

“Having Nextcloud applications built into the Librem 5, as well as default within PureOS, will help people have a convenient, ethical encrypted file storage service alongside other easy-to-use defaults” says Todd Weaver, Founder and CEO of Purism.

“Partnering with Purism gets our software directly into the hands of customers, making their lives easier with security and privacy protection built-in” says Jos Poortvliet, Co-founder and Head of Marketing at Nextcloud.

Purism plans to include Nextcloud in the Librem 5 phone, as well as within PureOS for its Librem 13 and Librem 15 laptops. Additionally, Purism will be discussing with Nextcloud about a future Purism NAS that runs completely free software including Nextcloud and services.

“Nextcloud follows our strict beliefs in digital rights for people, and this partnership is a clear win for users by merging convenience and ethics together into simple products” adds Weaver.

About Nextcloud

Nextcloud offers the industry-leading fully open source solution for on-premise data handling and communication with an uncompromising focus on security and privacy and unprecedented scalability. Nextcloud brings together universal access to data with next-generation secure communication and collaboration capabilities under direct control of IT and integrated with existing compliant infrastructure. Nextcloud’s open, modular architecture, emphasis on security and advanced federation capabilities enable modern enterprises to leverage their existing assets within and across the borders of their organization.

About Purism

Purism is a Social Purpose Corporation devoted to bringing security, privacy, software freedom, and digital independence to everyone’s personal computing experience. With operations based in San Francisco (California) and around the world, Purism manufactures premium-quality laptops, tablets and phones, creating beautiful and powerful devices meant to protect users’ digital lives without requiring a compromise on ease of use. Purism designs and assembles its hardware in the United States, carefully selecting internationally sourced components to be privacy-respecting and fully Free-Software-compliant. Security and privacy-centric features come built-in with every product Purism makes, making security and privacy the simpler, logical choice for individuals and businesses.

Media Contact

Marie Williams, Coderella / Purism
+1 415-689-4029
pr@puri.sm
See also the Purism press room for additional tools and announcements.