Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] ibmtss
On Sun, 2019-01-13 at 16:07 +0000, Doug Fraser wrote:toggle quoted message. . .
James, Ken,Well, firstly, volatile keyhandles aren't deterministic (it won't
always be 80000001), but hopefully you already coped with that in your
We store the blob in a raw partition and it gets loaded into /proc atI think this means you use TPM2_Create to produce the blob and
TPM2_Load to load it into the TPM. The handle you get on TPM2_Load is
the 80000001 (or something different above).
Since the blob is intimately tied to the physical key, we are notThat's right. All an openssl engine key is is an ASN.1 wrapping of the
blob such that the blob key is stored along with information about it,
so really what you're doing is open coding openssl key generation and
probably you don't need to know the additional information that would
be encoded with the latter.
Right now, it is all working fine. It all went about as smoothly as IWell, presumably this was an early version of the Intel TSS on an older
kernel. In the "just get it working" phase, both TSSs worked directly
on the volatile key space. However, what you'll find now is that they
both use a resource manager to virtualize the volatile key space (it's
too small to allow for multiple users). TPM2_Load still works, but
you'll likely get back a different handle (80ffffff most likely from
the in-kernel resource manager). The other property about resource
managed volatile keys is that they only now last the lifetime of the
resource manager connection (for the in-kernel RM this is the file
descriptor used to open /dev/tpmrm0), so if you want to use them across
multiple processes, you have to reload the key.
All of this is why key files for the TPM2 engine exist: The key must
be persistent (actually across reboots as well as different processes)
and used efficiently within the single process resource manager domain.
I am continuing to learn, which has made this such an engaging career