Clearing the TPM on a Dell Device: Why the EKpub and Offline Device ID Change

Introduction

In our last Patch Tuesday blog, we discussed TPM attestation failures that are happening on Windows 11 24H2, specifically during the Endorsement Key (EK) Verify phase. This caused Windows Autopilot for Pre-Deployments enrollments to fail. To dig deeper, I decided to investigate what should happen during a Clear TPM (Trusted Platform Module) operation.

Using `Get-WindowsAutopilotinfo` to capture the hardware hash and OA3Tool to decode it. While doing so, I noticed something unusual: clearing the TPM (Trusted Platform Module) on one Dell device resulted in a new EKpub and a different Offline Device ID, which should NOT happen at all!!!

This behavior didn’t occur on other devices I tested, like those from HP and Lenovo. To understand why this is problematic, we first need to review how a Clear TPM operation is supposed to work.

What Should Happen During a Clear TPM Operation

Before looking at the issue, we need to have a good understanding of what the Clear-TPM PowerShell command should do. A Clear TPM operation is meant to reset the TPM to its default state without impacting its core identity. Here’s the standard flow:

1. Check TPM Ownership:
   Determines if the TPM is owned. Ownership means the system has control over the TPM’s functions. If ownership hasn’t been established, provisioning continues to set it.

2. Provision SRK (Storage Root Key):
   The SRK is the master key used to secure all other keys and data within the TPM chip. This step resets and provisions the SRK.

3. Provision EK (Endorsement Key):
   The EK is a unique, manufacturer-provided key used to validate the TPM’s authenticity. It doesn’t change unless explicitly reset by commands like TPM2_ChangeEPS.

4. Set Lockout Policy:
   Configures protections against brute-force attacks, like locking the TPM after too many failed attempts.

5. Provision Auths and Counters:
   Sets passwords or authorizations for TPM functionality and initializes secure counters to track usage or tampering.

6. Check TCG Log:
   Validates the Trusted Computing Group (TCG) log, which tracks system startup events, ensuring no tampering has occurred.

7. Publish Final Status:
   Updates the system to indicate that provisioning is complete and the TPM is ready for use.

Clearing the TPM on Dell Devices

Using the tools below, I found that the Dell device deviated from this standard flow.

Steps I Took:

1. Exporting the Hardware Hash: Before clearing the TPM, I ran the following to capture the hardware hash: `Get-WindowsAutopilotInfo -OutputFile “pre-clear-hash.csv”`
2. Decoding the Hardware Hash: I used the OA3Tool to decode the EKpub and compare the hardware hash:`oa3tool /decodehwhash=”the hash from the pre-clear-hash.csv”
3. Clearing the TPM: I cleared the TPM through the BIOS/UEFI.
4. Repeating the Process Post-Clear: After clearing the TPM, I exported and decoded the new hardware hash:    `Get-WindowsAutopilotInfo -OutputFile “post-clear-hash.csv”`
   `oa3tool /decodehwhash=” the hash from the post-clear-hash.csv”

Findings: (fasten your seatbelt)

– The EKpub Changed!!!!!: Comparing the decoded EKpub values showed that they were different before and after the Clear TPM operation.
– The Offline Device ID Changed!!!!: The Offline Device ID, derived from TPM measurements like the EKpub, also changed.

One thing is for sure: this should never ever happen when clearing the TPM.

Why the EKpub Should Never Change when clearing the TPM

According to TPM specifications:

1. The EKpub Is Deterministic: The EKpub is always derived from the EPS and a predefined template. As long as the EPS remains unchanged, the EKpub stays the same.
2. Clear TPM Does Not Reset the EPS: A Clear TPM operation resets user-created data (like the SRK) but retains the EPS. Resetting the EPS would be a significant event, usually requiring a specific command like `TPM2_ChangeEPS`.
3. The Offline Device ID Relies on EKpub Stability: Since the Offline Device ID is tied to the EKpub, any change in the EKpub results in a different device ID. This can disrupt Attestation during Windows Autopilot Pre-Provisioning and lead to Autopilot time-out issues as well.

Source: TCG Credential Profile EK 2.0

Why This Matters

1. Attestation Failures: The EKpub is tied to the EK certificate (EKcert). If the EKpub changes, the EKcert becomes invalid, breaking the attestation process. This likely explains the 0x80070490 error I discussed in my previous blog.
2. Device Identity Problems: The Offline Device ID, which is derived from the EKpub, also changes. I guess with a new device ID and a new EKPub, the device looks totally different!
3. Inconsistent Behavior Across Devices: Clearing the TPM on devices from HP and Lenovo doesn’t affect the EKpub or Offline Device ID. Only a subset of Dell devices that are using the STM chipset have this issue! So it could be very difficult to find the culprit!
   

Final Thoughts

Clearing the TPM should reset user-created data and keys, but it should NEVER (and I do mean NEVER!) change the EKpub or Offline Device ID.

On this Dell device, something in the Clear TPM process altered the EKpub, causing downstream issues with attestation and device provisioning. While the exact cause isn’t clear, whether it’s firmware-related or a TPM-specific implementation. This behavior breaks expected standards.
If you’re managing Dell devices, it’s worth testing how they handle Clear TPM operations and factoring these anomalies into your workflows.