Overview

System firmware, commonly referred to as Basic Input Output System (BIOS), plays an important role in platform security. Running unauthorized firmware components may introduce significant threats by creating a permanent denial of service or introducing persistent malware. In 2011, the National Institute of Standards and Technology (NIST) published BIOS Protection Guidelines (SP800-147). NIST extended the scope to all platform firmware and published Platform Firmware Resiliency Guidelines (SP800-193) in 2018. The goal of those documents is to provide a general guideline for firmware integrity.

Integrity Models

The UEFI Secure Boot chain can be applied to the Clark-Wilson integrity policy, developed in 1987. The Clark Wilson model includes the following concepts:

1. Data Item:

   1. Constrained Data Item (CDI)

   2. Unconstrained Data Item (UDI)

2. Procedure:

   1. Integrity Verification Procedure (IVP)

   2. Transformation Procedures (TPs)

3. Rule:

   1. Certification Rule (CR) – integrity monitoring

      1. C1: (Basic: IVP Certification) All IVPs must properly ensure that all CDIs are in a valid state.

      2. C2: (Basic: Validity) All TPs must be certified to be valid. For each TP and each set of CDI that it may manipulate, the security officer must specify a “relation” of the form: (TP, {CDI}).

      3. C3: (Separation of Duty Certification) The list of relation in E2 must be certified to meet the separation of duty requirement.

      4. C4: (Journal Certification) All TPs must be certified to write to an append-only CDI (the log) all information necessary to permit the nature of the operation to be reconstructed.

      5. C5: (Transformation Certification) Any TP that takes a UDI as an input value must be certified to perform only valid transformations, or no transformations, for any possible value of the UDI. The transformation should take the input from a UDI to a CDI, or the UDI is rejected.

   2. Enforcement Rule (ER) – integrity preserving

      1. E1: (Basic: Enforcement of Validity) The system must maintain the list of relation specified in C2, and must ensure that only TPs certified to run on a CDI manipulate that CDI.

      2. E2: (Enforcement of Separation of Duty) The system must associate a user with each TP and set of CDIs in a list of relations of the form: (User, TP, {CDI}). It must ensure that only executions described in one of the relations are performed.

      3. E3: (User Identity) The system must authenticate the identity of each user attempting to execute a TP.

      4. E4: (Initiation) Only the agent permitted to certify entities may change the list of such entities associated with other entities, specifically the one associated with a TP. An agent that can certify an entity may not have any execute rights concerning that entity.

This model is based on the relationship between authenticated principal, program, and data items. The elements of this relationship are referred to as the “Clark-Wilson Triple” (User, TP, {CDI}). The Clark-Wilson model shows the rules required to meet the security properties of integrity: (from Blake).

Table 1-1: Clark-Wilson model

Figure 1-1: Clark-Wilson model, From Lee

Because the Clark-Wilson focuses on duty and transaction, it is more applicable to business and industry processes. Currently, some papers describe how to apply the Clark-Wilson integrity model to the existing system, such as Windows, Java or Trusted Computing Group (TCG) security.

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

Patterns in the Secure Boot Chain

Definition:

1. Firmware[N] - the N level firmware binary. Any firmware layer is updatable.

   Firmware[0] means the component verified by Hardware.

   Firmware[N] means the component verified by Firmware[N-1].

   It may include both code (Firmware[N].Code) and data (Firmware[N].Data).

2. Firmware[N].Code - the code of the N level firmware binary.

   It may include the verifier (Firmware[N].Code.Verifier.)

3. Firmware[N].Data - the data of the N level firmware binary.

   It may include the verification policy. (Firmware[N].Data.Policy.)

4. Firmware[N].Code.Verifier - the verification function of the N level firmware binary.

5. Firmware[N].Data.Policy - the policy data inside of the N level firmware binary. This data is used by the verification function. Both verification function and policy data have below subcategory:

   1. Boot - the firmware boot

   2. FirmwareUpdate - the firmware update (it may or might not include policy data)

   3. PolicyUpdate - the policy update. It may or might not exist.

   4. Recovery - the firmware recovery

   5. Communication - the firmware runtime communication

6. Hardware – the hardware, including Register Transfer Level (RTL) and register. The hardware is not updatable. The hardware must be fused when it is shipped to the end user.

There are two types of verification:

1. The verifier for boot (verified boot). The read-only code and read-only data are in this category. This category includes both initial installation and upgrade. For example, UEFI Secure Boot is for code installation, or signed capsule update is for code/data upgrade. In most cases, the verification is based upon a crypto-algorithm, such as Secure Hash Algorithm (SHA) or Rivest-Shamir-Adleman Algorithm (RSA). The policy data can be the hash value of the firmware or the public key hash of the firmware. Above 5.a, 5.b, 5.c, 5.d belongs to this type.

2. The verifier for communication (verified communication). The read/write data are in this category. This category is for cross-boundary data passing such as SMM communication, including the UEFI non-volatile variable. In most cases, the verification is based upon the boundary check, valid range check, etc. Above 5.e belongs to this type.

Patterns for Verified Boot

Table 1-3: Patterns for Verified Boot

NOTE: If N == 0, Firmware[-1] means the hardware.

Patterns for Verified Policy Update

Table 1-4: Patterns for Verified Policy Update

• Patterns for Verified Firmware Update

Table 1-5: Patterns for Verified Firmware Update

• Patterns for Verified Recovery

Table 1-6: Patterns for Verified Recovery

• Patterns for Verified Runtime Communication

Table 1-7: Patterns for Verified Runtime Communication

Comparing Clark-Wilson and UEFI Secure Boot

The following table illustrates how the UEFI Secure Boot Chain maps to Clark-Wilson certification and enforcement rules.

Table 1-8: Comparison between Clark-Wilson and Secure Boot Chain