Bug 3498

Summary:	Support for unlocking keys with more than one FIDO/WebAuthn token
Product:	Portable OpenSSH	Reporter:	Ben Boeckel <bugzilla.mindrot>
Component:	Smartcard	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED LATER
Severity:	enhancement	CC:	bugzilla.mindrot, djm
Priority:	P5
Version:	9.1p1
Hardware:	Other
OS:	Linux

Description Ben Boeckel 2022-11-08 03:08:46 AEDT

I'd like to be able to have a single key be unlocked by multiple FIDO/WebAuthn tokens instead of having one-to-one. The problem is that I juggle dozens of keys (I prefer one key per "service"; $DAYJOB also has a setup where keys get access to specific resources using rrsync[1], so a key-per-resource is required) as it is and having to double (or triple) it for robust backups feels excessive.

Specifically, what would be nice-to-have:

- support for multiple FIDO/WebAuthn tokens to be able to unlock a private key
- ability to add a new token to be able to unlock an existing private key
- the public key should not know/care about which token unlocked the private key (i.e., should not change after adding a token)

I don't think this supports the mechanism where part of the private key is stored on the token itself; I think that's fine as now to support the second point is really questionable if part of the key is token-locked.

[1] https://download.samba.org/pub/rsync/rrsync.1

(I tried searching for existing issues, but I just get errors about malformed redirects.)

Comment 1 Damien Miller 2022-11-08 10:07:46 AEDT

It sounds like you're after something like Passkeys (https://fidoalliance.org/passkeys/) - I have no idea whether these will work with OpenSSH or whether modifications will be required.

Putting Passkeys aside, there is no trivial way to do what what you want. Private keys are fundamentally device-linked in the FIDO model, so you could no longer rely on their notion of keys directly.

It might be possible to rig something up using the FIDO2 hmac-secret extension (https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#sctn-hmac-secret-extension), which can let you exchange a key handle for a durable symmetric key.

Maybe it would be possible to rig up some multi-key encryption scheme that uses these keys to decrypt the actual private key material. However, it isn't clear whether this would yield a more convenient workflow than managing separate FIDO keys. Also, you'd be giving up most of the benefit of hardware tokens as the actual key material would be decrypted on the host and not the token.

Another non-FIDO approach would be to buy FIDO keys that also support PIV or some other standard that allows key access via PKCS#11, and load the same key onto multiple tokens (rather than having the token generate the keys). This gets you proper hardware backing for the keys (so long as you didn't leak it when generating and loading it), but you would be dealing it the messiness of PKCS#11...

Comment 2 Ben Boeckel 2022-11-08 10:53:44 AEDT

Thank you for the information. This makes sense; I'll put my hopes into (evolution of?) Passkeys then. Hopefully we also get support that doesn't rely on trillion-dollar companies too…

Comment 3 Damien Miller 2023-03-17 13:42:26 AEDT

OpenSSH 9.3 has been released. Close resolved bugs