W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

Re: [webauthn] Syncing Platform Keys, Recoverability and Security levels (#1640)

From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Jan 2022 15:29:47 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1008995640-1641828585-sysbot+gh@w3.org>
I think that @MeydanOzeri's proposal could be made phishing resistant if combined with ideas from our [recovery extension](https://github.com/w3c/webauthn/pull/1425). What's currently missing is that the user's private key be tied to a particular origin, so that the browser can verify that the RP is authorized to exercise that private key. This of course leads to a new problem: the user doesn't want to perform the setup and store one private key for each individual RP, right? But this could also be solved using [asynchronous remote key generation (ARKG)](https://dl.acm.org/doi/10.1145/3372297.3417292). I think this could even work without any changes to RP code or the WebAuthn API, something like this:

1. Initial setup:
    1. The browser generates a "seed" key pair, instructs the user to safely store the private key and stores the public key in the user's browser profile.
    2. The browser also generates a MAC key deterministically from the public key (for example by hashing the public key) and stores it.
    3. The public seed key and MAC key can be safely exported and imported to another machine in order to "connect" it to the same set of recovery credentials.
2. Whenever the user registers a new credential (`navigator.credentials.create()`), the browser checks if `excludeCredentials` contains any credential ID with a valid MAC suffix. If none does, the browser offers to register the recovery credential instead of a normal platform or roaming credential.
3. If the user chooses to register a recovery credential:
    1. The browser uses ARKG to generate a new public key and credential ID from the RP ID combined with the stored public seed key.
    2. The browser computes a MAC of the credential ID using the stored MAC key, and appends the MAC to the credential ID.
    3. The browser returns this public key and credential ID (with the MAC appended) as the credential to be registered.
4. Whenever the user is to authenticate (`navigator.credentials.get()`), the browser checks if `allowCredentials` contains any credential ID with a valid MAC suffix. If one does, the browser offers the user to use this recovery credential.
5. If the user chooses to use the recovery credential:
    1. The browser prompts the user to enter the private seed key.
    2. The browser removes the MAC suffix from the credential ID.
    3. The browser uses ARKG to derive a private key from the credential ID combined with the RP ID and private seed key.
    4. The browser uses the derived private key to sign the authentication challenge and returns the result as a normal WebAuthn assertion.
6. The user is now successfully logged in and can perform any credential management as usual.

I'll need to think a bit more on it, but the idea seems quite interesting:

- No secret key is stored long term in the browser
- Origin-bound and phishing resistant just like normal WebAuthn credentials
- Multiple browsers can be set up with the same public seed key and MAC key, and each needs the private key only at recovery time
- Entirely a browser feature, automatically compatible with all existing RPs (except ones with an attestation policy that excludes it)

I can't easily think of a way to preserve the "single-use" aspect of it, but that seems to me like a very minor problem compared with the advantages. Maybe a bigger problem is that so far, ARKG is intrinsically tied to elliptic curve cryptography and thus not quantum resistant.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 January 2022 15:29:49 UTC

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