Bypassing disk encryption on systems with automatic TPM2 unlock

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise.

Entering a password on boot isn't even that much work

On servers, it protects against someone stealing your disks (or stealing the raw bytes from your disks) and then booting them in a copy of your machine.

> Entering a password on boot isn't even that much work

It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot.

There has to be a better way.

If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.

Is the boot time password unlock occurring in GRUB or after the Linux kernel has started? If the latter you should be able to setup an SSH server to run in that early boot environment, that’s how I can remote unlock drives on NixOS.

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew.

Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). Typos can take a toll too because of all the delays included.

> There has to be a better way.

Probably Clevis and Tang, network disk decryption that can only decrypt if most of your servers are online. https://github.com/latchset/clevis https://github.com/latchset/tang

Or network decryption (SSH into initrd). https://github.com/gsauthof/dracut-sshd

Between consciously encrypting with a user-supplied password, and not encrypting at all, automatic encryption seems more like a nuisance/hazard for recovery than anything else.

Consciously encrypting with a password implies an understanding of the risk of permanent loss. Leaving it unencrypted implies an understanding of the risk of disclosure. Having your drive silently encrypted feels like the worst of both worlds. "I never encrypted or locked it, what do you mean my data is encrypted and gone forever!?"

> I don't understand why anyone would use passwordless disk encryption.

I'm using it on my home server that I'm using for self-hosting. This way, if it's stolen, the thief won't be able to easily get to my data. At the same time, I don't have to physically enter the password if my server reboots.

It's just not practical. How are you going to manually enter the password for let's say 10 servers?

Passwordless TPM FDE effectively "pairs" your HDD(s) with the TPM module such that the data on the drive(s) is inaccessible without it or a strong LUKS password if added.

Using even a weak pin/password will allow you to both "pair" and "secure" assuming the TPM is configured to destroy the key on multiple failed attempts.

You should also add a strong (high entropy) LUKS password to allow data recovery in case the TPM chip is lost or the keys are destroyed.

Note that the bits of the encryption keys are present somewhere in the TPM and could in theory be extracted with an exploit or with scanning probe microscopy perhaps.

You do not even need to enter a password.

Use a randomly generated key. Retrieve it from an USB drive at boot (it does it automagically), which contains everything, giving you full plausible deniability without it. It means literally everything you need to boot up is on the USB drive, and if you so want it, you can use 2 separate USB drives.

This is for computers you have physical access to, of course. You will need to carry the USB disk if it is a laptop, but you choose: you want to enter a password (which by itself gives you no plausible deniability BTW), or you want plausible deniability and/or you don't want to enter a password. And while we are at it, laptops (and even desktops) today have SSD, and encryption and plausible deniability is different for an SSD, but again, you choose. Right tool for the job.

https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...

USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.

There is: https://news.ycombinator.com/item?id=42734841.

A weak password is always better than no password. It's like using a cheap lock on your door or not locking it. Practically, if a thief wants to get through he'll get through but your insurance and sentencing will look different.

There is, I use kexec to boot a modified cpio containing the fde password, since cpio can be extended by concatenation. https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...

It's the same technique grub uses to forward the FDE password to the initramfs after its own initial decryption (to read the kernel and initramfs). This works to reboot remote servers with FDE, without needing a vnc or earlyboot-sshd.

Try having a chat with a HCI person. Or in a pinch ask a LLM to emulate one for you. It's a useful perspective to have for a lot of stuff.

> I don't understand why anyone would use passwordless disk encryption

You want to install and operate a device at a remote site with restricted (or no) VPN access and where you don't trust the local staff?

I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine.

This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.

A remote KVM, i.e TinyPilot will help avoid dealing with lack of trust in local staff. Additionally connection to the KVM can be done over LTE/Cellular if you don't trust the local connection too.

I set up a server last year which is at a remote site which is completely air-gapped from the Internet, it's allowed to see one local LAN and that's all. For any kind of admin task someone has to drive to site.

There is precisely zero chance that the relevant IT security goons would allow any kind of remote KVM/LTE connection.

Going around 10 servers with a USB drive sounds just as tedious, and what happens when you lose the key or the attacker gets it?

Some systems need to boot without a (trusted or skilled) user present.

Encrypted data are noise now, maybe, but may be decryptable in the future with advances in computing.

So all this depends on what you worry about.

> Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?).

So does-it means you do not setup a password/passphrase for your user account?

That is what remote kvm are for and if you do that on commodity hardware you can start a tiny ssh server starting up from an initrd. Having said that an attacker with local access could change the initrd without your knowledge so that it logs the password you enter so it is not necessarily the most secure solution.

Google: IPMI, BMC

I also use a fedora.

Typically I use offline upgrade if I mean to poweroff but otherwise I just run `sudo dnf update -y && sudo systemctl reboot` in a terminal if I want a quick update&reboot.

On another laptop I am using silverblue (well bluefin) and the atomic upgrades solve the issue completely.

Imagine a big corporate workplace, where the infosec team wasn't comprised of freewheeling anarchic hacker types who've dedicated their career to mastering the intricacies of the Linux boot process, but instead by compliance folks who've dedicated their career to mastering the intricacies of global privacy laws and passing SOC2 compliance audits.

From their perspective, "Secure Boot" has the word "Secure" right in the name. And they've looked up details about the TPM - Microsoft says the TPM avoids systems being tampered with, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.

If you don't know the intricacies involved, that stuff all sounds great! So they put a line into the corporate IT policy that TPM use is mandatory.

You’ve answered it yourself. Without TPM you have no idea if you can provide the secret to the system or if it’s compromised. Whether that secret comes from TPM or network is secondary.

How does this make sense?

Any change the untrusted local staff could make to the server, they could also make to the KVM machine (e.g. turn it into a keylogger).

Now you have the same problem but with a smaller computer.

You cannot turn untrusted systems into trusted systems by adding more untrusted systems.

I use auto login (control userpassword2 still work to set that up on Windows11) on my gaming computer in the living room! If I could that user account wouldn't have a password.

But my work computers requires a pin to boot and a password that only my yubikeys (bind the static password to the long press) knows to login. different policy for different context...

You can reboot your full-disk-encryption server while you sleep. Obligatory plug: <https://www.recompile.se/mandos>

Disclosure: I am a co-author of Mandos.

Most of this concern is around certain public key cryptography algorithms which depend on math problems being extremely hard to solve but could in theory be mathematically solved (decrypted without the key) with a good enough quantum computer.

Disk encryption (AES etc) is symmetric and still only brute-force would work which can be made infeasible with a long enough key.

Has this solution been audited? In particular, is it safe to replay attacks by actors listening in to the network traffic?

Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?

Brute-forcing symmetric encryption is a somewhat silly concept anyways, because each decryption is equally valid.

That's only true for information theoretically secure algorithms like one-time pad. It's not true for algorithms that are more practical to use like AES.

> Has this solution been audited?

Only insofar as everybody that I’ve asked over the years has failed to find anything wrong with it. But no formal verification has been done.

> In particular, is it safe to replay attacks by actors listening in to the network traffic?

Yes, it is safe, since we make sure to only use TLS with PFS.

> Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?

No, the secret is stored encrypted on the server, encrypted with a key which only the client ever has.

For more information, see the introduction and FAQ: <https://www.recompile.se/mandos/man/intro.8mandos>

It's always felt like the best way to lock myself out of my own machine. While I don't really keep any important data on it that's not backed up, I also don't build my workstation image from a config file or anything, so some time will be lost. The thing that's always bugged me is that before AMD had a TPM built into the CPU, the TPM was just a poorly-secured dongle hanging off the motherboard (at least with Asus motherboards) and it just seems like something that's going to break randomly. That breaks, then what. Meanwhile, the CPU owning the keys also doesn't feel great. Sometimes you swap your CPU and now there is an 800 step process to disable decryption before you do that, which is certain to be forgotten as you excitedly unpack your new CPU purchase. (Even if you're completely rebuilding the computer, the number of times I've put a new disk into a new build is approximately zero.)

Just typing a passphrase at boot seems like a pretty decent compromise. I've done it for years and it's never caused a problem.

Thank you for this. I will almost certainly be deploying that.

I sympathize with your points, especially rebuilding the box from scratch.

But all the “passwordless” schemes I’ve seen support at least an additional “master key” which you can type in.

So if you’re ok with the security tradeoffs of passwordless tpm, it’s only an added convenience on top of your approach.

This was actually a problem for me on my current gaming PC build!

I had switched to a new AM4 mobo a few years back and decided to spring for a pluggable TPM chip (since the CPU I have doesn't come with TPM onboard). Plugged it in, set everything up pretty seamlessly in windows, no fuss, no muss, boot drive's encrypted transparently. The lack of a password was a bit jarring at first, but it's a gaming PC, so if things go pear-shaped it's not the end of the world.

Fast forward six months and my PC suddently refuses to boot; turns out the pluggable TPM thing was defective and stopped working (without any warning that got surfaced to me).

It was just my boot drive, and reinstalling windows isn't a huge hassle, but it definitely cemented my mixed feelings about passwordless FDE. Had that been the drive I use for my photo library, or my software projects, or work-related documents (tax slips, employment contracts, whatever), that would've been devastating.

It's actually made me rethink the strategy I use for my laptop's backups, and I think I'm in a better place about that now.

I believe with software-based encryption (LUKS and the like), the decryption key ends up being stored in RAM, which will always present a risk.

And TPM-based solutions don't have this problem. Could be wrong though.

Don't all AM4 CPUs feature fTPM which is a firmware-based TPM? Bitlocker at least accepts this as secure enough to boot Windows 11.

I think most TPM based solutions still use software encryption. Most TPMs don't have the bandwidth to actually decrypt all disk data as it is read. (I think Apple devices do actually do something like this, but I don't think it is common.)

I believe when using TPM with LUKS the TPM just decrypts the master key and that is handed back to the OS and used in software. So the primary key does end up in RAM.

No, I use biometrics login for the same reasons. I have a strong password, but 99% of the time, I don’t need it.

As I said before, if someone’s determined enough to spend a lot of time find OS level vulnerabilities and exploit them to decrypt my disk, they will certainly have enough time and determination to break a weak password.

I would consider it for my hosted server.

Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have).

Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. And I could store a recovery key somewhere I think is safe in case of hardware issues (although, last time I had hardware issues, I simply restored from backup to new to me disks)

> Encrypted disks is a requirement because I don't trust the facility to wipe disks properly.

Couldn't you wipe the disks yourself?

Or are you thinking of cases where the disk breaks, gets replaced, and the removed disk does not get properly destroyed?

Frankly, it's possible; I don't remember at this point. At the time, I just decided to go for a separate chip since I hadn't heard of fTPM being available at the time. The chip in question's a 3900X and it's still running smoothly.

> Brute-forcing symmetric encryption is a somewhat silly concept anyways, because each decryption is equally valid.

Each decryption is equally valid as long as the key has the same size as the data. What happens, in practice, is that the key is much smaller than the data. Take a look at your filesystem, it should have hundreds or thousands of bytes of fixed information (known plaintext), or an equivalent amount of verifiable information (the filesystem structure has to make sense, and the checksums must match). That is: for a large enough filesystem (where "large enough" is probably on the order of a small floppy disk), decrypting with the wrong key will result in unrecoverable garbage which does not make sense as a filesystem.

To give an illustration: suppose all filesystems have to start with the four bytes "ABCD", and the key has 256 bits (a very common key size). If you choose a key randomly to decrypt a given cyphertext, there's only one chance in 2^32 that the decryption starts with ABCD, and if it doesn't, you know it's the wrong key. Now suppose the next four bytes have to be "EFGH", that means only one in 2^64 keys can decrypt to something which appears to be valid. It's easy to see that, once you add enough fixed bytes (or even bits), only one key, the correct one, will decrypt to something which appears to be valid.

Fully agree, especially for a laptop. A password that combines three unrelated words and a few numbers takes about 3 seconds to type in.

I shut it down every day, so type in the password every day too. Short of a concussion, I'm not going to get locked out.

So.. it is possible…

You can add alternative Bitlocker decryption mechanisms including a strong password using manage-bde CLI tool. Also, Bitlocker gives you the opportunity to save your recovery data externally in case you lose all your authentication mechanisms. I'm surprised that you lost your data.

Yes.. it is...

It's a risk I'm fine with. Anything I care about is backed up separately.

They'll have your data if they just take the whole server...

Dropbear is the solution for this.

Sometimes yes, but if there's a hardware issue, I may not be able to.

Ex: the first server I had failed and they ended up replacing it with a different server with similar specs, but the drives werem't moved. In this case, the failure was gradual (resetting by itself) and as part of debugging it, I wiped the drives and installed a new OS, but towards the end, the amount of time between resets was very short, and I wouldn't have had a chance to wipe it if I had started later.

Yes, this isn't great service, but it's personal hosting and it's cheap and I get a whole (very old) machine.

And then what? They will be faced with a login prompt. Reading from disks is useless. My login password is strong.

Well, if the FreeBSD installer would set that up for me, I probably would have done it that way, but lazy, and I don't reboot that often.

It's pretty fast to destroy all the keys in a TPM. Should take a minute if you know the right place to go. Meanwhile securely deleting a normal drive requires overwriting every sector with random data, which could take hours. So it also helps if you're giving away the whole machine.