Last Updated on April 12, 2023 by rudyooms

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!

This blog will be updated along the way

1. Introduction
2. A brief introduction to Attestation
3. Taking a closer look
4. The “Garbage”
5. The flow
6. The Certificate Chain

1. Introduction

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

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

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

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

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

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)

(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 would walk the Certificate Chain to the proper AIK URL. This one would be created by using the proper Intermediate 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.

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

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 it’s roaming appdata.

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

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

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

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 certificate in the same request.

5. The Flow

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

6. The Certificate Chain

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

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 giving the issues but that was definitely not the cause! So updating your firmware doesn’t look like the solution

It starts to look like an issue between having a TPM with CA 042 and CA 039. It looks like 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 chain walk 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!