FIDO Clients on the OS Level

[My1]

So there are at least 3 instances where there are FIDO Clients (as in the side that takes high level commands from e.g. webauthn and translate them into CTAP calls) on the OS Level rather than the application levels, and I am not sure what I should think of those as the 2 I do have experience with hinder FIDO in enough ways while making it somewhere between hard and impossible for applications to easily go their own route and do it properly.

1) Windows 10 1903+: While they add the capability of BLE and NFC compared to the application-side clients I am aware of, they are severely cutting features on other places like when doing RK signin with multiple options for a Relying Party, the list gets cut to 20 elements, the CTAP2.1 Credential management is also missing, and instead of properly passing through hmac-secret and likely any other authenticator extensions, they just arbitrarily remove it, and any interaction with FIDO devices that cannot go through this interface requires the application to run as administrator, something that not only isnt always possible, also undesirable, as that means an application gets way more permissions than it would actually need normally on Linux or an older version of Windows.

2) Android: CTAP1 aka U2F only, meaing most of the FIDO2 Feature spec (UV, Resident keys, hmac-secret, and so on) are all unavailable, and while I am frankly not sure how much it takes to sidestep the Google-API and do CTAP on your own, this is really annoying since it is basically impossible to log into places you have set up passwordless with UV, unless you temporarily un-enforce the UV or find another method to log in, so you can register a platform credential, which miraculously can do UV.

3) iOS: not my personal experience but from what I heard using FIDO outside of safari is basically impossible unless you use a Yubikey as iOS runs a severe lockdown on devices it can interact with, making FIDO support in applications also not overly fun.

I personally think that while well intentioned (e.g. windows tells you clearly which application is requesting FIDO and telling the user what's going on in regard to attestation and RK signup), they are actually counterproductive since updates to these likely need an OS update which is especially on mobile not a process that goes on for too long and applications are left with what there is.

For example KeepassXC has an open issue to use HMAC-secret for decryption of the database, however due to windows10 forcing itself in, not do standard libraries like libfido2 not work, the needed functionality is not given, which especially given HMAC-secret being an authenticator extention without any relation to the client, should not happen, this is currently on halt which is not something I personally think should be going on.

[Eldan Ben Haim]

On android  there’s 

https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/Fido2ApiClient which seems to communicate using CTAP2...

On iOS — I think there’s no OS Level FIDO client 

A platform level client also has a benefit — it allows sharing platform attached authenticator credentials among apps (Eg different browsers in Windows, and browsers and apps on android). 

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d49dbed7-1aa8-4ebf-b7ba-921745686dddn%40fidoalliance.org.

[My1]

does it actually communicate over CTAP2tho? the only place where I have seen actual CTAP2 with PIN and stuff on android is the "hardware security SDK" (https://hwsecurity.dev/fido2/), which considering it is a commercially sold SDK rather than an open source library, sounds like it is a lot of effort, and is likely a lot harder than on PC where you have libfido2 and the big part is done already.

after all for example chrome does clearly not as for example a eWBM/Trustkey G450 lights up orange which is a clear sign of classic U2F/CTAP1 (on CTAP2 it lights up blue or cyan). the API is also called FIDO2, which is a very loosely defined term, and basically means "the ctap protocols", WebAuthn, or any cobination thereof, so it is technically still FIDO2 even if there is CTAP1 involved.

https://twitter.com/FIDOAlliance/status/1268972883814100992

https://twitter.com/FIDOAlliance/status/1356944500837515264

on iOS okay there may not technically be a seperate client (as said I dont exactly have experience with fido on ios) but still the landmarks of it are there in the way that the OS is restricting FIDO in quite a big manner.

regarding sharing the platform credentials among applications, does that really need a full CTAP client, which also disallows applications to talk directly to roaming ones? because I would normally think that the platform can open an API to the platform and the user and RP get to choose what gets actually used so the client can choose whether it calls the platformauthenticator API or just calls CTAP directly.

[Dominik Schuermann]

Hey,

just FYI: If you like to use the Hardware Security SDK in your open
source project: We offer a GPLv3 version at
https://github.com/cotechde/hwsecurity

You only need to buy a license if you like to integrate it in a
commercial closed source project.

Cheers
Dominik

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d49dbed7-1aa8-4ebf-b7ba-921745686dddn%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org

> <mailto:fido-dev+u...@fidoalliance.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d036c696-bf82-4239-ad5f-f767ca41fac2n%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d036c696-bf82-4239-ad5f-f767ca41fac2n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[John Bradley]

Allowing arbitrary applications to interact with a security key is a problem.   Those applications can specify any rpID and potentially engage in man in the middle attacks.  

That is why on windows only apps with admin privileges can talk to authenticators.   

So I would make the counter argument for security only privilaged fido clients should talk to authenticators.

On the HMAC issue that extension was designed to enable desktop login to windows.  The response is encrypted to the platform and not the RP if you read it carefully.   The web RP never gets the response.

You are probably saying but it would be useful to so many RP that want to encrypt data. You would be largely correct in that.   In WebAuthn a new extension was proposed to enable WebRP to use the existing CTAP2.0 extension and be able to get a decrypted response.

Unfourtunatly Mozilla blocked the extension on WebAuth charter and some other issues so it was removed from WebAuthn level2.

Hopefully with the current WG recharter that work will be able to go forward in WebAuthn level 3.   There are some additional complications when it is an RP as the platform was in a privilaged position to see the credentialID before making a final getAssertion with the extension so it knows what seeds to send.

A web based RP would need to send a seed list for all credentialID if it wants to maintain a per authenticator seed list.   These are some of the issues the new extension for RP use of the HMAC extension.  

So for the moment Windows and Chrome are functioning as intended. 

Yes platforms move slowly. 

The webAuthn API on Android is redicoulusly behind and Google is reminded of that by me and others every week.   They have not yet publicly announced an availability date for CTAP2 or probably now CTAP2.1. 

For the moment people are using workarounds on Android to be able to support authenticators with multi-factor.  They work for now but will likely get blocked for security reasons once GMS is updated with a new API.

For Apple they initially believed that invoking Safari in the app to do authentication would be sufficient.  That works but developers have not been super happy about that pattern.   I expect that they will eventually release an API like windows for apps.  They still have buggs in what they have that really need fixing. 

Apple hasn't blocked anything on iOS so apps can use NFC directly to talk to authenticators with the correct libs.   Lightning is more complicated as HID needs to be tunneled through licenced MFi to work.  I believe the only authenticator that an app can talk to directly over lightning is the Yubico 5Ci as they pay the apple licensing for the connector and chip.  The MFI licencing thing you need to talk to Apple about. 

So no it is not ideal but the platforms need to improve.  The solution is not to go the other way and allow all apps to bypass the platform.

Regards

John B. 

 

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d49dbed7-1aa8-4ebf-b7ba-921745686dddn%40fidoalliance.org.

[Philipp Junghannß]

I can see the security point, but I see 2 problems with that.

1) such a bridge should be also able to accept ctap requests directly and just pass them to the FIDO device while doing the other stuff like showing the Requesting RP and so on, without arbitrarily axing stuff. and regarding HMAC I am not necessarily just talking about Webauthn, as for example keepassxc could just call CTAP directly if windows wouldn't be blocking that, I mean there are many things that could be done either on new versions or by vendor extensions/commands, which applications would always require admin level, a user who doesn't have admin permissions himself should still be able to let applications access Fido devices if he wants to do that, as the device has no relation to the computer.

2) the requested permission is way too broad and having admin perms allows an application to do literally everything on any given system, rather than asking for example "allow application xy to access your security keys?" or as I stated in number 1, just act as a CTAP proxy that does not arbitrarily ax extensions and stuff, see and block, sure, but do not modify, also after the initial request has been made, how about not arbitrary limit follow ups to that request, like for example with the RK listing, it's very unlikely it comes up in practical use but I still dislike the fact that windows just arbitrarily cuts off RKs at 20.

honestly I wouldn't be complaining if platforms would not outright suck in the way they do.

[John Bradley]

The proxy needs to validate the identity of the calling app.  There are also a lot of things involved with the pin protocol that need to be in the lower layer.  

It is the pin protocol session key that encrypts the results of the HMAC.  So passing the information through is more complicated that it looks on the surface. 

It is however not super complicated and platforms should be doing a better job at providing those API.  Perhaps the more developers ask the more seriously they will take it.

Regards

John B. 

[Philipp Junghannß]

but would the proxy need to mess with the CTAP calls just to verify who's calling? I mean can't the system just check which process called the CTAP API and check that? not sure how the pin protocol works in depth but couldn't the system just play an active MITM then so the encryption goes program -> system -> Device, at least when the CTAP client on the program isn't getting some kind of attestation when doing the pinproto stuff, I wouldn't consider it out of reach, and even if it is, as long as the commands are not encrypted, the important part of what the proxy is supposed to do (check who's calling and let the user interfere if needed) it would not need to MITM the pinproto session.

[John Bradley]

It needs to create the collected data and verify the rpID is correct for the app calling it.  

You should have a CTAP2.1 RD03 spec in a couple of days.  (Atleast the WG should approve it tomorrow and the board after that). 

That has a bit more detail on what the platform is doing, than what was in CTAP2.0.  

You also need to consider the apps access to the platform authenticator that needs to be mediated by an API.

It however is not me that needs convincing it is the platforms. 

I well appreciate that things could be better.  

But we have made significant progress in platform adoption from what we had in U2F.

We just need to keep making progress.  So keep the pressure on the platforms, but don't underestimate the work that is needed. 

Regards

John B. 

[Philipp Junghannß]

but what defines whether an rpid is "correct" for an automatic check by the system? Like I do not expect the OS to have any Idea about what an app is doing to properly handle all that.

I would normally have said to show the RP to the user along with the calling application, and let the user decide whether to stop. After all, for example an alternative browser for example should obviously be able to access all RPIDs, as that is plausible for it to happen, and I do not want to play an Apple and outlaw alternative browsers all of a sudden.

Also for applications with only their own domain, based on what are they supposed to pin themselves? Code Signing Certificates (similar to android)? Well, unlike on android where apps are often self-signed, that would immediately lock down the API for anyone in the open source, hobby, indie, or otherwise small budget space, as code signing certs on PC are expensive and annoying to get.

And in fact, how are browsers supposed to call the native FIDO api to a domain if they are not able to get domain owners to whitelist the browsers on android?

and how are applications with no web context and only themselves are supposed to act, for example keepassxc, which could use FIDO2 with HMAC to get an unlock key for a password database.

I personally think that an automatic verification of RPs is something that cannot be done easily, and it should just say what application is asking for what domain, and that's it, no trying to be "smart".

Regards, My1

[John Bradley]

The native API provided by the platform is not part of the W3C or Fido specificaitons.

That is defined by the platform vendors themselves.

Thre are currently two public ones.

Android (Yes it is missing CTAP2 functionality for extenal keys currently)

This uses digital asset links to share RPID between apps and webRP. 

The documentaiion will do a better job than I can explaining it. https://developers.google.com/identity/fido/android/native-apps

Your next question will be how do 3rd party browsers like FireFox work.  There is a whitelist of browsers that google maintains that allows some special trusted browser apps to specify arbitrary RPID.   This is the case with FireFox however Mozzilla broke the Webauthn code on Android independently in switching some of there underlying code and it reamins broken to my knoledge.

Windows 10,

All the browsers (including Chrome) use webAtuhn.dll, this gives them acess to both the platform and roaming authenticators. 

App signing on windows is not all that it could be, so win32 apps names are displayed in the dialog, but I don't beleve at the moment that anything is used to validate the RPID.

Apple currently has an non native API approach

Native apps are expected to do authentication in a SFSafariViewController or ASWebAuthenticationSession and those use the RPID of the web page loaded.

I would expect when/if Apple releases an API it will be more like Android.

The native API are to the frustration of some outside the standards process.

Regards

John B.