Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation error for fido2-assert -G #858

Closed
kf106 opened this issue Mar 16, 2025 · 2 comments · Fixed by #859
Closed

Documentation error for fido2-assert -G #858

kf106 opened this issue Mar 16, 2025 · 2 comments · Fixed by #859
Labels
bug report Something isn't working

Comments

@kf106
Copy link

kf106 commented Mar 16, 2025

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
@kf106 kf106 added the bug report Something isn't working label Mar 16, 2025
@LDVG
Copy link
Contributor

LDVG commented Mar 18, 2025

Thanks for the report! We'll look into how we can clarify that these are CBOR encoded byte strings.

P.S. What's up with those medium links? :)

@kf106
Copy link
Author

kf106 commented Mar 18, 2025

Sorry, I was documenting what I was doing in Medium, and copied the links without following them to their final destination.

https://kf106.medium.com/playing-around-with-a-yubikey-0450e048ae2b and https://kf106.medium.com/trying-to-verify-a-yubikey-signature-115be0bd5ec4 if you're interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Something isn't working
Development

Successfully merging a pull request may close this issue.

2 participants