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

tpm2_getekcertificate should support values stored in high range (NVRAM) #3435

Closed
loicsikidi opened this issue Nov 25, 2024 · 4 comments · Fixed by #3440
Closed

tpm2_getekcertificate should support values stored in high range (NVRAM) #3435

loicsikidi opened this issue Nov 25, 2024 · 4 comments · Fixed by #3440

Comments

@loicsikidi
Copy link
Contributor

By default, tpm2_getekcertificate search EK cert in NVRAM (if there is no search ARGUMENT).

The latest TCG spec encourages vendors to support ECC P384 and RSA 3072 EK certificates, as stated below:

1. If the TPM is pre-provisioned with EK Certificates, it SHALL be provisioned with EK Certificates for an RSA
EK and an ECC EK.
    a. The TPM MAY include an EK Certificate for an RSA 3072-bit key.
    b. The TPM SHALL be provisioned with either an ECC P384 EK Certificate or an RSA 3072-bit EK
    Certificate.
    c. All Certificates SHALL comply with the definition in the TCG EK Credential Profile for TPM Family
    2.0 [14]. 

source: 4.5.2.1 Pre-provisioned EK Certificates

The latest TCG Credential Profile EK 2.0 defines where the newest algorithms must be stored (ie. High Range):

The handle values are normative as of version 2.3 of this specification. Defining the NV
index handles as normative simplifies EK certificate validation because it eliminates parsing of
certificate content in order to identify the algorithm (RSA or ECC) and key/curve size.

      0x01c00012 RSA 2048 EK Certificate (H-1)
      0x01c00014 ECC NIST P256 EK Certificate (H-2)
      0x01c00016 ECC NIST P384 EK Certificate (H-3)
      0x01c00018 ECC NIST P521 EK Certificate (H-4)
      0x01c0001a ECC SM2_P256 EK Certificate (H-5)
      0x01c0001c RSA 3072 EK Certificate (H-6)
      0x01c0001e RSA 4096 EK Certificate (H-7)

source: 2.2.1.5 High Range

It seems that the current implementation of tpm2_getekcertificate only search in Low Range (see code here). The tool should also support High Range values in order to comply with the latest version of TCG spec.

PS: I'm willing to do a PR on this issue if this ticket is relevant to maintainers.

@dzogrim
Copy link

dzogrim commented Nov 25, 2024

Thank you for bringing up this topic.

The points you raised align with the latest TCG specifications, and I completely agree that supporting High Range handles in tpm2_getekcertificate is crucial for compliance and broader compatibility with modern TPM configurations.

Including these High Range values, particularly for RSA 3072 and ECC P384 EK certificates, would not only ensure adherence to the specifications but also improve the tool’s usability for scenarios where vendors provision certificates as specified in TCG EK Credential Profile 2.0.

It would be great if the maintainers could share their thoughts or confirm whether a contribution in this direction would align with the project’s priorities.
Looking forward to hearing from the maintainers on this!

@JuergenReppSIT
Copy link
Member

JuergenReppSIT commented Nov 25, 2024

Currently only FAPI supports high range certificates. For instance after provisioning with the P_ECCP384SHA384 profile you can get the EK certificate with:
tss2_getcertificate -p /P_ECCP384SHA384/HE/EK -o ek_cert.pem
Or just read the certificate with:
tpm2_nvread 0x1C00016 -o ek_cert.der
@loicsikidi a PR for the tool command tpm2_getekcertificatewould be welcome.

@loicsikidi
Copy link
Contributor Author

Great @JuergenReppSIT!

I'll submit something by the end of the week ;)

@loicsikidi
Copy link
Contributor Author

@JuergenReppSIT if you could take a look to the PR #3440 💪

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

Successfully merging a pull request may close this issue.

3 participants