Closed VedaviBalaji closed 1 year ago
Thank you! Something seems to be failing in https://github.com/Yubico/libfido2/blob/main/src/ecdh.c#L61; I'm not sure why. It's also unclear why fido_dev_make_cred() is returning FIDO_OK. Is the binding you're using opensource?
Yes its open source.
I installed libfido using brew install libfido2
And I build my rust library using:
$ export FIDO2_LIB_DIR=/usr/local/Cellar/libfido2/1.13.0/lib
$ cargo rustc -- -L /usr/local/opt/openssl/lib -l framework=CoreFoundation -l framework=IOKit
Yes its open source.
Can you point us at it? From a quick look, it does not appear to be https://github.com/PvdBerg1998/libfido2.
I installed libfido using
brew install libfido
There does not appear to be a package called libfido in Homebrew. Did you mean libfido2, or did you install a package from a tap (third-party Homebrew repository)?
And I build my rust library using: $ export FIDO2_LIB_DIR=/usr/local/Cellar/libfido2/1.13.0/lib $
cargo rustc -- -L /usr/local/opt/openssl/lib -l framework=CoreFoundation -l framework=IOKit
The difference in prefix is a bit suspicious. Can you use otool -L
to verify that libfido2 is linked against the same libcrypto as your application?
Sorry, yes I used
$ brew install libfido2
$brew info libfido2
/usr/local/Cellar/libfido2/1.13.0
$ otool -L myfidoapp
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/opt/libcbor/lib/libcbor.0.10.dylib (compatibility version 0.10.0, current version 0.10.2)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
**/usr/local/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)**
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
$ otool -L /usr/local/Cellar/libfido2/1.13.0/bin/fido2-cred
**/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)**
/usr/local/Cellar/libfido2/1.13.0/lib/libfido2.1.dylib (compatibility version 1.0.0, current version 1.13.0)
/usr/local/opt/libcbor/lib/libcbor.0.10.dylib (compatibility version 0.10.0, current version 0.10.2)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
Yes, the openssl was different. I used cargo rustc -- -L /usr/local/opt/openssl@1.1/lib -l framework=CoreFoundation -l framework=IOKit
and it looks like its working. I will test a bit more, but thanks for helping me debug. :)
Edit:
Weirdly if the PIN is wrong it still returns a FIDO_ERR_SUCCESS
but data are null.
Weirdly if the PIN is wrong it still returns a FIDO_ERR_SUCCESS but data are null.
Could you please provide information on:
FIDO_DEBUG=1
enabled.Something else I just spotted in your code snippet over at StackOverflow:
let r = libfido2::fido_cred_set_pin_minlen(cred, 9);
if has_pin {
let r = libfido2::fido_dev_make_cred(device, cred, _cptr);
} else {
let r = libfido2::fido_dev_make_cred(device, cred, std::ptr::null() as *const i8);
}
if r != libfido2::FIDO_OK {
// ...
}
You are shadowing the r
variable in the if-statement's body. Once that scope ends, the inner shadowing ends and r
returns to being the result of the fido_cred_set_pin_minlen()
call. This is likely to be the cause of your confusing fido_dev_make_cred()
return values.
If this is the root cause of your problem, the above request for additional information will not be necessary.
Closing in understanding that the issue was resolved / questions answered.
Hello,
Thanks for helping me debug.
I am trying to debug a similar error that fails fido_dev_make_cred
with FIDO_ERR_INTERNAL
.
...
fido_rx: buf=0x7fd3a7160e00, len=0
fido_tx: dev=0x600003901b00, cmd=0x03
fido_tx: buf=0x6000020f7d58, len=73
0000: 00 01 00 00 00 00 40 e3 b0 c4 42 98 fc 1c 14 9a
0016: fb f4 c8 99 6f b9 24 27 ae 41 e4 64 9b 93 4c a4
0032: 95 99 1b 78 52 b8 55 49 96 0d e5 88 0e 8c 68 74
0048: 34 17 0f 64 76 60 5b 8f e4 ae b9 a2 86 32 c7 99
0064: 5c f3 ba 83 1d 97 63 00 00
fido_rx: dev=0x60000391c990, cmd=0x03, ms=50
fido_hid_read: read: Resource temporarily unavailable
rx: rx_preamble
u2f_get_touch_status: fido_rx
fido_rx: dev=0x60000391c750, cmd=0x10, ms=50
rx_preamble: buf=0x7ff7bfc2d750, len=64
0000: 5a 25 7f b3 90 00 01 31 00 00 00 00 00 00 00 00
0016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rx: payload_len=1
fido_rx: buf=0x7fd3a5901200, len=1
0000: 31
es256_sk_create: EVP_PKEY_paramgen
fido_do_ecdh: es256_derive_pk
fido_dev_make_cred_tx: fido_do_ecdh
fido_tx: dev=0x60000391c750, cmd=0x11
fido_tx: buf=0x0, len=0
This time, I downloaded the libfido.1.13.0
source and manually built it.
$ otool -L fido-cred
@rpath/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
@rpath/libfido2.1.dylib (compatibility version 1.0.0, current version 1.13.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
@rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.13)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
and my app
$ otool -L myapp
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current
version 1690.5.4)
@rpath/libpcre2-8.0.dylib (compatibility version 12.0.0, current version 12.2.0)
@rpath/libffi.8.dylib (compatibility version 10.0.0, current version 10.1.0)
@rpath/libnghttp2.14.dylib (compatibility version 39.0.0, current version 39.0.0)
@rpath/libsoup-3.0.0.dylib (compatibility version 8.0.0, current version 8.0.0)
@rpath/libgmodule-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
@rpath/libavcodec.59.18.100.dylib (compatibility version 59.0.0, current version 59.18.100)
@rpath/libavutil.57.17.100.dylib (compatibility version 57.0.0, current version 57.17.100)
@rpath/libturbojpeg.0.2.0.dylib (compatibility version 0.0.0, current version 0.2.0)
@rpath/libsasl2.3.dylib (compatibility version 4.0.0, current version 4.0.0)
@rpath/libjson-glib-1.0.0.dylib (compatibility version 601.0.0, current version 601.6.0)
@rpath/libprotobuf-c.1.dylib (compatibility version 2.0.0, current version 2.0.0)
@rpath/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
@rpath/libgio-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
@rpath/libgobject-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
@rpath/libglib-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
@rpath/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
@rpath/libpangocairo-1.0.0.dylib (compatibility version 5001.0.0, current version 5001.7.0)
@rpath/libpango-1.0.0.dylib (compatibility version 5001.0.0, current version 5001.7.0)
@rpath/libharfbuzz.0.dylib (compatibility version 40200.0.0, current version 40200.0.0)
@rpath/libcairo.2.dylib (compatibility version 11603.0.0, current version 11603.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2299.50.120)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
@rpath/libgstreamer-1.0.0.dylib (compatibility version 2203.0.0, current version 2203.0.0)
@rpath/libgtk-3.0.dylib (compatibility version 2406.0.0, current version 2406.32.0)
@rpath/libgdk-3.0.dylib (compatibility version 2406.0.0, current version 2406.32.0)
@rpath/libatk-1.0.0.dylib (compatibility version 23810.0.0, current version 23810.1.0)
@rpath/libcairo-gobject.2.dylib (compatibility version 11603.0.0, current version 11603.0.0)
@rpath/libgdk_pixbuf-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.10.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 169.0.0)
I see that libcbor is not linked as before, but the code works fine for keys without pin. The code is almost the same (it is just part of a another project).
Thanks
What version of libfido2 are you using? 1.13.0
What operating system are you running? macOS Ventura 13.3.1
What application are you using in conjunction with libfido2? Using webauthn.io and native messaging using Chromium
How does the problem manifest itself? I am unable to get PIN and touch to work simultaneously. Trying to perform registration using my YubiKey 5C Nano device. I have a YubiKey 5C Nano device with PIN set. Product details - YubiKey OTP+FIDO+CCID.
I tried to use
fido_dev_make_cred(device, cred, pin)
, this returns aFIDO_ERR_SUCCESS
but the attstmt and authdata are null. AFAIK, this device requires a touch to generate credentials, however, the UV support is FALSE and whenfido_dev_make_cred
is called, it bypasses the wait for touch and returns SUCCESS. If the pin is not configures and passed as NULL infido_dev_make_cred
, the device waits for the touch and the data are generated properly.If I set the UV to fido_opt_t_FIDO_OPT_TRUE, it fails with UNSUPPORTED error, but that is because the fido_dev_supports_uv returns false.
Is the problem reproducible? Yes. Code snippet is available in this stackoverflow qs. https://stackoverflow.com/questions/76144744/fido-dev-make-cred-returns-success-but-attstmt-and-authdata-are-null
What are the steps that lead to the problem? Set the pin and long touch configured. Use libfido2 rust library to make a credential passing the PIN as a non-null UTF-8 string to the
fido_dev_make_cred
method.Does the problem happen with different authenticators? Happens with Yubikey only if the PIN is configured.
Please include the output of
fido2-token -L
.fido2-token -L
Please include the output of
fido2-token -I
.fido2-token -I
Please include the output of
FIDO_DEBUG=1
.FIDO_DEBUG=1