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.
EDIT: Based on the responses I have to assume some of you guys live in windowless underground bunkers sealed off with concrete. 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.
I am sorry you were treated like this and downvoted for just asking for help without being a jerk at all.
OP, just change your encryption key to whatever you have your password as and set your login to auto login. This will give you the experience you desire as it’ll decrypt the disk with your password and log you in automatically once it’s decrypted, but if you lock the system (close the lid. Screen lock. Etc) you’ll still get a login screen as normal. (Just keep in mind they’re technically two separate passwords and will unfortunately need to be changed separately if you do change your password).
This is solid advice
What I do for a little extra security is that my encryption password is just a longer variation of my normal password. So of I have an encrypted password sentence like “correct battery staple horse” my login password would just be “correct battery”. It’s a simple way to add a little extra and a good reminder everytime I turn on my computer that they are in fact two different passwords and protect me differently.
https://wiki.archlinux.org/title/Trusted_Platform_Module#Data-at-rest_encryption_with_LUKS
Thats what you want i think
My mom brings me and my anime mousepad with boobs waifu bagel bites, what does your mom even do? Also, you can do autologin, so you only enter a password once to decrypt on boot.
I do not know the answer, but this got me thinking: would it be easier to set up a single login for both session and decryption if /home was on a separate partition and only /home was encrypted?
Assuming you want:
- Single password prompt instead of auto-decrypt with tpm
- User’s files to be encrypted
There are several ways to achieve this:
-
autologin (recommended for single user system): / is encrypted using luks or zfs native encryption and user’s home needs to be unencrypted. User’s password may be same as encryption password for convenience, though they still are two passwords used for different purposes.
-
pam mount: / is unencrypted or auto-decrypted and user’s home is encrypted independently from / using zfs,luks,fscrypt,etc. In this case, user’s login password must be same as user’s home encryption password. It’s suitable for multi-user system. NOTE: It cannot be used with autologin since user’s home needs to be decrypted to log in.
WARNING: For tpm usage, using secure boot is highly recommended to prevent unauthorized user from accessing key stored in tpm.
To prevent auto-decrypt with tpm, tpm-pin can be used (with autologin for requirement #1).
-
systemd-cryptenroll with/without tpm: As far as I know it can be only used to unlock disk encrypted with luks2. It can be used without tpm with pkcs11-token (e.g. YubiKey) or fido2-device. It also uses parameter encryption while key is unsealed, so safe from key sniffing via communication bus. This is easy if secure boot is enabled and luks2 is used for encryption.
-
clevis with tpm: It can be used in place of systemd-cryptenroll. May be used with zfs native encryption. Though I’m not sure if it uses parameter encryption (correct me).
-
unencrypted keyfile on usb: Not sure about zfs, but you can use keyfile on a usb drive to decrypt luks containers.
NOTE: I’m not a forensic/security expert. I listed a brief overview of methods I could think of to keep user’s files encrypted while providing single password till login.
systemd-homed can also do it.
Auto decrypt with TPM sounds fine to me but I have no idea what TPM is as this is my first PC with it.
Thanks for the great response though I’ll look into these
I have no idea what TPM is
Read Skull giver’s reply or look it up.
Re-reading your post, I take you want to avoid typing long and tedious password? And that’s why you want to auto-decrypt?
- (Recommended) You could use strong memorable passwords that are not difficult to type and enable autologin. Related xfcd comic:
- systemd-cryptenroll: For TPM usage, I highly recommend using secure boot. Though not sure if you can easily do that. A less secure alternative using systemd-cryptenroll would be use tpm2-pin and bind key to no pcrs (discouraged). But then you’ll have to use luks2 for encryption.
Notice from
man systemd-cryptenrollregarding tpm2-pin:
Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout mechanism is a global property of the TPM, systemd-cryptenroll does not control or configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary attack lockout, with tpm2_getcap(1) and tpm2_dictionarylockout(1) commands, respectively Also tpm2-pin is not disk encryption password and short alphanumeric password needed so tpm decrypts the device; so encryption password should be secured in a safe place. Also check if your distro supports systemd-cryptenroll.
-
usb drive: read previous comment
-
clevis: It probably isn’t as simple as systemd-cryptenroll but I guess you can use zfs and combine that with tpm2-pin if not using secure boot (discouraged).
You’ll have to make a compromise somewhere between security and convenience. Even if you use pam mount, you’ll have to enter the password, biometrics won’t do.
Edit: remove unnecessary user tag and add img uri
This reply isn’t going to be helpful to OP, but thought I might add context for others passing by.
I’m using Arch Linux with LUKS encryption and gdm. As long as my user’s password is the same as the LUKS password, I only ever type my password in once.
Just saying that a MacOS-like convenience is definitely possible on Linux.
Fascinating, you don’t have automatic login enabled? And I assume this is at the pre-login prompt?
Oof - forgot to mention that I do have autologin configured on gdm 😀
user’s password can be totally different from luks password if you’re using autologin. You can keep it same but that’s totally optional. You can login without entering any password at all if not using luks (or using autodecrypt), you can see that in live isos.
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.
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
They are full disk encryption, and it’s using the hardware TPM.
Oh then I guess idk what TPM actually is
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.
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
Yes normal password but it happens super early on mine, and once you log in there is a boot progress bar afterwards. This is an Intel Mac, might be different on apple chips.
That’s likely because your Macs are using the TPM. Does your Linux machine have a TPM, and are you using it?
I don’t think so, they are both intel macs over 10 years old and Macs didn’t start adding TPM until 2017. On Mac, when you check the box to encrypt the drive during install you’re prompted for an encryption password which you never need to use again unless you remove the drive and put it into another mac (or in my case add a second hard drive and use the original as “extra” storage).
If you want to do away with any protection you have with opting in to a security measure, like typing in a password, why don’t you just reinstall and not select the encryption option?
Not requiring a password, or automatically entering a password to decrypt the filesystem, is essentially the same as not having encryption.
Decide which you want: Security or convenience. You cannot have both.
Not sure if this works with drive encryption since it comes before the OS, but could this maybe be done with a YubiKey or something like that?
That way, you can plug it in and not worry about typing the password every time, but then it’s also secure if someone takes your PC? As long as you remove the key when it’s off of course.
Yes, systemd-cryptenroll supports Yubikey as well as generic FIDO2 tokens (and the TPM on most distros).
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?
Disk encryptions entire point is securing against physical access
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.
Or you use TPM, which you can get the key out of
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.
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.
MacOS does ask for a different password during setup, which you never have to use again unless you want to access the drive on a different PC.
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.
I don’t suppose you know of a tutorial to get this set up? Google turned up nothing.
I see. I don’t know that the usual drive encryption you set up during Linux install works with that, but there are BitLocker-like programs for Linux that might.
Although OPs scenario is if someone steals the tower, in which case it’s not a different TPM. Would only help if the drives were yanked, which honestly I’d probably do rather than try to take the whole tower.
If you boot the computer into the currently installed OS, you will be presented with a login screen and will have to enter the correct password to log in (kernel parameters are part of the checksums, so booting into single-user mode won’t help you, that counts as a modified OS). If you boot a different OS, you won’t get the key off the TPM.
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.
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.
GDM has an autologin feature, OP should use it.
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
How would they be able to copy the unencrypted contents? They still can’t do anything without logging in.
By intercepting the key on hardware level
Perfect security doesn’t exist. If they’ve got the engineering capital required to design and manufacture key retrieval hardware, you lost the moment they gained physical access to your equipment.
If they have the capability to extract the key, they probably also have the computational resources to brute-force the passphrase. It’s not a meaningful difference.
Most brute-force attacks can be hardened against. Again there’s no perfect security, just better security.
I agree. Physical access to the device and its often game over.
Sadly reading off the key is already trivial in some cases as showcased in this recent video by stacksmashing
Since the key has to be sent to the cpu in plain text it can easily be sniffed. If however the TPM is integrated in the cpu its not so easy, but then the os can be manipulated or hacked after boot with known exploits.
If you have a long and secure password for you encryption the absolute only way in is to brute force the key which is significantly harder if not impossible regardless of capital
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
If he uses TPM. I’m not aginst OP using it but he needs to understand the drawbacks. At least I hope he will.
Bypassing login is not difficult on a lot of OS.
At least on Windows that requires booting the PC from some other media, and that wouldn’t work with the drive encrypted because you have no access to the files you need to modify.
Is it similar with Linux, or do you mean you can actually bypass login from the OS that’s already booted up??
Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the
singlekernel parameter to boot into a root shell. And different decryption key means no access to the data.
Fedora has a good write up using Clevis, I am not sure how well Ubuntu supports it as they traditionally have been against using the TPM for security reasons. https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/
systemd-cryptenroll can do it very quick and easy, it’s literally about two minutes work, but Ubuntu patches out the TPM support.
Ubuntu will soon have TPM-backed full disk encryption as a standard option in the installer. Their implementation is designed to defeat most of the security implications that the naysayers bring up, except the login process is still a potential vulnerability. What you are asking about is not so far fetched as some of the comments would lead you to believe: https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu
Instead of encrypting the entire drive, encrypt the home folder. That way it’s unlocked when you sign in.
I’m not familiar with zfs, but on an encrypred drive I got around this using crypt tab If i recall. you edit a crypt file, ftab points to it or something…sorry it was 7 years ago. But there is a way to make the OS grab the decryption password. You trade convienience for security obviously
I think people are misunderstanding the whole point of drive encryption. It’s so that if the drive is stolen or lost, you don’t have to worry about it as much. I personally don’t see any benefit in doing this if I have to enter a password every time I plug the damn thing in. If you’re concerned about somebody stealing your laptop or desktop, the disk-encryption should be the least of your worries.
To the OC; if you happen to use GNOME, then check out the settings in the DISKS app. It has auto-unlock options in the per-drive settings. I long ago configured it so my USB is auto-unlocked upon being plugged in. Though after several system resets and such whatever I did to do that seems to no longer be visible in the GUI, I know that’s how I set it up in the first place.
To the OC; if you happen to use GNOME, then check out the settings in the DISKS app. It has auto-unlock options in the per-drive settings.
Thanks so much!
EDIT: This didn’t work
They do understand the point. The problem is that if you use TPM to unlock on boot it is slightly self defeating. Now the attacker has access to your display manager or TTY. They can guess passwords, try to bypass the biometric checks, or find an exploit. But that does indicate a higher tech level that your average thief.
I appreciate the concern but odds are if someone is stealing my PC its not going to be a 1337 hax0r. I am not keeping government docs on here I just don’t want someone to be able to rip out the HDD and have easy access to everything.
