7 ms·
Yet again we're shown that secure boot and TPMs are security theatre designed for DRM and not to protect you, the user.
by beeboobaa 3y ago
Yet again we're shown that secure boot and TPMs are security theatre designed for DRM and not to protect you, the user.
- nine_k 3y agoA TPM is a pretty useful thing, but all it can do is to securely store secrets.
- eimrine 3y agoTo securely store some secrets from the user?
- Avamander 3y agoFrom everyone, if needed.
- nine_k 3y agoYes. E.g. there are cases when it's much better to lose your disk encryption key and the entire disk's contents with it than to let a third party see it. So the disk encryption key may live in a TPM. This is supported by LUKS, for example.
- mschuster91 3y agoStill pointless when the key can be sniffed in cleartext by intercepting the communication between the TPM and the CPU [1]. You should always combine it with something only known to the user (i.e. a passphrase). The only attack TPM-backed disk encryption prevents is someone imaging the disk. [1] https://blog.scrt.ch/2021/11/15/tpm-sniffing/ https://blog.scrt.ch/2021/11/15/tpm-sniffing/
- chrismorgan 3y ago> 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.)
- hulitu 3y ago> The last section of the article you link says TPM 2.0 may fix the sniffing attack English is not my native language but, as far as i know, _may_ expresses uncertainity.
- dan000892 3y ago…or booting from alternate media to retrieve data from the disk in situ (depending on which measurements are used to seal the key in the TPM). “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.
- devbent 3y ago> You should always combine it with something only known to the user (i.e. a passphrase). 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.
- LoganDark 3y agoYes, exactly. The user is the enemy.
- immibis 3y agoIf a TPM is going to be supported, I want to be the one to install it - whether that means inserting a USB key, or soldering it onto a circuit board. Otherwise, how do I know that it really serves me? A TPM serves the first person who programmed it.
- MBCook 3y agoApple has it working just fine. Don’t blame shoddy implementations by companies who are only checking checkboxes.
- stefan_ 3y agoWhile Apple will spend billions on the latest techniques to ensure your iPhone can only run things Apple signed, there is meanwhile a real lack of enthusiasm around the basics like making the central messaging app not a native code shitshow invoking obscure (native of course) open source libraries they never update, you know, the basics. It's the latter that keeps getting their customers exploited.
- hug 3y agoWhy are you emphasising native code? Is there something about native code being bad that I am missing?
- geraldhh 3y agoeverything not running in a browser is bad, b/c it's not within reach of the fullstack shitheads /s
- xerox13ster 3y agoif they can't go down to the metal, they're not "fullstack" /s
- chriswarbo 3y agoNative code has more direct access to the system, e.g. accessing arbitrary regions of a process's memory via pointer arithmetic, invoking arbitrary syscalls, etc. In contrast, "managed code" like a JVM, CPython VM, etc. is subject to a more structured semantic model, which allows more restrictions to be imposed.
- bigstrat2003 3y agoThis is an absolutely terrible take. Just because the mechanism doesn't provide perfect security doesn't mean a) it provides none, or b) it isn't even trying to provide security.
- stefan_ 3y ago"Secure boot", despite the name, really has very very little to do with security and everything with only running "sanctioned" code, even if that sanctioned code is an ancient browser engine or 300 MiB worth of .text.
- ajross 3y agoBetter an ancient browser engine and 300 MiB worth of .text than a trojaned userspace launched by someone with a USB stick. This is a bad take. Authenticated and validated secure boot is an important feature that keeps us all safe.
- stefan_ 3y agoIf someone has access to the hardware you have lost already. The other argument people make is that it prevents "persistence", as in the "authenticated and validated" code is actually a remote code execution engine, but while it does that, at least it can't be modified to be.. even worse? It's little consolation really.
- ajross 3y ago> If someone has access to the hardware you have lost already. 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.
- ajross 3y agoThis isn't related to secure boot or TPM/hardware-secrets-management. It's just an vulnerability[1] in some configurable[2] software running with privilege. This is downstream of the TPM keys for sure, and running validated blobs from the perspective of secure boot. 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
- amluto 3y ago> This is downstream of the TPM keys for sure 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.
- dist-epoch 3y agoEven bigger security flaws were found in OpenSSL, Firefox or the Linux kernel. Are they also security theater?
- halJordan 3y agoOf course they are. Openssl didnt prevent that malware from modifying a ufi driver so of course it's worthless.
- jeroenhd 3y agoNo, I think this shows that adding customisability features to please a small minority of users into low level components can be a huge security risk. Secure boot and TPMs aren't the problem here, the inclusion of user-configurable images and insecure image decoders is.
- sounds 3y agoSecure boot and TPM that only come with PCIe card drivers signed by the Microsoft CA are definitely the problem here. 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.
- jeroenhd 3y agoThere's nothing preventing you from installing your own CAs in normal decices. There are some ultra locked down devices (often made by Microsoft, or made extremely cheaply to low standards) and I think that practice should be banned. That's not the case in the laptops and PCs I've come across, though. 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.
- sounds 3y ago> There's nothing preventing you from installing your own CAs in normal decices [sic] 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.
- Lammy 3y agoEven worse: they’re security non-theater designed to protect “the computing environment” from you, the user.
- gruez 3y ago>Yet again we're shown that secure boot and TPMs are security theatre designed for DRM 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.
- cryptonector 3y agoTPMs can't make sure that there's no vulnerabilities. Are TPMs actually used for DRM?? Apparently not: https://news.ycombinator.com/item?id=25193346 https://news.ycombinator.com/item?id=25193346
- frankjr 3y ago> Yet again we're shown that secure boot and TPMs are security theatre designed for DRM and not to protect you, the user. I don't understand how this is not downvoted into oblivion. As others have already pointed out, this is absolute BS.
- alex7734 3y agoBS why? 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.
- frankjr 3y agoI have a Linux box set up with secure boot. I manage my own keys, I sign my UKI kernels. I use TPM2 for disk encryption in addition to requiring password. Where does DRM come into this? Where does Microsoft? I use neither. So no, secure boot and TPMs are not "designed for DRM and not to protect you, the user". The fact that some garbage companies have figured out how to use some of these features to harm consumers is another matter but so can millions of other things. Choose the companies you work with well, garbage gonna garbage.
- alex7734 3y agoLike I said, just take a look at Android. If you don't have an approved ROM you cannot use banking apps. Or Netflix. Or play most gacha games. 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.