Re: [webauthn] Authenticator flag to indicate internal knowledge of rk (discoverable credential creation). (#1761)

From the BSI PP.

> During authentication, the authenticator receives (via the user device) the AppID, the previously registered key handle as well as a challenge. The authenticator verifies the message authentication code and thus checks whether the supplied key handle contains a nonce generated by the authenticator that fits to the supplied AppID. After successful verification, the KDF is activated with the seed together with the AppID and nonce to re-generate the private key

The PP is one implementation choice including a nonce in the credentialID and integrity protecting the credentialID then running the KDF again for each signature vs randomly generating the key and encrypting using AAD (eg AES GCM) the result with a key derived from the RPID and seed maintained inside the secure element.  Certifications at AAL3 don't require the BSI profile,  however, that is the profile that was used for the one AAL3+ certified key as I understand it.  The profile reflects the device it was written for.

In both cases, the protection of the seed is the issue.   If CC somewhere expresses a preference for one approach over the other that would be news to me.   The Fido security requirements don't make that distinction.

For a number of reasons including FIPS certification Yubikeys take the latter approach, though older keys did use the BSI approach.

The finer points of this are really a topic for the SPWG.

To @serianox point RP concerned about this should be looking at the AAGUID and the certification level of the authenticator.  Untill you get to AAL3 this flag really makes no difference and after that, the AAL3 certification should be enough assurance independent of if the credential is discoverable or not.



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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 19 July 2022 22:41:09 UTC