-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating a primary key with the FAPI with an empty "unique" field #2709
Comments
If you use the tpm2 tool command |
Sorry I was to fast and didn't read your question correctly. |
I tried doing this and still the unique field being populated for both "restricted, sign, user" and "user, sign". So, the FAPI assumes that any primary key under HE is an EK? |
I have created a primary signing key with FAPI: |
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation keys under the endorsement hierarchy. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys under the endorsement hierarchy. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: #2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: #2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: tpm2-software#2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
In several cases the wrong handle TPM2_RH_EK was used instead of TPM2_RH_ENDORSEMENT. This caused a wrong recreation of keys (except the EK) under the endorsement hierarchy. Now the correct hierarchy handle is used and a check whether the recreated public key of the recreated primary corresponds to the keystore. Addresses: #2709 Signed-off-by: Juergen Repp <juergen_repp@web.de>
I'm trying to create the keys based on the TCG specification: https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf
When creating a primary signing key under the endorsement hierarchy the unique field gets populated automatically. Is there any way to disable this behavior?
The text was updated successfully, but these errors were encountered: