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.
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.
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.
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.
>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).