Setting up TPM protected certificates using a Microsoft Certificate Authority – Part 3: Key Attestation


Hey Everyone, I am back with the last part of this 3 of this series on TPM protected certificates.  The last topic for this series is on Key Attestation.  Recently I have had a few people ask me about the Key Attestation tab in Windows Server 2012 R2.  Another person informed me they tried to set it up, and it didn’t work.  That’s not cool.  I hadn’t used the feature before so I decided to take a dive into it and maybe I could help y’all out.  Here is what I found.  First, what is this for?  Key Attestation is an assurance mechanism.  It validates the private key in a certificate key pair are protected via a TPM.  If you don’t know what the big deal is about protecting keys via TPM please see part 1 and part 2 of this series.  Depending on how the key is being protected, the CA can also insert Issuance Policy OID’s into a certificate based on what attestation method was used.

The 3 methods used for Key Attestation are:

User Credentials: (Low Assurance) Issuance Policy/Certificate Policy OID: 1.3.6.1.4.1.311.21.32 – The user provides an EKPub to the enterprise CA.  The enterprise CA performs no further validation.

Endorsement Certificate: (Medium Assurance) Issuance Policy/Certificate Policy OID 1.3.6.1.4.1.311.21.31 – The TPM has a manufacturer supplied certificate embedded.  The Enterprise CA validates the EKCert chain.  All CA’s in the chain must be trusted.  This method also means that ALL TPM’s from the manufacturer’s chain are trusted.

Endorsement Key: (High Assurance) Issuance Policy/Certificate Policy OID: 1.3.6.1.4.1.311.21.30 – The Enterprise CA validates each EKPub provided against an administrator defined list of allowed EKPub.  The list is contained in a directory that includes files named for each EKPub SHA-256 hash.

 

Assumptions

This article assumes the individual has a basic understanding of Microsoft PKI and its components.

 

Microsoft Lab Configuration

Requirements:

  1. A domain controller running Windows Server 2003 or later
  2. An enterprise certificate authority running Windows Server 2012 R2
  3. A desktop or laptop with a enabled and configured TPM, running Windows 8.1
  4. You have completed the labs from part 1 of this series.  (We will be leveraging certificate templates you created from part 1)

Configuring and Testing User Credential Attestation:

This option only requests the client send an EKPub to the Enterprise CA.  There is no further validation other than the user’s domain credentials (low assurance).

Step 1: Certificate Template Configuration

In this section we will modify the template we configured in Part 1 of this 3 part series to perform key attestation and insert issuance policies.

  1. Open the Certificate Template Console (certtmpl.msc)

  2. Modify the Workstation Authentication Template you created in Part 1 of this series

  3. Verify the following:

    • Compatibility Tab

      • Certificate Authority: Windows Server 2012 R2

      • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

    • Cryptography Tab

      • Provider Category: Key Storage Provider

      • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

  4. New Settings:

    • Request Handling

      • Renew with the same key: cleared/unchecked

    • Key Attestation Tab

      • Key Attestation: Required

    • Attestation Type

      • User Credentials

    • Issuance Policies for key attested certificates

      • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following


Configuring and Testing Endorsement Certificate Attestation:

 

This option makes use of the certificate some manufacturers burn into their TPM’s.  Notice I said some, not all manufacturers are doing this.  The next fun thing about this one is, depending on the manufacturer you have to go chase them down to get copies of the public keys for all the CA’s in their chain and import those certificates into special containers on your CA.  The good thing about this is, after you do it all of the TPM enabled devices that chain to those certificates are trusted for attestation.

Let’s get started on setting this up.

Step 1: Who made my TPM and do I have an EKCert?

From the Windows 8.1 device that has a TPM.

  1. Open PowerShell as an Admin.
  2. Run the following cmdlet: Get-TPMEndorsementKeyInfoyou should get an output similar to that seen below.  Sorry I had to block out a bunch of stuff but you should get the point.  From here we can see the certificate information for the EKCert (if you have one)

  3. Now the fun part.  Visit the manufacturer’s site and pray they publish these certificates there and you can find them.  If not, you will have contact them and ask nicely.  Mine was the latter.

Step 2: Importing the Manufacturer Certificates to be used with Attestation

Now that the manufacturer has given us the public keys we can go ahead and import them into special containers in the local machine store so they can be used for attestation purposes.

Some of this is from the TechNet Article: TPM Key Attestation.  So a big thanks to the folks that wrote this.

The following commands will create the EKCert containers for the manufacturer’s certificates.

# Create EKCert containers and import TPM manufacturer certificates

cd cert:
cd .\\LocalMachine

new-item EKROOT

new-item EKCA

 

These commands will create the following certificate containers in the local machine store:

After you create the containers you will need to import the manufacturer’s certificates to the proper containers.

Now we can configure your certificate template for Endorsement Certificate attestation.

Step 3: Certificate Template Configuration

  1. Open the Certificate Template Console (certtmpl.msc)

  2. Modify the Workstation Authentication Template you created in Part 1 of this series

  3. Verify the following:

    • Compatibility Tab

      • Certificate Authority: Windows Server 2012 R2

      • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

    • Request Handling

      • Renew with the same key: cleared/unchecked

    • Cryptography Tab

      • Provider Category: Key Storage Provider

      • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

  4. New Settings:

    • Key Attestation Tab

      • Key Attestation: Required

    • Attestation Type

      • Endorsement Certificate

    • Issuance Policies for key attested certificates

      • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following


 

Configuring and Testing Endorsement Key Attestation:

 

This process takes the most administrative effort and thus provides the highest level of assurance.  With this method our goal is to populate a folder, either locally or network, with empty files.  The names of the files are the sha256 hash of the TPM endorsement keys for the devices in your organization you want to perform attestation.

Step 1: Identifying the TPM Hash

 

For this we are going to use a sample PowerShell script that I made using the one in the Technet article for a reference (with a few tweaks of courseJ).

#This line provides us with the TPM Public Endorsement Key info and also provides the hash in sha-256 form

$tpmhash=Get-TpmEndorsementKeyInfo -HashAlgorithm sha256

# We only want the hash value so here we pull just that value

$tpmhashfile=$tpmhash.PublicKeyHash

#Lastly we create an empty file with no extension whose name is the hash of the TPM EK public key.  Mine writes to a file share where multiple CA’s can read it.  Notice I said READ.  So the NTFS and file share permissions will need to be configured to allow the machine accounts of the CA’s to READ.

New-Item -path \\Fab-LAB-DC01\TPMHash\$tpmhashfile -ItemType file

 

Step 2: Adding the EKPub Hash Folder to the Issuing CA

 

Now that we have an EKPub hash file in the folder we need to have the CA recognize this folder as a repository. Remember, the CA machine account needs to have read permissions on this folder so if it’s local that’s no big deal.  But since mine is on a network share I needed to configure this on the NTFS and share permissions.

  1. We are going to run this command to add the folder as an Endorsement Key List Directory, there is currently no method to do this through the GUI

    certutil.exe -setreg CA\EndorsementKeyListDirectories +\\con-lab-dc01\EKPub$

    Alternatively you can run certutil.exe -setreg CA\EndorsementKeyListDirectories -\\con-lab-dc01\EKPub$ to remove a directory

  2. Now we need to restart the CA services for the change to take effect.  You can choose your favorite method I am going to use the command line.

    net stop certsvc & net start certsvc

Step 3: Certificate Template Configuration

 

  1. Open the Certificate Template Console (certtmpl.msc)

  2. Modify the Workstation Authentication Template you created in Part 1 of this series

  3. Verify the following:

    • Compatibility Tab

      • Certificate Authority: Windows Server 2012 R2

      • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

    • Cryptography Tab

      • Provider Category: Key Storage Provider

      • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

  4. New Settings:

    • Request Handling

      • Renew with the same key: cleared/unchecked

    • Key Attestation Tab

      • Key Attestation: Required

    • Attestation Type

      • Endorsement Key

    • Issuance Policies for key attested certificates

      • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following


Technical Resources:

 

Processing Rules for Key Attestation Based on a Trusted Endorsement Key
http://msdn.microsoft.com/en-us/library/dn410471.aspx

Get-TPMEndorsementKeyInfo
http://technet.microsoft.com/en-us/library/dn449037.aspx

TPM Key Attestation
http://technet.microsoft.com/en-us/library/dn581921.aspx

TPM System Fundamentals Testing Prerequisites
http://msdn.microsoft.com/en-us/library/windows/hardware/dn247549.aspx

TPM Attestation Test
http://msdn.microsoft.com/en-us/library/windows/hardware/hh998296.aspx

Links to part 1 and 2 of this 3 part series are below:

Part 1: Microsoft Platform Crypto Provider
Part 2: Virtual Smart Cards

 


Comments (10)

  1. WesH [MSFT] says:

    Microsoft does not support HSM’s. HSM support is provided by the HSM manufacturer.

  2. Anonymous says:

    215 Microsoft Team blogs searched, 58 blogs have new articles. 142 new articles found searching from

  3. chrisl says:

    Is it possible to use the YubiKey HSM with a Microsoft CA?

  4. Anonymous says:

    Von der Sicherheit privater Schlüssel – oder verstecken Sie den Haustürschlüssel immer noch unter der

  5. Pavel says:

    Hi, many thanks for this series.

    Q1: The last picture (Key Attestation) looks like that the certificate is for user/logon/signing. It is also issued for Wes. Shouldn’t be that certicicate for Workstation Authentication (i.e. LAB.fabrikam.com)?

    Q2: Does it make sense to issue certificates with Key Attestation for users? Any use case for such User cert?

    Sorry if those questions are silly 😉

  6. joshua says:

    @WesH I have configured my environment according to this series’ documentation. I am not able to issue a workstation cert including any of the issuance policies. The endpoint states that the certificate has invalid policy. If I exclude the issuance policy the certificate works correctly.

    1. WesH [MSFT] says:

      Are you using a 2 tier PKI? If so does your issuing CA certificate include either the allissuance policy (2.5.29.32.0 ), or the OID’s for the attestation issuance policies?

      1. Radim says:

        Hi WesH, I have the same issue as joshua, cannot include the “attestation policy” in the final certificate. It works without it.
        My problem is: How do I include this “allowance” to the subCA? I tried to do a rekey of the subCA (with same key) and used a new certificate template “NewSub” with “Issuance Policies = All issuance policies”, but the Root CA refuses to issue that cert because of wrong policies … (Error constructing or publishing certificate – Invalid issuance policy)
        Do I also need a new RootCA or what am I missing? Root CA is standalone and offline.
        Regards and thanks for your blogs, Radim

        1. WesH [MSFT] says:

          Here is a copy of the CAPolicy.inf I used on my subordinate CA. If the certificate policy does not make it into the request you may have to modify the CSR generated by your subordinate before submitting it to the Root.

          [Version]
          Signature= “$Windows NT$”

          [PolicyStatementExtension]
          Policies = AllIssuancePolicy
          Critical = FALSE

          [AllIssuancePolicy]
          OID = 2.5.29.32.0
          [Certsrv_Server]
          CRLPeriod=Days
          CRLPeriodUnits=7
          CRLDeltaPeriod=Days
          CRLDeltaPeriodUnits=1
          LoadDefaultTemplates=0

          [BasicConstraintsExtension]
          PathLength=0
          Critical=Yes

          1. MM-Vader says:

            do a dump of your root ca cert and check for issuance (certificate) policies there…

Skip to main content