48

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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
php_nub_qq
  • 787
  • 1
  • 6
  • 13
  • 1
    How do you supply the keyfile? – schroeder May 12 '20 at 13:19
  • @schroeder As far as I understand you map it to the device and you keep it somewhere on your filesystem. – php_nub_qq May 12 '20 at 13:29
  • So, from what I'm reading, it's a removable drive. If the keyfile is on your main system, how is encryption defeated? – schroeder May 12 '20 at 13:35
  • 1
    @schroeder it is not a removable drive, it's just another drive added inside the system. But even if it were a removable one what if say a thief steals everything physically, he'll have both anyway. – php_nub_qq May 12 '20 at 13:36
  • 20
    If an installed drive, using a keyfile adds no protection. If removable, the theft of the media is mitigated. Security is not all-or-nothing. – schroeder May 12 '20 at 13:39
  • In "wouldn't need to manually unlock it every time", the word "every" might be the pertinent one. If the key expires in 24 hours, you only need to manually unlock once per day. If the device is stolen, the thief only has 24 hours to unlock it, which will protect you in some circumstances. – Simon Lepkin May 12 '20 at 22:13
  • 9
    All drives are removable. Some just take a little more work than others. And in the long term, all drives will actually be removed. It is easier to wipe a keyfile than an entire drive. – jjanes May 13 '20 at 16:56
  • 1
    I've always thought it obvious keyfiles defeat whatever they sit alongside… How is it not obviously easier to hack one more-strongly-protected keyfile than 123 individually encrypted data files? With this, that and the other protections, Mr Hacker needs to breach this, that and the other individually. If there's a keyfile, Mr Hacker needs to breach that alone. Who doubts that? If that keyfile had thrice the security, that might balance against this, that and the other… Further, if you normally use a keyfile how will you remember your security details when it matters? – Robbie Goodwin May 13 '20 at 19:12
  • 11
    "In case of god knows what," that right there is your problem: you don't have a threat model and are already looking for solutions against ... yeah, against what? Make up your mind about which kinds of data theft are a real threat **to you** and which you want to protect yourself against. Then choose a form of protection that suits your threat model. Encryption, in one way or another, *might* be the solution. – marstato May 14 '20 at 12:16
  • 4
    @jjanes: Selling a drive with all your data on it is foolish in the extreme. Wiping the keyfile does not mitigate that. It's important to realise that as time goes on encryption becomes easier to crack. Encryption is like a door - it does not prevent entry, it merely delays it. In earlier days, we used 48-bit encryption which could hopefully delay cracking for a year. Today, we can crack that in mere seconds, so we've moved on to stronger keys, but the same applies. – RichardP May 28 '20 at 00:01
  • [Two-factor] authentication could be so much more convenient if a good system were available that **checked if your phone was near**... (With a potential backup method such as a YubiKey, of course.) – Timo Jun 01 '20 at 19:10

4 Answers4

74

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.

RJFalconer
  • 293
  • 1
  • 7
Demento
  • 7,249
  • 5
  • 36
  • 45
  • 46
    …also, it's common to have the keyfile itself encrypted with a password. This has a number of advantages, but the biggest one is that it provides a form of two-factor authentication: an attacker needs to both guess your password _and_ gain access to the keyfile in order to decrypt the data. – Ilmari Karonen May 12 '20 at 22:19
  • 3
    Depending on the OS and exactly how you store the keyfile, it may even be well protected if it remains on the same physical machine. For example on macOS if the key is stored in the keychain then the key itself is encrypted, and the decryption key for that is stored in the Secure Enclave - accessing this without appropriate credentials is not a trivial task. – jacksonj04 May 13 '20 at 09:33
  • 1
    @IlmariKaronen thank you. I've had to vigorously defend that encryption key + password are **TWO** factors https://security.stackexchange.com/a/220416/44419 – Paul Draper May 13 '20 at 18:14
  • 1
    The keyfile can also be printed on a piece of paper (with ASCII armor or a QR code) and placed in a secure location so that if the person who knows the passphrase is unable to provide it for whatever reason, the volume can be recovered. – chrylis -cautiouslyoptimistic- May 13 '20 at 21:51
  • 1
    Note that in certain setups this might be used to make it easier to change the password. E.g. if you want to change the password, you would normally need to re-encrypt the whole drive. However when you have a keyfile encrypted by a password you only need to reencrypt the keyfile if you want to change the password. – yankee May 14 '20 at 11:24
  • 4
    An actual benefit of encrypting with readily available key is that it makes disposing the data much easier. Usually you'd need to erase all of the hard drive to destroy the data (e.g. before selling the drive on ebay). If you have a keyfile it is enought to destroy this file. – yankee May 14 '20 at 11:26
  • 1
    Keep in mind that there's a higher chance of the USB stick breaking or you losing it (either through carelessness, an unforeseeable accident or intentional theft) than for the drive itself. Not a reason to disregard this idea, but something you might want to consider. – Blueriver May 14 '20 at 22:27
  • @yankee I would erase the drive before selling it anyway, cause there is plenty of time to do that, so why not do it. But your idea is valuable when *they* are knocking on the door already :) – vadipp May 29 '20 at 04:10
  • 1
    @vadipp erasing the drive is not foolproof. At least use a "file shredder" software that overwrites all the disk a number of times with various specially designed patters that make sure the disk contents cannot be easily recovered. – Jonathan Rosenne May 29 '20 at 07:47
  • @Demento A simple USB stick isn't too secure. It would be better to use a FIPS approved secure USB or smart card, protected by a reasonably strong password. – Jonathan Rosenne May 29 '20 at 07:54
  • @JonathanRosenne Proper encryption is already indistinguishable from random data, so why bother when you could just erase the key? – SilverbackNet May 29 '20 at 10:05
  • @SilverbackNet it depends on what is stored on the drive. It's true that encrypted data is random without the key, but what if someone manages to recover the key in some way? I believe that sometimes it's even better to even physically *destroy* the drive (after erasing it), because you just can't risk *any* chances. – vadipp May 29 '20 at 12:31
  • @vadipp If you need to erase a drive, the claw hammer/drill/thermite method is definitely far more effective. Even for donating to charity, I'd rather buy a cheap new drive and destroy the old. – SilverbackNet May 30 '20 at 02:39
12

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:

  • The boot partition is encrypted and requires a password to be entered so the boot manager (GRUB) is able to mount it.
  • The partition contains the kernel image and the so-called "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 image is kept with as tight permissions as possible.

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).

Jonathan Leffler
  • 156
  • 5
kostix
  • 221
  • 1
  • 6
  • If an attacker gains root access to a system with an active dm-crypt/LUKS volume they extract the master key from the kernel which allows arbitrary access to the volume in question. However, in the case of LUKS, they cannot extract the passphrase or key file content unless they “listen in” on the the volume activation since neither the kernel nor `cryptsetup` keep the key material around after it was used to derive the master key. – David Foerster May 13 '20 at 23:10
  • 2
    @DavidFoerster, in the setup I described, the keys to all the LUKS partitions except the boot one are kept as plain unencrypted files inside the initramfs file (which is a gzipped `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. – kostix May 14 '20 at 11:01
  • @kostix How did you install your system like this? I've been [asking Canonical to implement](https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1773457) this on Ubuntu, with some people incorrectly claiming that it cannot be done (one person even claiming that perfect security is unachievable therefore you shouldn't encrypt boot). (I wrote [how to do this on *buntu](https://help.ubuntu.com/community/ManualFullSystemEncryption), but it's tailored to Ubuntu 18.04 and isn't guaranteed to work on other versions. Thus, I'm interested in other methods, such as how you did it.) – Paddy Landau May 29 '20 at 10:14
  • @PaddyLandau, semi-manually, using [this guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) from the Debian's `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). – kostix May 29 '20 at 10:21
  • @PaddyLandau, the most crucial thing to keep an eye on there is «Until LUKS version 2 support is added to GRUB2, the device(s) holding /boot needs to be in LUKS format version 1 to be unlocked from the boot loader.», so the boot partition must be LUKS1, and the rest of them can freely be LUKS2. – kostix May 29 '20 at 10:25
  • @kostix Thank you, that was helpful. Incidentally, LVM seems to be useful for reasons other than growing or spanning volumes, and certainly can't hurt. – Paddy Landau May 29 '20 at 14:53
  • @PaddyLandau, I have flashbacks of the times LVM did not contain code which supported filesystem "barriers", so basically `fsync`s and `fdatasync`s issued against a filesystem which overlied an LV would dissolve in the LVM code and never reach `mdraid` and below. IIUC, that was fixed but, well, this uncomfortable feeling stuck in me ;-) – kostix May 29 '20 at 16:13
1

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.

Milen
  • 1,148
  • 6
  • 12
-1

Security is usually achieved via a) something you have plus b) something you know, like a password secured file on a pen drive?

MR DAVID G PICKETT
  • 1
  • Welcome! Your answer doesn't address OP and is of poor quality. Consider reading over the question again and updating your answer. Otherwise I see no reason for your answer to remain posted. – phbits Jun 02 '20 at 15:49