GmsCore
GmsCore copied to clipboard
microg
Support for U2F / Fido2 / webauthn?
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
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.
Hi everyone, I was wondering if anybody is currently working on this issue?
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...
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?
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.
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.
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.
+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.
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.
Btw, is there anything wrong with switching microG to GPLv3? Just curious.
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".
Are the microg maintainers against bountys because if not I'd like to put one on this
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.
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/
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.
It still doesn't work with microG tho, I tried it a couple of days ago.
correct
I would also be interested in FIDO2 support.
I added a 20$ bounty for this
Where can I add a bounty?
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
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?
If needed I'd be willing to raise my bounty in order to get a guarantee this feature will be implemented,
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.
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.
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)
Nice to see a milestone added to this. Thanks for prioritizing it somewhat, @mar-v-in. Glad to be a sponsor as well.
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...
@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.
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.