[New post] The Pursuit of HAPPY… Uhhh TPM Intel Happyness (part 2)
Rudy Ooms posted: "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!Like I showed /told you in the blog,"
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!
Like I showed /told you in the blog, it showed you the flow with firmware-based TPM's (fTPM).
A lot changed with the Intel Tiger Lake chipset (11th gen) and like I also showed you, a lot of parts in the flow could break. I will try to guide you through the whole flow and hopefully can show you the "why" in why it breaks.
Let's start with the Management Engine, to begin with. In the past, all Intel CPU's 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 stick to some important changes in CSME 15.0.
The CSME was introduced with the release of Tiger Lake. Did you notice the MS Docs?
One of the many technologies for which the CSME is the cryptographic basis for is the firmware based TPM. Let's talk some more about this.
One of the biggest changes within the CSME 15.0 would be 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 whilst preserving the user's privacy.
It will increase the security and maybe it could 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 it can create the needed EKCert without having a server connection.
Please note: The creation of the EKCert, doesn't necessarily need to happen at 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 comes 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. With that information, it could create a query to the AIK service.
Like I told you in the "EKCert" part, we noticed that we now have (11th gen Intel) a build-in certificate authority that generates its own EKCert. Isn't that nice?
But that's not all because the TPM Key/ Signing key that needs to sign the EkCert also has a device unique (available in the TPM) intermediate certificate (ODCA) which also needs to be signed.
But 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 unique ODCA Intermediate certificate that is inside the TPM.
We need to have the device unique ODCA intermediate certificate because it's the signer of the EKCert. And another "big thingy", We also need to have 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)
You will end up with a nice "does not exist" error when trying to connect to the wrong URL.
And a nice red screen of death… uhhh Autopilot
1.3 The Ek Certificate Flow Pre 11th Gen and the 11th Gen
Okay, we now know what changed with the new CSME 15.0 and the 11th gen Intel Tiger Lake chipset, I will try to explain the 11th gen certificate flow in a diagram and with some more details
11th 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 11th Gen
Now we have seen the new flow, compare this flow below to the Pre 11th
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 11th Gen Ekcert?
When you have read the first part of the happyness blog you have noticed the Intel EkCert was being retrieved from ekop.intel.com during the pre-provisioning autopilot flow.
Like I told you in the "what changed part" earlier on, this is process is done within the Intel CSME now. Let's take at what else needs to happen to get the AIK certificate to do some attestation
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:
You will find your nice Endorsement Key Certificate in it. It's the same you get when running the command: get-tpmendorsementkeyinfo. Look at the thumbprint!
Just for fun, delete this key and run this tpm-maintenance task like 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
Now open that certificate you exported with one of the 2 methods I described above. And make a note of the Key Id of the CA like I show below. I am going to show you later on why this key id is important!
Just like with the EKCert, I will divide this part also in 2 subparts
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 time out error
But let's try it on a Pre 11th 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)
So I guess you know now, why I showed you that ISSUER ID from the EKCert export results!
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
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
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
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.
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!!!!
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
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.
And of course the troubleshooting tools I mentioned in part 1 of this blog!
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 we might think we can fix it on our own.
Here is what you might try to do
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
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)
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
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 would 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.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.