This blog will be the first of 3 and will be about the TPM provisioning part (which I briefly explained in another blog) when using devices WITH a firmware-based TPM (Intel, AMD or Qualcomm) and you need to perform a white glove.

Please note the flow I am showing is PRE Intel Tiger Lake, the next one will show you the flow WITH Intel Tiger Lake.

I decided to write these additional blogs because In my opinion there were still some important parts missing. While writing this blog I also updated my Blog about Willy’s White glove Autopilot flow 🙂

Before we start please read my previous blog showing us the bigger picture about this process. And while you are at it, read the other blog about Device Health Attestation as it will explain some terms!

1. TPM Attestation Errors

Let’s start by explaining why I decided to explain a little bit more about which errors we could receive when TPM attestation is not working. Here are some nice, beautiful errors you could run into while using Autopilot for pre-provisioned deployment. Please note that when using the user-based Autopilot flow, these errors shouldn’t occur as it doesn’t need to perform some Attestation with the use of the EkCert.

Error 1: Time-Out during TPM attestation check 0x800705b4 or 0x81039023

While running the first phase of the pre-provision process, you could experience a nice red screen. Luckily, I wrote a blog about his some time ago

https://call4cloud.nl/2020/12/the-red-screen-before-christmas

It could still help you a little bit… but I guess…. not in this case.

Error 2: Not found (404). 0x80190194 (-2145844844 HTTP_E_STATUS_NOT_FOUND)

Of course, when troubleshooting Autopilot for pre-provisioned deployment, one of the first things you need to do is, start running the MDMdiagnosticstool on the failing device. When running the mdmdiagnosticstool on a firmware-based device that is missing the EKCert. You could experience this error as shown below.

Error 3: Certreq_Enrollaik_output.log

Another log you should dig into should be the Certreq_enrollaik_output.log. In this Logfile you will find all kinds of nice errors, like the famous GetCACaps: Not found, like I am mentioning in this blog!

Looking at the log itself, you will again find the 404 not found error. This error code will also be logged in this registry key :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Ngc\AIKCertEnroll (If the TPM attestation is successful the error code will be set to zero)

If the TPM AIKcert enrollment part was not successful, you will end up with the error code 80190194

2. Some basic information about TPM’S

Okay, now we know the issues, first some additional basic one-liners about TPMs

*Firmware based TPM (fTPM): no hardware module on MB is needed

*Discrete based TPM: hardware module needed

*Firmware TPM devices, which are only provided by Intel, AMD, or Qualcomm, don’t include all needed certificates at boot time and must be able to retrieve them from the manufacturer on first use.

*Devices with discrete TPM chips come with these certificates preinstalled.

*Intel CPUs (“INTC”) have an embedded TPM 2.0 that Intel calls Platform Trust Technology (PTT).

*AMD CPUs have an embedded TPM 2.0 called fTPM since the AM4 platform (2016)

*PTT or Platform Trust Technology is a firmware extension from Intel that supports Microsoft TPM requirements.

*fTPM or Firmware TPM is a firmware technology from AMD that supports Microsoft TPM requirements.

*Run the gwmi win32_Processor, to determine what kind of CPU you have

As an example: 11th gen –>Intel Tiger Lake

*Run the tpmtool getdeviceinformation, to determine if you are good to go for attestation. Ready For Attestation needs to be: True

If you want to read more about the requirements of the “Ready for Attestation” to become True please read this blog. It explains the requirements needed!

3. The Attestation Flow

Now we have seen the errors and some TPM oneliners, let’s take a look at the whole flow with a firmware-based TPM device (PRE Intel Tiger Lake). I will divide this part into multiple subparts with a timestamp attached to it.

3.1 TPMcoreProvisioniong (9:15:41)

A kind and nice DLL file, tpmcoreprovisioning.dll will launch the TPM attestation/provisioning flow (UTC time)

3.2 WMI (9:15)

This attestation process will kick off by creating the necessary keys in the registry

HKLM\System\CurrentControlSet\Services\TPM\WMI\Endorsement\

3.3 Downloading the Autopilot Profile (9:15)

After the TPM registry keys are created, it will fill the Autopilot Provisioning part of the registry with the settings it got when it downloaded the autopilot profile. These important keys contain all the needed information about your Microsoft tenant

3.4 Getting the EKCert part 1(9:15:18)

That was the easiest part, now the coolest part. Like I told you at the beginning of this blog, firmware TPM (Intel, AMD etc) devices don’t include all needed certificates, these must be retrieved from the manufacturer (Let’s call it the Public CA). In this case, Intel is our TPM manufacturer. So it needs to fetch the needed *EKCert from Intel. This process is done by sending the endorsement /credentials key to Intel’s Public CA.

*This EK certificate contains the EK public key and is signed by the manufacturer. With that certificate, you can verify, that the EK public key is associated with a genuine hardware TPM produced by the manufacturer.

Before the device could send its endorsement credentials to the Public CA it needs to determine if the Public CA also can be trusted. This is done by checking the CA’s public exchange certificate if it is still valid and not compromised/disallowed.

To check out the Public CA certificate it first needs to fetch the up-to-date trusted certificates list from Windows update.

Looking at the cab file, you will notice it contains an STL file (Certificate Trust List File Type)

3.5 Getting the EkCert part 2 (9:15:42)

Now we have everything in place, we can check out the Public CA. If everything is good to go we can begin to create the connection to make sure we get out EKCert back.

So, the device will contact the TPM manufacturer Public CA and establish a secured channel/network connection to (in this example) ekop.intel.com. To set up this secured channel with the CA, the CA chain needs to be already imported into the Client, so I guess that’s why it fetched the STL file first.

Off the record: In this example below, the EkCert retrieving process died trying as the cert is not found?! Even with 21h2 it will fail (for now?)

But let’s pretend like this error didn’t happen……? This error is something for a new blog… about the ODCA!

Now we have our secured channel in place, the Public CA will ask for more information about the device.

To answer this call, the client will send its Client_HardwareKeyinfo. The Client_hardwareKeyinfo contains the *endorsement key/credentials to the Public CA to prove it’s trustworthy. (szOID_ENROLL_EK_INF)

*Endorsement credentials contain: the Public EK (EKpub) and information about the security properties of the TPM.

With all of this information, the Public CA will:

1. Check if the TPM is not at risk.
2. Check if the TPM has not been tampered with or compromised.
3. Check the TPM name if it’s a valid TPM (szOID_ENROLL_KSP_NAME)

If everything is good to go, it will decrypt the Client_HardwareKeyInfo and sign it with a certificate (*EKCert) to prove that the EKpub is associated with a genuine hardware TPM. Then, it will send it back to the device, which will decrypt it and save it for later use.

After the client receives the certificate encrypted with the EKPub part (EKCert), it can use this certificate to start the attestation.

3.6 Retrieving the AIK certificate (9:15:54)

With the EkCert in our possession we also need to establish a secure connection with the Microsoft Attestation Service aka ACA (*.microsoftaik.azure.net) to get back the Attestation Identity Key certificate (AIK). (please read that blog..)

Just like with the EKCert, the TPM needs to check if the ACA’s public cert is still valid and not compromised. Again, it will do so by fetching the up-to-date certificate list from the Windows update server.

If everything is fine, it will start the AIK activation process to establish a good trust relation, by sending the *Proof of identity (EKCert) to the Microsoft ACA using the *AIK.

*Proof of Identity contains: EKCert, platform certificate, AIK_pubkey, Identity label, Spec version, Identity binding

*AIK: “Their dedicated purpose is, is to sign the information/quote. This will prove the data was coming from inside the TPM and is not tempered with.”

With this information, the Microsoft Attestation Service is 100% sure it’s communicating with a real, living TPM. So, it will create the AIK certificate using the AIK_Pub it received earlier. After the AIK certificate has been created, the Microsoft Attestation Service will send back the much-needed AIK certificate!

The device will decrypt this AIK certificate by using the TPM and the EK private key (which only exists in the TPM itself), With this aik cert, a nice trust relationship is created.

The screenshot above is from a working device showing you the AIK certificate… Because the Intel Tiger lake CPU doesn’t like to retrieve its certificate from the Public CA. Without it… the AIK activation process will fail.

4. The Flow in a simple diagram

After the whole technical explanation, I will now show it in a simple flow. Of course, this flow can be used when you are using firmware-based TPM devices like intel and starting the pre-provisioning process.

5. Trying to Solve it.

Microsoft is telling us that 21H2 will solve all of those Intel Tiger Lake issues (and I guess also the AMD ones, etc.). As I told you earlier, I tried it with Windows 11 (21H2) and the 21H2 Windows 10 version. But both of them showed the same issue and flow.

Some people tell us you could change the host file on your device to change the IP address corresponding to a working CA. I spent a lot of time looking up all possible IP addresses I could use. I changed the IP address for the public CA (Intel) and the Microsoft AIK servers, but none of them worked.

But looking at the first response I got with the Intel CA… it’s pretty obvious as you ask me… The response from the Intel CA was clear: Certificate not Found.

I hope someone at Microsoft or Intel could give us some nice feedback on why it doesn’t have the certificate in store for us. So please share this blog with as many people as you can reach. Hopefully, someone at Microsoft/Intel or AMD will pick it up.

I guess for the second part of this blog, I am going to dig into ODCA (On-Die Certificate Authority) and the 11th-generation Intel CPU. Why? Because the whole flow I showed you will be changed with this 11th-generation Intel CPU!

6. Sources used

I guess I only need to show you one link and nothing more. It contains all the information about the Windows Client Certificate Enrollment Protocol but the data is a little bit scrambled all over the document…

[MS-WCCE]: Windows Client Certificate Enrollment Protocol | Microsoft Docs

Conclusion:

I guess now that I have dealt with some Device compliance, Device Health Attestation, White Glove Attestation, and now the TPM pre-provisioning in detail, I need to shout it out loud! I just love those TPMs.

I guess when looking at the simple flow in part 3, it’s obvious that when you have a pre-11th-generation Intel CPU, you will need to get the EKcert first before you can get your AIK certificate! Otherwise, the whole AIK flow will break and you end up with a nice red screen!

Maybe it is not important… but I am happy with my new T-shirt with this picture from above 🙂

Please read my other blogs about the TPM attestation series! (AND THE SECOND PART!!!!)

The Pursuit of HAPPY… Uhhh TPM Intel Happyness (part 2) – Call4Cloud

https://call4cloud.nl/category/attestation-and-compliance-series/