Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
How shall that be a security problem? Because you have to transfer the key file to the system for checking? –  Hauke Laging May 18 '13 at 1:13

1 Answer 1

up vote 4 down vote accepted

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...

share|improve this answer
    
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.