FIDO2: TPM 2.0 with PIN support

[AlfioEmanueleFresta]

Includes:

• Using TPM 2.0 as a keystore, implement a TPM-based authenticator
  • Note: This could be implemented on top of the TPM2-TSS OpenSSL engine (see https://github.com/tpm2-software/tpm2-tss-engine)
• Use the PIN/password feature of TPM 2.0 for user verification
• Partial WebAuthn/FIDO2 support via protocol downgrade

[AleDema]

Any updates on this?

[AlfioEmanueleFresta]

Hey @AleDema, I don't have plans to work on this at the moment, but I would be happy to have a chat if you're interested in contributing, or have an interesting use case you'd like to discuss.

[AlfioEmanueleFresta]

I just discovered @psanford's tpm-fido, which is a TPM based, U2F platform authenticator for Linux. This might be a great fit.

tpm-fido currently emulates a HID device. We already support CTAP1 over HID, but it would be great to be able to integrate without HID dependencies. I've opened an issue for the implementation of high-level APIs https://github.com/psanford/tpm-fido/issues/14

As for CTAP2, in addition to higher level APIs, we would need some sort of user verification (TPM2 PIN?).

[zaolin]

@AlfioEmanueleFresta I may get nlnet funding for it, I am currently in discussion with them. I thought of integrating it directly into systemd so it comes by default with the distro. Any thoughts, wishes from your side?

[AlfioEmanueleFresta]

@zaolin that sounds great.

For FIDO2 use cases, I can think of the following requirements:

• Signature operations - for CTAP2 getAssertion;
• Encryption and decryption - for extensions such as hmac-secret where we must store some payload alongside the credential, or HMAC-SHA-256.
• Minimum algorithms support (from WebAuthn spec):
  • ECDSA using P-256 and SHA-256 (ES256 from RFC 7518)
  • RSASSA-PKCS1-v1_5 using SHA-256 (RS256 from RFC 8812)
  • EdDSA with Ed25519 (SHA-512 and and Curve25519)
• Large number of keys - Users should be able to create large number of credentials.
• Support for origin scoping - Allowing FIDO2 platform authentication middleware to enforce the following controls:
  • Non-privileged can only use credentials created by themselves;
  • Privileged applications can use any credentials as long as they are authorised by the user.

I have written about the challenge of origin scoping in a blog post. I do not recommend you solve this within your TPM (systemd?) service, but rather simply ensure the design is compatible with origin scoping being enforced by xdg-desktop-portal or whatever D-Bus portal providing FIDO2 functionality to applications. Specifically, I can think of two ways of achieving this:

1. Using high-entropy handles to reference keys within the TPM, requiring TPM applications to keep track of these handles. The 'desktop portal' offering FIDO2 origin scoping protections would be responsible for storing per-application mappings, so as to prevent applications independently accessing FIDO2 credentials, bypassing the
2. Using wrapped keys to offload storage of encrypted key material to user space applications.

I would recommend approach (2) because it would solve both issues of (a) supporting origin scoping enforcement by FIDO2 middleware, as well as (b) storing a virtually unbounded number of credentials, by completely offloading storage of wrapped private keys to the user space middleware.

WDYT?

I would recommend joining the Secrets @ GNOME Matrix room and connect other contributors who may have more thoughts on the systemd integration.

[zaolin]

@AlfioEmanueleFresta Hey, I have joined meanwhile the matrix channel. Yes I think from the first view I would also go for option 2) I need to summarize your and the systemd community feedback on that matter. I hope I can come up this week with a complete/detailed proposal. I will post it into a systemd issue and link it here as reference. I already checked your blog post and will come back here in few days :)