Date   
Re: TSS aligned with TPM2 engine

James Bottomley
 

On Mon, 2019-01-21 at 12:01 +0100, Fredrik Ternerot wrote:
On Mon, Jan 14, 2019 at 3:38 PM James Bottomley
<James.Bottomley@...> wrote:

On Mon, 2019-01-14 at 14:47 +0100, Fredrik Ternerot wrote:
On Sat, Dec 22, 2018 at 7:21 PM James Bottomley
<James.Bottomley@...> wrote:

On Fri, 2018-12-21 at 15:22 +0000, Doug Fraser wrote:
[...]
On to openssl-tpm2-engine:

I had to make one small change to openssl-tpm2-engine before
running bootstrap/configure prior to the build.
Right after pulling the git tree, at the top of the tree I
do:

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am

This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot
execute
`create_tpm2_key --help` on the build host to extract the
document.

It would be helpful if there were a configure option to block
documentation generation completely.
Well, as I said, I've never actually done a cross
compile. However, leafing through the somewhat confusing
automake documentation on cross compiles, I think this is the
fix.
I can confirm that this solves the problem with help2man for me.

The changes in configure.ac are present in the latest commit
(b43aa97 Version: 2.1.1). Would you mind to add the changes in
Makefile.am as well?
Heh, well, I was supposed to be keeping that local to my tree until
someone tested it, but it must have got partially pushed with the
version update. Thanks for testing, I've added a commit for the
rest of the Makefile stuff. Note, I don't think this is
sufficient, but like I said I got out of cross compiling ages ago
mainly because of the need to run make check, so I only use
emulation containers nowadays, so I'm betting there will be other
issues.
You are right, another issue is the detection of enginesdir in
configure.ac. This is done by generating a test program that is
compiled and executed, which doesn't work when cross compiling. Do
you know any other ways to do it?
Yes, we can use pkg-config to get that. The reason we didn't before is
that openSUSE actually had the wrong directory in the openssl.pc file
(so you couldn't build working engines on openSUSE unless you detected the engines directory yourself). They've since fixed this as a bug and it should now work on all distributions.

James

Re: TSS aligned with TPM2 engine

Fredrik Ternerot
 

On Mon, Jan 14, 2019 at 3:38 PM James Bottomley
<James.Bottomley@...> wrote:

On Mon, 2019-01-14 at 14:47 +0100, Fredrik Ternerot wrote:
On Sat, Dec 22, 2018 at 7:21 PM James Bottomley
<James.Bottomley@...> wrote:

On Fri, 2018-12-21 at 15:22 +0000, Doug Fraser wrote:
[...]
On to openssl-tpm2-engine:

I had to make one small change to openssl-tpm2-engine before
running
bootstrap/configure prior to the build.
Right after pulling the git tree, at the top of the tree I do:

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am

This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot
execute
`create_tpm2_key --help` on the build host to extract the
document.

It would be helpful if there were a configure option to block
documentation generation completely.
Well, as I said, I've never actually done a cross
compile. However,
leafing through the somewhat confusing automake documentation on
cross
compiles, I think this is the fix.
I can confirm that this solves the problem with help2man for me.

The changes in configure.ac are present in the latest commit (b43aa97
Version: 2.1.1). Would you mind to add the changes in Makefile.am as
well?
Heh, well, I was supposed to be keeping that local to my tree until
someone tested it, but it must have got partially pushed with the
version update. Thanks for testing, I've added a commit for the rest
of the Makefile stuff. Note, I don't think this is sufficient, but
like I said I got out of cross compiling ages ago mainly because of the
need to run make check, so I only use emulation containers nowadays, so
I'm betting there will be other issues.
You are right, another issue is the detection of enginesdir in
configure.ac. This is done by generating a test program that is
compiled and executed, which doesn't work when cross compiling. Do you
know any other ways to do it?

Thanks,
Fredrik

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

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




Re: TSS aligned with TPM2 engine

James Bottomley
 

On Mon, 2019-01-14 at 14:47 +0100, Fredrik Ternerot wrote:
On Sat, Dec 22, 2018 at 7:21 PM James Bottomley
<James.Bottomley@...> wrote:

On Fri, 2018-12-21 at 15:22 +0000, Doug Fraser wrote:
[...]
On to openssl-tpm2-engine:

I had to make one small change to openssl-tpm2-engine before
running
bootstrap/configure prior to the build.
Right after pulling the git tree, at the top of the tree I do:

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am

This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot
execute
`create_tpm2_key --help` on the build host to extract the
document.

It would be helpful if there were a configure option to block
documentation generation completely.
Well, as I said, I've never actually done a cross
compile.  However,
leafing through the somewhat confusing automake documentation on
cross
compiles, I think this is the fix.
I can confirm that this solves the problem with help2man for me.

The changes in configure.ac are present in the latest commit (b43aa97
Version: 2.1.1). Would you mind to add the changes in Makefile.am as
well?
Heh, well, I was supposed to be keeping that local to my tree until
someone tested it, but it must have got partially pushed with the
version update. Thanks for testing, I've added a commit for the rest
of the Makefile stuff. Note, I don't think this is sufficient, but
like I said I got out of cross compiling ages ago mainly because of the
need to run make check, so I only use emulation containers nowadays, so
I'm betting there will be other issues.

James

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

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

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

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

Re: TSS aligned with TPM2 engine

Fredrik Ternerot
 

On Sat, Dec 22, 2018 at 7:21 PM James Bottomley
<James.Bottomley@...> wrote:

On Fri, 2018-12-21 at 15:22 +0000, Doug Fraser wrote:
[...]
On to openssl-tpm2-engine:

I had to make one small change to openssl-tpm2-engine before running
bootstrap/configure prior to the build.
Right after pulling the git tree, at the top of the tree I do:

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am

This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot execute
`create_tpm2_key --help` on the build host to extract the document.

It would be helpful if there were a configure option to block
documentation generation completely.
Well, as I said, I've never actually done a cross compile. However,
leafing through the somewhat confusing automake documentation on cross
compiles, I think this is the fix.
I can confirm that this solves the problem with help2man for me.

The changes in configure.ac are present in the latest commit (b43aa97
Version: 2.1.1). Would you mind to add the changes in Makefile.am as
well?

Thanks,
Fredrik


James

---

diff --git a/Makefile.am b/Makefile.am
index 8c24dbe..7d3b645 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,8 +1,11 @@
-EXTRA_DIST = README openssl.cnf.sample create_tpm2_key.1
+EXTRA_DIST = README openssl.cnf.sample

+if NATIVE_BUILD
+EXTRA_DIST += create_tpm2_key.1
man1_MANS = create_tpm2_key.1

CLEANFILES = $(man1_MANS)
+endif

openssl_engine_LTLIBRARIES=libtpm2.la
bin_PROGRAMS=create_tpm2_key
diff --git a/configure.ac b/configure.ac
index ea544ea..a96206c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,6 +4,8 @@

AC_INIT(openssl-tpm2-engine, 2.1.0, <James.Bottomley@...>)
AM_INIT_AUTOMAKE(1.6.3)
+AC_CANONICAL_HOST
+AM_CONDITIONAL(NATIVE_BUILD, test "x$cross_compiling" = "xno")

AM_MISSING_PROG(HELP2MAN, help2man)



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

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






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

TSS data dir permission problem

Fredrik Ternerot
 

Hi,

there is a problem with permission on the libibmtss data directory
(TPM_DATA_DIR) when the engine is used by a service (like Apache
httpd) that loads the key as root but uses the key as another user. In
this case, the data dir is created by the engine at the time when the
key is loaded, and thus root becomes the owner of the dir, and then
later when the other user is trying to use (create files in) this dir
it will fail due to access restrictions.

One possible solution would be to simply allow any user to create
files in this directory by chmod 0777 at creation time (
tpm2_set_unique_tssdir()). Since any sensitive data in this dir is
encrypted it may be an acceptable solution.

Another solution would be to allow the service that are using the
engine to decide on the group ownership for this directory, e.g. by
setting an environment variable with the group name before loading the
key. If the environment variable is set, the engine chown to the new
group and chmod 0770. This is a bit more complex but would keep the
current behaviour when running as the same user all the time (and
hence not setting the environment variable). One drawback with this
solution is that the user of the engine needs to know about it and
actually get the service to set the environment variable.

What do you think? Are there any better options on how to handle this?

Fredrik Ternerot

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

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?

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

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?

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

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

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

Re: [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.

Re: ibmtss

James Bottomley
 

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 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.

James

Thanks......

Douglas Fraser

-----Original Message-----
From: Doug Fraser
Sent: Friday, December 21, 2018 4:45 PM
To: Fredrik Ternerot <fredrik.trot@...>
Cc: openssl-tpm2-engine@groups.io
Subject: RE: [openssl-tpm2-engine] TSS aligned with TPM2 engine

I am doing this between my ibmtss build and my openssl_tpm2_engine
build....
This gets me the proper path, then I hand install using my own
makefile.
I tried editing the configured Makefile using the results of this,
but it still does some strange things with libtool that blows it up,
so I hand install the output to the target after the build.

This *should* work with any installed version of opensll.
Feel free to pick away at parts of this if they are useful at all.

Douglas Fraser

# For OPENSSL TPM2 Engine, we need to know where the installed
OpenSSL # is going to look for its engines.
# We do that by cross building this little application and running it
# in chroot, and then extracting the string that it spits out.
rm -f enginesdir
rm -f openssl_engine_path.c
cat <<PATH_TEST >openssl_engine_path.c
#define HEADER_CRYPTLIB_H
#include <openssl/crypto.h>
#include <stdio.h>
int
main ()
{
#if OPENSSL_VERSION_NUMBER < 0x10100000
puts(ENGINESDIR);
#else
puts(OpenSSL_version(OPENSSL_ENGINES_DIR));
#endif

;
return 0;
}
PATH_TEST

# Cross compile directly to /tmp on chroot install top.
if ! "${CROSS_COMPILE}"gcc
-o "${install_top}"/tmp/openssl_engine_path --
sysroot="${install_top}" openssl_engine_path.c then
echo "Failed: unable to build openssl_engine_path.c"
exit "${exit_code}"
fi
exit_code=$((exit_code+1))

# Execute and store the printed string in /tmp chroot ${install_top}
/bin/sh -c '/tmp/openssl_engine_path > /tmp/enginesdir'

# Bring the string up here (in its file) and clean up cp
"${install_top}"/tmp/enginesdir "${build_top}"/enginesdir rm -f
"${install_top}"/tmp/openssl_engine_path
"${install_top}"/tmp/enginesdir


-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 4:37 PM
To: Doug Fraser <doug.fraser@...>
Cc: openssl-tpm2-engine@groups.io
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

On Fri, Dec 21, 2018 at 8:11 PM Doug Fraser <doug.fraser@...>
wrote:

Fred,

Thanks for your response.

I have some ideas how I am going to install at this point, but I am
curious how you are determining your OpenSSL engine directory for
your specific target?
We are actually building OpenSSL on our target, so I have two
options:

1) grep for OPENSSL_ENGINES_DIR in the build artifacts and process
that. *it is indeed, there..... ugly, but useable*
2) after cross building and installing openssl, cross building a
small test application that does nothing more than
"puts(OpenSSL_version(OPENSSL_ENGINES_DIR));" and running that in
chroot on target.

Those are the two methods I have at hand, did you use one of these?
Or a third way?
Sorry but I have no good solution for this either, I'm basically hard
coding the engines dir. I will try to clean up my changes after the
holidays and if I come up with some good solution I will let you
know.

I also have some other workarounds that I probably should send mails
about. In short one problem regarding padding for RSA decrypt when
using openssl 1.0.x (not seen when using 1.1) and one problem
regarding permission of TSS tmp dir when the application is changing
user (in my case Apache httpd loads the keys as root but using them
as another user).

Fredrik Ternerot


Thanks for the reply!

Douglas Fraser

-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 1:59 PM
To: openssl-tpm2-engine@groups.io; Doug Fraser <doug.fraser@...
m>
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

============

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am
I actually do almost exactly the same fix. I'm also cross compiling
for 32-bit armv7 using OpenEmbedded.


This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot
execute `create_tpm2_key --help` on the build host to extract the
document.

It would be helpful if there were a configure option to block
documentation generation completely.
I agree.


In addition, when I `make install`, everything goes well until it
runs libtool on libtpm2(.la/.so), where it installs it on my
host, not on my cross target.
It is not honoring --prefix for the cross target libraries, only
the binary.
In case you wonder, I haven't checked this since I'm using a custom
install variant in my bitbake recipe instead of relying on 'make
install'.

Fredrik Ternerot


ibmtss

Doug Fraser
 

Does anyone know if tssclear supports hardware PresenceDetect clear?

(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.


Thanks......

Douglas Fraser

-----Original Message-----
From: Doug Fraser
Sent: Friday, December 21, 2018 4:45 PM
To: Fredrik Ternerot <fredrik.trot@...>
Cc: openssl-tpm2-engine@groups.io
Subject: RE: [openssl-tpm2-engine] TSS aligned with TPM2 engine

I am doing this between my ibmtss build and my openssl_tpm2_engine build....
This gets me the proper path, then I hand install using my own makefile.
I tried editing the configured Makefile using the results of this, but it still does some strange things with libtool that blows it up, so I hand install the output to the target after the build.

This *should* work with any installed version of opensll.
Feel free to pick away at parts of this if they are useful at all.

Douglas Fraser

# For OPENSSL TPM2 Engine, we need to know where the installed OpenSSL # is going to look for its engines.
# We do that by cross building this little application and running it # in chroot, and then extracting the string that it spits out.
rm -f enginesdir
rm -f openssl_engine_path.c
cat <<PATH_TEST >openssl_engine_path.c
#define HEADER_CRYPTLIB_H
#include <openssl/crypto.h>
#include <stdio.h>
int
main ()
{
#if OPENSSL_VERSION_NUMBER < 0x10100000
puts(ENGINESDIR);
#else
puts(OpenSSL_version(OPENSSL_ENGINES_DIR));
#endif

;
return 0;
}
PATH_TEST

# Cross compile directly to /tmp on chroot install top.
if ! "${CROSS_COMPILE}"gcc -o "${install_top}"/tmp/openssl_engine_path --sysroot="${install_top}" openssl_engine_path.c then
echo "Failed: unable to build openssl_engine_path.c"
exit "${exit_code}"
fi
exit_code=$((exit_code+1))

# Execute and store the printed string in /tmp chroot ${install_top} /bin/sh -c '/tmp/openssl_engine_path > /tmp/enginesdir'

# Bring the string up here (in its file) and clean up cp "${install_top}"/tmp/enginesdir "${build_top}"/enginesdir rm -f "${install_top}"/tmp/openssl_engine_path "${install_top}"/tmp/enginesdir


-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 4:37 PM
To: Doug Fraser <doug.fraser@...>
Cc: openssl-tpm2-engine@groups.io
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

On Fri, Dec 21, 2018 at 8:11 PM Doug Fraser <doug.fraser@...> wrote:

Fred,

Thanks for your response.

I have some ideas how I am going to install at this point, but I am curious how you are determining your OpenSSL engine directory for your specific target?
We are actually building OpenSSL on our target, so I have two options:

1) grep for OPENSSL_ENGINES_DIR in the build artifacts and process
that. *it is indeed, there..... ugly, but useable*
2) after cross building and installing openssl, cross building a small test application that does nothing more than "puts(OpenSSL_version(OPENSSL_ENGINES_DIR));" and running that in chroot on target.

Those are the two methods I have at hand, did you use one of these? Or a third way?
Sorry but I have no good solution for this either, I'm basically hard coding the engines dir. I will try to clean up my changes after the holidays and if I come up with some good solution I will let you know.

I also have some other workarounds that I probably should send mails about. In short one problem regarding padding for RSA decrypt when using openssl 1.0.x (not seen when using 1.1) and one problem regarding permission of TSS tmp dir when the application is changing user (in my case Apache httpd loads the keys as root but using them as another user).

Fredrik Ternerot


Thanks for the reply!

Douglas Fraser

-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 1:59 PM
To: openssl-tpm2-engine@groups.io; Doug Fraser <doug.fraser@...>
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

============

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am
I actually do almost exactly the same fix. I'm also cross compiling for 32-bit armv7 using OpenEmbedded.


This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot execute `create_tpm2_key --help` on the build host to extract the document.

It would be helpful if there were a configure option to block documentation generation completely.
I agree.


In addition, when I `make install`, everything goes well until it runs libtool on libtpm2(.la/.so), where it installs it on my host, not on my cross target.
It is not honoring --prefix for the cross target libraries, only the binary.
In case you wonder, I haven't checked this since I'm using a custom install variant in my bitbake recipe instead of relying on 'make install'.

Fredrik Ternerot

Re: TSS aligned with TPM2 engine

James Bottomley
 

On Fri, 2018-12-21 at 15:22 +0000, Doug Fraser wrote:
[...]
On to openssl-tpm2-engine:

I had to make one small change to openssl-tpm2-engine before running
bootstrap/configure prior to the build.
Right after pulling the git tree, at the top of the tree I do:

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am

This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot execute
`create_tpm2_key --help` on the build host to extract the document.

It would be helpful if there were a configure option to block
documentation generation completely.
Well, as I said, I've never actually done a cross compile. However,
leafing through the somewhat confusing automake documentation on cross
compiles, I think this is the fix.

James

---

diff --git a/Makefile.am b/Makefile.am
index 8c24dbe..7d3b645 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,8 +1,11 @@
-EXTRA_DIST = README openssl.cnf.sample create_tpm2_key.1
+EXTRA_DIST = README openssl.cnf.sample

+if NATIVE_BUILD
+EXTRA_DIST += create_tpm2_key.1
man1_MANS = create_tpm2_key.1

CLEANFILES = $(man1_MANS)
+endif

openssl_engine_LTLIBRARIES=libtpm2.la
bin_PROGRAMS=create_tpm2_key
diff --git a/configure.ac b/configure.ac
index ea544ea..a96206c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,6 +4,8 @@

AC_INIT(openssl-tpm2-engine, 2.1.0, <James.Bottomley@...>)
AM_INIT_AUTOMAKE(1.6.3)
+AC_CANONICAL_HOST
+AM_CONDITIONAL(NATIVE_BUILD, test "x$cross_compiling" = "xno")

AM_MISSING_PROG(HELP2MAN, help2man)

Re: TSS aligned with TPM2 engine

Doug Fraser
 

I am doing this between my ibmtss build and my openssl_tpm2_engine build....
This gets me the proper path, then I hand install using my own makefile.
I tried editing the configured Makefile using the results of this, but it still does some strange things with libtool that blows it up, so I hand install the output to the target after the build.

This *should* work with any installed version of opensll.
Feel free to pick away at parts of this if they are useful at all.

Douglas Fraser

# For OPENSSL TPM2 Engine, we need to know where the installed OpenSSL
# is going to look for its engines.
# We do that by cross building this little application and running it
# in chroot, and then extracting the string that it spits out.
rm -f enginesdir
rm -f openssl_engine_path.c
cat <<PATH_TEST >openssl_engine_path.c
#define HEADER_CRYPTLIB_H
#include <openssl/crypto.h>
#include <stdio.h>
int
main ()
{
#if OPENSSL_VERSION_NUMBER < 0x10100000
puts(ENGINESDIR);
#else
puts(OpenSSL_version(OPENSSL_ENGINES_DIR));
#endif

;
return 0;
}
PATH_TEST

# Cross compile directly to /tmp on chroot install top.
if ! "${CROSS_COMPILE}"gcc -o "${install_top}"/tmp/openssl_engine_path --sysroot="${install_top}" openssl_engine_path.c
then
echo "Failed: unable to build openssl_engine_path.c"
exit "${exit_code}"
fi
exit_code=$((exit_code+1))

# Execute and store the printed string in /tmp
chroot ${install_top} /bin/sh -c '/tmp/openssl_engine_path > /tmp/enginesdir'

# Bring the string up here (in its file) and clean up
cp "${install_top}"/tmp/enginesdir "${build_top}"/enginesdir
rm -f "${install_top}"/tmp/openssl_engine_path "${install_top}"/tmp/enginesdir

-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 4:37 PM
To: Doug Fraser <doug.fraser@...>
Cc: openssl-tpm2-engine@groups.io
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

On Fri, Dec 21, 2018 at 8:11 PM Doug Fraser <doug.fraser@...> wrote:

Fred,

Thanks for your response.

I have some ideas how I am going to install at this point, but I am curious how you are determining your OpenSSL engine directory for your specific target?
We are actually building OpenSSL on our target, so I have two options:

1) grep for OPENSSL_ENGINES_DIR in the build artifacts and process
that. *it is indeed, there..... ugly, but useable*
2) after cross building and installing openssl, cross building a small test application that does nothing more than "puts(OpenSSL_version(OPENSSL_ENGINES_DIR));" and running that in chroot on target.

Those are the two methods I have at hand, did you use one of these? Or a third way?
Sorry but I have no good solution for this either, I'm basically hard coding the engines dir. I will try to clean up my changes after the holidays and if I come up with some good solution I will let you know.

I also have some other workarounds that I probably should send mails about. In short one problem regarding padding for RSA decrypt when using openssl 1.0.x (not seen when using 1.1) and one problem regarding permission of TSS tmp dir when the application is changing user (in my case Apache httpd loads the keys as root but using them as another user).

Fredrik Ternerot


Thanks for the reply!

Douglas Fraser

-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 1:59 PM
To: openssl-tpm2-engine@groups.io; Doug Fraser <doug.fraser@...>
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

============

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am
I actually do almost exactly the same fix. I'm also cross compiling for 32-bit armv7 using OpenEmbedded.


This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot execute `create_tpm2_key --help` on the build host to extract the document.

It would be helpful if there were a configure option to block documentation generation completely.
I agree.


In addition, when I `make install`, everything goes well until it runs libtool on libtpm2(.la/.so), where it installs it on my host, not on my cross target.
It is not honoring --prefix for the cross target libraries, only the binary.
In case you wonder, I haven't checked this since I'm using a custom install variant in my bitbake recipe instead of relying on 'make install'.

Fredrik Ternerot

Re: TSS aligned with TPM2 engine

Fredrik Ternerot
 

On Fri, Dec 21, 2018 at 8:11 PM Doug Fraser <doug.fraser@...> wrote:

Fred,

Thanks for your response.

I have some ideas how I am going to install at this point, but I am curious how you are determining your OpenSSL engine directory for your specific target?
We are actually building OpenSSL on our target, so I have two options:

1) grep for OPENSSL_ENGINES_DIR in the build artifacts and process that. *it is indeed, there..... ugly, but useable*
2) after cross building and installing openssl, cross building a small test application that does nothing more than "puts(OpenSSL_version(OPENSSL_ENGINES_DIR));" and running that in chroot on target.

Those are the two methods I have at hand, did you use one of these? Or a third way?
Sorry but I have no good solution for this either, I'm basically hard
coding the engines dir. I will try to clean up my changes after the
holidays and if I come up with some good solution I will let you know.

I also have some other workarounds that I probably should send mails
about. In short one problem regarding padding for RSA decrypt when
using openssl 1.0.x (not seen when using 1.1) and one problem
regarding permission of TSS tmp dir when the application is changing
user (in my case Apache httpd loads the keys as root but using them as
another user).

Fredrik Ternerot


Thanks for the reply!

Douglas Fraser

-----Original Message-----
From: Fredrik Ternerot <fredrik.trot@...>
Sent: Friday, December 21, 2018 1:59 PM
To: openssl-tpm2-engine@groups.io; Doug Fraser <doug.fraser@...>
Subject: Re: [openssl-tpm2-engine] TSS aligned with TPM2 engine

============

#$ sed -i 's/ create_tpm2_key.1//' Makefile.am
I actually do almost exactly the same fix. I'm also cross compiling for 32-bit armv7 using OpenEmbedded.


This removes a documentation dependency on help2man.
This is required because I am cross-compiling, and I cannot execute `create_tpm2_key --help` on the build host to extract the document.

It would be helpful if there were a configure option to block documentation generation completely.
I agree.


In addition, when I `make install`, everything goes well until it runs libtool on libtpm2(.la/.so), where it installs it on my host, not on my cross target.
It is not honoring --prefix for the cross target libraries, only the binary.
In case you wonder, I haven't checked this since I'm using a custom install variant in my bitbake recipe instead of relying on 'make install'.

Fredrik Ternerot