Garrett: Producing a trustworthy x86-based Linux appliance

[Posted June 2, 2021 by corbet]

Matthew Garrett has written up the long, complex series of steps required to build an x86 device that only boots code that the creator wants to run there. "At this point everything in the boot process is cryptographically verified, and so should be difficult to tamper with. Unfortunately this isn't really sufficient - on x86 systems there's typically no verification of the integrity of the secure boot database. An attacker with physical access to the system could attach a programmer directly to the firmware flash and rewrite the secure boot database to include keys they control. They could then replace the boot image with one that they've signed, and the machine would happily boot code that the attacker controlled. We need to be able to demonstrate that the system booted using the correct secure boot keys, and the only way we can do that is to use the TPM."

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 15:13 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (21 responses)

While the presentation pretends catering to the needs of paranoïd users, no one but very dedicated tivoizing evil corporations will invest in deploying and maintaining all the parts this sand castle requires to work.

We could not even deploy “simple” tech like individual certificates without something like let’s encrypt! (And let’s encrypt totally voided any attestation/trust value certificates might provide).

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 15:19 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> We could not even deploy “simple” tech like individual certificates without something like let’s encrypt! (And let’s encrypt totally voided any attestation/trust value certificates might provide).

That's not quite true; let's encrypt ties attestation/trust to the entity that controls the domain in question. Which is all most registrars ever did.

It will be impossible to further improve trust/attestation until the globally-trusted CA model is discarded in favor of something like DANE (+DNSSEC)

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 16:22 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

> That's not quite true; let's encrypt ties attestation/trust to the entity that controls the domain in question.

Which means that anything that wrestles control of a domain can “prove” to others it is legit :(. Putting the trust bar quite low.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 17:01 UTC (Wed) by pizza (subscriber, #46) [Link]

> Which means that anything that wrestles control of a domain can “prove” to others it is legit :(. Putting the trust bar quite low.

But that's not something pioneered by letsencrypt -- Every SSL certificate I've ever purchased from a "traditional" CA was validated the same way; via proving you have operational control of the domain.

If anything, letsencrypt's approach represents an improvement, as any fradulently-obtained certificate will become invalid sooner rather than later due to their short, 3-month lifecycle.

Sure, you could always pay a registrar extra for an "extended validation" certificate, but they were never common, and browser makers have found they're not the panacea they were hoped to be.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 17:48 UTC (Wed) by st (guest, #96477) [Link] (14 responses)

I do not want a tivoizing corporation using techniques like this against me any more than anyone else reading this. However, as a slightly paranoid user, I find this very interesting if I can leverage it to work for me rather than against me.

Some time ago I used to work in the online gambling community, and I read enough real user accounts of Evil Maid attacks to know the threat is legit. A large international poker tournament in a hotel-casino is a very inviting target for Evil Maid attacks. The attackers know many of the guests staying in the hotel are online poker players with very valuable data on their laptops.

Of course, a cabal of Evil Maids isn't sophisticated enough to try to flash mainboard firmware, but I'm not one to judge an individual's threat model just because I'm not targeted by adversaries as sophisticated.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 17:59 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (3 responses)

> Of course, a cabal of Evil Maids isn't sophisticated enough to try to flash mainboard firmware

The techies providing the cabal of Evil Maids with attack tools, on the other hand, might be.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 18:12 UTC (Wed) by MattBBaker (guest, #28651) [Link]

Or asking the Evil Maid to bring the laptop to the break room where the techie is hiding out, flash it, then take it back. Leave a bottle of cleaner behind for the excuse to go back. Feels like I'm writing a hacker thriller movie already.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 5:21 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

Many recent PCs even have a helpfully colour-coded USB port that'll reflash the firmware without initialising the main CPU (and no UI = no prompts), so that's the hard part done.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 5:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

It should destroy the stored encryption keys, though.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 19:39 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (8 responses)

> However, as a slightly paranoid user, I find this very interesting if I can leverage it to work for me rather than against me.

Well, read the article then. It is *not* a simple or cheap endeavor, it requires quite a lot of infrastructure, there’s no way the casual paranoïd user will ever leverage this.

Far cheaper to buy single-use burner hardware, you need scale (and lots of identical systems to protect) to make the thing semi worthwhile.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 2, 2021 22:03 UTC (Wed) by st (guest, #96477) [Link]

You are right. I stand corrected.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 5:12 UTC (Thu) by gdt (subscriber, #6284) [Link] (6 responses)

I wouldn't be so sure. The level of ransomware attacks in corporations has bought a sharp focus to the integrity of the installed operating system. What's described in the article is less complex than some other fleet management tasks.

It's not all addition of complexity either. Tying disk encryption keys to the mainboard's TPM makes administration of disk encryption simpler since there's no need to find an out-of-band way to enter the keys upon boot. Using your own secure boot keys and deleting the default keys means that stolen laptops can't be re-imaged and resold and provides a positive marker of removal of the laptop from the fleet (firm's keys removed, firms BIOS password cleared, default keys added, standard OS installed).

On the embedded systems side, it's notable that Cisco and Juniper have vastly improved the integrity checking of their operating systems due to instances of supply-chain attacks (the best-documented of these was in US NSA slides leaked by Snowden).

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 6:53 UTC (Thu) by patrakov (subscriber, #97174) [Link] (5 responses)

> Using your own secure boot keys and deleting the default keys

I was going to do that on my own machines, but this statement in the Arch wiki has stopped me:

> Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware is signed using Microsoft's key.

https://wiki.archlinux.org/index.php?title=Unified_Extens...

Is it accurate? How to check in advance whether it is safe to replace the default keys on a particular desktop or laptop?

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 11:03 UTC (Thu) by leromarinvit (subscriber, #56850) [Link] (1 responses)

> Is it accurate? How to check in advance whether it is safe to replace the default keys on a particular desktop or laptop?

1. Buy computer
2. Replace keys
3a. It works? Good!
3b. It doesn't? Return it as broken, because it is. Tell people not to buy $BRAND (or at least $MODEL) and why.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 24, 2021 12:15 UTC (Thu) by immibis (subscriber, #105511) [Link]

3b.ii: argue with the manager for 2 hours before getting banned from the store.
3b.iii: sue the store.
3b.iv: lose.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 4, 2021 18:50 UTC (Fri) by JanC_ (guest, #34940) [Link]

Sounds like you’d want to keep one of Microsoft’s signing keys (the one used to sign UEFI drivers & device firmwares) in addition to your own, or make 100% sure you re-signed everything with your key (if that is possible, as it might be included in some ROM)?

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 4, 2021 20:54 UTC (Fri) by thwalker3 (subscriber, #89491) [Link] (1 responses)

> Is it accurate? How to check in advance whether it is safe to replace the default keys on a particular desktop or laptop?

I've actually had much better luck with this with laptops (Lenovo X1s in particular), presumably because everything is integrated. Tried it on a desktop once and found it wouldn't POST until I removed the 3rd party graphics card because or the MS signed option ROM. Unfortunately, the MS cert that is used for these ROMs is the same as that used for shim, so leaving it in db means anyone can boot their favorite distro via USB if they can get it into the boot order.

If you're trying this for the first time on hardware that you don't know how it will behave, it is wise to dump the UEFI ROM with an external programmer before you change the keys so that you can restore it to working order if you find that removing the MS cert leaves you with an unbootable system.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 9, 2021 14:16 UTC (Wed) by JanC_ (guest, #34940) [Link]

Are shim & the ROMs signed by the same key, or by different keys signed by the same CA key?

(If they are separate keys, it would be possible to blacklist it.)

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 9:51 UTC (Thu) by k3ninho (subscriber, #50375) [Link]

>Of course, a cabal of Evil Maids isn't sophisticated enough to try to flash mainboard firmware
I think it works to the advantage of Evil Maids that you underestimate them. They don't just learn where to balance the chocolate in the turn-down service in Evil Maid School, you know.

K3n.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 4:40 UTC (Thu) by alison (subscriber, #63752) [Link] (1 responses)

> no one but very dedicated tivoizing evil corporations will invest in deploying and maintaining all the parts this sand castle requires to work.

Assuredly companies that make SCADA systems for utilities or robotic medical devices that must be networked should be extremely motivated about traceability of the boot chain? Perhaps their insurers will require them to behave this way? Companies in Taiwan and South Korea have excellent reasons to build in the strongest Chain of Trust that money can buy for reasons that scarcely need explanation.

Tivoization is real: no one should deny it. Nonetheless I'd prefer that my electricity provider and any robotic surgical device that cuts into me to have the strongest possible security.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 7:24 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

The companies making the systems, yes, their customers not at all.

When you have the scale to deploy a SCADA or a medical system the last thing you want is something that would allow your providers to lock you into a particular setup, driving costs sky-high. Also you plan for decades, not for the next Christmas sale.

That’s the same reason Apple, Samsung, etc could adapt to component shortages (very narrow product offering range, with short shelf life) but automakers could not (very broad product offering range, with long shelf life).

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 6, 2021 22:11 UTC (Sun) by marcH (subscriber, #57642) [Link]

> While the presentation pretends catering to the needs of paranoïd users, no one but very dedicated tivoizing evil corporations will invest in deploying and maintaining all the parts this sand castle requires to work.

BTW when you buy a chromebook you get both: the "evil tivoization" _and_ the freedom to do and install whatever you want. Even... Windows :-)

Of course not both at the same time.

https://www.chromium.org/chromium-os/chromiumos-design-do...
https://chromium.googlesource.com/chromiumos/docs/+/maste...
https://mrchromebox.tech/#alt_os

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 12:35 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Hi Matthew, if you notice this... your website is blocking me with 403 Forbidden. Are you using an IP-based denylist? I'd love to know what denylist I'm on....

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 3, 2021 19:52 UTC (Thu) by thwalker3 (subscriber, #89491) [Link]

This is right up the alley of https://safeboot.dev/. Long story short, Secure Boot + self-signed PK, KEK, db certs + TPM gives you a system that can only access the encryption key for the rest of the disk provided the system is booted with known UEFI code, config, and kernel/initrd/boot parameters.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 4, 2021 1:55 UTC (Fri) by martin.langhoff (guest, #61417) [Link]

We did a version of this for OLPC. We used OpenFirmware, which validated kernel and initramfs had valid signatures. Kernel and initramfs applied antitheft checks -- they could soft-brick the laptop if they thought it was stolen. Once booted to userland, no more controls.

As Matthew points out, validating the hw itself against tampering is somewhere between very hard and a fool's errand. Linux userland support for this has gotten much better it seems.

In any case, once you have a system like this, it's a massive PITA to maintain the toolchain, issue developer builds that both apply the restrictions/validations and yet provide an escape hatch and debugging mechanisms.

There are many use cases. Tivoization is only one of them. Securing your own hardware, and antitheft tools are important ones.

Garrett: Producing a trustworthy x86-based Linux appliance

Posted Jun 5, 2021 0:21 UTC (Sat) by cypherpunks2 (guest, #152408) [Link]

An attacker with physical access to the system is going to be able to get around any form of verification put into use. The real reason to be using any form of trusted boot is to prevent privileged local processes from modifying firmware while still allowing firmware to be updated by legitimate users.

Secure Boot is not designed for this. It is the job of SRTM, which involves a read-only component of the BIOS called the CRTM. This component is (or should be) physically read-only so even an SPI programmer cannot modify it (much less malicious code in kernelmode). All the CRTM does is send a hash of the BIOS to the TPM, which can then implement the rest of SRTM.

The real reason it's not used very often is because any small change to firmware configuration will break it. Combining Heads (https://osresearch.net/) with Intel BootGuard goes very far.