On Sun, 2019-01-13 at 16:07 +0000, Doug Fraser wrote:
Thanks again for your help and feedback. I am learning this all at a
brisk pace. This past fall was my introduction to TPM as anything
other than a technology buzz word.
James, we are using a TPM key blob from create_tpm2_key that is tied
to a fixed key at 80000001.
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 at
boot through FDT via u-boot.
I 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 not
concerned with that exposure, and the openssl engine can reference
the blob from /proc space directly, which is fast.
That'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 I
could have hoped being that we started with Intel TSS and slid over
to IBM TSS as a result of the first email I traded with James.
Well, 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
for the last thirty-five years!
From: firstname.lastname@example.org <email@example.com>
On Behalf Of James Bottomley
Sent: Thursday, January 3, 2019 4:14 PM
To: firstname.lastname@example.org; Doug Fraser <doug.fraser@...>
; Ken Goldman <kgold@...>; Ibmtpm20tss-users@...
Subject: Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] ibmtss
On Thu, 2019-01-03 at 20:59 +0000, Doug Fraser wrote:
Hello All./dev/tpm0 runs without the kernel resource manager, so,
On UDEV rules....
(depending on where I search, different answers)
I am currently setting both /dev/tpm0 and /dev/tpmrm0 to mode 0666
I don't care who the owner or group is, since I am not running
Is this inherently wrong-headed to be working this way?
realistically, it should never be used (if you do use it you can get
out of memory errors from the TPM) if something else is using the
resource manager or you have more than one application using the TPM.
The safe course, I think, is only ever to use the /dev/tpmrm0. I
usually run with /dev/tpm0 0600 and /dev/tpmrm0 0666. The Intel TSS
tends to run with /dev/tpm0 and /dev/tpmrm0 set to 0660 meaning that
only members of the tpm group can access TPM functions.
How about for openssl-engine?I take it you mean you have a persistent key and you refer to it via
Thanks all. It is working in this use case (mode 0666 on both) and
openssl is happy.
An optional 'use case' question. For the openssl engine, I am using
TPM2 ECC key directly, not a wrapped PEM file.
It works fine that way for my use case, but is there I reason why
would prefer the other method?
the //nvkey: prefix? There are several reasons for using files
instead of nv based keys, the main one being nv keys require a unique
nv index, so arbitrating who gets what index in a multi app situation
becomes complex fast, plus for large numbers of keys you'll likely
run out of nv index space. The second reason for using files is
because you want to associate policy with a key (like expiring keys
or certain PCR values). Without a file to explain to the openssl-
tpm2-engine what the policy is, you won't get it to work.