Protecting systems with the TPM [LWN.net]

Protecting systems with the TPM

Posted Feb 16, 2016 7:50 UTC (Tue) by ras (subscriber, #33059)
Parent article: Protecting systems with the TPM

Is is just me, or is this another example of open source finally paying attention to something because Microsoft forced it under our noses? TPM's have been around for a decade now, yet this is the first talk I've come across from an open source perspective that discusses them in a sane, approachable manner that doesn't treat them like the work of the devil.

It's a pity it's taken 10 years for their usefulness to dawn on the community. As it is, this dawning has been nicely timed to coincide with the version we use (TPM 1.2) becoming obsolete. TPM 2.0 apparently attempts to fix the "brittle sealed storage" problem in TPM 1.2, which would be nice.

But I gather 2.0 isn't backward compatible with 1.2. Is there any planned upgrade path? For example, I presume there is no reason both can't exist in the system at the same time? Or maybe people make devices that support both interfaces.

to post comments

Protecting systems with the TPM

Posted Feb 16, 2016 8:18 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Nobody makes parts that support both and nobody ships systems that expose both at the same time, but there are people working on solving this problem in a useful way. Real hardware TPM 2.0 isn't really shipping yet (most TPM 2.0 implementations I've seen in the real world have been code running on the Intel ME, and the rest have been engineering samples), but it's completely true that we're behind the curve in terms of supporting it. Windows already provides a layer that abstracts 1.2 and 2.0 devices for common purposes.

People have been using TPMs for good for a while, including LUKS and SSH support. But we've done a bad job at obtaining wider support for this, and that's definitely a failure on our side. Even so, this is still an area where free operating systems can do a good job of competing against Windows (still basically uses TPMs for disk encryption or corporate VPN support) and Apple (doesn't ship TPMs), so there's plenty of work to do. I don't think your characterisation is entirely fair - we've been paying attention, just not advertising it.

The first talk?

Posted Feb 16, 2016 13:01 UTC (Tue) by corbet (editor, #1) [Link] (5 responses)

I guess you weren't reading back in 2005 :)

The first talk?

Posted Feb 16, 2016 23:58 UTC (Tue) by ras (subscriber, #33059) [Link] (4 responses)

I thought I was paying attention back then. But that's pretty damning, so evidently not. The comments illustrate the deep distrust the community had towards TPM's a back then. A decade of those fears being unrealised means those fears have evaporated now. Unfortunately they have been replaced with indifference.

After reading Matthew's reply, it occurred to me ssh + TPM's are a match made in heaven. Not the ssh implementations we have now that unlock client keys - they seem rather pointless. But an sshd daemon that used the TPM 2.0 to guard the host key would be awesome. It would give me a guarantee the machine I am ssh'ing into is still running the BIOS signed my the manufacturer, a kernel signed by my distro, and user space signed by whoever I trusted. The machine is same state it was when I I built it in other words - uncompromised.

It's one of the most basic usage scenario's one can imagine for a TPM, but can't really be done with TPM 1.2 due to the brittleness problem. It could be done with TPM 2.0. Maybe in another 10 years our software stack will have adapted to 2.0 and will finally be able to use TPM's to do the things they were designed for on a regular basis.

It will have only taken 20 years. For an industry that prides itself on moving quickly, sometimes we are god awfully slow. We needed this stuff to working 5 years ago, when the cloud broke our assumption the machines we look after are under our personal supervision. It would be nice if these TPM's were a standard feature in the IoT deployments (which effectively adds a few noughts to the number of machines in the cloud, scaling the security problem by a similar factor). But AFAICT we don't even have user space libraries that talk 2.0 yet, so I bet we miss that boat too.

The first talk?

Posted Feb 17, 2016 3:40 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

The brittleness problem is a solvable one, even on 1.2 - we can certainly develop the infrastructure required to re-seal secrets on updates of components under our control. The only real problem is around firmware updates, and even that's something that's being worked on.

The first talk?

Posted Feb 17, 2016 9:20 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Your SSH client being able to verify the server is running the BIOS the hardware provided, the same OS you installed from the available list of hardware provider approved choices, etc. is somewhat terrifying. For if your SSH client can do it, then so much more powerful (though, not all-powerful) entities can.

That the fears havn't been realised isn't because there was nothing to fear, it was simply because it has taken the leading player - MS - a long time to be able to start _requiring_ the constituent bits of technology because of backward compatibility reasons. Which were exacerbated by a misstep in a major OS release MS made. There were also anti-trust issues to be careful not to step into.

You can't dismiss the fears when the major players still havn't finished the long game they are playing in setting up the required environment.

The first talk?

Posted Feb 17, 2016 11:44 UTC (Wed) by ras (subscriber, #33059) [Link]

> Your SSH client being able to verify the server is running the BIOS the hardware provided, the same OS you installed from the available list of hardware provider approved choices, etc. is somewhat terrifying. For if your SSH client can do it, then so much more powerful (though, not all-powerful) entities can.

Maybe they can, but the TPM doesn't give them anything they didn't have before.

It is true that after boot the TPM can uniquely identify the software that is running. However the TPM doesn't magically "gather" this information. It is gathered by the software as it boots (CPU Boot code, BIOS, Boot Loader, kernel, ...) and given to the TPM as a series of hashes (SHA-1 for TPM 1.2) for each lump of code loaded. So there is no "new" information being created here - anyone with access to the system can run SHA-1 and come to the same result.

And in this case at least, if they have access to the TPM then they have access to entire system so they could do it themselves. This is because the TPM is no different to any other local device in that no one outside of the system access it any more than they can access the disk drives or clock. *I* can certainly choose to give someone access to the information in the TPM and that information could be used to verify whatever I want to let them verify regarding the software running, but this is no different to say me choosing to provide access to some of the content on my disk drives via a web server. But as it happens I don't have to provide any external access to the TPM for this ssh magic to work, so no new potential channels that might leak information need be created.

My SSH client verifies the host is unchanged by verifying the host key just as it does now, whatever information that host key reveals about my system is unchanged by the presence of the TPM. The only difference is the host key is "sealed" by the TPM, which effectively means it is encrypted by the TPM and the TPM will refuse to decrypt it if the software (BIOS, Boot loader, kernel, ssh daemon, and whatever else you think might be important) changes. It doesn't do that by "knowing" what the right software is. It does that by verifying the hashes it was given through the boot process match the hashes you gave it when you asked it to seal the ssh host key.

The first talk?

Posted Feb 17, 2016 17:49 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

In this context, there's no way a third party can rely on this in the same way - anyone who controls the system can re-seal the key against a different PCR state.

Protecting systems with the TPM

Posted Feb 18, 2016 3:25 UTC (Thu) by rahvin (guest, #16953) [Link] (4 responses)

It's just you. Outside large enterprises TPM is virtually non existent. I'd wager 90% of the time it's included in a computer it's never even used and it's rarely included. Even on Windows the software stack up until recently has been highly specialized and often quite expensive with no real guarantee of security. You'd be hard pressed to find any organization you know that's actually using it in production outside highly secure areas (for example, I'm quite sure the NSA uses it extensively internally). But even up to multi thousand employee companies outside those specific security areas you aren't going to find TPM. Go on Dell, HP or one of the computer manufacturers and try to find a computer with a TPM module builtin (your best bet is Lenovo BTW).

With Windows 8 and future versions Microsoft is making an effort to integrate the TPM controls directly into the OS to make use of the TPM less expensive, standard and more secure. As a result TPM has seen some mild expansion in use. But I wouldn't argue Open source is much behind the curve here. Honestly FOSS could leapfrog Microsoft overnight if TPM actually became popular enough that you could count on a module being in any random computer your purchased instead of having to spec an expensive enterprise model.

That's why I'm glad the same people that developed the FOSS secureboot shim are looking at this. Secureboot and TPM combined are complementary technologies. And if Microsoft actually gets enough support built into windows that TPM actually standardizes then FOSS will be well placed to take advantage of it.

Protecting systems with the TPM

Posted Feb 18, 2016 4:58 UTC (Thu) by ras (subscriber, #33059) [Link] (3 responses)

> I'd wager 90% of the time it's included in a computer it's never even used and it's rarely included. ... Go on Dell, HP or one of the computer manufacturers and try to find a computer with a TPM module builtin (your best bet is Lenovo BTW).

My last Dell two laptops (Precision and now XPS) do have TPM's, and I gather that is usually the case for "work" oriented Dell's.

You are right in saying it is a rare person that uses them (certainly I didn't) - but that has to come with a big qualification. It only applies to PC's. My phone has a TPM like thingy, and it is switched on by default. That isn't unusual. In fact in a few years I'd say most people will use hardware protect provided by a TPM like device every day of their lives.

When I ask myself why I am happy to use it on my phone but not my PC, the answer seems to be I am pretty confident I won't lose data on my phone due to the TPM. At least I haven't yet, and it's gone through a fair few firmware upgrades. On the other hand I have a friend who did turn on disk encryption for his Mac and one mishap or so later, he lost everything stored there. (It was backed up, but turns out Time machine encrypted the backup with the sealed key.) It happened to contain his wife's photo collection from an overseas holiday, so he wasn't a popular boy. Colour me skeptical, but if I ever get around turn on full disk encryption on Debian testing and seal the key with the TPM, I also fully expect to lose all the data on the disk; repeatedly.

If that expectation changes to me believing it works as well on my PC as it does on my phone, I would enable the TPM and full disk encryption as a matter of course, and I'd hope my distro would do that by default.

I guess the point I'm trying to make is that people do find TPM's useful, they only avoid them because they are too hard to use. Microsoft, Apple and Google are now doing an excellent job of making it obvious they don't have to be hard to use. It seems we in the open source world are learning how to deploy TPM's them, not the other way around.

Protecting systems with the TPM

Posted Feb 19, 2016 2:11 UTC (Fri) by rahvin (guest, #16953) [Link] (1 responses)

>My last Dell two laptops (Precision and now XPS) do have TPM's, and I gather that is usually the case for "work" oriented Dell's.

Yea, but were they accessible? There's been a shocking tendency with TPM to build them in because they are so cheap and then just disable them in the bios with no way to activate them. That is unless you pay extra for the model with the bios that enables them.

Until the PC side figures out how to do TPM right like on the Phone side I would avoid them. My experience on windows with TPM was terrible honestly. But the technology is quite powerful if you use it right. The FOSS community has really smart people looking at this. I can actually see this being a key feature some day and I can see FOSS leading the way here. Microsoft's support of TPM has always been pretty terrible, I don't see that changing very soon.

Protecting systems with the TPM

Posted Feb 19, 2016 3:01 UTC (Fri) by ras (subscriber, #33059) [Link]

> Yea, but were they accessible?

It definitely was working in the precision. The XPS having TPM 1.2, and 1.2 being on the way out due to SHA-1 has sapped my interest. The kernel on the XPS seems to know about it, though.

> Until the PC side figures out how to do TPM right like on the Phone side I would avoid them.

Yes, well my take is TPM 1.2 is just too hard to use. Matthew's says the brittleness problem can be solved by resealing, but getting that right for software you control sounds hard and for software that changes underneath you (BIOS, host software in a VM) sounds impossible. Maybe TPM 2.0 will fix that, but given you can't buy one yet that's a long way out. And besides, I care more about keeping the data on my laptop accessible than I care about keeping it secure. So maybe it will never be good enough.

However, my laptop isn't where my interest lies. I am responsible for keeping customer data secure on VM's managed by others. My "responsible" approach is to keep it to a minimum and cross my fingers. If it was a joke it might even be funny. It almost brought an audible sigh of relief from me when I heard Matthew say he was working on extending the TPM into containers. The interesting thing is I don't even care that it's brittle and so probably will lose my data. That's mostly because VM's are already very good at losing my data.

One thing I don't understand is why they don't put the TPM on the CPU die. Why everyone thinks putting the TPM on an external bus where it can be reset at will with a minimal amount of hardware is a complete mystery to me. The TPM's integrity depends on being able to provide a tamper evident audit trail from boot. If you can reset it without resetting the rest of the system you can re-program that audit trail to be whatever you want. So if it's not on the die, it can only provide a very moderate level of protection.

Protecting systems with the TPM

Posted Feb 19, 2016 18:05 UTC (Fri) by foom (subscriber, #14868) [Link]

Macs don't even have a TPM, and never have. (Well, the very first Intel macbook did, probably was in the default Intel reference design or something, but there was never a driver for it).

Whatever problem your friend had with disk encryption in MacOS can't be blamed on a TPM...