14

Looking into hard disk encryption. the go to solution seems to be dm-crypt with LUKS using a password. I work with multiple independent hard disks mounted into a disk pool for reading. In this case, I have to type a password multiple times.

Is there a way for me to encrypt the hard disks with a key file, maybe put it on a USB drive and just plug it in when necessary??

Improve this question

2 Answers 2

Reset to default
11

One of the best ways to do this is to use a smart card with a crypto key on it to unlock the keys for your encrypted block devices. You will only need to enter the passphrase (called "PIN" by the tools but it's really a passphrase) once, after which it will be cached. This has the added advantage of protecting the encrypted data with something-you-have (the smart card itself, out of which the private key cannot be extracted) and something-you-know (the passphrase).

Format your /etc/crypttab like this:

mapper-name /dev/disk/raw-device /var/lib/filename-containing-encrypted-key \ luks,keyscript=/lib/cryptsetup/scripts/decrypt_opensc

In Debian and derivatives, the initramfs-tools will notice the keyscript and copy all of the necessary tools and daemons for accessing the smart card to the initramfs automatically.

Information on setting up the smart card and creating (and encrypting) the keys is found in /usr/share/doc/cryptsetup/README.opensc.gz.

You can use a Yubikey 4 or Yubikey NEO among others for this purpose.

Implementation notes: This feature has rough edges and apparently doesn't work out of the box so YMMV. The last time I successfully achieved it, I had to add the following hacks:

  • Disable systemd because it disastrously tries to take over the whole process of setting up encrypted devices from /etc/crypttab but it knows nothing about keyscript which leads to a big FAIL. Luckily, in Debian, you can still opt out of systemd.

  • Install this fixer-upper script as /etc/initramfs-tools/hooks/yubipin because the built-in feature didn't install quite enough support to get the Yubikey to be usable from the initramfs. You may need to adjust this.

    #!/bin/sh PREREQ=cryptroot prereqs() { echo "$PREREQ" } case $1 in prereqs) prereqs exit 0 ;; esac # /scripts/local-top/cryptopensc calls pcscd with the wrong path ln -s ../usr/sbin/pcscd ${DESTDIR}/sbin/pcscd mkdir -p "${DESTDIR}/usr/lib/x86_64-linux-gnu" # opensc-tool wants this dynamically, copy_exec doesn't know that cp -pL /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 "${DESTDIR}/usr/lib/x86_64-linux-gnu/libpcsclite.so.1" mkdir -p "${DESTDIR}/lib/x86_64-linux-gnu" # without this, pcscd aborts with a pthread_cancel error cp -pL /lib/x86_64-linux-gnu/libgcc_s.so.1 "${DESTDIR}/lib/x86_64-linux-gnu/libgcc_s.so.1" # this gets copied as a dangling symlink, fix it rm "${DESTDIR}/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist" cp -pL /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist "${DESTDIR}/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist" # pcscd needs this to open the reader once it has found it cp -pL /lib/x86_64-linux-gnu/libusb-1.0.so.0 "${DESTDIR}/lib/x86_64-linux-gnu/libusb-1.0.so.0"

  • Install another script as /etc/initramfs-tools/scripts/local-bottom/killpcscd to clean up:

    #!/bin/sh set -e PREREQ=cryptopensc prereqs() { echo "$PREREQ" } case $1 in prereqs) prereqs exit 0 ;; esac # because cryptopensc does not do it properly killall pcscd
Improve this answer
3
  • 1
    Very nice incentive to use smart-cards and kudos for achieving that, but I'd say a distribution-specific method which involves changing init system and third-party hack scripts shoved into system directories with unreadable paths cannot be deemed as an answer to how to use passkey files question. Highlights the incredible mess these software are, tho. Commented Sep 25, 2016 at 17:07
  • @dbanet, I fully agree and I hope that someone else will come along and add an answer describing how to do this in some other simpler way. Then the OP can choose their favorite. Commented Sep 25, 2016 at 20:41
  • dbanet and @Celada, exactly my thoughts. This is far too complicated and even if I manage to do this, its proprietary, meaning another vendor would have another method. :( Commented Sep 26, 2016 at 5:26
3

It's possible to simply store the luks password in a file.

I use this on my home computer; The root file system lives on a regular luks volume which I unlock with my passphrase at boot. An additional drive contains a luks volume with a generated password.

This additional volume is unlocked by a password file which lives on the encrypted root file system. It is automatically unlocked during boot if the root file system is unlocked.

My /etc/crypttab looks like this:

crypt-root UUID=c5a2cf25-0aae-457e-874f-fca7ea3d5742 none luks crypt-data UUID=96d79323-246d-49e0-9149-ec3a4cfc1c1e /etc/crypt-data.key luks

The third field is the keyfile, none for the root filesystem, but /etc/crypt-data.key for the data filesystem. /etc/crypt-data.key contains the luks password:

Tm90IHJlYWxseSBteSBwYXNzd29yZC4K

Note, a newline or any other white space will be taken as part of the password! Take care to generate this file without trailing newline. Also, ensure it has strict permissions:

-rw------- 1 root root 59 Sep 14 23:57 /etc/crypt-data.key

You should be able to duplicate this approach for multiple volumes (either with distinct passwords or one shared password, your choice).

Improve this answer
2
  • can you also mention how to configure LUKS to use the keyfile instead of the password? Commented Sep 26, 2016 at 5:31
  • @Nithin The keyfile is the third field in my example /etc/crypttab. I added a little extra text to make that clearer. Commented Sep 26, 2016 at 9:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.