Full Disk Encryption with GRUB2 and TPM

Systems targeted are those using UEFI firmware and Trusted Platform Module (TPM) 2.0 with Secure Boot enabled.

Motivation

The goals of Full Disk Encryption (FDE) are to secure sensitive data against loss and theft. Today, private user data is increasingly coveted, with the number of cyber security threats only increasing, especially on large servers where a huge amount of data is stored. The attackers seek to steal these, demanding ransom or threatening disclosure. This can be very expensive for the attacked company with ethical and moral repercussions on customers. Therefore, FDE is a security feature designed to protect data, which is encrypted and impossible to read without an appropriate  passphrase / key.

Starting with SUSE SLE Micro 6.0, an optional method to unlock devices, implements the Trusted Platform Module (TPM). It allows an unattended auto-unlock, providing a pass is no longer required. That completely fits to secure disks that have been put in a machine in a safe location. With FDE and TPM, your data becomes protected and cannot be read outside of your machine.

Booting an Encrypted Disk

As introduced, FDE is a security method for protecting sensitive data at hardware level and it will require physical access and request a password to decrypt the data.

“Everything is Encrypted?” Not really, we encrypt as much as possible the disk but the UEFI Firmware requires an unencrypted EFI System Partition. From there the UEFI Firmware will load shim which subsequently loads grub.efi. grub.efi will then read its configuration file from the encrypted root file system.

The grub cryptomount command in grub.cfg in the EFI System Partition will be called to get access to the encrypted device and a passphrase will be requested interactively.

In the next step grub will read grub.cfg in /boot/grub2/ from the root partition to continue the boot process and hand over control to the chosen Linux kernel.

Then the Linux kernel will have to gain access again to the encrypted root file system, which means it will need to decrypt requesting the passphrase from the user a second time.

The user has been asked twice for the passphrase, by grub and by the Linux kernel. Not what do we want to, so How to auto-unlock the encrypted root securely? And how to pass the disk decryption key from grub2 to kernel ?

Auto-unlocking the disk securely

Auto-unlocking in GRUB2

We start by using the TPM for the creation of a recovery password and a random binary key during the installation. The second step is to seal this key against the PCR values during the first boot. During subsequent boot processes, the key is unsealed before cryptomount is called.

To seal, the tool fde-tools will be called before updating grub.cfg. It invokes the pcr-oracle command which predicts the PCR values needed to seal the data based on the TPM event log.

PCRs to seal will be from UEFI Firmware code with PCR0, PCR2 and PCR4; from Secure Boot with PCR7; from Grub2 files with PCR9 (Grub2 extends the expanded ‘variables’ into PCR8, which makes it difficult to predict)

pcr-oracle --input random-key.bin --output sealed.tpm 
  --key-format tpm2.0 
  --algorithm sha256 
  --from eventlog 
  --stop-event "grub-command=cryptomount" 
  --before 
  seal-secret 0,2,4,7,9

The grub configuration needs to be updated like this:

set btrfs_relative_path="yes"
tpm2_key_protector_init -T ${prefix}/sealed.tpm
if ! cryptomount -u 0c5cc6925ceb42dcb4aa439719b6fdcd --protector tpm2; then
  cryptomount -u 0c5cc6925ceb42dcb4aa439719b6fdcd
fi
search --fs-uuid --set=root e7c3ebb3-768a-4451-a077-5aeca32dc2ae
set prefix=(${root})/boot/grub2
source "${prefix}/grub.cfg"

Nevertheless, there are weaknesses in the PCR concept, any component updates in the boot path can change PCR values. To deal with this, we could have some possible options for a bootloader update. Starting with resealing the raw random key, but the raw file become unprotected! Or replacing the random key with a new one, but it is error prone!

Authorized Policy For Full Disk Encryption

The use of an Authorized Policy allows to reduce these weaknesses. Now, instead of the PCR values, during the first boot we seal the random binary key after creating a recovery password, the PCR values are then signed in the first boot and also during an upgrade.

Create an Authorized Policy:

pcr-oracle 
  --rsa-generate-key 
  --private-key my-priv.pem 
  --authorized-policy my-auth.policy 
  create-authorized-policy 0,2,4,7,9

Seal the key with the Authorized Policy:

pcr-oracle 
  --key-format tpm2.0 
  --authorized-policy my-auth.policy 
  --input random-key.bin 
  --output unsigned.tpm 
  seal-secret

And finally,  sign the new Authorized Policy:

pcr-oracle --input unsigned.tpm --output sealed.tpm 
  --key-format tpm2.0 
  --algorithm sha256 
  --private-key my-priv.pem 
  --from eventlog 
  --stop-event "grub-command=cryptomount" 
  --before 
  sign 0,2,4,7,9

This way, the random key is always sealed. The private key can be managed in a secure server. And in one sealed key, it is possible to support multiple signed policies.

Passing Key to Kernel

To pass the key to the Kernel, Grub2 creates a synthesized initrd containing the key file in /etc/cryptsetup-keys.d/ and then appends it to the original initrd (it may overwrite files). The creation of the synthesized initrd will be skipped for any action that may alter the GRUB2 config, e.g. editing menu entries, and the key held in memory will be erased for safety.

Missing Pieces in First Boot

We still experience some difficulties to unlock the first boot. Indeed, predicting the PCR values during installation isn’t easy, it needs to differentiate booting from DVD versus booting from HDD, therefore it is impractical to seal or sign the key before the first boot.

The tenet of the key under the door mat: one-shot password for first-boot cryptomount –p “<one shot password>”, is removed after enabling TPM sealing/authorizing in first boot.

Epilogue

Current Status

All GRUB2 patches that incorporate these features have been merged into openSUSE Tumbleweed and SL-Micro 6.0. Same for tools as fde-tools and pcr-oracle.

TODO

● Pushing GRUB2 patches into upstream
● Signing the policies in a central server
● LUKS2 + Argon2 support in GRUB2
● Explore other authentication methods e.g. FIDO2

(Visited 1 times, 1 visits today)