Full disk encryption

Full disk encryption

Ubuntu Core 20 uses full disk encryption (FDE) whenever the hardware allows, protecting both the confidentiality and integrity of a device’s data when there’s physical access to a device, or after a device has been lost or stolen.

Built-in FDE support requires both UEFI Secure Boot and TPM (Trusted Platform Module) support, but its implementation in Ubuntu Core is generic and widely compatible to help support a range of hardware. TPM-based FDE seals the FDE secret key to the full EFI state, including the kernel command line, which is subsequently unsealed by the initrd code in the secure-boot protected kernel.efi at boot time.

The following factors affect how a device is encrypted:

Storage layouts

The layout of the generated image used to install Ubuntu Core, and the resultant storage on the device, is described by the gadget snap and its associated gadget.yaml.

Ubuntu Core 20 typically uses the following storage partitions:

  • ubuntu-seed (role: system-seed; read-only, ext4 or typically vfat)
  • ubuntu-boot (role: system-boot; read-only, ext4 or vfat):
  • ubuntu-save (role: system-save; writable, ext4, encrypted)
  • ubuntu-data (role: system-data; writable, ext4, encrypted)

ubuntu-save is mandatory on an encrypted system. The initramfs bootstrapped from ubuntu-boot is responsible for decrypting both the ubuntu-save and ubuntu-data partitions.

The system boot process:

  1. verifies the bootloaders and kernel signatures
  2. measures the above and the kernel command line with the TPM
  3. on-top of the above trusted set, the snapd initrd code measures the snap device model
  4. snapd then separately verifies other snaps with their assertions as needed

When run normally, the snap content comes from snaps in the encrypted data partition, with the exception of the kernel image which is loaded from the system boot partition via secure boot. In any case the unsealing of the disk encryption key(s) is tied to the correct TPM boot measurements.

For further details on how Ubuntu Core 20 uses these partitions, what they contain, and how they boot, see Storage layout.

Disabling encryption

It is sometimes desirable to install Ubuntu Core 20 without encryption, even when the device hardware supports it.

This option is provided by the “storage-safety” setting in the model assertion used to build the installable image. It can be set to one of the following:

  • prefer-unencrypted: do not encrypt by default, even if the device supports encryption.
  • prefer-encrypted: do encrypt if the hardware supports it
  • encrypted: ensure encryption is used and fail if the device does not support it

See Creating a bespoke image for further details on building an image from a model assertion.

Model grade

The grade option in the model assertion is used to set the constraints for the device. It can be one of the following:

  • dangerous: relax some of the constraints here (mandatory snap id for example), and should allow for the use of unasserted snaps, devmode snaps, or the presence of extra snaps in the recovery system. These relaxations are meant for development and not for production system use as they weaken the system security.
  • signed (default): no unasserted (unsigned) snaps or snaps not mentioned in the model can appear or be used in the recovery system.
  • secured: same properties as signed plus it is mandatory for the device to use full disk encryption and secure boot.

The snap model command can be used to view the currently running model declaration, including its grade and storage-safety values:

snap model --verbose
brand-id:      bJzr2XzZg6Qv6Z53HIeziXyxtn1XItIq
model:         ubuntu-core-20-amd64
grade:         signed
serial:        0fb187ff-a037-42ca-b0d6-1a802245e799
architecture:  amd64
base:          core20
timestamp:     today at 08:54 UTC

The values of both a model’s grade and the storage-safety option influence whether a device is encrypted, unencrypted, or generates an error, as shown in the tables below:

With hardware support

grade ↓ / safety → unset encrypted prefer-encrypted prefer-unencrypted
dangerous encrypted encrypted encrypted unencrypted
signed encrypted encrypted encrypted unencrypted
secured encrypted encrypted encrypted invalid

Without hardware support

grade ↓ / safety → unset encrypted prefer-encrypted prefer-unencrypted
dangerous unencrypted error output unencrypted unencrypted
signed unencrypted error output unencrypted unencrypted
secured error output error output error output invalid

Note : grade:secured is the same as grade:signed and storage-safety:encrypted.
storage-safety:prefer-encrypted is the same as unset

A couple of comments and suggestions:

writable should be in italics here too

s/DIsabling/Disabling/

Perhaps it should be ... weaken the system security ?

In the table, under prefer-unencrypted, the rows should be:

|-------------|
| unencrypted |
|-------------|
| unencrypted |
|-------------|
| invalid     | 
|-------------|
1 Like

Thanks for the fixes and suggestions! I’m incorporated them all into the above doc.