- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
- Core members have approved the issue with the label
implementable - Design details are appropriately documented
- Test plan is in place
- User-facing documentation has been created in [keylime/keylime-docs]
This enhancement proposes leveraging the IDevID and IAK keys/certificates to register each device at the registrar service and enabling the generation and use of LDevID and LAKs. IDevID is an industry standard identity which is issued by manufacturers when the device is built.
The IEEE 802.1AR Standard [1] defines a secure device identifier (DevID) as "a cryptographic identity that is bound to a device and used to assert the device’s identity". The initially installed identity is defined as an IDevID/IAK ("I" for initial) and is installed in the factory, where the server, switch, or other device is built, before shipping. The IDevID credential is intended to be usable for the life of the product. The IDevID/IAK is expected to be created at device manufacturing time.
The IEEE 802.1AR Standard can be used together with TPM-based keys and certificates as described in [2]. It applies the IEEE Standard 802.1AR device identity module definition and formatting to keys protected by a TPM 2.0. It addresses ways to incorporate TPM 2.0 created keys into solutions that protect device identities and helps prevent a "malicious endpoint". TPM is a secure Root of Trust for Storage (RTS) that provides protection for private keys, preventing use of keys from one device on another device or with another TPM. The security of the DevID keys provisioning is anchored in the Endorsement Key (EK) and its certificate (issued by the TPM manufacturer).
The IDevID and IAK keys are generated by the TPM at the OEM factory and certified by the OEM CA. The CA enforces the TCG-defined provisioning protocol which uses the EK similarly to how Keylime currently validates colocation of the EK and AK. The IDevID certificates include serial number information, so you can identify the specific device. This is used to bootstrap onboarding of devices for services, including attestation services. Using IDevID, provides important security guarantees to users. It assures them the device is genuine and one that they own (via the serial number in the IDevID). In many cases the devices will be geographically distributed in remote or branch offices, for example. So securely identifying the specific device is important.
[1] IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity at https://standards.ieee.org/standard/802_1AR-2018.html
[2] TPM 2.0 Keys for Device Identity and Attestation at https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf
- Use IDevID and IAK keys/certificates to register each device at the registrar service
- Use LDevID and LAK keys/certificates to register each device at the registrar service
- Provisioning of LDevID and LAKs based on the IAK. The provisioning is done outside of Keylime, or at least as a separate tool.
- mTLS usage scenario
We propose to optionally leverage the IDevID and IAK keys/certificates to register each device at the registrar service and generate the LDevID and LAK keys/certificates. This will enable: 1) further checking of the device based on IDevID information and CA trustchain ; 2) use of IAK for generation of LAK and LDevID ; 3) attestation based on LAK instead of an ephemeral AK.
For compatibility reasons and taking into account different scenarios, the proposal extends to the ones detailed below regarding the possible keys. When EAK is mentioned it means an ephemeral Attestation Key that can be generated at the TPM with access to exporting it's public and private parts. Generally the private part of the EAK is exportable encrypted, so that it can be reimported into the TPM but not used anywhere else, while the private part of IDevID and IAK keys cannot be exported due to TCG defined template restrictions.
- EK, EK certificate and EAK: this is the current configuration used in Keylime
- EK, EK certificate, IDevID, IAK and EAK: this configuration can be used when an IDevID and IAK exists, but the user does not want to maintain a CA for issuing LDevIDs or LAKs.
- EK, EK certificate, LDevID and LAK: this configuration can be used when a long-lived AK is required, but no IDevID/IAK is available. The proof of co-residency is done between the LDevID/LAK and the EK.
- EK, EK certificate, IDevID, IAK, LDevID and LAK: this configuration enables issuing LDevID and LAKs based on the IAK (from the OEM) and allows the user/client to issue LAK certificates from their own CA.
Adding support for IDevID and IAK as an option to the Keylime registrar, to the RUST agent, and verifier services, allows our users to take advantage of IDevID and IAK when using Keylime. It will promote use of IDevID for switches and servers, which will improve security for all users. Using the IAK and IDevID credentials would mean the OEM had already exercised the proof of residency pre-requisites for generating the credentials, making it possible to simplify the registering process to a single exchange from the agent to the registrar service, by skipping the DevID provisioning in the field.
A challenge (nonce) will be sent to the node agent to prove it owns the TPM protected private EAK key, avoiding registering a node that is invalid (does not have access to the private key related to the certificate provided). Explicit proof of possession of the private IAK key is not required as the TPM needs this when using TPM2_Certify in the process, which can use the nonce, and that is used for the proof of co-residency between the IAK and LDevID/LAK/EAK, so proof of possession is implicit
Either the EAK or the LAK can be used for attestation, and in case when there is no IDevID and IAK keys then the EAK is verified using the EK and the Make and Activate credential process. Furthermore, the idea is not to use the IAK for attestation of the device after it is registered, so it's necessary to enroll an EAK. The IAK and IDevID certificates and their associated keys don't expire, as they are intended to last the life of the product, so several years at least. To preserve the cryptographic strength of the keys it is recommended to minimize their use.
Regarding the validation process on how the IAK and IDevID certificates will be accepted: the registrar service will need to be configured with a set of trusted CA certificates for validating IAK and IDevID certificates in order to support a multi-OEM environments. More precisely, when used they will be validated through:
- Checking the validity of the certificate chain from the OEM;
- Checking the device information (as Serial number) present at the IDevID cert. This is optional.
- Executing a challenge/response with the agent to ensure it has the private keys. The challenge is not necessary in case TPM2_Certify is used in the process, as previously mentioned.
Regarding the item 1 when checking of the certificate chain, the OEM should supply the IDevID and IAK signed certificates along with the necessary intermediaty certificates used within the signing process. Once the Keylime server is deployed the Root CA Cert of the OEMs should be configured within the registrar service. This way the registrar service will be able to fully validate the trust chain.
In case the Root CA Cert of the OEM is not available and/or the intermediate certs are not provided, this will block the validation of item 1, but this should be configurable. This will allow using the IDevID and IAK even if the certificates are not available (item 1).
Regarding the validation of LAK and LDevID: the LAK should be verified to be in the same TPM as the IAK provided by the OEM and the IAK certificate shows in which device this key resides on. The LDevID key should be verified to be in the same TPM as the LAK.
The IDevID plays an important role to securely identify that a device is genuine from a given OEM. Within the registration process, along with information like the EK and EAK, the IDevID key and certificates will be provided. At the registrar service the OEM Root CA will be configured and the IDevID trust chain will be checked, ensuring the certificates are signed by the OEM CAs. In addition to the certificates the signed IDevID certificate Subject will contain the device's SN(Serial Number) and the registrar service will check it against the information obtained from the device.
With the IAK provided by the OEM, the client can issue it's own LDevID signed by it's own CAs. Instead of a long lived certificate as the IDevID from the OEM, the client can renew this certificate on a more frequent basis and securely verify its binding to the IAK and the devices TPM. Along with the LDevID, it can create LAKs for different services or workloads, enabling a secure execution of services issuing short lived LAKs according to the demand in place.
The risk involved at this proposal is increasing the configuration complexity and by enabling using different chains of trust for the IDs.
For mitigation it is necessary to properly document what is trusted during registration and what is not, besides providing examples on how to configure it correctly.
A potential workflow is presented below for the scenario using EK, EK certificate, IDevID, IAK, LDevID and LAK. The other scenarios will include most parts of this workflow. It also worth mentioning that when using an IAK the EK is not needed to enroll another AK (being either an EAK or an LAK). Instead of using make/activate credential, which requires a decryption key, TPM2_Certify is used to prove that the EAK/LAK (including the sensitive area, e.g., the plaintext private key) is co-resident in the same TPM as the IAK.
- Create session (done at get_tpm2_ctx)
- Get endorsement certificate from TPM NV index and EK public key (done at create_ek)
- Regeneration of IAK and IDevID possible info (create create_iak and create_idevid routines). Depending on the configuration, the IDevID/IAK may also require a session.
- Load the IDevID and IAK and their certificates from a given local path and send them along with the rest of the attestation/measured data to the registrar service
- Create keys for LAK and LDevID based on the IAK (if possible, load them if already created). When using the TPM2_Certify the nonce should be used here.
- Encode the necessary data and send it to the registrar service (modify the method do_register_agent to support the new parameters regarding IDevID, LDevID, IAK and LAK keys).
- Receive the challenge to prove that is actually has the IDevID, LDevID, IAK and LAK keys.
- Sends challenge response back to the registrar service.
- The agent gets its UUID in case of a successful registering process.
- The main endpoints here are do_register_agent() and do_activate_agent() invoked by the agent. The registration will affect the /v{api_version}/agents/{agent_id} exchange, while the activation will affect the /v{api_version}/agents/{agent_id}/activate endpoint. The specific changes might not happen at the API endpoints, but on the data exchanged and the api_version to support the new information.
- Decode data and parse certificates. This implies modifying the method doRegisterAgent to support new parameters regarding IAK and IDevID. This method exercises a POST to /v{api_version}/agents/{agent_id} at registrar_common.py do_POST method.
- Verify IDevID certificate chain of trust + IAK certificate chain of trust
- Create a challenge to send to the agent for prove the possession of the private keys. It's important to mention that the challenge will change from using Make/ActivateCredential to use TPM2_Certify.
- Receive the challenge response and process
- Load and check the certificates for LAK and LDevID keys with the owner/company's CAs. The certificates should be generated using a separate process.
- Commit data to the local Keylime database, the necessary fields regarding keys and certificates to be included there.
- Activate the agent. This implies modifying the method do_activate_agent at keylime\keylime\registrar_client.py to support new parameters regarding IAK and IDevID. This method exercises a PUT to /v{api_version}/agents/{agent_id}/activate at registrar_common.py do_PUT method.
The work from the verifier perspective can keep using the ephemeral AK or switch between all the possible scenarios mentioned. This is being thought as a multi-step plan and these scenarios will be implemented gradually.
TBD
In case of downgrade: don't use that feature as it will not be available. In case of upgrade: it will be required to use the new API version for this feature.
It is a feature that will be optional to use, but will require a device with IDevID and IAK keys issued by the OEM at its factory.