Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TPM provides zero practical security

gist.github.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: TPM provides zero practical security

#61

Post by sudosysgen »

notquiteright wrote: post #39
vlovich123 wrote: post #31

Earlier quoted context omitted.

I prefer to require entering a master password on boot manually and then configuring the OS to auto login to my non root user (with a different password than the disk). The longer and more complex your dependency chain for security, the more opportunity for it to be compromised. The encrypted “password on boot” partition then contains the keys to mount the other disks. I’d really like Apple’s model on my machine wher…

Using a decryption password on boot is less secure than TPM + measured boot/secure boot. Specifically, it’s vulnerable to a two-touch attack. In the first touch, the attacker replaces your bootloader with one that looks identical but steals your password. On the second touch, they now use the password to steal your data.

If the attacker can replace your bootloader, why can't they just get the decryption key from the kernel later? And if you did have Secure Boot, then using a password with encryption at rest is just as secure : you can't change the bootloader and you can't change the OS (since it's encrypted), so you can't exfiltrate the password. The end result is that the TPM doesn't have a practical benefit.

Re: TPM provides zero practical security

#62

Post by vlovich123 »

notquiteright wrote: post #39
vlovich123 wrote: post #31

Earlier quoted context omitted.

I prefer to require entering a master password on boot manually and then configuring the OS to auto login to my non root user (with a different password than the disk). The longer and more complex your dependency chain for security, the more opportunity for it to be compromised. The encrypted “password on boot” partition then contains the keys to mount the other disks. I’d really like Apple’s model on my machine wher…

Using a decryption password on boot is less secure than TPM + measured boot/secure boot. Specifically, it’s vulnerable to a two-touch attack. In the first touch, the attacker replaces your bootloader with one that looks identical but steals your password. On the second touch, they now use the password to steal your data.

You would still use the TPM to verify the software chain. But don’t use the TPM to Auto unlock disks. That’s the part that feels like a bad idea

Re: TPM provides zero practical security

#63

Post by vetinari »

Nextgrid wrote: post #28
hooverd wrote: post #24

Earlier quoted context omitted.

While that's a very good use case, the desired one where you're not allowed to use the Internet unless you're using a big three approved device that can attest you're not using an ad blocker isn't so much.

> he desired one where you're not allowed to use the Internet unless you're using a big three approved device that can attest you're not using an ad blocker isn't so much. There's no reason to believe this will require a TPM or depend on the presence of one. As far as I know, Widewine and similar DRM schemes successfully achieved this without any hardware assistance. Yes, bypasses exist and all the major piracy group…

Widewine and similar DRM schemes pretty much require hardware assistance; the lower levels that do not will provide you with 720p, which is exactly what you are getting in Linux. For 4k, it requires tee application, or similar mechanism that's not in the reach of mere mortals.

The early bypass of widewine meant burning an nvidia shield (invalidating its keys) for each and every single rip.

Re: TPM provides zero practical security

#64

Post by lxgr »

sudosysgen wrote: post #60
lxgr wrote: post #56

Earlier quoted context omitted.

Are you sure Widevine uses the attestation functionalities of a TPM on Windows? I thought Widevine on computers (whether Windows, macOS or Linux) is always L3, i.e. software only, and L1 needs a TEE on Android or an embedded OS such as on a set top box or streaming dongle.

Indeed, it doesn't use it on Windows. Widevine L2 however uses the TEE in exactly the same way as a TPM is used, for attestation and for cryptography (you can do AES decryption using a TPM).

A TPM isn't the same thing as a TEE at all. You can't run copy protection logic in a TPM, for example. The two are complementary, though:

A TEE can run "trusted" logic, such as DRM decryption code, and you can use a TPM-like device to hold the attestation keys and measurement funcitonalities for the TEE. I'm saying "TPM-like" because some TEEs have their own proprietary or embedded secure elements and don't need a TPM proper. (I'm actually not sure if TPMs are "TEE-aware", which would be required to e.g. only let some keys be used from the secure context, as otherwise storing DRM keys in the generally-accessible portion defeats the purpose.)

Without a TEE (and a TPM itself does not imply one on x86), what you can do is declare your entire system a TEE, and then use the TPMs measurements as an assertion over that system's untampered state.

This is pretty infeasible to do securely though, given the size of the codebase of most OSes, which is why the "DRM in TEE" approach is much more common. That's what Android does, for example.

Re: TPM provides zero practical security

#65

Post by mixmastamyk »

Nextgrid wrote: post #12

Unfortunately this sounds like a typical pro-Linux rant with the usual scare words such as "Microsoft", "UEFI", "secure boot", etc. To be clear, I am attacking the piece itself, not the author. The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend o…

This "middle-brow dismissal" should be downvoted and flagged on the first sentence alone. Not be the top comment.

The datacenter use case sounds useful—should have led with that.

Re: TPM provides zero practical security

#66

Post by lxgr »

candiddevmike wrote: post #18
Nextgrid wrote: post #12

Unfortunately this sounds like a typical pro-Linux rant with the usual scare words such as "Microsoft", "UEFI", "secure boot", etc. To be clear, I am attacking the piece itself, not the author. The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend o…

What's the point of TPM-backed full disk encryption with no usability impact (meaning password/pin-less) for the average user who is more likely to get their device stolen vs some covert disk image shenanigan?

You can store the full disk encryption key in the TPM and rate-limit PIN attempts using its secure non-volatile storage, as far as I know. That's very useful in case of loss/theft, given that users don't like typing long passwords or PINs for every login.

I'm not sure if this is what Windows actually does, though, or if the TPM just hands over the disk encryption key after Windows passes system attestation and then verifies the screen unlock PIN/password in software – that would be significantly less secure.

Re: TPM provides zero practical security

#67

Post by lxgr »

alerighi wrote: post #42
Nextgrid wrote: post #12

Unfortunately this sounds like a typical pro-Linux rant with the usual scare words such as "Microsoft", "UEFI", "secure boot", etc. To be clear, I am attacking the piece itself, not the author. The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend o…

There are two issues. One is a false sense of security. You think that you have the same level of security of a full disk encryption, but you don't. On a full disk encryption only who knows the password can access your data. On this system the disk is automatically decrypted at boot, so any flaw in Windows that permits a privilege escalation done by that PC can give access to your data. If somebody that wants your da…

> But wait, you say Microsoft tought about that, indeed if you signed in with a Microsoft account you can recover your Bitlocker encryption key from the Microsoft portal... wait what?

Can't you alternatively also export a copy of the actual disk encryption key and write that on a piece of paper? The last time I used Windows, that was possible, at least (but I think I didn't use the TPM back then).

On macOS, you can do either, for example, and it uses a similar construction (although using Apple's proprietary secure element and hardware encryption engine rather than a TPM and secure boot).

Re: TPM provides zero practical security

#68

Post by AnthonyMouse »

lxgr wrote: post #51
osy wrote: post #36

Earlier quoted context omitted.

This is not the way TPMs are used by most of the industry. For example, Microsoft and now Canonical are advertising it as a way to do FDE which Microsoft has known to be broken since 2006. They are requiring it for Windows 11 because of "security" and have provided no software feature on Windows for this kind of use case. It is only done by the OSS community. > The other useful application is to prevent block device…

> This is not the way TPMs are used by most of the industry. [...] It is only done by the OSS community. So some industry stakeholders are doing bad things with an inherently neutral technology. Does that mean we need to get rid of the entire thing, thereby also killing the OSS use cases? Yes, trusted computing can be used in user-hostile ways, but the solution here seems to be to not use OSes and applications using…

The trouble is we keep conflating two different things.

Something that works like a hardware security module, where it stores your keys and tries to restrict who can access them, has some potential uses. The keys are only in your own device, so someone can't break an entirely different device or a centralized single point of failure to get access. And this can't be used against the user because both the device and the key itself are still fully in their control -- they could put a key in the HSM and still have a copy of it somewhere else to use however they like.

Whereas anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil. Malicious because it causes the user's device to defect against them and some users aren't sophisticated enough to understand this or bypass it even if malicious attackers can, and snake oil because you can't rely on something for actual security if a break of any device by anyone anywhere could forge attestations, since that is extremely likely to happen and has a long history of doing so.

Re: TPM provides zero practical security

#69

Post by tredre3 »

sudosysgen wrote: post #50
etna_ramequin wrote: post #30

Earlier quoted context omitted.

I’ve seen many widely deployed applications of TPM for security, never for DRM.

You've never used Widevine? If you ever tried to use a streaming website, you almost certainly did. EDIT: To clarify, Widevine doesn't actually use the TPM, but Widevine L2 uses a TEE for key exchange and decryption, which are all things that modern TPMs support. The use a crypto coprocessor for key exchange and decryption is widely used.

Please stop spreading FUD.

Re: TPM provides zero practical security

#70

Post by hooverd »

Nextgrid wrote: post #28
hooverd wrote: post #24

Earlier quoted context omitted.

While that's a very good use case, the desired one where you're not allowed to use the Internet unless you're using a big three approved device that can attest you're not using an ad blocker isn't so much.

> he desired one where you're not allowed to use the Internet unless you're using a big three approved device that can attest you're not using an ad blocker isn't so much. There's no reason to believe this will require a TPM or depend on the presence of one. As far as I know, Widewine and similar DRM schemes successfully achieved this without any hardware assistance. Yes, bypasses exist and all the major piracy group…

Touche, not a TPM, those are usually separate hardware whereas TEEs are integrated.
Post reply on HN