Include libfido2

[nicoduck]

Openssh 8.2 includes the option authenticate via fido token backed ssh keys. The key itself can be stored on the phone or FIDO 2 token (older FIDO U2F tokens only support them on the phone).
OpenSSH release notes provide more information on that: https://www.openssh.com/releasenotes.html
I don't know if the mentioned libfido2 is also working on android or (because android has its own way to talk to fido tokens) a workaround with the native API is possible.

Link to home page and sources
https://github.com/Yubico/libfido2
https://www.openssh.com/releasenotes.html
https://developers.google.com/identity/fido/android/native-apps

Additional information
Have you compiled or tried to compile the package on device?
No

Trying to generate a ssh key with the needed options currently returns:
➜ ~ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Provider "" dlopen failed: dlopen failed: can't read file "/data/data/com.termux/files/usr/lib": Is a directory
Key enrollment failed: invalid format

[hashworks]

Hm, I wonder if libfido2 supports the NFC devices of Android phones (or NFC at all).

[dsseng]

Not only NFC, but also USB OTG connection should work, just as libusb patch by Termux.

[Fresheyeball]

Any progress on this?

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hashworks]

This is still relevant.

[xtkoba]

Depends on libudev.

[iprouteth0]

Depends on libudev.

What about for NFC?

[vb0]

What's the status here? I presume there isn't a complete roadblock as the issue is still open, but where it got stuck and is there anything we can do to get it unstuck?

The use case for this is very strong, ssh access is probably the thing that should be secured the most and Termux is IMHO the most trusted solution for Android, between loads of closed source clients, with ads, data collection, subscriptions, some not updated for years, some coming out of nowhere and so on. Heck, even Microsoft puts telemetry in their (open source) Windows openssh!

Allowing for FIDO2 tokens increases the security, simplifies the provisioning (like almost none at all needed on the phone like on any other client), makes it unnecessary to use unsafe ways like just having a secret key on a regular USB stick (even if it's encrypted a rogue machine can steal it, together with the passphrase if you log in there) and makes it easier to get in when there's an emergency just having the token you usually have for access (but not full Linux machine to access the token itself). Even more relevant as Android is trying to be usable as a desktop in recent versions (plus Samsung had the DeX since a while) and more and more tablets are sold with keyboards and intended as laptop replacements.

[Maxr1998]

Yubico/libfido2#571 might be relevant for this.

[jd1100]

Some additional context.

I tried compiling within termux using the steps from the repo docs but it failed on the "libcbor" dependency which I was not able to find in the termux pkg repo. This was after running the below command.

cmake -B build

[olmari]

+1 to this, nowadays there is no way in hell I use my servers SSH without FIDO2 (ed25519-sk).

[pgaskin]

Based on a quick skim through libfido2/src/hid_linux.c, libfido2/src/hid_freebsd.c, and related files, it doesn't seem like it'd be too complicated to make a PoC which uses termux-api/termux-usb to get access to the USB devices. I might attempt this at some point if I have time and nobody gets to it first. With this, the only other dependencies would be zlib, cbor, and openssl.

It seems like the only thing needed would be a custom implementation of fido_hid_manifest and fido_hid_open. Would probably also need to extend termux-api to return additional information from USB_SERVICE (product/vendor, usb hid interface fd).

For just OpenSSH, an alternative could be to write an implementation of sk-api.h using com.google.android.gms.fido.fido2. A minimal implementation would only need sk_sign. For sk_load_resident_keys, the privileged GMS Fido2 client would be required. For sk_enroll, it isn't apparent if the GMS Fido2 client provides the required functionality. I'm not sure how the PIN and key handle stuff would translate directly, so I'll probably look at the raw USB stuff first (that usb permission popup will get annoying over time, though...).

This might also be interesting: https://github.com/cotechde/hwsecurity.

And a kinda crazy idea: could maybe implement a ssh agent in a standalone app, then connect to that...

Back to the termux-api idea, it definitely would need changes on the Java side to be able to get the product/vendor ID, and to expose the HID interface indexes (and probably expose the interface claim functionality too, though that could be done directly with ioctls). Might also be nice to somehow reuse connections to termux-api, since the setup is somewhat expensive (requires a broadcast and socket setup). In the short term, for myself, I might either do the ssh agent thing, or implement something with root since I don't feel like messing with with termux-api just yet.

[Arbel-arad]

take a look at this application, it's supposed to work with keepassDX to allow unlocking with security keys.
https://gitlab.com/kunzisoft/android-hardware-key-driver

[pgaskin]

After reading the documentation in depth and looking at the Chromium source code, it looks like the GMS FIDO2 API has everything required to implement a sk helper, but without privileged/browser access (which seems to require emailing Google with the app signing key), it won't be able to:

• set the relying party / application id to a custom one for openssh (defaults to "openssh", but can be changed during ssh-keygen) (this isn't strictly required for a PoC, but without being able to do this, keys generated externally won't be usable since it'll be limited to the APK fingerprint or a domain from assetlinks)
• enumerate resident keys (this isn't strictly required for a PoC since it's only done when using ssh-add -K, which can be done on another machine)

I'll be attempting to implement this (when I have time) by compiling a dex with wrappers for the GMS API, then calling it using JNI from a custom sk helper library (which can be set using the SecurityKeyProvider SSH option for ssh and the SSH_SK_PROVIDER env var for ssh-keygen).

WIP: https://github.com/pgaskin/ssh-sk-provider-gms

[ghost]

@pgaskin is it also possible to use the patform key (activated by fingerprint sensor) like webauthn?

[dsseng]

As for physical USB and NFC authenticators, Yubico Authenticator seems to be able to list FIDO2 credentials, thus can perhaps access the token without restrictions. Not sure whether they have a special app signature or any app can access the key.

The latter is certainly true for NFC connection. I'm thinking of implementing an SSH agent powered by YubiKit API and NFC-attached YubiKey

[lolorc]

would it also work with non resident keys ? i guess there's no reason not to