Linux and TPMs with systemd measured boot [video]

https://media.ccc.de/v/all-systems-go-2023-186-linux-tpms

by transpute • 3 years ago

124 198 3 years ago

media.ccc.de

pzmarzly3• 3 years ago

I am not a big fan of systemd, but I am impressed in how they put this security feature all across the boot process. I also used some of the tools shown in presentation and they are pretty well made, kudos to the devs. (Also, most of them work fine without systemd running, they just happen to be in the systemd monorepo???)

andrewstuart• 3 years ago

Systemd is packed with impressive things.

The more you research it, the more you find to be impressed with.

keep_reading• 3 years ago

I'll be impressed when they figure out how to not break bind mounts and NFS on boot

immibis22• 3 years ago

The problem with systemd isn't that it's not packed with impressive things, it's how inextricable the things are from each other. systemd distros are practically whole new distros on the inside, designed by committee. Every part of systemd really wants to integrate with every other part, so while you can technically compile and run just part of it, it really wants you to use the whole thing and throw away all the things those parts replace.

In other words the complaints are political, not technical.

pzmarzly3• 3 years ago

I agree that there are some very cool components of systemd (or rather, very cool programs living in systemd repo) - networkd, resolved, repart, boot and stub come to my mind first, they have no alternatives that come even close to them.

Also, systemd made writing service definitions easy, hats off to them. With cgroups, namespaces and capabilities support out of the box - great.

However, every time I have to debug why some target wasn't reached (because some dependency of dependency failed), or why systemd mounted something wrongly, or just want to know how often and why some service restarted, I feel like the core part of systemd (which is, the systemd init and service runner) is working against me.

And let's not get started on journald, I declare it my enemy.

zlg_codes6• 3 years ago

I've kept my eye on the project from afar. What's impressive about systemd aside from its ability to manifest conformity and avoid social accountability for how it gained influence?

Boot charts and NIH syndrome for system level stuff ain't it for me. Binary journals ain't it, either. Services suck, you're never sure the difference between units, services, sockets, and other similar INI style files. Extra BS like $HOME management? Not necessary.

In over ten years, I've not found a single good reason to lean into systemd or like it. It runs my current computer, but not by choice and I will remedy that when I build my custom distro.

esjeon2• 3 years ago

This thing isn't really complicated, because all the hard-lifting is done by the design of TPM, not even TPM chips. Measurements and integrity checks are proven to be mundane tasks, and, for security, it's a good thing. Even without systemd, one can learn and integrate TPM in one or two months. But the systemd team has been working on this like 2 years now.

I'm quite curious what they've been doing. Security audits, maybe? Preparations for other integrations? I'm not criticizing here - I've been away from that scene for an year, and I wonder if there have been some new interesting developments or ideas that I'm not aware of.

pzmarzly3• 3 years ago

I wonder which of these tools Ubuntu is using - since they enabled TPM-backed encryption (Bitlocker-style) in 23.10. https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-c...

I am not a huge fan of relying on this, I cannot recall numer of times where I had to recover my files from live USB or by plugging my drive into another PC - both of which will get difficult to do when my true password sits in TPM on the (potentially bricked) motherboard. But I guess that if it can be used in addition to regular password (e.g. use regular password when TPM is missing, use PIN if it works) then it's fine

Manfred• 3 years ago

Do you prefer restoring from the original drive instead of a backup because it's faster?

magicalhippo• 3 years ago

I use a daily full-disk backup on Windows[1], this has allowed me to be back up and running within the hour the few cases my disk died.

What's a good alternative for Linux?

[1]: Acronis TrueImage, but there are others.

zeta0134• 3 years ago

Often I want to collect a very small number of files that I was working on which are newer than the last complete backup

INTPenis• 3 years ago

Also, correct me if I'm wrong, but TPM shifts the password input prompt from traditionally LUKS during boot, to your XDM or whatever display manager you're using?

And I seem to recall a recent vulnerability where people were able to bypass the display manager login on some graphical desktop Linux distro.

I just don't feel comfortable shifting the threat to this part of the OS, because desktop Linux has not had the extensive testing required yet. It reminds me of when I was in school and you could bypass NT4 or Windows 98 logins by mashing the Enter key or doing weird user input combinations. Basically manually fuzzing.

If TPM only adds convenience then I'd prefer to continue entering my LUKS password, and my login password, separately.

proto_lambda3• 3 years ago

If you rely only on TPM for key storage, yes, the disk is unlocked automatically and any sufficiently broken userspace application you can get your hands on will let you access it. You can still combine TPM+passphrase/PIN though, at the cost of having to enter it at boot.

g_p• 3 years ago

You could bind your disk unlock to also include a PIN entered at boot-time (TPM+PIN).

This gives you the benefit of system integrity verification at time of boot, but also requiring your input to release the keys (and meaning you can't get to the system lock screen without the PIN).

vladvasiliu• 3 years ago

Also, correct me if I'm wrong, but TPM shifts the password input prompt from traditionally LUKS during boot, to your XDM or whatever display manager you're using?

It doesn't "shift" it, it's not the same password. It doesn't work the way it does on a mac, where your user password unlocks the drive so you don't have to enter it again to unlock your user session.

Assuming you don't have autologon turned on, without this scheme, you'd have to enter two passwords: LUKS first during boot, then your user password in the XDM. With this scheme, you skip the first password.

But yeah, if you don't enable any other protection, like TPM+PIN, your PC will boot on its own all the way to the login manager. So if you don't trust your login manager, that's an issue.

ale42• 3 years ago

Not sure it was ever possible to bypass NT4 logins with whatever key combination... but Windows 98 was definitely doable.

jeroenhd3• 3 years ago

Ubuntu's implementation will also allow you to export a backup passphrase in case the TPM gets zapped (by a firmware update for example) after which you can re-enroll.

Annoyingly, this is a random 16 byte value that's translated into a numeric string that only Ubuntus's cryptsetup wrapper seems to use. You need to convert it into an actual key if you want to re-enroll your TPM or add a key file/passphrase to another slot.

If you don't back up the recovery key, your data is lost.

poettering5• 3 years ago

systemd has a similar logic, i.e. a recovery key concept, but we made sure you can type it in wherever a LUKS password would work too, even on systems where systemd is not available but LUKS ist. The recovery key is output in yubikey's modhex alphabet which means you can type it in on many keyboards even without setting a keymap first, and will work. We also output it as qr code, in case you want to scan it off. All on all it should be as robust as a recovery key could be.

poettering5• 3 years ago

To my knowledge Ubuntu does not use the TPM2 PCR logic systemd provides at all, but their own.

egberts12• 3 years ago

Shifting PIN to an XDM?

Does anyone remember the good ol' days of hitting spaces 127 times at a SunOS "login:" prompt to gain its root shell?

wolf550e• 3 years ago

I want a review of this by mjg59.

harvie• 3 years ago

TPM chips are not opensource, end user cannot simply check them for backdoors. Manufacturers of these chips are under heavy scrutiny of intelligence agencies. Governments around the world try their best to prevent people from using strong cryptography (eg. limiting effective key lengths in various ways).

Why should we trust such chips more than purely software based approach?

isilofi• 3 years ago

We shouldn't. TPM-based security is only sufficient against unsophisticated attackers such as a common thief stealing your laptop from your backpack.

jon-wood4• 3 years ago

This is a massive overstatement of the situation. Sure, a TPM might not protect you against the NSA or the Chinese government stealing your computer. If configured correctly it probably will protect you against anything less than a major nation state stealing your computer.

goodpoint2• 3 years ago

Not even that.

mratsim2• 3 years ago

The real question is

"What's your threat model?"

If it's people stealing your laptop and fear of identity theft, use the TPM.

If it's the NSA, ¯\_(ツ)_/¯

cobertos• 3 years ago

LUKS or eCryptfs work perfectly fine for the "stealing your laptop" use case, and are purely software implementations.

There's a poster below that provides a more reasonable use case for TPM. Headless server where asking for password on boot is undesirable (eg after a power failure)

LikesPwsh• 3 years ago

Like most ordinary folks, my threat model is the use of TPM for DRM.

Netflix playing at lower resolution for example.

Widespread TPM is actively harmful for most people, and the biggest blow to general purpose computing in recent years.

rnhmjoj2• 3 years ago

It doesn't need to be the NSA; if your chip is vulnerable and exploits published online I don't think it's too far fetched that a resourceful thief could try to unlock your disk if he thinks it has valuable content (bank accounts, cryptocurrency, passwords, etc.)

Why take unnecessary risks when you can just use GRUB+LUKS and type the passphrase at boot?

SenpaiSilver• 3 years ago

How is the TPM protecting my if my laptop with the TPM chip is stolen?

I understand that I will be protected from removing the HDD/SSD and putting it into another machine to read the data, but does it really protect me from anything else?

huggingmouth• 3 years ago

No, the true question is why should we switch to tpms, and what are we giving up if we do.

In my experience, tpms are worse than worthless since they prevent rescuing garddrives from bricked systems. Nontpm luks can be unlocked on any system.

Bognar2• 3 years ago

I'm always curious what threat model that is valid against TPMs is not also valid against CPUs and main memory.

traverseda• 3 years ago

Or anyone with a pcileach.

dist-epoch6• 3 years ago

Because the alternative, not using SecureBoot, is strictly worse in all scenarios.

Just like HTTP vs HTTPS with LetsEncrypt. Even if an attacker can compromise a web-server rendering HTTPS protection useless, it's still better to always use HTTPS.

immibis22• 3 years ago

You're framing this as a choice between SecureBoot and InsecureBoot, but it's actually a choice between SecureBoot and DRM, or InsecureBoot and no DRM.

Besides, SecureBoot isn't strictly better in all scenarios. The most obvious one is the one where you forgot how to log in, and want to retrieve your data.

fsflover5• 3 years ago

TPM chips are not opensource

I'm using Librem 14 with a TPM chip with exclusively free software.

zlg_codes6• 3 years ago

Slight segue, have you had any luck with distros besides PureOS? I want to make my own LFS for my Librem but I'm not sure what my custom system would need to support the EC firmware and pureboot, etc.

cedws2• 3 years ago

This feature isn't really for people like you and me. It's for big companies like Red Hat and Google to utilise on their servers. Google have their own TPMs they can trust. Red Hat probably have the paperwork to say their TPMs are safe.

But worrying about your TPM being backdoored is pointless anyway. If they can backdoor your TPM, they can backdoor anything.

immibis22• 3 years ago

If they can backdoor your TPM, they can backdoor anything.

[citation needed]

mjg5912• 3 years ago

How would an end user simply check them for backdoors if they were open source? Security auditing is a skilled job, and the people best capable of identifying security flaws or backdoors are generally able to do that given a binary blob as well.

JohnFen3• 3 years ago

I dislike TPM personally (for a very different reason), but...

They reduce the attack surface. Not only in terms of the actual interface, but in terms of who has the ability to subvert the security. Using TPM may or may not be effective security against governments, manufacturers, and the like, but they are effective security against a whole host of other bad actors.

It could be argued that's still a worthwhile improvement. You can engage in other layers of security regardless of whether TPM is being used to help cover the areas TPM may not.

immibis22• 3 years ago

They're dangerous because the same effective security can be turned against the legitimate owner of the machine. The TPM effectively belongs to whoever configured it first.

o11c3• 3 years ago

TPMs are also highly effective against "you can just use a LiveCD to try Linux temporarily, then reboot and return to Windows."

azzentys• 3 years ago

I'm curious if open source TPM would mean easier side-channel attacks. What's the reason everyone is super hush-hush around how their Hardware Security works?

badrabbit• 3 years ago

Because it isn't a silver bullet but rather a countermeasure against rootkits, bootkits and certain physical tampering by regular and insider threat actors.

chlorion4• 3 years ago

This is very important.

For some reason in these threads nobody seems to bring up or realize that modern AMD CPU's fTPM is completely broken and not fixable via ucode updates. The AMD TPM exploit is exploitable by a "regular" person too, it doesn't have to be a state level actor, just some techy person with a few tools and physical access to the system.

We can't audit these things at all and I don't think we should just trust that they are safe, and we know for a fact that many of them aren't safe, even against "regular" threats.

(AMD fTPM exploit source) https://arxiv.org/abs/2304.14717

mkopec2• 3 years ago

Dropping a link to a project attempting to create a fully open source TPM: https://twpm.dasharo.com/

fsflover5• 3 years ago

How does it compare with Pureboot with Librem Key?

sweetjuly2• 3 years ago

No ASIC is ever going to satisfy your desire to audit. Even if they publish the RTL, you can't verify that this is what they synthesized, that this is what the fab actually produced, etc. You have to trust hardware because it's your everything. Even with relatively obvious attacks like backdooring the bootrom (which can be done by modifying just the metal layers!), practically speaking no one is going to ever catch it because modern processes are simply too fine for all but the fabs themselves to physically inspect. This isn't even to mention more clever attacks which attack the doping of the silicon [1] for individual transistors (which cannot be generically detected post fabrication by any publicly known technique).

Embrace the suck :) Sure, you can't truly trust hardware, but there's nothing to be done about it anyhow and so you may as well reap the benefits of trusting it.

[1] http://sharps.org/wp-content/uploads/BECKER-CHES.pdf

JohnFen3• 3 years ago

there's nothing to be done about it anyhow and so you may as well reap the benefits of trusting it.

Alternatively, you can avoid relying on any single thing to be secure and use layered security approaches instead.

matheusmoreira3• 3 years ago

We need the ability to create computer hardware at home just like we can create software at home. Until we can make chips in our garages, we'll be at the mercy of giant corporations and the governments looking to subvert our security through them. Decentralization of production is key to our technological emancipation.

spicymaki• 3 years ago

Some TPMs are FIPS-140 compliant and go through 3rd party audits and extra screening. If you purchase a device that is compliant you can then retrieve a certificate of compliance. Some TPMs can be made compliant with the appropriate firmware update.

If you don't trust FIPS then you could support open source TPMs and help audit them.

Other than that if you care enough about it and had the prerequisite skills and money, you could develop your own TPM (the interface specifications are online) and run your own trusted and audited Linux system.

mongol• 3 years ago

I think the topic of Lennart's talks usually is very interesting but his delivery assumes the audience knows much more about the subject than I do, at least. Most other talks I watch I have an easier time to follow.

mqus• 3 years ago

Do you have an example for stuff that the audience is expected to know? Or the other talks that do a better job? What kind of background do you have? Assuming an average full stack dev, of course he addresses a different audience, since this is a talk addressed to Linux OS developers at a conference with the description:

"All Systems Go! is a conference focused on foundational user-space Linux technologies. Its goal is to provide a gathering place for both contributors and users of projects that make up the foundation of modern Linux systems."

So, summing up: maybe you are not part of the target audience?

esjeon2• 3 years ago

I think this one is especially worse, because TPM is a piece of hardware and is for security. The combination of the two alienates a lot of software engineers, like >90%. I've never met anyone in real-life who already knew how to use TPM, though many do know what it is and what it's for.

So, it's really a bad (or s**ty) topic to talk about in front of an unsuspecting audience, but certainly there are people who would appreciate the work, especially in embedded/robotics fields (which have been rising slowly for a long time).

Arnavion• 3 years ago

The vidoes are mostly a condensed form of the blogposts he's been writing on these topics (filesystem layout / Boot Loader Specification / Secure Boot / Measured Boot / Unified Kernel Images) for a couple of years now, so you can read those if you prefer.

https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-...

https://0pointer.net/blog/the-wondrous-world-of-discoverable...

https://0pointer.net/blog/authenticated-boot-and-disk-encryp...

https://0pointer.net/blog/fitting-everything-together.html

https://0pointer.net/blog/brave-new-trusted-boot-world.html

https://0pointer.net/blog/linux-boot-partitions.html

shrubble• 3 years ago

Not just no, but heck no! TPM will never be auditable, and therefore can never be considered trustworthy.

chlorion4• 3 years ago

Just a heads up for anyone using AMD CPUs fTPM, it is completely broken and cannot be used even for "someone stealing your laptop".

A few hours time and a few tools can fully compromise the TPM's secrets. This can be performed by anyone who has a little experience tinkering with electronics, someone who can use a soldering iron for example can almost certainly pull this off.

From my understanding all of the "zen" CPUs are effected except for maybe the very most recent models.

https://arxiv.org/abs/2304.14717

bootsmann3• 3 years ago

Note that this attack only works if you don’t enroll an additional password to unlock the TPM (see 5.3 of your linked paper).

Linux and TPMs with systemd measured boot [video]

Related Stories