Use the Force, LUKS

Not like there aren't a bunch of LUKS guides out there already ...mostly posting this one for myself.

Today, was working on turning the (attrocious - other than a long-past deadline, DISA, do you even care what you're publishing?) RHEL 7 V0R2 STIGs specifications into configuration management elements for our enterprise CM system. Got to the STIG item for "ensure that data-at-rest is encrypted as appropriate". This particular element is only semi-automatable ...since it's one of those "context" rules that has a "if local policy requires it" back-biting element to it. At any rate, this particular STIG-item prescribes the use of LUKs.

As I set about to write the code for this security-element, it occurred to me, "we typically use array-based storage encryption - or things like KMS in cloud deployments - that I can't remember how to cofigure LUKS ...least of all configure it so it doesn't require human intervention to mount volumes." So, like any good Linux-tech, I petitioned the gods of Google. Lo, there were many results — most falling into either the "here's how you encrypt a device" or the "here's how you take an encrypted device and make the OS automatically remount it at boot" camps. I was looking to do both so that my test-rig could be rebooted and just have the volume there. I was worried about testing whether devices were encrypted, not whether leaving keys on a system was adequately secure.

At any rate, at least for testing purposes (and in case I need to remember these later), here's what I synthesized from my Google searches.

1. Create a directory for storing encryption key-files. Ensure that directory is readable only by the root user:
   

   install -d -m 0700 -o root -g root /etc/crypt.d

2. Create a 4KB key from randomized data (stronger encryption key than typical, password-based unlock mechanisms):
   

   # dd if=/dev/urandom of=/etc/crypt.d/cryptFS.key bs=1024 count=4

   ...writing the key to the previously-created, protected directory. Up the key-length by increasing the value of the count parameter.
    
3. Use the key to create an encrypted raw device:
   

   # cryptsetup --key-file /etc/crypt.d/cryptFS.key \
   --cipher aes-cbc-essiv:sha256 luksFormat /dev/CryptVG/CryptVol

4. Activate/open the encrypted device for writing:
   

   # cryptsetup luksOpen --key-file /etc/crypt.d/cryptFS.key \
   /dev/CryptVG/CryptVol CryptVol_crypt

   Pass the location of the encryption-key using the --key-file parameter.
    
5. Add a mapping to the crypttab file:
   

   # ( printf "CryptVol_crypt\t/dev/CryptVG/CryptVol\t" ;
      printf "/etc/crypt.d/cryptFS.key\tluks\n" ) >> /etc/crypttab

   The OS will use this mapping-file at boot-time to open the encrypted device and ready it for mounting. The four column-values to the map are:
   1. Device-mapper Node: this is the name of the writable block-device used for creating filesystem structures and for mounting. The value is relative. When the device is activated, it will be assigned the device name /dev/mapper/<key_value>
   2. Hosting-Device: The physical device that hosts the encrypted psuedo-device. This can be a basic hard disk, a partition on a disk or an LVM volume.
   3. Key Location: Where the device's decryption-key is stored.
   4. Encryption Type: What encryption-method was used to encrypt the device (typically "luks")
    
6. Create a filesystem on the opened encrypted device:
   

   # mkfs -t ext4 /dev/mapper/CryptVol_crypt

7. Add the encrypted device's mount-information to the host's /etc/fstab file:
   

   # ( printf "/dev/mapper/CryptVol_crypt\t/cryptfs\text4" ;
      printf "defaults\t0 0\n" ) >> /etc/fstab

8. Verify that everything works by hand-mounting the device (`mount -a`)
9. Reboot the system (`init 6`) to verify that the encrypted device(s) automatically mount at boot-time

Keys and mappings in place, the system will reboot with the LUKSed devices opened and mounted. The above method's also good if you wanted to give each LUKS-protected device its own, device-specific key-file.

Note: You will really want to back up these key files. If you somehow lose the host OS but not the encrypted devices, the only way you'll be able to re-open those devices if you're able to restore the key-files to the new system. Absent those keys, you better have good backups of the unencrypted data - becuase you're starting from scratch.