13 ms·
TPM chips are not opensource, end user cannot simply check them for backdoors. Manufacturers of these chips are under heavy scrutiny of intelligence agencies. G
by harvie 3y ago
TPM chips are not opensource, end user cannot simply check them for backdoors. Manufacturers of these chips are under heavy scrutiny of intelligence agencies. Governments around the world try their best to prevent people from using strong cryptography (eg. limiting effective key lengths in various ways).
Why should we trust such chips more than purely software based approach?
- _8j50 3y agoBecause it isn't a silver bullet but rather a countermeasure against rootkits, bootkits and certain physical tampering by regular and insider threat actors.
- isilofi 3y agoWe shouldn't. TPM-based security is only sufficient against unsophisticated attackers such as a common thief stealing your laptop from your backpack.
- jon-wood 3y agoThis is a massive overstatement of the situation. Sure, a TPM might not protect you against the NSA or the Chinese government stealing your computer. If configured correctly it probably will protect you against anything less than a major nation state stealing your computer.
- justaj 3y agoBut wouldn't a properly configured LUKS encryption protect against nation-state threats too? If so, then why still use TPM?
- lostmsu 3y agoIf machine is not attached to a terminal it is useful if it boots on its own.
- immibis 3y agoThen it still boots on its own if the bad guy has it.
- alufers 3y agoConvenience, faster boot. Or if you have a headless server with disk encryption, but you want it to come back online without intervention after a reboot or power failure. It's all trade-offs.
- SV_BubbleTime 3y agoIn the scenario of headless, if I’m not missing something this only prevents drives from walking off. If the whole machine walks off you are in just as much trouble as not being encrypted at all if you don’t really trust your OS permissions systems?
- Nextgrid 3y agoThe whole machine walking off is more detectable though. You can use TPM as one factor (among many, such as the presence of the machine on the expected network and no unexpected downtimes) to obtain storage keys from a separate trusted server, using TPM remote attestation to assert the machine hasn't been tampered with in-place (by merely booting it off a compromised OS). The separate authentication server can be configured to only hand out the storage encryption key on expected reboots, so if the machine unexpectedly walks off and then powers back on that server would refuse to hand out the key, thus the stolen machine is now useless.
- Asmod4n 3y agoWhen someone steals your device and try’s to guess a user password a tpm can just throw away it's keys. (Or something similar) Try it on a secure boot and tpm2 enabled Bitlocker encrypted drive, the only way to get in is via the recovery key after a configurable number of attempts.
- alufers 3y agoIf you take some basic precautions - disable interrupting the boot process, serial console, etc. then bypassing that requires significant effort. As an attacker you need to know the versions of the software working on the server, know some exploit and then have the experise to use it. For example I know that the police in my country use off the shelf disk cloning devices and then some basic forensics software for analyzing the disk image. This can be done by an average computer technician, and such a TPM scheme would totally prevent them from extracting data. Of course for bigger cases they can invest some more effort, but they would have to be sure that there is some important data there to justify the cost.
- jon-wood 3y agoTPM based encryption is hugely useful in embedded devices, where you really don’t want to have to despatch someone to type the passphrase in. By driving it via the TPM you’re protected against someone removing the storage and being able to read the decryption key off it, and you’re also protected against someone modifying the components required to get to a decrypted disk to inject code you weren’t expecting - if the kernel or bootloader is modified then the device simply won’t boot.
- pmontra 3y agoWith an embedded device isn't easier to just steal the device instead of only the storage and making the device useless anyway?
- bmicraft 3y agoIn this scenario protecting the secrets on the device is supposedly more important that the monetary value of the device itself.
- SV_BubbleTime 3y agoI sell a device. There are lots of them in hands. You still aren’t getting my device key off of it. Yes, you can use that device all you like, but you aren’t going to clone it and make more.
- sillystuff 3y agoYou've described DRM; this is exactly why a lot of people are wary of TPMs.
- lxgr 3y agoNo, DRM is safeguarding other people's keys on your device. There's more applications of trusted computing and TPMs than that; one of them is using it to safeguard your own keys.
- cyberax 3y agoYes, but you'll need to enter a long password on every boot.
- goodpoint 3y agoNo, it's worse. It's *making* you vulnerable to those actors and possibly more.
- Nextgrid 3y agoThe majority of people don't want to type a long passphrase every boot (or would pick a trivially-bruteforceable one) and FDE-backed TPM (even if vulnerable to state-sponsored attacks) is better than what it would otherwise be which is no FDE at all.
- mjg59 3y agoEh no that's not true. If a device uses a discrete TPM and isn't using authenticated sessions it's trivial to sniff the bus and extract the encryption key. If it is then it's less trivial because you need to interpose the TPM but that's still in "Can solder SMT parts" territory, not major nation state.
- Bognar 3y agoYou can only extract the encryption key if using the unencrypted APIs. You can establish and require an encrypted channel with the TPM if you know which TPM you are expecting.
- goodpoint 3y agoNot even that.
- mratsim 3y agoThe real question is "What's your threat model?" If it's people stealing your laptop and fear of identity theft, use the TPM. If it's the NSA, ¯\_(ツ)_/¯
- cobertos 3y agoLUKS or eCryptfs work perfectly fine for the "stealing your laptop" use case, and are purely software implementations. There's a poster below that provides a more reasonable use case for TPM. Headless server where asking for password on boot is undesirable (eg after a power failure)
- Nextgrid 3y agoOnly problem of software implementations is that they are reliant on the strength of the user-supplied passphrase, so there's a inverse correlation between user experience (ease of typing the passphrase) and security (easy passphrases are also easy to bruteforce). A TPM provides hardware-backed bruteforce protection which means even an easy passphrase can be made secure as the number of attempts is rate-limited by the TPM (to a level much slower than even the hardest hashes).
- immibis 3y agoThen you want your own optional TPM that you trust - such as a YubiKey.
- mjg59 3y agoWhy is a Yubikey more trustworthy? You don't have the source code, you don't have the hardware design. In addition, a Yubikey is given no information about the system boot state, so is in no position to identify that the system has been tampered with.
- immibis 3y agoIt's just one example. Use a different one if you want. People tend to trust them more because they belong to them, not Microsoft, or Hollywood, or the board manufacturer.
- dist-epoch 3y agoBecause the alternative, not using SecureBoot, is strictly worse in all scenarios. Just like HTTP vs HTTPS with LetsEncrypt. Even if an attacker can compromise a web-server rendering HTTPS protection useless, it's still better to always use HTTPS.
- immibis 3y agoYou're framing this as a choice between SecureBoot and InsecureBoot, but it's actually a choice between SecureBoot and DRM, or InsecureBoot and no DRM. Besides, SecureBoot isn't strictly better in all scenarios. The most obvious one is the one where you forgot how to log in, and want to retrieve your data.
- lxgr 3y ago> [...] where you forgot how to log in, and want to retrieve your data. That's a use case typically better addressed with good backups, since there are indeed more failure modes when using effective full disk encryption.
- dist-epoch 3y ago> choice between SecureBoot and DRM, or InsecureBoot and no DRM. That's just false. I've had SecureBoot enabled for 10 years and I didn't have more DRM because of this. You're talking hypotheticals, slippery slope, etc... > The most obvious one is the one where you forgot how to log in SecureBoot is separate and does not imply full disk encryption. If you choose to use full disk encryption, yes, you can be locked out, with SecureBoot or not.
- immibis 3y ago> I've had SecureBoot enabled for 10 years and I didn't have more DRM because of this. Maybe stop pretending to understand what the parent comment is talking about. > SecureBoot is separate and does not imply full disk encryption. If you choose to use full disk encryption, yes, you can be locked out, SecureBoot or not. There's no purpose to Secure Boot if I can just put your hard drive in a different computer without Secure Boot.
- fsflover 3y ago> TPM chips are not opensource I'm using Librem 14 with a TPM chip with exclusively free software.
- zlg_codes 3y agoSlight segue, have you had any luck with distros besides PureOS? I want to make my own LFS for my Librem but I'm not sure what my custom system would need to support the EC firmware and pureboot, etc.
- fsflover 3y agoI'm using Qubes OS. AFAIK Pureboot should work fine with any distro, but I don't know the details. There are also EC firmware installation instructions for Qubes on their forums.
- zlg_codes 3y agoI've considered that one as well, especially once I upgrade to 64GB of RAM. Aside from hardware-accelerated needs like streaming, gaming, browsing, etc, I could do most of my software experimentation inside VMs and keep my system clean(ish). How has your experience been with Qubes?
- fsflover 3y agoI'm very happy with Qubes OS, using it as a daily driver for many years. It does indeed helps to organize your digital life and gives a great sense of security and control over your computer. I tried to list its advantages here: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 See also: https://forum.qubes-os.org/t/qubesos-4-2-rc3-clean-install-issue-on-librem-14/21051/5 https://forum.qubes-os.org/t/qubesos-4-2-rc3-clean-install-i...
- cedws 3y agoThis feature isn't really for people like you and me. It's for big companies like Red Hat and Google to utilise on their servers. Google have their own TPMs they can trust. Red Hat probably have the paperwork to say their TPMs are safe. But worrying about your TPM being backdoored is pointless anyway. If they can backdoor your TPM, they can backdoor anything.
- immibis 3y ago> If they can backdoor your TPM, they can backdoor anything. [citation needed]
- cedws 3y agoThere are hundreds of components in a computer and the TPM would be one of the hardest to backdoor. Bear in mind where this stuff is manufactured. The manufacturer would want nothing to do with funny business like this because it could harm their sales, so it would have to be done under their nose, or they would have to be compelled by the government. US intelligence agencies don't generally go around mass backdooring things. It's too risky. They carefully target their attacks.
- immibis 3y agoIt's... extremely easy for the government to compel mass backdoors in TPMs. Don't you remember Clipper? And the backdoor would be completely invisible until they used it, since TPMs aren't auditable.
- kenjackson 3y agoBut it’s easy for governments to compel backdoors into any component. Even open source for non trivial code is easy to introduce obscure bugs that are exploitable.
- immibis 3y agoThe backdoor in most components is really complicated. Backdooring a TPM is relatively easy, and undetectable.
- mjg59 3y agoHow would an end user simply check them for backdoors if they were open source? Security auditing is a skilled job, and the people best capable of identifying security flaws or backdoors are generally able to do that given a binary blob as well.
- JohnFen 3y agoI dislike TPM personally (for a very different reason), but... They reduce the attack surface. Not only in terms of the actual interface, but in terms of who has the ability to subvert the security. Using TPM may or may not be effective security against governments, manufacturers, and the like, but they are effective security against a whole host of other bad actors. It could be argued that's still a worthwhile improvement. You can engage in other layers of security regardless of whether TPM is being used to help cover the areas TPM may not.
- immibis 3y agoThey're dangerous because the same effective security can be turned against the legitimate owner of the machine. The TPM effectively belongs to whoever configured it first.
- JohnFen 3y agoTPM just stores crypto keys. It does so in a way that the user can't get them, which is my objection to the scheme (because it lets entities set up encrypted channels that I can't monitor). However, that's the only way it can be turned against the user, and the other user security gains are real.
- o11c 3y agoTPMs are also highly effective against "you can just use a LiveCD to try Linux temporarily, then reboot and return to Windows."
- azzentys 3y agoI'm curious if open source TPM would mean easier side-channel attacks. What's the reason everyone is super hush-hush around how their Hardware Security works?
- chlorion 3y agoThis is very important. For some reason in these threads nobody seems to bring up or realize that modern AMD CPU's fTPM is completely broken and not fixable via ucode updates. The AMD TPM exploit is exploitable by a "regular" person too, it doesn't have to be a state level actor, just some techy person with a few tools and physical access to the system. We can't audit these things at all and I don't think we should just trust that they are safe, and we know for a fact that many of them aren't safe, even against "regular" threats. (AMD fTPM exploit source) https://arxiv.org/abs/2304.14717 https://arxiv.org/abs/2304.14717
- mkopec 3y agoDropping a link to a project attempting to create a fully open source TPM: https://twpm.dasharo.com/ https://twpm.dasharo.com/
- fsflover 3y agoHow does it compare with Pureboot with Librem Key?
- sweetjuly 3y agoNo ASIC is ever going to satisfy your desire to audit. Even if they publish the RTL, you can't verify that this is what they synthesized, that this is what the fab actually produced, etc. You have to trust hardware because it's your everything. Even with relatively obvious attacks like backdooring the bootrom (which can be done by modifying just the metal layers!), practically speaking no one is going to ever catch it because modern processes are simply too fine for all but the fabs themselves to physically inspect. This isn't even to mention more clever attacks which attack the doping of the silicon [1] for individual transistors (which cannot be generically detected post fabrication by any publicly known technique). Embrace the suck :) Sure, you can't truly trust hardware, but there's nothing to be done about it anyhow and so you may as well reap the benefits of trusting it. [1] http://sharps.org/wp-content/uploads/BECKER-CHES.pdf http://sharps.org/wp-content/uploads/BECKER-CHES.pdf
- JohnFen 3y ago> there's nothing to be done about it anyhow and so you may as well reap the benefits of trusting it. Alternatively, you can avoid relying on any single thing to be secure and use layered security approaches instead.
- AlotOfReading 3y agoThere is no layered security approach that can fully mitigate malicious hardware. Even if you have a perfect cryptosystem where everything is running fully homomorphic encryption so that plaintext literally doesn't exist, you're still susceptible at the boundaries and to metadata leakages. On real computers you're also susceptible to the hardware simply not executing your code properly and a hundred other things. Since you can't fully mitigate malicious hardware, you have to state a more limited threat model for there to be any useful discussion.
- sweetjuly 3y agoWhat security boundary can you hope to hold if the CPU is running malicious code straight out of reset (such as through a bootrom implant)? No amount of layers and defense in depth can paper over the fact that your hardware is physically compromised. It's the whole trusting-trust thing. We don't really have a way to solve it, so it's best not to burn yourself out on it.
- spicymaki 3y agoSome TPMs are FIPS-140 compliant and go through 3rd party audits and extra screening. If you purchase a device that is compliant you can then retrieve a certificate of compliance. Some TPMs can be made compliant with the appropriate firmware update. If you don't trust FIPS then you could support open source TPMs and help audit them. Other than that if you care enough about it and had the prerequisite skills and money, you could develop your own TPM (the interface specifications are online) and run your own trusted and audited Linux system.