What's a secure way to prompt for a password and erase the cached password afterwards in Linux?

Question

So I have multiple hard drives encrypted with the same password and instead of having to enter it multiple times I'd like to have it set up so that after booting I automatically get a password-box displayed into which I enter the password once and which then mounts all the encrypted hard drives and securely removes the password from cache/memory afterwards.

It seems that this isn't yet possible via standard VeraCrypt. Hence it looks I need to write a short script to get this functionality. However for that I need to know how to securely prompt for a password and most importantly: how to securely erase the cached password after the volumes have been mounted.

I'm using Debian 9.1 with KDE.
^{(I'd also be interested whether there are any specific reasons why this isn't a standard VeraCrypt feature.)}

Answer 1

I don't think you will be able to guarantee that.

So, let's assume you have a command that takes the password in a prompt, eg.

echo mypassword | cryptsetup luksOpen /dev/disk volume`

And want to ask for the password once and open several volumes:

#!/bin/sh
set -e
read -p "What's the password? " password || exit 1
for disk in disk1 disk2 disk3; do
   FOLDER=/media/$USER/$disk
   echo "$password" | cryptsetup luksOpen /dev/$disk $disk && \
   mkdir -p "$FOLDER" && \
   mount /dev/mapper/$disk "$FOLDER/$disk"
done
password="xxxxxxxxxxxxxxxxxxxxxx"

This shell script would do. Except that, after bash finishes, and the memory is returned to the system, we have no guarantee that the password itself is not still in memory somewhere (no, despite that last statement your shell may not overwrite the location where it was saved).

So, we could rewrite this in C, and manually ensure that such location is overwriten, using something like memset_s (yes, a normal memset wouldn't do).

Still, there could be copies of the plaintext password in the stdio buffers, the ones used by cryptsetup, etc. The kernel will not give such pages to other programs without first zeroing them, but if a forensic investigator came freezing your memory slots with nitrogen and dumping it contents, it could still be there.

Moreover, the actual disk key (decrypted from the passphrase) will be in memory, for as long as you have the volumes mounted. So, it is probably not worth insisting on ensuring that much, and just letting the program finish would be acceptable.

I would suggest encrypting the main disk partition (and swap, of course), and have keyfiles for each of the other disks on there (they can be readable just for root). Thus, you only need to enter one password (at boot time) and will be able to decrypt all disks. There are no encrypted passwords laying out when the system is powered down, and if an attacker got root your system so they would be able to steal your keyfiles, he could access the files directly as well (and do too many other nasty things), so it doesn't make things much more insecure.

The main scenario for that I can think is where repeated access is obtained, eg. your encrypted disks are cloned, and later (after you shreded some secrets from them), they obtain your passphrase/keyfiles, thus being able to decrypt their earlier copy. They could probably do that as well by extracting the in-memory disk keys, but the existence of the keyfiles make things simpler. (In order to avoid this, change your passwords and keyfiles and rekey the disk after removing the Coke secret formula)

Hope this helps

Answer 2

It sounds like the setup you want is similar to mine, except I'm using LUKS. As far as I can tell everything should work with VeraCrypt by changing the commands and options slightly.

You don't specify, but it sounds like you have an encrypted root device and one or more encrypted secondary devices, if not this should still work fine by picking a device to use as the primary device.

I used to use Debian's decrypt_derived script, but last I checked (over a year ago) it wasn't working with systemd's cryptsetup, so instead I have a keyfile on my root device that's used to decrypt the second device.

To start I assume you have the root device decrypted and mounted at /.

Create random 256 bit keyfile:

head -c 32 /dev/urandom | sudo tee /keyfile >/dev/null && sudo chmod 400 /keyfile

Add keyfile as a key to secondary device(s)

sudo cryptsetup luksAddKey [device] /keyfile

Edit /etc/crypttab:

[primary device name]    UUID=[primary device uuid]    none        luks
[secondary device name]  UUID=[secondary device uuid]  /keyfile    luks,noearly

From man crypttab:

   noearly
       The cryptsetup init scripts are invoked twice during the boot process -
       once before lvm, raid, etc. are started and once again after that.
       Sometimes you need to start your encrypted disks in a special order. With
       this option the device is ignored during the first invocation of the
       cryptsetup init scripts.

So the secondary device(s) will be decrypted after the primary device has been mounted and the keyfile is available (as long as your primary device is listed in /etc/fstab correctly).

Don't forget to update initramfs so the crypttab changes take effect:

sudo update-initramfs -u -k all

This approach has the advantage that systemd handles asking for the password and doesn't require you to maintain a script. The disadvantage is that there's a keyfile sitting on one of your devices, so dismounting the secondary devices won't prevent someone with root from decrypting them.