LWN: Comments on "Ubuntu to add TPM-backed full-disk encryption"

Ubuntu to add TPM-backed full-disk encryption

Cyberax — Mon, 18 Sep 2023 06:15:57 +0000

> "You can store the keys outside of the TPM" is misleading

Not really? I have my encryption keys printed on a paper and stored in a safe deposit box in my local bank. So if my NAS has a motherboard failure, I'll still be able to recover all the data.

Of course, TPM allows me to avoid entering any credentials for the NAS during the boot.

Ubuntu to add TPM-backed full-disk encryption

ras — Mon, 18 Sep 2023 00:03:01 +0000

"You can store the keys outside of the TPM" is misleading. You don't achieve much can't unless you encrypt them with a key that isn't on the disk, so there is always something not stored on the disk. And that means you can't boot without some way of supplying the key, which usually ends up being done manually.

If you store the encryption key locally on the TPM you can do unattended reboots. As far as I can tell, that's it's prime advantage, and it's a very nice thing to have in VM's. If your threat scenario is someone stealing or copying the disk, maybe just storing the key on on some networked storage your hosting provider only allows that VM to access is a poor mans solution.

In any case, if merely remembering a good password is the problem there are multiple solutions. For example you could enable the network stack / USB during boot and supply it from a phone or similar device. But I don't think that's the real problem - it's having to supply the password that's the issue, and the other problems that go along with that - like knowing your sending the password to the right device, and not something controlled by an attacker.

Ubuntu to add TPM-backed full-disk encryption

jschrod — Sat, 16 Sep 2023 00:26:04 +0000

I didn't understand a single sentence that you wrote - and I use and administer Linux Systems since 0.99.4.

If you folks want people to use that TPM stuff (and we're interested) - well, then we, as a community, need better documentation and better packaging.

Ubuntu to add TPM-backed full-disk encryption

farnz — Fri, 15 Sep 2023 09:56:58 +0000

The important thing is not so much the time taken, as the user time spent on it. If you have a Time Machine backup of your Mac, you can restore to a replacement Mac in just a few minutes operator time (plus potentially hours of machine time restoring the backup). As long as the machine time is reasonable (overnight, say), this is fine because you can go and do something else while you wait for the backup to restore.

Ubuntu to add TPM-backed full-disk encryption

raof — Fri, 15 Sep 2023 01:31:14 +0000

At least one significant difference between this and systemd-cryptenroll is that Ubuntu manages the policy. To use systemd-cryptenroll you need to be able to generate & sign a policy that applies to the PCR measurements, which means either you've got a key capable of bypassing this protection on your system or your system is centrally managed and that key exists wherever central management happens.

Ubuntu to add TPM-backed full-disk encryption

raof — Fri, 15 Sep 2023 01:16:55 +0000

But is there a good reason to link TPM and SNAP?
I don't think so, other than they have aparantly already done it that way for Ubuntu Core.

I get that it's cool to hate on snaps, but isn't “the work has already been done for Snap-based installs” a good reason?

Additionally, there are other good reasons why this is harder with debs. To do this (as the article mentions) you need to distribute the kernel + the initrd + the kernel command line, but in the existing deb-based system only the kernel is distributed; the initrd is generated on each machine (potentially multiple times), and the kernel command line is also generated on each machine, from user-modifiable configuration.

Now, you could do a whole lot of work to replace the existing bootloader/kernel/initrd package infrastructure with a single .deb package, but why would you? The result would be a .deb that looks almost exactly like the snap, but with worse management capabilities.

I suspect there is a significant subset of users who would like TPM based FDE for the security benefits but would prefer to stay with DEBs.

Why, particularly, would they want to stay with Debian packages for the bootloader and kernel? This is not changing the rest of the system management. Indeed, this is backporting a feature which already exists on the snap-only Ubuntu Core system to a traditional apt-managed system.

I always thought SNAPs were for add on applications and the core OS was supposed to stay with the distribution package manager. But it doesn't get much more core than the bootloader and kernel...

This is an artifact of the focus of your attention. Ubuntu Core, the snaps-only transactional OS, is almost a decade old now - first public release was Ubuntu Core 16, based on 16.04, and that emerged from the work on the Ubuntu Touch phone OS dating back to 2011. You've probably only noticed snaps relatively recently, as using them for desktop-y things is a more recent evolution.

Ubuntu is somewhat behind the curve, here. Ubuntu Core Desktop is still in heavy development; Fedora Silverblue is broadly the same concept, but with Flatpaks, and has been usable for a while.

Ubuntu to add TPM-backed full-disk encryption

ms-tg — Thu, 14 Sep 2023 14:48:26 +0000

>> Press one button and install everything within one hour to get to 100% state as it was before the disaster?
> Yes. This is what happens when you restore a computer from a backup in Windows and Mac OS. You will even have the desktop icons in the same spots.

Heavy +1 to this. It amazes me that the Mac OS examples of how seamless Time Machine backup and restore process works seem not to have spread as far and wide even after many years.

When a Mac OS machine dies, and you have back-ups, you do indeed "Press one button and install everything within one hour to get to 100% state as it was before the disaster".

However, I have seen it take a bit more than 1 hour the last time it happened to me, more like 90 minutes if I recall correctly. But it does work!

Ubuntu to add TPM-backed full-disk encryption

highvoltage — Thu, 14 Sep 2023 08:08:40 +0000

Yep, we've had this in every company I've worked at. If a machine fails for whatever reason, we can just plonk in another one, add it's MAC address and let it run an automated re-installation/re-imaging. This is really by far the easiest overall and the most efficient way of doing things.

Ubuntu to add TPM-backed full-disk encryption

paulj — Mon, 11 Sep 2023 10:53:25 +0000

Pretty sure a family member also killed a laptop motherboard after pouring liquid on it.

Ubuntu to add TPM-backed full-disk encryption

paulj — Mon, 11 Sep 2023 10:52:48 +0000

A child of mine, when a toddler, spent a while pulling and fiddling at a peripheral connector plugged into my Dell XPS laptop. Sufficiently long that they did some kind of damage to the motherboard (the port no longer worked properly, and the laptop now also reports PCIe ECC errors regularly).

Ubuntu to add TPM-backed full-disk encryption

arsen — Mon, 11 Sep 2023 00:15:17 +0000

hi, TPM based FDE user here, this is fully false. see PCR 7.

note that not a single PCR even enrolls programs that come after the kernel anyway.

Ubuntu to add TPM-backed full-disk encryption

mpg — Sun, 10 Sep 2023 15:33:46 +0000

75 bits is quite a lot. Back when SHA-1 collisions required 2^80 evaluations of SHA-1, they were considered impractical. It's only when researchers got it down to 2^63 evaluations that it was finally done in practice. According to the SHAttered FAQ, that was "the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations".

IMHO if an organisation is able and willing to spend such a computing effort in order to get to your data, then they probably have other, more cost-efficient means of achieving that goal.

For the record, I find that for a small number of passwords that you have to type daily (and I don't have that many "root" passwords - by which I mean those that are not stored in a password manager), memorization is a non-issue. Personally I use some variant of `head -c 7 /dev/urandom | base64` (or `xxd -p | tr '0123456789abcdef' 'sdfghjklertyuiop'` which I find makes things easier to type) and never had any memorization issue.

(I'm happy with 56 bits of entropy, because the encryption scheme uses a purposefully slow key derivation function, as others have already mentioned - and if it doesn't, then again it probably has bigger flaws as well.)

Ubuntu to add TPM-backed full-disk encryption

gmgod — Sun, 10 Sep 2023 08:46:17 +0000

I don't agree with the "there is a single good way of tackling this". I loathe it actually because it is done without intelligence.

Alternatives could involve registering a key file that is centrally managed like any other secret by the organisation or a long proved-random "password" automatically generated by a machine.

Those solution don't reduce security for all intents and purposes.

Also, TPM lends itself very well to being used for OS protection. User data is probably better served by a hardware token they control (like a yubikey) if it has to be hardware based so that's yet another solution to gain flexibility while not being stranded if the way to unlock user's data is unavailable.

Ubuntu to add TPM-backed full-disk encryption

gmgod — Sun, 10 Sep 2023 08:37:03 +0000

That's how systemd-cryptenroll works (well, if you ask it to). That password would be long (insanely) and generated automatically so effectively random and non-bruteforceable.

Btw, if womeone wants something similar, i.e. trusted boot for themselves, custom-key secureboot + LUKS-protected data with systemd-cryptenroll is working very nicely.

It also supports fido hardware keys for whatever partition (so would be a good idea for /home on a single-user system).

I'm only mentioning this because that solution has existed for a long time, it works very well (actually systemd-cryptenroll is basically a C script) and does not involve snapd.

Ubuntu to add TPM-backed full-disk encryption

salimma — Sat, 09 Sep 2023 21:40:35 +0000

This. I manage my distrobox containers with Ansible, so it's easy to have a consistent environment across different host machines and different containers (eg I might want a Fedora Rawhide dev environment to reproduce build issues with an upcoming Python release)

No whole-machine backups?

zblaxell — Sat, 09 Sep 2023 21:09:07 +0000

This! Linux has excellent tools for managing guest system data. We can backup a guest and restore it (and replicate it to other hosts, and roll it back after a bad ad-hoc upgrade, and roll it forward atomically to a configuration-managed upgrade, and audit the offline copy for compliance, and fork a copy for development or testing, and..., and...).

We can do all that to the host system as well. The host system is essentially an EFI application with a big database (usually consisting of a number of block devices with partitions containing filesystems, sometimes complicated by encryption). Why would we expect a backup+restore cycle of a physical host to be less complete than our virtual ones?

Ubuntu to add TPM-backed full-disk encryption

faramir — Sat, 09 Sep 2023 17:47:59 +0000

And what percentage of the (already very selective) readers of this web site, do you think were even remotely aware of this information before your post? I am reminded of Arthur C. Clarke's 'law':

"Any sufficiently advanced technology is indistinguishable from magic."

Ubuntu to add TPM-backed full-disk encryption

kreijack — Sat, 09 Sep 2023 14:54:49 +0000

> Oh come on. Have you ever seen such a system for a workstation computer?

Yes, I saw these, and these work well. It is not very complicated to do a similar setup that can satisfy 90% of the user.
This because 90% of the user has very low requirement: an web+email client + {libre}office is enough. And likely in the near future only a browser will be enough.

In my company the PC arrived already configured with the most common software; and the files are already in the cloud; so replacing a PC requires only to login to the new one (and wait the download of the files from the cloud).

The key is the "90%" above. This works very well for the mast majority of the people that have low requirement.

This doesn't work for people that relies massively on complex tools (3D Cad, HW Cad, Software developments, or computer which acts as server ...), were the setup in not canonized (even tough it could be done easily, but it would requires specific setup from the IT and this doesn't worth).

So even tough you can't solve all the problem for all the people, you can massively reduce the load of the IT people.

And, even I never go deeply in this topic, my understand is that for every PC the key to unlock the disk is stored in the TPM, but the IT has another key to unlock the system when (e.g.) an upgrade doesn't work, leaving the system un-bootable (which is the major risk when you put the key inside the TPM).

No whole-machine backups?

HenrikH — Sat, 09 Sep 2023 14:38:40 +0000

Indeed, the great thing about a very simple (when it comes to file hierarchy) like Linux is that you can tar the entire disk and just untar on a new drive and you are good to go.

Ubuntu to add TPM-backed full-disk encryption

Cyberax — Sat, 09 Sep 2023 13:02:30 +0000

If you use a dictionary of 32768 words, then it's just 5*15 = 75 bits of entropy. It's not _that_ large.

Ubuntu to add TPM-backed full-disk encryption

mpr22 — Sat, 09 Sep 2023 11:56:08 +0000

> Bad capacitors was - iirc - notorious about the year 2000 time frame. Can't remember what happened or why, but a BIG batch of dodgy capacitors ended up in the motherboard manufacturers inventories.

The general consensus appears to be "incompetent industrial espionage".

https://en.wikipedia.org/wiki/Capacitor_plague

Ubuntu to add TPM-backed full-disk encryption

jwarnica — Sat, 09 Sep 2023 02:21:22 +0000

The same way you get data of a disk you physically possess, by whatever means.

Ubuntu to add TPM-backed full-disk encryption

Wol — Fri, 08 Sep 2023 21:41:33 +0000

Bad capacitors was - iirc - notorious about the year 2000 time frame. Can't remember what happened or why, but a BIG batch of dodgy capacitors ended up in the motherboard manufacturers inventories.

There was a whole spate of articles about how to tell if you had a dodgy motherboard. Then all the dodgy mobos died-were retired, and it's no longer a problem.

Same with hard drives. I think it was the Thailand floods or something, there was a massive shortage of disks and a lot of dodgy components, and - particularly with Seagate - a huge number of dodgy 3TB hard drives flooded the market. They disappeared over a few years, and things were back to their reliable norm.

At the end of the day, be it hard drives, NVMe, RAM, mobos, these things all have an expected lifetime. And mobos seem to be either (a) one of the most reliable things, or seriously prone to being obsolete before they fail. You never really ever heard of mobo problems apart from that (admittedly very large) dodgy batch.

Cheers,
Wol

Ubuntu to add TPM-backed full-disk encryption

rgmoore — Fri, 08 Sep 2023 21:05:51 +0000

Motherboard failure is definitely a thing. The big one you'll hear about is bad capacitors, though it sounds as if that more frequently causes stability problems rather than catastrophic failure.

Ubuntu to add TPM-backed full-disk encryption

rgmoore — Fri, 08 Sep 2023 21:01:54 +0000

If you're worried about your data on a stolen/lost laptop, and are using disk encryption as a countermeasure against that, you've presumably *already* thought about how you're going to regain access to your data after such an event (i.e., backups)!

Yes, I think this should be the key lesson. If you're worried about data loss, protect yourself against data loss. Being able to transplant the hard drive into another computer when something else fails is at most a convenience feature. You still need to be able to recover from a hard drive failure, so you should probably think about how to do it as efficiently as possible anyway.

Ubuntu to add TPM-backed full-disk encryption

ibukanov — Fri, 08 Sep 2023 20:28:45 +0000

The only motherboard that died on me for the last 30 years was one that I accidentally short-circuited when trying to measure it with a ruler that had a metal edge. CPU and the hard disk survived.

On the other hand I have Dell XPS laptop from 2016. It recently refused to boot. As the error happens very early in the boot process, I initially assumed it was my first non-acidental motherboard failure. It turned out it was failed SSD. UEFI firmware changed its state into a buggy one when disk misbehaved. Then it refused to boot with that state. Fortunately it was still possible to reset the state. Then after changing SSD everything was fine.

Ubuntu to add TPM-backed full-disk encryption

ibukanov — Fri, 08 Sep 2023 20:15:56 +0000

One can remember a passphrase of 5 random English words. That plus expensive to calculate hash makes it outside computational capabilities of anything in the next 30 years even assuming that Moore's law holds. And then as computational capabilities increase, one increases hash complexity.

Ubuntu to add TPM-backed full-disk encryption

somlo — Fri, 08 Sep 2023 18:36:11 +0000

*merely* a foot gun (I should also *look* at the screen while typing :D )

Ubuntu to add TPM-backed full-disk encryption

somlo — Fri, 08 Sep 2023 18:34:55 +0000

> Everything might die

I guess the moral of the story is: If you're worried about your data on a stolen/lost laptop, and are using disk encryption as a countermeasure against that, you've presumably *already* thought about how you're going to regain access to your data after such an event (i.e., backups)!

Otherwise simply do *not* enable disk encryption: In the absence of a threat model like described above, it's nereky a foot gun waiting to go off :)

Ubuntu to add TPM-backed full-disk encryption

lunaryorn — Fri, 08 Sep 2023 17:55:40 +0000

Does anyone know how this compares to systemd-cryptenroll or clevis? Or does it use either of this those under the hood?

The blog article doesn't mention prior art such as clevis or systemd-cryptenroll, so it's unclear to me what's really new with Ubuntu's approach here.

Ubuntu to add TPM-backed full-disk encryption

demfloro — Fri, 08 Sep 2023 16:32:01 +0000

>A BIOS update changes the TPM PCRs and invalidates all the keys.
Not entirely correct. BIOS update can change PCR0 (Firmware Code) and PCR1 (Firmware Settings), this is true only if distro or machine owner decided to seal TPM secret to PCR0+1 among others.

Sane way to seal LUKS secret is PCR7+11 if systemd-stub is used. PCR7+11+14 if systemd-stub and Shim are used. Then you seal the secret specifically to known combination of PK+KEK+db+MokList+SecureBoot state and kernel+initrd+kernel cmdline.

PCR7 - SecureBoot state (+ Shim measuresements if it's used)
PCR11 - systemd-stub UKI measurements
PCR14 - Shim measurements

https://www.freedesktop.org/software/systemd/man/systemd-...

Bitlocker uses not magic, but PCRs other than 0 and 1 for sealing: https://github.com/tianocore-docs/edk2-TrustedBootChain/b...

Ubuntu to add TPM-backed full-disk encryption

geert — Fri, 08 Sep 2023 14:03:26 +0000

Everything might die. And if your power supply dies, it might take your motherboard components (and some/all components attached to it), too.

Ubuntu to add TPM-backed full-disk encryption

Wol — Fri, 08 Sep 2023 13:04:00 +0000

> I have seen may disks die, but I have never seen a motherboard die (anecdotal evidence, I know).

If it's your personal experience DON'T CALL IT AN ANECDOTE. A court of law would call it evidence. As a scientist, I've known about 3 hard drives fail, and nary a motherboard, so if I'm doing an experiment I'd call that a reliable data point.

"My experience is" is an indisputable fact. "A lot of people have told me" is where we get into the realms of anecdotes and hearsay. But even then, if you make a point of rigorously recording what people tell you, "nobody told me they'd had a motherboard fail, lots of people said they'd had hard drives fail" is circumstantial evidence more than sufficient to drive a high-probability conclusion.

There's nothing wrong with other peoples' reports, provided (a) you're careful to make clear where your data came from, and (b) you are careful about the trustworthiness of the reports. But a report of your own experience is a hard fact - FULL STOP! (It might be a mistaken report, but that's another kettle of fish entirely.)

Cheers,
Wol

Ubuntu to add TPM-backed full-disk encryption

smoogen — Fri, 08 Sep 2023 11:57:53 +0000

I can say that Windows restores only work if the user and the applications install things in a way which can be 'restored' easily. I ran into this with my son's laptop recently where half of the apps were 'partially' restored. Parts of them were in user directories which onedrive caught and the other half were in places not normally backed up. Removing and reinstalling was not easily possible because the parts which did that were the bits not backed up. The registry keys were there so I couldn't easily reinstall as it kept complaining there was an existing thing there.

I expect that if I were a full time Windows admin I would have been able to get around this but I am not so it ended up being a reinstall from scratch . Having this happen now with 3 times this year, I really should learn

I have been impressed with the Mac on this because it does seem that time machine and other things will allow for most things to be restorable and comparable. It is what I consider the killer app for self-administration as it has solved a lot of little issues. Its not perfect, but it is a lot better than anything I have dealt with recently on Linux or Windows.

Also I didn't take your comments as bragging. I took them as 'this is possible' which can be helpful for us sysadmins who tend to get in a rut and also think nothing can be better than the pig sty we live in :)

Ubuntu to add TPM-backed full-disk encryption

magi — Fri, 08 Sep 2023 09:19:01 +0000

yup. I got tired of installing my various Linux laptops/desktops from scratch every now and again. They are all managed with ansible now. It's not that tricky and you stop worrying about trashing your systems...

Ubuntu to add TPM-backed full-disk encryption

mfuzzey — Fri, 08 Sep 2023 07:55:24 +0000

>SnapD-based INSTEAD OF DEB BASED

Yes I don't really understand it.
From reading the article it seems you can either have TPM based FDE with SNAP or non TPM based FDE with DEB (which they promise isn't going away...)
But is there a good reason to link TPM and SNAP?
I don't think so, other than they have aparantly already done it that way for Ubuntu Core.

I suspect there is a significant subset of users who would like TPM based FDE for the security benefits but would prefer to stay with DEBs.
I always thought SNAPs were for add on applications and the core OS was supposed to stay with the distribution package manager.
But it doesn't get much more core than the bootloader and kernel...

Ubuntu to add TPM-backed full-disk encryption

abo — Fri, 08 Sep 2023 07:45:26 +0000

After I switched to using toolbx/distrobox it became really easy to leave the OS alone.

Ubuntu to add TPM-backed full-disk encryption

marcH — Fri, 08 Sep 2023 06:05:29 +0000

> How do you move the disk to a different computer if your motherboard dies?

> And you might imagine, that this always happens at the worst time possible when that work (tm) has to be finished by tomorrow evening.

Err... no. I've seen many disks die. I remember about just one motherboard becoming flaky and it was still booting most of the time.

I'm not saying you shouldn't prepare for this situation; you should. A recovery key is probably the best option and in fact my IT department has one escrowed for every device. Also useful when you forget your password :-)

But this situation should definitely not be at the top of the list. There are other, much better reasons to do backups.

Ubuntu to add TPM-backed full-disk encryption

eduperez — Fri, 08 Sep 2023 06:01:22 +0000

> How do you move the disk to a different computer if your motherboard dies?

I have seen may disks die, but I have never seen a motherboard die (anecdotal evidence, I know). The point is, I would always have a back-up of all the data in that disk, not because it is encrypted and I could lose all the data if the motherboard dies, but because the disk could die, encryption or not.

Ubuntu to add TPM-backed full-disk encryption

geofft — Fri, 08 Sep 2023 01:04:49 +0000

So, I'm comparing that with the team of folks at my last job (a team I was also on) who put Debian packages together when people needed stuff that wasn't packaged or wasn't at the right version. We also prevented most people from having root there, and this also served to ensure that people weren't creating irreproducible machines - but the cost was that people basically couldn't try out any software at all without our involvement.

What I'm advocating for is a system where the team that officially maintains your computers, no matter how big or small that team is, doesn't feel like they have to choose between blocking short-term productivity or creating long-term risk. There usually will be a few people who know enough to install software and cobble things together even if that isn't their job on paper (and they therefore don't have root). Give them the ability to cobble things together, but also ensure their cobbling is recorded somewhere, and isn't just some hackery in their home directory. And if that team is one person, or even zero, there's still a way forward.

And I'm also posting this not to boast about our in-house system but to lament that we had to build one (and did not open source it). I think it might be relatively close to possible to get there with Nix these days, though it's both a fairly steep learning curve as well as an involved conversion from basically any existing system. I think there could be really good FOSS tools for this. I think these tools could be good enough that the average home user - who by definition has a corporate sysadmin staff of zero - can get their setup for installing the right graphics drivers and workarounds recorded in exactly the same way.

I think we (the FOSS community) actually sort of lost our lead: up until maybe the early '00s, Windows and Mac users basically did not have privilege separation at all, and were running everything as effectively root. Installing stuff was just copying files, uninstalling was hoping for the best, and "DLL hell" was a Windows problem. The Linux distros and the BSDs were the ones who said, even if this is your personal computer, run as a non-admin user and use well-defined packaging systems. Now, as another commenter alluded to, Windows and Mac OS have moved towards a model where the OS is read-only, applications are in their own private directories (and often sandboxed), and it is absolutely possible to restore the state of a Windows or Mac machine just by restoring user-level files and config. We haven't kept up, and I would bet there is much more "DLL hell" in practice on Linux machines than Windows ones today.

A few projects like NixOS and Spack are going in the right direction for specific use cases, but they're not commonplace. The Ubuntus and Fedoras of the world should do this too - and in a way that empowers users to try stuff out as opposed to just locking them out of the system and indeed makes them more confident about trying things that might not work.