101–110 of 136 posts
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 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.
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
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.
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.
Earlier quoted context omitted.
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 mot…
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 thing…
Earlier quoted context omitted.
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…
It's a risk I'm fine with. Anything I care about is backed up separately.
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 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.
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 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. A…
Earlier quoted context omitted.
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. A…
> 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?
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.
Earlier quoted context omitted.
> 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...
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.