W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2021

Re: [webauthn] Managing FIDO keys (#1612)

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Fri, 14 May 2021 02:19:26 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-840961012-1620958765-sysbot+gh@w3.org>
> Pardon a question/comment from a person who has just started to work with FIDO/WebAuthn...
> 
> I have tested several WebAuthn demos (Duo Security, Yubico, StrongKey) and they all seem to pass on deletion of keys which leaves you with lots of "zombie" keys which then makes the selection process unmanageable. The tests were mainly performed on W10 using resident keys (Windows Hello).

This is most likely a fault of those demos - when you delete a key, it should no longer be offered by the relying party which means it should not appear in the selection process. 

> 
> How is this supposed to work? For traditional security tokens (X.509) there always was a built-in manager but not so for FIDO.
> 
> Is discovery and deletion supported at the CTAP2 level?

https://www.w3.org/TR/webauthn-2/#client-side-discoverable-public-key-credential-source

There is a lot of text here in this section, and a lot of language about "resident/non-resident keys" and "discoverable/non-discoverable" credentials. This relates to your question, but I believe that the spec does not communicate clearly with it's language what is really going on. 

There are two types of keys available to a CTAP2 device. "discoverable" aka "resident", but better this is a "Persistent Private Key". This is a private key that is stored (resident) in a ring buffer on the authenticator, and the client can "discover" if no other credential ID's are requested. 

The second type is "non-discoverable" aka "non-resident" keys, which would be better known as "Ephemeral Key-Wrapped Key". In this mode, the authenticator has a single "primary secret". When you perform an authentication, the credentialid presented to the device is actually an encrypted blob, encrypted by the primary secret. Succesful decryption allows the private key to exist in memory of the authenticator for that operation (ephemeral) and the signing proceeds. After the operation, it is removed from ram.

This is how the devices "appear" to have unlimited storage - when you "delete" the credential from the RP (server, demo site), because you are destroying the "credential id" this means that it is "lost" as it was never stored in the device at all! 

I hope that helps explain it. 


-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1612#issuecomment-840961012 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 May 2021 02:19:28 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC