FIDO2 - Yubikey giving different attestation format in firefox and chrome

504 views
Skip to first unread message

Krishnan

unread,
Jun 26, 2019, 8:06:39 AM6/26/19
to FIDO Dev (fido-dev)
Hi,

I owe Yubikey Security key 4 and working on FIDO2 server implementation. 

I am getting different attestation format in chrome and firefox browser. When I try with chrome I am getting the fmt as "packed" and the same authenticator tired with firefox browsers and  I getting fmt as "fido-u2f". 

Is it normal where one authenticator will give two different attestation format for the same request?


Thanks in advance
Krishnan. G

Emil Lundberg

unread,
Jun 26, 2019, 8:34:03 AM6/26/19
to fido...@fidoalliance.org
Hi,

This could happen with authenticators that support both CTAP1 (U2F) and
CTAP2, which some Yubico products do, if different browsers support
different CTAP versions. Something similar could also happen if the
client modifies the attestation statement. What argument have you set
for the `authenticatorSelection.attestation` parameter to
`navigator.credentials.get()`?

/Emil
> Disclaimer:
> The contents of this email and any attachments are confidential. They
> are intended for the named recipient(s) only. If you have received this
> email by mistake, please notify the sender immediately and do not
> disclose the contents to anyone or make copies thereof. 
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/dc793581-fc24-4f42-90b3-0b56e9c062b1%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/dc793581-fc24-4f42-90b3-0b56e9c062b1%40fidoalliance.org?utm_medium=email&utm_source=footer>.

signature.asc

Emil Lundberg

unread,
Jun 26, 2019, 8:34:42 AM6/26/19
to fido...@fidoalliance.org
Sorry, I meant `navigator.credentials.create()` and not `.get()`.

/Emil
signature.asc

Lee Tk

unread,
Nov 26, 2019, 10:43:16 AM11/26/19
to FIDO Dev (fido-dev)
I am encountered the same, i.e tested with using the fido2 webapp (https://github.com/fido-alliance/fido2-interop-webapp) using Yubico Security Key 5 (NFC), Chrome sent to FIDO2 sever with format 'packed' ; Where Safari formatted as 'fido_u2f' (with wrong none-all-zero aaguid).

From the source, the argument passed into `navigator.credentials.create()` is as below:
let publicKey = preformatMakeCredReq(response);
return navigator.credentials.create({ publicKey })


where publicKey:
/**
* Decodes arrayBuffer required fields.
*/
var preformatMakeCredReq = (makeCredReq) => {
/* ----- DO NOT MODIFY THIS CODE ----- */
makeCredReq.challenge = base64url.decode(makeCredReq.challenge);
makeCredReq.user.id = base64url.decode(makeCredReq.user.id);
for(let excludeCred of makeCredReq.excludeCredentials) {
excludeCred.id = base64url.decode(excludeCred.id);
}
return makeCredReq
}
 
Any hints ? or any idea that we can tell browser to format the attestation as Packed ?
Thanks.

Rgds,
Lee

Emil Lundberg

unread,
Nov 27, 2019, 7:41:34 AM11/27/19
to fido...@fidoalliance.org

When you say "wrong none-all-zero aaguid", do you mean the value in authenticatorData is different from that in the attestation certificate?

There is no way to tell the browser which attestation statement format to use. If your server does not support the "fido_u2f" attestation statement format, then you will not be able to verify attestation statements from any U2F-only authenticator.

Emil Lundberg

Software Developer | Yubico


To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/314ae7fa-e1c5-47a1-9d87-290cf7b01d3d%40fidoalliance.org.
signature.asc

Lee Tk

unread,
Nov 27, 2019, 8:43:36 AM11/27/19
to FIDO Dev (fido-dev)
Hi Emil,

My mistake on "all-zero aaguid" only applicable to attestation is "none" as per spec 5.1.3. below, instead of "direct" when yubico security key used in Safari,  AAGUID HEX: 01000000000000001100000000000000, very close to all zeroes.

  1. If the AAGUID in the attested credential data is 16 zero bytes, credentialCreationData.attestationObjectResult.fmt is "packed", and "x5c" & "ecdaaKeyId" are both absent from credentialCreationData.attestationObjectResult, then self attestationis being used and no further action is needed.

  2. Otherwise

    1. Replace the AAGUID in the attested credential data with 16 zero bytes.

    2. Set the value of credentialCreationData.attestationObjectResult.fmt to "none", and set the value of credentialCreationData.attestationObjectResult.attStmt to be an empty CBOR map. (See §8.7 None Attestation Statement Formatand §6.4.4 Generating an Attestation Object).


Noted on thanks for the input of "no way to tell the browser which attestation statement format to use". 

To unsubscribe from this group and stop receiving emails from it, send an email to fido...@fidoalliance.org.

Lee Tk

unread,
Nov 27, 2019, 8:56:09 AM11/27/19
to FIDO Dev (fido-dev)

Hi Emil, 
When double check with FIDO2 Conformance tool, one test case is if FIDO-U2F, AAGUID must be all Zeroes (not spotted from fido2/w3c spec).
Screenshot 2019-11-27 at 9.50.56 PM.png
Reply all
Reply to author
Forward
0 new messages