Proposal 81: Adding support for IDevID and IAK #82
Conversation
81-IDevID_and_IAK_support.md
Outdated
| --> | ||
| 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 check 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 (not a Primary Key). |
There was a problem hiding this comment.
The private part of an EAK is generally exportable encrypted, so that it can be reimported into the TPM but not used anywhere else.
There was a problem hiding this comment.
Ok, comment added to include this info.
81-IDevID_and_IAK_support.md
Outdated
| Adding support for IDevID and IAK as an option to the Keylime registrar and verifier services, to the RUST agent, will allow 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. | ||
|
|
||
| If required, it would be possible to send a challenge (nonce) to a node agent to prove it owns the TPM protected private IAK key. A nonce challenge to make sure that the node can access the IAK private key is not mandatory but would be good just for avoiding registering a node that is invalid (does not have access to the private key related to the certificate provided). Even without this, the node would not be able to attest later. |
There was a problem hiding this comment.
Here the idea of why an EAK is still required when there is an IAK should be extended.
There was a problem hiding this comment.
Ok, a new paragraph was added regarding this point, please check if it explains your point.
81-IDevID_and_IAK_support.md
Outdated
|
|
||
| If required, it would be possible to send a challenge (nonce) to a node agent to prove it owns the TPM protected private IAK key. A nonce challenge to make sure that the node can access the IAK private key is not mandatory but would be good just for avoiding registering a node that is invalid (does not have access to the private key related to the certificate provided). Even without this, the node would not be able to attest later. | ||
|
|
||
| Finally, further planning will be required on how the IAK certificates will be accepted. The registrar service will need to be configured with a set of trusted CA certificates for validating IAK certificates in order to support a multi-OEM environments. |
There was a problem hiding this comment.
I think this proposal should include how the validation is done.
There was a problem hiding this comment.
Agreed, still working on this point, will update the PR soon
81-IDevID_and_IAK_support.md
Outdated
| 2. Get endorsement certificate from TPM NV index and EK public key (done at create_ek) | ||
| 3. Regeneration of IAK and IDevID possible info (create create_iak and create_idevid routines) | ||
| 4. 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 | ||
| 5. Create keys for LAK and LDevID based on the IAK. |
There was a problem hiding this comment.
Ideally we do not want to recreate the LAK and LDevID every time. So we should try to load them from disk if they are there.
There was a problem hiding this comment.
Same action as above with WIP, will update the PR soon
There was a problem hiding this comment.
I only got to read it briefly, but I think the general points on how this integration should are now clear 👍.
@mpeters @maugustosilva can you also have a look at it?
81-IDevID_and_IAK_support.md
Outdated
| 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. | ||
|
|
||
| If required, it would be possible to send a challenge (nonce) to a node agent to prove it owns the TPM protected private IAK key. A nonce challenge to make sure that the node can access the IAK private key is not mandatory but would be good just for avoiding registering a node that is invalid (does not have access to the private key related to the certificate provided). Explicit proof of possesion 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. |
There was a problem hiding this comment.
I would like if we change that to a hard requirement, so that we know that only correct agents have registered.
There was a problem hiding this comment.
Ok, the text was modified to address that purpose and it was mentioned the EAK and the IAK cases.
81-IDevID_and_IAK_support.md
Outdated
| 9. The agent gets its UUID in case of a successful registering process. | ||
|
|
||
| ### Registration from the registrar service perspective when interacting with the agent | ||
| 1. The main endpoints here are do_register_agent() and do_activate_agent() invoked by the agent. |
There was a problem hiding this comment.
Please explicitly state what in the API changes because I think we need to increase the API version in order to support this.
There was a problem hiding this comment.
I updated this point partially, will check and work more here.
There was a problem hiding this comment.
Similar to the testing. We should include this in the document, but we can also add that later.
| All code is expected to have adequate tests (eventually with coverage | ||
| expectations). | ||
| --> | ||
| TBD |
There was a problem hiding this comment.
Add unit tests where possible and otherwise instructions on how to integrate it into our e2e test suite.
There was a problem hiding this comment.
Still working here, will update soon on this topic.
There was a problem hiding this comment.
We can add that section later. Just make sure that the actual implementation is easily testable.
gustavobbrand
requested review from
THS-on
and removed request for
mpeters,
galmasi,
maugustosilva and
lukehinds
81-IDevID_and_IAK_support.md
Outdated
| This section is for explicitly listing the motivation, goals and non-goals of | ||
| this enhancement. Describe why the change is important and the benefits to users. | ||
| --> | ||
| 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. |
There was a problem hiding this comment.
nit: identity". The initially (two spaces)
81-IDevID_and_IAK_support.md
Outdated
| --> | ||
| 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). |
There was a problem hiding this comment.
nit: “malicious endpoint” are not ASCII quotes (comes pbly from C&P, I do that a lot)
There was a problem hiding this comment.
ok, fixed the ASCII quotes.
81-IDevID_and_IAK_support.md
Outdated
| This section is for explicitly listing the motivation, goals and non-goals of | ||
| this enhancement. Describe why the change is important and the benefits to users. | ||
| --> | ||
| 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. |
81-IDevID_and_IAK_support.md
Outdated
|
|
||
| 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 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. |
There was a problem hiding this comment.
nit: and in case there is no -> and in case when there is no?
|
|
||
| How will security be reviewed and by whom? | ||
| --> | ||
| The risk involved at this proposal is increasing the configuration complexity and by enabling using different chains of trust for the IDs. |
There was a problem hiding this comment.
The configuration files are under a big improvement right now. Do you have an idea of how would be the new configuration fields, and where should be placed?
There was a problem hiding this comment.
This is currently work in progress. Let me review the latest changes that are ongoing about the config files to get back to this point. A good moment to review this might be on the first PR with some code (which will not contain all the use cases, but incrementally deliver the content listed here).
| ### Registration from the agent perspective when interacting with the registrar service. | ||
| 1. Create session (done at get_tpm2_ctx) | ||
| 2. Get endorsement certificate from TPM NV index and EK public key (done at create_ek) | ||
| 3. 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. |
There was a problem hiding this comment.
Sorry about my ignorance, are not the I{AK,DevID} already present in NV index? Why should be regenerated?
There was a problem hiding this comment.
They can be present, but in case they are not they can be regenerated based on a standard template specified by TCG.
| 2. Get endorsement certificate from TPM NV index and EK public key (done at create_ek) | ||
| 3. 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. | ||
| 4. 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 | ||
| 5. 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. |
There was a problem hiding this comment.
"load them" means allocate them in the NV of the TPM? Is this resource not scarce and recommended not to be used?
There was a problem hiding this comment.
Again, bear with my lack of knowledge (I take this opportunity to learn). If I{AK,DevID} are not present, is it possible to crate the L versions? If so, how the data for the DevID part is generated?
There was a problem hiding this comment.
Regarding the first point, I have to recall the exact commands, but if I am not mistaken you can load for use it and then unload for save resources.
About the second point, in case IAK and IDevID are not present the Local keys can be generated according to the 3rd scenario that was mentioned, which includes info about the 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.
You can also find at the item 5.5 of [2] the generation of LAK and LDevID by the user/client: "This use case uses the owner installed LAK to prove that the new LDevID key is in the same TPM as the LAK and
therefore is on the device identified in the LAK certificate. Note that the assurance provided using this method
depends on the trustworthiness of the CA issuing the LAK certificate".
81-IDevID_and_IAK_support.md
Outdated
| --> | ||
| 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). |
There was a problem hiding this comment.
ok, fixed the ASCII quotes.
81-IDevID_and_IAK_support.md
Outdated
|
|
||
| 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 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. |
|
|
||
| How will security be reviewed and by whom? | ||
| --> | ||
| The risk involved at this proposal is increasing the configuration complexity and by enabling using different chains of trust for the IDs. |
There was a problem hiding this comment.
This is currently work in progress. Let me review the latest changes that are ongoing about the config files to get back to this point. A good moment to review this might be on the first PR with some code (which will not contain all the use cases, but incrementally deliver the content listed here).
| ### Registration from the agent perspective when interacting with the registrar service. | ||
| 1. Create session (done at get_tpm2_ctx) | ||
| 2. Get endorsement certificate from TPM NV index and EK public key (done at create_ek) | ||
| 3. 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. |
There was a problem hiding this comment.
They can be present, but in case they are not they can be regenerated based on a standard template specified by TCG.
| 2. Get endorsement certificate from TPM NV index and EK public key (done at create_ek) | ||
| 3. 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. | ||
| 4. 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 | ||
| 5. 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. |
There was a problem hiding this comment.
Regarding the first point, I have to recall the exact commands, but if I am not mistaken you can load for use it and then unload for save resources.
About the second point, in case IAK and IDevID are not present the Local keys can be generated according to the 3rd scenario that was mentioned, which includes info about the 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.
You can also find at the item 5.5 of [2] the generation of LAK and LDevID by the user/client: "This use case uses the owner installed LAK to prove that the new LDevID key is in the same TPM as the LAK and
therefore is on the device identified in the LAK certificate. Note that the assurance provided using this method
depends on the trustworthiness of the CA issuing the LAK certificate".
| All code is expected to have adequate tests (eventually with coverage | ||
| expectations). | ||
| --> | ||
| TBD |
gustavobbrand
force-pushed
the
master
branch
from
0581803
to
b897ead
Compare
Signed-off-by: Gustavo Brand <gustavo.brand@hpe.com>
gustavobbrand
force-pushed
the
master
branch
from
b897ead
to
02da8c2
Compare
This enhancement proposes leveraging the IDevID and IAK keys/certificates to register each device at the registrar service and enable attestation based on the IAK instead of using an ephemeral AK (Attestation key). IDevID is an industry standard identity which is issued by manufacturers when the device is built.