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://firstname.lastname@example.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.
I would like to announce the newest stable tools release of version 4.1.1 with the following changes:
4.1.1 - 2020-01-21
* tpm2\_certify: Fix output of attestation data including size field. Now outputs just bytes.
* tpm2\_certifycreation: Fix tool to match manpage where the code had the -C and -c options reversed.
* tpm2\_gettime: Fix output of attestation data including size field. Now outputs just bytes.
* tpm2\_nvcertify: Fix output of attestation data including size field. Now outputs just bytes.
* tpm2\_nvreadpublic: add name hash output.
* tpm2\_import: Support object policies when importing raw key material.
* Fix overflow in pcrs.h where sizeof() was used instead of ARRAY\_LEN().
- Fix compilation issue: lib/tpm2\_hash.c:17:19: note: 'left' was declared here.
- Fix manpage examples that have "sha" instead of "sha1"
- tpm2\_shutdown manpage was missing, add it to build.
- Fix manpage example for tpm2\_createak's tpm2\_evictcontrol example.
so I played around with tpm2 tools some more.
I managed to get TLS-EAP networking working with keys stored inside the
Now I would like to prove that the secret keys used are really stored
If I understand it correctly, I should be able to just sign keys stored
inside the TPM with the AIK I created in a previous step.
so, tpm2_load && tpm2_certify ?
except there seems to be no way to load the keys I created with
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
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:
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
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
I saw something from Matthew Garrett about a cool demo he did using the
TPM for remote attestation over Bluetooth. Looks like they're not there
yet on TPM2 support (here's a relevant issue
https://github.com/google/go-attestation/issues/98). But really cool
stuff so I thought you all would be interested.
[Matthew's] #lca2020 demo was remote attestation over Bluetooth, which
means you can gain the security benefits of remote attestation without
needing to pass data or identity to a third party. Code is at
There's no authentication yet, and it doesn't support TPM2, so a fair
amount of work to be done yet. Goal is to port this to phones so you
can use your phone to verify the state of your laptop before entering
Video of [Matthew] demoing TPM remote attestation over Bluetooth as a
privacy preserving security feature is now up:
Also, I remember discussion recently on event log parsing and there
being a difference between 1.2 and 2.0 that might have been tripping
something up? Maybe I remembered incorrectly. But looks like they've
got the 1.2 event log parsing down if someone needed to use that as a
As part of some TPM integration work that we’ve been doing, we required access to the Enhanced System API from the Rust language, so we decided to create a wrapper crate and make it available on crates.io. This week we managed to upstream v1 of the crate and its accompanying documentation:
The crate exposes:
* Raw FFI bindings to the TSS 2.0 ESYS layer
* A low-level abstraction of the bindings which mainly works as a convenience layer, hiding uses of `unsafe` code from the client and making more use of Rusty types.
* A high-level abstraction layer which allows for easy creation and usage of RSA keys for signing and verifying, closer to a proper Rusty development experience.
The last two are by no means complete (in terms of API coverage), focusing on RSA key generation/importing/exporting and signing/verifying with them.
We would be grateful for any feedback, comments, contributions or ideas for what other utilities/abstractions would be most useful!
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.