Hacker News Reader

Comment by pzmarzly | Hacker News Reader

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

View on HN

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.

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

Side note, does anybody know why TPM schemes use a numeric PIN for pre-boot unlock rather than a full alphanumeric password? For a given length (say, 8) a password would presumably be more secure than just a PIN. It’s not like this is a phone where you need users to be able to quickly enter the code on a limited input surface.

With systemd you can enroll any string you want as "PIN" for tpm. There are no restrictions. Can be long, can be alphanumeric, contain weird chars, up to you.

If you're going to use a long password there is no point to using the TPM as the length of the password itself is enough brute force resistance.

Some you know + something you have/are?

I don't think it is that much more secure, given that in this case "something you have" is bolted onto the machine you're attempting to protect and that a sufficiently long password provides enough space to make brute forcing impossible anyway.

In my opinion all the TPM achieves in this case is ensuring you lose your data if the machine dies (or if some OS update fucks up and doesn't properly ensure the TPM acknowledges the new version as valid).

That said it does help against the so called evil maid attacks, given that it would lock itself out if anyone modifies the OS, so if that's part of your threat model then it is useful, I guess.

Even with a TPM the disk is still fundamentally encrypted with a key that you can make a copy off and put in your drawer for recovery purposes. It just offers a way to do FDE with no or just a low entropy passcode. This protects against most data loss incidents (laptop getting stolen) without producing massive overhead.

> rather than a full alphanumeric password

Because there are different kinds of keyboards out there, with different layouts, so if you switch keyboard you could find yourself unable to input the password. Imagine typing a "non-English" letter in the password and then switching to a US layout keyboard without that letter. Sure, a rare scenario, but with hundreds of millions of users you will hit it.

French keyboards have the numbers and symbols swapped. The numbers require shift.

This is just the default configuration BitLocker used for a long time, there is a no hardware constraint that causes this. However, pins are easier to remember, usually guaranteed to be available at the pre-boot time the tpm needs unlocking and as the TPM ships with anti-hammering abilities they offer sufficient entropy to protect against attacks.

for windows 10 pro+: you can get full alphanumeric+special_chars ONLY if you do some gpedit stuff

(for win home users: regedit?)

There is no limit to the password. Usinging a 4 digit numeric PIN is just easier to remember, and because of the bruteforce resistance it doesn't decrease the security.

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

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.

> at the cost of having to enter it at boot

Isn't this the entire point of full disk encryption? You mention cost, but what is even the benefit of encryption that's unlocked by just booting?

With properly functioning secure boot and no bugs in the entire software stack, it doesn't matter if the disk is decrypted automatically, since you can't access the system without OS-level authentication. If you tried to replace system files to let you get in anyway, the secure boot measurements would no longer match up and the decryption fails entirely.

Then again, an attacker can read the decryption key from RAM (freeze and remove the modules, then dump the memory on another system) and decrypt the disk offline.

So, data on a stolen laptop which has an unprotected TPM (no PIN to boot) can be considered compromised.

There are such things are RAM encryption, but yes, overall it's more fragile from a security perspective than a strong plain passphrase.

So you use soldered RAM. And the OS provides hardened memory areas that can't be dumped.

I use a very long and inconvenient password for LUKS, and a simpler one for login and root. My lock screen is more a convenience in a trusted environment and not security. The TPM only solution sounds like it would require my very long password every time I leave my desk to get coffee.

Relying on no bugs in the entire software stack makes the attack surface quite large.

If a laptop is stolen the thief can wait sufficiently long for some vulnerability to be discovered somewhere in the stack. With LUKS only the LUKS encryption has to be good and full disk encryption protects the data.

> You mention cost, but what is even the benefit of encryption that's unlocked by just booting?

Ideally, your login screen is secure and allows no bypasses into a shell or similar, so you cannot really access any files on the hard drive.

And if you modify some system files or boot another operating system to get around this, you are required to know the disk encryption password to get to them.

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

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.

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.

> yubikey's modhex alphabet

For the curious, to avoid "most" QWERTZ/AZERTY differences among Latin layouts:

cbdefghijklnrtuv

Oh cool. Does that mean the TPM key is set up to use one of the LUKS key slots?

Yes, a tpm2 enrollment takes up one slot, the recovery key another, a fido2 yet another, a pkcs11 key yet another and a password yet another in any combination/subset you like.

That's a highly unusual attitude for systemd. Most of the systemd architecture requires you to run systemd for everything if you use it at all. What changed?

Nothing changed. You are just a victim of FUD on the Internet, my friend. That's all.

Why does this remind me of something a Bitcoin or Gamestop fanatic would say?

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

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?

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

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

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.

With modern file systems like BTRFS you could take a(n incremental) snapshot and send that over the network using btrfs send.

Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice.

Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative).

I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.

Last time I tried to replace my `rsync` backups, `btrfs send` had grave limitations - something like "you can't actually use the destination filesystem for anything other than the one computers backups" I think?

btrfs receive has some limitations for sure. I don't think having the volume mounted is a problem, but during the transfer the snapshot is read/write. If you modify the volume, subsequent differential updates will fail. If you have some other process messing with the snapshot being received, you also risk messing up the send/receive. There are also limitations w.r.t. the way the volume is mounted; if you alter the default mount point or mounted a subvolume somewhere deep in the chain, receive will also fail.

If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem.

I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.

Reply on news.ycombinator.com