Disk encryption key escrow use cases

Change log

• Sep 29: Clarify which block device /path/to/volume refers to
• Jun 30: Store escrow packets created by anaconda in /root, not in root directory of the volume - the volume might not contain a file system.
• May 26: Updated to match the implemented volume_key command-line interface.

Key escrow

The escrow packet may be encrypted using a certificate's public key. The certificate is chosen by a system administrator: if using the RH system management server, this is the key escrow server's certificate; if using something else, the certificate's origin and other uses are site-specific.

Key escrow during installation

• The system administrator creates a kickstart file; the kickstart file contains:
  • a (new) --escrowcert <url-of-certificate> option (in addition to the existing --encrypted option) in the part or autopart commands
  • a %post script to handle and delete the escrow packets.
• The system administrator starts installation using this kickstart file.
• anaconda recognizes the --escrowcert option: after setting up an encrypted volume, it creates an escrow packet encrypted by the certificate's public key, and stores it as a file named volume_label-volume_uuid-escrow in the /root directory. If a --backuppassphrase option is specified in addition to --escrow, an additional random passphrase is generated, set up for the volume in addition to the original passphrase (the volume format must support this), and stored in a file named volume_label-volume_uuid-escrow-backup-passphrase. (In both cases, '/' characters are replaced by '_' in volume labels and UUIDs.)
• The system administrator's %post script handles the key escrow packets:
  • If using the RH system management server, it registers the installed system as a management client, then sends the packets to the server.
  • Otherwise, it stores the packets in a site-specific way (uploading them to a server, sending by e-mail, storing on an USB drive...)
• The %post script deletes the key escrow packets. (This is left to the system administrator - they might decide not to send the packets anywhere in %post, only to set them up there, and send them later during manual system set up.)

Key escrow after installation — without a system management server

• The system administrator runs

volume_key --save /path/to/volume [-c /path/to/cert] [--create-random-passphrase passphrase-escrow-packet] -o main-escrow-packet

/path/to/volume is a LUKS device, not the plaintext device containted within: (blkid -s TYPE /path/to/volume) should report TYPE="crypto_LUKS"

• volume_key extracts the key and other volume metadata for /path/to/volume (asking for a passphrase if necessary)
• If --create-random-passphrase is specified, an additional random passphrase is generated and set up for the volume in addition to the original passphrase (the volume format must support this).
• volume_key saves the key and metadata to main-escrow-packet, and the random passphrase and metadata to passphrase-escrow-packet; if -c is specified, the packets are encrypted by the certificate's public key (using CMS), otherwise they are encrypted using a user-provided password (using CMS, if support for password encryption is added to NSS; currently it uses gnupg).
• The system administrator stores the escrow packets in a site-specific way.
• The system administrator deletes the local copies of the escrow packets.

Key escrow after installation — with a system management server

This is the same as above, except that when a system management client is set up, the client can automatically determine the correct certificate, and after the escrow packet is created, the client can automatically send it to the server. The system administrator uses the system management client to perform the operation instead of using volume_key directly.

Key recovery

Key recovery consists of two principal steps: making the escrow packet available to the client machine, and using it.

Making the packet available — without a system management server

• The system administrator locates the escrow packet and the NSS database that stores the certificate's private key.
• The system administrator runs

volume_key --reencrypt [-d /path/to/nss/db] escrow-packet-in -o escrow-packet-out

• volume_key decrypts escrow-packet-in (using a key stored in the provided NSS database, or prompting for a password), re-encrypts it using a provided (ideally one-time) password, and writes it to escrow-packet-out.

Making the packet available — with a system management server

• A system administrator locates the machine in the system management server's UI, selects the relevant volumes (and relevant key escrow packets, if more than one key escrow packet is stored for a volume), and initiates a recovery operation.
• The system administrator authorizes the operation (e.g. by manually entering the passphrase of the escrow server's master private key).
• The escrow packet is decrypted, and re-encrypted using a system-administrator-provided (ideally one-time) password.
• The system administrator downloads the re-encrypted escrow packet.

Restoring permanent access to a volume — manually

• The system administrator boots the client: from the client's regular system if available, or from a rescue medium (e.g. if the root volume passphrase was forgotten).
• The available escrow packet is copied to the system: e.g. over the network, or on a flash disk.
• The system administrator runs

volume_key --restore /path/to/volume escrow-packet

/path/to/volume is a LUKS device, not the plaintext device containted within: (blkid -s TYPE /path/to/volume) should report TYPE="crypto_LUKS"

• volume_key prompts for a packet password, decrypts the packet, and uses it to restore access to the volume (e.g. allowing the user to set up a new passphrase if the volume uses LUKS).

volume_key should support replacing a LUKS passphrase as well as adding it.

Restoring permanent access to a volume — using FirstAidKit

• The system administrator boots from into a rescue mode, or using a live CD (assuming that there is a RHEL live CD, and that it contains FirstAidKit).
• The system administrator starts FistAidKit, selecting the "recover access to encrypted volume" option.
• FirstAidKit prompts for the volume, escrow packet location (probably a pre-specified system management server or a flash disk), packet passphrase, and uses the information to restore access to the volume.

Gaining temporary access to a volume

This can be used when temporary access to the encrypted data is necessary, e.g. for forensic examination.

• The system administrator boots a computer that has access to the volume.
• The available escrow packet is copied to the system: e.g. over the network, or on a flash disk.
• The system administrator runs

volume_key --setup-volume /path/to/volume escrow-packet tmp-volume-name

/path/to/volume is a LUKS device, not the plaintext device containted within: (blkid -s TYPE /path/to/volume) should report TYPE="crypto_LUKS"

• volume_key prompts for a packet password, decrypts the packet, and uses it to set up the encrypted volume, usually as /dev/mapper/tmp-volume-name (depending on the specific volume format).
• The system administrator does whatever is necessary with /dev/mapper/tmp-volume-name (most likely mounting it and examining the stored files).
• The system administrator destroys /dev/mapper/tmp-volume-name, usually using dmsetup remove tmp-volume-name (depending on the specific volume format, something different may be necessary for LVM crypt).

Restoring access to a volume using a backup passphrase

This can be used if no technician is available locally and the above-described procedures are too complex, or if the user has no access to additional tools such as a rescue CD (e.g. on a business trip). It is possible only if --create-random-passphrase was used to generate and escrow the backup passphrase.

Restoring access to a volume using a backup passphrase — with a system management server

• A system administrator locates the machine in the system management server's UI, selects the relevant volumes (and relevant key escrow packets, if more than one key escrow packet is stored for a volume), and initiates a passphrase decryption.
• The system administrator authorizes the operation (e.g. by manually entering the passphrase of the escrow server's master private key).
• The escrow packet is decrypted, and the randomly-generated passphrase is displayed to the system administrator; the volume key is stored for later usage.
• The passphrase is told to the user, who can use it to access their data (and then change it to something more convenient).
• Eventually (after the client connects to the management server), the management server uses the stored volume key to ask the client to generate a new random passphrase, and send it back (similar to setting up the random passphrase during the key escrow operation).

Restoring access to a volume using a backup passphrase — without a system management server

• The system administrator locates the escrow packet and the NSS database that stores the certificate's private key.
• The system administrator runs

volume_key --secrets [-d /path/to/nss/db] escrow-packet

• volume_key decrypts escrow-packet (using a private key stored in the provided NSS database, or prompting for a passphrase), and writes the random passphrase (if stored in the packet) to standard output.
• The passphrase is told to the user, who can use it to access their data (and then change it to something more convenient).
• Eventually (after the system administrator has access to the machine), the system administrator removes the random passphrase from the volume (if the user has not replaced it with their passphrase)
• The system administrator runs

volume_key --save [-c /path/to/cert] [/path/to/escrow-packet-in] /path/to/volume --create-random-passphrase escrow-packet-out

/path/to/volume is a LUKS device, not the plaintext device containted within: (blkid -s TYPE /path/to/volume) should report TYPE="crypto_LUKS"

• volume_key gets the key (either from the volume, prompting for a passphrase, or from escrow-packet-in, which was made available using one of the above-described procedures), generates a new random passphrase, sets it up for the volume in addition to the original passphrase, and stores the the generated passphrase in escrow-packet-out.
• The system administrator stores the new escrow packet in a site-specific way (replacing the old passphrase escrow packet).

Replacing the data encryption key

(Requires underlying volume support for on-line re-encryption; this is planned for LVM.)

Replacing the data encryption key — without a system management server

• The system administrator runs

volume-key --reencrypt-volume /path/to/volume [-c /path/to/cert] -o escrow-packet

/path/to/volume is a LUKS device, not the plaintext device containted within: (blkid -s TYPE /path/to/volume) should report TYPE="crypto_LUKS"

• volume_key generates a new data encryption key, stores it and volume medatadata in the escrow packet; if -c is specified, the packet is encrypted by the certificate's public key (using CMS), otherwise it is encrypted using an user-provided password (using CMS, if support for password encryption is added to NSS, something else otherwise).
• volume_key initiates a password re-encryption operation, asking for a volume passphrase if necessary.
• The system administrator stores the escrow packet in a site-specific way.

Replacing the data encryption key — with a system management server

The functionality is the same as above, but the operation can be initiated automatically by the management server (based on a defined policy) and the escrow server certificate can be automatically supplied by the management client. If access to the old key were not available automatically, the server could make a previous escrow packet available to the client, to let the client extract a volume key.