Implement "PIN/UV Auth Protocol Two".

Not high priority as I do not know of any authenticators that do not also implement "PIN/UV Auth Protocol One", which is supported.

Specs: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#pinProto2

Spec: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-feature-descriptions-alwaysUv

Includes:

• Using TPM 2.0 as a keystore, implement a TPM-based authenticator
  • Note: This could be implemented on top of the TPM2-TSS OpenSSL engine (see https://github.com/tpm2-software/tpm2-tss-engine)
• Use the PIN/password feature of TPM 2.0 for user verification
• Partial WebAuthn/FIDO2 support via protocol downgrade

$ cargo run --example u2f_hid
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/examples/u2f_hid`
Found 1 devices.
Winking device: HS HyperFIDO (r13057)
Registration request sent (timeout: 10s).
Error: Ctap(InvalidLength)

This key works fine in Firefox and on Android.

Hi,

Is it possible to have an example code for webauthn/FIDO2 over BLE ?

Thanks

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#authenticatorCredentialManagement

Blocked:

• caBLE spec has not yet been released publicly.
  • If you're reading this and have access to a draft, please consider sharing a copy, figuring it out from the Chromium source is not that fun :)

Includes:

• Implement Cloud-Assisted Bluetooth Low Energy (caBLE) transport
• New crate for caBLE device management
• Trait for caBLE device pairing information storage

I'm confused what this project's relationship is, if any, with authenticator-rs. If I understand correctly, this project started by using authenticator-rs, but reimplemented USB HID support without it, and now this project also supports BLE? It seems that authenticator-rs development has stalled for a while and it only supports USB HID on Linux.

IIUC, this project aims to be a Linux-specific abstraction over the various hardware protocols for FIDO passkeys whereas authenticator-rs aims to be a cross-platform abstraction over different OS APIs? In that case, would it make sense for authenticator-rs to replace its Linux backend to use this project? Also, I think it would be helpful to rename libwebauthn to something platform-specific like webauthn-linux.

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-feature-descriptions-enterp-attstn

Implement PIN management requests

• authenticatorClientPIN
  • setPIN
  • changePIN

Simple ES256 CTAP2 requests can be downgraded to their CTAP1 equivalent, to work with FIDO U2F authenticators.

See docs:
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#u2f-interoperability

Requires:

• #9: Ctap1RegisterRequest support for exclude_credentials

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-hmac-secret-extension

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-credProtect-extension

CTAP1 does not support 'exclude credentials' in its register operation (like CTAP2). However, this functionality can be be implemented by exploiting the key enumeration functionality of the protocol. Before the register operation, for each key in the exclude list, the client sends a 'check only' signature request. If any of the keys exist, the register operation is aborted, with a compatible error.

This feature is needed to support CTAP2 request downgrading.

Required hardware (hw wishlist):

• FIDO U2F/WebAuthn NFC device
• USB NFC reader

Requires:

• #3 CTAP2 implementation
• #10 CTAP2 to CTAP1 (U2F) downgrade support

Includes:

• Looking into libnfc and neard
• Protocol negotiation via NFC
• Framing for CTAP1
• Framing for CTAP2

Requires:

• #2: BLE protocol version negotiation

Includes:

• Basic implementation of:
  • authenticatorGetInfo
  • authenticatorMakeCredentials
  • authenticatorGetAssertion

Currently the top-level Error enum lives in libwebauthn::transport::error. This should be moved out of the transport module, e.g. libwebauthn::error?

solo firmware already has support to emulate usb token running on linux

it's already working, no need to wait for ctap2 to be implemented by authenticator-rs

softkey solo issue

Hi,

I've been working on Kanidm's Webauthn Authenticator library, which has a lot of overlap with the work you're doing with libwebauthn; some of which is probably interesting to you.

Kanidm's library has a low level interface (for passing CTAP messages) and high level interface (for platform level stuff). The high level interface (which has a lot of overlap with your "future plans") currently has a SoftToken, and bindings for Mozilla's authenticator-rs (which I'm planning to replace) and Windows' WebAuthn API. There's someone currently writing bindings for macOS' Passkey API; and a future xdg-credential-platform would be an ideal target for that.

On the low-level side (which is where most of the libwebauthn overlap is), I'm currently building up a more complete implementation to allow us to replace Mozilla's authenticator-rs library. At the moment that targets FIDO 2.0/2.1 via NFC (via PC/SC) and USB HID (via hidapi) transports, with a view to eventually supporting BLE (and probably caBLE) in a similar (cross-platform) way.

Kanidm's WebAuthn (not just authenticators) library also has a bunch of compatibility tests, because it seems many things are broken in fun and exciting ways (authenticators, browsers, clients, platforms...) or just not implemented at all; and the specifications often leave a lot to be desired (or are plain wrong).

The goal with all that is to be able to provide a portable WebAuthn implementation that can be used anywhere, not just in browsers or on websites.

We normally lurk on https://gitter.im/kanidm/community if you want to say hi. 😄

The README has a demo showing off the reference portal implementation.

How can this demo be run? cargo reports not finding any binary targets in the workspace:

$ cargo run --all-features
error: a bin target must be available for `cargo run`

• Credential blobs: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-credBlob-extension
• Large blob keys: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-largeBlobKey-extension
• authenticatorLargeBlobs https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#authenticatorLargeBlobs

Allow caller to provide their own PinProvider to WebAuthn calls.

PinProviders should be told about attempt number, remaining attempts. Crucially, PinProviders should be able to cancel operations.

Create a StaticPinProvider implementation for testing. Also create a PromptPinProvider for use in examples. Make these convenience implementations safe by not providing PINs if attempts remaining is low.

In the future it may make sense to refactor this as a provider for all UV interactions, where PINs are only specific methods. I've not looked into bio auth enough yet.

If you're interested, please get in touch!

Tracks:

• Reaching out to Firefox eng team
• Implementation work

Currently a lot of errors are handled in a manner similar to:

let dev = device.open_device(&hidapi)
                .or(Err(Error::Transport(TransportError::ConnectionFailed)))?;

These errors are tricky to track down. Now that we're using the tracing crate fully, it would be best to rewrite these using let-else syntax, ie.:

let Ok(dev) = device.open_device(&hidapi) else {
    error!(?hidapi, "Failed to open device");
    return Err(Error::Transport(TransportError::ConnectionFailed));
}

If the error is relevant to the message, first consider if the method being called should be instrumented to automatically log errors in their context:

use tracing::instrument;

#[instrument(skipall, err)]
pub fn open_device(&self, dev: &HidDevice) {
    ...

If this is not possible, we can instead use match statements at the point of invocation:

let dev = match device.open_device(&hidapi) {
    Ok(dev) => dev,
    Err(err) => {
        error!({ %err, ?hidapi }, "Failed to open device");
        return Err(Error::Transport(TransportError::ConnectionFailed));
    }
};

Tracking reaching out to GNOME engs, and integration work.

I haven't reached out to anyone in the GNOME community yet. If you're reading this and you'd like to help, please reach out!

Thanks for working on this project!

The README.md says there are two crates, a libwebauthn crate and an xdg-credentials-portal crate, but I only see the libwebauthn crate? There's a ui.rs in the libwebauthn crate which uses the dbus crate. Is there a reason you used the bindings to the libdbus C library instead of zbus? Also, it would be great to expose both the portal-side D-Bus API and the application-side API as separate crates, or maybe behind different Cargo features.

Includes:

• Protocol negotiation
• Downgrading protocol from CTAP2 (and converting from WebAuthn APIs) moved to #10
• Basic implementation of:
  • Register
  • Sign

Requires:

• #3: CTAP2/BLE basic operations support

Includes:

• Implementing CTAP2 PIN operations

Based on the docs, this project would appear to contain both a "low level" webauthn library and the "credential platform", i.e. the UI and service executable. however, it looks like it's not possible to build/use the webauthn library standalone.

The main point of this project is off course the service executable, offering "platform auth", but using it as a library might be a nice to have as well. For this, it would be great if the dbus and UI dependencies could be separated out. This could offer the ability to use the library to build cross-platform apps with the FIDO2 built in, without needing platform specific things like D-Bus, UI stuff and Bluez.

My current use-case is testing support for authenticator hardware in Windows. While D-Bus is available on Windows, building and running the full service executable on Windows is probably challenging and beyond the scope of what I'm trying to do.

My end goal is supporting something like xdg-credentials-portal in the Webauthn client library I'm working on.

To be clear, I think where possible platform auth should be used, but a low level library would facilitate testing.

Please consider providing a package and installation instructions.

Publishing a release on crates.io may be a good start to enable easier testing and feedback.