Introduction to the Secure Boot Chain

According to NIST SP800-147 and SP800-193, the system needs to maintain integrity and availability during the firmware boot process. In firmware, secure boot (aka verified boot) uses a set of policy objects to verify the next entity before execution. For example, to match C5, the system uses the TP (verification procedure) to verify the UDI (untrusted firmware component), transforms the UDI into a CDI (trusted firmware component), and executes it.
In contrast, a trusted boot (aka measured boot) process does not verify the next entity. It only records the digest of the next boot entity to a trusted location, such as a Platform Configuration Register (PCR) in the Trusted Platform Module (TPM). This allows a trusted boot chain to be verified later in the boot process. Many security models use secure boot and trusted boot capabilities in combination for maximum effectiveness.
Table 1-2: Clark-Wilson model in Firmware
Property
Description
Rule
Firmware Secure Boot
​
Integrity
An assurance that CDIs can only be modified in constrained ways to produce valid CDIs.
C1, C2, C5, E1, E4
Yes. Firmware needs to verify the next component
​
Access Control
The ability to control access to resources.
C3, E2, E3
No. There is no user concept in secure boot.
​
Auditing
The ability to ascertain the changes made to CDIs and ensure that the system is in a valid state.
C1, C4
Yes, if TCG trusted boot is enabled. TCG event log may record such information.
​
Accountability
The ability to uniquely associate users with their actions.
E3.
No. There is no user concept in secure boot.
## Introduction to the Secure Boot Chain {#introduction-to-the-secure-boot-chain}
According to NIST SP800-147 and SP800-193, the system needs to maintain integrity and availability during the firmware boot process. In firmware, secure boot (aka verified boot) uses a set of policy objects to verify the next entity before execution. For example, to match C5, the system uses the TP (verification procedure) to verify the UDI (untrusted firmware component), transforms the UDI into a CDI (trusted firmware component), and executes it.
In contrast, a trusted boot (aka measured boot) process does not verify the next entity. It only records the digest of the next boot entity to a trusted location, such as a Platform Configuration Register (PCR) in the Trusted Platform Module (TPM). This allows a trusted boot chain to be verified later in the boot process. Many security models use secure boot and trusted boot capabilities in combination for maximum effectiveness.
Table 1-2: Clark-Wilson model in Firmware
Property
Description
Rule
Firmware Secure Boot
​
Integrity
An assurance that CDIs can only be modified in constrained ways to produce valid CDIs.
C1, C2, C5, E1, E4
Yes. Firmware needs to verify the next component
​
Access Control
The ability to control access to resources.
C3, E2, E3
No. There is no user concept in secure boot.
​
Auditing
The ability to ascertain the changes made to CDIs and ensure that the system is in a valid state.
C1, C4
Yes, if TCG trusted boot is enabled. TCG event log may record such information.
​
Accountability
The ability to uniquely associate users with their actions.
E3.
No. There is no user concept in secure boot.
## Introduction to the Secure Boot Chain {#introduction-to-the-secure-boot-chain}
According to NIST SP800-147 and SP800-193, the system needs to maintain integrity and availability during the firmware boot process. In firmware, secure boot (aka verified boot) uses a set of policy objects to verify the next entity before execution. For example, to match C5, the system uses the TP (verification procedure) to verify the UDI (untrusted firmware component), transforms the UDI into a CDI (trusted firmware component), and executes it.
In contrast, a trusted boot (aka measured boot) process does not verify the next entity. It only records the digest of the next boot entity to a trusted location, such as a Platform Configuration Register (PCR) in the Trusted Platform Module (TPM). This allows a trusted boot chain to be verified later in the boot process. Many security models use secure boot and trusted boot capabilities in combination for maximum effectiveness.
Table 1-2: Clark-Wilson model in Firmware
Property
Description
Rule
Firmware Secure Boot
Integrity
An assurance that CDIs can only be modified in constrained ways to produce valid CDIs.
C1, C2, C5, E1, E4
Yes. Firmware needs to verify the next component
Access Control
The ability to control access to resources.
C3, E2, E3
No. There is no user concept in secure boot.
Auditing
The ability to ascertain the changes made to CDIs and ensure that the system is in a valid state.
C1, C4
Yes, if TCG trusted boot is enabled. TCG event log may record such information.
Accountability
The ability to uniquely associate users with their actions.
E3.
No. There is no user concept in secure boot.

Integrity Models

Patterns in the Secure Boot Chain

Last modified 2yr ago

Property	Description	Rule	Firmware Secure Boot
Integrity	An assurance that CDIs can only be modified in constrained ways to produce valid CDIs.	C1, C2, C5, E1, E4	Yes. Firmware needs to verify the next component
Access Control	The ability to control access to resources.	C3, E2, E3	No. There is no user concept in secure boot.
Auditing	The ability to ascertain the changes made to CDIs and ensure that the system is in a valid state.	C1, C4	Yes, if TCG trusted boot is enabled. TCG event log may record such information.
Accountability	The ability to uniquely associate users with their actions.	E3.	No. There is no user concept in secure boot.	## Introduction to the Secure Boot Chain {#introduction-to-the-secure-boot-chain}