I was trying to make wpa_supplicant use a tpm2-pkcs11 stored private key to authenticate against a RADIUS server, I mentioned about it on this discussion: https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/message/AYUBCAFCCX...
With some fixes on tpm2-pkcs11, TLS is working and there is an integration test for that here: https://github.com/tpm2-software/tpm2-pkcs11/blob/master/test/integration...
I wasn't able to reproduce this on Ubuntu 18, and noted that the test cases ran on top of an Ubuntu 16.04 image. I tried Ubuntu 16.04 and TLS works as in the integration test. I also checked that using latest version of wpa_supplicant, it does work with tpm2-pkcs11 and creates an EAP-TLS connection using the TPM.
I've debugged a bit in both OS versions and found that openssl is calling pkey_rsa_sign with different padding modes: RSA_PKCS1_PADDING in Ubuntu 16, and RSA_PKCS1_PSS_PADDING in Ubuntu 18. The consequence is that in tpm2-pkcs11, sign_init is being called using CKM_RSA_PKCS as mechanism on Ubuntu 16, but in Ubuntu 18 it is being called with CKM_RSA_X_509, which is not supported.
I think I have to file a bug to OpenSSL, but I don't know too much about the PKCS11 specs to support the claims. I'd appreciate any help to file a decent issue. Also, any workaround is welcome, as replacing OpenSSL in any distribution is very hard given all the software that depends on it.

Hi,
I'm trying out the tpm2_createek tool and in the manual
https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_createek...
It explains how to create a transient EK, I following these
instructions but can't get them to work. I've taken ownership of the
TPM and created a SRK. I then ran the command as listed in the manual
page:
tpm2_createek -G rsa -u ek.pub
ERROR: Expected option -c
Usage: tpm2_createek [<options>]
Where <options> are:
[ -P | --eh-auth=<value>] [ -w | --owner-auth=<value>] [ -p |
--ek-auth=<value>] [ -G | --key-algorithm=<value>]
[ -u | --public=<value>] [ -f | --format=<value>] [ -c |
--ek-context=<value>] [ -t | --template=<value>]
So I added the -c to save the context to disk and provide the EH authorisation:
tpm2_createek -G rsa -u ek.pub -c ek.ctx -P xxx
echo $?
0
so it looks like it's succeeded but I then try the to list the
transient objects with
tpm2_getcap handles-transient
and I get nothing. The files have been created
ls -la ek*
-rw-r--r-- 1 root root 1287 Feb 28 2020 ek.ctx
-rw-r--r-- 1 root root 316 Feb 28 2020 ek.pub
Any ideas as to why this is not working for me, do I need to perform
some other step first?
Many Thanks,
Martin.

Back in the end of July, I wrote a message on this discussion list titled
"PCR Policy enforcement when using nvram". In that, I asked for a way to
have both a PCR check AND a password lock an nvram range (not an OR). I
really appreciated everyone's help, especially William Roberts, who gave
some sample code of using a session to accomplish this goal.
Now that Ubuntu has updated its repositories for the upcoming 20.04 LTS
release and included TPM-tools v4.x, I figured it was time to take another
look.
My goal is to provide a method to auto-unlock a ZFS encrypted root
filesystem. Currently, ZFS allows for unlocking via a prompt or file
containing a raw, hex, or passphrase values. The mechanisms are already
inplace to prompt on startup.
So far I have just done a proof of concept. It probably loads of bad code
and tons of polish needed:
https://github.com/ghfields/zfs/compare/master...ghfields:tpm2-autounlock
I forked the zfs project, expanded the its initramfs hooks to include the
required tpm2-tools binaries, and added another stanza to init script's
decrypting section. I also created a pair of scripts that configures the
system and tests readback.
The nvram index and the PCRs used are stored/read from the zfs filesystem
properties. I used the filesytem's GUID as the required password as
another check to verify the NVRAM range was intended for that filesystem.
I also intend to issue an nvreadlock to prevent snooping once the key is
used.
I'd be interested in a critique of the method overall I expect there ways
to make this more secure. With enough effort, one could issue a
break=premount on the kernel line and manually extract the password from
the TPM. Any way to tighten that up?
I'm a total novice at TPM in general, but am completely open to advise and
guidance.
Thanks,
Garrett Fields

Anyone knows how to get EK certificate?
I am able to get EK public key by using the command below, but not sure how to get EK cert.
#tpm2_readpublic -c 0x81010001 -o ek.pub.pem -f pem
TPM2 tools version:
tpm2-tools-4.1.1
tpm2-abrmd-2.3.1
tpm2-tss-2.3.2

Hi,
Do you know ?
From data sheet:
SLB 9670 TPM2.0
SLB 9670 TCG Family 2 Level 00 Rev. 01.16 Data Sheet, Revision 1.0, 2015-11-05:
1.1 Power Management
In the SLB 9670, power management is handled internally; no explicit power-down or standby mode is
available. The device automatically enters a low-power state after each successful command/response
transaction. If a transaction is started on the SPI bus from the host platform, the device will wake immediately
and will return to the low-power mode after the transaction has been finished.
4.2 Functional Operating Range
1) The useful lifetime of the device is 5 (five) years with a duty cycle (that means, a power-on time) of 100%. A useful
lifetime of 7 (seven) years can be guaranteed for a duty cycle of 70%. For both scenarios, it is assumed that the device
will be used for calculations for approximately 5% of the maximum useful lifetime.
Is it true? This is disqualification. Industrial equipment should work much longer, 15-20 years. It's not suitable for industrial equipment.
It's good for ink toner cartridge.
Best regards,
Tom

Hello Tom,
thanks for your interest and to bring up the topics. I would like to provide some additional information on that.
The document you mention is a datasheet, which only contains basic information. Some sections in particular to the integrated firmware is not included in the datasheet, because it is described in the full Databook document. You can get the databook via your distributor, who will grant you access on an Infineon portal for the distribution of such documents. There you will find also more recent documents from 2019.
1.1 Power management
In chapter 4.3 of the document you can find another sleep mode, which is activated when CS# pin is inactive. This is an explicit power-down or standby mode that can be activated by the user. The very low current consumption shows, that in this mode almost everything inside the TPM is deactivated to reduce the power consumption to a very low value.
4.2 Functional Operational Range
The SLB 9670 is the consumer variant of TPM, so therefore the lifetime is similar to consumer devices, which also have a much more limited lifetime (e.g. PC, workstation, tablet). There are other TPM variants for industrial - SLM 9670 - and for automotive - SLI 9670 -. The industrial SLM 9670 has a lifetime for 20 years, see https://www.infineon.com/cms/de/product/security-smart-card-solutions/opt... The datasheet is in the top right corner.
I hope this helps to clarify these topics.
Best regards,
Florian