Identity backed by FIDO2 authenticator.

[okoyfoeciov]

Is anyone interested in supporting identities backed by FIDO2 authenticators, like a YubiKey?

OpenSSH version 8.2 and newer support using security keys for authentication. This provides robust security, especially when working on a machine that you can't fully trust.

It also comes with some drawbacks:

• No Private Key Export: The private key cannot be exported from the device. If you lose access to your security key, you lose access to your identity.
• Limited Transports: Currently, only the USB transport is widely supported. BLE and NFC often present integration challenges.
• Credential Portability: If you use non-discoverable credentials, a key file must be stored on the disk. This makes the authenticator less portable than discoverable (resident) credentials, which are stored entirely on the device and allow it to act as a true roaming key.

I see that the SDK supports Hardware Security Modules (HSMs), but the usage flow isn't as straightforward as the FIDO2 standard.

This new type of identity could be a new storage mode. (--storage-mode=fido2)

Let me know what you all think. I'm willing to help with this feature's development.

[adamspofford-dfinity]

As far as I know, it is not possible (at the SDK level) for FIDO2 to be used. It produces signatures in a specific format which the IC will not accept, unlike PKCS#11 which can produce any signature. If you have a Yubikey you want to use, the PKCS#11 HSM flow should work with it using ykcs11 or OpenSC.

[okoyfoeciov]

@adamspofford-dfinity
If I infer correctly, The Internet Computer Interface Specification supports ECDSA on curve P-256

ECDSA on curve P-256 (also known as secp256r1), using SHA-256 as hash function, as well as on the Koblitz curve secp256k1.

And Yubikeys support COSE Algorithms Identifier -7, which I guess is the same algorithm used by the IC interface specs.

Can you elaborate more on that, whether this is a SDK's limitation or the IC limitation itself?

[adamspofford-dfinity]

The IC's ingress API asks for a signature according to a particular protocol, and FIDO2's signatures use a different unrelated protocol. Accepting a FIDO2 signature is something the underlying protocol must choose to support, and the IC does not.

Yes, both Yubikeys and the IC support P-256 keys (which COSE calls -9, not -7). It is not about the algorithm in use. The signature of a particular data string looks the same to FIDO2, PKCS#11, and the IC; the problem is not the signature scheme itself, but what data gets signed, i.e. what the signature is supposed to be of. You can read about the IC's signature protocol here.

As mentioned, dfx supports using your Yubikey as an HSM; install ykcs11, set up a P256 key in the PIV module as described in https://developers.yubico.com/yubico-piv-tool/YKCS11/ , and then set up the HSM identity with --hsm-pkcs11-lib-path pointing to the ykcs11 library.