Skip to content
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

Open
ahllamas opened this issue Nov 16, 2023 · 4 comments
Open

Creating a primary key with the FAPI with an empty "unique" field #2709

ahllamas opened this issue Nov 16, 2023 · 4 comments

Comments

@ahllamas
Copy link

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?

@JuergenReppSIT
Copy link
Member

If you use the tpm2 tool command tpm2_createprimary you can disable the output with the quiet option -Q.

@JuergenReppSIT
Copy link
Member

Sorry I was to fast and didn't read your question correctly.
The unique field is initialized according to EK credential profile for the EK (/HE/EK). If you create a primary signing key in the endorsement hierarchy (e.g. /HE/mykey) with the attributes "user,sign" this initialization is not done.

@ahllamas
Copy link
Author

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?

@JuergenReppSIT
Copy link
Member

JuergenReppSIT commented Nov 21, 2023

I have created a primary signing key with FAPI:
tss2_createkey -p /P_RSA2048SHA256/HE/mykey -t "user,sign"
and with the tpm tools:
tpm2_createprimary -Grsa2048 -C e -c prim.ctx -a "fixedtpm|fixedparent|sensitivedataorigin|userwithauth|sign
In both cases the same public key is produced. The unique field is empty when Esys_CreatPrimary is called.
But if the key has to be recreated (e.g. for tss2_sign) the key is incorrectly created under the storage hierarchy.
I will create a PR to fix this problem.

JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Nov 21, 2023
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>
JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Nov 21, 2023
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>
JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Nov 21, 2023
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>
JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Nov 21, 2023
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>
JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Nov 21, 2023
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>
AndreasFuchsTPM pushed a commit that referenced this issue Nov 30, 2023
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>
jouyouyun pushed a commit to jouyouyun/tpm2-tss that referenced this issue Dec 25, 2023
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>
AndreasFuchsTPM pushed a commit that referenced this issue Jan 30, 2024
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>
JuergenReppSIT added a commit to JuergenReppSIT/tpm2-tss that referenced this issue Mar 21, 2024
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>
AndreasFuchsTPM pushed a commit that referenced this issue Mar 26, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants