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