Android support

[jpalus]

Is there any chance on adding Android to supported platforms? It would be really cool to use it with openssh inside Termux in a similar fashion to TermBot. Not sure if Android + NFC is in scope of this library though.

[martelletto]

NFC on Linux is being worked on, and may land before the end of the year. Whether it will be enough to support Android is unclear. Android as a supported platform is unlikely to happen unless there is code contribution (and maintenance) by a third party.

[martelletto]

Unfortunately, no. I can try to have a look at NFC on macOS at some point next year, but can't promise anything. Sorry.

[martelletto]

Experimental support for NFC on Linux has been merged in 0a1a5ce.

[awakecoding]

Any update on this? I noticed that the Linux port requires libudev, which is not available on Android AFAIK. If libudev could be fixed, what else would be required to get libfido2 up and running on Android? Are there devices that should normally work with an Android phone?

[martelletto]

We are not aware of efforts in this area. I don't know enough about Android to say what would be required, but I expect libudev not to be a problem, even if it isn't available. As to devices, any USB-C or NFC device should work, at least in theory.

[awakecoding]

@martelletto I'll cleanup my patches another day, but I just wanted to report that I've managed to get it build for Android using libudev-zero. explicit_bzero / bzero is missing on Android, but explicit_bzero is defined in libcrypto, so I've tweaked the code a little bit. Other than that, it's really like a Linux build. My CMake build system patches are here: https://github.com/awakecoding/libfido2/tree/devolutions

[martelletto]

@awakecoding That's great news! Don't worry about cleaning up too much; anything that works is a good start, and we will happily take it from there. Did you get to test the resulting build? I was under the impression that Android applications would not be able to access /dev/hidraw* due to sandboxing.

[awakecoding]

@martelletto my primary goal at this point is just to get Win32-OpenSSH built for all platforms, even if libfido2 isn't actually used. I'm not sure what would be truly required to get FIDO2 support through libfido2 in a generic manner, and if libudev-zero would be sufficient. If not, how does FIDO2 work on Android? Are there higher-level APIs that should be used instead?

My patches were made on top of the PowerShell/libfido2 fork, so I remade them on top of the upstream repository. I've had to patch the CMake build system to accept non-default dependencies passed explicitly at generation time, and I see Microsoft made a few changes there as well. I kept my changes small, excluding dependency management for a first pull request upstream: #571

I could refactor the way the current build system detects dependencies to make it work properly with both globally-installed dependencies and explicitly-provided dependencies, but I would keep this for another pull request.

[viric]

@awakecoding FIDO2 works in Android usually through Google Apps, which talks to the device and offers an API to applications. MicroG (google apps open replacement) implemented that for USB/NFC (not blueooth): microg/GmsCore#849

Besides that, individual apps could also access the device by an android sdk like https://www.nitrokey.com/products/android-fido2-sdk

Another interesting point could be to use libfido2 in termux (linux as android app) through its "termux-usb", that allows launching a process with a fd handle to a usb device.