Attestation Client Server

These sections are close to what a production application would implement. The intent is to guide a developer who may not be familiar with the details of TPM 2.0.

TPM commands

The TPM commands and their the parameters are what an application would implement. Among the functions implemented are:

• Creating an EK from a template using TPM2_CreatePrimary.
• Validating EK certificates against the TPM vendor root certificates.
• Creating, loading, and using an attestation signing key.
• The Make Credential and Activate Credential processes, including creating, encrypting, and decrypting the challenge.
• Using TPM2_Quote to sign PCRs.
• Parsing a TPM 2.0 hash agile event log.
• Parsing a TPM 1.2 format IMA log.
• Examples for both RSA and Elliptic curve endorsement and attestation keys.

Enrollment and Attestation flow

These flows follow the standard TCG protocols.

These sections are implemented for a demo. It is expected that a production application will rewrite much of this code.

Database Code

Database access is integrated into the code and is hard coded to mySQL. A production application would create an abstraction layer so that different databases could be used.

Database Schema

While the schema represents typical storage, a production application may add fields. Some fields, like the TPM vendor, are purely for the demo.

Application Crypto

Similar to the database code, the crypto code uses OpenSSL. It should be abstracted if crypto library flexibility is desired.

Privacy CA

A production application should not put the privacy CA on the attestation server. It should be on a separate platform with isolation for security.
The attestation key X.509 certificate is a minimal carrier for the client public key. A production application that wants to use the certificate more widely may want to add fields.

IMA Log Format

The IMA log parser is hard coded to the TPM 1.2 SHA-1 format. Once IMA supports a hash agile format, the parser must be updated.

IMA Verification Keys

The server is hard coded to use one key to verify IMA signatures. This must be updated to support multiple signers. There must be some way to install signing keys, and perhaps to designate certain keys as approved on a client by client basis.

Client Server Data Interchange Format

The data is sent in json, with binary arrays sent as hex ascii. json is well supported by creation and parsing libraries, and the text format eases debugging. However, other interchange formats can certainly be substituted.

Client Server Network Interface

There is currently no client or server authentication, and data is sent in the clear. Client authentication will be useful to prevent a client masquerading as another and sending invalid attestations. Server authentication and encryption may be required for privacy.

Web Pages

The web pages are purely for a demo. They are php and do no validation of inputs.
Some fields, like the TPM vendor, the clickable EK and AK certificates, and the clickable quote report, are for a demo and would have little use for an end user administrator.
The IMA page displays the entire log. It's more likely that only error cases would be displayed.
Finally, it's likely that the attestation reports would be integrated into a more comprehensive dashboard, not displayed stand alone.

Download