13

I have a Debian Linux system (amd64) installed on a RAID-1 system encrypted device (LVM on LUKS) and will have a RAID-6 of >=4 disks where I'll put my data (LUKS and maybe LVM).

I think the basic idea is to unlock the system encrypted partition (at boot at local or via ssh) and to store a keyfile in /etc/crypttab for the RAID-6 encrypted partition. Does that pose a security risk ? I mean ... it's pretty useless if anybody can just enter my system locally / remotely and I think there are plenty of services running on servers that are vulnerable to "rooting" (e.g. SSH). Is there an alternative (beside unlocking the partition via SSH which may be a problem since e.g. backup operations start even before the data partition is mounted).

On another machine I'll use multiple disks with LUKS+greyhole (no RAID-6) for Backups and it'll be a real pain to unlock 10 disks by enterning 10 times the same password ...

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
user51166
  • 423
  • 1
  • 5
  • 10
  • If someone can break into your system and become root, they don't need to get the key to your encrypted partition. There's no point in protecting it from root (and it's not possible without special hardware such as a TPM or running in a virtual machine). – Gilles 'SO- stop being evil' Feb 24 '12 at 23:29
  • Excuse me ? Even if I'm root I have to give the keyfile / passphrase to unlock LUKS partitions. I suppose you mean that if somebody becomes root it has full access to my encrypted data. Unfortunately that is simply true because once the encrypted partition is mounted, it makes no difference if it's encrypted or not. What would the advantage of a virtual machine be then ? So why should encryption help at all ? Is the only solution to deny access to root via SSH and similar services ? But still if a hacker gets into the system as a normal user he typically has read access to every file,isn't it? – user51166 Feb 25 '12 at 07:06
  • 1
    Exactly, if someone is root on your system, they have access to everything. A VM can mean that they have access to everything in the VM. The only use of encryption is if someone steals your hardware. – Gilles 'SO- stop being evil' Feb 25 '12 at 20:14
  • Yeah well ... in that case we can argue that the only almost safe way to store data is in an encrypted computer disconnected from all network and integrated in the building. Then still anybody could come with a keyboard and steal your data without rebooting your system. I might as well isolate my systems from the internet since it will be a backup server therefore LAN access is all it needs. Then again ... should a VPN be used or one of the LAN machines gets infected the backup machine would be exposed as well. What would you do to solve these problems ? – user51166 Feb 25 '12 at 21:35
  • see also http://unix.stackexchange.com/a/110102/50601 – Tim Abell Mar 15 '17 at 02:07

3 Answers3

8

You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another.

The decrypt_derived script is part of Debian's cryptsetup package.

Small example to add the key from sda6crypt to sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

As it is nowadays very difficult to really delete a file, ensure that /path/to/mykeyfile is on a encrypted drive (sda6crypt would be in my example a good solution).

In general, you can add an additional security layer by using user space filesystem encryption e.g. via encfs.

jofel
  • 26,513
  • 6
  • 65
  • 92
  • That way I shouldn't need to store the keyfile on disk. That would be nice. However do you think it's worth the trouble (i.e. storing the keyfile on the encrypted root device is "safe enough") ? I'm asking an opinion since I have some doubts. Thanks for the suggestion. – user51166 Feb 24 '12 at 08:38
  • The solution with `decrypt_derived` has the only advantage, that there is no key file. If someone can get root access, you are normally lost anyway. Reading a key files could be a little bit easier for an intruder than running a script. To get more security, you can harden your system by using e.g. TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity,... but this takes additional efforts. And the question if it is worth is then more important. Please do not forget to have a backup of the key or a separate key for the case that the drive crashes where the key is derived from/stored on. – jofel Feb 24 '12 at 09:19
  • I planned on using grsecurity or similar softwares as well (not at the start, but when I'll have time I'd secure it). I'm thinking of using only passwords and not keyfiles if possible. Well the password will be stored in RAM, so I guess you can argue about that as well. – user51166 Feb 24 '12 at 18:02
  • There is no good way to delete a key file anywhere, short of overwriting the whole filesystem (and perhaps not even then if the disk fails). A journaling filesystem does not make things markedly worse. – Gilles 'SO- stop being evil' Feb 24 '12 at 23:27
  • @Gilles Since I am not an expert of safe file deletion, I edited my answer. I recommend now to store the keyfile on the encrypted drive. – jofel Feb 25 '12 at 09:56
  • @jofel Um, you can't store the key to an encrypted volume on the volume itself. Storing it on another encrypted volume only pushes the problem around: where do you put the key to that volume? In the end you have to store the key somewhere, either on the disk or on some removable storage (which means you need to have it at hand) or on some other device (such as a TPM, if you have one and are willing to go through the hurdles). – Gilles 'SO- stop being evil' Feb 25 '12 at 20:12
  • @Gilles I did not want to answer where to store key files in general, but where in our case the (derived) key file should *temporary* be stored. Since, if the key file is stored on the volume that is used to generate it, anyone who can read the (decrypted) remains of the key file, can derive the key by hand much easier. So I see no problem here. That my solution is not that what user51166 hoped to get, is another thing - I think you clarified the things by your comments above. – jofel Feb 25 '12 at 22:02
  • @david-personette Thanks for your edit suggestion. Storing keys on tmpfs (`/dev/shm`) would only be safe if swap is disabled. – jofel Sep 24 '14 at 11:42
  • Does `keyscript=` really works in Debian? – Shiji.J Jan 19 '16 at 23:21
  • @Shiji.Jiang I know system on Debian Jessie and Wheezy using sucessfully `keyscript`. If you using another release or other keyscripts have a look at the [BTS](https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=cryptsetup). – jofel Jan 20 '16 at 10:17
  • The Debian 8 documentation lists [`keyscript` as incompatible with Debian's use of systemd](https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-cryptsetup-unsupported-features). // cc @Shiji.Jiang – user Jan 21 '16 at 10:04
  • @Shiji.Jiang The systemd in Debian 8 does not support keyscript. If only root and swap are encrypted and they are both unlocked during initramfs phase (where systemd is not yet active), it at least somehow works (systemd gives error messages, but system boots correctly). – jofel Jan 21 '16 at 11:13
2

Consider using decrypt_keyctl instead because:

  1. LUKS2 compatibility. Don’t use decrypt_derived blindly on new installs. It might result in having a static error message instead a secure derived passphrase in your key slot.
  2. Passwords time out by default after 60 seconds. The derived passphrase is always available to root.
  3. It have almost all advantages decrypt_derived brings over keyfiles. The downside is, that you could not use it for disks attached later to the system.
stackcoder
  • 29
  • 2
  • Great comments. To your first point - I'd love to see a link to more details on this. Is `decrypt_derived` completely broken for LUKS2? I just get `/lib/cryptsetup/scripts/decrypt_derived: device sda3_crypt uses the kernel keyring`. I miss it because of your third point. – bitinerant Dec 31 '20 at 18:21
1

Based on jofels answer, here is the same example but without having to store the key in a file. The key is passed in a named pipe, which doesn't store anything to disk.

You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another. The decrypt_derived script is part of Debian's cryptsetup package.

Modified example to add the key from sda6crypt to sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

The keyscript option only works if crypttab is processed by Debian's original cryptsetup tools, the systemd reimplementation does not currently support it. If your system uses systemd (which is most systems), you need the initramfs option to force processing to happen in the initrd by the cryptsetup tools, before systemd starts up.

JanKanis
  • 1,019
  • 2
  • 12
  • 17