Mailing List Archive

On Fri, 4 Sep 2020, Ian Haken wrote:

> I was recently looking at verifying the attestation data
> (ssh-sk-attest-v00) for a SK key, but I believe the data saved in this
> structure is insufficient for completing verification of the attestation.
> While the structure has enough information for U2F devices, FIDO2 devices
> sign their attestation over a richer "authData" blob [1] (concatenated with
> the challenge hash). The authData blob contains data not derivable from the
> public/private key, such as a signature counter and the device's AAGUID. As
> I understand it, the attestation structure should probably persist the
> entire authData blob to enable validation of the attestation. (This is
> really only getting into support for verifying "packed" attestation
> statements. Figuring out what to extract and persist is likely even more
> nuanced for other formats, but I'm not terribly inclined to go there
> myself.)
>
> Is there something I'm missing that would enable verification of the
> attestation signature for FIDO2 devices, or is this a correct assessment
> that the ssh-sk-attest-v00 file saved from ssh-keygen would not be enough?
>
> [1] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-attestation

I haven't tried to parse the attestation blob for FIDO2 devices,
so it's entirely possible that it doesn't work.

We rely on libfido2 to obtain the attestation cert from the token,
so if it has functions that let us get at the rest of what we need
then it wouldn't be too much work to append/prepend that extra
information to the blob.

Pedro, do you have any insight here?

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 7 Sep 2020, pedro martelletto wrote:

> > I haven't tried to parse the attestation blob for FIDO2 devices,
> > so it's entirely possible that it doesn't work.
> >
> > We rely on libfido2 to obtain the attestation cert from the token,
> > so if it has functions that let us get at the rest of what we need
> > then it wouldn't be too much work to append/prepend that extra
> > information to the blob.
> >
> > Pedro, do you have any insight here?
> >
> > -d
>
> I agree with Ian -- we need to persist the contents of
> fido_cred_authdata_ptr(), or an external verifier won't be able to form a
> complete picture of what was signed.
>
> Alternatively, we could persist only the AAGUID and the signature counter, and
> let the verifier reconstruct authdata. Since authdata isn't strictly bounded
> (its last constituent part is a CBOR map of variable content and length),
> reconstructing it can get tricky.

Thanks for the pointers - I think the attached patch should do it.

-d

Thanks folks! This looks like it's exactly what I was looking for. As I'm
pulling the thread on this, one word of warning on the
fido_cred_authdata_ptr method. The following is mentioned libfido2 docs
[1]: "The authenticator data returned by fido_cred_authdata_ptr() is a
CBOR-encoded byte string, as obtained from the authenticator." This is a
bit unfortunate since it's the CBOR-decoded data over which the attestation
signature is computed (concatenated with the challenge hash). And of course
you would also want to CBOR-decode the byte string before parsing the auth
data structure. I just opened a question [2] on the libfido2 GH page to ask
if there shouldn't be an API to return the CBOR-decoded data instead since
really that's what you would want for any uses of the function.

Basically, I think the openssh docs might also want to clarify that the
"ssh-sk-attest-v01" structure similarly has "authenticator data" as a
CBOR-encoded byte array (since customers would need to decode it to verify
attestation), or else you may want to just CBOR-decode the output of
fido_cred_authdata_ptr in sk-usbhid.c, at least until libfido2 (hopefully)
follows up on my question and provides a convenience method for getting
that decoded value directly.

[1]
https://developers.yubico.com/libfido2/Manuals/fido_cred_authdata_ptr.html
[2] https://github.com/Yubico/libfido2/issues/212

On Mon, Sep 7, 2020 at 5:31 PM Damien Miller <djm@mindrot.org> wrote:

> On Mon, 7 Sep 2020, pedro martelletto wrote:
>
> > > I haven't tried to parse the attestation blob for FIDO2 devices,
> > > so it's entirely possible that it doesn't work.
> > >
> > > We rely on libfido2 to obtain the attestation cert from the token,
> > > so if it has functions that let us get at the rest of what we need
> > > then it wouldn't be too much work to append/prepend that extra
> > > information to the blob.
> > >
> > > Pedro, do you have any insight here?
> > >
> > > -d
> >
> > I agree with Ian -- we need to persist the contents of
> > fido_cred_authdata_ptr(), or an external verifier won't be able to form a
> > complete picture of what was signed.
> >
> > Alternatively, we could persist only the AAGUID and the signature
> counter, and
> > let the verifier reconstruct authdata. Since authdata isn't strictly
> bounded
> > (its last constituent part is a CBOR map of variable content and length),
> > reconstructing it can get tricky.
>
> Thanks for the pointers - I think the attached patch should do it.
>
> -d
>
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, 8 Sep 2020, Ian Haken wrote:

> Thanks folks! This looks like it's exactly what I was looking for. As I'm
> pulling the thread on this, one word of warning on the
> fido_cred_authdata_ptr method. The following is mentioned libfido2 docs
> [1]: "The authenticator data returned by fido_cred_authdata_ptr() is a
> CBOR-encoded byte string, as obtained from the authenticator." This is a
> bit unfortunate since it's the CBOR-decoded data over which the attestation
> signature is computed (concatenated with the challenge hash). And of course
> you would also want to CBOR-decode the byte string before parsing the auth
> data structure. I just opened a question [2] on the libfido2 GH page to ask
> if there shouldn't be an API to return the CBOR-decoded data instead since
> really that's what you would want for any uses of the function.
>
> Basically, I think the openssh docs might also want to clarify that the
> "ssh-sk-attest-v01" structure similarly has "authenticator data" as a
> CBOR-encoded byte array (since customers would need to decode it to verify
> attestation), or else you may want to just CBOR-decode the output of
> fido_cred_authdata_ptr in sk-usbhid.c, at least until libfido2 (hopefully)
> follows up on my question and provides a convenience method for getting
> that decoded value directly.

Thanks, I have committed these changes and they'll be in OpenSSH 8.4.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev