Mathew Garrett On The State Of Boot Security

[phoronix]

Phoronix: Mathew Garrett On The State Of Boot Security

Matthew Garrett presented this week at the Chaos Computer Club's 32C3 conference about the state of boot security...

http://www.phoronix.com/scan.php?page=news_item&px=MJG-CCC-Boot-Security

[stevenc]

TL;DW: how do you know the password prompt to unlock your encrypted disks isn't fake?

mjg's answer: you must have a TPM, and trust all the hardware, and then UEFI and bootloader and kernel must have no bugs, you must use secureboot, have the TPM communicate with your mobile phone and use that to check some crypto challenge to power on your laptop every time. and Apple sucks because they don't have a TPM or secureboot to do those things. and Intel sucks because they write bad code, blah blah.

my simple answer: you still don't know. you go to all that trouble, and someone could snatch your laptop right after you unlock it. or swap it for an identical-looking one. the hardware is probably backdoored anyway. using secureboot sounds so fragile, it could easily break on a bootloader or kernel update; or if your phone battery dies, you can't boot your laptop and you're screwed, stuck someplace without communications or access to your data; when people panic they throw all basic security out the window.

my practical answer: don't leave 'secure' laptops in your hotel room. don't take them through US border control. otherwise, at least put the bootloader on removable flash and keep it with you, separate from the laptop. use open-source firmware, on simple hardware, and re-flash as often as needed to make you comfortable it wasn't tampered with. that's about as secure as any laptop will ever get.

[Luke]

TL;DW: how do you know the password prompt to unlock your encrypted disks isn't fake?

mjg's answer: you must have a TPM, and trust all the hardware, and then UEFI and bootloader and kernel must have no bugs, you must use secureboot, have the TPM communicate with your mobile phone and use that to check some crypto challenge to power on your laptop every time. and Apple sucks because they don't have a TPM or secureboot to do those things. and Intel sucks because they write bad code, blah blah.

my simple answer: you still don't know. you go to all that trouble, and someone could snatch your laptop right after you unlock it. or swap it for an identical-looking one. the hardware is probably backdoored anyway. using secureboot sounds so fragile, it could easily break on a bootloader or kernel update; or if your phone battery dies, you can't boot your laptop and you're screwed, stuck someplace without communications or access to your data; when people panic they throw all basic security out the window.

my practical answer: don't leave 'secure' laptops in your hotel room. don't take them through US border control. otherwise, at least put the bootloader on removable flash and keep it with you, separate from the laptop. use open-source firmware, on simple hardware, and re-flash as often as needed to make you comfortable it wasn't tampered with. that's about as secure as any laptop will ever get.

Even worse: a mobile phone is an attack vector when dealing both with state level and with ISP level attackers. If you use it as part of your security chain the easiest way to get your communications is to do something in the phone that makes your laptop unbootable, then monitor whatever you use in it's place. From their perspective they hope that's your phone. Also, replacing the crypto challenge in your phone could easily be done remotely by the exact same MSS, FBI, or FSB operative who is replacing your initramfs-if indeed these agencies decide to act like your hacker roomate instead of pros with access to custom hardware.

The attacks on full disk encryption we see in the wild don't involve the "evil maid" software attack or even BIOS/UEFI attacks, probably because these require predicting in advance what software or hardware the opposition is using. Instead the keyboard is pulled and an inline hardware keylogger installed. Gluing down the keyboard with epoxy will slow this down but any computer that has been in the custody of your opponents while out of your sight should never be booted again to any encrypted filesystem. I recommend forensic examination without boot, followed by destruction.

We DO see UEFI style attacks in one scenario: that is the delivery of computers in bulk to a known adversary of the government of the day. A well known example is NSA interception of computers ordered by the Chinese military or government using shipping services the US can control or passing through US territory. A physical keylogger is vulnerable to detection by physical search, and in any event can't see the screen or IP addresses connected to. Thus the UEFI or BIOS is targetted instead. Due to this, secure computers must be purchased in cash and in person, taken randomly off the shelf. If the vendor or the delivery person can predict which computer will go to you, that is an attack vector.

[chithanh]

Also during Q&A it was pointed out that even with all those measures in place, the Evil Maid could just steal your laptop and put a fake one in place that just relayed I/O to the real one.

[SystemCrasher]

Mathew Garrett should listen to Intel bullshit a bit less and use his brain a bit more, taking more accurate look on overall system architecture and implementation details, like Intel ME, bootguard, non-removable ME firmware and so on.

The harsh truth is: you can't be secure on x86. And it's not just my idea. This conclusion comes from famous security expert, Joanna Rutkowska. While secure boot can work in favor of system owner, it just not going to happen on Intel x86, no matter what. You can't have your own, reliable, verifiable, opensource root of trust, but doomed to run huge blob firmware which can pwn system at will, can use net and so on. This can't be secure. Time to acknowledge obvious and stop this treachery.

Edit: of course I should post proof link in this place.

[mjg59]

Mathew Garrett should listen to Intel bullshit a bit less and use his brain a bit more, taking more accurate look on overall system architecture and implementation details, like Intel ME, bootguard, non-removable ME firmware and so on.

From the article:

Now, to be fair, there's attacks that even Windows and properly configured Linux will still be vulnerable to. Firmware defects that permit modification of System Management Mode code can still be used to circumvent these protections, and the Management Engine is in a position to just do whatever it wants and fuck all of you. But that's really not an excuse to just ignore everything else. Improving the current state of boot security makes it more difficult for adversaries to compromise a system, and if we ever do get to the point of systems which aren't running any hidden proprietary code we'll still need this functionality. It's worth doing, and it's worth doing now.

[stevenc]

I just don't feel safer with UEFI, secureboot, or trusting a hardware TPM to keep secrets. If anything it sounds a worse situation to me - these technologies seem more apt at stopping the user from installing a free OS, gives way more room for hardware vendors to screw you - and it sounds so fragile you may become locked out of your system and encrypted disks accidentally.

If you reflash system firmware with libreboot, then GRUB2 can verify (your own) GPG signatures on files before it loads them. It even supports some old Apple MacBooks, no TPM necessary. Even if advanced malware was baked into the design of 2006 hardware, I doubt it could successfully compromise an OS only developed years afterward.

[Kano]

I don't any increased security for evil maid attacks directly thru Windows Secure boot keys at all as you could use mjg59 own Linux Foundation Preloader. If you replace the keys you can sign everything on your own, then the boot security is down to the UEFI firmware password (to disable it). Maybe add post boot checks against all unprotected/unencrypted files of your hd. I would use a self encrypting ssd but if somebody modifies the firmware you are lost anyway. You could use SPI connectors in worst case to get access to it, it just increases the costs, it does not solve the problem. 100% security for hardware is impossible - for basic theads a hd password is enough, simple evil made attacks on powered off systems with no firmware bug that still holds the password should be impossible.

[Serge]

I'll play Devil's Advocate and speak out in favor of Secure Boot.

While it is not a complete and perfect defense against attackers that gain physical access to your device, I think a little perspective is in order. Provided that you replace your device's stock PK, KEK, and db keys with a PK, KEK, and db that you generated yourself, I think the so-called "Evil Maid" attack, which I believe is a substantial and prevalent attack vector, will be sufficiently thwarted by a properly standards conformat UEFI and Secure Boot implementation. Attackers will still have the ability to physically modify your device's internals, but very few of us actually have a threat model that includes attackers trained and motivated to go to such lengths.

The most important thing is to replace the keys and ensure that the interface mechanism that's used to manage keys is itself protected. If your device does not make that possible and your device is stuck being able to boot executables that are signed by keys not under your direct and immediate control, then yeah, Secure Boot is kinda pointless.

As for "what kinda spyware does Intel build into the hardware?!?", truth is that I don't think there is a single person in the world that can attest to the provenance of their device's entire supply chain. Even if you could somehow pause time indefinitely and then personally design all of the chip logic and board circuitry, and then personally operate the equipment that is used to produce this hardware, you are still susceptible to compromise through the design tools and equipment that you use in this process. In my opinion, to maintain our own sanity, I think we should worry about what kind of spyware manufacturers might be including in devices only if we have tangible evidence that the manufacturers in question have engaged in such behavior in the past.

EDIT: Oh, and for the record, I do not currently use Secure Boot on my main laptop. I've played with it. I've explored what deficiencies my laptop's UEFI implementation suffers from. I've replaced the factory-supplied keys with my own. I had a lot of fun in the process. But after the novelty of learning something new wore off, I just found it to be too much of a pain to either toggle Secure Boot off and on or sign every executable each time that I have a new executable that I want to boot, so now I normally just leave Secure Boot disabled. I haven't stayed with this laptop in a hotel yet, but if I do, you bet I'll leave Secure Boot enabled.

[stevenc]

The harsh truth is: you can't be secure on x86. And it's not just my idea. This conclusion comes from famous security expert, Joanna Rutkowska.

Actually she describes brilliant mitigations for this. She seems to think along the same lines as me on many things... including that we can't trust commercial vendors to solve this for us.

For anyone interested, her talk and corresponding papers are excellent:

https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops

http://blog.invisiblethings.org/pape...86_harmful.pdf (the problems)
http://blog.invisiblethings.org/pape...te_harmful.pdf (designs for possible solutions)