Call4Cloud | MMP-C | Autopilot | Device Preparation

Triangle of TPM Attestation Sadness

Patch My Pc | install & update thousands of apps

This small blog will be about the errors 0x81039001 and 0x80190190 you could get when enrolling your device with Autopilot (Self Deploying or Pre-Provisioning), and you have a nice Infineon TPM in your device!

1. TPM Attestation Issues

Today, 29-03-2023, was a day full of TPM attestation issues, especially when using Autopilot Pre-provisioning or self-deploying.

At the “securing your hardware” phase, you could encounter the error 0x81039001 or 0x80190190

0x81039001 tpm attestation error
0x80190190 attestation error

This error is nothing more than an error code for E_AUTOPILOT_CLIENT_TPM_MAX_ATTESTATION_RETRY_EXCEEDED.

When taking a closer look, we will notice that the device would retry the TPM attestation multiple times until it times out with the message: No valid TPM EK/Platform Certificate provided in the TPM identity request message

certreq -enrollaik -config gives you the error message: No valid TPM EK/Platform Certificate provided in the TPM identity request message

The same message could be noticed when you ran a Fiddler trace during the enrolllment (or using the certreq -enrollaik -config “” command)

Besides the No valid TPM EK/Platform Certificate provided in the TPM identity request message it also give the 0x80190190 error status bad request (HTTP_E_STATUS_BAD_REQUEST)

As shown above, the certreq tool would also throw the famous 0x80190190 (HTTP_E_STATUS_BAD_REQUEST) command at your feet

No valid TPM EK/Platform Certificate provided in the TPM identity request message
Afbeelding met tekst  Automatisch gegenereerde beschrijving

Reject the request: The ACA in this case simply rejects any AIK certificate request not accompanied by valid EK/Platform certificates. This is the expected behavior in the general case

Without a valid request, the TPM attestation would fail, and with it your Autopilot enrollment. Before taking a closer look, let’s start with a brief introduction to Attestation

2. A brief introduction to Attestation

I guess I have written enough blogs about this topic already but screw it! Let’s start

At the securing your hardware step, the device should start securing the hardware (duhhh) by performing the TPM attestation. During the TPM attestation, the device should try to fetch the AIK Cert.

Before your device can fetch the AIK Cert your device needs to be “Ready for Attestation”. If the device somehow fails the ready-for-attestation check, please read my blog first.

Ready For Attestation False and the 0x81039001 TPM time-out (call4cloud.nl)

the tpm attestation scep flow

(1) If everything is good to go, the TPM starts collecting the proof of identity/Identity_proof (EkCert and the AIK). This proof of identity is encrypted with a random number (k1) of the TPM (that explains the garbage I noticed in the request..) and also encrypted with the public key of the Attestation Certificate Authority (ACA). So Double Encrypted it is!! This request will be sent to the ACA

If the ACA, trusts the request, it needs to decrypt the garbage proof of identity by using its own Pub Key and the random number (K1) from the TPM

After the decrypting was successful, the ACA would reconstruct the package and would check if the EkCert is trustworthy by walking the certificate chain.

If the Package has been reconstructed the ACA will generate a random R. (Unique to the TPM). The ACA would generate the EK BLOB (Random R + AIK Pub Hash) and would encrypt it with the TPM its EkCert Pub which it received in the initial request and would send it back to the TPM

The TPM would verify if the EK Blob it received matches his own AIK and if it does it will return a random R to the ACA

The ACA would know with the random R send back, that it’s indeed the same TPM it got the AIK/EK from. After validating the information, the ACA would issue the AIK certificate. This Aik Certificate would be sent back to the device together with again the EK-BLOB and with a random number (K2)

The TPM would decrypt the AIK certificate with the K2 it got and would store it on the device

3. Taking a closer look

If we are performing TPM Attestation, the device will walk the Certificate Chain to the proper AIK URL. This one would be created by using the proper Intermediate Certificate

Infineon TPM certificate

So, in my case, the AIK URL should be

https://ntc-keyid-667d154665cac01f70cb40d8db33594c90b4d911.microsoftaik.azure.net

If we perform a Fiddler trace, we will indeed notice the same AIK URL.

PKIOperation GetCACaps and GetCACertChain

Isn’t that just wonderful? A good working AIK URL, that used the proper certificate! In the past, we have seen a lot of issues because of this (and still……even with the Intel one fixed, the AMD is still pretty much broken)

AMD and TPM Attestation Failing | 0x81039024 | Autopilot (call4cloud.nl)

TPM Provisioning | GetCaCaps | 0x800705b4 | AIK | EKCert (call4cloud.nl)

But somehow, the device doesn’t seem to be able to fetch the AIK cert; let’s check the basics! First off, I used the PowerShell script I wrote earlier to determine if we didn’t forget anything important

PowerShell script to troubleshoot TPM attestation issues (call4cloud.nl)

This script should test all the die-hard requirements there are to perform some attestation. Within a few seconds, the script ended with some red errors!

Mmm… I guess everything checks out? But you can never be too sure, so I also performed some manual checks. As shown below, the device has the EkCert

Afbeelding met tekst  Automatisch gegenereerde beschrijving

4. The Garbage

As mentioned before, the device would send out the encrypted AIK and EKcert to the ACA. If you are quick enough, you will spot this “request” also popping up in the SYSTEM user’s roaming data.

In the SYSTEM user his appdata, a temp file will be created in the systemcertificates\request\certificates folder

Afbeelding met tekst  Automatisch gegenereerde beschrijving

When opening this file, we would spot a lot of encrypted stuff

the scep pkioperation enrollment request shows the encryption certificate and the scpep protocol certificate

If we take a look at the Fiddler trace we would spot the same garbage

Afbeelding met tekst  Automatisch gegenereerde beschrijving

I tried to compare my not working Infineon one with a working (Nuvoton….) one but I couldn’t find anything weird in it… except that my Infineon device also sends out the Intermediate and Root certificates in the same request.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

5. The Flow

When combining all the information in the flow and using the TCG TPM documentation

6. The Certificate Chain

When looking at the certificates again, I noticed that the Infineon CA 042 Intermediate Certificate just got “renewed”. Valid from 08-02-2023.

TPM certficate chain

As mentioned before, when the ACA receives the AIK request (with the EKCert in it) it validates the “payload”. It will walk the chain of certificates to determine if everything checks out. What if the ACA at Microsoft wasn’t aware of this renewed certificate? I would assume it still checks the old Certificate.

With the fix Microsoft implemented, Microsoft made sure some specific Infineon TPMs (ca 042) are working again but unfortunately, other Infineon TPMs were still giving you attestation issues.

At first, I had the idea that only older TPMs were contributing to the issues, but that was definitely not the cause! So updating your firmware doesn’t look like the solution.

There is an issue with having a TPM with CA 042 and CA 039. The CA 039 was forgotten to be “renewed” on the Microsoft service side.

After some talks and reaching out to Microsoft and Infineon support and providing them with the failing request IDs as shown below

Suddenly something was fixed. As shown below about 7:00 AM Pacific time suddenly everyone who had the CA 039 could perform AIK Attestation

My guess, Microsoft forgot about the CA 039!

Conclusion

By the looks of it, the Intermediate certificate at Infineon got renewed without Microsoft knowing it. At that point, the certificate chainwalk would fail and, with it, the AIK Attestation. At first, TPs with CA 042 were fixed, and later on also, the TPMs with CA 039

Hopefully, this attestation blog showed you another reason why AIK attestation could fail even when you have done nothing wrong!

11 thoughts on “Triangle of TPM Attestation Sadness

  1. ah we we couldn’t provision any Hp G9 desktops today and they use infiniion tpm chips in the UK! this would explain it! amazing stuff legend of Intune

  2. Hello Rudy,
    Thanks a lot for all your work for the community!
    We now have a Service Restored notification in our tenant regarding this incident IT534781

    1. This issue is still not resolved for specific models.

      HP ProBook 430 G6 and HP ProBook 450 G6. (Infineon OPTIGA (TM))

  3. I’m still getting this error when trying to pre-provision an HP ProBook 450 G6 with the Infineon OPTIGA SLB9670 (fw 7.85.4555.0, spec 2.0, rev. 1.38). EK cert is version CA 039.

    I’ve ran through your attestation script and various other commands and it looks like it’s exactly what happened for you where the EK cert on the device has a validity period of 2019-07-13 to 2034-07-13, but the newest provided certs from Infineon are dated 2023-02-08 to 2043-02-08.

    Talking with Infineon support here: https://community.infineon.com/t5/OPTIGA-TPM/TPM-Attestation-Timeout-SLB-9670-Windows-11-Pro-22H2/td-p/410035

    1. Hi Rudy,

      I saw that you posted on the Infineon post. Thanks!

      You mentioned there that the 7.85 version was working, but if you look at the version I’m working with it’s 7.85.4555.0 and I’m still getting the error.

      Ran your attestation test script and it seems to check-off completely green until trying to run the real AIK cert part at the end. Then it fails.

      I’ve updated Windows, drivers, and BIOS to the absolute latest versions too.

  4. I’m seeing something very similar with older Atmel TPM’s under Windows 10.
    The Intermediate certificate retrieved by Get-TpmEndorsementKeyInfo is showing as expired April 7th 2023

  5. It is not an Infineon but STM of Thinkpad W520. Good fiddlings to you.

    Some Event logs after reboot, computer screen had frozen. Maybe will I clear TPM with windows service, in expectation to resolve burden.

    Error 28.07.2024 21:51:31 CertificateServicesClient-CertEnroll 87 None
    The winlogon notification subscriber took 132 second(s) to handle the notification event (Logon).

    Error 28.07.2024 21:37:18 CAPI2 4176 None
    PFX operation failed as AuthSafes count doesn’t lie in expected range. Maximum permissible value: 200. Erroneous value: 449.

  6. Hi

    I have this exact issue. The only difference ist that my devices have CA 035. Did Microsoft Forget those too?
    What can i do to fix this?
    Thank you for your help

Leave a Reply

Your email address will not be published. Required fields are marked *

96  −    =  86

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.