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

81–90 of 111 posts

Re: TPM provides zero practical security

#81

Post by lxgr »

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 successfully achieved this

Do you have any references to back that statement up? Software-only DRMs are ultimately always either plain obfuscation or some variant of white-box cryptography, which is also anything but proven to actually work.

Re: TPM provides zero practical security

#82

Post by lxgr »

Nextgrid wrote: post #76
vetinari wrote: post #63

Earlier quoted context omitted.

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.

Do the DRM schemes interact with HDCP at the hardware level? I know HDCP is necessary, but my understanding has always been that the decrypted video data is always available to the OS (at the kernel level) and the "requirement" of it being outputted only to an HDCP-enabled sink was purely done in software through layers of obfuscation?

Higher-resolution ones definitely do. That's why you only get Widevine L3 on PCs and Macs, which most content providers limit to 720p or below.

You need something else (like Apple's FairPlay or Microsoft PlayReady) beyond that, and these definitely check your HDCP version. I believe 4k output commonly requires HDCP 2.2.

FairPlay on macOS might be based on obfuscation still (there was an interesting article on that here some days ago), but high-resolution playback on Windows definitely does involve the GPU driver somehow.

Re: TPM provides zero practical security

#83

Post by als0 »

osy wrote: post #40
helloooooooo wrote: post #17

Ask Google exactly how they enforce their zero trust, VPN-less remote work environment. Hint: it has to do with the TPM. DRTM + Device Certificates + TLS Token Binding is a huge deal for proving that the endpoint is trusted, and that the principal actually logging in is using an approved device. DRTM prevents boot time tampering by assuring that the measured boot state is consistent with what the network expects.

Yes, when implemented correctly (I've never seen Google's implementation so I can't comment), D-RTM + Secure Boot is good. If Microsoft would give us this before shoving TPM down our throats, it would be good :) But they haven't even fixed the weaknesses they identified on their own in 2006.

> D-RTM + Secure Boot is good. If Microsoft would give us this before shoving TPM down our throats, it would be good

D-RTM requires TPM.

Re: TPM provides zero practical security

#84

Post by als0 »

mixmastamyk wrote: post #73

Been wondering if I should enable these things in the firmware for several years, so the discussion is welcomed. I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?

Yes you can set up your LUKS to require both. Have a look at systemd-cryptenroll.

Re: TPM provides zero practical security

#85

Post by riedel »

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?

Why go pin less? I like the fact that the TPM can restrict retry counts and I do not need a rediculously long password.

The only thing I do not get is why this is not done by a simple SIM card like in any mobile phone. Then one could choose a TPM. Even more: I do not get why I cannot encrypt my android phone with my SIM card.

Re: TPM provides zero practical security

#86

Post by AnthonyMouse »

lxgr wrote: post #72
AnthonyMouse wrote: post #68

Earlier quoted context omitted.

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 th…

> Anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil. I don't agree that all trusted computing use cases are inherently user-hostile. DRM is a well-known example, but e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT, like secure contact matching or short PIN/password security stretching for account reco…

> e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT

Because this is the "snake oil" prong of its failure -- and why it's no longer trusted.

> Android Protected Confirmation

This could be implemented without any vendor keys. You associate the user's own key with the user's account.

> Attestation keys are usually per-device, so if indeed only one device gets compromised at great attacker expense, it's usually possible for a scheme to recover.

That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.

And once they extract a key from one device, they have a known working procedure to get more. For non-software extraction most of the expense is the equipment which they'd still have from the first one.

> If all devices just systematically leak their keys as has certainly happened in the past, that won't help, of course.

And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.

Re: TPM provides zero practical security

#87

Post by acdha »

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 install a custom boot loader the system is already defective by design.

Re: TPM provides zero practical security

#88

Post by EPWN3D »

Not a great take. The TPM provides the primitive of "non-extractable keys"; it's not supposed to magic up secure boot.

Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.

A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."

Re: TPM provides zero practical security

#89

Post by lxgr »

AnthonyMouse wrote: post #86
lxgr wrote: post #72

Earlier quoted context omitted.

> Anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil. I don't agree that all trusted computing use cases are inherently user-hostile. DRM is a well-known example, but e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT, like secure contact matching or short PIN/password security stretching for account reco…

> e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT Because this is the "snake oil" prong of its failure -- and why it's no longer trusted. > Android Protected Confirmation This could be implemented without any vendor keys. You associate the user's own key with the user's account. > Attestation keys are usually per-device, so if indeed only one device gets c…

> This could be implemented without any vendor keys. You associate the user's own key with the user's account.

But how would you bootstrap this? How do you make sure the initial key was actually created in the secure exceution environment and not created by MITM malware running on the main application processor?

If this was that easy, FIDO authenticators wouldn't need attestation either.

> That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.

If attacking a single device costs a few millions, it definitely does matter, since you'd need to expend that effort every single time (and you'd be racing against time, since the legitimate owner of the device can always report it as stolen and have it revoked for transaction confirmation, transfer their funds to another wallet etc.)

> And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.

How does some implementations falling apart imply all possible implementations being insecure? Smartcards are an application of trusted computing too, and there have been no successful breaches there to my knowledge. The fact that the manufacturers specialize in security, not in general-purpose computing like Intel and only occasionally dabble in security, probably helps.

Re: TPM provides zero practical security

#90

Post by xinayder »

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…

I might be a bit ignorant towards the topic but so far everything I've seen about TPM has no actual benefits for the home user. For cloud, sure, there are benefits.

It seems like it's a sunken cost fallacy that big tech spent a lot of money on and they are trying to get it back by convincing average Joe that a TPM is good for your PC.

Post reply on HN