This is a supplement to the current enhancement proposal for adding support for agent-driven attestation to Keylime.
The IEEE 802.1AR specification describes a type of X.509 certificate known as a Secure Device Identifier, or DevID, which is issued by the manufacturer of a networked device and can be used to authenticate the device right out of the factory without further provisioning.
The Trusted Computing Group (TCG) has released a spec of their own (TPM 2.0 Keys for Device Identity and Attestation) which conforms to 802.1AR and allows the manufacturers of devices which ship with a TPM to issue such DevIDs tied to the TPM. This addresses a shortcoming of the TPM 2.0 specification which requires the user to perform a binding between the device and the device's TPM themselves via some undefined mechanism (see TPM 2.0 Part 1, §9.4.3.3).
Work is in progress (on the server-side and agent-side) to allow Keylime to use these as a node's root identity in place of the EK, for users with devices which ship with DevIDs.
This page describes how the proposed trust mechanisms for future push support in Keylime can be applied to DevIDs as the root identity.
| Contents |
|---|
Device manufacturers which comply with the TCG device identity spec are actually required to issue two initial DevID-like certificates at manufacture time: these are termed an IDevID and IAK. The former can be used to sign any arbitrary data and is thus more consistent with the original use cases envisioned by 802.1AR whereas the later is used for certifying TPM attestations.
The TCG spec also allows other parties to generate DevIDs associated with a TPM. Such certificates are called LDevIDs/LAKs (where the 'L' stands for 'local') and are functionally identical to IDevIDs/IAKs.
During manufacture of a device that ships with an IDevID/IAK, the manufacturer uses the TPM to generate a new attestation key (AK) and issues a certificate for this AK, signed by the manufacturer's certificate authority (CA). These are known as the initial attestation key (IAK) and IAK certificate respectively.
The IDevID is produced in similar fashion: the manufacturer uses the TPM to generate a new signing key (i.e., a non-restricted key) and issues a certificate. The signing key is referred to as the IDevID key and the certificate itself is the IDevID.
The device manufacturer guarantees that the IAK and IDevID keys have been obtained from the unique device described by the IAK and IDevID certificates. The manufacturer will include information which uniquely identifies the device in the subject field of the IAK and IDevID certificates, e.g., the serial number of the device, and may include other details such as the model number.
Even though the IDevID/IAK keys will likely not be persisted by the TPM, they can be regenerated by the customer (or software installed by the customer, like Keylime) by performing the same steps described in the TCG spec.
Since an IAK is a TPM attestation key, it can only be used to certify data which has been created by, or loaded into, the TPM. Meanwhile, an IDevID key can be used to sign any arbitrary data, making it suitable, e.g., for producing identity proofs for any arbitrary challenge–response protocol based in public-key cryptography.
The same mechanisms for trusting EKs can be used for IDevIDs/IAKs, whether the trust store mechanism, the webhook mechanism, or a combination of both.
If the IDevID or IAK certificate provided by an agent can be verified against the registrar's certificate trust store, the IDevID/IAK is trusted in transitive fashion. The user may place a device manufacturer's CA certificate in the trust store to automatically trust all IDevIDs/IAKs issued by a particular manufacturer. Alternatively, they could directly place IDevID/IAK certificates themselves in the registrar's trust store to mark only those individual devices as trusted.
Just as with EKs, IDevIDs/IAKs can be alternatively be trusted based on a decision made by an HTTP endpoint configured by the user to be called as a webhook. This may be an attractive option when an IDevID/IAK certificate is not available to the agent at registration time.
The way in which IDevID/IAK certificates are made available to customers differs per manufacturer. As such, until a universal mechanism for obtaining these certificates is standardised, the user has a few different options to make the certificates available to Keylime:
- Agents can be pre-provisioned with the appropriate IDevID/IAK certificates prior to registration.
- The IDevID/IAK certificates can be added to the registrar's trust store as intermediate certificates. In this case, the registrar will still ensure that they chain to a trusted root certificate.
- The IDevID/IAK certificates can be added to the registrar's trust store as trusted certificates. In this case, the user is assumed to have verified the source of the IDevID/IAK certificates themselves.
- If the IDevID/IAK certificates are obtainable automatically, e.g., by querying an inventory management system, the webhook mechanism can be used to look up the appropriate certificate for the node and supply it to the registrar.
In those situations where no IDevID/IAK certificate is sent by the agent during registration and the node's IDevID/IAK certificate is made available to the registrar some other way (i.e., the last three list items above), the registrar can still establish a binding between the node's TPM and the IDevID/IAK certificates. This is because IDevID/IAK keys can be re-generated by the TPM at will and so the agent will always send the IDevID/IAK public keys to the registrar even when it cannot send the corresponding certificates.
IDevID/IAK certificates contain the device's serial number more often than not. We propose adding a configuration option to set the agent's identifier to the serial number extracted from the IDevID/IAK certificate (supported alongside the current options for hostname and EK hash). Then, given that the identifier presented by an agent matches its IDevID and IAK certificates, the identifier can be deemed bound to the device identity and the TPM identity and the verifier can confidently apply the correct verification policy for that node.