Skip to content

Firmware Validation

Jump to bottom
iadgovuser26 edited this page Mar 17, 2020 · 2 revisions

Overview

When a UEFI based device boots, the Trusted Platform Module (if present and activated) should contain a set of cryptographic hashes held in registers referred to as A Platform Configuration Register's (PCR's) that that can be used (by a third part appraiser) to verify the following claims:

  1. The code which device booted (Firmware, Boot Manager, OS Loader, up to the Kernel) came from a known good source and has not been altered.

  2. The configuration of the UEFI within the device has been set or altered by trusted entities.

  3. The data used to lock down the UEFI (e.g. Secure Boot keys) has been set by a trusted entity and has not been altered.

TCG Defined Artefacts that can be used for Firmware Validation

To that end, there are three (seven?) types of information that an Attestation Certificate authority need to perform validation of the Firmware prior to issuing an Attestation Certificate:

  1. A Reference in Integrity Manifest (RIM) that provides the values (cryptographic hashes) expected to be held by the TPMs Platform Configuration Registers (PCRs) when the Device powers up. It also holds a list of the measurements (hashes) that were used to create those TPM values. This list is comprised of the critical firmware, software, configuration, and data (keys) that are described by the UEFI specification. The Original (Primary) RIM is signed by the OEM that installed the UEFI. Systems Integrators, Value Added Resellers and Maintenance departments can create Supplemental RIMS as well.

  2. A Log file produced by UEFI, during the devices boot cycle, which contains a history of the measurements (hashes) that were extended into the TPM PCRs. This log file (the TPM "Event Log"), can be used by a verifier to compare against the RIM to provide details of what components were changed or altered.

  3. A TPM Quote and PCR List The TPM can be commanded to produce a Quote which creates a signed digest of the TPM PCR contents and a nonce. This quote can be used to detect any alteration of the TPM PCR's from a source that is not part of the devices Software Root of Trust for Measurement. The Quote, along with a list of the TPM PCR Contents is needed by the ACA to determine if any of the Firmware, UEFI configuration, UEFI applications or OS boot software has been altered by a none approved source.

  4. The Platform Certificate issued by the OEM, System Integrator, Valued added reseller. These certificate(s) can be placed in the TPM's non-volatile memory , but are not placed there by OEMs. The HIRS ACA provides a Web based upload capability to import the Platform Certificates into the ACA. The Platform Certificate is cryptographically bound to the Endorsement Certificate by the Holder field within the Platform Certificate.

  5. The Endorsement Certificate to which the Platform Certificate is linked. This certificate can be found on the TPM's Volatile memory and is usually found by the HIRS provisioner and sent to the ACA. The HIRS ACA provides a Web based upload capability to import the Endorsement Certificates into the ACA.

  6. A Certificate chain of the organization that produced the Platform Certificate. The HIRS ACA provides a Web based upload capability to import the Platform Certificates into the ACA.

  7. Certificate chain of the organization that produced the RIM. The HIRS ACA provides a Web based upload capability to import the RIM into the ACA.

Definitions:

Trust Chains (certificate paths) from the RIM, Endorsement Certificate, or Platform certificate creators. These are CA and Subordinate CA certificates used to validate the Trust Store Signatures. For HIRS the existing Trust Store import capability should be fine with no additions required.

PCRIM Bundles: These will consist of the PCRIM Files: Base RIM (Signed SWID Tag with TCG Defined Meta Attributes) and one or more support RIM.

What the ACA needs to validate upon Import:

  1. The Signature on the PCRIM validates against the Cert Chain that resides in the ACA Trust Store. The Signature element of the PCRIM should contain a KeyInfo field which can be used to determine the cert needed to validate the Base RIM.

  2. The Payload hash within the Base RIM should contain two hash and File references for each of the Two support RIM. The hash needs to match those files.

  3. The Measurements within the TPM event log can be extracted and used to create expected PCR values. This can be checked against the TPM PCR List sent within the RIM Bundle.

The ACA will store each RIM in its database.

UI features of supporting PCRIM:

  1. A RIM List Page (similar to the Platform Cert Page). A row in the left hand column of the ACA main UI would be used to select this page (Should display "Reference Integrity Manifests" if its fits). The page itself should have one row per RIM. A RIM icon should be available on the left hand column which links to RIM detail. The other columns would have Basic RIM info (Manufacturer, Model, etc.). The other icon on the right hand side should e similar to the PC cert page (delete, download, etc.).

  2. A RIM detail page selectable by the RIM List Page. The RIM detail page would have ROWS which list the details found within the RIM Files (e.g. SoftwareIdentity, Entity, Payload, etc) as well as firmware and boot software components (e.g. SRTM, Boot Manager OS loader, initrd, Linux Kernel, etc)

  3. When a TPM verification fails, the PCRIM detail page will need to highlight the component that failed (e.g. OS loader gets highlighted if it failed). This should be similar to how the PCCert page is used to highlight a hard component failure.

PCR collection

To verify the Firmware, a TPM Quote (from the client) will be used to collect the resultant PCR values after the last boot cycle. The tpm event log will also be collected to provide details of what went into each PCR.

TPM Provisioner needs to collect the event log binary and append it to the IdentityClaim portion of the provisioning process. The ACA will generate a nonce and place that in the IdentityClaimResponse. After the AC sends the IdentityClaimResponse out it can do processing on the ACA log if needed.

The HIRS Provisioner will also need to collect a Quote (after the Provisioner get the IdentityClaimResponse since that has a nonce needed by the TPM Quote function), and appends Quote to the CertificateRequest.

ACA Processing of the PCRIM prior to sending the CertificateResponse.

  1. The ACA will verify the nonce, check the quote against values within the DB.
  2. The Log file will be processed to create PCR values that should be found in the Quote. The processing continues if these values match.
  3. The PCR values are checked against the PCR values stored in the DB.
  4. If a failure occurs then the values from the RIM are retrieved and each individual component within the RIM is compared against values within the Log.
Clone this wiki locally