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, not in root directory of the volume - the volume might not contain a file system.
 * May 26: Updated to match the implemented  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)  option (in addition to the existing   option) in the   or   commands
 * a  script to handle and delete the escrow packets.
 * The system administrator starts installation using this kickstart file.
 * anaconda recognizes the  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   in the   directory.  If a   option is specified in addition to , 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  .  (In both cases,   characters are replaced by   in volume labels and UUIDs.)
 * The system administrator's  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  script deletes the key escrow packets.  (This is left to the system administrator - they might decide not to send the packets anywhere in , only to set them up there, and send them later during manual system set up.)

Key escrow after installation &mdash; without a system management server
volume_key --save /path/to/volume [-c /path/to/cert] [--create-random-passphrase passphrase-escrow-packet] -o main-escrow-packet
 * The system administrator runs
 * /path/to/volume is a LUKS device, not the plaintext device containted within:  should report


 * extracts the key and other volume metadata for /path/to/volume (asking for a passphrase if necessary)
 * If  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).
 * saves the key and metadata to main-escrow-packet, and the random passphrase and metadata to passphrase-escrow-packet; if  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 &mdash; 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  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 &mdash; without a system management server
volume_key --reencrypt [-d /path/to/nss/db] escrow-packet-in -o escrow-packet-out
 * The system administrator locates the escrow packet and the NSS database that stores the certificate's private key.
 * The system administrator runs
 * 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 &mdash; 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 &mdash; manually
volume_key --restore /path/to/volume escrow-packet
 * 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
 * /path/to/volume is a LUKS device, not the plaintext device containted within:  should report


 * 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).
 * should support replacing a LUKS passphrase as well as adding it.

Restoring permanent access to a volume &mdash; 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.

volume_key --setup-volume /path/to/volume escrow-packet tmp-volume-name
 * 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
 * /path/to/volume is a LUKS device, not the plaintext device containted within:  should report


 * prompts for a packet password, decrypts the packet, and uses it to set up the encrypted volume, usually as tmp-volume-name (depending on the specific volume format).
 * The system administrator does whatever is necessary with tmp-volume-name (most likely mounting it and examining the stored files).
 * The system administrator destroys /dev/mapper/tmp-volume-name, usually using  (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  was used to generate and escrow the backup passphrase.

Restoring access to a volume using a backup passphrase &mdash; 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 &mdash; without a system management server
volume_key --secrets [-d /path/to/nss/db] escrow-packet volume_key --save [-c /path/to/cert] [/path/to/escrow-packet-in] /path/to/volume --create-random-passphrase escrow-packet-out
 * The system administrator locates the escrow packet and the NSS database that stores the certificate's private key.
 * The system administrator runs
 * 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
 * /path/to/volume is a LUKS device, not the plaintext device containted within:  should report


 * 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 &mdash; without a system management server
volume-key --reencrypt-volume /path/to/volume [-c /path/to/cert] -o escrow-packet
 * The system administrator runs
 * /path/to/volume is a LUKS device, not the plaintext device containted within:  should report


 * generates a new data encryption key, stores it and volume medatadata in the escrow packet; if  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).
 * 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 &mdash; 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.