Network_Bound_Disk_Encryption

Network_Bound_Disk_Encryption#

Overview#

The purpose of this page is to outline a plan for binding an encrypted disk to a network.

Use Case#

A server’s storage contains sensitive data. Suddenly, the disk fails. The disk needs to be sent in for warranty service. However, corporate policy does not permit the disclosure of this data. Since the drive has failed, it cannot be wiped.

While simply encrypting this disk with a master secret will suffice, the management for this is cumbersome. Either manual intervention is required for encryption and booting or the master secret needs to be shared in automation tooling risking the security of the system.

What is required is an automated system for provisioning and acquisition of per-host decryption keys.

Architecture#

The basic workflow is two steps:

  1. Provisioning: enabling the encrypted host for automatic decryption

  2. Acquisition: fetching the decryption key and using it to unlock the disk

This process is implemented using Petera. For an example of this workflow, see the Petera Disk Encryption instructions.

Provisioning#

Provisioning is the process whereby the encrypted host is enabled for automatic decryption at boot. This process presumes that the disk is already encrypted at install time using a recovery key. Alternatively, the provisioning process can be cooked into Anaconda directly.

  1. Generate a random key

  2. Add the random key to LUKS

  3. Encrypt the random key to the Petera server’s encryption certificate (online or offline operation)

  4. Store the encrypted random key on the local (encrypted) disk

  5. Copy the encrypted random key into the initramfs

No data is ever stored on the Petera server. This entire procedure can be performed offline if the Petera server’s encryption certificate is known.

Acquisition#

These are the steps that occur in the initramfs in order to decrypt the root volume.

  1. Bring up the network

  2. Connect to the Petera server and validate the TLS certificate (including stapled OCSP)

  3. Send the encrypted random key to the Petera server

  4. Receive the (decrypted) random key from the Petera server

  5. Use the random key to decrypt the disk

This process is entirely automated and the random key can only ever be decrypted by the Petera server. This requires network connectivity, but no authentication is needed.

Other Considerations#

Escrow#

Recovery key escrow is not part of this plan. It is likely that we will also want to generate a random recovery key and store it somewhere secure. This should probably be the FreeIPA Vault.

The escrow feature only requires changes to provisioning and/or Anaconda. The acquisition phase should not be affected.