[pkg-cryptsetup-devel] cryptsetup and hibernation

[Christoph Anton Mitterer]

Hey.

I'd like to use hibernation (suspend to disk) in a secure manner with
cryptsetup.

Perhaps someone can help me with the following:

1) My assumption is that in general works roughly the following:
   - The kernel freezes the processes, and stores an in a swap area (or
     does it have to be swap?).
   - When I start the system again, a fresh kernel is loaded from
     wherever I boot from, e.g. some boot USB stick.
   - I guess somewhere in between here, the initramfs must run and e.g.
     set up dm-crypt or LVM.
     So initramfs scrip hooks DO run before the hibernated image is
     restored, right?
   - That kernel then finds the hibernated image, loads it again and
     ultimately replaces itself with the image.
   Right so far?


2) When one now encrypts the swap area to protect the memory contents
   from the hibernated session...
   ... is the RESUME= parameter from initramfs tools the "decrypted"
   dm-crypt volume? Or does it have to be set to the device containing
   the ("encrypted") dm-crypt volume?


3) In principle I think there are the following options:
   a) Make a completely separate dm-crypt volume for the swap, and use
      two passphrases (or at least enter it twice).
      => of course that's rather unhandy.

   b) Use the same passphrase, and something like decrypt_keyctl to
      fetch the (previously entered same) key from e.g. the kernel
      keyring.
      => that has IMO the disadvantage, that when one uses "extreme"
         settings for the LUKS KDF (e.g. Argon2), things would still
         take twice as long to unlock, even though one doesn't have to
         enter the passphrase twice

   c) Use one dm-crypt volume, and place e.g. LVM in that, or maybe it
      would even work with a simple partition table (inside the dm-
      crypt) and have there the root filesystem and swap.
      => IIRC there were in the past some reports about issues with dm-
         crypt+lvm+btrfs.
         Maybe I'm mistaken about that, and probably these issues have
         been fixed in the meantime, but still, I'd like to avoid
         another block device layer if possible.

   d) Use decrypt_derived.
      My understanding is that this simply takes the hex encoded master
      key from some other (already "opened") dm-crypt mapping as
      passphrase for the target device (i.e. the swap area),... so it's
      not used as the master key for the swap area, but just as the
      keyslot passphrase (in terms of LUKS).
      
      AFAIU, since this is already high-entropy, one should be able to
      take the minimal settings for the KDF on the swap device and
      still be as safe as with the other device.

      => Does that sound reasonable?

      Little drawback is of course that if someone finds out the
      master key for the main dm-crypt volume, the swap area is also
      automatically broken, but this is of course rather a little
      concern.

    e) Use a keyfile that is on another device that is "decrypted"
       during the initramfs.
       
       Should have the same properties than (d) (i.e. one should be
       able to "drop" the KDF).

       => But does cryptsetup's initramfs script support that?
          Especially, is there some guaranteed order in which the
          devices are "decrypted"?
          Like root fs first, then the ones marked with "initramfs"
and 
          then the resume device? Or is it simply the order in which
          they appear in crypttab (and is that like guaranteed
          interface or is it just the current behaviour)?

     f) Use a swap file within the root fs (which is anyway already
        decrypted in the initamfs).

        I'd have kinda liked this idea for several reasons:
        - security is per se the same as that of the root filesystem
        - no "losses" because of additional KDF
        - one doesn't "waste" storage to a separate swap parition,
          which then cannot be easily used by the fs
          e.g. in my case, I have so much memory that I wouldn't want
          swap to be normally used - just for the sake of hibernation

        I think btrfs has some limited swap file support since a while.
        => But is that supported by initramfs-tools respectively
           cryptsetup?


Thanks,
Chris.