Ubuntu 23.10 Adding Experimental TPM-Backed Full Disk Encryption

[Anux]

There's some fun legal reviews that come out every once in a while with things like "suspect goes to coffee shop, undercover officer A intentionally spills coffee, suspect gets up to get napkins for officer A, undercover officer B grabs unlocked laptop and runs."

Of course, if you use disk encryption you should be aware that it only protects your data if the computer is powered off else you rely on your screen locker which also might be much easier to hack if you even use it properly.

And please don't use a fingerprint reader for unlocking, the whole laptop is covered in your fingerprints, your best chance then is that the police guys might die from laughing at your stupidity.

[billyswong]

That's the way it's usually done though: you need an existing key to make changes like adding a TPM key & token to the LUKS header. You could probably coerce cryptsetup to delete the original and leave just the TPM one, but that would risk making the data completely unrecoverable so it's not the norm or recommended. Bitlocker is similar: it'll unlock with TPM, but it'll generate a secondary key for recovery.

Bitlocker / Cryptsetup etc are handing one a computer generated key string. It is different from normal password. It is not something one can think up by themself, memorized and typed in whenever required. It is something one have to save it either as text file or take picture and save as photo. Then one have to find somewhere "secure" to store the key. So no, the current TPM-backed disk encryption is in my eyes still more vulnerable to data loss than normal password-based encryption.

Jakobson is correct that TPM-based encryption is more about satisfying legalese that corporations being subjected to. I am not objecting to companies using this technology for company-provided laptops handed to employees, as the issue is no longer about real security risk but more about playing along with the legal game.

[Jakobson]

Bitlocker / Cryptsetup etc are handing one a computer generated key string. It is different from normal password. It is not something one can think up by themself, memorized and typed in whenever required. It is something one have to save it either as text file or take picture and save as photo. Then one have to find somewhere "secure" to store the key. So no, the current TPM-backed disk encryption is in my eyes still more vulnerable to data loss than normal password-based encryption.

Jakobson is correct that TPM-based encryption is more about satisfying legalese that corporations being subjected to. I am not objecting to companies using this technology for company-provided laptops handed to employees, as the issue is no longer about real security risk but more about playing along with the legal game.

The Ubuntu Blog post actually explain the feature more verbal. What are your particular security concerns, especially in the latter section?

TPM-backed FDE brings a number of improvements. Because it eliminates the need for users to manually enter passphrases during boot, it provides a lower barrier to enabling encryption on devices that are shared in enterprise environments, and streamlines the boot process in large-scale enterprise deployments, leading to increased operational efficiency.

For users who will choose to use a passphrase (in addition to TPM), they will still increase their security posture, as they will eliminate the attacker’s ability to perform offline brute-force attacks against the passphrase.

[antonyshen]

My work requires me to build custom kernel from time to time, I hope this won't make my life miserable.

[sarmad]

Encryption does not open without that particular piece of HW. Advanced enterprise Android phones already has Secure Element for that purpose. Credit card has a chip instead of cloneable data stripe.
Passphrases/passwords chosen by people usually don't have very strong. Additional binding to HW improves security. Otherwise encrypted disk for example can be cloned and tried to brute-force by mush more faster supercomputers.

So, that means if your computer dies you don't have the option of putting your storage device in another computer, you simply lose that data. Am I right?

[billyswong]

So, that means if your computer dies you don't have the option of putting your storage device in another computer, you simply lose that data. Am I right?

This is an issue that those business-oriented people always downplay and dismiss, as their scenario don't mind this problem.

For computers bought for a company, any business-critical files are supposed to have at least one copy in the local NAS server / traditional server / cloud server. And they can store the lengthy human-unmemorable recovery key for that TPM-backed encrypted boot drive in that server too. So enabling TPM-backed disk encryption is almost cost-free for them.

[Jakobson]

So, that means if your computer dies you don't have the option of putting your storage device in another computer, you simply lose that data. Am I right?

Yes, that's why it's always important to store the LUKS disk's master key in a secure location. Exporting the LUKS master key can be accomplished using cryptsetup luksDump.
However, with LUKS, you have multiple slots available. In another slot, you could use, for instance, a long and complex password or a random keyfile without involving TPM at all to get it open also on other computer.

[mangeek]

What's the benefit of TPM? What does it provide over the traditional way of entering a password upon boot?

Being able to have machines' up and running even when they're not signed in is pretty awesome from a corporate perspective. I can't manage or remotely reboot an unattended Linux box with FDE today.

I can't tell you how many times I've done some remote upkeep to a box over SSH or pushed packages and sent a reboot, just to have the machine fall into a 'black hole' waiting for a passphrase to unlock the system volume afterwards.

[mangeek]

This is an issue that those business-oriented people always downplay and dismiss, as their scenario don't mind this problem.

Yes, and we can automatically escrow the master keys in a vault at deploy time, so there's usually a way to move a drive tied to a TPM of a dead/lost system to another system, retrieve the key from the security team, and get back at the data.

[rohowdy]

I'd put the de-crypt key file somewhere on the encrypted OS partition and mount it afterwards with a script, triggered by a systemctl unit