5

I am writing a Chef LWRP to add a key to a LUKS container and I'm having difficulty coming up with a way to determine whether or not my key already exists. cryptsetup luksAddKey will happily add the same keyfile multiple times, so I can't simply keep calling luksAddKey each Chef run.

So far, the best that I have come up with is 

cryptsetup luksDump /dev/xvdf1 --dump-master-key --key-file <thenewkey> > /dev/null

That seems:

  1. CPU intensive
  2. not very secure

Anyone have a better idea?

Thanks!

Aaron Brown
  • 1,677
  • 1
  • 12
  • 21

1 Answers1

4

I don't see any chance for testing a key without unlocking the volume (at least referring to the CPU load). But who doesn't have this few CPU seconds? Do you have lots of LUKS volumes per system?

You can alternatively do this:

Every time you add a key you store a digest of the file (that need not even be a secure digest; even MD5 would do). You make a directory /etc/my_luks_keyfiles. For every LUKS volume in the system you create a subdir with the UUID (cryptsetup luksUUID /dev/bla). If you add a key then you create a file with e.g. the timestamp as name and the digest as content. If you remove a key then you remove the file. If you want to know whether a key is active then you compare all files in the directory against the digest (i.e. you need not transfer the key file).

And if there are more or less files than active slots then you know you messed it up...

Hauke Laging
  • 5,157
  • 2
  • 23
  • 40
  • Thanks for the response, Hauke. The reality that I've observed is that while it's only a few seconds to unlock the volume, it completely saturates a CPU during this operation which could prove problematic on a database in an OLTP scenario. Thanks for the alternatives, also. – Aaron Brown May 20 '13 at 22:06
  • @AaronBrown It's the **aim** that the CPU is used completely! But this should affect one core only. On the other hand: Nothing prevents you from starting `cryptsetup` with nice -19. – Hauke Laging May 20 '13 at 23:30