Description
What version of libfido2 are you using?
1.15.0ppanoble1 and specifically fido2-assert -V
What operating system are you running?
Ubuntu 24.04.2 LTS
What application are you using in conjunction with libfido2?
fido2-assert
How does the problem manifest itself?
ww3 documentation states that to verify an assertion you concatenate authenticator data with the client data hash : https://medium.com/r/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fwebauthn%2F%23assertion-signature
ww3 documentation states that authenticator data in its simplest form is a SHA256 hash of the relying party ID, a byte of flags, and a four-byte counter, i.e. 37 bytes
fido2-assert documentation claims that the third line of data returned on a fido2-assert -V call is authenticator data: https://medium.com/r/?url=https%3A%2F%2Fdevelopers.yubico.com%2Flibfido2%2FManuals%2Ffido2-assert.html
fido2-assert returns 39 bytes, the first two are are 5825, which is a CBOR specification that the remaining string is 0x25 bytes long, i.e. 37 bytes.
Therefore, the output of fido2-assert is not authenticator data, as claimed in https://developers.yubico.com/libfido2/Manuals/fido2-assert.html which says the third line of the returned line is authenticator data.
To verify the signature, e.g. with openssl, the first two bytes need to be removed from the claimed authenticator data.
How to fix: amend the fido2-assert documentation to state that a two byte CBOR prefix plus authenticator data is returned on the third line by fido2-assert -G
Is the problem reproducible?
Yes
What are the steps that lead to the problem?
Follow the instructions at the end of https://medium.com/r/?url=https%3A%2F%2Fdevelopers.yubico.com%2Flibfido2%2FManuals%2Ffido2-assert.html then try to verify returned signature using openssl pkeyutl -verify
Does the problem happen with different authenticators?
Yubikey Security Key C NFC fw 5.7.1
Please include the output of fido2-token -L
.
fido2-token -L
$ fido2-token -L /dev/hidraw6: vendor=0x1050, product=0x0402 (Yubico YubiKey FIDO)
Please include the output of fido2-token -I
.
fido2-token -I
$ fido2-token -I <device> proto: 0x02 major: 0x05 minor: 0x07 build: 0x01 caps: 0x05 (wink, cbor, msg) version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE, FIDO_2_1 extension strings: credProtect, hmac-secret, largeBlobKey, credBlob, minPinLength transport strings: nfc, usb algorithms: es256 (public-key), eddsa (public-key), es384 (public-key) aaguid: e77e3c6405e3428b88240cbeb04b829d options: rk, up, noplat, noalwaysUv, credMgmt, authnrCfg, clientPin, largeBlobs, pinUvAuthToken, setMinPINLength, makeCredUvNotRqd, credentialMgmtPreview fwversion: 0x50701 maxmsgsiz: 1280 maxcredcntlst: 8 maxcredlen: 128 maxcredblob: 32 maxlargeblob: 4096 maxrpids in minpinlen: 1 remaining rk(s): 96 minpinlen: 4 pin protocols: 2, 1 pin retries: 8 pin change required: false uv retries: undefined
Please include the output of FIDO_DEBUG=1
.
FIDO_DEBUG=1
$ export FIDO_DEBUG=1 $ echo assertion challenge | openssl sha256 -binary | base64 > assert_param $ echo relying party >> assert_param $ head -1 cred >> assert_param $ tail -n +2 cred > pubkey $ fido2-assert -G -i assert_param /dev/hidraw5 > assert_output $ cat assert_output PQhSX/O9HYEvIbUZH/fWyCKg1nqXS5t41sztwV745nQ= chainfrog WCVnaHBXPn50f21/ute5h879H92zhpX0EtNrad3xx1KnPgEAAAAy MEYCIQCmAFE4jOiHVIoxIn00ecjAhDb3uUL61CFDl/d5RokTFQIhANYpiBUnRADTVDC6TvtpiDzMdzw+UzGXGfR/YZizQgBe $ echo "WCVnaHBXPn50f21/ute5h879H92zhpX0EtNrad3xx1KnPgEAAAAy" | base64 -d | xxd -p 5825676870573e7e747f6d7fbad7b987cefd1fddb38695f412d36b69ddf1 c752a73e0100000032