​Secure Boot Best Practices

Secure Boot ensures the authenticity of the software running on a directly connected device or an edge device by establishing a "chain of trust" where every running module verifies the subsequent module that is expected to use the device's resources. The next section provides more information on this feature. The secure boot implementation depends on the hardware platform as the trust is closely coupled with the host platform.

Secure Boot Implementation and Theory

The following figure shows the normal boot process without a secure boot.

Following the device startup process above, it is safest practice to believe that the boot loader, kernel, and/or user application modules could be from a not trusted source or that they could be altered by an attacker who would want to take control of the system for malicious reasons.

To establish a chain of trust, the various modules that take control of the device's resources are signed by a trusted source that uses asymmetric cryptography. The trusted source holds a public/private key pair and the private key is used to sign various modules that run on the device. The public key is available to the device to perform module authenticity and integrity measurements.

The process to share the public key with the device for signature verification is performed in a secure manner with this key protected against tampering or deletion​.

With a secure boot process, the boot loader is verified by the CRTM (Core Root of Trust for Measurement) module, which is the immutable trust anchor. This issues a verification code that is used to verify the boot loader. The boot loader then further initiates the verification of the kernel and this process continues until all the modules are verified and loaded successfully.

Secure Boot Mechanism

The Secure Boot Method uses the signature of the software provider to establish trust. The various modules of the software are signed by software providers.

The trusted boot sequence is show below​.

In this method, every module verifies the signature of the subsequent module to be loaded. The next module is loaded only after a successful signature verification by the previous module. This method when traced back leads to Core Root of Trust for Measurement(CRTM) which is generally the ROM code that is shipped by the CPU manufacturer and that is written once only and is immutable. This forms the root of trust that establishes the chain of trust in the device boot sequence​.

Using TPM for Secure Boot

If you are planning to use a TPM enabled device for your Ability solution there are specific best practices to ensure you are able to use TPM when setting up a secure boot. The following suggestions will work for some use cases and not for others, but overall these are the suggested best practices to follow when designing your Ability solution.

• Secure Boot should be implemented leveraging the Platform Hierarchy and CRTM of TPM for measurements.

• Implementation of secure boot should respect that the platform hierarchy and platform NV not accessible by OS and user space applications.

• It is recommended not to use the OWNER hierarchy during the secure boot process. This allows the platform owner to define policies for TPM ownership independent of the platform firmware, which effects the Secure Boot in accessing the owner hierarchy.

• Once you have successfully performed a secure boot the TPM shall be left in a state to be used by the Trusted Computing Group(TCG) Software Stack, to take ownership and provisioning of Owner and Endorsement Hierarchy.

• All the authorization sessions used in the secure boot process created with TPM shall be terminated.

TPM policies to be used at secure boot

• AuthPolicy is recommended to be used for accessing the Platform Hierarchy, but it is recommended to set a policy which cannot be satisfied by user space applications.

• AuthPolicy may be set for TPM Non Volatile Random Access Memory(NVRAM) access during secure boot, it is recommended to create and access NVRAM using platform hierarchy and not owner hierarchy, this is to prevent the need for TPM ownership for secure boot.