I recently switched to Linux (Zorin OS) and I selected “use ZFS and encrypt” during installation. Now before I can log in it asks me “please unlock disk keystore-rpool” and I have to type in the encryption password it before I’m able to get to the login screen.
Is there a way to do this automatically like with Windows or MacOS? Zorin has biometric login which is nice but this defeats the purpose especially because the encryption password is long and tedious to type in.
Also might TPM have anything to do with this?
EDIT: Based on the responses I have to assume some of you guys live in windowless underground bunkers sealed off with concrete because door locks “aren’t secure against battering rams”. Normal people don’t need perfect encryption they just want to add an extra hurdle or two for the crackhead who steals the PC. I assumed Linux had a system similar to what Windows or MacOS has been doing for a decade but I am apparently wrong.
Afaik you can’t. Disk encryption requires entering the password every time and it asks for it BEFORE the OS is started so you can’t use biometric login either
That’s not technically true as enabling bitlocker on windows and filevault on Mac don’t require two different passwords.
Mac will ask you to “log in” very early in the boot process to decrypt the disk, I assume it keeps the drive key encrypted with your password somewhere.
That’s just not true I have two macs with it enabled on both and it requires a single “normal” password
Sorry idk much about Windows and Mac. But what you said sounds like their encryption systems aren’t full disk encryption, they somehow found a way to store the password for login or they just disable the login password completely when the encryption is enabled
I recently dug into this because I accidentally trashed my wife’s OS which was encrypted with bitlocker. PITA btw and I couldn’t beat the encryption
Bitlocker encryption key hash is stored in 2 possible places. First is an unencrypted segment of the encrypted drive. This is bad because it’s pretty easy to read that hash and then decrypt the drive. The second place is on a Trusted Platform Module (TPM) which is a chip on the motherboard. This is better because it’s much more difficult to hack. It can be done but requires soldering on extra hardware to sniff the hash while the machine boots up. Might even be destructive… I’m not sure.
Either way a motivated attacker can decrypt the drive if they have physical access. For my personal machines, I wouldn’t care about this level of scrutiny at all.
Anyways you can see if any open source solutions support TPM.
What it sounds like you want is only your home folder encrypted, where it decrypts seamlessly upon login. It sounds like you have encrypted OS root, which is more secure but necessarily requires a password before the system gets to the login screen.
Other than reinstalling your system, you do have the option of either making your decryption password shorter, and/or enabling auto-login after boot (if you’re the computer’s only user), so you’d only have to type one password instead of two.
Or you can do full disk encryption and store the encryption info in the TPM and lock it down against various PCRs such that changes to the boot order or firmware prevent the drive unlocking without a secondary decryption key, just like Windows and Macs do.
It’s a built in feature of systemd, among other tools.
I’m not familiar with exactly what you mean, does it not require a password to boot that way? I have full-disk encryption on my laptop but not with TPM, grub just prompts me for a password before the kernel boots
Correct. The decryption key is stored in the TPM and unsealed when specific criteria match (for example, booted from the correct drive, to the correct kernel file). Figuring out the correct values to tie it to is probably the worst part for a user, if you do it wrong it might just unseal because your EFI firmware binary hasn’t changed, which isn’t all that useful if someone is trying to break in with a live image.
I’m also a linux noob, but I thought having to unlock the encryption before getting to the actual account was part of the point. If the encryption is always already unlocked it’s easier to break in.
They give up some security by gaining convenience and slightly better UX.
I can’t vet Apple’s security, but TPM isn’t a silver bullet either.
Yeah I don’t need a silver bullet I’m not storing highly sensitive data, I just mistakenly assumed this would be easier.
You keep bringing that up. Those are different systems with different approaches to security. You can compare them to death and back and it won’t bring your system to where you want it.
People have come to you with suggestions to achieve what you want and explained the consequences. Try that instead.
Kinda curious as to the point of drive encryption if you just want it to automatically unlock on boot.
Encryption makes it more difficult to copy data from the drive. Windows and MacOS can manage to encrypt drives without requiring two different passwords, I mistakenly assumed Linux could too.
How… How would they get the drive? Would n that need access to your computer? I imagine at that point they could turn it on first and copy your data that way, no?
No. With FDE, an adversary can’t just trun it on and copy data unless there are some 0day on the login that allows exectuing arbitrary codes.
But if you have it set to unlock automatically…? It’s not like the drive is going to know it’s you booting it vs someone else if you’re not having to enter the password.
Windows and Mac can indeed encrypt drives without two passwords - as long as you don’t set a drive encryption password to be entered at BIOS load before the OS loads, which is what you’ve done.
The idea is to use TPM to store the keys - if you boot into a modified OS, TPM won’t give you the same key so automatic unlock will fail. And protection against somebody just booting the original system and copying data off it is provided by the system login screen.
Voilà, automatic drive decryption with fingerprint unlock to log into the OS. That’s what Windows does anyway.
If you’re having it automatically unlock the drive at boot, it kind of defeats the purpose. If someone steals your tower, they can boot it and copy the unencrypted contents since it automatically unlocks.
How would they be able to copy the unencrypted contents? They still can’t do anything without logging in.
It depends on where the encryption data is stored. If the bootloader and bios/efi are locked down and the data to unlock is stored in an encrypted enclave or one is using a TPM (and not an external chip one that can be sniffed with a pi), that’s a reasonable protection for the OS even if somebody gains physical access.
You could also store the password in the EFI, or on a USB stick etc. It doesn’t help you much against longer-term physical access but it can help if somebody just grabs the drive. It’s also useful to protect the drive if it’s being disposed of as the crypto is tied to other hardware.
Even just encrypting the main OS with the keys in the boot/initrd has benefit, as ensuring that part is well-wiped makes asset disposal safe®. Some motherboards have an on-board SDCard or USB slot which your can use for the boot partition. It means I don’t have to take a drill to my drives before I dispose of them
OP isn’t asking for it to decrypt automatically. OP is asking for the entering the decryption password to also log you in. That way you only have to type the password once, instead of twice.
If you want some more convenience but don’t want to give up security, you can use hardware tokens like Nitrokey with GPG.
The process would be generate a random file using dd and /dev/urandom. Set this as the key for FDE. Encrypt it using your GPG and store it on /boot. Have a helper script to ask you plugin your Nitrokey and (optional) pin to decrypt the keyfile to have root decrypted. I had read this on some blog for dm-crypt so you will need to research and adopt to your setup.
