Secure and User-Friendly Encrypted Suspend-to-Disk with Debian GNU/Linux

Motivation

Suspend, a.k.a. hibernate, is an important method for usability of today’s laptops. There are essentially two flavors with different implications on security:

• Suspend-to-RAM (ACPI S3): This means that the processes are frozen, and all hardware components besides the main RAM (and minimal activity do refresh the DRAM cells) are turned off. This includes the display, the harddisk, and all peripheral components, and thus typically saves the majority of the power. On my Thinkpad T42p with the standard battery, the S3 state consumes roughly 1 percent of battery life each hour. The disadvantage of suspend-to-RAM is that a power failure leads to an unclean system crash, that is, batteries can not be exchanged in this mode when the system only uses one. It also needs a close integration between the OS, the BIOS, and the hardware, and is often tricky to get running with Linux (on the MacBook, it is still not completely stable at the time of this writing).
  From a security point of view, suspend-to-RAM does not open any additional vulnerabilities. When running processes are frozen, their complete state is preserved in RAM, and they will continue immediately after returning from S3 state. Therefore, all operating system security functions are still in place in this state, and after resume they continue to protect the system. This includes access control and crypto keys kept in RAM. In fact, as far as the OS is concerned, an S3 suspend is just a jump forwards for the system clock. It is advisable to lock the system before entering a suspend-to-RAM state so that the user’s password needs to be entered after resume, but this is comparable to locking after a period of inactivity, and typcially just enables the screensaver lock function.
• Suspend-to-Disk: This means that the processes are frozen, RAM content is written to the harddisk, and the complete system turns off normally like it does during a clean shutdown.

As long as suspend-to-RAM works under Linux and power is not/does not need to be interrupted, it is the better solution, and far less complicated to implement securely. But for those odd cases where suspend-to-disk is required, e.g. for switching batteries, when battery runs out, or when the machine needs to be switched off completely (such as in planes), we also need to implement it in a secure way. Fortunately, Linux gives us the possibility to do so. Read on for details.

Sidenote: Suspend-to-RAM and suspend-to-disk can be combined in a neat way: just perform the necessary steps for suspend-to-disk, but instead of switching the system off, switch to the S3 state. This way, resume will be quick from the S3 state, but when power is interrupted, the system can still resume from the disk state.

Requirements

The combined suspend-to-RAM/suspend-to-disk with encrypted disk state requires the following components:

• A recent Linux kernel, preferably >= 2.6.12, tested with 2.6.18. This needs LVM crypto support.
• One of the suspend-to-disk methods, tested with the suspend2 kernel patch and uswsusp.
• Scripts for initiating suspend and resuming from S3. I use the Debian hibernate package version 1.94-2 at the point of this writing with added custom hook scripts.
• An initramfs image with code for resuming from the disk state. I use the initramfs-tools package version 0.84 to create it.

Then either:

• dpkg-reconfigure uswsusp: enable encryption support with RSA key and use a strong password! This already works and the password is only used during suspend/resume. However, there is the issue that swap (which is required for uswsusp) is generally not encrypted and thus may contain sensitive data. This is generally a problem and should be addressed even without suspend. One way to do this is the second method.

or

• Encrypt the swap space in general and let uswsusp use the already encrypted volume. In this case, do not enable encryptioon for uswusp.

1. 1. In /etc/crypttab add a line:
      cswap /dev/sdxY /dev/urandom swap
   2. In /etc/fstab set swap to use this encrypted volume:
      /dev/mapper/cswap none            swap    sw              0       0

TODO: Need to keep the random key for swap, encrypt it with public key during bootup, and decrypt in initramfs.
TODO: Encrypt /tmp and parts of /var.