yubico / libfido2 Goto Github PK

Feature Request: Update the cred and assert examples to give the user the option to specify a relying party and user.

We are testing against BioPass Feitan which has a fingerprint scanner. We're actually confused by user verification bit.
If we disable user verification bit in make credentials or verify attestation the key works as a button, i.e. any unregistered fingers can be used as long as the button is pushed.
If we turn on user verification bit it either crashes or returns error 43 FIDO_ERR_UNSUPPORTED_OPTION or error 35 FIDO_ERR_PIN_NOT_SET.

Also how do libfido2 knows a device works with user verification or not, without trying and getting error code?

Hi, I've built a toy client and server using libfido2. It's working, but there are some behaviors I don't understand:

• If I don't set cred_fmt on my client, it defaults to fido-u2f. (Okay, but contradicts man page.)
• If I don't set cred_fmt on the server, validation fails with INVALID_ARGUMENT (Annoying, but okay.)
• If I set cred_fmt on the server to fido-u2f, validation succeeds. (Okay.)
• If I set cred_fmt on the client explicitly to fido-u2f, and set fido-u2f on the server, validation succeeds. (Okay.)
• If I set cred_fmt to "packed", I still get a token with format fido-u2f, as reported by fido_cred_fmt(). This passes server validation with server format set to fido-u2f. (I don't understand this.)

Also:

• If I don't fido_cred_set_type() on the client, the client fails make_cred with invalid argument. (Annoying, but okay.)
• If I set both client and server to COSE_ES256, validation succeeds. (Okay.)
• If I do fido_cred_set_type() only on the client to COSE_ES256, server validation succeeds. (Unexpected, but okay.)
• If I fido_cred_set_type() on the client to COSE_RS256, the client fails make_cred() with invalid argument. (I don't understand this.)
• If I fido_cred_set_type() on only the server to COSE_RS256, the validation succeeds, despite it not matching the COSE_ES256 on the client. (I really don't understand this.)

I'm running git master of libfido2, and have a U2F-only YubiKey from the GitHub promotion, if that matters.

Thanks!

With version 0.3.0 I'm encountering issues during compilation when trying to compile the software with NDEBUG and the following flags:

/usr/bin/cmake /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/. '-GUnix Makefiles' -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_BUILD_TYPE=RelWithDebInfo '-DCMAKE_C_FLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -DNDEBUG' '-DCMAKE_CXX_FLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -DNDEBUG' '-DCMAKE_Fortran_FLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -DNDEBUG' '-DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' -DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed '-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' -DLIB_SUFFIX=64 -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF -DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules -DCMAKE_INSTALL_PREFIX=/usr -DCBOR_LIBRARY_DIRS=/usr/lib64

There are multiple warnings regarding unused variables / parameters:

[   18s] cd /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/build/regress && /usr/bin/cc -DHAVE_ENDIAN_H -DHAVE_ERR_H -DHAVE_EXPLICIT_BZERO -DHAVE_GETOPT -DHAVE_GETPAGESIZE -DHAVE_SYSCONF -DHAVE_UNISTD_H -D_FIDO_MAJOR=0 -D_FIDO_MINOR=3 -D_FIDO_PATCH=0 -D_GNU_SOURCE -I/home/abuild/rpmbuild/BUILD/libfido2-0.3.0/src -I/usr/include/hidapi  -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -DNDEBUG -Wall -Wextra -Werror -Wshadow -Wwrite-strings -Wmissing-prototypes -Wbad-function-cast -pedantic -pedantic-errors -fstack-protector-all -std=c99 -Wno-unused-result -Wcast-qual -O2 -g -DNDEBUG -fPIE   -o CMakeFiles/regress_assert.dir/assert.c.o   -c /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c: In function 'dummy_close':
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c:65:19: error: unused parameter 'handle' [-Werror=unused-parameter]
[   18s]  dummy_close(void *handle)
[   18s]              ~~~~~~^~~~~~
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c: In function 'empty_assert':
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c:166:44: error: unused parameter 'a' [-Werror=unused-parameter]
[   18s]  empty_assert(fido_dev_t *d, fido_assert_t *a, int idx)
[   18s]                              ~~~~~~~~~~~~~~~^
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c:166:51: error: unused parameter 'idx' [-Werror=unused-parameter]
[   18s]  empty_assert(fido_dev_t *d, fido_assert_t *a, int idx)
[   18s]                                                ~~~~^~~
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c: In function 'empty_assert_tests':
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c:219:16: error: variable 'io_f' set but not used [-Werror=unused-but-set-variable]
[   18s]   fido_dev_io_t io_f;
[   18s]                 ^~~~
[   18s] At top level:
[   18s] /home/abuild/rpmbuild/BUILD/libfido2-0.3.0/regress/assert.c:15:28: error: 'es256_pk' defined but not used [-Werror=unused-const-variable=]
[   18s]  static const unsigned char es256_pk[64] = {
[   18s]                             ^~~~~~~~
[   18s] cc1: all warnings being treated as errors

It seems that this version (in particular the regress module) has not been compiled with NDEBUG defined. This is appended to the build flags automaticalyl in our build system, which is not unusual for production releases.

After running cmake, during the subsequent build:

[1/103] Building C object src/CMakeFiles/fido2.dir/authkey.c.o
FAILED: src/CMakeFiles/fido2.dir/authkey.c.o 
/usr/lib/ccache/cc -DHAS_DEV_URANDOM -DHAVE_ENDIAN_H -DHAVE_ERR_H -DHAVE_EXPLICIT_BZERO -DHAVE_GETPAGESIZE -DHAVE_SYSCONF -D_FIDO_INTERNAL -D_FIDO_MAJOR=0 -D_FIDO_MINOR=3 -D_FIDO_PATCH=0 -D_GNU_SOURCE -I../src -I/usr/include/hidapi -W -Wall -Wextra -Werror -Wshadow -Wwrite-strings -Wmissing-prototypes -Wcast-qual -Wbad-function-cast -pedantic -pedantic-errors -fstack-protector-all -std=c99 -Wno-unused-result -fPIC -MD -MT src/CMakeFiles/fido2.dir/authkey.c.o -MF src/CMakeFiles/fido2.dir/authkey.c.o.d -o src/CMakeFiles/fido2.dir/authkey.c.o   -c ../src/authkey.c
In file included from ../src/authkey.c:8:
../src/fido.h:29:10: fatal error: cbor.h: No existe el fichero o el directorio
 #include <cbor.h>
          ^~~~~~~~
compilation terminated.

Thanks!

I used to be able to test libfido2 with SoftU2F on old version of libfido2 but new version doesn't let me.

I'm on macOS 10.14.4 . Could be the SoftU2F doesn't return manufacturer name but that shouldn't crash nor stop the functionality.

get_utf8: IOHIDDeviceGetProperty
get_str: get_utf8 manufacturer
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
get_utf8: IOHIDDeviceGetProperty

I noticed the following lines in the CMake project

Judging by what is happening I believe the intent is to carry this out on all Apple builds, not just ones with a custom clang build. Apple identifies its compiler as AppleClang as opposed to Clang (reference)

Recommendation is to use the following logic instead:

if (CMAKE_C_COMPILER_ID MATCHES "Clang")
  # using regular Clang or AppleClang
endif()

Experimenting with the fido2-assert command-line tool, and noticed that it returns (per the man page) the following:

       1.   client data hash (base64 blob);
       2.   relying party id (UTF-8 string);
       3.   authenticator data (base64 blob);
       4.   assertion signature (base64 blob);

Per https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd-20170927.html#authenticatorGetAssertion
there should also be available a user object available. In particular it would be needed if trying to match a resident key assertion which had an empty allowCredentials list back to a user record for the username-less login scenario.

Is there any reason the fido2-assert tool doesn't provide this?

This may be just a question.

So it looks like the Webauthn spec defines the authenticator data as a plain memory structure.

libfido2 AFAICT requires a cbor encoded structure, however the structure is just a single byte string field which is the structure referred to above.

In order to validate authenticator data from javascript more easily would it be reasonable to have a fido_assertion_set_authdata_raw method or somesuch? Specifically for language bindings, this would avoid the need to depend on an additional cbor library to verify assertions. The current method ends up just unwrapping the cbor anyway.

Hi,
I have two questions:

1. does the lib support self attestation? it see,s not since the verification is failed when x5c is missing.
2. does it support type rs256? can't see it in verify_sig

Thanks

According to the documentation, fido_dev_make_cred and fido_dev_get_assert are synchronous and will block if necessary. I wonder if there is anyway to interrupt the API calls when they are blocking. The use case is quite simple:

1. Plug in a FIDO2 key to an USB port
2. call one of the API
3. The key will start flashing/blinking
4. Don't activate the key but pull it out
5. The API is still stuck.

In some cases the HID communication is even stuck even after I plug the device out and retry. Thanks

Hi I did RTFM including example code here and here . I also tried different variations of up and uv flags but they all return error code 0x22 FIDO_ERR_INVALID_CREDENTIAL . The registration part works though.

int up = false;
int uv = false;
fido_assert_set_clientdata_hash(assert, cdh, sizeof(cdh));
fido_assert_set_rp(assert, rpId);
fido_assert_set_extensions(assert, 0);
fido_assert_set_options(assert, up, uv);
result = fido_dev_get_assert(device, assert, NULL);

Adding fido_assert_allow_cred before fido_dev_get_assert doesn't help. Is there anyway I can debug the library to tell why it fails? FYI, we statically link libfido2 to our app.

I noticed that support for Windows shared library is explicitly disabled in the CMake project. I made some trivial changes locally and using this library as a shared library on Windows doesn't seem to cause any issues so why is it disabled? If it is because of lack of familiarity with Windows builds then I would be happy to submit a PR for review.

The reason I want it as a shared library is because I wrote a set of .NET bindings to allow use of the library from .NET languages but the ability to link statically is not available to .NET projects.

It seems some (like fido_dev_make_cred, fido_cred_exclude) functions return FIDO_ERR_INTERNAL when given a length of 0, which seems like it should be valid to me, or it should return FIDO_ERR_INVALID_LENGTH or similar.

Hi,

in parse_cbor_reply when parsing the attestation statement, the first thing that the package is looking for is a NULL byte.
if (blob[0] != FIDO_OK) {
log_debug("%s: blob[0]=0x%02x", func, blob[0]);
r = blob[0];
goto fail;
}
and then the parsing itself starts from blob+1.
Is there a reason for that?
Thanks a lot!!

What is the difference between fido_cred_verify and fido_assert_verify? They seem to do the same thing, but fido_cred_verify only supports ES256.

I'm trying to get pamu2fcfg to work with this fido2 authenticator.

Out of the box I'm getting the following:

fgervais@bionic_18041-yubico:~/pam-u2f$ pamu2fcfg -v -d -t es256
Setting origin to pam://bionic_18041-yubico
Setting appid to pam://bionic_18041-yubico
Setting user to fgervais
Setting user id to 8326c45fafb8d573c2444b33b2bd9284482ab739ba4238ba06844baa97dc00f1
get_report_descriptor: open
get_report_descriptor: open
get_report_descriptor: open
get_report_descriptor: open
get_report_descriptor: open
get_report_descriptor: open
tx: d=0x562b9c2361c0, cmd=0x86, buf=0x562b9c2361c0, count=8
  4f 51 da 5c 78 09 44 5d 
rx: initiation frame at 0x7ffdf6bbc370, len 64
  ff ff ff ff 86 00 11 4f 51 da 5c 78 09 44 5d 00 
  00 00 0b 02 01 00 01 0d 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
tx: d=0x562b9c2361c0, cmd=0x90, buf=0x562b9c233dc0, count=180
  01 a4 01 58 20 b9 03 4e 0e db af 4a 3b f6 16 9a 
  1e fc 02 db c1 f2 c9 06 6a 6c 58 b7 08 52 ec 64 
  8b df a7 ff 37 02 a2 62 69 64 78 19 70 61 6d 3a 
  2f 2f 62 69 6f 6e 69 63 5f 31 38 30 34 31 2d 79 
  75 62 69 63 6f 64 6e 61 6d 65 78 19 70 61 6d 3a 
  2f 2f 62 69 6f 6e 69 63 5f 31 38 30 34 31 2d 79 
  75 62 69 63 6f 03 a2 62 69 64 58 20 83 26 c4 5f 
  af b8 d5 73 c2 44 4b 33 b2 bd 92 84 48 2a b7 39 
  ba 42 38 ba 06 84 4b aa 97 dc 00 f1 64 6e 61 6d 
  65 68 66 67 65 72 76 61 69 73 04 81 a2 63 61 6c 
  67 39 00 06 64 74 79 70 65 6a 70 75 62 6c 69 63 
  2d 6b 65 79 
rx: initiation frame at 0x7ffdf6bbbac0, len 64
  00 00 00 0b 90 00 01 26 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
parse_cbor_reply: blob[0]=0x26
fido_dev_make_cred_rx: parse_makecred_reply
error: fido_dev_make_cred (38) FIDO_ERR_UNSUPPORTED_ALGORITHM

I using pam-u2f commit 775e5eb from here

I'm currently set up to rebuild test versions of libfido2 to debug so if somebody has an idea I'll be happy to try it out.

Is there a way to request the supported COSE protocols? I'm getting a runtime error because I chose an unsupported one, but have no method (afaik) to check which ones I can use.

is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len

I see a lot of these in log when turn on debug info. Wonder why it happens. It works with real device however SoftU2F doesn't work because of the following check. I'm on macOS libfido2 1.2.0

if (report->getLength() != sizeof(U2FHID_FRAME) || report->prepare() != kIOReturnSuccess)
    return;

Would it be possible to add a fido_cred_get_type? The data is available and it would help me automatically convert the contained public key to the right format, without having to keep track of a type flag myself.

It's unclear to me what pointers can be NULL. I see you calling set_user with two NULL arguments. Can I NULL all of them? This holds for any parameter for any function.

The following snipet worked on 99a9be59b77fc9e6513a2953c222b44b0dbbe91e but not on latest master 446408aab849d60aeec92558eeabac9aea96636f

fido_assert_set_clientdata_hash(assert, cdh, sizeof(cdh));
fido_assert_set_rp(assert, rpId);
fido_assert_set_extensions(assert, 0);
fido_assert_set_options(assert, true, false);
fido_assert_allow_cred(assert, credid->buffer, credid->length);
fido_dev_get_assert(device, assert, NULL);

It just crashes real hard :(

Is there any way that in a single API call can get the client data and assertion response in C-library too like python get_assertion() API? is it possible in simple way to get these details in any of the current API's

It's really helpful in authentication if the return can be captured in some structure.

Python API example:
assertions, client_data = client.get_assertion(rp_id, challenge, allow_list)

Thanks

Hi,

Assertion needs cred-id and for verification requires pubkey information from the developer manual page link :
https://developers.yubico.com/libfido2/Manuals/fido2-assert.html
{{{
$ 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 | fido2-assert -V pubkey es256
}}}

Is there a way to achieve authentication just using the response data from the demo server( from the authentication begin request-response) as we get only "public-key".

For example by using the below JSON response from the server:

{"success":true,"request":{"requestId":"4qhlmPMGxi4R6bBABBchyHaeXXXXXXXXXXXXXX","publicKeyCredentialRequestOptions":{"challenge":"EXI31nxwsmN2FuHTXXXXXXXXXXXXXXX","rpId":"localhost","allowCredentials":[{"type":"public-key","id":"j4J3QfhoFus6BWQXXXXXXXXXXXXXXXXXXXXX"}],"userVerification":"preferred","extensions":{"appid":"https://localhost:8443"}},"username":"Demo"},"actions":{"finish":"https://localhost:8443/webauthn/api/v1/authenticate/finish"}}

Basically I am looking for a registration and authentication on FIDO server by using libfido2(C-library).

In the docs, you write the only possible values are COSE_RS256 and COSE_ES256, but in the source you also check for COSE_EDDSA. Is this a mistake?

trying to compile on OSX:
build fails with:

<base_ommitted>/libfido2/build/CMakeFiles/CheckIncludeFiles/HAVE_ENDIAN_H.c:2:10: fatal error: 'endian.h' file not found
#include <endian.h>
         ^~~~~~~~~~
1 error generated.
make[1]: *** [CMakeFiles/cmTC_eda51.dir/HAVE_ENDIAN_H.c.o] Error 1
make: *** [cmTC_eda51/fast] Error 2

Source:
/* */
#include <endian.h>

fixed by installing command line tools:

xcode-select --install

then re-running cmake...

When encoding the hmac-secret extension parameters for an authenticatorGetAssertion request (https://github.com/Yubico/libfido2/blob/master/src/cbor.c#L818) the library uses COSE_ES256 (ECDSA w/ SHA-256) as the "alg" parameter in the public key (https://github.com/Yubico/libfido2/blob/master/src/es256.c#L83). This is clearly wrong, since the algorithm it is being used for is ECDH key agreement, not ECDSA signature.

In 53b0141 hidapi was replaced with bespoke hid_{linux,osx,win}.c implementations, and after that commit does not build on FreeBSD.

I am trying to determine the best path forward - possibilities:

• Use hid_linux.c and https://github.com/FreeBSDDesktop/libudev-devd
• Restore old hidapi use for FreeBSD (add wrappers back in a new hid_hidapi.c)
• (Re)implement the subset of hidapi functionality needed by libfido2
• Implement something based on libusbhid

The docs note that this function generates a Credential based on list of excluded credential IDs;. However, I can't find a way to actually set this list, is that correct? Edit: Found it. It's just not listed in the place I had expected it to be.

Also, what is the format (fido_cred_set_fmt) used for? Because it is not listed in the list of used attributes.

It's possible I'm just not using the library correctly. However, I could open the device with open(2). When I do it shows the following in dmesg:
uhid0 at uhidev0: input=64, output=64, feature=0
Not sure if that helps or not.

laptop$ cat fido.c

int
main(void)
{
        fido_dev_t *d;
        int fd;

        d = fido_dev_new();
        if (d == NULL)
               err(1, "fido_dev_new");

        fido_init(FIDO_DEBUG);

        fd = fido_dev_open(d, "/dev/uhid0");
        
        printf("%d\n", fd);

        return 0;
}

laptop$ ./fido
fido_dev_open_tx: dev->io.open
-9

I have a problem with the libfido2 detecting any attached key on my Surface Book 2. I have tried multiple keys and using webauth demos or the YubicoManager they all successfully detect the key, but the number of devices from the fido_dev_info_manifest call is always 0. Running the same code on other laptops/desktops works with the library detecting multiple keys (fido_dev_info_manifest returning > 0 devices).

The drivers for the keys always installs correctly and Windows recognize the key as a security device etc. I have tried keys from Yubico and some keys from other vendors.

The Windows version I have installed is 1903 (release preview) but I have tried attaching the key using a Virtual Machine with Windows 7 and earlier Windows 10 versions and still the same problem.

fido_dev_t *device = NULL;
fido_dev_info_t *deviceInfoList;
size_t ndevs = 0;
fido_init(0);
if ((deviceInfoList = fido_dev_info_new(64)) && fido_dev_info_manifest(deviceInfoList, 64, &ndevs) == FIDO_OK)

This code will return FIDO_OK but with ndevs set to 0 with a key attached to the computer.

It appears that tag 0.4.0 is a lightweight tag, so git describe (without --tags) goes back to the previous annotated tag (0.3.0). Was it intentional that 0.4.0 was not annotated?

I'm trying to reset a YubiKey 5 NFC and it tells me I'm not allowed for some reason.

The same commands does work for the BioPass adapter.

Am I missing something?

fgervais@fgervais-System-Product-Name:~$ fido2-token -L
/dev/hidraw2: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID)
fgervais@fgervais-System-Product-Name:~$ fido2-token -R -d /dev/hidraw2
tx: d=0x55e655d28260, cmd=0x86, buf=0x55e655d28260, count=8
  f2 a3 89 18 d8 f1 ec 90 
rx: initiation frame at 0x7ffed5db53c0, len 64
  ff ff ff ff 86 00 11 f2 a3 89 18 d8 f1 ec 90 00 
  0d 00 01 02 05 01 02 05 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
tx: d=0x55e655d28260, cmd=0x90, buf=0x7ffed5db54a7, count=1
  07 
rx: initiation frame at 0x7ffed5db4bf0, len 64
  00 0d 00 01 90 00 01 30 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fido2-token: fido_dev_reset: FIDO_ERR_NOT_ALLOWED

For distribution and packaging purposes it would be useful (presuming the library ABI is mostly stable at this point), to add the SOVERSION property to the build, allowing library minor and patch updates without forcing applications to be rebuilt due to library minor/patch bumps.

Presuming that the FIDO_MAJOR value will be bumped for ABI changes, perhaps something like the following might work (or add a new ABI_VERSION value if the FIDO_MAJOR not sufficiently stable or not intended to be thought if as a ABI version?):

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index bff3a78..5e1b4ab 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -83,7 +83,7 @@ elseif(APPLE)
                "-framework IOKit")
 endif()
 set_target_properties(fido2_shared PROPERTIES OUTPUT_NAME fido2
-       VERSION ${FIDO_VERSION})
+       VERSION ${FIDO_VERSION} SOVERSION ${FIDO_MAJOR})
 install(TARGETS fido2_shared
        ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
        LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}

Thank you for your consideration.

Building the library myself I see the generated package is dynamic. Would it be possible to compile a static version, and if so, what would be the changes required to the build.ps1?

It seems that Self Attestation is not supported, only Basic Attestation.

I have a token that has been issued with two resident key credentials for the same RP (different users).

When calling fido2-assert to obtain a resident key credential assertion, the current behaviour is to return an indication that there is more than one credential available:

fido2-assert: fido_assert_count: 2

Is there any way (or planned way) for the command-line tools to proceed forward from this point to identify and then choose to utilise one of these, or is that simply beyond the scope of what is intended for these tools?

I've been following along and have tried to build on Windows again but I get the message that GPG verification fails

gpg: Can't check signature: No public key

Which public key do I need to install? This should probably be added to the README.

As the project is C (and not C++), one could consider simplify the project build requirements and explicitly state the project language to be C (the cmake default languages are C and CXX). Proposed patch follows:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6689f98..a887048 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -5,7 +5,7 @@
 # detect AppleClang; needs to come before project()
 cmake_policy(SET CMP0025 NEW)
 
-project(libfido2)
+project(libfido2 C)
 cmake_minimum_required(VERSION 3.0)
 
 include(CheckCCompilerFlag)

I'm attempting to build on OpenBSD 6.3 and I'm getting the following error.

CMake Error at /usr/local/share/cmake/Modules/FindPkgConfig.cmake:645 (message):
None of the required 'hidapi' found

However, hidapi is installed as well as cbor.

laptop$ ls /usr/local/lib | grep hidapi
libhidapi.a
libhidapi.la
libhidapi.so.0.0

laptop$ ls /usr/local/lib | grep cbor
libcbor.a
libcbor.so.0.0

Unfortunantly I'm not well versed in cmake, so I'm not sure where to look to make changes to how it determines that it isn't installed. Any help appreciated.

It would be great if fido2-assert/fido2-cred supported hmac-secret FIDO2 extension the same way examples/assert and example/cred do, so one could integrate these standard tools into their workflows instead of building their own solution.

I run windows/build.bat, and create vs2017 project and get cred.exe,but it crash.I found the reason is fclose(fp) in example/util.c,if I comment the statement,it run good,but it run good on Ubuntu.

In the latest release docs I see fido_dev_info_product_string and fido_dev_info_manufacturer_string return w_char. This is weird since all other functions return normal chars. In the master branch they seem to do so.

Is this fixed on master?

In one of the examples, fido_dev_force_u2f is used, but this function is missing in the docs.

hi,

in the is_fido function we have:
return (usage_page == 0xf1d0);

well, it worked perfect but suddenly i get 1 as the device usage_page and therefor this condition returns false.
any idea what can be the reason?
i updated windows yesterday, this is the only reason i can think of...

thanks,
Shimrit

I'm (trying to) implement a Rust wrapper for this library. I was wondering: how thread safe is this library?

I just got my hand on the attestation certificate of a non Yubico authenticatior.

I'd like to perform a signature verification to ensure that I have a genuine device.

I'm looking for the easier way to do this.

Would libfido2 be a good place to start to perform such validation?

function get_id() in hid_osx.c incorrectly filters out device because get_int32() returns 0xFFFFxxxx where xxxx is the actual VID/PID.
Ideally get_int16() should be used.

Hi,

I have a question on the credential id length.

On registration, when I get the values form cred->attcred.id.ptr and cred->attcred.id.len, I get a byte array of length 64.
On authentication, when I get the value from assert->stmt[idx]->id.ptr and assert->stmt[idx]->id.len, I get a byte array of length 16.

Shouldn't that be the same value which is the credential Id?

Thanks!