Support for U2F / Fido2 / webauthn?

flipsa commented 5 years ago

Hey there,

I use LineageOS for MicroG on my NFC enabled phone and recently bought a Yubikey 5 NFC. While the phone does detect the Yubikey via NFC or UCB-OTG, there seems to be no support for U2F/ Fido2 / webauthn. I used the Yubico U2F demo site to test it.

If I understand correctly, this functionality is provided on stock Android with the usual Google Apps through the Google play services library, which then exposes it via an API to the mobile browser. On my device, depending on the browser I either get "The user agent does not support public key credentials" (Jelly), or I get a timeout while trying (Chrome, Firefox, Brave).

On a non LineageOS / non-microg device with the Chrome browser, the Yubico demo site works fine.

The browsers (except Jelly) all have support for U2F if I am not mistaken, so that is not the reason I think...

Are there any plans to incorporate this in MicroG? I could not find any info on it, so I'm asking here.

Thanks for any leads - and of course for MicroG in general, I appreciate it very much!

Oneplus 6 (Enchilada)
LineageOS 16 for MicroG (official build from last week)
tried with the following browsers: Jelly, Chrome, Firefox, Brave

afgks commented 4 years ago

Same question here.

gtbuchanan commented 3 years ago

Here's a Chromium ticket confirming this is handled by Google Play Services. I just wanted to throw in that the PIN implementation is especially important to me.

bintzandt commented 3 years ago

Hi everyone, I was wondering if anybody is currently working on this issue?

Sami32 commented 3 years ago

It seem that this issue should affect CalyxOS, /e/ OS and some others as well. So Apps requiring a high security level like banking or trading have to rely on weaker biometrics or 2FA at best :(

I guess that now with more workers doing their job from home their enterprise will ask for some security level using keys like Yubikey, OnlyKey...

jr64 commented 2 years ago

I'm very interested in this feature as well. At least support for simple Registration/Sign-In could probably be implemented fairly easily using https://github.com/cotechde/hwsecurity.

I've considered trying that route but I'm unsure regarding the licenses. This project is Apache 2.0 licensed, hwsecurity is GPLv3. From my (admittedly very limited) understanding of Open Source license compatibility, this means we can't even link against that library. Is that correct? Can anyone with more knowledge on that subject confirm/deny before I waste time on an unusable implementation?

ssaavedra commented 2 years ago

You should not link to that directly or this project would need to switch to GPLv3. However, you could expose an API at this project level that could be implemented in a separate app, like what is done with location providers. This way the supposed hwsecurity "mfa-provider" (or whatever we call it) itself could be a GPLv3 app, keeping microG on the other side of the API, and no licensing issues.

jr64 commented 2 years ago

Yeah, that's what I thought, thank you for confirming. While not ideal for the end user, I guess this is still the most viable solution.

I currently don't have a phone that is suitable for microG but I do plan on getting one. I'll give this a go if I can manage to find the time.

dschuermann commented 2 years ago

Just a small note from us, the devs of the Hardware Security SDK at https://github.com/cotechde/hwsecurity: Currently, the SDK is dual-licensed under the GPLv3 and a proprietary license. This allows us to have a business model by selling the SDK under the proprietary license that allows our customers to include it in their closed-source software.

Our business no longer works when we would license the SDK under Apache v2 since the Apache license allows the inclusion in closed-source apps.

That said, feel free to build one GPLv3 app with the SDK that exposes the API via AIDL and the call it from microG.

nsp-devel commented 2 years ago

+1 here, from someone using FIDO2/WebAuthN in production at day job, and having implemented FIDO2 server-side protocol in PHP.

Having support either in MicroG or the OS build would be great. Noting from the Chromium ticket referenced above, this is nothing that would /have to/ live in MicroG but could go all the way down to AOSP. Sad that there's no resource in AOSP for this to happen.

I guess an app+linking to HWSecurity code is the easiest way forward short-term.

samsapti commented 2 years ago

I just want to point out, that there's another issue regarding FIDO implementation: last time I tried using FIDO (YubiKey 5 NFC) on a regular Google Play Services enabled Android phone, the only browser that worked with it was Google Chrome. Other browsers didn't work. Now, I don't know if it's Google's FIDO implementation that intentionally makes it unusable in other browsers (since other browsers like Firefox technically do have support for FIDO, just look in about:config) or if it's something else.

If we were to implement FIDO in microG or all the way down to AOSP, we would still have to wait for third party browsers to implement the API.

samsapti commented 2 years ago

Btw, is there anything wrong with switching microG to GPLv3? Just curious.

nsp-devel commented 2 years ago

I tried current Firefox 92 on a Samsung S6 with stock Android 7 and that supported FIDO2 just fine. I.e. can't confirm a "Chrome only".

duplexsystem commented 2 years ago

Are the microg maintainers against bountys because if not I'd like to put one on this

duplexsystem commented 2 years ago

I added a 20$ bounty for this

samsapti commented 2 years ago

I tried current Firefox 92 on a Samsung S6 with stock Android 7 and that supported FIDO2 just fine. I.e. can't confirm a "Chrome only".

Hmm, then they've probably fixed it since the last time I tried. I don't have Google Services anymore, so I can't test it again. But that's not important anyway, the important part right now is getting FIDO support to microG. Would it be possible to make the mfa-provider-app-thingy able to translate Google Services FIDO API calls into API calls compatible with the HWSecurity SDK? Because that would make FIDO enabled browsers, that are currently working with Google Services, work with microG.

Another thing I wanna point out is this, don't know how it's gonna play out with the (hopefully) upcoming microG implementation.

duplexsystem commented 2 years ago

Important to note that as of version 92 Firefox Android supports webauth.

Added support for Web Authentication API, which allows USB tokens (such as the use of USB or Bluetooth Security Key) for website authentication.

https://www.mozilla.org/en-US/firefox/android/92.0/releasenotes/

samsapti commented 2 years ago

Important to note that as of version 92 Firefox Android supports webauth.

Added support for Web Authentication API, which allows USB tokens (such as the use of USB or Bluetooth Security Key) for website authentication.

https://www.mozilla.org/en-US/firefox/android/92.0/releasenotes/

It still doesn't work with microG tho, I tried it a couple of days ago.

duplexsystem commented 2 years ago

It still doesn't work with microG tho, I tried it a couple of days ago.

correct

Nuc1eoN commented 2 years ago

I would also be interested in FIDO2 support.

I added a 20$ bounty for this

Where can I add a bounty?

duplexsystem commented 2 years ago

I would also be interested in FIDO2 support.

I added a 20$ bounty for this

Where can I add a bounty?

https://www.bountysource.com/issues/75974640-support-for-u2f-fido2-webauthn

ssaavedra commented 2 years ago

Are bounties still interesting here? On bountysource, microG project says that other methods should be considered instead. I'd be OK if @mar-v-in takes this, but if this is not an "official priority" I'd be also ok sponsoring somebody external to the project for this task (would love to confirm if he would, too).

Should we just fund the bountysource? Anyone's estimate of worth raising for this feature to land?

duplexsystem commented 2 years ago

If needed I'd be willing to raise my bounty in order to get a guarantee this feature will be implemented,

mar-v-in commented 2 years ago

Please don't put any bounties on bountysource. They failed to pay out for several months now.

As of now, I haven't looked into what it takes to implement the U2F APIs at all, so I also don't know how much work it would be. I do have it on my list though.

pepijndevos commented 2 years ago

Great to hear. Would be a useful feature to have. Just donated to your GH sponsor instead because this project is what makes my phone usable while maintaining my privacy. Happy to take a stab at some Java/C glue code once it's clear what actually needs to be done.

bintzandt commented 2 years ago

Great to hear. Would be a useful feature to have. Just donated to your GH sponsor instead because this project is what makes my phone usable while maintaining my privacy. Happy to take a stab at some Java/C glue code once it's clear what actually needs to be done.

I have also just set up a recurring donation via GH sponsors so this might hopefully get some extra attention!

(I understand that you might be too busy; just trying to help)

ssaavedra commented 2 years ago

Nice to see a milestone added to this. Thanks for prioritizing it somewhat, @mar-v-in. Glad to be a sponsor as well.

devbrones commented 2 years ago

Any progress?

devbrones commented 2 years ago

Btw, is there anything wrong with switching microG to GPLv3? Just curious.

I am wondering this too. I think that it would actually make the project more easy to work with (as someone who mostly licenses their code under GPLv3), as we can use more code from other projects...

mar-v-in commented 2 years ago

@devbrones @theanonymousexyz The reasons for microG to be Apache 2.0 are:

Most of open-source Android ecosystem (including AOSP itself) is Apache 2.0 licensed. Not mixing licenses makes life easier for everyone.
It is unfortunately not always clear, if a usage of microG would fall under copyleft requirements or not. For example, applications that use Play Services APIs that make use of the Dynamite library loader (Vision SDK for Barcode scanning, Maps API v2, Conscrypt Security Provider Updater) will include the code from microG GmsCore (or parts thereof) in their classloader, which in normal Java would make those apps fall under the copyleft requirement if microG was using GPLv3 (without the classpath exception).
Parts of microG are meant as drop-in replacements for original Google libraries, which come under a "permissive" license (it has a ton of restrictions, but no copyleft and no cost, so I guess that counts as permissive). If those parts were provided under GPLv3, for example CCTG would have had to relicense their fork of the Corona-Warn-App (which is Apache 2.0 licensed).
microG is meant to be used in environments that are not fully free software. Android OS developers and even manufacturers do not fully control the license of the software they bundle (thinking of device drivers and other vendor blobs). This, together with uncertainties around copyleft as described above, would make it less feasible for custom Android distributions to bundle microG if it was licensed under GPL.

Nuc1eoN commented 2 years ago

The problem with Apache license is that it is incompatible with GPL and nearly nobody talks about this.

The GPL would be risky or even inpossible for microg because of mixing with potentially proprietary software.

The MIT license has no such issues btw.

ale5000-git commented 2 years ago

@Nuc1eoN: Why? Apache-2.0 is one-way compatible with GPL-3.0.

brunoais commented 2 years ago

The MIT license has no such issues btw.

MIT license also doesn't protect the name of the program. Anyone could just start using "microg" pretending to be this one while it's not.

mar-v-in commented 2 years ago

@Nuc1eoN Apache 2.0 license is only incompatible with GPLv2, it is one-way compatible with GPLv3.

Besides, I don't think this issue is the place for license discussions.

Zvezdin commented 2 years ago

Would love to see such an implementation too!

ale5000-git commented 1 year ago

mar-v-in has implemented Fido in recent commits, but I don't know the current status (if it is already usable or not).

mar-v-in commented 1 year ago

We now have support for WebAuthn on master (and the nightly build at https://microg.org/dl/core-nightly.apk) if you use Chromium, Chrome or Firefox. The implementation can connect to U2F / CTAP1 compatible USB devices or use the secure element in the phone itself (where available and only if screen lock is configured).

This leaves the open tasks:

CTAP2 protocol
NFC connectivity
Bluetooth connectivity
caBLE connectivity: use the secure element of your Android device as a WebAuthn token on your desktop browser
Non-privileged Fido API (use Fido token outside browsers)

Tasks 1-3 I didn't work on yet due to not having compatible hardware available yet. Task 4 is largely undocumented functionality as of now. For Task 5 I am not aware of any apps using it, please point me to any such app if you happen to know one.

nh2 commented 1 year ago

Tasks 1-3 I didn't work on yet due to not having compatible hardware available

@mar-v-in Which hardware do you need? For (2), would a Yubikey NFC work? If yes, I'm happy to sponsor one.

qcasey commented 1 year ago

The implementation can connect to U2F / CTAP1 compatible USB devices

This is huge. I'd also happily sponsor hardware.

nsp-devel commented 1 year ago

Is 5) needed for captive "mini-browser" uses? If not, it's quite exotic and can be put at the low end of the priority list. The one use case really out of browser I see in real life is openSSH where you can create keys that are secured with passphrase+FIDO2 hardware - you tap the hardware key every time you use the SSH key to log in.

You will only need a server with OpenSSH 8.2p1+ for that (https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html) , and an SSH client supporting the protocol. Looking at Google Play, not sure if there's an app supporting FIDO2 mode yet. If you get openssh in client mode running on your test device, it should be able to cope. The key types are called "sk-ecdsa-sha2-nistp256@openssh.com" etc.

Of course, if 5) is needed in the captive mini-browsers, then it's much higher priority as apps typically fire up the mini-browser for the SSO step.

luken-dev commented 1 year ago

Hey. I got hyper-excited about this, and decided to test signing into Google Mail on the nightly build with YubiKey, and unfortunately it didn't let me finish the flow. I got asked whether I'm allowing Firefox to use the key, then I got asked how I want to use the key. I chose the USB option and then I got asked whether I'm allowing microG to access YubiKey, the prompt didn't change from connect the key to touch the key, and the key didn't flash as it normally does on a PC. Touching the key acted as if I clicked "change how to use your security key" on YubiKey Series 5. On YubiKey FIDO (the blue one) nothing happened. It got stuck on the connect the key screen.

Tested on OnePlus 3T, LineageOS 18.1 with microG, build dated 18th July 2022.

Happy to keep testing if needed.

Screenshot_20220810-220713__microG_Services_Core Screenshot_20220810-220812_microG_Services_Core Screenshot_20220810-220822_System_UI

mar-v-in commented 1 year ago

Hi @luken-dev, thanks for the feedback. Can you provide logcat logs from the moment of attempting to use the key? I've succesfully tested this with a Yubikey 4 series device, but it's not unlikely that there are some differences that cause incompatibility with 5th series Yubikeys.

(The "change how to use your security key" button being pressed when touching the key is probably caused by the key operating in OTP mode - which means it's simulating a keyboard and typing in a bunch of characters, confirmed with pressing the enter key)

mar-v-in commented 1 year ago

I got hands on a FIDO key (not Yubikey 5) that also failed to work and fixed it, maybe it's the same issue as Yubikey 5. The fix is on master/nightly now.

daniellandau commented 1 year ago

I can't get it to fully work with either of the FIDO keys I have

Log with Yubikey (apparently 4):

08-11 15:31:21.874 17761 17761 D FidoUsbHandler: Trying to use Yubikey 4 OTP+U2F+CCID for SIGN
08-11 15:31:21.874 17761 17761 D FidoUi  : USB status set to waiting-for-user (Bundle[{device=UsbDevice[mName=/dev/bus/usb/001/003,mVendorId=4176,mProductId=1031,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=Yubico,mProductName=Yubikey 4 OTP+U2F+CCID,mVersion=4.37,mSerialNumberReader=android.hardware.usb.IUsbSerialReader$Stub$Proxy@230b242, mHasAudioPlayback=false, mHasAudioCapture=false, mHasMidi=false, mHasVideoCapture=false, mHasVideoPlayback=false, mConfigurations=[
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbConfiguration[mId=1,mName=null,mAttributes=128,mMaxPower=15,mInterfaces=[
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=3,mSubclass=1,mProtocol=1,mEndpoints=[
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=129,mAttributes=3,mMaxPacketSize=8,mInterval=10]]
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbInterface[mId=1,mAlternateSetting=0,mName=null,mClass=3,mSubclass=0,mProtocol=0,mEndpoints=[
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=4,mAttributes=3,mMaxPacketSize=64,mInterval=2]
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=132,mAttributes=3,mMaxPacketSize=64,mInterval=2]]
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbInterface[mId=2,mAlternateSetting=0,mName=null,mClass=11,mSubclass=0,mProtocol=0,mEndpoints=[
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=2,mAttributes=2,mMaxPacketSize=64,mInterval=0]
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=130,mAttributes=2,mMaxPacketSize=64,mInterval=0]
08-11 15:31:21.874 17761 17761 D FidoUi  : UsbEndpoint[mAddress=131,mAttributes=3,mMaxPacketSize=8,mInterval=32]]]]}])
08-11 15:31:21.875 17761 17761 D FidoCtapHidConnection: Opening connection
08-11 15:31:21.875  2369  2839 D OpenGLRenderer: endAllActiveAnimators on 0x7517689d90 (RippleDrawable) with handle 0x74373f7280
08-11 15:31:21.877 17761 17761 D FidoCtapHidConnection: Sending CtapHidInitRequest(nonce=q/4RwucpC4I=) in 1 packets
08-11 15:31:21.877 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.882 17761 17761 D FidoCtapHidConnection: Sent packet /////4YACKv+EcLnKQuCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.883 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.883 17761 17761 D FidoCtapHidConnection: Reading 64 bytes from usb
08-11 15:31:21.886 17761 17761 D FidoCtapHidConnection: Received packet /////4YAEav+EcLnKQuCAFgAAQIEAwcBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.887 17761 17761 D FidoCtapHidConnection: Received CtapHidInitResponse(nonce=0xq/4RwucpC4I=, channelId=0x580001, protocolVersion=0x2, version=4.3.7, capabilities=0x1) in 1 packets
08-11 15:31:21.889 17761 17761 D FidoCtapHidConnection: Sending CtapHidMessageRequest(U2fAuthenticationRequest(controlByte=0x7, challenge=phxm0Reh799O1N0HMLgNTX1MxcozyBbGn1x2kCfa5ZU=, application=OusAJGA4HG8ljoOV0wJvVx8NmnZIjc2DdjmxOu0xZWA=, keyHandle=m2aYsXCKBuqKpJ5JuSHVSLW7d2jJva148DJji7/s5yCZyB3Z+6e9ooW6su4GoM0ijpoQUShre29HzIUXXrGapg==)) in 3 packets
08-11 15:31:21.889 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.891 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAYMAiAACBwAAAIGmHGbRF6Hv307U3QcwuA1NfUzFyjPIFsafXHaQJ9rllTrrACRgOBxvJY6DldMCb1cfDQ==
08-11 15:31:21.893 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQCadkiNzYN2ObE67TFlYECbZpixcIoG6oqknkm5IdVItbt3aMm9rXjwMmOLv+znIJnIHdn7p72ihbqy7g==
08-11 15:31:21.897 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQEGoM0ijpoQUShre29HzIUXXrGapgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.897 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.897 17761 17761 D FidoCtapHidConnection: Reading 64 bytes from usb
08-11 15:31:21.911 17761 17761 D FidoCtapHidConnection: Received packet AFgAAYMAAmqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.911 17761 17761 D FidoCtapHidConnection: Received CtapHidMessageResponse(statusCode=0x6a80, payload=) in 1 packets
08-11 15:31:21.912 17761 17761 D FidoCtapHidConnection: Sending CtapHidMessageRequest(U2fAuthenticationRequest(controlByte=0x7, challenge=phxm0Reh799O1N0HMLgNTX1MxcozyBbGn1x2kCfa5ZU=, application=OusAJGA4HG8ljoOV0wJvVx8NmnZIjc2DdjmxOu0xZWA=, keyHandle=yog1Cf4zYgy7zk5byOmdUQtV89g1SXpF1L2VgarDdktwriH4wvnwn3In9YGeOKQz)) in 3 packets
08-11 15:31:21.912 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.913 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAYMAeAACBwAAAHGmHGbRF6Hv307U3QcwuA1NfUzFyjPIFsafXHaQJ9rllTrrACRgOBxvJY6DldMCb1cfDQ==
08-11 15:31:21.915 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQCadkiNzYN2ObE67TFlYDDKiDUJ/jNiDLvOTlvI6Z1RC1Xz2DVJekXUvZWBqsN2S3CuIfjC+fCfcif1gQ==
08-11 15:31:21.917 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQGeOKQzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.917 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.917 17761 17761 D FidoCtapHidConnection: Reading 64 bytes from usb
08-11 15:31:21.919 17761 17761 D FidoCtapHidConnection: Received packet AFgAAYMAAmqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.919 17761 17761 D FidoCtapHidConnection: Received CtapHidMessageResponse(statusCode=0x6a80, payload=) in 1 packets
08-11 15:31:21.919 17761 17761 D FidoCtapHidConnection: Sending CtapHidMessageRequest(U2fAuthenticationRequest(controlByte=0x3, challenge=phxm0Reh799O1N0HMLgNTX1MxcozyBbGn1x2kCfa5ZU=, application=OusAJGA4HG8ljoOV0wJvVx8NmnZIjc2DdjmxOu0xZWA=, keyHandle=m2aYsXCKBuqKpJ5JuSHVSLW7d2jJva148DJji7/s5yCZyB3Z+6e9ooW6su4GoM0ijpoQUShre29HzIUXXrGapg==)) in 3 packets
08-11 15:31:21.919 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.921 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAYMAiAACAwAAAIGmHGbRF6Hv307U3QcwuA1NfUzFyjPIFsafXHaQJ9rllTrrACRgOBxvJY6DldMCb1cfDQ==
08-11 15:31:21.923 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQCadkiNzYN2ObE67TFlYECbZpixcIoG6oqknkm5IdVItbt3aMm9rXjwMmOLv+znIJnIHdn7p72ihbqy7g==
08-11 15:31:21.925 17761 17761 D FidoCtapHidConnection: Sent packet AFgAAQEGoM0ijpoQUShre29HzIUXXrGapgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.925 17761 17761 D UsbRequestJNI: init
08-11 15:31:21.925 17761 17761 D FidoCtapHidConnection: Reading 64 bytes from usb
08-11 15:31:21.941 17761 17761 D FidoCtapHidConnection: Received packet AFgAAYMAAmqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
08-11 15:31:21.941 17761 17761 D FidoCtapHidConnection: Received CtapHidMessageResponse(statusCode=0x6a80, payload=) in 1 packets
08-11 15:31:21.941 17761 17761 D UsbDeviceConnectionJNI: close
08-11 15:31:21.942 17761 17761 W FidoUsbHandler: org.microg.gms.fido.core.transport.usb.ctaphid.CtapHidMessageStatusException: Received status 6a80
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at org.microg.gms.fido.core.transport.usb.ctaphid.CtapHidConnection.runCommand(CtapHidConnection.kt:143)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at org.microg.gms.fido.core.transport.usb.ctaphid.CtapHidConnection$runCommand$1.invokeSuspend(Unknown Source:15)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:33)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at androidx.lifecycle.DispatchQueue.drainQueue(DispatchQueue.kt:75)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at androidx.lifecycle.DispatchQueue.enqueue(DispatchQueue.kt:112)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at androidx.lifecycle.DispatchQueue.dispatchAndEnqueue$lambda-2$lambda-1(DispatchQueue.kt:100)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at androidx.lifecycle.DispatchQueue.$r8$lambda$G2ay370n_s_ksSHUJaD9zIU8eCw(Unknown Source:0)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at androidx.lifecycle.DispatchQueue$$ExternalSyntheticLambda0.run(Unknown Source:4)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at android.os.Handler.handleCallback(Handler.java:938)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at android.os.Handler.dispatchMessage(Handler.java:99)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at android.os.Looper.loop(Looper.java:223)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at android.app.ActivityThread.main(ActivityThread.java:7664)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at java.lang.reflect.Method.invoke(Native Method)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
08-11 15:31:21.942 17761 17761 W FidoUsbHandler:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
08-11 15:31:21.942 17761 17761 D FidoUi  : USB status set to waiting-for-device (null)
0

Log with a Solo key:

08-11 15:40:30.214 17761 17761 D FidoUsbHandler: Solo 4.1.2 has suitable hid interface 0
08-11 15:40:30.215 17761 17761 D FidoUsbHandler: Solo 4.1.2 has permission
08-11 15:40:34.739 17761 17761 D FidoUsbHandler: Solo 4.1.2 signature does not match
08-11 15:40:34.744 17761 17761 D FidoUi  : USB status set to waiting-for-device (null)

Both of the above are trying to log into github. On the yubico test site I can successfully register and authenticate with the yubikey, but not the solo key.

mar-v-in commented 1 year ago

@daniellandau

For the issue with the Solo key, can you connect it to a linux computer and run sudo usbhid-dump (might need to install usbutils before) and post it here together with the relevant line of lsusb.
The other issue seems to be related to the fact that you have multiple keys registered with the GitHub account. Can you double check that the same Yubikey works when using it on the desktop?

daniellandau commented 1 year ago

lsusb

Bus 003 Device 019: ID 0483:a2ca STMicroelectronics Solo 4.1.2

sudo usbhid-dump -m 0483:a2ca

003:019:000:DESCRIPTOR         1660290566.816009
 06 D0 F1 09 01 A1 01 09 20 15 00 26 FF 00 75 08
 95 40 81 02 09 21 15 00 26 FF 00 75 08 95 40 91
 02 C0

daniellandau commented 1 year ago

Ah sorry just noticed the other question. Yes the Yubikey does work on the desktop for logging in to github

samsapti commented 1 year ago

I have a YubiKey 5 NFC, so I'm happy to help with testing if needed.

rodjul42 commented 1 year ago

Hi, very cool that U2F support is coming. I just tested the latest nightly build. The Yubico U2F demo site works perfectly. However for gmail or bitwarden my YubiKey 5 NFC does not work. After I grant mircoG access to the YubiKey, it seems like the YubiKey starts in the U2F mode (it is barely noticeable), but switches immediately back in the keyboard mode and connect the USB security key.

lorenz commented 1 year ago

Most web-based services stopped using U2F and switched to WebauthN via CTAP2. WebauthN can also work with authenticators just talking U2F, but if the key supports it (the entire YubiKey 5 series does) it will talk to the key using CTAP2, at which point that credential is no longer compatible with hosts just capable of talking U2F. For the FIDO API implementation here to generally work you are kind of required to implement CTAP2.

mar-v-in commented 1 year ago

@lorenz §10.4 of CTAP2 requires that credentials created (registered) using CTAP1/U2F are assertable (can sign in) with CTAP2. Indeed the standard doesn't require credentials created with CTAP2 to be assertable with CTAP1.

Which means that right now, if you register the key with microG, you should be able to sign in everywhere, but if you register with a CTAP2 client (most except for microG) it might not work -compatibility depends on the implementation on the security key.

microg / GmsCore

Support for U2F / Fido2 / webauthn? #849