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

James Bottomley
 

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.