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.
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.
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.
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.
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.
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.
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.
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 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.
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.
A password can definitely give you plausible deniability. Look at VeraCrypt, for example. In a sense it's less secure because it can be seen being typed by others or by cameras and is vulnerable to hardware (and sometimes even software) keyloggers. On the other hand, a USB drive can be stolen and can also make you vulnerable to extortion. It's harder to make someone give up information in their brain then to give up a USB drive.
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 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.
Boot any Linux ISO and bypass any OS logins (secureboot would prevent this), connect devices over IO to otherwise exploit the login or just dump RAM content to potentially get data or even keys.
I would never trust OS login over FDE especially on desktop.
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.
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 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.
Entering a password on boot isn't even that much work