I’m dual booting fedora 39 and windows 11 pro and I wanted to encrypt my partitions (separately).
For windows there’s bitlocker (the only downside is that I won’t be able to boot from GRUB). So if you know an alternative that doesn’t ask for my encryption password every time I boot, it’ll help me a lot.
As for fedora, , I tried the built in encryption (when installing fedora) but it asked me for my encryption pass phrase every time I booted fedora, that was it for me.
I read veracrypt docs and it seems like it does the same thing.
The whole point of disk encryption is to make data and files be safe at-rest and in order to achieve that SW needs to authenticate the user. There is one method to decrypt disk using TPM2, but to me it seems that it provides weak security as it protects you only in cases where disk was removed from your computer. If bad actor gets access to you PC/laptop and boots it - the disk encryption is unlocked and the last line of defense is your password.
The user account login would also be a problem right?
I believe you can use a key-file with LUKS to unlock the machine at boot. I know this works great with USB drives. At boot, you’ll need to have the USB plugged in though. . .
Yes, I use key-file specifically to avoid typing the LUKS password twice.
First for GRUB (so it can look inside the disk and find kernel and loader entries there) and then again for the kernel (which won’t receive the password from GRUB)
To fix this, you can create a key-file, which also opens the LUKS partition, and bake it inside of the kernel. User uses password for GRUB and kernel uses keyfile that is baked into it. As long as the kernel and the keyfile (that has to be baked into each new kernel installed) lives on the parition locked by the LUKS, it doesn’t matter it’s readable (by root) there, as the whole parition still requires the initial password input for GRUB to be able to decrypt it in the beginning.
I think this approach is used in general, but I’m not sure, I don’t use Fedora installer.
I don’t know. I’d expect Bitlocker to take care of Windows’ boot and LUKS2 to take care of Fedora boot from storage unlocking perspective. I don’t know how dual boot with Windows works (especially from EFI perspective), never used myself and always recommended not to do for others. Maybe someone here having required knowledge and/or experience will help you.
So it seems you authenticate in Bitlocker in order to get access to Windows bootloader and if you choose Fedora to boot, then LUKS2 in involved to unlock Fedora’s partition. Seems normal, but maybe it is possible to optimize this, I just don’t know how.
Folks, you’re just overcomplicating a simple thing that was asked.
This is the answer. People might not think it’s a reliable way to secure your disk, but different people have different threat models and this solution is great for people with low threat models, which I believe it’s the case here.
This Bitlocker password is usually associated with your user account. This is why you only enter it once on Windows. The way Windows sets up the User account & Bitlocker is very different. I’ve never had to inspect a Bitlocker Drive, so I have no idea how it works.
Again, if you only want to type your password once, use a USB Drive with a keyfile. You will need to set it up and edit the config files for this. But with a key file all you would do is,
Plug in your USB Drive => Unlock your system
Type your User Account Password and you are done.
For those interested, There are tools like pam_usb or configuring pam for Screen-Lock or 2FA.
outside of LUKS there is ecryptfs or fscrypt which provide different tooling than LUKS for encrypting /home only.
You can setup a central provider in your network (physically hidden - on a raspberry?).
Check-out TANG[1]:
Allows unlocking volumes using a network server.
and have your machines read the decryption key from that network location in boot.
In that case when the device (PC/Server/laptop) is removed from your home/office network it won’t be able to start from the encrypted partition (unless user input).
I did not always implement it cause it’s to much complexity. It depends how valuable is your data.
So it’s:
entering password/passkey on boot
using Clevis with TANG a central password/passkey provider in the network
Other workarounds make the point of encrypting the drive pointless.
As OP did not mention or explain threat scenarios I assumed and from assumption point of view explained implications of poor security (i.e., “formal security” - adding LUKS, but removing authentication).
OP raised convenience related question and I hope you’d agree convenience and security are not really good “friends”. Normally adding security measures is not for making situation more convenient, but making it more secure.
Yes, but a middle ground can always be achieved with sane defaults from our part and slight modifications from the user’s side. Adding TPM2 automatic decryption of the LUKS encryption is a middle ground between no encryption at all (which doesn’t protect the user at all) and having encryption at the cost of longer boot times and more manual interaction from the user needed in order to boot. A Yubikey/USB with key-file is the perfect middle-ground IMHO but most users will lean towards the TPM2 due to being more convenient.
Back to your first replay - we do not know threat scenarios, right ? In theory, having LUKS with TPM unlock will save you if storage is removed. If computer is in bad actor’s possession and computer is booted, then there is not other protection then user’s password and this is “the middle ground” then.
P.S.: I fully agree with you that security must be sufficient and practical, without becoming a paranoia. But to comment/suggest sane levels of security we have to know threat models. My “default” recommendation is LUKS full disk encryption with passphrase + and good (min 12 char length, upper/lower case, punctuation, etc) password. That alone, without knowing specific security needs, is Good Enough™ security for average users.
Sure, if proper practices are in place, any computer becomes hard target. On the other hand I’ve seen too many users having “log in me automatically” set to on and living with this main threat scenario - “I’m not interesting person, who and why would want to attack me ?” So I’d rather repeat my security “mantras” on every occasion