Closed Gashmob closed 1 year ago
Hello @Gashmob, thank you for the thorough breakdown. I see in https://github.com/web-auth/webauthn-framework/issues/436 that this is due to malformed authData
in the attestationObject
reported by the authenticator during registration. Specifically a CBOR a3
(a list of three objects) should be a4
instead, but the authenticator incorrectly encodes the information. Flipping the byte seems to allow the response to parse as expected...interesting.
I'm evaluating a potential fix for this issue in this library. Stay tuned.
I've created #167 that should fix this issue. I'll let you know when it's released.
@Gashmob Thank you for your patience. You'll be happy to hear that webauthn==1.10.1
is now available with a fix for this issue. Thank you again for reporting it āļø
Wow, @Gashmob, I grabbed this response from https://github.com/web-auth/webauthn-framework/issues/436...
{
"id": "ma2Y7hbtrzJtoDR4N2PkazhnrO6_58gZ8mO8epx-6aCnR9Jtio8Ge1w0_msV7HniYmLIH9yxOW8Yu_9ze_y8oj-MehAozj1jFTsjlQUEc_dxdzG5uFJTn6_RnzhulEWCcZZwcvlNTYne99MpWAD31c-4IuEr-eRRV1DWSANcax0",
"rawId": "ma2Y7hbtrzJtoDR4N2PkazhnrO6_58gZ8mO8epx-6aCnR9Jtio8Ge1w0_msV7HniYmLIH9yxOW8Yu_9ze_y8oj-MehAozj1jFTsjlQUEc_dxdzG5uFJTn6_RnzhulEWCcZZwcvlNTYne99MpWAD31c-4IuEr-eRRV1DWSANcax0",
"response": {
"attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVkBCRawLfvD1MyjfrwvZRZlmxIhDbnhAYq58TqWkGOOpv2oRQAAAAIvwFefgRNH6rEWu1qNuSAqAICZrZjuFu2vMm2gNHg3Y-RrOGes7r_nyBnyY7x6nH7poKdH0m2KjwZ7XDT-axXseeJiYsgf3LE5bxi7_3N7_LyiP4x6ECjOPWMVOyOVBQRz93F3Mbm4UlOfr9GfOG6URYJxlnBy-U1Nid730ylYAPfVz7gi4Sv55FFXUNZIA1xrHaMBY09LUAMnIGdFZDI1NTE5IZggCBjXGDcYzBgpGFwYlBgcGJYYTxjdGOYY8BjyGL4YPxg7GEgYfBh_GCIYKxhgChgmGIQYkhhQGH0Y1hjoGIk",
"clientDataJSON": "eyJjaGFsbGVuZ2UiOiJvcTF2cGc3NHUtVG1xVzNEdjJMd1VfakgwME5RZjY1T3FwTWhydnI3eVBZIiwib3JpZ2luIjoiaHR0cHM6Ly90dWxlYXAtd2ViLnR1bGVhcC1haW8tZGV2LmRvY2tlciIsInR5cGUiOiJ3ZWJhdXRobi5jcmVhdGUifQ"
},
"clientExtensionResults": {},
"type": "public-key"
}
And the credential public key is actually pretty messed up:
{1: 'OKP', 3: -8, -1: 'Ed25519', -2: [8, 215, 55, 204, 41, 92, 148, 28, 150, 79, 221, 230, 240, 242, 190, 63, 59, 72, 124, 127, 34, 43, 96, 10, 38, 132, 146, 80, 125, 214, 232, 137]}
kty
is "OKP"
instead of 1
, and alg
is "Ed25519"
instead of 6
, x
is an array of numbers...
What kind of authenticator did you say you got this from? A YubiKey? Running which firmware?
Compare that with my YubiKey 5 running Firmware 5.4.3 - it returns what I'd expect given all of the other well-behaving authenticators I've interacted with thus far:
{1: 1, 3: -8, -1: 6, -2: b'8a\x86\x91\xbcx\xd1\xb3\x92\x87tKfq"\xd5\xcf\xf1~I\xf9\xc7\xeaA!\x9d\x01\x12\xabM\xf3Z'}
kty
is 1
, alg
is 6
, and x
is bytes as expected.
I kinda want to revert #167 and say, "that authenticator should never be asked for Ed25519 public keys." š¤
Huh, wild, if you look at Section 8.2 in RFC8152 it apparently spells out the requirement that kty
be the string "OKP"
, but while alg
should be the string "EdDSA"
it's "Ed25519"
instead.
I wonder if EC2 and RSA public keys use numbers for kty
and alg
because of this section of the spec:
https://www.w3.org/TR/webauthn-2/#sctn-encoded-credPubKey-examples
OKP
public keys are underspecified in WebAuthn, I suppose unsurprisingly given how new support for Ed25519 in WebAuthn is. š¤
It looks like the RFC8152 is using 'OKP'
as a human-friendly (though ironically confusing) alias of the actual value 1
. It's also confusing that the type of kty
is defined as tstr / int
, but there are only integer values defined in the registry, both on the IANA registry page and in Section 13 of RFC8152:
Key types are identified by the 'kty' member of the COSE_Key object.
In this document, we define four values for the member:
+-----------+-------+-----------------------------------------------+
| Name | Value | Description |
+-----------+-------+-----------------------------------------------+
| OKP | 1 | Octet Key Pair |
| EC2 | 2 | Elliptic Curve Keys w/ x- and y-coordinate |
| | | pair |
| Symmetric | 4 | Symmetric Keys |
| Reserved | 0 | This value is reserved |
+-----------+-------+-----------------------------------------------+
Table 21: Key Type Values
As far as I can tell, all actual values in the COSE registry (the "Value" and "Label" columns) seem to be integer typed.
Thanks for wading in here @emlun. I thought the string names might be allowed since the type was, as you noted, tstr / int
but I'm glad to hear someone else say that it really should only ever be an int
as per the values registered with IANA.
From the "COSE Algorithms" section of https://www.iana.org/assignments/cose/cose.xhtml, "Strings of length greater than 2" are supposedly under "Expert Review", though I must admit I don't entirely know what that means. Personally I suspect the structure is contrived, and that the values should be integers.
In goal to register a passkey on a website, I use a php library (https://github.com/web-auth/webauthn-framework). When I try to register a new credential with eddsa as 'prefered' algorithm, the load of passkey's response failed for presence of extra bytes in authentication data .If I comment the check then all is good.
I've tried to decompose the attestation object by hand and find that:
If we follow strictly the webauthn doc, yes, there is some extra bytes. So to check if the problem comes from the library I use, I decide to try another one (yours).
I've write this little script:
The file contains:
But your lib also raised an error
webauthn.helpers.exceptions.InvalidAuthenticatorDataStructure: Leftover bytes detected while parsing authenticator data
.So, did we really need to check that ?
I use a Yubikey 5 NFC (firmware 5.4.3) and have also opened an issue on the php lib https://github.com/web-auth/webauthn-framework/issues/436