3
$\begingroup$

I understand that FIDO2/WebAuthn generates a separate key-pair for each web-site (domain), and only allows a specific key-pair to be used for authentication on the same web-site (domain) who originally generated/registered that key-pair with the browser/authenticator. Also, I'm aware that this is done in order to prevent Man-in-the-Middle and "Phishing" attacks.

This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. A public key credential is created and stored by a WebAuthn Authenticator at the behest of a WebAuthn Relying Party, subject to user consent. Subsequently, the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators — https://www.w3.org/TR/webauthn-2/

But: Wouldn't it be sufficient to simply make the RPID (Relying Party ID, i.e. domain name) a part of the "challenge" value, i.e. the challenge would effectively become RPID || random_bytes, and require the browser/authenticator to verify that the RPID inside the challenge value is equal to the current web-site (domain), before signing? If a mismatch is detected, then someone obviously tried to trick us into signing a "foreign" challenge, which indicates a MITM/Phishing attack, so the authenticator would simply refuse to sign the challenge in that case. Problem solved?

The advantage of the above approach would be that we don't need tons of separate key-pairs for the same user. Keep in mind, that most FIDO2 devices (e.g. YubiKey) can only store a few...

Traditional TLS Client-Authentication can use a single key-pair (Client Certificate) for all sites too.

$\endgroup$
2
  • 2
    $\begingroup$ If we don't use separate key-pairs, different websites will be able to track users based on their public key, which is bad for privacy. That's the most obvious reason I can think of, and there's definitely other considerations. $\endgroup$
    – DannyNiu
    Mar 31, 2023 at 13:08
  • $\begingroup$ So, using a separate key-pair per site (domain) is purely a "privacy" feature, but from a pure "security" point of view (i.e. ignore tracking) it would not be necessary? $\endgroup$
    – Uwe Kohl
    Mar 31, 2023 at 13:18

1 Answer 1

4
$\begingroup$

I understand that FIDO2/WebAuthn generates a separate key-pair for each web-site (domain), and only allows a specific key-pair to be used for authentication on the same web-site (domain) who originally generated/registered that key-pair with the browser/authenticator. Also, I'm aware that this is done in order to prevent Man-in-the-Middle and "Phishing" attacks.

Generating an independent key pair per site—and per account at the site—isn't about defeating MITM or phishing attacks. An independent key pair per registration is critical for privacy, to prevent webauthn from becoming yet another method of tracking users across sites.

This makes it safe to use one device (plus a backup!) for as many sites and accounts as you want—work, personal, &c.—without turning webauthn into a passive instrument of mass surveillance. No need to carry around a keyring full of devices for different purposes.*

The advantage of the above approach would be that we don't need tons of separate key-pairs for the same user. Keep in mind, that most FIDO2 devices (e.g. YubiKey) can only store a few...

There is no limit to the number of key pairs that can be ‘stored’ by a U2F/FIDO device for normal webauthn registrations, because the device doesn't actually store the key pairs at all!

Instead, the device need only store one master secret key, say $k$. This is typically used in one of two ways with credential ids (‘key handles’, in older U2F nomenclature):

  1. A credential id is $s \mathbin\Vert A_k(s)$, where $s$ is a uniform random byte string and $A_k$ is a symmetric authenticator (e.g., AES-GMAC).

    (This is how Solokeys work (steps (1), (2), (3), (4)) and how older Yubikeys work (older reference).)

  2. A credential id is $E_k(s \mathbin\Vert m)$, where $s$ is a uniform random byte string, $m$ is some metadata, and $E_k$ is an authenticated cipher (e.g., AES-GCM).

    (This is how newer Yubikeys and Yubico security keys work (newer reference).)

In both cases, the key pair is derived from the seed $s$ stored in the credential id, using the device's master secret key. The key pairs are not actually stored on the device; the device derives them on the fly from the credential ids stored on the server.

Of course, you could design a FIDO device badly so that it does store a key pair for each site it has registered. But U2F/FIDO was designed from the start to make such a bad design unnecessary.


You may be thinking of resident keys, also known as discoverable credentials. Resident keys do have the limitations you mention. They also require special software configuration tools, have poor software compatibility, require PINs, and generally make the user experience abysmal—which hurts security.

Fortunately, resident keys are normally not used in FIDO2/webauthn. You will usually encounter resident keys only in ill-conceived enterprise deployments, or if you go out of your way to inflict the trouble on yourself. For example, you can use resident keys with OpenSSH ssh-keygen, but ssh-keygen -t ecdsa-sk works fine to make non-resident FIDO ssh keys—no need for resident keys with ssh unless you want to make life difficult for yourself.

You won't accidentally hit any limit on the number of normal webauthn site registrations, because there is no such limit for any serious FIDO device on the market.


* There is a caveat: U2F/FIDO/webauthn defeats passive tracking in mass surveillance, but not active linking of identities in a targeted attack. Suppose you have a normal business account and a spicy activist account at the same site example.com, and the owner of example.com suspects that the accounts are operated by the same person and wants to shut down the business account if so. When you log into one account, example.com can present the credential ids for the other account. If you had registered the same device with both accounts, and you tap the device, it will confirm the owner's suspicion. So if you need to ensure unlinkability against active targeted attacks, you do need to use separate devices. This attack doesn't scale well, though, so it's not useful for passive mass surveillance.

$\endgroup$
7
  • $\begingroup$ So, it all comes down to privacy concerns, I see. Regarding the number of key-pairs, YubiKey site says "FIDO2: the YubiKey 5 can hold up to 25 discoverable credentials". I'm not exactly sure what a "discoverable" credential means here, but it would seem that there is a limit in real-world products. YubiKey is pretty popular... $\endgroup$
    – Uwe Kohl
    Mar 31, 2023 at 17:55
  • 1
    $\begingroup$ @UweKohl Discoverable credential is synonymous with resident key. You don't have to worry about them unless you are dealing with an ill-conceived enterprise deployment, or you are trying to make life difficult for yourself. They are not relevant to the vast majority of FIDO/webauthn usage. $\endgroup$ Mar 31, 2023 at 18:59
  • $\begingroup$ Okay. But I still don't see how a site-specific asymmetric key-pair can be generated from a single "master key" easily and quickly. A symmetric key is no problem. But, e.g., generating an RSA key-pair usually requires generating a huge amount of pseudo-random numbers and testing whether they are prime; if they are not prime, we have to try again (usually many times). You can do this again every time, by starting with the same PRNG seed (derived from master-key and RIPD). But it would take a long time, every time you want to authenticate! Unless you actually store the key. $\endgroup$
    – Uwe Kohl
    Apr 3, 2023 at 7:44
  • 1
    $\begingroup$ @UweKohl That's why few, if any, hardware FIDO keys use RSA signatures. The vast majority use ECDSA over NIST P-256, which supports very cheap deterministic key derivation. Some also support Ed25519. $\endgroup$ Apr 3, 2023 at 19:49
  • $\begingroup$ So if I understand this specificaton correctly you have a keypair for every website. That also means if you have multiple accounts on that website you can't do that anonymously. So websites for example offering a trial period you can't prolong because the can identify you. Or even when you sell your yubikey the websites can then still track you because of the same keypair. Am I right? $\endgroup$
    – Hannes
    Jul 18, 2023 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.