Yet again we're shown that secure boot and TPMs are security theatre designed for DRM and not to protect you, the user.
If it weren't closed and controlled by one large corporation's interests, there wouldn't be a monoculture, which would make this less severe of a vulnerability.
Of course, managing your own CA is a pain, but because of Linux's design an externally manageable CA system isn't practical. I believe Fedora is quite close to releasing UKI kernels that will let you import Fedora's keys dor upstream kernels, but those will likely break the moment you need DKMS for proprietory or too-bad-for-upstream drivers.
Please consider what it would take for me to reflash and install a new digital signature in the UEFI device driver for at least the following PCIe devices: (1) a GPU (2) a network card. It's a requirement that the device can cold boot after the reflash on an enthusiast motherboard that costs less than $200 retail with no other changes except the reflash, because that's what average consumers could do. If an average consumer could follow your procedure and not void their warranty, you win.
PoC or GTFO.
Loading custom CA keys into the UEFI store doesn't void your warranty and is available as a standard menu option on every UEFI setup screen I've seen. The key store can usually also be reset to accept Microsoft's keys again for when you want to run Windows.
As long as you know the password to your UEFI firmware setup, you can enroll keys or reset the key store. Of course this process is way more complicated than necessary (especially in Arch's documentation), but there's nothing preventing vendors like Canonical or Fedora from pre-signing kernels and drivers.
If you want to use your/your vendor's keys for existing drivers, you/the vendor can also have sign those files.
The only difficult step for the end user is enrolling the MOK key, which requires selecting the right option in the UEFI setup and a reboot or two. Anyone can set up a repository of presigned keys and kernels you can rely on, whether that's you or your favourite open source project.
The problem is a lack of availability because the people who would need this, open source enthusiasts running Linux or *BSD, often just disable secure boot entirely. Nobody has made a nice GUI for managing this stuff either, because everyone who messes with this stuff knows the command line anyway.
As far as I'm aware, the Platform Key is used to validate UEFI drivers' signature, so configuring Secure Boot as detailed in the Arch wiki will also provide you with the possibility to sign a UEFI driver.
I'm not sure if there are any open source UEFI drivers out there (I don't think anyone has bothered), but you could write them if you wanted to. Kind of like Windows drivers, there's just not a lot of interest in open source UEFI drivers. Secure boot isn't preventing you from writing your own drivers.
Customization of the POST boot logo image should be as simple as burning an image to a simple flash ROM which remains untrusted and data-only (no-execute) - the fact that performing these ostensibly harmless customizations will introduce a security issue just leads me to believe an intelligence agency is involved somehow...
I mean, it makes sense: one can probably convince the leaders of Hamas or Cuba that it's worthwhile to let the 14yo great nephew twice-removed of an inner party cadre member to replace their laptop's capitalistic imagery from ASUS/Acer/Razer/Dell with some JPEG with far more revolutionary appeal - they'd never suspect a thing...
This is definitely the kind of thing intelligence agencies look for but considering the half century of C programmers utterly failing at decoding files safely makes me highly skeptical that anyone needed to compromise all of these vendors.
Also, the Hamas thing is a bit of a tangent but given that Israel had over a year’s advance notice I suspect that elite hacking is not a prerequisite.
If you think compact C file parsing libraries containing vulnerabilities are some kind of conspiracy by intelligence agencies, I've got bad news for you about almost every operating system out there.
Hopefully in the future vendors will pick up languages like Rust with better memory management security (though any programming language can contain vulnerabilities, of course), at least for critical components like UEFI firmware, but as long as the current code bases are used, we'll have parsing bugs. These firmwares have over a decade of legacy at this point, and if they haven't bothered fuzzing up to now, I doubt they will do in the future, let alone rewrite their parsers to be safer.
This is a bad take. Authenticated and validated secure boot is an important feature that keeps us all safe.
Tell that to my Chromebook that you can't crack. Or a Macbook. Or your phone. Or even a UEFI device absent the occasional vulnerability like this. There are vulnerabilities, but they're comparatively rare and they get patched.
In fact this is simply wrong. Defense of systems against attackers with physical access is a mostly solved problem, and secure boot is the answer. It is not (and never will be) perfect, but it does work.
This is not some science fiction scenario; look at the "addin boards" they found in CryptoPhones (you know that thing was using secure boot!):
https://www.cryptomuseum.com/crypto/gsmk/ip19/implant.htm
Nobody cares to exploit or modify the software if at the end of the day what you are trying to protect is running across a PCB trace and they have physical access.
Brilliant, but not a software or hardware issue. (Although actually having the device brick itself if it is opened up would have prevented the bug from being inserted).
Likewise secure PIN pads are easily "defeated" by a camera.
Plenty of TPM devices are encased in epoxy and designed to self destruct if tampered with. And lots of modern day devices (iPhones, game consoles) have stood up to years of attempts to exfiltrate their secrets.
Work arounds are possible, but the industry has, for better or for worse, figured out how to make secure secret stores.
NSO ? I mean, am I the only paranoic that thinks that Apple fixes its holes only _after_ other people make them public ?
Can I have it for a week or two, then send it back?
Chromebooks are quite robust against remote attacks, and they're fairly robust against local physical attacks, but "Put an external interface on the NOR SPI flash and put whatever you want there" defeats just about everything they do with secure boot, because you can put your own code there instead. Or, on at least some devices, just remove the write protect screw and run some incantations[0].
If you have physical access, very few systems are designed to be trustworthy in those cases. Even if you have a ROM root of trust somewhere, if it's on the board it can be desoldered and replaced with a different one (and I'm not aware of any hardware that does more than "write protect regions of the SPI flash - it can be done, but it's certainly not common).
Even the TPM can be physically de-encapsulated and be manipulated/have data read out, if it's a discrete physical device.
[0]: https://www.chromium.org/chromium-os/developer-information-f...
This hasn't been true for a decade or more. Boot ROMs are validated by on-chip firmware in the modern world (not just on Chromebooks, everywhere). You can flash the chip with your JTAG gadget, sure, but if doesn't have a signature that works it won't do anything but brick your board.
No, the obvious holes have long since been plugged. The design is secure. The implementation may have holes, but on the whole you can't break into an arbitrary box. You need to get lucky with a crack like the one in the linked article.
I'm going with what's written here as truth - if that's out of date, well... wouldn't surprise me, really: https://chromium.googlesource.com/chromiumos/docs/+/HEAD/wri...
> Note that even in case of the devices protected by the SE, opening up the device and disconnecting the battery would still disable write protection.
Unless I'm missing something, the "read only" region is simply a normally write-protected region of the flash chip, and with physical access, there a range of ways to rewrite that region.
It also causes a great deal of trouble (at least for me), which is why disabling it is the first thing I do when I get a new machine.
None of this means that I'd be going totally unprotected. It means that I'm addressing my security risks in a different way that is compatible with my use of my machines.
But UAC is not built into the motherboard, it's just a part of modern Windows, and it's only a factor when running Windows.
While UEFI, GPT, TPM, and SecureBoot immediately acted as major stumbling blocks to any OS not already installed on the PC at the factory. Insidiously smoothed over to behave on the surface for Windows 8+ no differently than under traditional BIOS, these were and still can be major stumbling blocks to the use of Linux or previous versions of Windows.
Plus with 20/20 hindsight as we have seen, CSM, regardless of the upcoming industry removal schedule for the CSM firmware modules, is not a full BIOS substitute for the real thing.
As predicted without having to possess 20/20 foresight at all.
Yes, this is why I don't put a lot of thought into UAC stuff -- the only place I use Windows is at my job, where it's required.
Which means that SecureBoot is an even greater worry for me.
It's always amusing how much people don't understand either of secure or trusted boot and start rambling about it.
OTOH, once the original Microsoft-signed SecureBoot keys for both Windows and Linux became compromised in recent years, triggering the need to blacklist those keys in everyone's firmware which requires an unprecedented worldwide need for a timely firmware update only if available from the original motherboard manufacturer, along with corresponding OS updates to match, neither of which has been fully accomplished yet, there was no-one to rely on other than Microsoft to mitigate the snafu.
More than just amusing, to "quote" Ballmer: "This is by design."
> "source of trust" is a technical term, and not a judgement about trustworthiness.
No, its both. And when there is a mismatch then you have a problem.
You could have this bug with or without that stuff, and it would be bad either way.
Or maybe you're trying to say that secure boot is an impossible problem and we shouldn't try? No, it clearly works. Boot cracks on UEFI devices are real, but comparatively rare.
[1] An image format parser bug
[2] To display that image at boot
Not really. The UEFI firmware is supposed to extend PCRs in the TPM based on what it does, but it looks like these vulnerabilities allow taking over the firmware before it does this and thus allows spoofing of what goes in those PCRs. Which breaks TPM security.
Except I'm not aware of any DRMs that use TPMs or secure boot (the 4k DRM that bluray and netflix uses SGX), but I use secure boot and TPM to handle my FDE keys, which I use everyday.
Don’t blame shoddy implementations by companies who are only checking checkboxes.
The only attack TPM-backed disk encryption prevents is someone imaging the disk.
The last section of the article you link says TPM 2.0 may fix the sniffing attack. It’s also worth noting that “someone imaging the disk” was really easy if you got even fairly brief access to the computer, whereas the other attacks that may still be viable involve invasive surgery and specialised knowledge of the hardware in question.
(This is my understanding as a developer not particularly informed about boot arrangements, upon reading some relevant material. I could be wrong or have missed some nuance.)
English is not my native language but, as far as i know, _may_ expresses uncertainity.
“Don’t let perfect be the enemy of good.” Vulnerabilities/limitations should be understood and you have every right to determine that TPM+PIN is the minimum control that addresses threats you’ve modeled and reduces risk to a tolerable level, but TPM-only encryption is not pointless. It reduces risk by increasing required attack complexity without impacting usability. That’s enough for a lot of people.
The fact this isn't mandatory blows me away. I remember when my work machine first got TPM full disk encryption, a passphrase was needed.
A few years later? Meh. Who needs "real" security.
Of course I get it is a convenience trade off, it almost always is.
I get it, for everyday people TPM-only is enough, but anyone remotely security-minded (or anyone traveling to the US and thus subject to the whims of the CBP) is better served with a good passphrase.
Variations on plausibly deniable rubberhose | TrueCrypt bare metal vmhosts allow for parallel OS's - one that can be booted by default and be "family friendly" with all the apps and photos | IMs etc expected and another (or many) OS's that have non obvious triggers to allow for passphrase entry into journalists document vaults.
The evidence for parallel OS's is two fold:-
* non obvious drivers almost always overlooked and essentially never noticed in border patrol scans, and
* "unused" areas of drive storage with contents indistinguishable from white noise (or multi pass disk shredding).
Otherwise, how do I know that it really serves me? A TPM serves the first person who programmed it.
Are they also security theater?
I don't understand how this is not downvoted into oblivion. As others have already pointed out, this is absolute BS.
Can a TPM not be used to remotely attest that you are running an unmodified OS and a TPM device that has been approved by the DRM implementer, before handing you an encryption key that never touches the disk?
Can you not restrict the list of approved OS to those that do not allow root/kernel access to the user?
Can you not restrict the list of approved TPMs to those that cannot be "easily" compromised? (i.e. only allow TPMs in the same die as the CPU)
Just because it's not used today does not mean it won't be used tomorrow. Microsoft has not completely pushed this through yet because they know that half of their userbase are pirates. But they are making preparatory steps for it, such as blocking systems without TPM or older CPUs out of Windows 11.
Just look at Android to see what it will look like in a few years.
Riot Games's anti-cheat for Valorant will already not let you play if you don't have a TPM and Secure Boot enabled, and I'm pretty sure you need to have factory (Microsoft) keys for it to work.
Google has recently backtracked on their WEI API proposal which would give websites access to TPM remote attestation, but it will be back once people cool off. Once it's released you can count on every website with ads (like YouTube) to slap it on just to ensure you don't block them.
The list of things you cannot do on your Linux box will just keep increasing over time.