Topics

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

Ken Goldman <kgold@...>
 

On 12/26/2018 10:29 PM, James Bottomley wrote:
On Wed, 2018-12-26 at 19:23 +0000, Doug Fraser wrote:
Does anyone know if tssclear supports hardware PresenceDetect clear?
This isn't a property of the command code (or the actual tssclear
command) but the platform and the TPM configuration.

(I want to wipe the device....)

I can use TPM FW update to move it back to 1.2 FW then back to 2.0
FW, and that will also wipe it, but just wiping with tssclear using
the presence detect would be easier.
I don't know if firmware upgrade is guaranteed - depends on your definition of 'wipe it'. E.g., some (maybe all) TPMs persist the
EKs and EK certificates through 1.2 <-> 2.0 cycles.

Also beware that some TPMs limit the number of 1.2 <> 2.0 cycles. Thus, it's not a good soltion if you're doing this often.

I added the tss users list for better information, but TPM2_Clear()
only requires physical presence (PP) if the TPM2_Clear command is in
the physical presence set list. If it is, tssclear will return
TPM_RC_PP. If it does return this, how you signal physical presence is
very platform dependent. The best way is to clear the TPM from the
BIOS/UEFI because it will be wired in correctly to the PP interface. I
know on most Dell systems, holding F12 while executing the command is
supposed to work, but I've never actually tried it.
Agreed. TPM 2.0 was designed so that platform authorization could
take the place of physical presence hardware. Even with 1.2, I suspect that the command physical presence was more often used.

Finally:

1 - Lockout authorization can be used for TPM2_Clear.

2 - Since both platform and lockout support policies, with enough indirection, you can get whatever you want.

Doug Fraser
 

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?

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?

Douglas Fraser

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

Ken Goldman <kgold@...>
 

On 1/3/2019 3:59 PM, 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?
Way back, the wisdom was to set some group protection (i.e.,
a group of trusted applications) on /dev/tpmxxx.

Using /dev/tpmrm0 protects against an application locking the
TPM and/or using all the resources.

However, even when using /dev/tpmrm0, might one want to protect
against an application extending PCR 10, for example?

Another - does /tpmrm0 protect against an application doing
the write() but never the read(), and thus blocking the device?

Doug Fraser
 

Ken,

In our case, the target is an embedded device and the only active user of TPM (post manufacture install) is the openssl engine, and even then, it is only used during boot and software upgrade.
I suppose someone could make a denial of service attack on that port. The option would be to add user/group tss and make openssl SGID tss.

I'll have to give that some thought.

Thank you for the feedback, this is all new stuff for me.

Douglas Fraser

-----Original Message-----
From: Ken Goldman <kgold@...>
Sent: Thursday, January 3, 2019 7:07 PM
To: Doug Fraser <doug.fraser@...>; James Bottomley <James.Bottomley@...>; openssl-tpm2-engine@groups.io; Ibmtpm20tss-users@...
Subject: Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] ibmtss

On 1/3/2019 3:59 PM, 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?
Way back, the wisdom was to set some group protection (i.e., a group of trusted applications) on /dev/tpmxxx.

Using /dev/tpmrm0 protects against an application locking the TPM and/or using all the resources.

However, even when using /dev/tpmrm0, might one want to protect against an application extending PCR 10, for example?

Another - does /tpmrm0 protect against an application doing the write() but never the read(), and thus blocking the device?

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

James Bottomley
 

On Sun, 2019-01-13 at 16:07 +0000, Doug Fraser wrote:
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.
Well, firstly, volatile keyhandles aren't deterministic (it won't
always be 80000001), but hopefully you already coped with that in your
script.

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.

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@...
rge.net
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

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






Doug Fraser
 

Morning Ken.

I apologize for my mixed up terminology on this topic. If I am using the wrong terms, point it out, and if possible, reference a section in an existing document.
I have been reading like a fiend and porting/coding as I go.

Isn't the openssl engine dynamically loading the tpm key dynamically each time it uses it?
I thought the key that we generated was just related to the internal key for validation reasons to associate the key with that physical initialized TPM?

From an earlier email I sent to James: (direct quote)

====
It gets shoved into a JSON in base64 format for storage on the device.
The device-tree hooks convert that back to native key text format for presentation in /proc space

From device initialization code (runs just once....)

echo "Generating new unit key..."
send_station "Generating new unit key..."

# use the TPM to create the key…
create_tpm2_key -p 81000001 --ecc prime256v1 /tmp/openssl-key.tpm

jq ".unit.\"tpm2_key#\" = \"$(cat /tmp/openssl-key.tpm | base64 -w0)\"" /tmp/upd.json > /tmp/upd-new.json

json2upd.py --json /tmp/upd-new.json --increment --upd "${FLASH}p$UPD_PRI"
dd "if=${FLASH}p$UPD_PRI" "of=${FLASH}p$UPD_BAK" bs=1M
====

So we have a key that we created on our initialized TPM stored into raw device storage, that get instantiated in /proc device space as its own text representation.

It seems to be keeping openssl (via the engine) completely happy at this point.
I have tested by reinitializing the TPM hardware so the key no longer matched the device, and the engine fails, until I go back and generate a new key.

Douglas Fraser

Ken Goldman <kgold@...>
 

On 1/13/2019 11:45 AM, James Bottomley wrote:
On Sun, 2019-01-13 at 16:07 +0000, Doug Fraser wrote:
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.
Well, firstly, volatile keyhandles aren't deterministic (it won't
always be 80000001), but hopefully you already coped with that in your
script.
Just FYI - not recommended because of resource limitations ...

The TPM does have non-volatile key slots. The usual use is
early in boot, when there is no other key storage. These keys
will have fixed handles.

A typical TPM has 7 slots, reserved by convention as follows:

3 for root keys
1 for the platform OEM
3 for OS and applications

James Bottomley
 

On Mon, 2019-01-14 at 14:33 +0000, Doug Fraser wrote:
Morning Ken.

I apologize for my mixed up terminology on this topic. If I am using
the wrong terms, point it out, and if possible, reference a section
in an existing document. I have been reading like a fiend and
porting/coding as I go.

Isn't the openssl engine dynamically loading the tpm key dynamically
each time it uses it? I thought the key that we generated was just
related to the internal key for validation reasons to associate the
key with that physical initialized TPM?
Essentially, yes. The file is reduced to the binary key form which is
kept in memory for the lifetime of the engine (so it's not loading a
file each time). But when you ask for a signature (the only universal
operation), the sequence of TPM commands is

TPM2_Load
TPM2_StartAuthSession
TPM2_Sign
TPM2_FlushContext

So it is loading the key from the memory area each time. This pretty
much corresponds to best practice, even internally to a single
application because you want to keep TPM resources tied up for the
smallest amount of time. In theory it is possible to keep the key and
the session loaded in TPM volatile memory, but this can lead to
resource issues if the application uses more than three keys.

If you're worried about time taken by the TPM operations, then actually
the TPM2_Load isn't the problem one (it's a simple aes128 decryption),
the heavy one is TPM2_StartAuthSession because we use a
cryptographically salted session and that means the TPM has to use the
primary storage key to derive the encrypted salt.

James


From an earlier email I sent to James: (direct quote)

====
It gets shoved into a JSON in base64 format for storage on the
device.
The device-tree hooks convert that back to native key text format for
presentation in /proc space

From device initialization code (runs just once....)

    echo "Generating new unit key..."
    send_station "Generating new unit key..."

    # use the TPM to create the key…
    create_tpm2_key -p 81000001 --ecc prime256v1 /tmp/openssl-key.tpm

    jq ".unit.\"tpm2_key#\" = \"$(cat /tmp/openssl-key.tpm | base64
-w0)\"" /tmp/upd.json > /tmp/upd-new.json

    json2upd.py --json /tmp/upd-new.json --increment --upd
"${FLASH}p$UPD_PRI"
    dd "if=${FLASH}p$UPD_PRI" "of=${FLASH}p$UPD_BAK" bs=1M
====

So we have a key that we created on our initialized TPM stored into
raw device storage, that get instantiated in /proc device space as
its own text representation.

It seems to be keeping openssl (via the engine) completely happy at
this point.
I have tested by reinitializing the TPM hardware so the key no longer
matched the device, and the engine fails, until I go back and
generate a new key.

Douglas Fraser