Passphrase protected keyfile usbs

philanc · 10-02-2013, 01:29 PM

Quote:

Originally Posted by hutyerah

philanc, I like your style and would like to subscribe to your newsletter.

But I'm confused... if I put the keyfile in the initrd, then I can't use a passphrase as well, right? I guess if I did this I'd effectively have my regular slackware boot partition just on the usb stick as well as my encrypted keyfile partition.

A) An option is to store in the initrd an encrypted keyfile. At boot time, the encrypted keyfile should be decrypted before being used with cryptsetup.

Of course it implies that you have also added a (hopefully small!) file encryption utility program to the initrd, with its dependencies if any.

An reasonably sane and well-kown example could be bcrypt (you will find it at SourceForge). The only dependency that may not be in the regular initrd is zlib which you should also add.

B) Another, simpler option is to use for the keyfile the concatenation of a password and a file stored within the initrd (let's call it 'key.part')

The complete content of the keyfile would be:

Code:

  <your password> <content of file key.part, stored in the initrd>

The keyfile can be built on the fly, just before calling cryptsetup:

Code:

  echo "Enter your encrypted partition password:"
  read -s PASSWD
  echo $PASSWD $(cat key.part) > keyfile
  unset PASSWD

This is obviously a rough skeleton. To make it more practical, you would put all this in a loop to make sure that if you make a typo entering the password, you can try again!

Code:

  while true ; do
    read password, build keyfile
    cryptsetup luksOpen, with keyfile
    if cryptsetup has succeeded, then
      overwrite/delete key.part, keyfile
      break
  done
  ... continue with initrd processing ...

HTH

Phil

hutyerah · 10-02-2013, 07:17 PM

To me that defeats the purpose of having the password though- i.e. if the usb key falls into the wrong hands, the password can still be read from it. Better to use an encrypted keyfile. Thanks though

philanc · 10-02-2013, 11:12 PM

Quote:

Originally Posted by hutyerah

To me that defeats the purpose of having the password though- i.e. if the usb key falls into the wrong hands, the password can still be read from it.

No, because the password is _never_ stored in the USB key.

When the PC boot, the kernel and the initrd are loaded in memory by the boot loader. The initrd, which is a compressed cpio archive, is expanded in RAM into a small file system (tmpfs). So all the operations I described above such as reading the password and building the keyfile, take place in RAM. The initrd.gz file is not modified during the boot. Nothing is written into the USB stick.

So if your USB stick is lost or stolen at any moment, it still contains only a part of the keyfile (the 'key.part' file), and the complete keyfile cannot be reconstructed without the password.

Hope it clarifies things!

Phil

hutyerah · 10-02-2013, 11:19 PM

Gotcha. Not bad

chrisretusn · 10-03-2013, 08:28 AM

Interesting discussion here. One note about key files. Make sure you have copies elsewhere. If something was to happen to your stick, you would be locked out forever if you don't have a copy of the key file tucked away. In fact it best to keep more that one copy of your key file tucked away. I speak from experience on this.

philanc · 10-03-2013, 12:06 PM

Quote:

Originally Posted by chrisretusn

Interesting discussion here. One note about key files. Make sure you have copies elsewhere. If something was to happen to your stick, you would be locked out forever if you don't have a copy of the key file tucked away. In fact it best to keep more that one copy of your key file tucked away. I speak from experience on this.

You are definitely right here, and I should have mentioned it earlier.

What I would do is to first create (cryptsetup luksFormat) the encrypted partition with a long, robust password.

Then I add with luksAddKey a keyfile built as described above, by concatenating a file to be stored in the initrd and a "day-to-day" password.

At this stage, I could unlock the encrypted partition either with the long password, or with my specially crafted initrd and the day-to-day password.

Then I can decide if I prefer to remove the long password (luksRemoveKey) and carefully backup the initrd, or just keep it. As I don't use it, the long password is not exposed, and it leaves an option to easily unlock the encrypted partition, should my precious initrd fail

hutyerah · 10-03-2013, 07:34 PM

Yeah, I just dd the first usb onto a few extra ones and put them in secure places. Like, a safe. Haha.