Trusted Boot

Trusted Boot is a technology to provide a chain of trust for all the components during boot. In this guide, we introduce this technology and how it can be enabled in Gentoo Linux.

Introduction
This guide will introduce Dynamic root-of-trust using Intel's TXT to support measuring the booted kernel and initramfs before it is loaded. The measured values are extended into the TPM chip so that values can be sealed and unsealed within it.

Dynamic vs Static Root of Trust
Trusted boot relies on having a Root of Trust that all the rest relies on. Originally there was a Static Root of Trust in which each component measured the next component in the chain. This method is fickle because if anything at all changes in the bios setup or boot chain then the PCR values will end up different and difficult to predict.

Dynamic Root of Trust instead uses Intel's Trusted Execution Technology to reset to a known state during boot.

TPM Platform Configuration Registers
The TPM Chip is an integral part of Trusted Boot. The important part are the Platform Configuration Registers (PCRs), special registers that can not be set, only extended with another measurement. A TPM usually has 23 PCRs, which are reset to zero during boot and after that point, are extended. An extend operation works like:

TPM chips support bind and seal operations. Binding means that the data is encrypted using a key only found within the TPM and cannot be extracted. Sealing is like binding but data will only be unencrypted if the PCRs are the same values as when the data was sealed. Sealing will be very useful for our purposes.

The Big Fat Warnings
Using Trusted Boot on your system is currently only recommended for development purposes. Gentoo Hardened is working on integrating Trusted Boot properly, so please be aware that a value sealed with TPM PCRs can only be unsealed if the PCR values are exactly the same as when sealing. Make sure you have a backups of all the data and other ways to unlock your machine if the TPM will not unseal the data.

Kernel configuration
First of all, enable Intel TXT in the Linux kernel configuration. Intel TXT is supported in the main tree since 2.6.38.

BIOS configuration
Reboot and enter your BIOS setup, look for an enable any options about VT-x, VT-d, Intel TXT. The TPM must also be set to Active, Enabled in some bios setups means that the chip is visible to the OS but cannot be used.

If using UEFI boot instead of Legacy, CSM or Compatibility Support Module needs to be enabled. The tboot program is not an EFI binary and appears not to work without CSM enabled.

After this reboot like normal and check dmesg to make sure the IOMMU is enabled:

Install the software
This will install tboot and its dependencies TrouSerS and tpm-tools. TrouSerS will install some udev rules for the tpm /dev node, you must either make udev re-read its rules or just reboot now.

Taking Ownership of the TPM
Next, we have to setup the TPM:

This will take ownership of the TPM chip using the well known password for both the Owner and SRK passwords. We will change the owner password later on, this is just for testing the initial parts.

Intel TXT SINIT module
Intel TXT requires an SINIT module that is signed by Intel and trusted by the CPU. The module for your specific CPU must be downloaded from: https://software.intel.com/en-us/articles/intel-trusted-execution-technology

Download, extract and copy the SINIT module into /boot/.

Grub config
At this point, rebooting and choosing the tboot option should start like normal using the default launch control policy.

Checking the PCR values
PCRs 0-7 are used by the static root of trust measurements and PCR 17-19 are used by Intel TXT. If Intel TXT is not launched, PCR 17-23 would be filled with FF instead of reset to 0 and extended with measurements.

The senter_done: TRUE and ERRORCODE: 0x00000000 are the important parts that shows Intel TXT was launched correctly and we are in a secure envrionment.

Setting the Launch Control Policy
The Launch Control Policy is used by the SINIT so control launching into the TXT environment. It controls which Measured Launch Environment (MLE, tboot in this case), PCRs are allowed. It also can contain the Verified Launch Policy which tboot will use later to verify the kernel and initrd.

The LCP can contain one or more policy lists which contain one or more policy elements. The policy lists can be signed or unsigned. We will use signed lists because the value extended into PCR18 will be the hash of the public key instead of the hash of the whole policy. This means policy upgrades will leave PCR18 unchanged so any sealed values are still accessible.

Next create the Verified Launch Policy that tboot will use to verify the kernel and initrd. --ctrl 0x00 disables the EXTEND_PCR_17 flag, which means that tboot will not extend the hash of the first module into PCR18. With that flag set, tboot will always extend the hash of the first module into PCR18. If another PCR is specified as well, that pcr will be extended in addition to pcr18. Instead we extend the kernel and initrd into pcr19/20 and leave pcr18 untouched. This means kernel upgrades will not break anything sealed to PCR18.

Put all the elements into a policy list, sign the list then make the policy and data. Policies with type list (as opposed to ANY) need to have a separate list.data because the TPM can not store all the data.

Make sure the required indexes are defined in the TPM:

The list.pol has to be written to the TPM index for the LCP. If using a signed list policy, the list.pol will be unchanged between versions so later upgrades will only require copying list.data to /boot

Sealing data in the TPM
TODO

Changing the well-known-password
As the tcsd is the only portal to access the TPM, you have always to start the Trusted Core Service Daemon before altering any information.

This will change the passwords for both the Owner and SRK (Storage Root Key).