-
Notifications
You must be signed in to change notification settings - Fork 58
FAQ
- What is an Attestation Certificate Authority?
- What is Supply Chain Risk Management and what role does the ACA play ?
- What does the ACA do to Provision a TPM?
- Is the ACA intended for use in an operational system?
- What capabilities is the ACA missing that a traditional CA would have?
- Does the ACA support both TPM version 1.2 and TPM version 2.0?
- What Operating systems will the ACA support?
- What Operating systems will the TPM provisioner (ACA client) support?
- What devices and/or specific TPM's has the TPM provisioner been tested on?
- How can I get involved with ACA development?
- What Future capabilities are envisioned for the ACA?
The Attestation Certificate Authority (ACA) is a specialized Certificate Authority (CA) which supports the creation and issuance of an Attestation Identity Credential (AIC) per the Trusted Computing Group's specifications. The requirement for specialization is a result of the nature of the keys for which it is providing certificates, the formats of the requests and responses specified, and the details of the identity creation process that are crucial for maintaining the "chain of trust" on which the trusted use of a TPM is based.
Supply Chain Risk Management is the application of risk management processes to the movement of a product from the Original Equipment Manufacturer (OEM) to a end customer taking ownership of the product.
The ACA plays a role in the acceptance testing of the product/device after delivery of any Trusted Platform Module (TPM) enabled device. The ACA can be configured to validate both TPM Endorsement Credentials and Platform Credentials as part of the TPM provisioning process (the acceptance test) that it performs. The validation process can be used to verify the OEM of the devices and sub components in the process.
The ACA main function is to create an Attestation Identity Credential for a device holding a TPM. There are a few policy options that the ACA Portal will support:
- No Validation of the TPM's Endorsement or Platform Credentials
- Validate the Endorsement Credential (typical PKI Cert validation: signatures, expiration dates, etc.)
- Validate the Platform Credential (same basic certificate validation as the Endorsement Credential)
- Check Platform Credential parameters against the device holding the TPM. (mainly motherboard and chassis serial numbers at this point).
No. The ACA is a proof of concept prototype that is intended to demonstrate a capability for provisioning a TPM and supporting TCG defined supply chain validation. It does not have many features that an operational CA would require.
There are many security related features that the ACA would need to incorporate that an operational CA would need such as (but not limited to):
- Support for user authentication and roles within the ACA (although this could be handled by a tomcat connector to a third party authorization service)
- Support for a a FIPS approved Hardware Security Module (HSM) (although this could be supported by a java security provider).
- Support for Attestation certificate revocation (although this could be handled by a intermediate CA)
Currently the ACA and TPM Provisioner only support TPM 1.2. TPM 2.0 support is expected early 2018.
The ACA support installation packages for RPM based systems (e.g. Redhat, Centos, etc.) 7.X release.
The TPM provisioner will support both RPM and Deb based Systems (Ubuntu 16.X).
| Manufacturer | Model | TPM |
|---|---|---|
| Dell | OptiPlex 9020 | STM 1.2.1.1 |
| Dell | PowerEdge R630 | WEC 1.2.4.15 |
| HP | ProLiant DL360p | Infineon 1.2.3.17 |
Currently we are still setting up the Project on Github, but expect to setup pull requests for the general public soon.
Future (planned) capabilities include:
- TPM 2.0 support
- Manifest (SWID based) golden baselines
- Update to the to be released version of the Platform Credential specification.