Re: Incomplete attestation data for FIDO2 SKs?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxx> 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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux