Configuring the Trusted Platform Module (TPM) Key Attestation

Since Windows 8 it is possible, that private keys for certificates are protected with a - if available - Trusted Platform Module (TPM). This makes the key non-exportable - even with tools like mimikatz.

However, it is not obvious at first glance that it cannot be guaranteed that a TPM is really used. Although no application via Microsoft Management Console or AutoEnrollment possible if the computer does not have a TPM.

However, the configuration in the certificate template is only a default setting for the client. The certification authority will, when requesting do not explicitly check whether a Trusted Platform Module was really used.

To ensure that the private key of a certificate request has really been protected with a Trusted Platform Module, only the TPM Key Attestation remains.

Functionality

During TPM Key Attestation, the certification authority checks whether the certificate request has been signed with the Trusted Platform Module's Endorsement Key. This can be achieved in two ways:

EKPUB: This variant explicitly trusts the individual endorsement keys of the TPM of the individual machines. These are explicitly stored on the certification authority.
EKCERT: In this variant, the manufacturer Certification Authorities of the TPMs of the individual machines are trusted. The TPMs are identified on the basis of the endorsement certificate. The manufacturer certificates are stored on the certification authorities in a special trust store.

The third option, User Credentials, in which the user confirms that the certificate request has been protected with a TPM by means of his credentials, is of course not really secure and is therefore not discussed further here.

Setting up the EKPUB method on the Certification Authority

This method has the disadvantage that it does not scale well. Without a management solution, it will be practically impossible to determine (in a secure way!) all endorsement keys.

The EKPUB method is the most stringent and is therefore also considered to be "High Assurance Level".

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

Export and deposit endorsement keys

A directory is created on the certification authority in which the checksums of the endorsement keys are saved as a file. The following command is then used to include the directory in the configuration of the certification authority.

certutil.exe -setreg CA\EndorsementKeyListDirectories +"{directory name}"

The following Windows PowerShell command can be used to identify the endorsement key hash of a Trusted Platform module and write it to a compatible file.

New-Item `
-Path (Get-TpmEndorsementKeyInfo -HashAlgorithm SHA256).PublicKeyHash `
-ItemType File

These files must now be saved for each client computer in the directory previously configured on the certification authority.

Setting up the EKCERT method on the Certification Authority

The EKCERT method is considered a "medium assurance level". It has the advantage that it is not necessary to determine each individual endorsement key. Instead, the manufacturer Certification Authorities are trusted, which (hopefully) have signed an endorsement certificate for the respective trusted platform module.

Generate certificate store on the certification authority

First, two new certificate stores must be created on the certification authority:

Endorsement Key Trusted Root Certification Authorities
Endorsement Key Intermediate Certification Authorities

This can be done with the following Windows PowerShell command:

cd Cert:\LocalMachine
New-Item EKROOT
New-Item EKCA

Afterwards, these certificate stores should show up in the Microsoft Management Console (MMC) for computer account certificates (certlm.msc).

Determine certification authority certificates

Microsoft offers a cabinet file for the Host Guardian Service (HGS), which contains the manufacturer certification authorities for the most common Trusted Platform Modules. This can also be used for the TPM Key Attestation.

The latest version of the list can be downloaded from this link can be downloaded. Since it is very complex to maintain all manufacturer certificates, this is a useful starting point.

If you do not want to use this option, or if the manufacturer certificate of a computer is not included, it can also be extracted manually from the TPM of a computer. The determination of a manufacturer certificate from a Trusted Platform Module is described in the article "Determine and export a Trusted Platform Module (TPM) Endorsement Certificate" described.

Unfortunately, not every TPM has an endorsement certificate, so it may also be the case that the EKCERT method cannot be used for certain computer models.

Import certification authority certificates

First of all, the code signature of the channel file should be checked.

Get-AuthenticodeSignature .\TrustedTpm.cab

Afterwards the cabinet file can be unpacked:

mkdir .\TrustedTPM
expand.exe -F:* TrustedTpm.cab .\TrustedTPM

The folder contains the certificates and, conveniently, an installation script. However, since this is for the Host Guardian service, it must be edited to be used for a certificate authority.

The variables $intermediateStore and $rootStore are adjusted as follows:

$intermediateStore = "Cert:\LocalMachine\EKCA"
$rootStore = "Cert:\LocalMachine\EKROOT"

The file is digitally signed. Changing the file will invalidate the signature, which we have to accept in this case.

Now the certificates can be imported with the script.

.\setup.ps1

The two trust memories should now be filled.

Function test

Whether a certificate authority trusts a particular endorsement certificate for TPM Key Attestation can be checked with the following PowerShell command:

New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 "{Path-to-Certificate}"| Confirm-CAEndorsementKeyInfo

For the export of an endorsement certificate see article "Determine and export a Trusted Platform Module (TPM) Endorsement Certificate„.

Configure certificate template

In order to be able to issue TPM-protected certificates, a certificate template must first be configured, which contains the Microsoft Platform Crypto Provider is used. This process is described in the article "Configure a certificate template to use the Microsoft Platform Crypto Provider to enable private key protection through a Trusted Platform Module (TPM)." described.

Afterwards, the attestation can be configured in the "Key Attestation" tab. The following options are available:

Key Attestation	Description
None	The certificate request is not checked for attestation. The certificate is issued even if the attestation was not successful.
Required, if client is capable	The certificate request is checked for attestation only if the client supports it. The certificate is issued even if attestation was not successful.
Required	The certificate request is checked for attestation in any case and the request is discarded if it was not successful.

Perform Attestation based on	Description
User Credentials	The user confirms that the private key is protected with a TPM, which of course is not really secure.
Hardware certificate	Corresponds to the EKCERT method.
Hardware Key	Corresponds to the EKPUB method.

The attestation methods can also be combined with each other by multiple selection. For example, clients that do not have an endorsement certificate can be checked via EKPUB and all others via EKCERT. The "User credentials" method is of course not really secure and should therefore not be used.

Include certificate policies in issued certificates

In addition, it can be specified that the Certification Authority writes an issuance policy in an issued certificate to confirm the type of attestation.

OID	Meaning
1.3.6.1.4.1.311.21.32	TPM Key Attestation: User Credentials: (Low Assurance)
1.3.6.1.4.1.311.21.31	TPM Key Attestation: Endorsement Certificate: (Medium Assurance)
1.3.6.1.4.1.311.21.30	TPM Key Attestation: Endorsement Key: (High Assurance)

For example, from the combination of these options, it is possible to specify that while every applicant is granted a certificate, only those whose private keys can be proven to be protected with a TPM (which can be proven via the issuance policy in the certificate) are also granted access to certain resources.

However, in order for these policies to be written to issued certificates, the certification authority certificate must also be configured accordingly. See the articles "Include the issuance policies for Trusted Platform (TPM) Key Attestation in a certification authority certificate." or "Include the wildcard issuance policy (All Issuance Policies) in a certification authority certificate„

Troubleshooting

Failed TPM attestations are usually indicated by the events with the numbers 22 and 53 identifiable on the Certification Authority.