Comment by acheong08 a day ago
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
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.
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)
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.
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?
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>
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.
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.
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...
> 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.
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.
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.
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!?"
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...
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.
USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.
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.
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.