4 ms·
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
by raxxorrax 5y ago
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_lavina_jayesh/CS259_report_lavina_jayesh.pdf 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.
- gruez 5y ago>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).
- ajklsdhfniuwehf 5y ago> 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.
- Sanzig 5y ago> 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.
- ajklsdhfniuwehf 5y agofor 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.
- gruez 5y ago> 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.
- riskable 5y agoThe 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.
- gruez 5y ago>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.
- brokenmachine 5y agoThat'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.
- JohnFen 5y ago> 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.
- vinsci 5y agoAlso, 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 https://github.com/sporkexec/rubberhose [2] A partial archive.org copy https://web.archive.org/web/20010819035021/http://www.marutukku.org/ https://web.archive.org/web/20010819035021/http://www.marutu... Edit: add URLs
- yrro 5y agoWhich apps refuse to run in the absence of a TPM, please?
- raxxorrax 5y agoWindows 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 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.
- yrro 5y agoOk 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.