I just added a drive to my system which is basically a partition mounted for extra storage. I'd like to encrypt it to protect my data in case of god knows what, and by doing that I'd need to enter the passphrase every time to unlock the partition.
I just read that I can add a keyfile so I wouldn't need to manually unlock it every time, but this is confusing. What is the point of having encryption if it's going to unlock automatically anyway?
If decryption only relies on the keyfile and this keyfile is readily available, there is indeed no significant security benefit in your setup.
What you can do though is store the keyfile on a removable device (e.g. a USB stick) and detach it when you are not around. That way decryption is only possible when you are present and the removable device is attached.
Storing the keyfile locally makes sense if you want to ensure that a removable device can only be decrypted on your system. You can distribute the keyfile to other systems as well if you want to use the encrypted device in different places. If you lose the removable device in transit, little harm is done, because it can only be decrypted on a system that has your keyfile.
While Demento's answer is fine, I'd also present another user case I'm personally using: I have full disk encryption set up — using LUKS on a Linux-based box, and the scheme is implemented as follows:
initramfs"
which is an "early-boot userspace" used to bring up the rest of the
system. This image contains the unencrypted keys used to decrypt
other attached LUKS-encrypted partitions.The upside of this setup is that it requires the user to only enter their passphrase once.
The obvious downside is that if the attacker somehow manages to decrypt the boot partition they automatically gain access to the rest of the disk space;
if an attacker somehow manages to mount a local root exploit on a running system to gain access to the initramfs image available on the decrypted partition exported by the LUKS subsystem, it gains access to the partitions other than the boot (though, in the case of such an exploit they'd get such access right away as the partitions are already decrypted and exported).
Here, the usage of the key to encrypt data storage is to replace the need to provide a passphrase (given the key itself is kept in a reasonably secure manner).
cryptsetup keep the key material around after it was used to derive the master key.
Commented
May 13, 2020 at 23:10
cpio archive). While the file is root:root 0600, if an attacker gets root, they would have no problem reading the archive and obtaining the keys. Of course, the attacker has to know the setup to understand where to look, but we assume they do. So the security of the non-boot partitions rests in the security of the boot partition + the security of the running system.
cryptsetup team. By default, the installer also adds LVM which I did not want (saw no reason to use it on a laptop which was not going to grow its logical volumes).
Surprised that nobody mentioned TPM as an additional measure.
Doesn't protect against "god knows what" attacks, but does provide quite a bit more assurance than a keyfile, particularly against boot process attacks (if done right with sealed PCRs), giving you a bit of extra boot device security.
PIN on TPM should simplify your passphrase hassle, or a FIDO device.
Stepping on the shoulders of giants:
Having said that, suggest thinking seriously about what do you really want to protect against - stolen devices (so baddies can't use your data), forensics/decryption attempts by law enforcement (if you live in a country where things aren't stacked in your favor if you're a dissident), or you're just hiding your hentai collection from whoever. YMMV.
Security is usually achieved via a) something you have plus b) something you know, like a password secured file on a pen drive?
