*33c3 preroll music*
Herald: So, the last speaker for this morning is Trammell. He is doing
awesome research on "Bootstrapping more secure laptops or servers" and
he is doing that basically by moving the root of trust into the write-protected room.
He is 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! *applause*
Trammel Hudson: So I'm Trammell Hudson with Two Sigma Investments, and for the
past several years I've been researching firmware security vulnerabilities
and looked at how they affect systems. Two years ago, I presented my work
on Thunderstrike here at CCC. And this was the first firmware attack against MacBooks
that allowed an attacker to override the motherboard bootrom.
The year after that, I collaborated with Xeno Kovah and Corey Kallenberg
from LegbaCore - both of whom are now at Apple, doing firmware work.
And we ported a bunch of Windows UEFI vulnerabilities over to the Mac, and
showed that the software platform - the UEFI software platform, you know - allowed
very portable attacks to be done. This also allowed a remote attacker with code
execution on your machine to override the motherboard bootrom. But, more than just
breaking things, what we like to do is take the things apart and understand how
they work and document them, so that other people can build systems on top of them.
And that's why I'm really excited to be talking to you all about my project
"Heads", which is a open source firmware and boot loader
for laptops and servers. The name is kind of 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. And, 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. And so it's in a really privileged position to be able to
circumvent any sort of OS or other policies. And 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 firmware could - 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. And 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. And they are very persistent,
because they are in the motherboard bootrom So you've reinstalled the OS -
they're still there, you swap out the hard drive - they're still there. And some
vendors are even bundling these rootkits into their official ROMs. That 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. And they had to do that. This wasn't something that the users could
do on their own - they couldn't update the the firmware in their machine the
way they do with their operating system or an application. And in fact, most firmware
vulnerabilities never see patches get deployed out to the end-user.
Part of the reason for that is that the the firmware is usually four or five
companies, removed from the end-user. That there's the open source reference
implementation from Intel, called eh TianoCore or EDK II. When vulnerabilities
are patched in there, they have to get pulled by the independent BIOS vendor, and
merged into the IBV tree, and then the BIOS vendor sells that to the device
manufacturers. So they have to package up a release the thing gets pulled by the
device manufacturer. It has to get QA'd it against however many motherboards they
want to test it on. And then it has to get again pulled by the original equipment
manufacturer to get rebranded and whatever value they want to add. And then sometimes
it has to go through the operating system vendor to even make it out to the end-
user. And 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, and in my work with them, I've been really 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, and 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 systems worth of code. And 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. And it took a long time for
UEFI to even become widely supported. But even now most systems ship with both the
UEFI and a BIOS compatibility module. So they've basically doubled their attack
surface for potential bugs and vulnerabilities. So 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, and we can't see what's inside, since most of
them are built with closed source components - and that's not a great state
for something that is as privileged as a firmware. So 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 that it can get widely tested and well
tested. It needs to be built in a reproducible manner, so that we can be
secure against that build chain attacks. And it needs to be cryptographically
measured, so that we can be sure that this, what we flash on the system, is what
is actually running on the system. And that's the philosophy behind Heads - it's
built on the free software coreboot firmware, plus a Linux kernel in ROM, that
acts as a bootloader, and then a lot of security research and tools, that help us
try to build slightly more secure systems. Using Linux as a bootloader 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 PXE booting
large machines, that even with those frustrations, we built one, that was about
the 30th fastest in the world on the top 500. Meanwhile, my colleague Ron Minich 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 the Linux kernel
and in the Linux kernel, enumerates all the buses, initializes all the devices,
and he thought: "This is this is silly, why are we doing this twice?".
So 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 "Coreboot". And Google chose to use
Coreboot as the firmware on their Chromebooks - which are at this point the
only non-UEFI x86-based laptops that you can buy. And they've done some really some
great work in trying to lock down the configuration and the firmware on the
Chromebooks. Ron, who has only moved to Google in 2011 and is continuing to work
on the Coreboot project there. So Coreboot 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 its 1970's. 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-as-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 route of trust that's hopefully a little bit more
secure. And 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 MB once it's uncompressed.
The ROM stage then measures and executes the RAM stage, which does the more
traditional "walk the bus, find / 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 it is able to get into the payload and actually get to the
user code very, very quickly. On something like the X230 it's able to go from power
on to a interactive recovery shell in less than 2 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 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 1 GiB or something, it's really, really limited as
to how it can find its boot device. There's a saying in the in the Open Source
community that with enough eyes all bugs are shallow.
And Linux has a lot more eyes looking at it. That 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 we're 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 though, Coreboot and Linux are Open Source, so it is possible to build
custom versions for the device drivers that you need, for the 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 it.
And the third major component of heads is a tool called "kexec", which is a system
call that was added for the Linux BIOS project back in 2003 by Eric Peterman,
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 bootloader 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 4 MB of ROM. So it's not something that you learn to run as a day-to-day sort
of OS. Hopefully this won't explode on me again.
Because we have the Bourne Shell, most of the policies and the startup scripts in
"Heads" are implemented as as shell scripts. In this case we were 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 with a good degree of security. So, those are the building blocks that
"Heads" is built on: Coreboot, Linux and tools like "kexec". 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, you know, security and
threat models, I want to quote my friend Steph, who said that, "Your threat model
is not my threat model." But you know your threat model is okay 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 having an 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 Joanna Rutkowska 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 Stuge's advice of disassembling 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'll have to open up
your laptop to install "Heads." It's not quite as easy as it is to install most
Linux distributions, because we have to flash it into the motherboard boot ROM.
While we're in there, now, 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
close 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 Maid attacks that want to do a 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. Devices like the Management Engine,
which is a really scary CPU inside the CPU. Rudolf Marek two years ago at CCC
called it the "Matroyshka CPU". And Igor Skochinsky detailed what are the
capabilities of the management engine. And they're really worrisome, that it runs a
opaque obfuscated blob of code about 5 MiB 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 bytecodes 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 rootkit inside the
chipset, 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 rootkit
functions, and just leaves the "CPU bring up" module. This takes that 5 MiB and
shrinks it down to about about 40 KiB of space. So we don't know exactly what it's
doing in that 40 KiB, 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 Chell Chromebook. And that's
really encouraging, that if we can apply this to more modern hardware, that allows
us to, you know, move away from our five- year-old ThinkPads to something a little
shinier. The management engine isn't the only device that might be trying subvert
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, now called VTD, to protect against rogue devices. To the best of my
knowledge, since they've written this guide, no UEFI firmware is taking
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, what we get essentially - we get that DMA protection
for free by using Linux as our bootloader in the ROM. Another way devices, rogue
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 a sort of a device driver.
And this code can do things like about log keystrokes and then try to exfiltrate
passwords as we see here. That problem was initially reported in 2007 by John Heasman
at BlackHat, again by Snare in 2012, and 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
a option that they can say, this, I am concerned about this threat, let me 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 bootloader in the ROM, you don't use the
option ROMs for anything. Everything is done with 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 we've 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, now 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 other user-hostile things. Since we control the TPM from the first
instruction in the 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
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
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 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, the non-write
protected part of the ROM, that would 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 they 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 the old joke about there
are two types of people with encrypted drives - those who have lost data due to
forgetting their key, and 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 Shamir secret sharing to
regenerate the cryptographic disk encryption key.
We're also able to take advantage of best practices like using the, including the
disk encryption key headers in the PCRs that we use to seal the disks. This avoids
a certain class of Evil Maid attack, where someone swaps out your drive; may not be
in your threat model, but it is easy to deal with just a few lines of shell
script. So we 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 left, left up, carefully
replaced our stickers to make us believe we're typing our password into to our own
computer. Some anti-Evil Maid toolkits will encrypt a secret, secret phrase, and
then display it to you if and only if the PCR is match, but that's subject to a
replay attack. What Matthew Garrett demonstrated last year at 32C3, was, using
the time, a 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 it goes through measuring all of the various components
the, 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, it's a great idea, and it's
implemented again as a very small shell script to read, read the value from the
TPM, unseal it and then compute the the hash of it.
This also allows us to start making a transition from the TPM-rooted, a TPM
static route of trust to a PGP-based 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 a GPG to verify the next stages of the, the
hypervisor, the initial RAM disk and the kernel. And it also then uses the 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, this allows the, allows us to be
sure, that not only are we running the firmware, 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. Having the PGP key also allows us to take
advantage of an idea from Android and Chrome OS which is the the dm-verity read-
only root filesystem - this hashes all of the blocks and that hashes all of the 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 the
essentially a signature on that data. This does require a read-only root filesystem,
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 you know some security conscious thoughts
as well, you know. Heads is mostly focused on, "how do we securely transition to an
OS" and that OS you run is up to you. I like Qubes - it's reasonably secure, it's
highly recommended by people who know about endpoint security. And the Qubes
team recognizes that firmware security is a vital piece of system security. For
their next release, Qubes are for - they're going to require the machines have
open source firmware, such as coreboot. And I hope that Heads is going to be a
piece of that. I've also been working with with the Qubes software and have modified
it to work with things like the dm-verity read-only root filesystem. This now allows
the user to lock down the configuration, so that someone can't tamper with their
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 what that the builds match what they should. In the case of of Heads 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 Xen - 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 Qubes, with Heads, and we're hoping to other Linux distributions
pick it up as well. All of our tree is cryptographically
signed, so hopefully GitHub is not trying to slip in any patches. And it is open
source so we encourage anyone to read through it. No NDA is required, unlike most
of the UEFI sources. So that's sort of the state of where things are - it's pretty
much in very beta, but it is usable. But there are a lot of areas where we could
continue to do research - things like the embedded controllers on Chromebooks are
open source. We can use those to help with our root of trust as well. Porting
coreboot to more modern platforms would let us take advantage of things like
tamper switches and Intel Boot Guard. I'm also working on porting coreboot over to
server platforms so that we can use it for more secure cloud hosting. Servers have a
very different threat model from 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 open BMC project to be able to take advantage of the open source in the
management controller for the servers. And I'm also collaborating with the Mass Open
Cloud project that's trying to build secure bare metal clouds. I'm cautiously
optimistic about enclaves and how they will help us with the security, especially
in a 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 to work on the
installing this on their laptop. And if if you are interested I'll be hanging out at
the coreboot assembly later today and occasionally this week. The coreboot team
has a bunch of people here. They have flash programmers and can help you install
coreboot on your laptop. The source code for Heads is available on GitHub, and a
annotated version of this talk is up on my website, and welcome comments and feedback
on it. So thank you all for coming to hear about this project I hope that everyone is
and you know as excited about open source firmware as I am and I'd love to take any
questions that you all have.
*Applause*
Question: Thanks for your great talk - this is very interesting. Do you have any
advice for the 95% of us who are stuck on non coreboot compatible laptops.
Trammell: Buy a Chromebook? *Laughter*
Trammell: It's hard to trust the closed- source firmware. It certainly; there are
people we have to trust - there are institutions we have to trust. We have to
trust Intel to some extent, and Intel is responsible for, you know, both our CPUs
and a lot of the firmware. Depending on your threat model, firmware attacks may
not be a huge concern for your particular machine. Or they might be, you know, of
grave concern, in which case even just doing some of the things that Peter Stuge
suggested of clipping the write-protect pin on the on the chip, removing things
that might be hostile and attacking your system. His guides are really good one to
follow for the hardware security. Question: I was wondering if you also
support ARM - I just saw Intel laptops so I was just wondering.
Trammell: So ARM it 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 they their boot code is a few is
on die and outside of the control of the user. Luckily, most of that boot code is
fairly simple, and can establish - and some of them will establish a hardware
root of trust. But in general, yeah that 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 coreboot like thing", and I suspect the folks at the booth would
be able to talk more about that. Question: And then just a followup - so if
coreboot or Libreboot supports the platform - Heads will work too right?
Trammell: Essentially yes, yeah. Heads is a payload for coreboot.
Question: OK. Herald: It's there on the left.
Signal Angel: Thank you - there's a question from the Internet about coreboot.
Coreboot has blobs included and, for example, binary blobs from Intel with all
the firmware support package and all that stuff. How can we call coreboot secure,
then, in the light of this - let alone open source?
Trammell: So the intel FSP is a significant concern. This is the firmware
support package that is required to initialize the memory controllers on on
modern Intel cpus. On older CPUs, such as the the Sandy Bridge and Ivy Bridge, the
coreboot and Libreboot are able to initialize the memory natively without
having to go into the FSB. However, if you look at what coreboot 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 it's modern memory controllers are so complex that, and Intel
is unwilling to document them, that without extensive NDA's that it's very
hard to build any sort of memory initialization. So what we can't say it's
a hundred percent free software, we can at least we can ensure that the 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 get us one hundred
percent open source - and as far as I know the only system that does that right now
is bunnies' Novena laptop. At least we can measure it and we can know that it hasn't
been tampered with from what we initially installed.
Question: And before 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 a BSD kernel which are usually perceived to be more secure
and of a higher quality, and why did you choose a shell over let's say, Python
or Haskell, which are also often perceived of higher quality?
Trammell: There is a lot of desire to support Python in Heads. The downside is
that there's a very limited space: the X230 bootrom, for instance, has 4
megabytes of available space. The Python interpreter is a couple megs already. In
terms of why Linux over BSD - the kexec system call is a core component of this:
to be able to do a graceful shut down and transfer from the Linux kernel to another
kernel or - to any multi-boot compliant kernels, which includes BSD. It is a
necessary feature if it, if BSD had such functionality, that it would be a fine
just a choice for the the internal boot ROM/boot loader.
Question: Thanks for great work. How to perform updates of coreboot and its
payload when it's binaries used in measurement for releasing encryption key
then when you update coreboot this measurement will change and you will know
no longer will be able to boot the system - how to solve that problem?
Trammell: So migrating 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 the of all the firmware stages can be published - it can be pre-computed,
and then the PCR values can be pre- computed so you can read 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 an 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.
Herald: Another question from the Internet.
Signal Angel: Thank you. On your webpage you implemented Heads on ThinkPads only.
How much work is still needed to translate this to, let's say, non-ThinkPads?
Trammell: ThinkPads are really popular with the security community. It's quite
interesting to look out at you know the hall here and see how many ThinkPads there
are. And as a result the coreboot community has been very supportive of
ThinkPads. There's, 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's
value in provide an open source firmware and move to move to using it. Both as a
cost-saving measure as well as a freedom measure. In terms of the difficulty
important 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.
Question: Would you plan to rework embedded controller firmware on ThinkPads
because it's remain close at birth which still has an access to PC bus and probably
couldn't be trusted. Trammell: So your question is how do we
how do we replace the EC? Question: Yes do plan to replace EC with
open source firmware as in the Chromebooks?
Trammell: 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 is running the firmware that you think it is running. On other
platforms, this would require a lot more research. The doc; 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 case of the ThinkPads,
there's a module in the ThinkPad BIOS that will do that update. There's, we would
need to figure out what that protocol looks like.
Question: Sorry yes I mean if you have working prototype on ThinkPads probably
want to add remaining business open sources EC on ThinkPads as well in the
first place. Trammell: I'm sorry, I don't think I
understood your follow-up. Question: Okay. So if you if you have a
working prototype on ThinkPads and only on ThinkPads, will you finish somewhat soon
current existing prototype of open source EC exists in college shade by Lincoln's or
you are playing to extend your work on other platforms and finish this bits
later. Trammell: 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 that needs to updated EC firmware,
but I haven't actually gotten into that. This is a area of open research
Signal Angel: Thank you, two quick questions from the IRC - are you planning
to use systemd in the boot process is the first one
*Laughter* Signal Angel: And the second one let's 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? Trammell: Right now you can update
afterwards at great risk, because you can leave the flash writeable, 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 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.
Questioner: It was like good one, thanks.
*applause*
*postroll music*
*subtitles created by c3subtitles.de in the year 2018*