Secure key handling using the TPM

Posted Oct 17, 2018 17:36 UTC (Wed) by mjg59 (subscriber, #23239)
In reply to: Secure key handling using the TPM by jgg
Parent article: Secure key handling using the TPM

Windows has the advantage of a sufficiently large security team and support infrastructure that they can support escrowing the Bitlocker keys and allowing users to recover them when system measurements change. All the pieces exist to do this in Linux, the problem is that it's a terrible user experience when an update results in them being locked out of their machine.

to post comments

Secure key handling using the TPM

Posted Oct 17, 2018 18:05 UTC (Wed) by jejb (subscriber, #6654) [Link] (11 responses)

> All the pieces exist to do this in Linux, the problem is that it's a terrible user experience when an update results in them being locked out of their machine.

Just to clarify: what Matthew is talking about is where you tie keys to policy such as specific measurement values: the policy (and thus the key its tied to) needs to change if the measurements do. In the interests of full disclosure, the openssl engine I was talking about does have the ability to work with policy limited keys. However, because of the difficulty pointed out, I would recommend most people don't use this in their first foray into TPM protections.

The other difficulty about Bitlocker and Linux disk encryption is that the TPM cannot protect the keys used because it's far too slow for the bulk encryption requirements, so the TPM is used to store the symmetric disk key and release it under specific requirements for the OS to do the bulk encryption. With bitlocker these release requirements do include a password and an OS measurement policy but we could begin in Linux with simply requiring a password.

Secure key handling using the TPM

Posted Oct 17, 2018 19:52 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (10 responses)

Password protection makes some sense here, but it ends up depending somewhat on your threat model. If you're using argon2id as the key derivation function (as is supported in recent versions of cryptsetup) then brute-forcing the disk passphrase isn't realistically possible in any case - it'd be cheaper to decap the TPM and read stuff out of it than it would be to throw enough compute at the brute-force job, so using the TPM is then arguably weaker than not doing so. The only real benefit you're getting is that stealing the drive on its own gets you nothing. Using policy-bound keys at least gives you the advantage of being able to boot an encrypted FS without requiring user interaction, at the cost of needing some reasonable way to handle recovery.

Secure key handling using the TPM

Posted Oct 17, 2018 19:57 UTC (Wed) by rdoty (guest, #39529) [Link] (9 responses)

Doesn't decapping the TPM need to be compared to other ways of _providing_ the disk passphrase? Manual entry of the disk passphrase, for example, is subject to everything from hardware keyloggers to software reading user input. Or am I missing something?

Secure key handling using the TPM

Posted Oct 17, 2018 21:40 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (8 responses)

If you're able to intercept the user typing the password (or compel the user to provide their password in any other way) then using the TPM gives you no benefit over not using the TPM.

Secure key handling using the TPM

Posted Oct 18, 2018 6:43 UTC (Thu) by smurf (subscriber, #17840) [Link] (7 responses)

Again, that depends on the threat model. You're assuming that the adversary has access to the complete computer.

If they can "only" get away with [a copy of] the disk, the TPM approach does improve security.

Secure key handling using the TPM

Posted Oct 18, 2018 7:25 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (6 responses)

You need to construct a pretty elaborate model to be able to obtain someone's password without either:

a) Having physical access to the system, or
b) Having enough control over the system to be able to exfiltrate the contents of the disk after it's been unlocked

Secure key handling using the TPM

Posted Oct 18, 2018 16:46 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

Obtaining an unlock password is easy. You watch the target type it – either directly or via a surveillance camera.

Then you borrow the disk for a couple of hours – while they're asleep, off on a date, or whatever.

Secure key handling using the TPM

Posted Oct 18, 2018 16:51 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (4 responses)

If you can borrow the disk then why wouldn't you just borrow the computer? It's going to be massively faster than taking the system apart to extract the disk, and for a bunch of modern laptops with flash on the motherboard you're not even going to be able to do that.

Secure key handling using the TPM

Posted Oct 19, 2018 7:54 UTC (Fri) by jgg (subscriber, #55211) [Link] (3 responses)

It isn't taking the disc that worries people, it is copying it.

If I borrow your computer, disassemble it, clone the disk, then put it back, you have no idea it was stolen and I can access your data as soon as I observe the passphrase through some means.

With the TPM even if I do all of these steps I can't decrypt the copy of the drive as I need the physical TPM as well.

Of course if I steal the entire computer then more options are possible, but at least you'll know the computer was stolen and can take counter-mesaures, ie re-keying online accounts, etc.

Secure key handling using the TPM

Posted Oct 19, 2018 8:42 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (2 responses)

So the threat model is one where I have physical access to your computer before I know your passphrase, but don't afterwards?

Secure key handling using the TPM

Posted Oct 19, 2018 15:44 UTC (Fri) by jejb (subscriber, #6654) [Link] (1 responses)

A couple of observations on this argument:

Firstly neither system protects the case where the attacker got the passphrase by looking over your shoulder and then runs off with your laptop because even in the bitlocker case the measurements won't change when the attacker unlocks.

Secondly, I think there is value to having the TPM dictionary attack protections against brute forcing the password. I don't buy the argon2id brute forcing argument because most people do have insecure passphrases which a dictionary attack will eventually crack given enough compute power. I also don't buy the idea that training people not to use memorable words is the way forward because then they tend to write them down (especially if you force them to change their unmemorable passphrase every couple of months), so TPM DA protections do give benefits in the average user case where they're using a memorable word as the passphrase.

Plus simply placing the decryption key in the TPM is a big step towards implementing policy based protections around it, so it would be a good first step to take regardless of any additional security benefits.

Secure key handling using the TPM

Posted Oct 20, 2018 12:58 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

argon2id is sufficiently RAM intensive that you're going to need to throw significant resources at it even if the user is using a low entropy password. If the user's using a high entropy password then it's effectively unbreakable, whereas a TPM is, well, not. I definitely think there's value in using TPMs, but for this kind of thing I think there's more value in trying to reduce PCR fragility and using them as a way of improving user experience.