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.

Thanks,
Dimi

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

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).

Thanks,
Dimi

Dimi

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.

Thanks,
Dimi

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.

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

Thanks,
Dimi

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.

Thanks,
Dimi

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,
Dimi