Hi Messias,

Our new wolfTPM version 2.2.0 has fix for this error and improved attestation examples.


Make/ActivateCredential examples can now work with EK using the new "-eh" option.

Please find example output below:

dimitartomov@Dimitars-MacBook-Pro wolfTPM % ./examples/keygen/keygen -eh
TPM2.0 Key generation example
    Key Blob: keyblob.bin
    Algorithm: RSA
    Template: AIK
    Use Parameter Encryption: NULL
RSA AIK template
Creating new RSA key...
New key created and loaded (pub 280, priv 222 bytes)
Wrote 508 bytes to keyblob.bin
Wrote 320 bytes to ek.pub
Wrote AK Name digest

dimitartomov@Dimitars-MacBook-Pro wolfTPM % ./examples/attestation/make_credential -eh
Using keys under the Endorsement Hierarchy
Demo how to create a credential challenge for remote attestation
Credential will be stored in cred.blob
wolfTPM2_Init: success
Reading 320 bytes from ek.pub
Reading the private part of the key
Public key for encryption loaded
Read AK Name digest
TPM2_MakeCredential success
Wrote credential blob and secret to cred.blob, 648 bytes

dimitartomov@Dimitars-MacBook-Pro wolfTPM % ./examples/attestation/activate_credential -eh
Use Endorsement Key
Demo how to create a credential blob for remote attestation
wolfTPM2_Init: success
Credential will be read from cred.blob
EK loaded
Reading 508 bytes from keyblob.bin
Reading the private part of the key
AK loaded at 0x80000001
Read credential blob and secret from cred.blob, 648 bytes
TPM2_ActivateCredential success

Hi Messias,

Thank you for reaching out. We can offer a solution.

To use the EK, the TPM requires a Policy Session with Endorsement Auth. This is done using the TPM2_PolicySecret command.

I will try to add an example code for using the EK with Make/ActivateCredential later this week.

In the mean time, you could also try the command in your code.

Let us know if you have more questions.



(6 replies, posted in wolfTPM)

Hi junioarssuncaolp,

I am happy you have creationCertify with wolfTPM working for your use case.

As someone passioned about hardware security, HSM and TPM, I am curious to learn more about what makeCredential+creationCertify offers more compared to makeCredential+ActivateCredential?

We have examples of this under ./example/attestation


Hi Hadrien,

Have you tried running the native tests in wolfTPM?

They provide some of the TPM 2.0 Capabilities in human readable form.

Launch from ./examples/native/native_test

... and scroll up, it is one of the first tests.

We would also welcome a contribution to our GitHub repo. wolfTPM is an open-source software with commercial support. Thus, you could submit a new example with nice prints about the TPM capabilities. It could be ./examples/caps smile

Please note what David highlighted - wolfTPM works with TPM 2.0. Because TPM 1.2 is obsolete and not recommended by the TCG (Trusting Computing Group).




(7 replies, posted in wolfTPM)

Hi Hadrien,

Thank you for following-up.

TPM2_SetupPCRSel indeed has an issue and I submitted a one-line change to fix it.


Now, if someone tries to use pcrIndex outside the allowed range, TPM2_SetupPCRSel will leave pcr->count to zero(0).

The TPM will respond with "TPM2_PCR_Reset failed 0x184: TPM_RC_VALUE: Value is out of range or is not correct for the context". Similar to asking the TPM to use an invalid pcrIndex.

Let us know if you have more questions or feedback. We are happy to help.


(6 replies, posted in wolfTPM)

Hi junioarssuncaolp,

I think one of the command parameters has to be adjusted. Please see my explanation below.

If you have received TPM_RC_SUCCESS from TPM2_CertifyCreation, then the command did succeed. You should have a populated certifyInfo structure and the TPM signature over that structure. Have you checked the data in cmdOut.certifyCreationOut?

typedef struct {
    TPM2B_ATTEST certifyInfo;
    TPMT_SIGNATURE signature;
} Certify_Out;

You could cast the member cmdOut.certifyCreationOut.certifyInfo.attested to TPMS_CREATION_INFO.
This way, you can have easier access to the Name of the RSA key you certified and its creationHash, and you could do a comparison using XMEMCMP. Also, it is important to verify the TPM signature in cmdOut.certifyCreationOut.signature.

About the requirements of a certifyCreation command

  • signHandle should point to a TPM signing key that is loaded.

  • signHandle should point to a different key from the one you are certifying in objectHandle.

For example

cmdIn.certifyCreationIn.signHandle = signingKey.handle;
cmdIn.certifyCreationIn.objectHandle = attestationKey.handle;
/* Use the public part of the signingKey to verify the TPM signature over the certifyCreation output */

Could you please tell a bit more about your use case?
What is the end goal of using CertifyCreation over an Attestation Key?

Let us know if you have more question. We are happy to help.



(7 replies, posted in wolfTPM)

Hi Hadrien,

Thank you for pointing this out.

I was unable to reproduce your crash. When I use pcrIndex above 23, I get TPM_RC_VALUE response from the TPM chip at this line https://github.com/wolfSSL/wolfTPM/blob … ap.c#L2477 and clean exit from the wolfTPM2 wrapper.

At the same time, you are correct that an unitialized digestLen could lead to a XMEMCPY crash. Therefore, I made this change to wolfTPM - https://github.com/wolfSSL/wolfTPM/pull/165

Does this help?



(1 replies, posted in wolfTPM)

Hi Hadrien,

PCR register contains only a hash digest. This hash digest is a computation of the current PCR value and the new one provided using PCR Extend. Typically, PCR registers use SHA256 digests on TPM 2.0. Back in the TPM 1.2 days, the PCR used SHA1 digest, but this is now deprecated (both TPM 1.2 and SHA1).

Could you please clarify what do you mean by "disabled"?

It could be another Windows TBS limitation, because wolfTPM does not have a flag to enable or disable PCR extend.

It could also be related to the TPM locality as David mentioned before.

Maybe these three resources could help understand what are PCR useful for:
- https://opensecuritytraining.info/Intro … nd-att.pdf
- https://developers.tpm.dev/posts/localities
- https://ebrary.net/24811/computer_scien … ty_command

PCRs are useful to verify the state or content of something. I am not sure they are an easy solution to authentication.

For communication authentication using a TPM between a client and a server, I could recommend using our examples/tls server-client demo.


(3 replies, posted in wolfTPM)

Hi Hadrien,

The benefit of working with the TPM simulator is that the code you write using wolfTPM will be exactly the same when you switch to a physical, dedicated TPM chip on the real hardware.

Please let me know if you have more questions.



(3 replies, posted in wolfTPM)

Hi Hadrien,

Typically, symmetric key operations are restricted on TPM due to export regulations(law).

However, you could still develop and test these operations using a TPM Simulator.

Please check out our documentation for how to develop using a TPM simulator - https://github.com/wolfSSL/wolfTPM/blob … s/SWTPM.md



(5 replies, posted in wolfTPM)

Hi Hadrien,

I can confirm everything that David explained.

The only extra suggestion I could make is to use ECC instead of RSA, because it is faster.

One detail: Although the TPM is not a cryptographic accelerator, all cryptographic operations for a primary key happen inside the TPM. Therefore, it depends on the TPM model/vendor what is the cryptographic performance. Your PC's performance is not to be blamed  wink



(1 replies, posted in wolfTPM)

Hi Et,

We just added preliminary support for CubeMX I2C HAL in tpm_io.c

Please clone and try the code in this PR - https://github.com/wolfSSL/wolfTPM/pull/142

To enable CubeMX I2C HAL:

1. wolfTPM must be build using `--enable-i2c`
2. Your OpenSTM or STM32IDE project should have the following define in its project settings: `WOLFSSL_STM32_CUBEMX`

Let us know if you have further questions.


Hi Petr,

I did some more research on the topic and would be best if we could get on a call to discuss the details.

In nutshell:
- Combined key, with both decrypt and signing set, indeed can not be restricted
- However, Attestation keys are recommended to be restricted, but the TPM does accept non-restricted, fixed TPM, fixed Parent key for attestation purposes

Please let me know if it is okay to contact you over email and set up a call.


Hi Petr,

Thank you for the detailed information.

I will have to check about the NULL signature scheme for combined keys. This could be a recommendation by the TCG rather than a restriction. In the mean time, could you please tell us for context on what systems (devices) this will be used?

Best Regards,

Hi again Petr,

Today there was a TPM.dev weekly call and got the following idea: You could have Attestation Key under the Owner Hierarchy. That key does not have to be restricted for signing only. It can be for decrypt and signing. Then, you could/should be able to use it for TPM2_RSA_Decrypt as well.

The above would be useful, if you are not obligated to respect the TCG provisioning guides. Because indeed Attestation Keys are expected to be restricted for signing, however TPM2_Quote would work with (almost) any key for signing, including key with signing and decryption capabilities.

Hope this information helps and please share more information about your scenario.

Dimitar Tomov, wolfSSL

Hi Petr,

There are two aspects to your question.

First, a TPM2.0 Attestation Key (or TPM1.2 Attestation Identity Key) has restricted usage only for signing TPM generated data.

Second, any TPM key that is a restricted key (TPMA_OBJECT_restricted) and for signing (TPMA_OBJECT_sing) can not be used for decryption.

Therefore, if we use a TPM key for signing, when using TPM2_RSA_Decrypt that would indeed fail.

If I understand you correctly, you would want to use one TPM key for both Identification and decryption(CSR/TLS). Is my understanding correct and could you please share more details about your concrete need, scenario?

Dimitar Tomov, wolfSSL