Skip to content

HIRS Performs Validation

Provisioning Pass 1a – Client – Identity Claim

ACA configuration

First, the user selects the desired configuration on the ACA. For example, the user selects Endorsement, Platform, and Firmware validation, and optionally requests issuance of an Attestation Certificate and LDevID certificate.

HIRS Policy Page

Run Provisioner

User runs the Provisioner script on the Client device. For details on setup, refer to the Provisioner Installation section.

Provisioner collects data

The Provisioner collects data from the Client according to the TCG Component Class Registries such as: SMBIOS , PCIE , Storage .

Device info

The Provisioner retrieves info from the Client device, including but not limited to:

  • Serial numbers
  • TPM information
  • Firmware information
  • OS information
  • Network information

Attestation public key

The Provisioner requests creation of a Local Attestation Key (LAK) from the TPM. The Attestation Key is generated on the TPM (if one is not already present). The TPM returns the public key of the LAK to the Provisioner; the TPM stores the private key of the LAK (or alternatively, double encrypts it and puts it in regular memory).

Note

This LAK will be the key that is used in the final Attestation Certificate.

Endorsement Key Credential

The Provisioner attempts to read this from the TPM’s NVRAM.

Platform Certificate

The Provisioner attempts to read this from the EFI partition on the PC. If it’s not here, the ACA must retrieve it from another source – such as downloading it from an OEM server onto the ACA server. In future implementations, the ACA may retrieve it from an OEM-provided URL.

RIM Bundle

Base RIM (from OEM) The goal is to have this located in the EFI partition, where the Provisioner can automatically retrieve a copy of it. However, some companies will put it in a server with URL access which can be automated. If neither of these automated methods are options, the user can manually upload it via the ACA.

Support RIM – Event Log The Provisioner grabs the Event Log from a location on the PC that the OS has copied it to.

Provisioner sends Attestation Certificate request

The Provisioner packages this data and sends it to the ACA along with a request for an Attestation Certificate.

Provisioning Pass 1b – Server – ACA Responds with Nonce

The ACA does a preliminary check on the provided info and if that check passes, the ACA requests a Quote from the Provisioner, sending the Provisioner a challenge (nonce).

Provisioning Pass 2a – Client – Client Sends Quote with Nonce

The Provisioner requests a Quote from the TPM using the nonce and PCR mask. The TPM generates this Quote and signs it with LAK private key. The Quote contains a single signed composite hash of the selected PCR values defined by the PCR mask register (in other words, a hash of hashes, or a signed PCR digest report).

Info

The Quote gives 2 proofs:

  1. The signed Quote proves authenticity and integrity. Since only the TPM has access to the LAK private key, the signature confirms the Quote originated from the TPM and that the data has not been altered.
  2. The nonce ensures that the Quote is current. Because the nonce generated by the ACA is included in the signed Quote, it proves the Quote was produced after the nonce was issued, preventing replay attacks.

Provisioning Pass 2b – Server – ACA Responds with Attestation Certificate

ACA Performs Verification

Verify Certs via Cert Chains

The ACA checks the EK Credential, Platform Certificate, and RIM via their respective certificate chains. (Recall these certificates represent the expected values.) The chains must be grabbed from a secure location such as directly from the manufacturer. This check verifies that these certificates are valid and haven’t been tampered with.

Verify TPM

The ACA decrypts the Quote with the EK Credential public key. This proves that the TPM is legit because only the legit TPM would have the correct private key that matches this EK Credential public key.

Verify Platform

The ACA compares the platform info provided by the Provisioner (can be considered the “measured” values) to the expected values in the Platform Certificate.

Verify Firmware

  1. Process RIM (from OEM)
    • ACA adds events from new RIM (specific to this device’s manufacture and model number) to the RIM database, if they are not already present.

  2. Verify TPM Quote signature and nonce

    • ACA verifies the signature of the Quote with the LAK public key
    • ACA verifies nonce

    Info

    1. Signature verifies authenticity and integrity of data. The signature tells the ACA that this is a legit Quote signed by the actual TPM.
    2. Nonce verifies freshness of the data. The nonce tells the ACA that this is a fresh Quote (i.e. not from the previous boot before a bad guy altered something, where the old good data is just replayed).

  3. Real-time values check: Verify Event Log against TPM Quote

    • ACA takes the Event Log sent by the Provisioner and creates a PCR Replay by hashing all event digests.
    • ACA compares the PCR Replay Hash with the Quote’s hash to confirm they are the same.
      • Quote hash: Generated by TPM from its PCR registers.
      • Replay hash: Reconstructed by ACA from the Event Log.

    Info

    This verification confirms that the Event Log accurately reflects the measurements stored in the TPM PCR registers. If the Event Log had been modified after boot, the PCR Replay Hash would not match the TPM Quote. (Though the PCR registers cannot be modified inside the TPM, it is still possible for Event Log to be tampered with.)

  4. Reference values check (RIM check): Verify Boot Process / Firmware

    • ACA retrieves RIM Events from the RIM database corresponding to the device’s manufacturer and model. These represent the expected measurements provided by the OEM.
    • The ACA compares each event in the Event Log (measured values) against RIM Events pulled from database (expected values).
      • For each Event Log entry, the digest must exist in the RIM Events set. If no match found, validation fails.
      • Note: There could be more RIM Events in the database that correspond to that manufacture/model that are not used in the Event Log for a given device (likely hundreds). This occurs because firmware updates and patches introduce additional valid measurements over time. Since RIMs do not include an explicit list of obsolete measurements, the set of valid events can grow as new RIMs are added.

    Info

    This verification tells the ACA that the boot process occurred exactly as the manufacturer stated it would.

ACA Sends Response

If verification passes, ACA creates certificates according to validation policy set by the user:

  • Attestation Certificate
  • LDevID Certificate

ACA sends the response to the client, which includes the Attestation Certificate and/or LDevID.

Process is complete!