webauthn signatures: SecurityKeyProvider, json parsing

[Scott C Wang]

Damien, thanks for clarifying.

(1 SecurityKeyProvider)

I don't have a FIDO security key, but I do have an Android phone, and the Android phone can act as a webauthn key via Google Chrome. So these were the shower thoughts I had for getting this to work.

I implement a SecurityKeyProvider that prints a https URL upon sk_sign. I open this URL in Google Chrome. The script on the page calls the webauthn authentication API; Google Chrome prompts me to choose an authentication method, and I pick my phone. Authenticating my fingerprint on my phone yields a webauthn signature to the script, which POSTs the signature, origin, clientData, and extensions back to the same URL. The SecurityKeyProvider polls the URL (or some endpoint) until the signature arrives, which it returns, along with the origin, clientData, and extensions, to the OpenSSH client. The OpenSSH client now has what it needs to pack a "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com" signature message, all of which the OpenSSH server currently already supports validating.

More generally, this one SecurityKeyProvider implementation would be able to bridge the OpenSSH client's security key authentication to any platform running a web browser exposing the webauthn API.

I've only given preliminary thought to this as yet -- have I gone mad?

(2 json key order) Perfect! Very prudent.

(3 mindrot.org) Excellent, thank you for the link. (I was trying /webauthn.html, but hadn't thought to try /webauthn.) Perhaps the hardcoded "mindrot.org" relying party can be changed to window.location.host, so that the standalone page can be hosted without modification on anyone's domain.



Scott C Wang


From: Damien Miller <djm at mindrot.org>
Sent: 11 January 2022 00:32
To: Scott C Wang <wangsc at cs.wisc.edu>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing 
 
On Tue, 11 Jan 2022, Scott C Wang wrote:

> Greetings,
>
> I was recently exploring OpenSSH's support for security keys and
> webauthn signatures, and had the following questions.
>
> (1) Could you confirm that the client doesn't support creating
> signatures of type "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com"?
> To me, it looked like SecurityKeyProvider implementers of sk-api.h
> aren't provided fields in the sk_sign_response struct in which to
> return the origin, clientData, and extensions signature fields,
> and sshsk_sign in ssh-sk.c cannot create signatures of type
> "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com". What considerations
> would there be against augmenting sk-api.h with a webauthn signature
> type with fields for origin, clientData, and extensions, so that
> SecurityKeyProvider implementers can provide webauthn signatures?

What use for this do you have in mind?

It wouldn't be too hard to allocate a SSH_SK_* flag that indicates
that the data to be signed is a webauthn request and that the result
should be a webauthn signature, but I don't see how this would be used
in OpenSSH itself.

> (2) Am I correct to understand, from my reading of
> webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server
> requires the webauthn signature's clientData field to begin with the
> type, challenge, and origin json fields, and ignores all fields after
> origin; and the hash is computed over the entire clientData blob? I'm
> asking to clarify since I notice Google Chromium [0] and the webauthn
> spec [1] warn that the json could be extended in the future, so they
> discourage verifiers from relying upon the order of the keys.

We worked with the webauthn team to avoid this. Strictly the
signed/verified data isn't JSON, but a JSON-compatible format that
strictly specifies the ordering of fields in a way to *not* require
a JSON parser in a signature verifer, as that would be a deal-breaker
for SSH use :)

> (3) I happened upon regress/unittests/sshsig/webauthn.html, which
> is very useful; however, the script hardcodes the relying party as
> "mindrot.org". I edited out that domain and hosted the site on my
> own domain to get this page to work. Is this page already hosted on
> mindrot.org, and if so, what's the path?

it's at https://www.mindrot.org/webauthn 

-d