On my system, I used `tpm2-measure-pcr=yes` in `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000` with `systemd-cryptenroll`.
As soon as a volume is decrypted, initrd will write `volume-key` to PCR 15, so any further executables can no longer access the data stored in the TPM.
This is great if you only have a single disk, but if you have multiple encrypted disks that are unlocked in the initrd this way, then if you can gain control flow by faking data on the last decrypted disk you can still gain access to all the previously unlocked partitions.
Of course you cannot unseal the secret from the TPM anymore.
When I first read about TPM-based FDE on Linux[0], I was excited that the systemd guys were finally taking a step in the right direction - BitLocker/FileVault were standard on Windows/macOS for a long time by that point. FDE should be secure by default, dead-simple to set up (e.g. a checkbox in the installer that defaults to "enabled"), and painless for everyday use.
Then I read about the implementation details[0], and it's a complex bloody mess with an unending chain of brittle steps and edge cases, that are begging for a mistake and get exploited. So here we are.
I'm convinced that "measure the kernel" into "measure the initrd" into "show login screen" is all it should take.
Of course. The typical Linux initrd is also too complicated. It should be doing this, and nothing else:
- There's an executable called /init, link it statically with everything it needs to do.
- Load kernel modules from a list (hardcoded at build time; optional if you include common modules in the generic kernel).
- Mount the root filesystem (hardcoded at build time) and pivot.
- execve("/sbin/init", ...)
I've built a PoC in pure Go that does all of this, the resulting initrd was ~2.5MB plus kernel modules. I simply moved all the boot-time complexity to build-time. It doesn't do LUKS or TPM yet, but that's also further down the roadmap.
OpenBSD went a step further and crammed FDE decryption into the bootloader. It doesn't do TPM but simple is simple.
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
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
> 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.
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.
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.
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.
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.
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.
Full disk encryption is just inherently a flawed approach compared to per file encryption. Androids approach of only protecting user data with behind the password and otherwise using a separate encryption key to allow the os to boot to the lock screen and some apps to run (eg alarms) is a more user friendly approach. Unfortunately we don't seem to have that sortve option available to us with desktop OS.
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!?"
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.
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.
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.
> 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.
Seems like this could be easily mitigated with a read only root filesystem using dm verity
Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.
Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.
LUKS for encryption and verity for integrity/verification.
The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.
Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs.
Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add:
If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.
The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.
Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.
I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.
I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here.
What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed initrd, just after mounting the filesystem, I assert that hash(/prehash) == expected_hash or crash the system otherwise. Do you think it would be enough to fix the issue?
I was reading another web page (I don't have the link unfortunately) several days ago where another reader pointed out to the author the same type of attack mentioned in this article. To address that attack the author came up with the same solution you proposed and I do believe that is sufficient for preventing the type of attack mentioned in this article. There still are other types of attacks (cold boot attack, sniffing TPM traffic, etc...) that can be done though so it still is a good idea to use a PIN/password, network bound disk encryption, etc... in addition to the the TPM.
I'm currently working on setting up disk encryption for a new home server and as an additional precaution I'm also working on getting the initrd to do a few additional sanity checks prior to decrypting a LUKS partition and prior to mounting the root file system within. One check which I think will be highly effective is that prior to decrypting the LUKS partition I have the initrd hash the entire LUKS header and make sure it has the expected value before allowing the boot to continue. So far it seems to be working OK but hashing the entire LUKS header is overkill which will require some care to make sure the expected hash value is kept updated if the LUKS header changes for some reason (like changing encryption passwords). I can not recommend this idea for everyone consequently.
You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.
Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.
> Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
> You can mitigate this by including PCRs that sign the kernel and initrd
nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.
the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:
1. (temporarily) replace encrypted volume with our own, encrypted with a known password.
2. boot the device.
3. the automated tpm unlock fails, prompting for a password.
4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.
5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.
the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.
At least for PCR 7, it's well specified and documented how the digest is generated. You can dump the component digests of a PCR using `tpm2_eventlog`, and I've written a tool that can be used to populate the requisite data structures for hashing.
It's ridiculous that there's no software implementation to do this, it's a huge problem.
Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.
The "mitigation" itself is still not very safe if you're paranoid about governments or very motivated organisations. The extra step of checking PCR12 is performed by the initrd that you trust because it's signed by a private key that has probably leaked to every serious hacking corp / government. They can just boot their own signed initrd and kindly ask the TPM that will oblige.
I personally replace the firmware certificates (PK, KEK, db, dbx, …) with my own and sign every kernel/initrd update, I also unlock my disks with a passphrase anyways, but I'm on the fence WRT if it's more secure than TPM.
Yes in theory TPM key extraction is feasible (and even easy if it's performed by a chip other than your CPU https://pulsesecurity.co.nz/articles/TPM-sniffing ) but it is harder than filming/watching you type the passphrase or installing a discrete key-logger ?
If you believe that the those SecureBoot private keys were leaked, why not also believe that the linux kernel signing keys were also leaked and that you are downloading a backdoored one.
Long before UKI was a thing, this kind of attack was prevented by hardcoding into an EFI stub kernel the sha512 hash of a trusted initrd that would verify the cryptographic authenticity of the initrd that did the "heavy lifting" (mounting disks etc).
We have had not just secure boot but had it better on Linux (and other Unix-like) systems for a very long time.
So if you use this PCR state machine, the problem is that the step before initrd doesn't require the correct password to move the PCR forward? It accepts any password that decrypts the next stage, which didn't have its integrity verified here.
Seems there are multiple ways of solving this, and adding integrity checks is only one. It could also let the TPM verify the disk decryption password (when it's needed.)
> It could also let the TPM verify the disk decryption password (when it's needed.)
The design intent is basically:
1. The TPM is very sensitive, and errs on the side of not unlocking your disk.
Booting into recovery mode to fix a driver? Reinstalled your distro? Added a MOK so you can install the nvidia drivers? Toggled certain options in your BIOS? The expected-computer-state checksums are wrong, better not unlock the disk as it could be an attack.
2. When this happens, you key in the password instead.
You can't rely on the TPM to verify the manually entered password, as the intent of the manually entered password is to recover when the TPM is in a broken state.
> You are safe if you additionally use a pin to unlock your TPM
Does the default configuration not somehow tangle a user-entered password to authentication against the TPM?
That's still not perfect (i.e. how do you make PIN/password entry non-keyloggable), but anything else, in particular extending the trusted computing base to the entire kernel and the hardware it runs on and hoping that they will both be bug-free and impossible to impersonate, seems like a bad idea.
The TPM is also in a much better position to properly velocity check PIN/password entries than the OS.
The other option is to have an intrusion prevention switch or two in the case so the TPM locks itself in some way and the machine refuses to boot at all without some PKI attestation.
Personally i would like a way to use TMP2 (with PIN) + password. (i.e. mode where PIN is derived from the password, but is also used to encrypt), so that i do not have to trust the TPM manufacturer.
This can be done. Not sure how on Windows/bitlocker but certainly with cryptenroll. Essentially you’d wrap this in your bootscript, though.
So password (or pin) encrypts passphrase, passphrase encrypts LUKS and goes to TPM, then you
need to reverse the process for your init script (request password, decrypt passphrase, exchange with TPM to decrypt LUKS), but it depends on your appetite for planning that out.
Your edit is correct. The kernel and initramfs are exploited unmodified to boot a tampered root filesystem, which allows userspace tools to extract data from the TPM, as the PCRs used to protect data like the LUKS passphrase have not changed.
> Even with the key, one must decrypt and re-encrypt.
That's not true, the unlock key will be regenerated, but the disk contents will not be re-encrypted, because it's encrypted with another immutable key.
Hah, my gist from 2022 is on this post as a "broken guide". I'd disagree in saying it is broken. It works just fine and I flat out say at the top to not use it if you are worried about a cold boot attack on your hardware.
Instead of the luks key in tpm you can use a fido2 compatible hardware security usb token. For booting/unlocking it has to be plugged in then you can remove it. This is pretty convenient and secure against many threats like stealing the nas in my opinion.
On my system, I used `tpm2-measure-pcr=yes` in `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000` with `systemd-cryptenroll`.
As soon as a volume is decrypted, initrd will write `volume-key` to PCR 15, so any further executables can no longer access the data stored in the TPM.
Yes, that seems a good extra level of defense. Allow unsealing only once. We extend a PCR with random data.
This is what Bitlocker does. There was a recent article about it.
This is great if you only have a single disk, but if you have multiple encrypted disks that are unlocked in the initrd this way, then if you can gain control flow by faking data on the last decrypted disk you can still gain access to all the previously unlocked partitions.
Of course you cannot unseal the secret from the TPM anymore.
If you have tpm encryption on your boot disk, then you can simply store decryption keys for your otyer disks on it.
What to do for a single root fs spanned over 2 encrypted partitions on 2 separate disks?
When I first read about TPM-based FDE on Linux[0], I was excited that the systemd guys were finally taking a step in the right direction - BitLocker/FileVault were standard on Windows/macOS for a long time by that point. FDE should be secure by default, dead-simple to set up (e.g. a checkbox in the installer that defaults to "enabled"), and painless for everyday use.
[0]: https://0pointer.de/blog/brave-new-trusted-boot-world.html
Then I read about the implementation details[0], and it's a complex bloody mess with an unending chain of brittle steps and edge cases, that are begging for a mistake and get exploited. So here we are.
I'm convinced that "measure the kernel" into "measure the initrd" into "show login screen" is all it should take.
>> we can confuse the initrd into executing a malicious init executable.
This hash the next link method is always as flawed as the weakest link..
Of course. The typical Linux initrd is also too complicated. It should be doing this, and nothing else:
- There's an executable called /init, link it statically with everything it needs to do.
- Load kernel modules from a list (hardcoded at build time; optional if you include common modules in the generic kernel).
- Mount the root filesystem (hardcoded at build time) and pivot.
- execve("/sbin/init", ...)
I've built a PoC in pure Go that does all of this, the resulting initrd was ~2.5MB plus kernel modules. I simply moved all the boot-time complexity to build-time. It doesn't do LUKS or TPM yet, but that's also further down the roadmap.
OpenBSD went a step further and crammed FDE decryption into the bootloader. It doesn't do TPM but simple is simple.
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
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.
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.
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.
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.
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.
Brute-forcing symmetric encryption is a somewhat silly concept anyways, because each decryption is equally valid.
> 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.
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.
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.
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.
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?
> 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>
Thank you for this. I will almost certainly be deploying that.
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.
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.
Google: IPMI, BMC
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?
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.
Dropbear is the solution for this.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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...
No, I use biometrics login for the same reasons. I have a strong password, but 99% of the time, I don’t need it.
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.
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.
> 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.
> 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
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.
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.
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.
There is: https://news.ycombinator.com/item?id=42734841.
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...
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.
Full disk encryption is just inherently a flawed approach compared to per file encryption. Androids approach of only protecting user data with behind the password and otherwise using a separate encryption key to allow the os to boot to the lock screen and some apps to run (eg alarms) is a more user friendly approach. Unfortunately we don't seem to have that sortve option available to us with desktop OS.
> Unfortunately we don't seem to have that sortve option available to us with desktop OS.
As I understand MacOS uses per file encryption on AFS.
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
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?
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.
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.
It's just not practical. How are you going to manually enter the password for let's say 10 servers?
USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.
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?
You generate a new one and replace it. Those what ifs apply to passwords as well.
It might sound tedious for 10 servers, but passwords are even more so.
For desktop, it is definitely the way.
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.
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.
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.
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.
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…
Yes.. it is...
It's a risk I'm fine with. Anything I care about is backed up separately.
Some systems need to boot without a (trusted or skilled) user present.
> 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.
They'll have your data if they just take the whole server...
And then what? They will be faced with a login prompt. Reading from disks is useless. My login password is strong.
[dead]
Seems like this could be easily mitigated with a read only root filesystem using dm verity
Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.
Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.
LUKS for encryption and verity for integrity/verification.
> If a malicious partition is presented to initrd
The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.
That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4
Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs. Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add: If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.
ChromeOS uses a different solution from AVB, but it works pretty similarly in practice.
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
Any theories on why no one pursues it? Lack of incentives?
That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.
Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.
I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.
Very clever!
I am the author of one of the older guides https://blastrock.github.io/fde-tpm-sb.html .
I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here.
What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed initrd, just after mounting the filesystem, I assert that hash(/prehash) == expected_hash or crash the system otherwise. Do you think it would be enough to fix the issue?
I was reading another web page (I don't have the link unfortunately) several days ago where another reader pointed out to the author the same type of attack mentioned in this article. To address that attack the author came up with the same solution you proposed and I do believe that is sufficient for preventing the type of attack mentioned in this article. There still are other types of attacks (cold boot attack, sniffing TPM traffic, etc...) that can be done though so it still is a good idea to use a PIN/password, network bound disk encryption, etc... in addition to the the TPM.
I'm currently working on setting up disk encryption for a new home server and as an additional precaution I'm also working on getting the initrd to do a few additional sanity checks prior to decrypting a LUKS partition and prior to mounting the root file system within. One check which I think will be highly effective is that prior to decrypting the LUKS partition I have the initrd hash the entire LUKS header and make sure it has the expected value before allowing the boot to continue. So far it seems to be working OK but hashing the entire LUKS header is overkill which will require some care to make sure the expected hash value is kept updated if the LUKS header changes for some reason (like changing encryption passwords). I can not recommend this idea for everyone consequently.
You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.
Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. > Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
You can use tpm2_policyauthorize and allow the PCR to change without having to manually unlock. This was not supported in TPM 1.2.
You can use it with Systemd.
https://github.com/tpm2-software/tpm2-tools/blob/master/man/...
> You can mitigate this by including PCRs that sign the kernel and initrd
nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.
the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:
1. (temporarily) replace encrypted volume with our own, encrypted with a known password.
2. boot the device.
3. the automated tpm unlock fails, prompting for a password.
4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.
5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.
the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.
> 3. the automated tpm unlock fails, prompting for a password.
> 4. type in our password.
In a serious security conscious setup this should be a big red flag to investigate. Any unexpected boot password prompt.
yes of course - but in this case the "unexpected" prompt is presented to the attacker, not the user.
At least for PCR 7, it's well specified and documented how the digest is generated. You can dump the component digests of a PCR using `tpm2_eventlog`, and I've written a tool that can be used to populate the requisite data structures for hashing.
https://github.com/balena-os/tcgtool
It's ridiculous that there's no software implementation to do this, it's a huge problem.
Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.
That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
The "mitigation" itself is still not very safe if you're paranoid about governments or very motivated organisations. The extra step of checking PCR12 is performed by the initrd that you trust because it's signed by a private key that has probably leaked to every serious hacking corp / government. They can just boot their own signed initrd and kindly ask the TPM that will oblige.
I personally replace the firmware certificates (PK, KEK, db, dbx, …) with my own and sign every kernel/initrd update, I also unlock my disks with a passphrase anyways, but I'm on the fence WRT if it's more secure than TPM.
Yes in theory TPM key extraction is feasible (and even easy if it's performed by a chip other than your CPU https://pulsesecurity.co.nz/articles/TPM-sniffing ) but it is harder than filming/watching you type the passphrase or installing a discrete key-logger ?
> sign every kernel/initrd update
If you believe that the those SecureBoot private keys were leaked, why not also believe that the linux kernel signing keys were also leaked and that you are downloading a backdoored one.
It's quite easy to generate your own signing keys which you use to sign a kernel you've built yourself.
Long before UKI was a thing, this kind of attack was prevented by hardcoding into an EFI stub kernel the sha512 hash of a trusted initrd that would verify the cryptographic authenticity of the initrd that did the "heavy lifting" (mounting disks etc).
We have had not just secure boot but had it better on Linux (and other Unix-like) systems for a very long time.
Very nice exploit.
So if you use this PCR state machine, the problem is that the step before initrd doesn't require the correct password to move the PCR forward? It accepts any password that decrypts the next stage, which didn't have its integrity verified here.
Seems there are multiple ways of solving this, and adding integrity checks is only one. It could also let the TPM verify the disk decryption password (when it's needed.)
> It could also let the TPM verify the disk decryption password (when it's needed.)
The design intent is basically:
1. The TPM is very sensitive, and errs on the side of not unlocking your disk.
Booting into recovery mode to fix a driver? Reinstalled your distro? Added a MOK so you can install the nvidia drivers? Toggled certain options in your BIOS? The expected-computer-state checksums are wrong, better not unlock the disk as it could be an attack.
2. When this happens, you key in the password instead.
You can't rely on the TPM to verify the manually entered password, as the intent of the manually entered password is to recover when the TPM is in a broken state.
Right. The password verification would not be tied to the PCR states, or it wouldn't solve the problem at hand.
> You are safe if you additionally use a pin to unlock your TPM
Does the default configuration not somehow tangle a user-entered password to authentication against the TPM?
That's still not perfect (i.e. how do you make PIN/password entry non-keyloggable), but anything else, in particular extending the trusted computing base to the entire kernel and the hardware it runs on and hoping that they will both be bug-free and impossible to impersonate, seems like a bad idea.
The TPM is also in a much better position to properly velocity check PIN/password entries than the OS.
The other option is to have an intrusion prevention switch or two in the case so the TPM locks itself in some way and the machine refuses to boot at all without some PKI attestation.
depends on the threat model. a rot saw will hack it :P
TPM+PIN is pretty great, is a shame it's nearly never used.
Personally i would like a way to use TMP2 (with PIN) + password. (i.e. mode where PIN is derived from the password, but is also used to encrypt), so that i do not have to trust the TPM manufacturer.
This can be done. Not sure how on Windows/bitlocker but certainly with cryptenroll. Essentially you’d wrap this in your bootscript, though.
So password (or pin) encrypts passphrase, passphrase encrypts LUKS and goes to TPM, then you need to reverse the process for your init script (request password, decrypt passphrase, exchange with TPM to decrypt LUKS), but it depends on your appetite for planning that out.
Wouldn't this work with some kind of PKDF instead?
Like: Password ---> PKDF ---> PIN
And then Password XOR (Key from TPM) -> LUKS
But i guess this kind of logic is not for a bootscript, but for tools like systemcd-cryptenroll.
This is mitigated if your initramfs + kernel are measured into the TPM, right?
Edit: never mind, I think it's still vulnerable.
Your edit is correct. The kernel and initramfs are exploited unmodified to boot a tampered root filesystem, which allows userspace tools to extract data from the TPM, as the PCRs used to protect data like the LUKS passphrase have not changed.
Any idea how this works in the Windows world with bitlocker? I hope it's not same vulnerability
I recently changed motherboard on my laptop, had the bitlocker key if not I was told I'll have to reinstall Windows all over again.
Even with the key, one must decrypt and re-encrypt.
> Even with the key, one must decrypt and re-encrypt.
That's not true, the unlock key will be regenerated, but the disk contents will not be re-encrypted, because it's encrypted with another immutable key.
Thanks may be I didn't know the exact steps. It kept prompting key at every startup until I disabled and re-enabled bitlocker.
Hah, my gist from 2022 is on this post as a "broken guide". I'd disagree in saying it is broken. It works just fine and I flat out say at the top to not use it if you are worried about a cold boot attack on your hardware.
How do you deal with something like this in a NAS? There is no way to enter password during boot.
If someone steals the NAS how easily can they get to the data? Assuming volumes are encrypted, but the are automatically mounted on boot?
How to ensure the data is safe in case of theft.
Instead of the luks key in tpm you can use a fido2 compatible hardware security usb token. For booting/unlocking it has to be plugged in then you can remove it. This is pretty convenient and secure against many threats like stealing the nas in my opinion.