I guess it’s time for the second part of the Pursuit of Happy…Uhhh Tpm happyness. In the first part, I showed you the first phase during pre-provisioning the device with Autopilot. Please read this first if you haven’t!

As I showed /told you in the blog, it showed the flow with firmware-based TPMs (fTPM).

A lot changed with the Intel Tiger Lake chipset (11^th gen), and as I also showed you, many parts in the flow could break. I will try to guide you through the whole flow and hopefully show you the “why” of why it breaks and, of course, how to fix it!

1. What Changed?

I guess I also need to divide this one into multiple separate parts.

1.The EKCert

2.The AIK part

3.The Certificate Flow

1.1 EKCert

Let’s start with the Management Engine. In the past, all Intel CPUs had a chipset that contained the Management Engine. This Management Engine is now called the CSME (Converged Security and Management Engine). Please note that the CSME runs in an isolated environment.

This engine is the root of trust for all the Intel technologies and components in the device. There is a lot to tell about the CSME, but in this blog, I will focus on some important changes in CSME 15.0.

The CSME was introduced with the release of Skylake. Did you notice the MS Docs?

One of the many technologies for which the CSME is the cryptographic basis is the firmware-based TPM. Let’s talk some more about this.

One of the biggest changes within CSME 15.0 is the replacement of the Intel Enhanced Privacy ID (EPID) with an On-Die Certificate Authority (ODCA).

*Intel(R) EPID is a cryptographic protocol that enables the remote authentication of a trusted platform while preserving the user’s privacy.

It will increase security and maybe be cost-effective. Please Remember, remember the ODCA of November to stay stuck in movie quotes.

You can guess what it does when reading the name out loud… Like any other certificate authority, the ODCA is responsible for issuing certificates, but with the ODCA, there is a little difference because it can issue certificates for internal functions WITHOUT establishing a server connection. Do you remember the part I mentioned when the device was reaching out to ekop.intel.com?

With ODCA, this isn’t necessary anymore, because the ODCA can issue certificates to a lot of applications, to mention a few.

*Boot Guard

*DRM

*PTT (Intel Platform Trust Technology)

The last one is PTT… Mmm, that sounds a lot like Trusted Platform Module (TPM), does it? Oh, wait… I mentioned that one also in the happyness blog .

ODCA summary: The ODCA can help generate the endorsement key and create the needed EKCert without having a server connection.

Please note: The creation of the Endorsement Key Certificate (EKCert), doesn’t necessarily need to happen during the self-provisioning phase. When you have installed the device and pressed shift-f10 to get the command prompt, you will notice the EKCert is already there. So it doesn’t need to fetch it at the securing hardware phase.

1.2 AIK

And yet, there is another change. In the past, the Microsoft AIK service checked out the device to identify the vendor by checking the issuer ID of the Public EK certificate. That information could create a query for the AIK service.

As I told you in the “EKCert” part, we noticed that we now have (11^th gen Intel) a build-in certificate authority that generates its own Eckert. Isn’t that nice?

But that’s not all. The TPM Key/ Signing key that needs to sign the EkCert also has a device-unique (available in the TPM) intermediate certificate (ODCA) that also needs to be signed.

However, that signing key/Intermediate Certificate is chained up to the Intel Root CA, so to verify the certificate chain, we also need to fetch that device’s unique ODCA Intermediate certificate inside the TPM.

We need the device’s unique ODCA intermediate certificate because it’s the signer of the EKCert. Another “big thingy” is that we also need this certificate to make sure the right AIK URL can be built!!!

Windows determines the address of *.microsoftaik.azure.net based on the manufacturer id (Intel INTC) and the Issuer ID of what Windows thinks is the intermediate CA for the EK Certificate.

As an example: (intc-keyid-)ca712a9f875e48cde7bf657fb7262c703eff5fe2.cer

Microsoft made sure it has set up AIK service CA’s for each TPM vendor and they have one per product line.

You can guess what happens when Windows tries to get an AIK certificate and it doesn’t know about the ODCA intermediate certificate that signed the EKCert… It will try to connect to the wrong AIK URL (It will use the issuer ID from the EKCert and that one is device unique)

When trying to connect to the wrong URL, you will receive a nice “does not exist” error.

And a nice red screen of death… uhhh Autopilot

1.3 The Ek Certificate Flow Pre 11^th Gen and the 11^th Gen

Okay, we now know what changed with the new CSME 15.0 and the 11^th gen Intel Tiger Lake chipset, I will try to explain the 11^th gen certificate flow in a diagram and with some more details

11^th Gen

*EKCert (It’s in the TPM, generated in the CSME and it’s signed by the ODCA Intermediate Certificate)

*ODCA Intermediate Certificate (This device unique certificate will be read by the TPM and is also generated in the CSME. This certificate is signed by the Intel Intermediate Cert)

*Intel Intermediate Certificate (This device family unique certificate is provided by Intel and is signed by the Intel Root Ca)

*Intel Root CA (I guess I don’t need to explain this one)

Pre 11^th Gen

Now we have seen the new flow, compare this flow below to the Pre 11^th (Infineon as an example)

You could also walk the EK Chain by using the TPMDiagnostics.exe tool!

When looking at the details, you maybe have noticed that in the pre11th gen I am showing the exact flow with the names in it, shall we look at the 11^th Gen Ekcert?

You will notice a nice error status: The supplier of this certificate could not be found! That could be a problem?

2. The Graphical Flow

When you read the first part of the happiness blog, you noticed the Intel EkCert was being retrieved from ekop.intel.com during the pre-provisioning autopilot flow.

As I told you in the “what changed part” earlier on, this process is done within the Intel CSME now. Let’s look at what else needs to happen to get the AIK certificate to do some attestation

3. Take a look at the EKCert Yourself

Before I show you the technical details behind the graphical flow, I need to explain a part a little bit more, so you can understand how the AIK URL is created. To do so open the registry and browse to this key:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tpm\WMI\Endorsement\EKCertStore\Certificates\

You will find your nice Endorsement Key Certificate in it. It’s the same one you get when running the command: get-tpmendorsementkeyinfo. Look at the thumbprint!

Just for fun, delete this key and run this tpm-maintenance task as shown below

It will get the EKcert back in the EkCertStore.

But let’s go forth and take a look at how we could get some more information about this nice certificate. We have got 2 options here

1. Using the Registry
2. Using a PowerShell One-liner
3. TpmDiagnostics Tool
4. The results

3.1 Using the registry

1. Export the corresponding registry key/blob I showed you earlier

2. Open the reg file with notepad and remove all the weird stuff in it (, \ etc and all spaces) , so it looks something like this

3.Download this hex editor tool and copy-paste the contents in a new file. When everything checks out you can export it to certificateoriginal.cer

HxD – Freeware Hex Editor and Disk Editor | mh-nexus

4. Now open a cmd and copy-paste these commands in it

certutil -encode certificateorginal.cer certificatedecoded.cer

certutil -dump certificatedecoded.cer

3.2 Using a PowerShell one liner

But why not use a nice PowerShell One liner to export your EKcert ?

(Get-TpmEndorsementKeyInfo).ManufacturerCertificates | Foreach-Object -Process { Set-Content -Value $_.RawData -Encoding Byte -Path “$($_.Thumbprint).crt” -Force }

3.3 TPMDiagnosticsTool

In Windows 11, we could add an additional optional feature called TPM to our device

When it’s installed we could fetch the EK cert by using the “GetEkCertFromReg” command. It will output the registry to a nice CRT file!

3.4. The Results

Now open that certificate you exported using one of the 2 methods I described above. Make a note of the CA’s Key ID, as shown below. I will show you later why this key ID is important!

4. Taking a look at the AIKCert Yourself

Just like with the EKCert, I will divide this part into 2 subparts

4.1. The Command

4.2 The Results

4.1 The Command

To get back some information about the AIK certificate, you will need to enter one command line. Of course, I couldn’t do this on an 11th gen device. For now, you will end up with a 0x80072ee2 WinHttp: 12002 error_WINHTTP_TIMEOUT

But let’s try it on a Pre 11^th gen device, should we?

To do so, the only thing you need is to put in 1 command (O

certreq -enrollaik -config “”

It will give you a lot of information about the TPM, did you notice the https://IFX-KeyID part? Looks familiar, right?

And do you know what cool is? Just copy the information from ——begin certificate —– to —-end certificate —– like I am showing below and copy-paste it in a text file and give it a nice name, something like Thisismyaikcert.cer

4.2 Results

As shown below, you will notice the Key usage: AIK-Certificate (Again…. As 11th gen isn’t working yet… I did this on a pre 11th gen device)

And who the issues of this nice certificate is! (Mmm.. looks like the AIK service URL)

5. The Technical Flow

So I guess you know now, why I showed you that ISSUER ID from the EKCert export results!

1. The TPM will request the ODCA to issue the EKCert. This process could happen anytime but mostly when the TPM fires up! The build-in ODCA will create the EKCert and will send it back
2. So step 1 doesn’t need to happen when performing the self-provisioning phase, but it needs to happen because we need our EKCert. Now Windows will need to read the EkCert from the TPM to determine if it’s an Intel TPM and if so, it will check if the firmware version corresponds with a version in which an Intel ODCA exists. If an ODCA exist, Windows will need to walk up to/verify the certificate chain
3. But to verify the certificate chain, the device also needs to check/have the ODCA Intermediate certificate. Todo so Windows will ask the TPM for the ODCA Intermediate certificate. This Certificate isn’t stored online anymore but only exists in the Intel CSME
4. If … and that is the big issue. When it’s possible for Windows to retrieve and read the ODCA Intermediate certificate, the device could finish the EkCert validation and could “walk” the certificate chain.
5. The device needs to walk the certificate chain to get the ISSUER id of the device unique ODCA intermediate certificate, because it needs that issuer id (Intel Intermediate CA) to create the AIK service url!!!!
6. If Windows could fetch/read the ODCA intermediate certificate to find the Intel Intermediate CA it will create the right AIK url and will send the EKpub/Cert to get the so much needed AIK certificate
7. When everything checks out and the AIK service knows about the Ek intermediate cert it can issue the AIK certificate.

So to give a brief summary. If Windows is not able to read the ODCA intermediate Certificate it will use the wrong issuer ID to create the AIK url. And we all know what happens when you are trying to knock on the wrong door.

6. Sources used

*Intel® AMT SDK Implementation and Reference Guide

*WhitepaperCSME (intel.com)

*Intel publishes details of the new management engine CSME 15.0 – Rondea %

And of course the troubleshooting tools I mentioned in part 1 of this blog!

7. My stupid Attempts to fix it

Now we all know we are getting the wrong AIK URL from the EKcert Issuer ID and not the working one from the ODCA intermediate Certificate, so we might think we can fix it on our own.

Here is what you might try to do

1. Changing IP addresses in your host file to match another Intel Intermediate CA is not going to work, as it still is trying to use the same url
2. Installing your own dns server and creating a cname to a working CA . You could get a working intel ca from this list below (as the URL isn’t changed)

https://docs.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-install-trusted-tpm-root-certificates

1. I had the good hope that redirecting the wrong INC-KEY url to another known and working intel Intermediate ca with the use of fiddler rules could be a (stupid) solution

But looking at the error (0x80092009 CRYPT_E_NO_MATCH) above, I guess you know the outcome

8. 21h2 Should fix it right?…..

Luckily, Microsoft is aware of TPM attestation errors when you are using Windows 10 21h1.

It’s a good thing we can all download 21h2 right now. There are a lot of nice features added!

What’s new for IT pros in Windows 10, version 21H2 – Microsoft Tech Community

Now, let’s test the same EKCert/Intermediate flow with 21h2 again. You don’t need to perform the white glove to check it out. Of course, you are free to test it by pressing the Windows logo 5 times to start the pre-provisioning, but launching the Eckert task and performing the certenroll -enrollaik -config “” will do the same.

So let’s check it out!

As I showed earlier, the AIK process will still try to connect to the wrong AIK URL. I guess Microsoft needs to update its documentation.

To be sure I of course also performed a white glove… The red screen showed us a nice error: Something happened, and TPM attestation timed out.

9. Applying the Fix!

Okay, we have learned that the officially released 21H2 isn’t fixing it… So what now? Let me tell you a little secret… KB5007253 is going to fix your Intel Tiger Lake TPM attestation issues.

Do you want to know what’s funny? This article doesn’t mention what changed with this release.

Releasing Windows 10 Build 19044.1379 / 19043.1379 to Release Preview Channel | Windows Insider Blog

But I guess when you don’t believe me, I still need to prove it to you

So I downloaded the insider preview build from Microsoft first, installed the device…pressed shift + f10 to get into a nice CMD, and enrolled into the insider program.

After updating the whole device for the first time and rebooting and searching again for updates, this one popped up!

After rebooting I made sure I got the right Windows build version. As shown below, you will need to have the 19044.1379 build.

And now let’s try to white glove the device!!! .. Oh wait that’s too easy! let’s try it with certreq -enrollaik -config “” first

And export that certificate just like I did earlier on another device to see what’s in it!

And the certification path. As shown below… it can walk the certificate chain!!!

That Issuer ID / AIK Url looks way better than before… let’s check if we can find it in the AIK version history!

Now let’s start the pre-provisioning stuff! As shown below… it’s working!!!! yeah, it’s totally working!!!!!

Conclusion

So (in my opinion, correct me if I am wrong…) but looking at the facts I have seen, Intel changed some stuff, now Microsoft needs to change/add some code to make sure Windows could read the device unique ODCA certificate to start the process to retrieve the so much wanted AIK certificate.

If it does not get the ODCA intermediate certificate, it will create the wrong AIK URL, and the self-provisioning phase will fail!

And believe me, they are working on it! I can’t give you the solution to fix it, only one piece of advice… please have patience and hope this blog makes you understand what’s happening. And the KB that is going to fix it is released… even while it’s still only available in the insider preview… I am confident that this update will soon be released to the normal builds!