OPTIGA™ TPM Forum Discussions

Hello Everyone,

Can anyone give the support for how to use TPM for storing the secure boot keys in imx6/imx8 series platforms. All the suggestions are highly appreciated. Show Less

I am using a SLB9670 TPM (Vendor String: 7.40.2098) module to create a duplicate of a key generated in that same TPM, for the sake of clarity:

- TPM_A: The TPM where I created a key.
- TPM_A_KEY: The key generated in TPM_A that I want to create a duplicate of.
- TPM_B: The TPM where I want to import the duplicate.
- TPM_B_KEY: The ECC P-256 key generated in TPM_B which I want to use to wrap the duplicate create in TPM_A of TPM_A_KEY.

As part of this process, I need to import the public part of TPM_B_KEY in TPM_A, for which I use the LoadExternal TPM command, which allows me to load the external public part (TPM2B_PUBLIC), the private part is set to the empty buffer, TPM_B_KEY has the attributes DECRYPT and RESTRICTED.

In the SLB9670 Module I am unable to do this, I receive a 0x101 error (TPM_RC_FAILURE) and the TPM enters into Failure Mode, unable to process any other commands. In the SLM9670 it works OK, same for Microsoft TPM Simulator, I do not receive any other errors. The TPM2B_PUBLIC structure has no errros, it contains the symmetric algo for wrapping, the public components X and Y...

I am using a HMAC session for the command, but without a session it is also possible to reproduce.

I have also noticed that I am able to import keys with SIGN as the only attribute, but if I try to load it with a session it enters into Failure Mode.

I am able to create the duplicate successfully, import it... with the Microsoft TPM Simulator and also with the SLM9670 (Vendor String: 13.11.4555) module, without any changes in the code.

This all seems quite strange, so I am thinking that perhaps this is an errata or undefined behaviour in the SLB9670 chip, and I was wondering if someone at Infineon would be able to look at this. I can provide TCTI communication traces if required, but I think it should be easy to reproduce, just call LoadExternal with a decrypt/restrict ECC NIST P256 key.

Many thanks for your help. Show Less

We're using the Optiga SLB 9665 TPM with the TBOOT module on Linux. When TBOOT is initializing the NULL hierarchy by calling _tpm20_create_primary() on the TPM_RH_NULL handle, it can take anywhere from 10 to 40 seconds,
as shown in this log snippet:

TBOOT: tboot: supported alg count = 2
TBOOT: tboot: hash alg = 00000004
TBOOT: tboot: hash alg = 0000000B
TBOOT: TPM:CreatePrimary creating hierarchy handle = 40000007
(10 to 40 seconds elapse here)
TBOOT: TPM:CreatePrimary created object handle = 80000000
TBOOT: TPM attribute:
TBOOT: extend policy: 2
TBOOT: current alg id: 0x4
TBOOT: timeout values: A: 750, B: 2000, C: 75000, 😧 750

I'm puzzled as to why the time this takes varies so widely. The longer times are killing us as we have some bootup time deadlines, and the unpredictability complicates things even more. Sometimes it's fast, sometimes it's slow.
There doesn't seem to be any pattern, nor is it influenced by whether the system is starting from a powered-off state or
just a warm reboot. I suspect it may have to do with the TPM trying to gather enough entropy to generate the random number that forms the seed for the NULL hierarchy although that's just a guess. Can anyone from inside
or outside Infineon comment on why the time is so variable? Show Less