How does FIDO2 Authenticator Device communicate with Server ?

[Nisha Vashisht]

If I have a FIDO2 Client in a laptop, or any other smart device, and I require that the application be authenticated by the FIDO2 authenticator as present in Mobile Device, how does this communication flow takes place ?

Does FIDO2 Server directly communicates with the authenticator if the list is provided to it by the FIDO2 client or the communication is handled by the client side with the help of CTAP protocols ?

Does the Server directly sends the challenge/response message to mobile device ? or does 1. ) the laptop sends the challenge via the CTAP protocols to Mobile 2) and then mobile sends the response back to laptop and 3) laptop sends the response to the FIDO server.

Please note in this case, our application is running in Laptop and we have external authenticator like Mobile device (which has internet access).

Also does the flow differs if we have a BLE/USB authenticators like google Titan key or yubico keys ?

[Philipp Junghannß]

basically there are 3 components:

1) the Server (aka the backend of wherever you wanna authenticate, aka the website)

2) the "client" (usually the browser or Operating system, in some cases an other application can also play client)

3) the "Authenticator" (the FIDO device)

The server first gives instructions to the client, e.g. on a website with some javascript which the browser can use to either spawn a client by itself or in case of windows 10 1903+ and android, it will call the OS to do it. In the "instructions" you have all the data needed for the client to talk with the authenticator to do its thing like the relying party identifier, the challenge and so on.

The client will then talk to the authenticator using CTAP2 (or in the case of devices back in the U2F era, CTAP1) and gets the signature and all needed. (the client will also tell the user to interact with the device in the way needed to accomplish the task.)

When that part is done the response will be relayed back to the server using the path it came from where the server then can validate the response.

hope it helps,

--
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/1ce6f80e-6300-444d-847b-6cd9135b1b4fn%40fidoalliance.org.

[Nisha Vashisht]

This is ok in case we have both the authenticator and the application in the same environment like BLE, NFC, USB, but what if the application and the authenticator are at remote location. 

Like we have the application at different location and the authenticator is at remote location.

In this scenario how it will happen ?

[Philipp Junghannß]

Generally authenticators in remote locations are not part of the way most services allow to be accessed as user presence is generally enforced in order to prevent malware from having a field day.

Most authenticators have a physical touch area or button you have to interact with, so unless you specialize in Lego Tech or have someone at that remote location to trigger the device.

Something you can do tho is if the authenticator is with you and the client is remote (e.g. if you have a cloud computer) is running USB over IP, but you are getting into weird territory and need to be careful. There's a reason why CTAP only uses close range protocols and in WebAuthn and U2F scenarios you generally dont get away with silent auth.

Regards

[David Chadwick]

I would say there are 4 entities involved, because the user is also involved in the "ceremony" between the authenticator and the user

Kind regards

David

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNqey9YUCWkPR0fr_ZcnZkDVu48SUZ%2B1kB139qcWvMcPBA%40mail.gmail.com.

[Philipp Junghannß]

good point.

User presence involves the user so it makes sense to add that to the flow in some way.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ffc2f418-e8f1-e8fe-c15f-dfc738237300%40kent.ac.uk.

[Nisha Vashisht]

So, in case the authenticator is with the user and the client is remote, then also the communication will be happening via the client device and server. 

So, to summarize, there will be no direct interaction between authenticator and the Server in any scenario. 

Client side is solely responsible for interacting with the authenticator and providing its response to Server.

[Philipp Junghannß]

yup, that's the gist of it. at least the protocol FIDO2 and U2F devices interact with CTAP 1/2 is standing for client to authenticator protocol, you generally go by the client, which is usually your browser.

pretty sure remote wasn't thought of a lot especially due to the need for resistance to malware. and as most FIDO devices dont have a display you cannot even really verify what you are signing.

Regards

[Emil Lundberg]

Correct, FIDO authenticators do not communicate directly with the server. One important reason for this is that the protocol's built-in phishing protection relies on the client to verify the server's origin against the alleged RP ID. If the server were to communicate directly with the authenticator, then there's no guarantee that the challenge being signed was initiated by the legitimate user. We've actually seen real attacks like that against the Swedish BankID system, where fraudsters cold-called people and asked them to confirm an authentication prompt on their phone. This is one reason why FIDO requires that the exchange between server and authenticator must be mediated by the user's client.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNqdrsQF7YYKVE4rV4t8aisW_iGiOC5smXneGMgjYmJ98g%40mail.gmail.com.

--

Emil Lundberg

Software Developer | Yubico

[Dani Mező]

Hi Emil,

What is the information malicious parties can gain upon such an attack you are describing? Isn't the worst that could happen that they just create an additional credential, or obtain a signature (with the authentication ceremony)?
I guess the signature is easier to brute force attack against than a system, but that should still be cryptographically safe even in the wrong hands, no?

Cheers, Daniel

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CANMnvkzjSYcyUO8mZqCLo6NMXsfQOzRCMLoyTus0L%2BH%2BMwC8MA%40mail.gmail.com.

[Emil Lundberg]

Yes, the attacker could obtain a signature and use that to impersonate the user. Here's how an attacker might proceed if the server contacts the authenticator directly:

1. Purchase the domain login.com and set up a fake Google login page at google.login.com.

2. Send an e-mail to a target victim, prompting them to enter their Google credentials at google.login.com.

3. Capture username and password and send them to your server.

4. From your server, send the username and password to the real Google servers.

5. Google's servers send an authentication challenge to the user's authenticator. The user, believing they are correctly logging in, confirms the authentication prompt.

6. Google's servers return the victim's session credentials to your server. You now have control of the victim's GMail account.

This form of attack works against all forms of OTP 2FA, and also against "mobile push" style authentication (BankID is also one example, though some countermeasures have since been added).

FIDO2/WebAuthn prevents this attack since all communication with the authenticator is mediated by the victim's client. Assuming the client is honest (and that HTTPS works as it should), it will detect that the HTTPS domain `google.login.com` does not match the claimed RP ID `google.com`, and stop the attack before the challenge reaches the authenticator.

Note that it's not physical proximity that's the critical point here (though it certainly helps), or that the server<->authenticator communication goes via network protocols. Rather it's that this connection structure is always vulnerable:

  Client <-> Server <-> Authenticator

while this connection structure can be made immune to the above attack:

  Authenticator <-> Client <-> Server