I have the exactly same issue as https://superuser.com/questions/1404738/tpm-2-0-hardware-error-da-lockout...
TPM2 tools version v1.1
Tried clearing ownership:
linux-host:~ # tpm2_takeownership -c -L lockpass
ERROR: Clearing Failed! TPM error code: 0x921
Tried clearing dictionary lockout:
linux-host:~ # tpm2_dictionarylockout -c -P lockpass
ERROR: 0x921 Error clearing dictionary lockout.
The error id decode says:
linux-host:~ # tpm2_rc_decode 0x921
description: Error produced by the TPM
format 0 warning code
description: authorizations for objects subject to DA protection are not allowed at this time because the TPM is in DA lockout mode
Can't figure out how to get out of this lockout state. Has someone came across same error before? How to fix it? Thanks.
Based on some limited debugging on Windows 10 1809, it appears that Windows does not require the owner auth. Running the application "as administrator" and providing an empty TPM2B_AUTH (with auths.sessionHandle = TPM2_RW_PW) allows me to successfully call functions like...
I've searched through the project's issues but didn't find anything on this topic.
Our team is porting the Linux implementation of the 'tpm-provider' (application interface (wraps tpm2-tss for use with golang) to Windows. On Linux we take ownership of the tpm and specify the owner auth password, which is then used for the tpm2-tss function calls (ex. https://github.com/intel-secl/tpm-provider/blob/64cd53d6fd91b50eb011e1e43...).
My understanding is that taking ownership is not needed on Windows and I've retrieved the "ownerauth" form the Get-Tpm cmdlet. Base64 decoding that value and passing the 20 bytes for owner auth returns 0x9a2 (TPM_RC_BAD_AUTH).
What ownerath value should I pass to tpm2-tss?
Duplicated at https://github.com/tpm2-software/tpm2-tss/issues/1767
I would like to announce tpm2-pkcs11 v1.3.0-RC0, with the following chamngelog:
1.3.0 - 2020-06-29
* C\_CreateObject: Support for CKO\_DATA objects only with CKA\_PRIVATE set to CK\_TRUE.
Token defaults to CK\_TRUE.
* Fix Tests against simulator that support RSA 3072 keys
The release can be found here:
we are currently discussing deprecation of the esys libgcrypt backend, keeping only
openssl and the upcoming mbed-crypto.
If you have any thoughts on that topic, please join the discussion at
I'd like to highlight the command tcti's inclusion into the TSS:
What's really cool, if you have tpm2_send on master post PR 2094:
You can use it to run commands on remote machine. For instance, you can
Run a tpm command over an SSH tunnel on a remote machine to get the
quote. There will be no endianness issues in anything and no worries of
how to transmit the data.
Another great perk, is that if your device node has a too old version
of tpm2-tools, you can just issue a partial update to tpm2_send, or provide
some other command suitable. For most devices, something that
can read and write a file might be useful, not really sure offhand what
that would look like in entirety.
tpm2_getrandom -T "cmd:ssh localhost tpm2_send" --hex 4
> -----Original Message-----
> From: Oleksii Moisieiev <Oleksii_Moisieiev(a)epam.com>
> Sent: Thursday, June 18, 2020 1:21 PM
> To: Struk, Tadeusz <tadeusz.struk(a)intel.com>
> Cc: tpm2(a)lists.01.org
> Subject: [tpm2] Re: Sharing TPM 2.0 between containers with access policy
> Hello Tadeusz.
> Thank you for the answer.
> I've done some investigation and found that passing device /dev/tpmrm0 to the
> containers will do the job. Also problem with tpm_clear can be solved by
> restriction owner access to the tpm. So each container can use keys in TPM but
> talk to owner if any changes is needed.
> I have another question: According to the documentation - TPM is having unique
> endoresement key, embedded to the device during manufacturing. So each
> module can be identified by this key.
> How can I retrieve this key embedded to the TPM module?
Only the endorsement hierarchy primary seed (EPS) is embedded at manufacturing time. So
Calls to tpm2_createprimary with the proper inputs will yield the same key every time. Calls
to tpm2_createek should create this for you. The calls to tpm2_getekcertificate should give you
that manufacturer certificate.
Details on this process can be found in this spec:
> Best regards,
> From: Tadeusz Struk <tadeusz.struk(a)intel.com>
> Sent: Friday, June 5, 2020 8:16 PM
> To: Oleksii Moisieiev <Oleksii_Moisieiev(a)epam.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] Sharing TPM 2.0 between containers with access policy
> On 6/5/20 12:52 AM, Oleksii Moisieiev wrote:
> > Hello all,
> > I have an embedded device, with Docker containers based architecture.
> > This device is operating by software, installed in separate containers.
> > I would like to share TPM2.0 access between this containers with the
> > following restrictions:
> > 1) Forbid Clear TPM command for the containers;
> > 2) Each container should have an access only to the set of keys it owns.
> > 3) Each container can create keys, but not overwrite existing keys
> > that does not related to this container.
> > According to the "TCG TSS 2.0 TAB and Resource Manager Specification"
> > - TPM Resource manager doesn't implement access restrictions right now.
> I think you could run a separate instance of RM in per container to get
> 2 & 3. As for 1, this would need to be prevented on a platform configuration level,
> like in BIOS or equivalent.
On 6/5/20 12:52 AM, Oleksii Moisieiev wrote:
> Hello all,
> I have an embedded device, with Docker containers based architecture.
> This device is operating by software, installed in separate containers.
> I would like to share TPM2.0 access between this containers with the
> following restrictions:
> 1) Forbid Clear TPM command for the containers;
> 2) Each container should have an access only to the set of keys it owns.
> 3) Each container can create keys, but not overwrite existing keys that
> does not related to this container.
> According to the "TCG TSS 2.0 TAB and Resource Manager Specification" -
> TPM Resource manager doesn't implement access restrictions right now.
I think you could run a separate instance of RM in per container to get
2 & 3. As for 1, this would need to be prevented on a platform
configuration level, like in BIOS or equivalent.
Since FAPI is now supported in the latest tss2, I would like to implement
the Attestation protocol using FAPI, I believe basic commands like
create_ek, create_ak, read_manufac_certificate exist in FAPI API, what is
missing is, make credential w/o a TPM chip as most servers don't have tpm
chip. I also don't see Activate Credential.
How can we achieve this in FAPI?