Hacker News Reader

Comment by raxxorrax | Hacker News Reader

I don't really think TPM can offer me reasonable security. The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices. We see the same strategy on mobile phones.

So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.

https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_l...

We need tools to fake it, like we do in our jobs.

There are other ways, but also your device gets a unique identifier that you cannot change.

This is "security" done wrong as described in the textbook. This WILL be used as a DRM component.

View on HN

The TPM provides a number of useful functions but the use case upon which it was created was to act as a tamper-evident seal. We have such seals on all sorts of things in our lives: Food containers, shipping containers, etc.

The big difference between the TPM and something like a food seal is that the end user is the one that opens the food and knows that yes, "I did that myself; this is intended." Whereas with the TPM the only "user" with the right to break the seal is a 3rd party that has completely different--and often conflicting--interests to the end user (and owner of the device). If the end user/owner breaks the seal they're treated as an attacker. This is the big problem and the big bad thing that must not be allowed.

The entertainment/music industry (the only ones that actually want this) are looking for a guarantee that the end user has not modified the device that they own in order to play back their content. It's ridiculous.

It's not just ridiculous that they are seeking what is essentially a veto right over everyone's systems it's also ridiculous in that it assumes it'll actually be effective in any way, shape, or form.

There's a million and one ways to work around this kind of "protection" many of which are trivial (e.g. point a camera at the device). The industry knows this!

So then the question becomes: Why do it? The answer is simple: So they can be the gatekeepers for all devices sold and therefore be able to veto in essence any devices the don't like. They may even be able to extract a tidy profit from those who require certification.

The whole notion is anti-consumer and just generally a really bad idea from the perspective of technological progress and innovation. Content owners should not have any say whatsoever in how general purpose devices are made or used. They should conform to the market; not the other way around.

>They should conform to the market; not the other way around.

But they are. It's just that the vast majority of the market are indifferent so it gets accepted.

That's not conforming to the market, that's doing what you want because people are indifferent.

Conforming to the market would be to not add something that nobody wants.

Approximately 0 companies have used a TPM for DRM even though they have been put in PCs for 15 years now.

At the same time, boot sector attacks have become prevalent, which TPMs can protect from.

The net effect is the paranoid "never use anything that might possibly one day might be used for DRM" folks have made practical computer security worse by threatening anyone that adds TPM functionality into their product.

Good job.

Normally full disk encryption and booting security is the province of your OS. To my recollection both Bitlocker and LUKS can optionally use the TPM which means it can be used for 100% of the use cases which would improve computer security.

What are we missing out on exactly?

TPM isn't active on many private devices, so the ability to abuse its capability was more or less impossible. That would come after it is firmly established.

What we do know thought is the software landscape of devices that are indeed locked down mostly to the benefit of the manufacturers. Turns out the uniformity of that software landscape didn't stop NSO from silently taking over phones. Different threat scenario, but I think the pattern is clear.

I think we need a closer examination on how often private devices are affected by firmware attacks or messing with boot. As far as I know they have become quite rare. Perhaps I need to shift my paranoia there, but I am not convinced.

But these questions are irrelevant if TPM stays optional. A lot of IT security comes down to trust problems, so I fail to see why possible disadvantages shouldn't be examined.

As far as I know I could activate TPM right now, so I also fail to see how "folks" hold practical security back. Weighting security mechanisms is also an essential step. I am just not convinced it does improve my practical security, while maybe it proves detrimental to general computing.

> even though they have been put in PCs for 15 years now.

i have never seen a consumer motherboard with a TPM device in the last 15 years. In fact, the last batch of enthusiast AM4 ones ("pro" model), the TPM doesn't even have the Header populated, only the holes for one that you can solder a header.

And non-workstation office machines from hp and dell ship weird ones that probably won't even pass the win11 test.

Why is that? It is because the TPM failed in the consumer market. Why is that?

One reason is the constant stream of FUD from the anti-DRM folks.

> the constant stream of FUD from the anti-DRM folks.

Yes? Fear, uncertainty and doubt is the correct attitude toward TPMs. (Assuming you count "We know it's going to hurt us, just not how long it will take to happen." as "doubt".)

> FUD

https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

You think all those FIDO members don't care about DRM. That is beyond naive in my opinion. Security is a trust problem, so much should be clear before even starting to discuss it.

Also FUD is employed by presenting advantages of TPM as it often invokes ransomware.

Nice, but probably 99% of ransomware is just executed in user space and starts encrypting typical network drives in typical corporations. Some are more sophisticated, but I haven't seen any bios attacks recently. And why would they? Ransomware is quite profitable.

TPM is typically implemented in firmware for consumer boards. Having the option to upgrade to a hardware TPM module is nice, but probably not necessary for the vast majority of users. Hardware TPMs also come with their own sustainability questions regarding bugs/upgrades and how/if that process works. This is hard to do without compromising the benefits of using a physically separate TPM unless the end-user takes some form of responsibility in the custodianship themselves (which is not likely at the consumer level).

Considering that the vast majority of boards aren't going to need the header, the board manufacturers can scale cost reduced versions for the masses and spin versions with a couple more headers for a couple more dollars for the fringe users that want them (pre-)populated. Seems like a rational business decision?

> Whereas with the TPM the only "user" with the right to break the seal is a 3rd party that has completely different--and often conflicting--interests to the end user (and owner of the device).

This is completely false, and is in fact contradicted by the Lenovo PDF that we're discussing.

>I don't really think TPM can offer me reasonable security

>So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.

The main security benefits to me are for full-disk encryption:

1. it ensures the bootloader isn't compromised so I know I'm not giving my FDE encryption keys to a bootkit

2. I can use a simpler/more memorable password because entry attempts have to go through the TPM, rather than being able to be bruteforced with a GPU cluster.

I'm not sure how what the "other methods" for accomplishing these are.

>The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices. We see the same strategy on mobile phones.

>This WILL be used as a DRM component.

Resisting TPM isn't really going to change much. All the major CPUs produced today (intel, amd, most ARM vendors) all have trusted execution environments, which does everything a TPM can do and more. They're also already required for many DRM schemes (eg. intel SGX for watching netflix 4k, arm trustzone for widevine L1).

> 2. I can use a simpler/more memorable password because entry attempts have to go through the TPM, rather than being able to be bruteforced with a GPU cluster.

this is already the case with every single open source encryption model out there. You have a simple password which then encodes the true key.

Nothing will save you from GPU cluster brute forcing it, if the adversary have your harddrive.

> Nothing will save you from GPU cluster brute forcing it, if the adversary have your harddrive.

Not really true.

In the case where a password is used to derive the encryption key, the password is passed to a key derivation function which deterministically generates the key of the appropriate length. Ideally, the KDF should be computationally difficult to slow down brute force attempts, but you can still parallelize the attack with a big GPU/FPGA cluster. If the password is sufficiently weak, you can often get a break this way.

In the case of using a TPM for full disk encryption, the key is generated by the module itself and requires a password to unlock. This is rate-limited by hardware, and typically the TPM will lock itself out if you have entered the incorrect password too many times. If you steal the hard drive, you can't decrypt it even if you know the password (the password unlocks the TPM and has nothing to do with key generation). Likewise, if you steal the whole machine but don't have the password, you'll be hard-pressed to brute force it since the rate-limiting / lockout features mean you can't make lots of parallel tries. Your GPU cluster is an expensive paperweight in this case.

In theory, the only reliable way to decrypt a device using full-disk encryption and a TPM without the password is to try extracting the secrets from the TPM itself. This isn't impossible, but they are specifically built to resist key-extraction attacks. You're pretty much talking about an attacker with state-level resources in that case, or at the very least a very determined group of private sector professionals.

for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.

well, this might be true if you use some NIST or RSA certified process :) but who cares about that other than bureaucrats who run entire cities with one set of master keys anyway.

> This is rate-limited by hardware

See this is the kinda of thing those bureaucrats would say. If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.

> for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.

You're not bruteforcing the derived key (ie. the value from the KDF), you're running a wordlist against the KDF and seeing which values work.

>If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.

The difference is that with a TPM, you can't run a wordlist attack, since password attempts have to go through the TPM, and it throttles your guessing attempts. Without a TPM you can run the KDF as fast as you want, across as many machines as you want.

put down the intel certification pamphlets and go find a single key encryption where those two things are true.

> The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices.

This sort of thing is why I consider TPM harmful and avoid machines that include it to the best of my ability.

Since avoiding it becomes less tenable as time goes by, I'm starting to consider methods that could block access to it instead.

Also, a TPM does not protect you from rubberhose key extraction. There is, however, a file system that can give you some modicum of protection against that, the Rubberhose File System[1][2], created by Julian Assange in the 1990s. It comes with a description that is worth looking up and read.

[1] This appears to be a copy https://github.com/sporkexec/rubberhose [2] A partial archive.org copy https://web.archive.org/web/20010819035021/http://www.marutu...

Edit: add URLs

Which apps refuse to run in the absence of a TPM, please?

Windows 11 maybe?

Of course you would see the effects once it is established. Since it was rejected for the most part, this mechanism cannot work.

You can deny these fears all you want, but TPM is not for you, the security benefits are negligible. Perhaps put it on your server, but I don't see the necessity either.

https://secret.club/2021/06/28/windows11-tpms.html

I don't think anyone can make reasonable argument against the problems put on the table here.

You can also look up the FIDO group. While they are important to strengthen and develop encryption, there is a reason for its corporate sponsors aside user security. The user is a hostile entity in TPM security schemes.

Ok I walked into that one. ;)

I was thinking more in terms of user applications. Bit having read your link I confess I had no idea about the seldom talked about endorsement keys.

On the one hand this will allow my IT department to completelyoxk down all out end user devices such that they cannot access any of our services if the device has been compromised. But the price well pay is that Disney will refuse to let me play video on my own device, and I expect sooner or later PunkBuster and so on wont even let me join a game server on such a device...

The future looks pretty bleak.

Reply on news.ycombinator.com