TPM isn’t about security, it’s about DRM
No, TPM can be about both – and more.
In theory, yes. In practice, TCBs are so big, that DRM solutions based on it are nearly meaningless for general purpose computers.
TPM provides zero practical security
91–100 of 111 posts
Re: TPM provides zero practical security
#92Earlier quoted context omitted.
> 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…
> 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?
The device comes with no keys in it, but includes firmware that will generate a new key, put it in the HSM and provide the corresponding public key. The public key is authenticated to the service using whatever means is used to authenticate the user rather than the device, because what you're doing here is assigning the key in this device to this user, so it's the user and not the device you need to authenticate.
But now if the user wants to they can use a different kind of device.
> If this was that easy, FIDO authenticators wouldn't need attestation either.
They shouldn't.
> 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.)
You're talking about the HSM case where the user's own key is in the device and you need to break that specific device. In that case you don't need to prove that the device is a specific kind of device from a specific manufacturer (remote attestation), you need to prove that it is that user's device regardless of what kind it is (user's key in the HSM).
> How does some implementations falling apart imply all possible implementations being insecure?
Because for remote attestation the attacker can choose which device they use for the attack, so if there is any insecure implementation the attacker can use that one.
And if you deploy a system relying on it and then a vulnerability is discovered in millions of devices you're screwed, because you now have a security hole you can't close or you have to permanently disable all of those devices and have millions of angry users. But this is historically what has happened, so relying on it not happening again is foolish.
> Smartcards are an application of trusted computing too, and there have been no successful breaches there to my knowledge.
Smartcards don't require any kind of a third party central authority. You know this is Bob's card because Bob was standing there holding it in his hand while you scanned it and assigned it to Bob in the system. Bob could have made his own card and generated his own key and it works just as well. It's a completely different thing than remote attestation.
Re: TPM provides zero practical security
#93Earlier quoted context omitted.
An attacker still needs to use some kind of semi-advanced attack in the boot chain or DMA to steal the user's data, instead of just plugging in a LiveUSB and going to town. Yes, there are a lot of vulnerabilities in the Secure Boot process on most devices, because the surface area is huge, but the attacker still needs _some sort_ of vulnerability to gain a foothold. I agree with the frustration in the gist - Secure B…
For the typical user, losing their data is a greater risk than someone with physical control over their machine being able to access it. The logic board in your computer fails or you forget your password and all your data is gone . And the default way of mitigating it is an even worse security risk. Now all your data is on some cloud somewhere, waiting for that vendor to get breached or your account to get phished wh…
If your data is this valuable, you certainly do backups? I suppose something like cloud backups is now built-in into windows, and would save your Documents (and maybe more) also by default.
Re: TPM provides zero practical security
#94Unfortunately 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…
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.
A core argument the post makes is that TPMs are insufficient for verifying full stack integrity and thus ineffective for FDE. (Eg by exploiting vulnerable drivers, an attacker can dump the disk encryption key from kernel memory.)
But in such a scenario, an attacker can also use such an attack to bypass any remote attestation/DRM/etc!
I guess you could argue that such attacks are too much work for consumers, and that low fences control big dumb animals…but I think, fundamentally, the same argument applies to consumer security functions like FDE!
Tl;dr: I think it’s hard to argue that TPMs are both useless for practical user security and a threat to free computing. It’s gotta be one or the other!
Re: TPM provides zero practical security
#95Unfortunately 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.
Home users take their PC to airports, hostels and cafes. Criminals who break into homes steal laptops. Of course there are benefits.
Re: TPM provides zero practical security
#96I don't agree with this. Yes, any TPM is necessarily possible to bypass, but it's not easy. I know I could bypass normal password-based FDE with physical access to a machine without any special hardware or software, but not TPM-based. I assume, by the Pareto principle, that there are lots of people with my ability but exponentially fewer who could bypass a TPM. So it's definitely more secure than password-based FDE,…
>I know I could bypass normal password-based FDE with physical access to a machine without any special hardware or software How?
Change the bootloader and /bin/init so that it captures the disk encryption password as you enter it. It could then send it to me, or add a second password that I know so that I can decrypt it with later physical access.
Actually, on second thought, it's secure boot that protects against this attack, which doesn't require or use a TPM? So maybe I'm wrong
Re: TPM provides zero practical security
#97Earlier quoted context omitted.
For the typical user, losing their data is a greater risk than someone with physical control over their machine being able to access it. The logic board in your computer fails or you forget your password and all your data is gone . And the default way of mitigating it is an even worse security risk. Now all your data is on some cloud somewhere, waiting for that vendor to get breached or your account to get phished wh…
If your data is this valuable, you certainly do backups? I suppose something like cloud backups is now built-in into windows, and would save your Documents (and maybe more) also by default.
Windows backups are subpoenable by half the governments on the planet, who have bad actors in them, and may also have exploits for dedicated attackers because they present a huge target.
Re: TPM provides zero practical security
#98Earlier quoted context omitted.
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.
The bit about "two touches" seems to imply physical access, so in absence of TPM the attacker can replace your bootloader with little effort vs with TPM they'd need to break TPM.
Re: TPM provides zero practical security
#99Earlier quoted context omitted.
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.
I have many machines, some headless.
Re: TPM provides zero practical security
#100Zero is a stretch. I think they have largely failed to serve their purpose in the consumer device realm, beyond decent integration with BitLocker. Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
I feel like BitLocker is a great feature. So great it's one of the few things keeping me on Windows. Would not call it "largely failed".