Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] ibmtss

Doug Fraser
 

James, Ken,

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.
We store the blob in a raw partition and it gets loaded into /proc at boot through FDT via u-boot.
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.

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.

I am continuing to learn, which has made this such an engaging career for the last thirty-five years!

Cheers,

Douglas Fraser

-----Original Message-----
From: openssl-tpm2-engine@groups.io <openssl-tpm2-engine@groups.io> On Behalf Of James Bottomley
Sent: Thursday, January 3, 2019 4:14 PM
To: openssl-tpm2-engine@groups.io; 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.

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 SUID
tss


Is this inherently wrong-headed to be working this way?
/dev/tpm0 runs without the kernel resource manager, so, 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?

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 a
TPM2 ECC key directly, not a wrapped PEM file.
It works fine that way for my use case, but is there I reason why I
would prefer the other method?
I take it you mean you have a persistent key and you refer to it via 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.

James

Join openssl-tpm2-engine@groups.io to automatically receive all group messages.