Return to Video

Bootstraping a slightly more secure laptop (33c3)

  • 0:00 - 0:13
    33c3 preroll music
  • 0:13 - 0:17
    Herald: So, the last speaker for this
    morning is Trammell. He is doing
  • 0:17 - 0:22
    awesome research on "Bootstrapping
    more secure laptops or servers" and
  • 0:22 - 0:27
    he is doing that basically by moving the
    root of trust into the write-protected room.
  • 0:27 - 0:33
    He is building an open-source custom
    firmware, so big ups for that, and also
  • 0:33 - 0:37
    encouraging the research on this field
    which I believe it's super interesting.
  • 0:37 - 0:42
    Thanks!
    applause
  • 0:42 - 0:47
    applause
  • 0:47 - 0:50
    Trammel Hudson: So I'm Trammell Hudson
    with Two Sigma Investments, and for the
  • 0:50 - 0:54
    past several years I've been researching
    firmware security vulnerabilities
  • 0:54 - 0:59
    and looked at how they affect systems.
    Two years ago, I presented my work
  • 0:59 - 1:05
    on Thunderstrike here at CCC. And this was
    the first firmware attack against MacBooks
  • 1:05 - 1:09
    that allowed an attacker to override
    the motherboard bootrom.
  • 1:09 - 1:14
    The year after that, I collaborated with
    Xeno Kovah and Corey Kallenberg
  • 1:14 - 1:19
    from LegbaCore - both of whom
    are now at Apple, doing firmware work.
  • 1:19 - 1:25
    And we ported a bunch of Windows UEFI
    vulnerabilities over to the Mac, and
  • 1:25 - 1:30
    showed that the software platform - the
    UEFI software platform, you know - allowed
  • 1:30 - 1:36
    very portable attacks to be done. This
    also allowed a remote attacker with code
  • 1:36 - 1:42
    execution on your machine to override the
    motherboard bootrom. But, more than just
  • 1:42 - 1:47
    breaking things, what we like to do is
    take the things apart and understand how
  • 1:47 - 1:51
    they work and document them, so that other
    people can build systems on top of them.
  • 1:51 - 1:55
    And that's why I'm really excited to be
    talking to you all about my project
  • 1:55 - 2:01
    "Heads", which is a open source
    firmware and boot loader
  • 2:01 - 2:06
    for laptops and servers.
    The name is kind of a play
  • 2:06 - 2:11
    on the popular 'Tails' distribution
    which is a stateless Linux
  • 2:11 - 2:15
    for when you don't want to leave any traces
    of what you're doing on your machine.
  • 2:15 - 2:19
    Heads is for the opposite case: it's where
    you want to be able to trust the machine,
  • 2:19 - 2:24
    and you want to be able to trust that the
    data you store on the machine is safe
  • 2:24 - 2:29
    and unmodified. And, let's back up
    for a quick minute and just talk about
  • 2:29 - 2:34
    why firmware security is so important,
    that this is the code that is
  • 2:34 - 2:39
    executed by the CPU when it comes out of
    reset. This is the first instruction that
  • 2:39 - 2:44
    the CPU executes. And so it's in a really
    privileged position to be able to
  • 2:44 - 2:51
    circumvent any sort of OS or other
    policies. And there's no shortage of talks
  • 2:51 - 2:56
    that you can watch on interesting
    attack vectors using firmware-based
  • 2:56 - 3:01
    malware. One that I really liked
    was last year at DEFCON. The
  • 3:01 - 3:06
    Intel Advanced Threat Research
    presented an attack that showed
  • 3:06 - 3:12
    how firmware could - malicious firmware -
    could circumvent the hypervisors. They
  • 3:12 - 3:18
    then went further and showed how buggy
    firmware allowed a unprivileged guest
  • 3:18 - 3:25
    inside a virtual machine to escalate into
    privileges inside the hypervisor. And for
  • 3:25 - 3:30
    that reason, it's really important that
    firmware vulnerabilities and firmware bugs
  • 3:30 - 3:36
    have a way to get patched. These aren't
    just theoretical research vulnerabilities,
  • 3:36 - 3:41
    either. We know that there are malicious
    organizations and hacking groups that are
  • 3:41 - 3:48
    selling firmware rootkits to whoever will
    pay - including nation-state adversaries,
  • 3:48 - 3:56
    that are using them for their persistent
    threats. And they are very persistent,
  • 3:56 - 4:01
    because they are in the motherboard
    bootrom So you've reinstalled the OS -
  • 4:01 - 4:07
    they're still there, you swap out the hard
    drive - they're still there. And some
  • 4:07 - 4:15
    vendors are even bundling these rootkits
    into their official ROMs. That they are
  • 4:15 - 4:22
    using them to install the bloatware, or
    whatever adware they want to put into the
  • 4:22 - 4:28
    OS. So even after you reinstall a clean
    version of the OS, this particular vendors
  • 4:28 - 4:35
    system would install its own additions.
    Some of those had vulnerabilities that
  • 4:35 - 4:41
    could then be exploited by attackers. This
    particular case, the vendor received
  • 4:41 - 4:46
    enough bad press, that they released a
    firmware update that patched this
  • 4:46 - 4:51
    vulnerability. And they had to do that.
    This wasn't something that the users could
  • 4:51 - 4:56
    do on their own - they couldn't update the
    the firmware in their machine the
  • 4:56 - 5:02
    way they do with their operating system or
    an application. And in fact, most firmware
  • 5:02 - 5:09
    vulnerabilities never see patches get
    deployed out to the end-user.
  • 5:09 - 5:15
    Part of the reason for that is that the
    the firmware is usually four or five
  • 5:15 - 5:22
    companies, removed from the end-user. That
    there's the open source reference
  • 5:22 - 5:28
    implementation from Intel, called eh
    TianoCore or EDK II. When vulnerabilities
  • 5:28 - 5:34
    are patched in there, they have to get
    pulled by the independent BIOS vendor, and
  • 5:34 - 5:39
    merged into the IBV tree, and then the
    BIOS vendor sells that to the device
  • 5:39 - 5:45
    manufacturers. So they have to package up
    a release the thing gets pulled by the
  • 5:45 - 5:49
    device manufacturer. It has to get QA'd it
    against however many motherboards they
  • 5:49 - 5:56
    want to test it on. And then it has to get
    again pulled by the original equipment
  • 5:56 - 6:01
    manufacturer to get rebranded and whatever
    value they want to add. And then sometimes
  • 6:01 - 6:05
    it has to go through the operating system
    vendor to even make it out to the end-
  • 6:05 - 6:10
    user. And as a result of this, most of the
    time, products do not receive any updates
  • 6:10 - 6:15
    after they've been sold. There's one
    exception: in this chart you can see that
  • 6:15 - 6:21
    Apple builds their own firmware, and in my
    work with them, I've been really pleased
  • 6:21 - 6:26
    that they've rolled out patches for eight
    years of hardware. Which is above and
  • 6:26 - 6:35
    beyond what any other firmware vendor is
    doing right now. When EFI was introduced,
  • 6:35 - 6:44
    it brought a lot of complexity, and the
    Linux community was very skeptical as to
  • 6:44 - 6:48
    what the value was going to be provided by
    all this complexity. It's basically an
  • 6:48 - 6:54
    entire operating systems worth of code.
    And it's not, that the 16-bit real-mode
  • 6:54 - 7:01
    BIOS was all that much better. In fact, it
    had its own set of issues. But it was
  • 7:01 - 7:09
    small, it was simple, it did one thing, it
    did it okay. And it took a long time for
  • 7:09 - 7:15
    UEFI to even become widely supported. But
    even now most systems ship with both the
  • 7:15 - 7:20
    UEFI and a BIOS compatibility module. So
    they've basically doubled their attack
  • 7:20 - 7:25
    surface for potential bugs and
    vulnerabilities. So the state of the
  • 7:25 - 7:33
    firmware world today is that updates are
    rare, patches, if they ever come out, take
  • 7:33 - 7:36
    a long time to make it through the
    process.
  • 7:36 - 7:41
    Users can't fix things on their own, and
    we can't see what's inside, since most of
  • 7:41 - 7:45
    them are built with closed source
    components - and that's not a great state
  • 7:45 - 7:53
    for something that is as privileged as a
    firmware. So it's my belief, that firmware
  • 7:53 - 7:57
    needs to be built with open source. It
    must be flexible, so we can adapt it to
  • 7:57 - 8:03
    our needs for our systems. It needs to be
    built with software that we understand and
  • 8:03 - 8:09
    we use for, in, other applications, so
    that it can get widely tested and well
  • 8:09 - 8:13
    tested. It needs to be built in a
    reproducible manner, so that we can be
  • 8:13 - 8:18
    secure against that build chain attacks.
    And it needs to be cryptographically
  • 8:18 - 8:23
    measured, so that we can be sure that
    this, what we flash on the system, is what
  • 8:23 - 8:30
    is actually running on the system. And
    that's the philosophy behind Heads - it's
  • 8:30 - 8:36
    built on the free software coreboot
    firmware, plus a Linux kernel in ROM, that
  • 8:36 - 8:45
    acts as a bootloader, and then a lot of
    security research and tools, that help us
  • 8:45 - 8:52
    try to build slightly more secure systems.
    Using Linux as a bootloader is not a
  • 8:52 - 8:58
    particularly new idea. Back in the 1990s
    when we started building large scale Linux
  • 8:58 - 9:08
    clusters, we were very frustrated with the
    inflexibility of DHCP and PXE booting
  • 9:08 - 9:13
    large machines, that even with those
    frustrations, we built one, that was about
  • 9:13 - 9:21
    the 30th fastest in the world on the top
    500. Meanwhile, my colleague Ron Minich at
  • 9:21 - 9:26
    Los Alamos was also building large
    clusters, and had the observation that the
  • 9:26 - 9:33
    BIOS enumerates all the buses, initializes
    a bunch of devices, finds the Linux kernel
  • 9:33 - 9:39
    and in the Linux kernel, enumerates all
    the buses, initializes all the devices,
  • 9:39 - 9:44
    and he thought: "This is this is silly,
    why are we doing this twice?".
  • 9:44 - 9:50
    So he had the idea to build a version of
    Linux, that ran in the ROM. He called this
  • 9:50 - 9:56
    project "Linux BIOS" and it went on to
    power the MRC cluster, which was the third
  • 9:56 - 10:05
    fastest machine in the world in 2003. In
    2008 Linux BIOS underwent a major
  • 10:05 - 10:10
    refactoring and it was renamed to
    "Coreboot". And Google chose to use
  • 10:10 - 10:15
    Coreboot as the firmware on their
    Chromebooks - which are at this point the
  • 10:15 - 10:24
    only non-UEFI x86-based laptops that you
    can buy. And they've done some really some
  • 10:24 - 10:28
    great work in trying to lock down the
    configuration and the firmware on the
  • 10:28 - 10:36
    Chromebooks. Ron, who has only moved to
    Google in 2011 and is continuing to work
  • 10:36 - 10:47
    on the Coreboot project there. So Coreboot
    has three stages that it goes through as
  • 10:47 - 10:54
    it starts up the machine: the first one is
    a very small amount of real-mode assembly,
  • 10:54 - 11:01
    because your modern 64-bit laptop still
    boots up in real mode with 16-bit just
  • 11:01 - 11:08
    like its 1970's. So that's a very small
    amount of code - about 1.5K. That in turn
  • 11:08 - 11:14
    sets up a C runtime environment with
    what's called "Cache-as-RAM mode" and it
  • 11:14 - 11:20
    calls into the ROM stage which is about
    70K. "Heads" has moved the TPM
  • 11:20 - 11:27
    initialization early in the ROM stage
    before DRAM is set up to help measure the
  • 11:27 - 11:33
    boot block and provide a static route of
    trust that's hopefully a little bit more
  • 11:33 - 11:38
    secure. And because that measurement is
    done early on, our trusted computing base
  • 11:38 - 11:45
    is actually quite small. This is a
    fraction of 1% of the size of a UEFI
  • 11:45 - 11:50
    firmware, which is usually about 16 MB
    once it's uncompressed.
  • 11:50 - 11:56
    The ROM stage then measures and executes
    the RAM stage, which does the more
  • 11:56 - 12:01
    traditional "walk the bus, find / figure
    out what devices are on there", but it
  • 12:01 - 12:04
    doesn't initialize them: it just
    enumerates them and generates the
  • 12:04 - 12:09
    descriptors for Linux. It also installs
    the SMM handler for system management
  • 12:09 - 12:17
    mode. It then measures and jumps into the
    payload - and that whole process takes
  • 12:17 - 12:24
    less than a second. So it is able to get
    into the payload and actually get to the
  • 12:24 - 12:31
    user code very, very quickly. On something
    like the X230 it's able to go from power
  • 12:31 - 12:37
    on to a interactive recovery shell in less
    than 2 seconds. And that includes bring up
  • 12:37 - 12:43
    the TPM, doing cryptographic measurements
    and assessing the state of the system.
  • 12:43 - 12:47
    Because we now have Linux at this point,
    we have all the flexibility that comes
  • 12:47 - 12:54
    with that. We can implement boot scripts
    with the full power of the shell or the C
  • 12:54 - 12:58
    language runtime:
    we're not stuck with the limited functions
  • 12:58 - 13:03
    of UEFI. Linux supports lots of different
    file systems. It supports lots of
  • 13:03 - 13:07
    different devices. It supports lots of
    different encryption methods. And this
  • 13:07 - 13:13
    gives us the ability to use any of them
    for your specific application. In
  • 13:13 - 13:20
    contrast, UEFI, which supports unencrypted
    FAT file systems on the first drive that
  • 13:20 - 13:24
    have to be in the first 1 GiB or
    something, it's really, really limited as
  • 13:24 - 13:32
    to how it can find its boot device.
    There's a saying in the in the Open Source
  • 13:32 - 13:36
    community that with enough eyes all bugs
    are shallow.
  • 13:36 - 13:43
    And Linux has a lot more eyes looking at
    it. That the device drivers and the file
  • 13:43 - 13:50
    systems and the encryption have been
    reviewed by both white hat and black hat
  • 13:50 - 13:57
    people around the world. The UEFI versions
    of these do not have that same level of
  • 13:57 - 14:03
    scrutiny, so we're using both the UEFI
    drivers and then having to run whatever on
  • 14:03 - 14:08
    top of it, increases the attack surface.
    But by putting Linux in the ROM and
  • 14:08 - 14:15
    depending on its drivers we've reduced our
    attack surface very dramatically. More
  • 14:15 - 14:21
    importantly though, Coreboot and Linux are
    Open Source, so it is possible to build
  • 14:21 - 14:25
    custom versions for the device drivers
    that you need, for the file systems that
  • 14:25 - 14:31
    you need. It's possible to fix bugs when
    they come out, and sign and install your
  • 14:31 - 14:37
    own kernels. You don't have to wait for
    the vendor to get around to doing it.
  • 14:37 - 14:45
    And the third major component of heads is
    a tool called "kexec", which is a system
  • 14:45 - 14:50
    call that was added for the Linux BIOS
    project back in 2003 by Eric Peterman,
  • 14:50 - 14:56
    that allows a running kernel to do a
    graceful shutdown and start a new kernel
  • 14:56 - 15:01
    without having to go through the reboot
    process. So this allowed, on their
  • 15:01 - 15:07
    application, it allowed them to do very
    fast reboots of their cluster nodes. And
  • 15:07 - 15:12
    in the "Heads" case, it allows us to act
    as a bootloader where we can find the real
  • 15:12 - 15:16
    kernel, that you want to run, and exec it.
    Because "Heads" is quite small. It has to
  • 15:16 - 15:23
    fit in 4 MB of ROM. So it's not something
    that you learn to run as a day-to-day sort
  • 15:23 - 15:31
    of OS. Hopefully this won't explode on me
    again.
  • 15:36 - 15:41
    Because we have the Bourne Shell, most of
    the policies and the startup scripts in
  • 15:41 - 15:48
    "Heads" are implemented as as shell
    scripts. In this case we were able to pass
  • 15:48 - 15:53
    in a new set of command line parameters, a
    new initial RAM disk, and in this case we
  • 15:53 - 15:59
    can even start a hypervisor. And all of
    that can happen very very quickly, as well
  • 15:59 - 16:07
    as with with a good degree of security.
    So, those are the building blocks that
  • 16:07 - 16:13
    "Heads" is built on: Coreboot, Linux and
    tools like "kexec". But it now gives us a
  • 16:13 - 16:17
    really nice platform to begin
    experimenting with additional security
  • 16:17 - 16:23
    features. And before we go too deep down
    the rabbit hole of, you know, security and
  • 16:23 - 16:28
    threat models, I want to quote my friend
    Steph, who said that, "Your threat model
  • 16:28 - 16:31
    is not my threat model."
    But you know your threat model is okay as
  • 16:31 - 16:36
    well, that we all have different things we
    want to protect, from different attackers,
  • 16:36 - 16:40
    who are willing to spend different amounts
    of effort to go after them. And the nice
  • 16:40 - 16:46
    thing about having an open source is: We
    can build systems tailored to your
  • 16:46 - 16:51
    individual threat model. So a lot of these
    things may not actually apply to your
  • 16:51 - 16:59
    specific threats, but the fact that we can
    build them is a great capability. Last
  • 16:59 - 17:06
    year Joanna Rutkowska reminded us that
    firmware is not just in our CPU. Firmware
  • 17:06 - 17:13
    is in our Wi-Fi card. It is in our GPU. It
    is in our SSD. It is in our keyboards. And
  • 17:13 - 17:19
    all of these devices might be trying to
    subvert the boot process.
  • 17:19 - 17:26
    One way to handle that is to take Peter
    Stuge's advice of disassembling the
  • 17:26 - 17:30
    machine and ripping out anything we can't
    control. If this is your threat model, his
  • 17:30 - 17:35
    instructions are really worth following.
    They're really thorough about what pieces
  • 17:35 - 17:41
    are potentially of concern. And you're
    going, right now, you'll have to open up
  • 17:41 - 17:47
    your laptop to install "Heads." It's not
    quite as easy as it is to install most
  • 17:47 - 17:53
    Linux distributions, because we have to
    flash it into the motherboard boot ROM.
  • 17:53 - 17:57
    While we're in there, now, we take
    advantage of some features that, to the
  • 17:57 - 18:02
    best of my knowledge, no UEFI system is
    using. These flash chips have a hardware
  • 18:02 - 18:10
    write-protect mode, where you can specify
    part of the chip is write-only. Excuse me.
  • 18:10 - 18:15
    Is read-only, write-once. And this gives
    us our immutable boot block in which to
  • 18:15 - 18:20
    store the trusted computing base, the TCB,
    so that we can measure the rest of the
  • 18:20 - 18:26
    system. We also then suggest disconnecting
    the write-protect PIN from the
  • 18:26 - 18:33
    motherboard, which protects against
    certain classes of attacks, like the Intel
  • 18:33 - 18:39
    close chassis adapter, that allows
    external JTAG of the CPU.
  • 18:39 - 18:42
    Depending on your threat model you might
    want to cover that chip in epoxy as well,
  • 18:42 - 18:48
    to frustrate Evil Maid attacks that want
    to do a physical programming on it.
  • 18:48 - 18:53
    Disconnecting the write-protect PIN also
    serves to protect from other devices on
  • 18:53 - 18:59
    the machine that have access to those
    PINs. Devices like the Management Engine,
  • 18:59 - 19:09
    which is a really scary CPU inside the
    CPU. Rudolf Marek two years ago at CCC
  • 19:09 - 19:18
    called it the "Matroyshka CPU".
    And Igor Skochinsky detailed what are the
  • 19:18 - 19:24
    capabilities of the management engine. And
    they're really worrisome, that it runs a
  • 19:24 - 19:31
    opaque obfuscated blob of code about 5 MiB
    that the CPU can't see. The management
  • 19:31 - 19:36
    engine can read and write all of main
    memory. It can read from the keyboard and
  • 19:36 - 19:42
    video. It can receive Java bytecodes over
    the network and execute them on behalf of
  • 19:42 - 19:47
    someone outside the machine. And it's
    listening on the network even when the
  • 19:47 - 19:52
    system is powered off.
    So this is basically a rootkit inside the
  • 19:52 - 19:58
    chipset, as some folks have called it. So
    that concerned me a lot, and I spent some
  • 19:58 - 20:04
    time looking at how its firmware images
    are built, and realized that we can build
  • 20:04 - 20:10
    modified, reduced functionality firmware
    for it that removes all of the rootkit
  • 20:10 - 20:16
    functions, and just leaves the "CPU bring
    up" module. This takes that 5 MiB and
  • 20:16 - 20:24
    shrinks it down to about about 40 KiB of
    space. So we don't know exactly what it's
  • 20:24 - 20:28
    doing in that 40 KiB, but we at least know
    it doesn't have a device driver, or a Java
  • 20:28 - 20:32
    Virtual Machine, or a lot of the other
    functions.
  • 20:32 - 20:38
    And we've successfully done this on both
    Sandy Bridge and Ivy Bridge like the X230
  • 20:38 - 20:43
    ThinkPads as well as modern Skylake CPUs
    like the Chell Chromebook. And that's
  • 20:43 - 20:48
    really encouraging, that if we can apply
    this to more modern hardware, that allows
  • 20:48 - 20:54
    us to, you know, move away from our five-
    year-old ThinkPads to something a little
  • 20:54 - 21:02
    shinier. The management engine isn't the
    only device that might be trying subvert
  • 21:02 - 21:06
    the boot process. Again Johanna showed us
    there are lots of things to be worried
  • 21:06 - 21:12
    about. Intel's UEFI architects, Yao and
    Zimmer, recommend that firmware turn on
  • 21:12 - 21:20
    the IOMMU, now called VTD, to protect
    against rogue devices. To the best of my
  • 21:20 - 21:24
    knowledge, since they've written this
    guide, no UEFI firmware is taking
  • 21:24 - 21:29
    advantage of the IOMMU. So, it's a great
    piece of hardware to have, but it doesn't
  • 21:29 - 21:36
    help if you don't turn it on. Linux,
    meanwhile has no problem taking advantage
  • 21:36 - 21:40
    of it, so we use it, what we get
    essentially - we get that DMA protection
  • 21:40 - 21:48
    for free by using Linux as our bootloader
    in the ROM. Another way devices, rogue
  • 21:48 - 21:52
    devices, can try to interfere with the
    boot process is by providing option ROMs,
  • 21:52 - 21:59
    which are executable code to be run by the
    BIOS, that have a sort of a device driver.
  • 21:59 - 22:04
    And this code can do things like about log
    keystrokes and then try to exfiltrate
  • 22:04 - 22:12
    passwords as we see here. That problem was
    initially reported in 2007 by John Heasman
  • 22:12 - 22:19
    at BlackHat, again by Snare in 2012, and
    again by my work on Thunderstrike. And as
  • 22:19 - 22:24
    of last week a official fix has finally
    rolled out for it to close that particular
  • 22:24 - 22:30
    vulnerability.
    Folks who are using coreboot have this as
  • 22:30 - 22:36
    a option that they can say, this, I am
    concerned about this threat, let me let me
  • 22:36 - 22:40
    fix this, let me disable this function.
    And they point out that it might cause
  • 22:40 - 22:46
    degraded functionality, but that's
    something you can QA on your own system.
  • 22:46 - 22:51
    And in practice with Linux as your
    bootloader in the ROM, you don't use the
  • 22:51 - 22:57
    option ROMs for anything. Everything is
    done with with Linux's own device drivers,
  • 22:57 - 23:03
    so you're not dependent on the whatever
    limited functionality the option ROM
  • 23:03 - 23:08
    provided.
    So, now that we have we've taken our
  • 23:08 - 23:12
    building blocks and we hopefully have
    protected the boot process, and hopefully
  • 23:12 - 23:17
    the code that's running is what we think
    it is, we need to turn to how do we secure
  • 23:17 - 23:23
    the secrets on the machine. And I'm a huge
    fan of the TPM, the Trusted Platform
  • 23:23 - 23:29
    Module, now I know in the free software
    community it's been largely unwelcome. It
  • 23:29 - 23:35
    has not received a very welcome reception,
    because of the way it's been used for DRM
  • 23:35 - 23:42
    and other other user-hostile things. Since
    we control the TPM from the first
  • 23:42 - 23:47
    instruction in the in the boot block,
    we're able to use it in ways that we want
  • 23:47 - 23:55
    to, so we don't have to enable DRM, but we
    can use it to protect our secrets. And the
  • 23:55 - 23:59
    the way that it does that, is it keeps
    track of what code is executed as the
  • 23:59 - 24:06
    system boots, and it hashes that code into
    special registers called PCRs. And the
  • 24:06 - 24:11
    idea is that, you can extend the PCR by
    hashing the next module of code, and then
  • 24:11 - 24:17
    hashing that with the previous hash, and
    this creates a chain of trust that allows
  • 24:17 - 24:25
    to say: If these hashes match the expected
    values, only the code, that we want to
  • 24:25 - 24:34
    have run, has run. And then the TPM will
    only decrypt the the disk encryption key
  • 24:34 - 24:40
    if those PCRs match, which means that the
    code that we want to have run, is what has
  • 24:40 - 24:47
    been executed. This means if someone
    manages to overwrite the, the non-write
  • 24:47 - 24:52
    protected part of the ROM, that would
    change those measurements and the TPM
  • 24:52 - 24:59
    won't reveal the key to them. It also
    takes a user password and that password is
  • 24:59 - 25:05
    validated by the TPM hardware itself,
    which gives us hardware rate-limiting on
  • 25:05 - 25:11
    how often an attacker can try. It also
    gives us the ability to do hardware-based
  • 25:11 - 25:16
    retry limits, so that the TPM will flush
    the key, if they if an attacker in
  • 25:16 - 25:22
    possession of your machine tries too long.
    That does mean there's now another way to
  • 25:22 - 25:27
    lose your disk encryption key.
    And there's the the old joke about there
  • 25:27 - 25:31
    are two types of people with encrypted
    drives - those who have lost data due to
  • 25:31 - 25:37
    forgetting their key, and and those who
    will. So what "Heads" does, when you
  • 25:37 - 25:42
    generate your key, is, it takes that key
    and splits it into multiple pieces, that
  • 25:42 - 25:47
    you can then share either to friends or to
    backup services, where each piece doesn't
  • 25:47 - 25:53
    let you decrypt it. But you can combine
    them with Shamir secret sharing to
  • 25:53 - 25:58
    regenerate the cryptographic disk
    encryption key.
  • 25:58 - 26:05
    We're also able to take advantage of best
    practices like using the, including the
  • 26:05 - 26:12
    disk encryption key headers in the PCRs
    that we use to seal the disks. This avoids
  • 26:12 - 26:16
    a certain class of Evil Maid attack, where
    someone swaps out your drive; may not be
  • 26:16 - 26:19
    in your threat model, but it is easy to
    deal with just a few lines of shell
  • 26:19 - 26:28
    script. So we hopefully we now trust that
    the system is running the code we think it
  • 26:28 - 26:34
    is, but how does it prove to us that it is
    actually our machine, that someone hasn't
  • 26:34 - 26:39
    snuck into our hotel room and swapped out
    everything and left, left up, carefully
  • 26:39 - 26:44
    replaced our stickers to make us believe
    we're typing our password into to our own
  • 26:44 - 26:52
    computer. Some anti-Evil Maid toolkits
    will encrypt a secret, secret phrase, and
  • 26:52 - 26:56
    then display it to you if and only if the
    PCR is match, but that's subject to a
  • 26:56 - 27:04
    replay attack. What Matthew Garrett
    demonstrated last year at 32C3, was, using
  • 27:04 - 27:11
    the time, a time-based one-time password
    used by Google Authenticator to protect
  • 27:11 - 27:17
    the firmware and have it attest to the
    user, that it is unmodified. So when the
  • 27:17 - 27:22
    system boots, and it goes through
    measuring all of the various components
  • 27:22 - 27:30
    the, the TPM will only release the secret
    if those PCRs match. The firmware then
  • 27:30 - 27:34
    hashes that along with the current time
    and generates a six digit value that it
  • 27:34 - 27:39
    prints on the screen. You compare that to
    what's on your phone and that tells you
  • 27:39 - 27:47
    whether or not you can trust the machine.
    It's a, it's a great idea, and it's
  • 27:47 - 27:52
    implemented again as a very small shell
    script to read, read the value from the
  • 27:52 - 27:59
    TPM, unseal it and then compute the
    the hash of it.
  • 27:59 - 28:04
    This also allows us to start making a
    transition from the TPM-rooted, a TPM
  • 28:04 - 28:10
    static route of trust to a PGP-based
    trust, where most importantly, this is a
  • 28:10 - 28:15
    TPM key - excuse me, this is a PGP key,
    that you, the owner of the computer
  • 28:15 - 28:20
    control, not some random vendor or some
    random hardware device manufacturer that's
  • 28:20 - 28:26
    going to lose the key and allow malware
    like Stuxnet to use it to circumvent
  • 28:26 - 28:31
    security. The boot script
    in "Heads", again, it's a
  • 28:31 - 28:37
    small shell script, is able to use a GPG
    to verify the next stages of the, the
  • 28:37 - 28:45
    hypervisor, the initial RAM disk and the
    kernel. And it also then uses the the
  • 28:45 - 28:51
    TPM's counters to help prevent against
    rollback, where someone takes your drive
  • 28:51 - 28:55
    and rolls it back to a previous version,
    perhaps with a vulnerability that they can
  • 28:55 - 28:59
    exploit. So this, this
    allows the, allows us to be
  • 28:59 - 29:04
    sure, that not only are we running the
    firmware, the OS that we think we should
  • 29:04 - 29:11
    be running, it ensures us that someone
    hasn't been able to substitute one that, a
  • 29:11 - 29:17
    vulnerable version. Having the
    PGP key also allows us to take
  • 29:17 - 29:25
    advantage of an idea from Android and
    Chrome OS which is the the dm-verity read-
  • 29:25 - 29:31
    only root filesystem - this hashes all of
    the blocks and that hashes all of the the
  • 29:31 - 29:38
    hashes and so on up until it gets to a
    root hash in the tree that is then signed.
  • 29:38 - 29:45
    This allows the kernel, on every read
    access, in logarithmic time to verify the
  • 29:45 - 29:52
    essentially a signature on that data. This
    does require a read-only root filesystem,
  • 29:52 - 30:00
    but it gives us even more confidence that
    the system has been untampered with. Once
  • 30:00 - 30:05
    you're running your OS, it's good to have
    you know some security conscious thoughts
  • 30:05 - 30:11
    as well, you know. Heads is mostly focused
    on, "how do we securely transition to an
  • 30:11 - 30:18
    OS" and that OS you run is up to you. I
    like Qubes - it's reasonably secure, it's
  • 30:18 - 30:24
    highly recommended by people who know
    about endpoint security. And the Qubes
  • 30:24 - 30:30
    team recognizes that firmware security is
    a vital piece of system security. For
  • 30:30 - 30:35
    their next release, Qubes are for -
    they're going to require the machines have
  • 30:35 - 30:39
    open source firmware, such as coreboot.
    And I hope that Heads is going to be a
  • 30:39 - 30:46
    piece of that. I've also been working with
    with the Qubes software and have modified
  • 30:46 - 30:53
    it to work with things like the dm-verity
    read-only root filesystem. This now allows
  • 30:53 - 30:59
    the user to lock down the configuration,
    so that someone can't tamper with their
  • 30:59 - 31:06
    their setup. It also gives you a recovery
    mode that allows you to fix things up and
  • 31:06 - 31:12
    re-sign the OS. Reproducible builds are
    really important so that everyone can
  • 31:12 - 31:19
    verify what that the builds match what
    they should. In the case of of Heads we
  • 31:19 - 31:22
    have a lot of upstream dependencies that
    aren't reproducible so we're working with
  • 31:22 - 31:28
    them to try to patch them. We've patched
    Xen - they've accepted that commit. We've
  • 31:28 - 31:34
    also built some tools to let you build
    initial RAM disks in a reproducible way.
  • 31:34 - 31:37
    This works with Qubes, with Heads, and
    we're hoping to other Linux distributions
  • 31:37 - 31:42
    pick it up as well.
    All of our tree is cryptographically
  • 31:42 - 31:48
    signed, so hopefully GitHub is not trying
    to slip in any patches. And it is open
  • 31:48 - 31:53
    source so we encourage anyone to read
    through it. No NDA is required, unlike most
  • 31:53 - 32:00
    of the UEFI sources. So that's sort of the
    state of where things are - it's pretty
  • 32:00 - 32:05
    much in very beta, but it is usable. But
    there are a lot of areas where we could
  • 32:05 - 32:09
    continue to do research - things like the
    embedded controllers on Chromebooks are
  • 32:09 - 32:14
    open source. We can use those to help with
    our root of trust as well. Porting
  • 32:14 - 32:17
    coreboot to more modern platforms would
    let us take advantage of things like
  • 32:17 - 32:23
    tamper switches and Intel Boot Guard. I'm
    also working on porting coreboot over to
  • 32:23 - 32:30
    server platforms so that we can use it for
    more secure cloud hosting. Servers have a
  • 32:30 - 32:36
    very different threat model from from
    laptops, and a lot of things have firmware
  • 32:36 - 32:41
    that we have to be concerned about. One
    collaboration I'm looking at there is with
  • 32:41 - 32:46
    the open BMC project to be able to take
    advantage of the open source in the
  • 32:46 - 32:54
    management controller for the servers. And
    I'm also collaborating with the Mass Open
  • 32:54 - 33:01
    Cloud project that's trying to build
    secure bare metal clouds. I'm cautiously
  • 33:01 - 33:07
    optimistic about enclaves and how they
    will help us with the security, especially
  • 33:07 - 33:10
    in a environment where we control the
    firmware and we can ensure that the
  • 33:10 - 33:17
    enclaves are set up in a safe way. There
    are a lot of issues on GitHub, again,
  • 33:17 - 33:25
    please welcome contributions. I hope
    everyone gets inspired to to work on the
  • 33:25 - 33:31
    installing this on their laptop. And if if
    you are interested I'll be hanging out at
  • 33:31 - 33:38
    the coreboot assembly later today and
    occasionally this week. The coreboot team
  • 33:38 - 33:43
    has a bunch of people here. They have
    flash programmers and can help you install
  • 33:43 - 33:51
    coreboot on your laptop. The source code
    for Heads is available on GitHub, and a
  • 33:51 - 33:56
    annotated version of this talk is up on my
    website, and welcome comments and feedback
  • 33:56 - 34:02
    on it. So thank you all for coming to hear
    about this project I hope that everyone is
  • 34:02 - 34:07
    and you know as excited about open source
    firmware as I am and I'd love to take any
  • 34:07 - 34:10
    questions that you all have.
  • 34:10 - 34:22
    Applause
  • 34:29 - 34:32
    Question: Thanks for your great talk -
    this is very interesting. Do you have any
  • 34:32 - 34:39
    advice for the 95% of us who are stuck on
    non coreboot compatible laptops.
  • 34:39 - 34:43
    Trammell: Buy a Chromebook?
    Laughter
  • 34:43 - 34:53
    Trammell: It's hard to trust the closed-
    source firmware. It certainly; there are
  • 34:53 - 34:56
    people we have to trust - there are
    institutions we have to trust. We have to
  • 34:56 - 35:02
    trust Intel to some extent, and Intel is
    responsible for, you know, both our CPUs
  • 35:02 - 35:09
    and a lot of the firmware. Depending on
    your threat model, firmware attacks may
  • 35:09 - 35:15
    not be a huge concern for your particular
    machine. Or they might be, you know, of
  • 35:15 - 35:20
    grave concern, in which case even just
    doing some of the things that Peter Stuge
  • 35:20 - 35:30
    suggested of clipping the write-protect
    pin on the on the chip, removing things
  • 35:30 - 35:35
    that might be hostile and attacking your
    system. His guides are really good one to
  • 35:35 - 35:43
    follow for the hardware security.
    Question: I was wondering if you also
  • 35:43 - 35:50
    support ARM - I just saw Intel laptops so
    I was just wondering.
  • 35:50 - 35:55
    Trammell: So ARM it has a lot of
    advantages as a CPU. It only has 20 years
  • 35:55 - 36:01
    of legacy baggage rather than 40. And the
    boot process on it is much much simpler
  • 36:01 - 36:07
    since it doesn't have to go through real
    mode to long mode to paging and all the
  • 36:07 - 36:15
    other steps. The downside to a lot of ARMs
    is that they their boot code is a few is
  • 36:15 - 36:22
    on die and outside of the control of the
    user. Luckily, most of that boot code is
  • 36:22 - 36:29
    fairly simple, and can establish - and
    some of them will establish a hardware
  • 36:29 - 36:37
    root of trust. But in general, yeah that
    the ARM to U-Boot to whatever seems to
  • 36:37 - 36:44
    work out pretty well. I know there's been
    some interest in, "can U-Boot be replaced
  • 36:44 - 36:50
    with a Linux BIOS or coreboot like thing",
    and I suspect the folks at the booth would
  • 36:50 - 36:55
    be able to talk more about that.
    Question: And then just a followup - so if
  • 36:55 - 37:01
    coreboot or Libreboot supports the
    platform - Heads will work too right?
  • 37:01 - 37:06
    Trammell: Essentially yes, yeah.
    Heads is a payload for coreboot.
  • 37:06 - 37:13
    Question: OK.
    Herald: It's there on the left.
  • 37:13 - 37:18
    Signal Angel: Thank you - there's a
    question from the Internet about coreboot.
  • 37:18 - 37:23
    Coreboot has blobs included and, for
    example, binary blobs from Intel with all
  • 37:23 - 37:29
    the firmware support package and all that
    stuff. How can we call coreboot secure,
  • 37:29 - 37:33
    then, in the light of this - let alone
    open source?
  • 37:33 - 37:38
    Trammell: So the intel FSP is a
    significant concern. This is the firmware
  • 37:38 - 37:42
    support package that is required to
    initialize the memory controllers on on
  • 37:42 - 37:52
    modern Intel cpus. On older CPUs, such as
    the the Sandy Bridge and Ivy Bridge, the
  • 37:52 - 37:57
    coreboot and Libreboot are able to
    initialize the memory natively without
  • 37:57 - 38:06
    having to go into the FSB. However, if you
    look at what coreboot is doing in the MRC
  • 38:06 - 38:11
    on those platforms, it tends to just be
    poking a bunch of registers with values
  • 38:11 - 38:20
    that seem to work. And it's modern memory
    controllers are so complex that, and Intel
  • 38:20 - 38:27
    is unwilling to document them, that
    without extensive NDA's that it's very
  • 38:27 - 38:32
    hard to build any sort of memory
    initialization. So what we can't say it's
  • 38:32 - 38:39
    a hundred percent free software, we can at
    least we can ensure that the FSP is
  • 38:39 - 38:47
    measured and it's unchanging. We can also
    look at the state of things that it sets
  • 38:47 - 38:52
    up and include those in our measurements.
    So even if it doesn't get us one hundred
  • 38:52 - 38:58
    percent open source - and as far as I know
    the only system that does that right now
  • 38:58 - 39:05
    is bunnies' Novena laptop. At least we can
    measure it and we can know that it hasn't
  • 39:05 - 39:11
    been tampered with from
    what we initially installed.
  • 39:11 - 39:17
    Question: And before so this is a great
    project and I'd like to ask why you did
  • 39:17 - 39:24
    certain architectural decisions. The
    specific combination of Linux and shell.
  • 39:24 - 39:30
    So why didn't you choose a BSD kernel which
    are usually perceived to be more secure
  • 39:30 - 39:35
    and of a higher quality, and why did you
    choose a shell over let's say, Python
  • 39:35 - 39:41
    or Haskell, which are also often
    perceived of higher quality?
  • 39:41 - 39:45
    Trammell: There is a lot of desire to
    support Python in Heads. The downside is
  • 39:45 - 39:52
    that there's a very limited space: the
    X230 bootrom, for instance, has 4
  • 39:52 - 40:02
    megabytes of available space. The Python
    interpreter is a couple megs already. In
  • 40:02 - 40:09
    terms of why Linux over BSD - the kexec
    system call is a core component of this:
  • 40:09 - 40:15
    to be able to do a graceful shut down and
    transfer from the Linux kernel to another
  • 40:15 - 40:22
    kernel or - to any multi-boot compliant
    kernels, which includes BSD. It is a
  • 40:22 - 40:31
    necessary feature if it, if BSD had such
    functionality, that it would be a fine
  • 40:31 - 40:37
    just a choice for the the internal boot
    ROM/boot loader.
  • 40:46 - 40:54
    Question: Thanks for great work. How to
    perform updates of coreboot and its
  • 40:54 - 41:00
    payload when it's binaries used in
    measurement for releasing encryption key
  • 41:00 - 41:07
    then when you update coreboot this
    measurement will change and you will know
  • 41:07 - 41:12
    no longer will be able to boot the system
    - how to solve that problem?
  • 41:12 - 41:19
    Trammell: So migrating encryption keys
    with TPM requires a explicit step of
  • 41:19 - 41:24
    retrieving the key from the TPM with the
    current configuration and then resealing
  • 41:24 - 41:30
    it with the new configuration. One
    advantage of a reproducible build is the
  • 41:30 - 41:37
    hashes of the of all the firmware stages
    can be published - it can be pre-computed,
  • 41:37 - 41:41
    and then the PCR values can be pre-
    computed so you can read you can seal the
  • 41:41 - 41:52
    keys for the new values. In terms of the
    update process for the Heads payload - one
  • 41:52 - 41:57
    of the things that we're working on is
    being able to have an even more minimal
  • 41:57 - 42:04
    heads that has just a USB device driver
    that you can boot into, copy your new
  • 42:04 - 42:09
    payload, and then install that elsewhere
    on the chip. And part of that process
  • 42:09 - 42:15
    would involve resealing any of the keys
    that you need to transfer.
  • 42:15 - 42:17
    Herald: Another question from the
    Internet.
  • 42:17 - 42:22
    Signal Angel: Thank you. On your webpage
    you implemented Heads on ThinkPads only.
  • 42:22 - 42:28
    How much work is still needed to translate
    this to, let's say, non-ThinkPads?
  • 42:28 - 42:33
    Trammell: ThinkPads are really popular
    with the security community. It's quite
  • 42:33 - 42:36
    interesting to look out at you know the
    hall here and see how many ThinkPads there
  • 42:36 - 42:42
    are. And as a result the coreboot
    community has been very supportive of
  • 42:42 - 42:49
    ThinkPads. There's, other than the
    ThinkPads and the Chromebooks, there
  • 42:49 - 42:53
    aren't a lot of devices that support
    coreboot out of the box. And that's
  • 42:53 - 42:58
    something that I hope would change - I
    hope that some OEMs would realize there's
  • 42:58 - 43:05
    value in provide an open source firmware
    and move to move to using it. Both as a
  • 43:05 - 43:11
    cost-saving measure as well as a freedom
    measure. In terms of the difficulty
  • 43:11 - 43:16
    important coreboot to a platform - I
    haven't successfully done that yet, but I
  • 43:16 - 43:23
    suspect the people at the assembly would
    be happy to discuss that further.
  • 43:23 - 43:29
    Question: Would you plan to rework
    embedded controller firmware on ThinkPads
  • 43:29 - 43:38
    because it's remain close at birth which
    still has an access to PC bus and probably
  • 43:38 - 43:43
    couldn't be trusted.
    Trammell: So your question is how do we
  • 43:43 - 43:49
    how do we replace the EC?
    Question: Yes do plan to replace EC with
  • 43:49 - 43:52
    open source firmware as in the
    Chromebooks?
  • 43:52 - 43:58
    Trammell: So the Chromebook has open
    source EC. The part of building coreboot
  • 43:58 - 44:03
    for Chromebook involves installing the ARM
    cross compiler to build the EC firmware.
  • 44:03 - 44:09
    And the Chromebooks actually have a really
    elegant protocol for the EC to attest to
  • 44:09 - 44:14
    the CPU that is running the firmware that
    you think it is running. On other
  • 44:14 - 44:24
    platforms, this would require a lot more
    research. The doc; many of the EC chipsets
  • 44:24 - 44:28
    have data sheets available, so it's
    possible to read through and see how they
  • 44:28 - 44:33
    work. And most of them have updatable
    firmware. In case of the ThinkPads,
  • 44:33 - 44:37
    there's a module in the ThinkPad BIOS that
    will do that update. There's, we would
  • 44:37 - 44:41
    need to figure out what that protocol
    looks like.
  • 44:41 - 44:48
    Question: Sorry yes I mean if you have
    working prototype on ThinkPads probably
  • 44:48 - 44:57
    want to add remaining business open
    sources EC on ThinkPads as well in the
  • 44:57 - 45:01
    first place.
    Trammell: I'm sorry, I don't think I
  • 45:01 - 45:10
    understood your follow-up.
    Question: Okay. So if you if you have a
  • 45:10 - 45:18
    working prototype on ThinkPads and only on
    ThinkPads, will you finish somewhat soon
  • 45:18 - 45:29
    current existing prototype of open source
    EC exists in college shade by Lincoln's or
  • 45:29 - 45:37
    you are playing to extend your work on
    other platforms and finish this bits
  • 45:37 - 45:40
    later.
    Trammell: Yeah right now I have not
  • 45:40 - 45:47
    personally made any progress on the
    ThinkPad EC. I was looking into it because
  • 45:47 - 45:52
    I have a modified keyboard on my ThinkPad
    that that needs to updated EC firmware,
  • 45:52 - 46:01
    but I haven't actually gotten into that.
    This is a area of open research
  • 46:01 - 46:04
    Signal Angel: Thank you, two quick
    questions from the IRC - are you planning
  • 46:04 - 46:08
    to use systemd in the boot process
    is the first one
  • 46:08 - 46:11
    Laughter
    Signal Angel: And the second one let's say
  • 46:11 - 46:16
    you flash your firmware at the Congress
    right here with the help of a hardware
  • 46:16 - 46:23
    programmer. Can you update when there's a
    new version or do you have to currently
  • 46:23 - 46:30
    need the hardware access to update?
    Trammell: Right now you can update
  • 46:30 - 46:40
    afterwards at great risk, because you can
    leave the flash writeable, which would
  • 46:40 - 46:46
    allow you to flash after the fact. We are
    still working on a good procedure for
  • 46:46 - 46:54
    doing software-only firmware updates once
    the immutable boot block is installed. And
  • 46:54 - 46:59
    to the other question - did I mention that
    we are really short on space and we don't
  • 46:59 - 47:08
    want to put any large applications like
    systemd on there.
  • 47:08 - 47:11
    Questioner: It was like good one, thanks.
  • 47:11 - 47:19
    applause
  • 47:19 - 47:28
    postroll music
  • 47:28 - 47:43
    subtitles created by c3subtitles.de
    in the year 2018
Title:
Bootstraping a slightly more secure laptop (33c3)
Description:

more » « less
Video Language:
English
Duration:
47:43

English subtitles

Revisions Compare revisions