Hacker News Reader

Comment by INTPenis | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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

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.

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.

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

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

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.

Reply on news.ycombinator.com