Bootstraping a slightly more secure laptop
Hudson, Trammell
Heads is an open source custom firmware and OS configuration for laptops and servers that aims to provide slightly better physical security and protection for data on the system. Unlike Tails, which aims to be a stateless OS that leaves no trace on the computer of its presence, Heads is intended for the case where you need to store data and state on the computer. It targets specific models of commodity hardware and takes advantage of lessons learned from several years of vulnerability research. This talk provides a high level overview of Heads, a demo of installing it on a Thinkpad and a tour of some of the attacks that it protects against.
 So the last speaker for this morning is Traml. He's doing awesome research on Bootstrapping more secure laptops or servers. He's doing that basically by moving the root of trust into the right protected ROM. He's building an open-source custom firmware, so big ups for that, and also encouraging the research on this field, which I believe it's super interesting. Thanks. So I'm Traml Hudson with two-segment investments, and for the past several years, I've been researching firmware security vulnerabilities and looking at how they affect systems. Two years ago, I presented my work on Thunderstrike here at CCC. This was the first firmware attack against Macbooks that allowed an attacker to overwrite the motherboard Boot ROM. The year after that, I collaborated with Zeno Kova and Corey Kalenberg from Legbacore, both of whom are now at Apple doing firmware work, and we ported a bunch of Windows UE5 vulnerabilities over to the Mac and showed that the software platform, the UE5 software platform, allowed very portable attacks to be done. This also allowed a remote attacker with code execution on your machine to overwrite the motherboard Boot ROM. But more than just breaking things, what I really like to do is take things apart and understand how they work and document them, so that other people can build systems on top of them. That's what I'm really excited to be talking to you all about my project Heads, which is an open-source firmware and bootloader for laptops and servers. The name is a play on the popular Tails distribution, which is a stateless Linux for when you don't want to leave any traces of what you're doing on your machine. Heads is for the opposite case. It's where you want to be able to trust the machine and you want to be able to trust that the data you store on the machine is safe and unmodified. Let's back up for a quick minute and just talk about why firmware security is so important. That this is the code that is executed by the CPU when it comes out of reset. This is the first instruction that the CPU executes. So it's in a really privileged position to be able to circumvent any OS or other policies. There's no shortage of talks that you can watch on interesting attack vectors using firmware-based malware. One that I really liked was last year at Defcon, the Intel Advanced Threat Research presented an attack that showed how malicious firmware could circumvent the hypervisors. They then went further and showed how buggy firmware allowed a unprivileged guest inside a virtual machine to escalate into privileges inside the hypervisor. For that reason, it's really important that firmware vulnerabilities and firmware bugs have a way to get patched. These aren't just theoretical research vulnerabilities either. We know that there are malicious organizations and hacking groups that are selling firmware rootkits to whoever will pay, including nation-state adversaries that are using them for their persistent threats. They are very persistent because they are in the motherboard boot ROM. So you reinstall the OS, they're still there. You swap out the hard drive, they're still there. Some vendors are even bundling these rootkits into their official ROMs. They are using them to install the bloatware or whatever adware they want to put into the OS. So even after you reinstall a clean version of the OS, this particular vendors system would install its own additions. Some of those had vulnerabilities that could then be exploited by attackers. This particular case, the vendor received enough bad press that they released a firmware update that patched this vulnerability. They had to do that. This wasn't something that the users could do on their own. They couldn't update the software in their machine the way they do with their operating system or an application. In fact, most firmware vulnerabilities never see patches get deployed out to the end user. Part of the reason for that is that the firmware is usually four or five companies removed from the end user. There's the open-source reference implementation from Intel called Tiano Core or EDK2. When vulnerabilities are patched in there, they have to get pulled by the independent BIOS vendor and merged into the IPV tree. Then the BIOS vendor sells that to the device manufacturers. They have to package up or release the thing that gets pulled by the device manufacturer. It has to get QA to get motherboards they want to test it on. It has to get pulled by the original equipment manufacturer to get rebranded and whatever value they want to add. Sometimes it has to go through the operating system vendor to even make it out to the end user. As a result of this, most of the time products do not receive any updates after they've been sold. There's one exception. In this chart, you can see that Apple builds their own firmware. In my work with them, I've been pleased that they've rolled out patches for eight years of hardware, which is above and beyond what any other firmware vendor is doing right now. When EFI was introduced, it brought a lot of complexity. The Linux community was very skeptical as to what the value was going to be provided by all this complexity. It's basically an entire operating system's worth of code. It's not that the 16-bit real mode BIOS was all that much better. In fact, it had its own set of issues. But it was small. It was simple. It did one thing. It did it okay. It took a long time for UEFI to even become widely supported. Even now, most systems ship with both UEFI and a BIOS compatibility module. They've basically doubled their attack surface for potential bugs and vulnerabilities. The state of the firmware world today is that updates are rare. Patches, if they ever come out, take a long time to make it through the process. Users can't fix things on their own. We can't see what's inside since most of them are built with closed source components. That's not a great state for something that is as privileged as firmware. It's my belief that firmware needs to be built with open source. It must be flexible so we can adapt it to our needs for our systems. It needs to be built with software that we understand and we use for in other applications so it can get widely tested and well tested. It needs to be built in a reproducible manner so we can be secure against build chain attacks. It needs to be cryptographically measured so we can be sure that what we flash on the system is what is actually running on the system. That's the philosophy behind heads. It's built on the free software core boot firmware plus a Linux kernel and ROM that acts as a boot loader and then a lot of security research and tools that help us try to build slightly more secure systems. Using Linux as a boot loader is not a particularly new idea. Back in the 1990s when we started building large scale Linux clusters we were very frustrated with the inflexibility of DHCP and Pixie booting large machines. Even with those frustrations we built one that was about the 30th fastest in the world on the top 500. Meanwhile, my colleague Ron Minnick at Los Alamos was also building large clusters and had the observation that the BIOS enumerates all the buses, initializes a bunch of devices, finds Linux kernel and then the Linux kernel enumerates all the buses, initializes all the devices. He thought this is silly. Why are we doing this twice? He had the idea to build a version of Linux that ran in the ROM. He called this project Linux BIOS and it went on to power the MRC cluster which was the third fastest machine in the world in 2003. In 2008 Linux BIOS underwent a major refactoring and it was renamed to core boot. Google chose to use core boot as the firmware on their Chromebooks which are at this point the only non UEFI X86 based laptops that you can buy. They've done some great work in trying to lock down the configuration and the firmware on the Chromebooks. Ron moved to Google in 2011 and is continuing to work on the core boot project there. So core boot has three stages that it goes through as it starts up the machine. The first one is a very small amount of real mode assembly because your modern 64 bit laptop still boots up in real mode with 16 bit just like it's 1970s. So that's a very small amount of code, about 1.5K. That in turn sets up a C runtime environment with what's called cache's RAM mode and it calls into the ROM stage which is about 70K. Heads has moved the TPM initialization early in the ROM stage before DRAM is set up to help measure the boot block and provide a static root of trust that's hopefully a little bit more secure. Because that measurement is done early on, our trusted computing base is actually quite small. This is a fraction of 1% of the size of a UEFI firmware which is usually about 16 megs once it's uncompressed. The ROM stage then measures and executes the RAM stage which does the more traditional walk the bus, figure out what devices are on there, but it doesn't initialize them. It just enumerates them and generates the descriptors for Linux. It also installs the SMM handler for system management mode. It then measures and jumps into the payload and that whole process takes less than a second. So the is able to get into the payload and actually get to the user code very, very quickly. From something like the X230, it's able to go from power on to a interactive recovery shell in less than two seconds. And that includes bring up the TPM doing cryptographic measurements and assessing the state of the system. Because we now have Linux at this point, we have all the flexibility that comes with that. We can implement boot scripts as with the full power of the shell or the C language runtime. We're not stuck with the limited functions of UEFI. Linux supports lots of different file systems. It supports lots of different devices. It supports lots of different encryption methods. And this gives us the ability to use any of them for your specific application. In contrast, UEFI which supports unencrypted, fat file systems on the first drive that have to be in the first one gig or something. It's really, really limited as to how it can find its boot device. There's a saying in the open source community that with enough eyes, all bugs are shallow. And Linux has a lot more eyes looking at it. The device drivers and the file systems and the encryption have been reviewed by both White Hat and Black Hat people around the world. The UEFI versions of these do not have that same level of scrutiny. So using both the UEFI drivers and then having to run whatever on top of it increases the attack surface. But by putting Linux in the ROM and depending on its drivers, we've reduced our attack surface very dramatically. More importantly, core boot and Linux are open source. So it is possible to build custom versions for the device drivers that you need, for file systems that you need. It's possible to fix bugs when they come out and sign and install your own kernels. You don't have to wait for the vendor to get around to doing that. And the third major component of Heads is a tool called K-Exec, which is a system call that was added for the Linux BIOS project back in 2003 by Eric Biederman that allows a running kernel to do a graceful shutdown and start a new kernel without having to go through the reboot process. So this allowed, on their application, it allowed them to do very fast reboots of their cluster nodes. And in the Heads case, it allows us to act as a boot loader where we can find the real kernel that you want to run and exec it. Because Heads is quite small. It has to fit in four megabytes of ROM. So it's not something that you're going to run as a day-to-day OS. Hopefully this won't explode on me again. Because we have the born shell, most of the policies and the startup scripts in Heads are implemented as shell scripts. In this case, we're able to pass in a new set of command line parameters, a new initial RAM disk, and in this case, we can even start a hypervisor. And all of that can happen very, very quickly, as well as with a good degree of security. So those are the building blocks that Heads is built on, core boot, Linux, and tools like K-Exec. But it now gives us a really nice platform to begin experimenting with additional security features. And before we go too deep down the rabbit hole of security and threat models, I want to quote my friend Steph, who said that, your threat model is not my threat model. But your threat model is OK, as well. That we all have different things we want to protect from different attackers who are willing to spend different amounts of effort to go after them. And the nice thing about Heads and Open Source is we can build systems tailored to your individual threat model. So a lot of these things may not actually apply to your specific threats, but the fact that we can build them is a great capability. Last year, Johanna Rotowska reminded us that firmware is not just in our CPU. Firmware is in our Wi-Fi card. It is in our GPU. It is in our SSD. It is in our keyboards. And all of these devices might be trying to subvert the boot process. One way to handle that is to take Peter Stugus' advice of just assembling the machine and ripping out anything we can't control. If this is your threat model, his instructions are really worth following. They're really thorough about what pieces are potentially of concern. And you're going, right now, you will have to open up your laptop to install Heads. It's not quite as easy to install as most Linux distributions because we have to flash it into the motherboard boot ROM. While we're in there, we take advantage of some features that, to the best of my knowledge, no UEFI system is using. These flash chips have a hardware write protect mode where you can specify part of the chip is write only, excuse me, is read only, write once. And this gives us our immutable boot block in which to store the trusted computing base, the TCB, so that we can measure the rest of the system. We also then suggest disconnecting the write protect pin from the motherboard, which protects against certain classes of attacks like the Intel closed chassis adapter that allows external JTAG of the CPU. Depending on your threat model, you might want to cover that chip in epoxy as well to frustrate evil made attacks that want to do physical programming on it. Disconnecting the write protect pin also serves to protect from other devices on the machine that have access to those pins. This is like the management engine, which is a really scary CPU inside the CPU. Rudolph Merrick two years ago at CCC called it the Matroyshka CPU. And Igor Skraczinski detailed what are the capabilities of the management engine. And they're really worrisome that it runs a opaque obfuscated blob of code, about five megabytes, that the CPU can't see. The management engine can read and write all of main memory. It can read from the keyboard and video. It can receive Java byte codes over the network and execute them on behalf of someone outside the machine. And it's listening on the network even when the system is powered off. So this is basically a root kit inside the chip set, as some folks have called it. So that concerned me a lot. And I spent some time looking at how its firmware images are built and realized that we can build modified reduced functionality firmware for it that removes all of the root kit functions and just leaves the CPU bring up module. This takes that five megabytes and shrinks it down to about 40K of space. So we don't know exactly what it's doing in that 40K, but we at least know it doesn't have a device driver or a Java virtual machine or a lot of the other functions. And we've successfully done this on both Sandy Bridge and Ivy Bridge, like the X230 ThinkPads, as well as modern Skylake CPUs, like the Chel Chromebook. And that's really encouraging that if we can apply this to more modern hardware, that allows us to move away from our five-year-old ThinkPads to something a little shinier. So the management engine isn't the only device that might be trying to separate the boot process. Again, Johanna showed us there are lots of things to be worried about. Intel's UEFI architects, Yao and Zimmer, recommend that firmware turn on the IOMMU, called VTD, to protect against road devices. To the best of my knowledge, since they've written this guide, no UEFI firmware is taken advantage of the IOMMU. So it's a great piece of hardware to have, but it doesn't help if you don't turn it on. Linux, meanwhile, has no problem taking advantage of it. So we use it, essentially, we get that DMA protection for free by using Linux as our boot loader in the ROM. Another way road devices can try to interfere with the boot process is by providing option ROMs, which are executable code to be run by the BIOS that have sort of a device driver. And this code can do things like log keystrokes and then try to exfiltrate passwords, as we see here. That problem was initially reported in 2007 by John Heisman at Black Hat, again by Snare in 2012, and then again by my work on Thunderstrike. And as of last week, a official fix has finally rolled out for it to close that particular vulnerability. Folks who are using Coreboot have this as an option that they can say, I am concerned about this threat. Let me fix this. Let me disable this function. And they point out that it might cause degraded functionality, but that's something you can QA on your own system. And in practice, with Linux as your boot loader in the ROM, you don't use the option ROMs for anything. Everything is done with Linux's own device drivers. So you're not dependent on the whatever limited functionality the option ROM provided. So now that we have taken our building blocks and we hopefully have protected the boot process and hopefully the code that's running is what we think it is, we need to turn to how do we secure the secrets on the machine. And I'm a huge fan of the TPM, the Trusted Platform Module. And I know in the free software community, it's been largely unwelcome. It has not received a very welcome reception. Because of the way it's been used for DRM and other user hostile things. Since we control the TPM from the first instruction in the boot block, we're able to use it in ways that we want to. So we don't have to enable DRM, but we can use it to protect our secrets. And the way that it does that is it keeps track of what code is executed as the system boots. And it hashes that code into special registers called PCRs. And the idea is that you can extend the PCR by hashing the next module of code and then hashing that with the previous hash. And this creates a chain of trust that allows us to say if these hashes match the expected values, only the code that we want to have run has run. And then the TPM will only decrypt the disk encryption key if those PCRs match, which means that the code that we want to have run is what has been executed. This means if someone manages to overwrite the non-right protected part of the ROM, that will change those measurements and the TPM won't reveal the key to them. It also takes a user password, and that password is validated by the TPM hardware itself, which gives us hardware rate limiting on how often an attacker can try. It also gives us the ability to do hardware-based retry limits so that the TPM will flush the key if an attacker in possession of your machine tries too long. That does mean there's now another way to lose your disk encryption key. And there's the old joke about there are two types of people with encrypted drives, those who have lost data due to forgetting their key and those who will. So what Heads does when you generate your key is it takes that key and splits it into multiple pieces that you can then share either to friends or to backup services, where each piece doesn't let you decrypt it, but you can combine them with Shamiro secret sharing to regenerate the cryptographic disk encryption key. We're also able to take advantage of best practices, like including the disk encryption key headers in the PCRs that we use to seal the disks. This avoids a certain class of evil mate attack where someone swaps out your drive, may not be in your threat model, but it's easy to do with just a few lines of shell script. So hopefully we now trust that the system is running the code we think it is, but how does it prove to us that it is actually our machine, that someone hasn't snuck into our hotel room and swapped out everything and carefully replaced our stickers to make us believe we're typing our password into our own computer. Some anti-evil made toolkits will encrypt a secret phrase and then display it to you if and only if the PCRs match, but that's subject to a replay attack. What Matthew Garrett demonstrated last year at 32C3 was using the time-based one-time password used by Google Authenticator to protect the firmware and have it attest to the user that it is unmodified. So when the system boots and goes through measuring all of the various components, the TPM will only release the secret if those PCRs match. The firmware then hashes that along with the current time and generates a six-digit value that it prints on the screen. You compare that to what's on your phone and that tells you whether or not you can trust the machine. It's a great idea and it's implemented again as a very small shell script to read the value from the TPM, unseal it, and then compute the hash of it. This also allows us to start making a transition from the TPM static root of trust to a PGP base trust where most importantly, this is a TPM key, excuse me, this is a PGP key that you, the owner of the computer control, not some random vendor or some random hardware device manufacturer that's going to lose the key and allow malware like Stuxnet to use it to circumvent security. The boot script in heads, again, it's a small shell script, is able to use GPG to verify the next stages of the hypervisor at the initial RAM disk and the kernel. And it's also then uses the TPM's counters to help prevent against rollback where someone takes your drive and rolls it back to a previous version, perhaps with a vulnerability that they can exploit. So this allows us to be sure that not only are we running the firmware, excuse me, the OS that we think we should be running, it ensures us that someone hasn't been able to substitute one that, a vulnerable version. Even the PGP key also allows us to take advantage of an idea from Android and Chrome OS, which is the DM Verity read-only root file system. This hashes all of the blocks and then hashes all of the hashes and so on up until it gets to a root hash in the tree that is then signed. This allows the kernel on every read access in logarithmic time to verify essentially a signature on that data. This does require a read-only root file system, but it gives us even more confidence that the system has been untampered with. Once you're running your OS, it's good to have some security-conscious thoughts as well. This is mostly focused on how do we securely transition to an OS, and that's OS you run is up to you. I like Cubes. It's reasonably secure. It's highly recommended by people who know about endpoint security. And the Cubes team recognizes that firmware security is a vital piece of system security. For their next release, Cubes R4, they're going to require the machines have open source firmware such as Corbude, and I hope that Hedge is going to be a piece of that. I've also been working with the Cubes software and have modified it to work with things like the DMVarity read-only root file system. This now allows the user to lock down the configuration so that someone can't tamper with their setup. It also gives you a recovery mode that allows you to fix things up and re-sign the OS. Reproducible builds are really important so that everyone can verify that the builds match what they should. In the case of Hedge, we have a lot of upstream dependencies that aren't reproducible, so we're working with them to try to patch them. We've patched as in. They've accepted that commit. We've also built some tools to let you build initial RAM disks in a reproducible way. This works with Cubes, with Hedge, and we're hoping other Linux distributions pick it up as well. All of our tree is cryptographically signed, so hopefully GitHub's not trying to slip in any patches. It is open source, so we encourage everyone to read through it. No NDA is required, unlike most of the UEFI sources. It's the state of where things are. It's pretty much in very beta, but it is usable. There are a lot of areas where we can continue to do research, things like the embedded controllers on Chromebooks are open source. We can use those to help with our route of trust as well. Porting core boot to more modern platforms would let us take advantage of things like tamper switches and Intel boot guard. I'm also working on porting core boot over to server platforms so that we can use it for more secure cloud hosting. Servers have a very different threat model from laptops, and a lot of things have firmware that we have to be concerned about. One collaboration I'm looking at there is with the OpenBMC project to be able to take advantage of the open source in the management controller for the servers. I'm also collaborating with the MassOpen cloud project that's trying to build secure bare metal clouds. I'm cautiously optimistic about enclaves and how they will help us with security, especially in an environment where we control the firmware and we can ensure that the enclaves are set up in a safe way. There are a lot of issues on GitHub. Again, please welcome contributions. I hope everyone gets inspired to work on installing this on their laptop. If you are interested, I'll be hanging out at the core boot assembly later today and occasionally this week. The core boot team has a bunch of people here. They have flash programmers and can help you install core boot on your laptop. This code for heads is available on GitHub. A annotated version of this talk is up on my website. Welcome comments and feedback on it. Thank you all for coming to hear about this project. I hope everyone is as excited about Open Source firmware as I am. I'd love to take any questions that you all have. Thanks for your great talk. This is very interesting. Do you have any advice for the 95% of us who are stuck on non-core boot compatible laptops? Buy a Chromebook? It's hard to trust the closed source firmware. There are people we have to trust. There are institutions we have to trust. We have to trust Intel to some extent. Intel is responsible for both our CPUs and a lot of the firmware. The, depending on your threat model, firmware attacks may not be a huge concern for your particular machine. Or they might be grave concern. In which case, even just doing some of the things that Peter suggested, clipping the right protect pin on the chip, removing things that might be hostile and attacking your system. His guide is a really good one to follow for the hardware security. I was wondering if you also support ARM? I just saw Intel laptops. I was wondering. So ARM has a lot of advantages as a CPU. It only has 20 years of legacy baggage rather than 40. And the boot process on it is much, much simpler since it doesn't have to go through real mode to long mode to paging and all the other steps. The downside to a lot of ARMs is that their boot code is on die and outside of the control of the user. Probably most of that boot code is fairly simple and can, and some of them will establish a hardware root of trust. But in general, the ARM to U-boot to whatever seems to work out pretty well. I know there's been some interest in can U-boot be replaced with a Linux BIOS or core boot like thing. And I suspect the folks at the booth would be able to talk more about that. And then just to follow up. So if core boot or lipo boot supports the platform, it heads will work too, right? Essentially, yes. It heads is a payload for core boot. It's there on the left. Thank you. I'm from the Internet about core boot. Core boot has blobs included. And for example, binary blobs from Intel with all the firmware support package and all that stuff. How can we call core boot secure then in the light of this? Let alone open source. So the Intel FSP is a significant concern. This is the firmware support package that is required to initialize the memory controllers on modern Intel CPUs. On older CPUs, such as the Sandy Bridge and Ivy Bridge, the core boot and lipo boot are able to initialize the memory natively without having to go into the FSP. However, if you look at what core boot is doing in the MRC on those platforms, it tends to just be poking a bunch of registers with values that seem to work. And modern memory controllers are so complex that an Intel is unwilling to document them without extensive NDAs. That it's very hard to build any sort of memory initialization. So while we can't say it's 100% free software, we can at least, we can ensure that the FNC FSP is measured and it's unchanging. We can also look at the state of things that it sets up and include those in our measurements. So even if it doesn't give us 100% open source, as far as I know, the only system that does that right now is Bunny's and Novena laptop. At least we can measure it and we can know that it hasn't been tampered with from what we initially installed. Number four. Hi, so this is a great project and I'd like to ask why you did certain architectural decisions, the specific combination of Linux and Shell. So why didn't you choose BSD kernel, which are usually perceived to be more secure and of a higher quality? Why did you choose the Shell over, let's say, Python or Haskell, which are also often perceived of higher quality? So there is a lot of desire to support Python in heads. The downside is that there's very limited space. The X230 boot ROM, for instance, has four megabytes of available space. The Python interpreters a couple of megs already. The, in terms of why Linux over BSD, the Kexex system call is a core component of this. To be able to do a crease will shut down and transfer from the Linux kernel to another kernel or to any multi-boot compliant kernels, which includes BSD, is a necessary feature. If BSD had such functionality, it would be a fine choice for the internal boot ROM boot litter. Thanks for great work. How to perform updates of Core Boot and its payload? When its binary is used in measurement for releasing encryption key, then when you update Core Boot, this measurement will change and you will no longer be able to boot the system. How to solve that problem? So migrated encryption keys with TPM requires a explicit step of retrieving the key from the TPM with the current configuration and then resealing it with the new configuration. One advantage of a reproducible build is the hashes of all the firmware stages can be published, can be pre-computed, and then the PCR values can be pre-computed. So you can seal the keys for the new values. In terms of the update process for the heads payload, one of the things that we're working on is being able to have a even more minimal heads that has just a USB device driver that you can boot into, copy your new payload, and then install that elsewhere on the chip. And part of that process would involve resealing any of the keys that you need to transfer. Another question from the Internet. Thank you. On your web page, you implemented head on ThinkPads only. How much work is still needed to translate this to, let's say, non-ThinkPads? ThinkPads are really popular with the security community. It's quite interesting to look out at the hall here and see how many ThinkPads there are. And as a result, the CoreBoot community has been very supportive of ThinkPads. Other than the ThinkPads and the Chromebooks, there aren't a lot of devices that support CoreBoot out of the box. And that's something that I hope would change. I hope that some OEMs would realize there is value in providing open source firmware and move to using it, both as a cost saving measure as well as a freedom measure. In terms of the difficulty importing CoreBoot to a platform, I haven't successfully done that yet, but I suspect the people at the assembly would be happy to discuss that further. What do you plan to rework and embed the control firmware on ThinkPads because it's a remaining closed part which still has access to the PC bus and probably couldn't be trusted? So your question is how do we replace the EC? Yes, do you plan to replace EC with open source firmware in Chromebooks? So the Chromebook has open source EC. The part of building CoreBoot for Chromebook involves installing the ARM cross compiler to build the EC firmware. And the Chromebooks actually have a really elegant protocol for the EC to attest to the CPU that it is running the firmware that you think it is running. On other platforms, this would require a lot more research. Many of the EC chipsets have data sheets available, so it's possible to read through and see how they work. And most of them have updatable firmware. In the case of the ThinkPads, there's a module in the ThinkPad BIOS that will do that update. We would need to figure out what that protocol looks like. Sorry. Yes, I mean, if you have working prototype on Syncpads, probably want to add a remaining bit as open source EC on Syncpads as well. The first place. I'm sorry. I don't think I understood your follow-up. Okay. So if you have working prototype on Syncpads and only on Syncpads, will you finish someone soon, a current existing prototype of open source EC existing on H8, or are you planning to extend your work on other platforms and finish these bits later? Yeah. Right now, I have not personally made any progress on the ThinkPad EC. I was looking into it because I have a modified keyboard on my ThinkPad that needs an updated EC firmware, but I haven't actually gotten into that. That's an area of open research. Thank you. Two quick questions from the IRC. Are you planning to use SystemD in the boot process? Yes. It's the first one. And the second one. I say you flash your firmware at the Congress right here with the help of a hardware programmer. Can you update when there's a new version, or do you have to currently need the hardware access to update? Right now, you can update afterwards at great risk because you can leave the flash writable, and then you can flash, which would allow you to flash after the fact. We are still working on a good procedure for doing software-only firmware updates once the boot, the immutable boot block is installed. And to the other question, did I mention that we are really short on space and we don't want to put any large applications like SystemD on there? It was a good one. Thanks. Thank you all.
 So the last speaker for this morning is Traml.  He's doing awesome research on  Bootstrapping more secure laptops or servers.  He's doing that basically by moving  the root of trust into the right protected ROM.  He's building an open-source custom firmware,  so big ups for that,  and also encouraging the research on this field,  which I believe it's super interesting. Thanks.  So I'm Traml Hudson with two-segment investments,  and for the past several years,  I've been researching firmware security vulnerabilities and  looking at how they affect systems.  Two years ago, I presented my work on  Thunderstrike here at CCC.  This was the first firmware attack against  Macbooks that allowed an attacker to  overwrite the motherboard Boot ROM.  The year after that,  I collaborated with Zeno Kova and Corey Kalenberg from  Legbacore, both of whom are now at  Apple doing firmware work,  and we ported a bunch of Windows UE5 vulnerabilities over to  the Mac and showed that the software platform,  the UE5 software platform,  allowed very portable attacks to be done.  This also allowed a remote attacker with  code execution on your machine to  overwrite the motherboard Boot ROM.  But more than just breaking things,  what I really like to do is take things apart and  understand how they work and document them,  so that other people can build systems on top of them.  That's what I'm really excited to be talking to you all about  my project Heads, which is  an open-source firmware and  bootloader for laptops and servers.  The name is a play on the popular Tails distribution,  which is a stateless Linux for when you don't want to leave  any traces of what you're doing on your machine.  Heads is for the opposite case.  It's where you want to be able to trust the machine and you want to be able to  trust that the data you store on the machine is safe and unmodified.  Let's back up for a quick minute and just talk about why  firmware security is so important.  That this is the code that is executed by  the CPU when it comes out of reset.  This is the first instruction that the CPU executes.  So it's in a really privileged position to be able to circumvent  any OS or other policies.  There's no shortage of talks that you can watch on  interesting attack vectors using firmware-based malware.  One that I really liked was last year at Defcon,  the Intel Advanced Threat Research presented an attack  that showed how malicious firmware could circumvent the hypervisors.  They then went further and showed how buggy firmware  allowed a unprivileged guest inside a virtual machine  to escalate into privileges inside the hypervisor.  For that reason, it's really important that  firmware vulnerabilities and firmware bugs have a way to get patched.  These aren't just theoretical research vulnerabilities either.  We know that there are malicious organizations and hacking groups that are  selling firmware rootkits to whoever will pay,  including nation-state adversaries that are using them for their persistent threats.  They are very persistent because they are in the motherboard boot ROM.  So you reinstall the OS, they're still there.  You swap out the hard drive, they're still there.  Some vendors are even bundling these rootkits into their official ROMs.  They are using them to install the bloatware or whatever adware they want to put into the OS.  So even after you reinstall a clean version of the OS,  this particular vendors system would install its own additions.  Some of those had vulnerabilities that could then be exploited by attackers.  This particular case, the vendor received enough bad press that they released  a firmware update that patched this vulnerability.  They had to do that.  This wasn't something that the users could do on their own.  They couldn't update the software in their machine the way they do with  their operating system or an application.  In fact, most firmware vulnerabilities never see patches get deployed out to the end user.  Part of the reason for that is that the firmware is usually four or five companies  removed from the end user.  There's the open-source reference implementation from Intel called Tiano Core or EDK2.  When vulnerabilities are patched in there, they have to get pulled by the independent  BIOS vendor and merged into the IPV tree.  Then the BIOS vendor sells that to the device manufacturers.  They have to package up or release the thing that gets pulled by the device manufacturer.  It has to get QA to get motherboards they want to test it on.  It has to get pulled by the original equipment manufacturer to get rebranded and whatever  value they want to add.  Sometimes it has to go through the operating system vendor to even make it out to the end  user.  As a result of this, most of the time products do not receive any updates after they've been  sold.  There's one exception.  In this chart, you can see that Apple builds their own firmware.  In my work with them, I've been pleased that they've rolled out patches for eight years  of hardware, which is above and beyond what any other firmware vendor is doing right now.  When EFI was introduced, it brought a lot of complexity.  The Linux community was very skeptical as to what the value was going to be provided  by all this complexity.  It's basically an entire operating system's worth of code.  It's not that the 16-bit real mode BIOS was all that much better.  In fact, it had its own set of issues.  But it was small.  It was simple.  It did one thing.  It did it okay.  It took a long time for UEFI to even become widely supported.  Even now, most systems ship with both UEFI and a BIOS compatibility module.  They've basically doubled their attack surface for potential bugs and vulnerabilities.  The state of the firmware world today is that updates are rare.  Patches, if they ever come out, take a long time to make it through the process.  Users can't fix things on their own.  We can't see what's inside since most of them are built with closed source components.  That's not a great state for something that is as privileged as firmware.  It's my belief that firmware needs to be built with open source.  It must be flexible so we can adapt it to our needs for our systems.  It needs to be built with software that we understand and we use for in other applications  so it can get widely tested and well tested.  It needs to be built in a reproducible manner so we can be secure against build chain attacks.  It needs to be cryptographically measured so we can be sure that what we flash on the  system is what is actually running on the system.  That's the philosophy behind heads.  It's built on the free software core boot firmware plus a Linux kernel and ROM that acts as  a boot loader and then a lot of security research and tools that help us try to build slightly  more secure systems.  Using Linux as a boot loader is not a particularly new idea.  Back in the 1990s when we started building large scale Linux clusters we were very frustrated  with the inflexibility of DHCP and Pixie booting large machines.  Even with those frustrations we built one that was about the 30th fastest in the world  on the top 500.  Meanwhile, my colleague Ron Minnick at Los Alamos was also building large clusters and  had the observation that the BIOS enumerates all the buses, initializes a bunch of devices,  finds Linux kernel and then the Linux kernel enumerates all the buses, initializes all  the devices.  He thought this is silly.  Why are we doing this twice?  He had the idea to build a version of Linux that ran in the ROM.  He called this project Linux BIOS and it went on to power the MRC cluster which was the third  fastest machine in the world in 2003.  In 2008 Linux BIOS underwent a major refactoring and it was renamed to core boot.  Google chose to use core boot as the firmware on their Chromebooks which are at this point  the only non UEFI X86 based laptops that you can buy.  They've done some great work in trying to lock down the configuration and the firmware  on the Chromebooks.  Ron moved to Google in 2011 and is continuing to work on the core boot project there.  So core boot has three stages that it goes through as it starts up the machine.  The first one is a very small amount of real mode assembly because your modern 64 bit laptop  still boots up in real mode with 16 bit just like it's 1970s.  So that's a very small amount of code, about 1.5K.  That in turn sets up a C runtime environment with what's called cache's RAM mode and it  calls into the ROM stage which is about 70K.  Heads has moved the TPM initialization early in the ROM stage before DRAM is set up to help  measure the boot block and provide a static root of trust that's hopefully a little bit  more secure.  Because that measurement is done early on, our trusted computing base is actually quite  small.  This is a fraction of 1% of the size of a UEFI firmware which is usually about 16 megs  once it's uncompressed.  The ROM stage then measures and executes the RAM stage which does the more traditional  walk the bus, figure out what devices are on there, but it doesn't initialize them.  It just enumerates them and generates the descriptors for Linux.  It also installs the SMM handler for system management mode.  It then measures and jumps into the payload and that whole process takes less than a second.  So the is able to get into the payload and actually get to the user code very, very quickly.  From something like the X230, it's able to go from power on to a interactive recovery  shell in less than two seconds.  And that includes bring up the TPM doing cryptographic measurements and assessing the state of the  system.  Because we now have Linux at this point, we have all the flexibility that comes with  that.  We can implement boot scripts as with the full power of the shell or the C language runtime.  We're not stuck with the limited functions of UEFI.  Linux supports lots of different file systems.  It supports lots of different devices.  It supports lots of different encryption methods.  And this gives us the ability to use any of them for your specific application.  In contrast, UEFI which supports unencrypted, fat file systems on the first drive that have  to be in the first one gig or something.  It's really, really limited as to how it can find its boot device.  There's a saying in the open source community that with enough eyes, all bugs are shallow.  And Linux has a lot more eyes looking at it.  The device drivers and the file systems and the encryption have been reviewed by both  White Hat and Black Hat people around the world.  The UEFI versions of these do not have that same level of scrutiny.  So using both the UEFI drivers and then having to run whatever on top of it increases the  attack surface.  But by putting Linux in the ROM and depending on its drivers, we've reduced our attack surface  very dramatically.  More importantly, core boot and Linux are open source.  So it is possible to build custom versions for the device drivers that you need, for  file systems that you need.  It's possible to fix bugs when they come out and sign and install your own kernels.  You don't have to wait for the vendor to get around to doing that.  And the third major component of Heads is a tool called K-Exec, which is a system call  that was added for the Linux BIOS project back in 2003 by Eric Biederman that allows  a running kernel to do a graceful shutdown and start a new kernel without having to go  through the reboot process.  So this allowed, on their application, it allowed them to do very fast reboots of their  cluster nodes.  And in the Heads case, it allows us to act as a boot loader where we can find the real  kernel that you want to run and exec it.  Because Heads is quite small.  It has to fit in four megabytes of ROM.  So it's not something that you're going to run as a day-to-day OS.  Hopefully this won't explode on me again.  Because we have the born shell, most of the policies and the startup scripts in Heads  are implemented as shell scripts.  In this case, we're able to pass in a new set of command line parameters, a new initial  RAM disk, and in this case, we can even start a hypervisor.  And all of that can happen very, very quickly, as well as with a good degree of security.  So those are the building blocks that Heads is built on, core boot, Linux, and tools  like K-Exec.  But it now gives us a really nice platform to begin experimenting with additional security  features.  And before we go too deep down the rabbit hole of security and threat models, I want to quote  my friend Steph, who said that, your threat model is not my threat model.  But your threat model is OK, as well.  That we all have different things we want to protect from different attackers who are  willing to spend different amounts of effort to go after them.  And the nice thing about Heads and Open Source is we can build systems tailored to your individual  threat model.  So a lot of these things may not actually apply to your specific threats, but the fact that  we can build them is a great capability.  Last year, Johanna Rotowska reminded us that firmware is not just in our CPU.  Firmware is in our Wi-Fi card.  It is in our GPU.  It is in our SSD.  It is in our keyboards.  And all of these devices might be trying to subvert the boot process.  One way to handle that is to take Peter Stugus' advice of just assembling the machine and  ripping out anything we can't control.  If this is your threat model, his instructions are really worth following.  They're really thorough about what pieces are potentially of concern.  And you're going, right now, you will have to open up your laptop to install Heads.  It's not quite as easy to install as most Linux distributions because we have to flash  it into the motherboard boot ROM.  While we're in there, we take advantage of some features that, to the best of my knowledge,  no UEFI system is using.  These flash chips have a hardware write protect mode where you can specify part of the chip  is write only, excuse me, is read only, write once.  And this gives us our immutable boot block in which to store the trusted computing base,  the TCB, so that we can measure the rest of the system.  We also then suggest disconnecting the write protect pin from the motherboard, which protects  against certain classes of attacks like the Intel closed chassis adapter that allows external  JTAG of the CPU.  Depending on your threat model, you might want to cover that chip in epoxy as well to  frustrate evil made attacks that want to do physical programming on it.  Disconnecting the write protect pin also serves to protect from other devices on the  machine that have access to those pins.  This is like the management engine, which is a really scary CPU inside the CPU.  Rudolph Merrick two years ago at CCC called it the Matroyshka CPU.  And Igor Skraczinski detailed what are the capabilities of the management engine.  And they're really worrisome that it runs a opaque obfuscated blob of code, about five  megabytes, that the CPU can't see.  The management engine can read and write all of main memory.  It can read from the keyboard and video.  It can receive Java byte codes over the network and execute them on behalf of someone outside  the machine.  And it's listening on the network even when the system is powered off.  So this is basically a root kit inside the chip set, as some folks have called it.  So that concerned me a lot.  And I spent some time looking at how its firmware images are built and realized that we can  build modified reduced functionality firmware for it that removes all of the root kit functions  and just leaves the CPU bring up module.  This takes that five megabytes and shrinks it down to about 40K of space.  So we don't know exactly what it's doing in that 40K, but we at least know it doesn't  have a device driver or a Java virtual machine or a lot of the other functions.  And we've successfully done this on both Sandy Bridge and Ivy Bridge, like the X230  ThinkPads, as well as modern Skylake CPUs, like the Chel Chromebook.  And that's really encouraging that if we can apply this to more modern hardware, that  allows us to move away from our five-year-old ThinkPads to something a little shinier.  So the management engine isn't the only device that might be trying to separate the boot  process.  Again, Johanna showed us there are lots of things to be worried about.  Intel's UEFI architects, Yao and Zimmer, recommend that firmware turn on the IOMMU,  called VTD, to protect against road devices.  To the best of my knowledge, since they've written this guide, no UEFI firmware is taken  advantage of the IOMMU.  So it's a great piece of hardware to have, but it doesn't help if you don't turn it  on.  Linux, meanwhile, has no problem taking advantage of it.  So we use it, essentially, we get that DMA protection for free by using Linux as our  boot loader in the ROM.  Another way road devices can try to interfere with the boot process is by providing option  ROMs, which are executable code to be run by the BIOS that have sort of a device driver.  And this code can do things like log keystrokes and then try to exfiltrate passwords, as we  see here.  That problem was initially reported in 2007 by John Heisman at Black Hat, again by Snare  in 2012, and then again by my work on Thunderstrike.  And as of last week, a official fix has finally rolled out for it to close that particular  vulnerability.  Folks who are using Coreboot have this as an option that they can say, I am concerned  about this threat.  Let me fix this.  Let me disable this function.  And they point out that it might cause degraded functionality, but that's something you can  QA on your own system.  And in practice, with Linux as your boot loader in the ROM, you don't use the option ROMs  for anything.  Everything is done with Linux's own device drivers.  So you're not dependent on the whatever limited functionality the option ROM provided.  So now that we have taken our building blocks and we hopefully have protected the boot process  and hopefully the code that's running is what we think it is, we need to turn to how do  we secure the secrets on the machine.  And I'm a huge fan of the TPM, the Trusted Platform Module.  And I know in the free software community, it's been largely unwelcome.  It has not received a very welcome reception.  Because of the way it's been used for DRM and other user hostile things.  Since we control the TPM from the first instruction in the boot block, we're able to use it in  ways that we want to.  So we don't have to enable DRM, but we can use it to protect our secrets.  And the way that it does that is it keeps track of what code is executed as the system  boots.  And it hashes that code into special registers called PCRs.  And the idea is that you can extend the PCR by hashing the next module of code and then  hashing that with the previous hash.  And this creates a chain of trust that allows us to say if these hashes match the expected  values, only the code that we want to have run has run.  And then the TPM will only decrypt the disk encryption key if those PCRs match, which  means that the code that we want to have run is what has been executed.  This means if someone manages to overwrite the non-right protected part of the ROM, that  will change those measurements and the TPM won't reveal the key to them.  It also takes a user password, and that password is validated by the TPM hardware itself, which  gives us hardware rate limiting on how often an attacker can try.  It also gives us the ability to do hardware-based retry limits so that the TPM will flush the  key if an attacker in possession of your machine tries too long.  That does mean there's now another way to lose your disk encryption key.  And there's the old joke about there are two types of people with encrypted drives, those  who have lost data due to forgetting their key and those who will.  So what Heads does when you generate your key is it takes that key and splits it into  multiple pieces that you can then share either to friends or to backup services, where each  piece doesn't let you decrypt it, but you can combine them with Shamiro secret sharing  to regenerate the cryptographic disk encryption key.  We're also able to take advantage of best practices, like including the disk encryption  key headers in the PCRs that we use to seal the disks.  This avoids a certain class of evil mate attack where someone swaps out your drive, may not  be in your threat model, but it's easy to do with just a few lines of shell script.  So hopefully we now trust that the system is running the code we think it is, but how  does it prove to us that it is actually our machine, that someone hasn't snuck into our  hotel room and swapped out everything and carefully replaced our stickers to make us  believe we're typing our password into our own computer.  Some anti-evil made toolkits will encrypt a secret phrase and then display it to you  if and only if the PCRs match, but that's subject to a replay attack.  What Matthew Garrett demonstrated last year at 32C3 was using the time-based one-time  password used by Google Authenticator to protect the firmware and have it attest to  the user that it is unmodified.  So when the system boots and goes through measuring all of the various components, the  TPM will only release the secret if those PCRs match.  The firmware then hashes that along with the current time and generates a six-digit value  that it prints on the screen.  You compare that to what's on your phone and that tells you whether or not you can trust  the machine.  It's a great idea and it's implemented again as a very small shell script to read the value  from the TPM, unseal it, and then compute the hash of it.  This also allows us to start making a transition from the TPM static root of trust to a PGP  base trust where most importantly, this is a TPM key, excuse me, this is a PGP key that  you, the owner of the computer control, not some random vendor or some random hardware  device manufacturer that's going to lose the key and allow malware like Stuxnet to use  it to circumvent security.  The boot script in heads, again, it's a small shell script, is able to use GPG to verify  the next stages of the hypervisor at the initial RAM disk and the kernel.  And it's also then uses the TPM's counters to help prevent against rollback where someone  takes your drive and rolls it back to a previous version, perhaps with a vulnerability that  they can exploit.  So this allows us to be sure that not only are we running the firmware, excuse me, the  OS that we think we should be running, it ensures us that someone hasn't been able to  substitute one that, a vulnerable version.  Even the PGP key also allows us to take advantage of an idea from Android and Chrome OS, which  is the DM Verity read-only root file system.  This hashes all of the blocks and then hashes all of the hashes and so on up until it gets  to a root hash in the tree that is then signed.  This allows the kernel on every read access in logarithmic time to verify essentially a  signature on that data.  This does require a read-only root file system, but it gives us even more confidence that  the system has been untampered with.  Once you're running your OS, it's good to have some security-conscious thoughts as well.  This is mostly focused on how do we securely transition to an OS, and that's OS you run  is up to you.  I like Cubes.  It's reasonably secure.  It's highly recommended by people who know about endpoint security.  And the Cubes team recognizes that firmware security is a vital piece of system security.  For their next release, Cubes R4, they're going to require the machines have open source  firmware such as Corbude, and I hope that Hedge is going to be a piece of that.  I've also been working with the Cubes software and have modified it to work with things like  the DMVarity read-only root file system.  This now allows the user to lock down the configuration so that someone can't tamper  with their setup.  It also gives you a recovery mode that allows you to fix things up and re-sign the OS.  Reproducible builds are really important so that everyone can verify that the builds match  what they should.  In the case of Hedge, we have a lot of upstream dependencies that aren't reproducible, so  we're working with them to try to patch them.  We've patched as in.  They've accepted that commit.  We've also built some tools to let you build initial RAM disks in a reproducible way.  This works with Cubes, with Hedge, and we're hoping other Linux distributions pick it up  as well.  All of our tree is cryptographically signed, so hopefully GitHub's not trying to slip  in any patches.  It is open source, so we encourage everyone to read through it.  No NDA is required, unlike most of the UEFI sources.  It's the state of where things are.  It's pretty much in very beta, but it is usable.  There are a lot of areas where we can continue to do research, things like the embedded controllers  on Chromebooks are open source.  We can use those to help with our route of trust as well.  Porting core boot to more modern platforms would let us take advantage of things like  tamper switches and Intel boot guard.  I'm also working on porting core boot over to server platforms so that we can use it  for more secure cloud hosting.  Servers have a very different threat model from laptops, and a lot of things have firmware  that we have to be concerned about.  One collaboration I'm looking at there is with the OpenBMC project to be able to take  advantage of the open source in the management controller for the servers.  I'm also collaborating with the MassOpen cloud project that's trying to build secure  bare metal clouds.  I'm cautiously optimistic about enclaves and how they will help us with security, especially  in an environment where we control the firmware and we can ensure that the enclaves are set  up in a safe way.  There are a lot of issues on GitHub.  Again, please welcome contributions.  I hope everyone gets inspired to work on installing this on their laptop.  If you are interested, I'll be hanging out at the core boot assembly later today and  occasionally this week.  The core boot team has a bunch of people here.  They have flash programmers and can help you install core boot on your laptop.  This code for heads is available on GitHub.  A annotated version of this talk is up on my website.  Welcome comments and feedback on it.  Thank you all for coming to hear about this project.  I hope everyone is as excited about Open Source firmware as I am.  I'd love to take any questions that you all have.  Thanks for your great talk.  This is very interesting.  Do you have any advice for the 95% of us who are stuck on non-core boot compatible laptops?  Buy a Chromebook?  It's hard to trust the closed source firmware.  There are people we have to trust.  There are institutions we have to trust.  We have to trust Intel to some extent.  Intel is responsible for both our CPUs and a lot of the firmware.  The, depending on your threat model, firmware attacks may not be a huge concern for your  particular machine.  Or they might be grave concern.  In which case, even just doing some of the things that Peter suggested, clipping the  right protect pin on the chip, removing things that might be hostile and attacking your system.  His guide is a really good one to follow for the hardware security.  I was wondering if you also support ARM?  I just saw Intel laptops.  I was wondering.  So ARM has a lot of advantages as a CPU.  It only has 20 years of legacy baggage rather than 40.  And the boot process on it is much, much simpler since it doesn't have to go through real mode  to long mode to paging and all the other steps.  The downside to a lot of ARMs is that their boot code is on die and outside of the control  of the user.  Probably most of that boot code is fairly simple and can, and some of them will establish  a hardware root of trust.  But in general, the ARM to U-boot to whatever seems to work out pretty well.  I know there's been some interest in can U-boot be replaced with a Linux BIOS or core boot  like thing.  And I suspect the folks at the booth would be able to talk more about that.  And then just to follow up.  So if core boot or lipo boot supports the platform, it heads will work too, right?  Essentially, yes.  It heads is a payload for core boot.  It's there on the left.  Thank you.  I'm from the Internet about core boot.  Core boot has blobs included.  And for example, binary blobs from Intel with all the firmware support package and all  that stuff.  How can we call core boot secure then in the light of this?  Let alone open source.  So the Intel FSP is a significant concern.  This is the firmware support package that is required to initialize the memory controllers  on modern Intel CPUs.  On older CPUs, such as the Sandy Bridge and Ivy Bridge, the core boot and lipo boot are  able to initialize the memory natively without having to go into the FSP.  However, if you look at what core boot is doing in the MRC on those platforms, it tends  to just be poking a bunch of registers with values that seem to work.  And modern memory controllers are so complex that an Intel is unwilling to document them  without extensive NDAs.  That it's very hard to build any sort of memory initialization.  So while we can't say it's 100% free software, we can at least, we can ensure that the FNC  FSP is measured and it's unchanging.  We can also look at the state of things that it sets up and include those in our measurements.  So even if it doesn't give us 100% open source, as far as I know, the only system that does  that right now is Bunny's and Novena laptop.  At least we can measure it and we can know that it hasn't been tampered with from what  we initially installed.  Number four.  Hi, so this is a great project and I'd like to ask why you did certain architectural  decisions, the specific combination of Linux and Shell.  So why didn't you choose BSD kernel, which are usually perceived to be more secure and  of a higher quality?  Why did you choose the Shell over, let's say, Python or Haskell, which are also often perceived  of higher quality?  So there is a lot of desire to support Python in heads.  The downside is that there's very limited space.  The X230 boot ROM, for instance, has four megabytes of available space.  The Python interpreters a couple of megs already.  The, in terms of why Linux over BSD, the Kexex system call is a core component of this.  To be able to do a crease will shut down and transfer from the Linux kernel to another  kernel or to any multi-boot compliant kernels, which includes BSD, is a necessary feature.  If BSD had such functionality, it would be a fine choice for the internal boot ROM boot  litter.  Thanks for great work.  How to perform updates of Core Boot and its payload?  When its binary is used in measurement for releasing encryption key, then when you update  Core Boot, this measurement will change and you will no longer be able to boot the system.  How to solve that problem?  So migrated encryption keys with TPM requires a explicit step of retrieving the key from  the TPM with the current configuration and then resealing it with the new configuration.  One advantage of a reproducible build is the hashes of all the firmware stages can be  published, can be pre-computed, and then the PCR values can be pre-computed.  So you can seal the keys for the new values.  In terms of the update process for the heads payload, one of the things that we're working  on is being able to have a even more minimal heads that has just a USB device driver that  you can boot into, copy your new payload, and then install that elsewhere on the chip.  And part of that process would involve resealing any of the keys that you need to transfer.  Another question from the Internet.  Thank you.  On your web page, you implemented head on ThinkPads only.  How much work is still needed to translate this to, let's say, non-ThinkPads?  ThinkPads are really popular with the security community.  It's quite interesting to look out at the hall here and see how many ThinkPads there  are.  And as a result, the CoreBoot community has been very supportive of ThinkPads.  Other than the ThinkPads and the Chromebooks, there aren't a lot of devices that support  CoreBoot out of the box.  And that's something that I hope would change.  I hope that some OEMs would realize there is value in providing open source firmware  and move to using it, both as a cost saving measure as well as a freedom measure.  In terms of the difficulty importing CoreBoot to a platform, I haven't successfully done  that yet, but I suspect the people at the assembly would be happy to discuss that further.  What do you plan to rework and embed the control firmware on ThinkPads because it's a remaining  closed part which still has access to the PC bus and probably couldn't be trusted?  So your question is how do we replace the EC?  Yes, do you plan to replace EC with open source firmware in Chromebooks?  So the Chromebook has open source EC.  The part of building CoreBoot for Chromebook involves installing the ARM cross compiler  to build the EC firmware.  And the Chromebooks actually have a really elegant protocol for the EC to attest to the  CPU that it is running the firmware that you think it is running.  On other platforms, this would require a lot more research.  Many of the EC chipsets have data sheets available, so it's possible to read through  and see how they work.  And most of them have updatable firmware.  In the case of the ThinkPads, there's a module in the ThinkPad BIOS that will do that update.  We would need to figure out what that protocol looks like.  Sorry.  Yes, I mean, if you have working prototype on Syncpads, probably want to add a remaining  bit as open source EC on Syncpads as well.  The first place.  I'm sorry.  I don't think I understood your follow-up.  Okay.  So if you have working prototype on Syncpads and only on Syncpads, will you finish someone  soon, a current existing prototype of open source EC existing on H8, or are you planning  to extend your work on other platforms and finish these bits later?  Yeah.  Right now, I have not personally made any progress on the ThinkPad EC.  I was looking into it because I have a modified keyboard on my ThinkPad that needs an updated  EC firmware, but I haven't actually gotten into that.  That's an area of open research.  Thank you.  Two quick questions from the IRC.  Are you planning to use SystemD in the boot process?  Yes.  It's the first one.  And the second one.  I say you flash your firmware at the Congress right here with the help of a hardware programmer.  Can you update when there's a new version, or do you have to currently need the hardware  access to update?  Right now, you can update afterwards at great risk because you can leave the flash writable,  and then you can flash, which would allow you to flash after the fact.  We are still working on a good procedure for doing software-only firmware updates once  the boot, the immutable boot block is installed.  And to the other question, did I mention that we are really short on space and we don't  want to put any large applications like SystemD on there?  It was a good one.  Thanks.  Thank you all.
33c3-8314-bootstraping_a_slightly_more_secure_laptop_0_443.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_444_1223.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_1224_1511.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_1512_1643.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_1644_2327.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_2328_5303.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_5304_5843.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_5844_6191.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_6192_7211.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_7212_7727.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_7728_8807.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_8808_19319.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_19320_19643.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_19644_19691.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_19692_20111.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_20112_20411.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_20412_23099.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_23100_23939.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_23940_24059.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_24060_25259.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_25260_25391.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_25392_25511.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_25512_26447.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_26448_30479.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_30480_31295.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_31296_31403.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_31404_31907.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_31908_32015.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_32016_32183.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_32184_32591.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_32592_35855.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_35856_36035.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_36036_36671.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_36672_38927.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_38928_44687.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_44688_47603.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_47604_51575.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_51576_55319.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_55320_55715.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_55716_61067.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_61068_63443.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_63444_63503.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_63504_70667.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_70668_70799.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_70800_70847.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_70848_70967.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_70968_71255.png 33c3-8314-bootstraping_a_slightly_more_secure_laptop_71256_71567.png
So the last speaker for this morning is Traml. He's doing awesome research on Bootstrapping more secure laptops or servers. He's doing that basically by moving the root of trust into the right protected ROM. He's building an open-source custom firmware, so big ups for that, and also encouraging the research on this field, which I believe it's super interesting. Thanks. So I'm Traml Hudson with two-segment investments, and for the past several years, I've been researching firmware security vulnerabilities and looking at how they affect systems. Two years ago, I presented my work on Thunderstrike here at CCC. This was the first firmware attack against Macbooks that allowed an attacker to overwrite the motherboard Boot ROM. The year after that, I collaborated with Zeno Kova and Corey Kalenberg from Legbacore, both of whom are now at Apple doing firmware work, and we ported a bunch of Windows UE5 vulnerabilities over to the Mac and showed that the software platform, the UE5 software platform, allowed very portable attacks to be done. This also allowed a remote attacker with code execution on your machine to overwrite the motherboard Boot ROM. But more than just breaking things, what I really like to do is take things apart and understand how they work and document them, so that other people can build systems on top of them. That's what I'm really excited to be talking to you all about my project Heads, which is an open-source firmware and bootloader for laptops and servers. The name is a play on the popular Tails distribution, which is a stateless Linux for when you don't want to leave any traces of what you're doing on your machine. Heads is for the opposite case. It's where you want to be able to trust the machine and you want to be able to trust that the data you store on the machine is safe and unmodified. Let's back up for a quick minute and just talk about why firmware security is so important. That this is the code that is executed by the CPU when it comes out of reset. This is the first instruction that the CPU executes. So it's in a really privileged position to be able to circumvent any OS or other policies. There's no shortage of talks that you can watch on interesting attack vectors using firmware-based malware. One that I really liked was last year at Defcon, the Intel Advanced Threat Research presented an attack that showed how malicious firmware could circumvent the hypervisors. They then went further and showed how buggy firmware allowed a unprivileged guest inside a virtual machine to escalate into privileges inside the hypervisor. For that reason, it's really important that firmware vulnerabilities and firmware bugs have a way to get patched. These aren't just theoretical research vulnerabilities either. We know that there are malicious organizations and hacking groups that are selling firmware rootkits to whoever will pay, including nation-state adversaries that are using them for their persistent threats. They are very persistent because they are in the motherboard boot ROM. So you reinstall the OS, they're still there. You swap out the hard drive, they're still there. Some vendors are even bundling these rootkits into their official ROMs. They are using them to install the bloatware or whatever adware they want to put into the OS. So even after you reinstall a clean version of the OS, this particular vendors system would install its own additions. Some of those had vulnerabilities that could then be exploited by attackers. This particular case, the vendor received enough bad press that they released a firmware update that patched this vulnerability. They had to do that. This wasn't something that the users could do on their own. They couldn't update the software in their machine the way they do with their operating system or an application. In fact, most firmware vulnerabilities never see patches get deployed out to the end user. Part of the reason for that is that the firmware is usually four or five companies removed from the end user. There's the open-source reference implementation from Intel called Tiano Core or EDK2. When vulnerabilities are patched in there, they have to get pulled by the independent BIOS vendor and merged into the IPV tree. Then the BIOS vendor sells that to the device manufacturers. They have to package up or release the thing that gets pulled by the device manufacturer. It has to get QA to get motherboards they want to test it on. It has to get pulled by the original equipment manufacturer to get rebranded and whatever value they want to add. Sometimes it has to go through the operating system vendor to even make it out to the end user. As a result of this, most of the time products do not receive any updates after they've been sold. There's one exception. In this chart, you can see that Apple builds their own firmware. In my work with them, I've been pleased that they've rolled out patches for eight years of hardware, which is above and beyond what any other firmware vendor is doing right now. When EFI was introduced, it brought a lot of complexity. The Linux community was very skeptical as to what the value was going to be provided by all this complexity. It's basically an entire operating system's worth of code. It's not that the 16-bit real mode BIOS was all that much better. In fact, it had its own set of issues. But it was small. It was simple. It did one thing. It did it okay. It took a long time for UEFI to even become widely supported. Even now, most systems ship with both UEFI and a BIOS compatibility module. They've basically doubled their attack surface for potential bugs and vulnerabilities. The state of the firmware world today is that updates are rare. Patches, if they ever come out, take a long time to make it through the process. Users can't fix things on their own. We can't see what's inside since most of them are built with closed source components. That's not a great state for something that is as privileged as firmware. It's my belief that firmware needs to be built with open source. It must be flexible so we can adapt it to our needs for our systems. It needs to be built with software that we understand and we use for in other applications so it can get widely tested and well tested. It needs to be built in a reproducible manner so we can be secure against build chain attacks. It needs to be cryptographically measured so we can be sure that what we flash on the system is what is actually running on the system. That's the philosophy behind heads. It's built on the free software core boot firmware plus a Linux kernel and ROM that acts as a boot loader and then a lot of security research and tools that help us try to build slightly more secure systems. Using Linux as a boot loader is not a particularly new idea. Back in the 1990s when we started building large scale Linux clusters we were very frustrated with the inflexibility of DHCP and Pixie booting large machines. Even with those frustrations we built one that was about the 30th fastest in the world on the top 500. Meanwhile, my colleague Ron Minnick at Los Alamos was also building large clusters and had the observation that the BIOS enumerates all the buses, initializes a bunch of devices, finds Linux kernel and then the Linux kernel enumerates all the buses, initializes all the devices. He thought this is silly. Why are we doing this twice? He had the idea to build a version of Linux that ran in the ROM. He called this project Linux BIOS and it went on to power the MRC cluster which was the third fastest machine in the world in 2003. In 2008 Linux BIOS underwent a major refactoring and it was renamed to core boot. Google chose to use core boot as the firmware on their Chromebooks which are at this point the only non UEFI X86 based laptops that you can buy. They've done some great work in trying to lock down the configuration and the firmware on the Chromebooks. Ron moved to Google in 2011 and is continuing to work on the core boot project there. So core boot has three stages that it goes through as it starts up the machine. The first one is a very small amount of real mode assembly because your modern 64 bit laptop still boots up in real mode with 16 bit just like it's 1970s. So that's a very small amount of code, about 1.5K. That in turn sets up a C runtime environment with what's called cache's RAM mode and it calls into the ROM stage which is about 70K. Heads has moved the TPM initialization early in the ROM stage before DRAM is set up to help measure the boot block and provide a static root of trust that's hopefully a little bit more secure. Because that measurement is done early on, our trusted computing base is actually quite small. This is a fraction of 1% of the size of a UEFI firmware which is usually about 16 megs once it's uncompressed. The ROM stage then measures and executes the RAM stage which does the more traditional walk the bus, figure out what devices are on there, but it doesn't initialize them. It just enumerates them and generates the descriptors for Linux. It also installs the SMM handler for system management mode. It then measures and jumps into the payload and that whole process takes less than a second. So the is able to get into the payload and actually get to the user code very, very quickly. From something like the X230, it's able to go from power on to a interactive recovery shell in less than two seconds. And that includes bring up the TPM doing cryptographic measurements and assessing the state of the system. Because we now have Linux at this point, we have all the flexibility that comes with that. We can implement boot scripts as with the full power of the shell or the C language runtime. We're not stuck with the limited functions of UEFI. Linux supports lots of different file systems. It supports lots of different devices. It supports lots of different encryption methods. And this gives us the ability to use any of them for your specific application. In contrast, UEFI which supports unencrypted, fat file systems on the first drive that have to be in the first one gig or something. It's really, really limited as to how it can find its boot device. There's a saying in the open source community that with enough eyes, all bugs are shallow. And Linux has a lot more eyes looking at it. The device drivers and the file systems and the encryption have been reviewed by both White Hat and Black Hat people around the world. The UEFI versions of these do not have that same level of scrutiny. So using both the UEFI drivers and then having to run whatever on top of it increases the attack surface. But by putting Linux in the ROM and depending on its drivers, we've reduced our attack surface very dramatically. More importantly, core boot and Linux are open source. So it is possible to build custom versions for the device drivers that you need, for file systems that you need. It's possible to fix bugs when they come out and sign and install your own kernels. You don't have to wait for the vendor to get around to doing that. And the third major component of Heads is a tool called K-Exec, which is a system call that was added for the Linux BIOS project back in 2003 by Eric Biederman that allows a running kernel to do a graceful shutdown and start a new kernel without having to go through the reboot process. So this allowed, on their application, it allowed them to do very fast reboots of their cluster nodes. And in the Heads case, it allows us to act as a boot loader where we can find the real kernel that you want to run and exec it. Because Heads is quite small. It has to fit in four megabytes of ROM. So it's not something that you're going to run as a day-to-day OS. Hopefully this won't explode on me again. Because we have the born shell, most of the policies and the startup scripts in Heads are implemented as shell scripts. In this case, we're able to pass in a new set of command line parameters, a new initial RAM disk, and in this case, we can even start a hypervisor. And all of that can happen very, very quickly, as well as with a good degree of security. So those are the building blocks that Heads is built on, core boot, Linux, and tools like K-Exec. But it now gives us a really nice platform to begin experimenting with additional security features. And before we go too deep down the rabbit hole of security and threat models, I want to quote my friend Steph, who said that, your threat model is not my threat model. But your threat model is OK, as well. That we all have different things we want to protect from different attackers who are willing to spend different amounts of effort to go after them. And the nice thing about Heads and Open Source is we can build systems tailored to your individual threat model. So a lot of these things may not actually apply to your specific threats, but the fact that we can build them is a great capability. Last year, Johanna Rotowska reminded us that firmware is not just in our CPU. Firmware is in our Wi-Fi card. It is in our GPU. It is in our SSD. It is in our keyboards. And all of these devices might be trying to subvert the boot process. One way to handle that is to take Peter Stugus' advice of just assembling the machine and ripping out anything we can't control. If this is your threat model, his instructions are really worth following. They're really thorough about what pieces are potentially of concern. And you're going, right now, you will have to open up your laptop to install Heads. It's not quite as easy to install as most Linux distributions because we have to flash it into the motherboard boot ROM. While we're in there, we take advantage of some features that, to the best of my knowledge, no UEFI system is using. These flash chips have a hardware write protect mode where you can specify part of the chip is write only, excuse me, is read only, write once. And this gives us our immutable boot block in which to store the trusted computing base, the TCB, so that we can measure the rest of the system. We also then suggest disconnecting the write protect pin from the motherboard, which protects against certain classes of attacks like the Intel closed chassis adapter that allows external JTAG of the CPU. Depending on your threat model, you might want to cover that chip in epoxy as well to frustrate evil made attacks that want to do physical programming on it. Disconnecting the write protect pin also serves to protect from other devices on the machine that have access to those pins. This is like the management engine, which is a really scary CPU inside the CPU. Rudolph Merrick two years ago at CCC called it the Matroyshka CPU. And Igor Skraczinski detailed what are the capabilities of the management engine. And they're really worrisome that it runs a opaque obfuscated blob of code, about five megabytes, that the CPU can't see. The management engine can read and write all of main memory. It can read from the keyboard and video. It can receive Java byte codes over the network and execute them on behalf of someone outside the machine. And it's listening on the network even when the system is powered off. So this is basically a root kit inside the chip set, as some folks have called it. So that concerned me a lot. And I spent some time looking at how its firmware images are built and realized that we can build modified reduced functionality firmware for it that removes all of the root kit functions and just leaves the CPU bring up module. This takes that five megabytes and shrinks it down to about 40K of space. So we don't know exactly what it's doing in that 40K, but we at least know it doesn't have a device driver or a Java virtual machine or a lot of the other functions. And we've successfully done this on both Sandy Bridge and Ivy Bridge, like the X230 ThinkPads, as well as modern Skylake CPUs, like the Chel Chromebook. And that's really encouraging that if we can apply this to more modern hardware, that allows us to move away from our five-year-old ThinkPads to something a little shinier. So the management engine isn't the only device that might be trying to separate the boot process. Again, Johanna showed us there are lots of things to be worried about. Intel's UEFI architects, Yao and Zimmer, recommend that firmware turn on the IOMMU, called VTD, to protect against road devices. To the best of my knowledge, since they've written this guide, no UEFI firmware is taken advantage of the IOMMU. So it's a great piece of hardware to have, but it doesn't help if you don't turn it on. Linux, meanwhile, has no problem taking advantage of it. So we use it, essentially, we get that DMA protection for free by using Linux as our boot loader in the ROM. Another way road devices can try to interfere with the boot process is by providing option ROMs, which are executable code to be run by the BIOS that have sort of a device driver. And this code can do things like log keystrokes and then try to exfiltrate passwords, as we see here. That problem was initially reported in 2007 by John Heisman at Black Hat, again by Snare in 2012, and then again by my work on Thunderstrike. And as of last week, a official fix has finally rolled out for it to close that particular vulnerability. Folks who are using Coreboot have this as an option that they can say, I am concerned about this threat. Let me fix this. Let me disable this function. And they point out that it might cause degraded functionality, but that's something you can QA on your own system. And in practice, with Linux as your boot loader in the ROM, you don't use the option ROMs for anything. Everything is done with Linux's own device drivers. So you're not dependent on the whatever limited functionality the option ROM provided. So now that we have taken our building blocks and we hopefully have protected the boot process and hopefully the code that's running is what we think it is, we need to turn to how do we secure the secrets on the machine. And I'm a huge fan of the TPM, the Trusted Platform Module. And I know in the free software community, it's been largely unwelcome. It has not received a very welcome reception. Because of the way it's been used for DRM and other user hostile things. Since we control the TPM from the first instruction in the boot block, we're able to use it in ways that we want to. So we don't have to enable DRM, but we can use it to protect our secrets. And the way that it does that is it keeps track of what code is executed as the system boots. And it hashes that code into special registers called PCRs. And the idea is that you can extend the PCR by hashing the next module of code and then hashing that with the previous hash. And this creates a chain of trust that allows us to say if these hashes match the expected values, only the code that we want to have run has run. And then the TPM will only decrypt the disk encryption key if those PCRs match, which means that the code that we want to have run is what has been executed. This means if someone manages to overwrite the non-right protected part of the ROM, that will change those measurements and the TPM won't reveal the key to them. It also takes a user password, and that password is validated by the TPM hardware itself, which gives us hardware rate limiting on how often an attacker can try. It also gives us the ability to do hardware-based retry limits so that the TPM will flush the key if an attacker in possession of your machine tries too long. That does mean there's now another way to lose your disk encryption key. And there's the old joke about there are two types of people with encrypted drives, those who have lost data due to forgetting their key and those who will. So what Heads does when you generate your key is it takes that key and splits it into multiple pieces that you can then share either to friends or to backup services, where each piece doesn't let you decrypt it, but you can combine them with Shamiro secret sharing to regenerate the cryptographic disk encryption key. We're also able to take advantage of best practices, like including the disk encryption key headers in the PCRs that we use to seal the disks. This avoids a certain class of evil mate attack where someone swaps out your drive, may not be in your threat model, but it's easy to do with just a few lines of shell script. So hopefully we now trust that the system is running the code we think it is, but how does it prove to us that it is actually our machine, that someone hasn't snuck into our hotel room and swapped out everything and carefully replaced our stickers to make us believe we're typing our password into our own computer. Some anti-evil made toolkits will encrypt a secret phrase and then display it to you if and only if the PCRs match, but that's subject to a replay attack. What Matthew Garrett demonstrated last year at 32C3 was using the time-based one-time password used by Google Authenticator to protect the firmware and have it attest to the user that it is unmodified. So when the system boots and goes through measuring all of the various components, the TPM will only release the secret if those PCRs match. The firmware then hashes that along with the current time and generates a six-digit value that it prints on the screen. You compare that to what's on your phone and that tells you whether or not you can trust the machine. It's a great idea and it's implemented again as a very small shell script to read the value from the TPM, unseal it, and then compute the hash of it. This also allows us to start making a transition from the TPM static root of trust to a PGP base trust where most importantly, this is a TPM key, excuse me, this is a PGP key that you, the owner of the computer control, not some random vendor or some random hardware device manufacturer that's going to lose the key and allow malware like Stuxnet to use it to circumvent security. The boot script in heads, again, it's a small shell script, is able to use GPG to verify the next stages of the hypervisor at the initial RAM disk and the kernel. And it's also then uses the TPM's counters to help prevent against rollback where someone takes your drive and rolls it back to a previous version, perhaps with a vulnerability that they can exploit. So this allows us to be sure that not only are we running the firmware, excuse me, the OS that we think we should be running, it ensures us that someone hasn't been able to substitute one that, a vulnerable version. Even the PGP key also allows us to take advantage of an idea from Android and Chrome OS, which is the DM Verity read-only root file system. This hashes all of the blocks and then hashes all of the hashes and so on up until it gets to a root hash in the tree that is then signed. This allows the kernel on every read access in logarithmic time to verify essentially a signature on that data. This does require a read-only root file system, but it gives us even more confidence that the system has been untampered with. Once you're running your OS, it's good to have some security-conscious thoughts as well. This is mostly focused on how do we securely transition to an OS, and that's OS you run is up to you. I like Cubes. It's reasonably secure. It's highly recommended by people who know about endpoint security. And the Cubes team recognizes that firmware security is a vital piece of system security. For their next release, Cubes R4, they're going to require the machines have open source firmware such as Corbude, and I hope that Hedge is going to be a piece of that. I've also been working with the Cubes software and have modified it to work with things like the DMVarity read-only root file system. This now allows the user to lock down the configuration so that someone can't tamper with their setup. It also gives you a recovery mode that allows you to fix things up and re-sign the OS. Reproducible builds are really important so that everyone can verify that the builds match what they should. In the case of Hedge, we have a lot of upstream dependencies that aren't reproducible, so we're working with them to try to patch them. We've patched as in. They've accepted that commit. We've also built some tools to let you build initial RAM disks in a reproducible way. This works with Cubes, with Hedge, and we're hoping other Linux distributions pick it up as well. All of our tree is cryptographically signed, so hopefully GitHub's not trying to slip in any patches. It is open source, so we encourage everyone to read through it. No NDA is required, unlike most of the UEFI sources. It's the state of where things are. It's pretty much in very beta, but it is usable. There are a lot of areas where we can continue to do research, things like the embedded controllers on Chromebooks are open source. We can use those to help with our route of trust as well. Porting core boot to more modern platforms would let us take advantage of things like tamper switches and Intel boot guard. I'm also working on porting core boot over to server platforms so that we can use it for more secure cloud hosting. Servers have a very different threat model from laptops, and a lot of things have firmware that we have to be concerned about. One collaboration I'm looking at there is with the OpenBMC project to be able to take advantage of the open source in the management controller for the servers. I'm also collaborating with the MassOpen cloud project that's trying to build secure bare metal clouds. I'm cautiously optimistic about enclaves and how they will help us with security, especially in an environment where we control the firmware and we can ensure that the enclaves are set up in a safe way. There are a lot of issues on GitHub. Again, please welcome contributions. I hope everyone gets inspired to work on installing this on their laptop. If you are interested, I'll be hanging out at the core boot assembly later today and occasionally this week. The core boot team has a bunch of people here. They have flash programmers and can help you install core boot on your laptop. This code for heads is available on GitHub. A annotated version of this talk is up on my website. Welcome comments and feedback on it. Thank you all for coming to hear about this project. I hope everyone is as excited about Open Source firmware as I am. I'd love to take any questions that you all have. Thanks for your great talk. This is very interesting. Do you have any advice for the 95% of us who are stuck on non-core boot compatible laptops? Buy a Chromebook? It's hard to trust the closed source firmware. There are people we have to trust. There are institutions we have to trust. We have to trust Intel to some extent. Intel is responsible for both our CPUs and a lot of the firmware. The, depending on your threat model, firmware attacks may not be a huge concern for your particular machine. Or they might be grave concern. In which case, even just doing some of the things that Peter suggested, clipping the right protect pin on the chip, removing things that might be hostile and attacking your system. His guide is a really good one to follow for the hardware security. I was wondering if you also support ARM? I just saw Intel laptops. I was wondering. So ARM has a lot of advantages as a CPU. It only has 20 years of legacy baggage rather than 40. And the boot process on it is much, much simpler since it doesn't have to go through real mode to long mode to paging and all the other steps. The downside to a lot of ARMs is that their boot code is on die and outside of the control of the user. Probably most of that boot code is fairly simple and can, and some of them will establish a hardware root of trust. But in general, the ARM to U-boot to whatever seems to work out pretty well. I know there's been some interest in can U-boot be replaced with a Linux BIOS or core boot like thing. And I suspect the folks at the booth would be able to talk more about that. And then just to follow up. So if core boot or lipo boot supports the platform, it heads will work too, right? Essentially, yes. It heads is a payload for core boot. It's there on the left. Thank you. I'm from the Internet about core boot. Core boot has blobs included. And for example, binary blobs from Intel with all the firmware support package and all that stuff. How can we call core boot secure then in the light of this? Let alone open source. So the Intel FSP is a significant concern. This is the firmware support package that is required to initialize the memory controllers on modern Intel CPUs. On older CPUs, such as the Sandy Bridge and Ivy Bridge, the core boot and lipo boot are able to initialize the memory natively without having to go into the FSP. However, if you look at what core boot is doing in the MRC on those platforms, it tends to just be poking a bunch of registers with values that seem to work. And modern memory controllers are so complex that an Intel is unwilling to document them without extensive NDAs. That it's very hard to build any sort of memory initialization. So while we can't say it's 100% free software, we can at least, we can ensure that the FNC FSP is measured and it's unchanging. We can also look at the state of things that it sets up and include those in our measurements. So even if it doesn't give us 100% open source, as far as I know, the only system that does that right now is Bunny's and Novena laptop. At least we can measure it and we can know that it hasn't been tampered with from what we initially installed. Number four. Hi, so this is a great project and I'd like to ask why you did certain architectural decisions, the specific combination of Linux and Shell. So why didn't you choose BSD kernel, which are usually perceived to be more secure and of a higher quality? Why did you choose the Shell over, let's say, Python or Haskell, which are also often perceived of higher quality? So there is a lot of desire to support Python in heads. The downside is that there's very limited space. The X230 boot ROM, for instance, has four megabytes of available space. The Python interpreters a couple of megs already. The, in terms of why Linux over BSD, the Kexex system call is a core component of this. To be able to do a crease will shut down and transfer from the Linux kernel to another kernel or to any multi-boot compliant kernels, which includes BSD, is a necessary feature. If BSD had such functionality, it would be a fine choice for the internal boot ROM boot litter. Thanks for great work. How to perform updates of Core Boot and its payload? When its binary is used in measurement for releasing encryption key, then when you update Core Boot, this measurement will change and you will no longer be able to boot the system. How to solve that problem? So migrated encryption keys with TPM requires a explicit step of retrieving the key from the TPM with the current configuration and then resealing it with the new configuration. One advantage of a reproducible build is the hashes of all the firmware stages can be published, can be pre-computed, and then the PCR values can be pre-computed. So you can seal the keys for the new values. In terms of the update process for the heads payload, one of the things that we're working on is being able to have a even more minimal heads that has just a USB device driver that you can boot into, copy your new payload, and then install that elsewhere on the chip. And part of that process would involve resealing any of the keys that you need to transfer. Another question from the Internet. Thank you. On your web page, you implemented head on ThinkPads only. How much work is still needed to translate this to, let's say, non-ThinkPads? ThinkPads are really popular with the security community. It's quite interesting to look out at the hall here and see how many ThinkPads there are. And as a result, the CoreBoot community has been very supportive of ThinkPads. Other than the ThinkPads and the Chromebooks, there aren't a lot of devices that support CoreBoot out of the box. And that's something that I hope would change. I hope that some OEMs would realize there is value in providing open source firmware and move to using it, both as a cost saving measure as well as a freedom measure. In terms of the difficulty importing CoreBoot to a platform, I haven't successfully done that yet, but I suspect the people at the assembly would be happy to discuss that further. What do you plan to rework and embed the control firmware on ThinkPads because it's a remaining closed part which still has access to the PC bus and probably couldn't be trusted? So your question is how do we replace the EC? Yes, do you plan to replace EC with open source firmware in Chromebooks? So the Chromebook has open source EC. The part of building CoreBoot for Chromebook involves installing the ARM cross compiler to build the EC firmware. And the Chromebooks actually have a really elegant protocol for the EC to attest to the CPU that it is running the firmware that you think it is running. On other platforms, this would require a lot more research. Many of the EC chipsets have data sheets available, so it's possible to read through and see how they work. And most of them have updatable firmware. In the case of the ThinkPads, there's a module in the ThinkPad BIOS that will do that update. We would need to figure out what that protocol looks like. Sorry. Yes, I mean, if you have working prototype on Syncpads, probably want to add a remaining bit as open source EC on Syncpads as well. The first place. I'm sorry. I don't think I understood your follow-up. Okay. So if you have working prototype on Syncpads and only on Syncpads, will you finish someone soon, a current existing prototype of open source EC existing on H8, or are you planning to extend your work on other platforms and finish these bits later? Yeah. Right now, I have not personally made any progress on the ThinkPad EC. I was looking into it because I have a modified keyboard on my ThinkPad that needs an updated EC firmware, but I haven't actually gotten into that. That's an area of open research. Thank you. Two quick questions from the IRC. Are you planning to use SystemD in the boot process? Yes. It's the first one. And the second one. I say you flash your firmware at the Congress right here with the help of a hardware programmer. Can you update when there's a new version, or do you have to currently need the hardware access to update? Right now, you can update afterwards at great risk because you can leave the flash writable, and then you can flash, which would allow you to flash after the fact. We are still working on a good procedure for doing software-only firmware updates once the boot, the immutable boot block is installed. And to the other question, did I mention that we are really short on space and we don't want to put any large applications like SystemD on there? It was a good one. Thanks. Thank you all.
for the past several years, I've been researching Heads, which is an open-source firmware and bootloader for laptops and servers. The name is a machine. Heads is for the opposite case. It's where you want to be able to trust the machine and you want to be able to trust that the data build chain attacks. It needs to be running on the system. That's the philosophy the rabbit hole of security and threat models, I pin from the motherboard, which protects against physical programming on it. Disconnecting the of the computer control, not some random vendor to take advantage of the open source in the of the keys that you need to transfer. Another