The Trusted Computing Group has recently defined the TCG Reference Integrity Manifest Information Model (RIMIM). The intent of this specification is to define a structure that can capture integrity measurements (in the form of cryptographic message digests) for firmware and boot software taken by organizations that participate in the production process (OEMs, System Integrators, Value added resellers, etc.). These structures (aka. "RIM") provide cryptographically verifiable firmware integrity measurements that an end verifier can use to provide an automated means to verify the firmware and boot software for the platform.

Setup

HIRS will allow a RIM to be used as a policy option to provide an added capability to augment the Platform Certificate for Supply Chain acceptance testing. The flow of the operation is similar to the Platform Certificate:

• The Trust Chain (e.g. certificate path) used for validating the Base RIM mus be uploaded prior to uploading the a specific RIM file(s).
• The Base RIM and any support RIM (aka.the "RIM Bundle") for a specific RIM must be uploaded before a client (provision) request can be processed.
• The "Firmware RIM Validation:" policy option must be enabled in order for the firmware checking to take place during a provision/validation request.

What gets checked when the Firmware RIM Validation policy option is enabled:

• Critical Firmware, including the "Software Root of Trust for Measurement" by the TCG.
• Option ROMs (Firmware loaded in from add-in devices such as NIC Cards).
• UEFI Configuration: Boot Order, Current boot selection, Secure Boot enable.
• Boot Disk partition tables.
• Secure Boot Variables (e.g. OEM and OS certificates and databases).
• UEFI applications such as the Boot Manager and OS Loader.
• Optional OS parameters (e.g. OS Kernel, device drivers, etc.).

How does HIRS provide RIM verification during the provisioning process?

The HIRS provisioner (a client side application) collects the TCG Event log, list of TPM PCR's, the Endorsement, Attestation (or Attestation Public Key), and Platform Certificate, and a TPM Quote (using a nonce obtained from the ACA) during the provisioning process. Note that the ACA will use previously uploaded Attestation, Endorsement and Platform Certificates if they are not provided by the provisioner. This information is sent to the ACA as evidence used for the "identity claim" used in the provisioning/validation process. The ACA, if the Firmware RIM Validation policy is set, will process this information by:

• Validating the TPM Quote by decrypting the nonce and checking it against the nonce issued to the HIRS provisioner.
• Verifying that Quote Digest matches the PCRs sent.
• Verifying the PCRs sent against the Event Log collected from the client (PCR Replay).
• Verifying the PCRs sent against the Expected PCRs generated from the RIM.
  • If any PCR fails to match against the expected PCRs generated from the RIM then for each failed PCR:
    • The Event digests for Each Event associated with the PCR number (e.g. the Event index) from the Event log collected at the client is compared with the RIM to determine which event was in error.
      • Details taken from the Clients Event Log are extracted and displayed in human readable form to note what caused the error. Some example error statements are:
        • Boot Order changed
        • Unexpected Secure Boot state change
        • Firmware (SRTM) modification detected
        • Firmware Module modification detected
        • Unknown or altered Option ROM detected
        • Boot Manager modification detected
        • OS Loader modification detected
        • Unknown or altered EFI application detected
        • Unexpected Kernel Modification
        • OS specific critical file or configuration modification detected
    • A failed PCR comparison will result in a failed validation report with the error noted above.
  • If the PCR comparison passes then a successful validation report is generated.

The details associated with the OS specific critical file of configuration modification will depend upon the documentation provided with the specific OS. Currently both Linux and Windows provide support for TCG Event Logs, however, different versions or distributions provide evolving event log support so the amount of details will depend upon the version of the OS installed on the client as well.