I would like to announce the following release of tpm2-tools 4.1.3 with the following changes:
4.1.3 - 2020-06-02
* tpm2\_create: Fix issue with userauth attribute being cleared if policy is specified.
The release can be found here:
I am using the tpm2 tools combination below:
After initial installation, I got an error when running tpm2_nvreadpublic. (installation sequence tss -> abrmd -> tools)
Could anyone please let me know how I can resolve this issue? thank you so much in advance.
** (process:3426476): CRITICAL **: 23:52:45.971: CreateConnection expected to return 1 handles, received 2
WARNING:tcti:src/tss2-tcti/tctildr.c:62:tcti_from_init() TCTI init for function 0x7f5a0003da10 failed with a0001
WARNING:tcti:src/tss2-tcti/tctildr.c:92:tcti_from_info() Could not initialize TCTI named: tcti-abrmd
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:150:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-tabrmd.so.0
if I do a restart "service tpm2-abrmd restart", then this issue can be resolved. I would like to resolve this without using the workaround.
Sorry for what might be an obvious question ...
What is the right command sequence to destroy keys, despite the users
possibly still having context files?
I read something about resetting the seed for a hierarchy through the
TPM2_Clear operation (presumably the tpm2_clear command can do this).
But that is too drastic.
I just want to kill off a single key and make it not usable. If I kill
off a parent presumably I can destroy a whole tree of keys. But that
just moves the problem, potentially up to a primary key.
What is the right way to do this?
I suppose there is some trick whereby you make a policy not able to be
satisfied. But then it seems you still need to retain state to prevent
the key from being used. I would rather just have all the key state be
gone and not able to be recreated.
Ted H. Kim, PhD
I was wondering if someone has ideas about integrating the TPM with
Recently I started looking into supporting Secure Device Connection
Protocol (SDCP, ) in libfprint. The general idea is to verify that
the Fingerprint reader can be trusted, but I initially also imagined
that further use-cases like unsealing data in a TPM may be possible
(e.g. to retrieve disk encryption keys).
However, looking into it more, my current conclusion is that there is
little to no advantage to use the TPM. At least not unless one also has
a trusted (userspace) program which is capable of signing TPM
authorizations. One could easily offload the required parts into a
small helper, but that may require ensuring it runs in a trusted
Microsoft seems to run relevant parts as trustlets that are walled off
from the rest of the system. That seems sensible to me, but it also
means requiring all the infrastructure for execution and signing and I
doubt that is feasible currently.
Right now I'll probably go the way of not using the TPM at all. But I
am really not an expert for this. So should someone see scenarios where
a TPM is actually helpful in this context, then I would like to hear
PS: A quick summary of how SDCP works:
* Device has a private ECC key that signs the firmware and ephemeral
keys during boot (and is inaccessible afterwards)
* A certificate proofs that this key was provisioned in factory
* Device builds a shared secret with the host (s)
* Device sends id, HMAC_SHA256(s, "identify" || nonce || id)
when the finger "id" was presented.
* The HMAC proofs knowledge of the shared secret and authorizes the