LWN: Comments on "Secure key handling using the TPM"

TPM proof?

mjg59 — Sun, 21 Oct 2018 15:05:28 +0000

One of the benefits of running the TPM stack on the ME is that MITM becomes a significantly tougher problem (and on chips where the PCH is on package, basically impossible) - I'm actually leaning towards using PTT rather than a physical TPM where possible.

TPM proof?

jboone — Sun, 21 Oct 2018 15:03:26 +0000

I suppose there are a few downsides to asking userspace to verify the key.

First, if a man-in-the-middle (interposer) sits on the bus between the kernel and the TPM peripheral, then by the time that userspace executes, the kernel may have already been compromised. For example, this MITM can spoof measurements that are extended into PCRs, making it appear as if a malicious kernel is in fact legitimate. A compromised kernel should be able to present the real key to userspace.

The kernel could itself verify the key prior to communicating with the TPM (for the purposes of PCR extends, unsealing secrets, etc). But I understand why we may not want to do key verification in the kernel, asking the kernel to keep copies of public keys [1] for every TPM manufacturer is a maintenance problem. As an aside, similar challenges are faced by other peripheral drivers, such as the USB Type-C Authentication scheme [2] and the more recent PCIe Device Security Enhancements [3].

The above also holds true for the pre-kernel boot environment. Each boot stage needs to be able to securely communicate with the TPM. As with the kernel, the PCR Extend operations that are performed by the platform's bootloader(s) must be integrity protected. This requires knowledge of the HMAC shared secret, which must be kept hidden from a MITM. So we once again encounter the same problem that is faced by the kernel.

[1] https://www.st.com/content/ccc/resource/technical/digital...
[2] https://community.nxp.com/servlet/JiveServlet/downloadBod...
[3] https://www.intel.com/content/www/us/en/io/pci-express/pc...

Secure key handling using the TPM

pizza — Sun, 21 Oct 2018 00:10:38 +0000

That laptop was not sold with Windows 10.

Anything sold as new today is unlikely to have been tested with anything other than Windows 10, and even then only in the configuration that MS requires (ie UEFI with secure boot).

Secure key handling using the TPM

dps — Sat, 20 Oct 2018 23:48:36 +0000

I have personally run Windows 10 on a laptop without uefi firmware and secure boot. It did have a tpm but I did briefly run Windows 10 with it disabled to upgrade infeon's insecure firmware. Modulo bitlocker there where no problems.

I doubt bitlocker is useful enough justify spenfing an extra £300+ more for most people.

Secure key handling using the TPM

mjg59 — Sat, 20 Oct 2018 12:58:14 +0000

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.

Secure key handling using the TPM

jejb — Fri, 19 Oct 2018 15:44:15 +0000

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

rdoty — Fri, 19 Oct 2018 12:37:08 +0000

The original use case for NBDE was servers in a data center or VPN environment. The addition of TPM2 support adds more security - you can require both TPM and a network server - and opens up new use cases like desktops and laptops. The PIN base architecture of the Clevis client provides a flexible way to add new ways to unlock keys, and the policy capability of Clevis allows you to use multiple PINs.

Secure key handling using the TPM

grawity — Fri, 19 Oct 2018 10:10:24 +0000

> most USB devices can only cope with one or two key pairs, and smart cards tend to only hold three.

I'd be slightly surprised if that were true for USB-stick-shaped smartcards at least. (Especially when they don't have the size constraints that actual cards do...)

Yes, Yubikeys and other tokens implementing the PIV spec have 3 primary keypair slots for specific tasks – but they also have 20 additional "retired key" slots into which an obsolete primary keypair can be moved, so clearly the memory capacity is present, just the firmware is somewhat restrictive about it.

Here I have an old Aladdin eToken 72K USB token which uses a more freeform structure, I can upload as many keypairs as the ~72 kB memory will fit – although I've never tried more than six. (Unfortunately it's EOL and won't go above RSA2048 either. But wouldn't modern devices have at least similar capacity?)

Secure key handling using the TPM

nix — Fri, 19 Oct 2018 09:46:28 +0000

So long as they're not running it in SGX enclaves. L1tf showed us how much *that* security was worth.

Secure key handling using the TPM

mjg59 — Fri, 19 Oct 2018 08:42:56 +0000

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

jgg — Fri, 19 Oct 2018 07:56:44 +0000

I thought NBDE was for servers not latops? Interested in the laptop use case here..

Secure key handling using the TPM

jgg — Fri, 19 Oct 2018 07:54:33 +0000

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

zlynx — Thu, 18 Oct 2018 19:49:59 +0000

All of the AMD Ryzen CPUs offer what they call a fTPM. f for Fake, maybe? (No, really it is Firmware).

It's implemented on the CPU via their PSP (Platform Security Processor). Essentially the same thing as Intel's ME.

Secure key handling using the TPM

mjg59 — Thu, 18 Oct 2018 18:26:18 +0000

…although I believe the TPM can be in the form of software running on the ME or SPU.

Secure key handling using the TPM

pizza — Thu, 18 Oct 2018 18:17:40 +0000

In order to ship something with Windows 10 (Client), Microsoft mandates use of UEFI, secure boot, and a TPM.

Secure key handling using the TPM

mjg59 — Thu, 18 Oct 2018 16:51:24 +0000

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

smurf — Thu, 18 Oct 2018 16:46:58 +0000

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

dps — Thu, 18 Oct 2018 15:47:18 +0000

I might be badly informed, or one a weird band that buy memory, cpus, motherboards, etc separately (and don't buy windows). At least 98% of the moderateoy cheap brand new motherboards I have condisdered don't have a tpm.

A lot of these mothebostds offer at most minimal uefi support. I find it hard to believe that just people like me are sufficient to make these tpm free motherboards economic.

I think that despite the propaganda most people don't have a tpm. Even microsoft probably can't afford not to support those that can't use uefi.

" Twelve keys is beyond the capacity of any USB device that he knows of..."

Herve5 — Thu, 18 Oct 2018 12:33:01 +0000

(answering to myself) OK, sorry for second part the above. Obviously, just mounting the Nitrokey encrypted volume means any borked system can access my precious keys...

" Twelve keys is beyond the capacity of any USB device that he knows of..."

Herve5 — Thu, 18 Oct 2018 09:18:24 +0000

I understand some of the Nitrokeys can offer 20 RSA key pairs and 30 ECC ones; mine, the 'storage' version, only supports 3 + 3 but also offers Gbytes of encrypted memory that I trust reasonably unreachable...
Thus my very naive question : is it really less safe to store keys on an encrypted Nitrokey volume?
H.

Secure key handling using the TPM

mjg59 — Thu, 18 Oct 2018 07:25:14 +0000

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

smurf — Thu, 18 Oct 2018 06:43:32 +0000

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

mjg59 — Wed, 17 Oct 2018 21:40:47 +0000

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

rdoty — Wed, 17 Oct 2018 19:57:58 +0000

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

mjg59 — Wed, 17 Oct 2018 19:52:52 +0000

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.

TPM proof?

jejb — Wed, 17 Oct 2018 18:09:34 +0000

> How can the TPM prove that it's really a TPM, instead of some software emulating one?

TPMs come with an endorsement key (EK) certificate signed by the manufacturer. Thus you run an X509 verification on this key which proves the public part of the EK (provided you trust the manufacturer, of course) and then the TPM itself will give you various proofs signed by the EK which you can externally verify.

The proposal for defeating TPM Genie with the in-kernel TPM handling relies on the kernel simply using the NULL seed primary as an encryption key but userspace proving after boot that this is indeed a key genuinely produced by the expected TPM.

Secure key handling using the TPM

jejb — Wed, 17 Oct 2018 18:05:11 +0000

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

TPM proof?

smurf — Wed, 17 Oct 2018 18:02:36 +0000

How can the TPM prove that it's really a TPM, instead of some software emulating one?

Secure key handling using the TPM

jejb — Wed, 17 Oct 2018 17:58:32 +0000

> if you can't trust the kernel there are probably equally bad problems as loss of a private key

So there are things you can do about this. A fully untrusted kernel is a hugely difficult problem but a trusted but vulnerable one (meaning it's your kernel but someone could gain access via an exploit) is much easier because the more interception channels you shut down the less likely the exploit is to gain access.

However, the point about the TPM is that even a fully untrusted kernel can't gain access to the key you place in the TPM if you do it correctly. The handheld market is working on this (where you can root the system but can't get access to their credentials) but there's a huge amount of work that goes into "... do it correctly".

Secure key handling using the TPM

mjg59 — Wed, 17 Oct 2018 17:36:18 +0000

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.

Secure key handling using the TPM

rdoty — Wed, 17 Oct 2018 17:24:51 +0000

The Clevis module in Network Bound Disk Encryption (NBDE) has added support for TPM2. It is initially included in Fedora 28. Details available at https://blog.dowhile0.org/2017/10/18/automatic-luks-volum...

Secure key handling using the TPM

GennaroReinger — Wed, 17 Oct 2018 17:06:16 +0000

Here's link to the talk. I couldn't find it in the article.

https://kernel-recipes.org/en/2018/talks/tpm-enabling-the...

Secure key handling using the TPM

jgg — Wed, 17 Oct 2018 17:03:15 +0000

What I would really like to see is for distros to start supporting tpm for holding the disk encryption key. It is rediculous how far ahead Windows is here.

Secure key handling using the TPM

jgg — Wed, 17 Oct 2018 17:01:50 +0000

The tpm subsystem supports this, and I recall qemu can work with emulated tpm as well.

Secure key handling using the TPM

epa — Wed, 17 Oct 2018 16:58:25 +0000

From the sound of it, if access to the TPM is mediated by the kernel, then for some applications you don't need a physical TPM at all. After all, if you can't trust the kernel there are probably equally bad problems as loss of a private key. (This is certainly not true in all applications, hence the desire for a hardware TPM that stays secure even if the kernel is compromised -- but just as certainly there are cases where it does hold, and any attacker who controls the kernel can already do all the bad things you're worried about.)

That suggests a virtual TPM in software, but exposed using the same kernel interface, would be a useful thing to have for some virtualization applications, for debugging, and for systems that don't have a hardware TPM but nonetheless want to run software that expects one (at the user's own risk, of course).