1

During registration, the authenticator response includes a public key and attestation data as can be seen at https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Registration.html. The attestationObject in step 4 is changed to AuthenticatorAttestationResponse in step 5. Why doesn't authenticator directly generate AuthenticatorAttestationResponse or we just send attestationObject in step 5.

tarun14110
  • 940
  • 5
  • 26
  • 57

2 Answers2

4

This is a good question and to answer this we need to understand the roles of all FIDO components. In FIDO protocols there are three main components:

  • Server(aka RP) - Initiates authentication session, and so it's responsibility is to generate good challenge, and correctly validate the response.

  • Client(aka Browser) - Ensures session security(aka TLS) and provide logistics to communicate to the device via available transports(NFC/USB/BLE). All of these functionalities are packaged into Webauthn API.

  • Authenticator(Security Keys and Built-in Platform Authenticators) - provides key management and user verification.

Each component has its own limitation:

  • Server does not know what user sees, so it entrusts Client/Browser to do a good job in enforcing TLS.
  • Browser does not deal with private keys, or does user verification, so it hopes, that authenticator is sufficiently secure.
  • Authenticator hopes that browser was not exploited, and that attacker.xom was not able to substitute RPID.

Which is why when server generates MakeCredential request with a challenge and calls Webauthn API, what browser does is:

  • Checks that TLS session is OK. There was no MITM, and it's not HTTP.
  • It them checks that request RPID(login.example.com wants to login on behalf of example.com) is permitted and not out of security scope.
  • It then calls all available devices to see if any of them knows the specified credential, and if it does, it will wait till user performs some action, like tapping a button, or swiping a finger.
  • When operation succeeds it will take the response, and based on attestation option, none/direct, it will remove attestation information or keep it, and then check if no privacy problematic fields are went to server(CTAP2.1 CredBlobKey extension)
  • Browser then encodes the remaining attestation structure and attaches session information(CollectedClientData) and sends it to the Server
  • Server decodes the attestation and clientDataJSON and validates that responses did not cable from ATATACKER.XOM, but from expected origin, example.com.

So in conclusion:

  • Authenticators are signing stuff
  • Browsers are making sure that your TLS session is secure and no Russian Hackers have tried to spoof you.

Useful resources:

Ackermann Yuriy
  • 537
  • 3
  • 10
  • 1
    I knew you'd be along and provide a lot more detail ;) – mackie Sep 28 '21 at 08:37
  • 1
    Long answers is mah drug! XD – Ackermann Yuriy Sep 28 '21 at 17:27
  • 1
    Thanks for the answer @AckermannYuriy. Can you please explain the 4th step "When operation succeeds it will take the response, and based on attestation option, none/direct, it will remove attestation information or keep it, and then check if no privacy problematic fields are went to server(CTAP2.1 CredBlobKey extension)". 1. Why authenticator creates attestation if attestation is none. 2. What exact "privacy problematic fields" are not sent to the server and why the browser receives them from authenticator? – tarun14110 Oct 04 '21 at 00:14
  • 1
    @tarun14110 1. Device always generates attestation. It is mandatory functionality of the FIDO device. 2. Attestation is a way to identify device model. Is it really Yubikey/Feitian/Trustkey? This is done using Batch Attestation certificates. The certificates and privatekey is signed by manufacturer and installed on every single device. During MakeCredential device signs response with he attestation private key and attaches batch certificate to the response. The server then can use it to validate attestation and knowing trusted root it can ensure that device is genuine – Ackermann Yuriy Oct 04 '21 at 08:39
  • 1
    However the problem is that what happens when certificate is leaked? Well now you can make fake security keys with built-in vulnerabilities and no one will be able to distinguish them from real, which is why the name of the certificate is BATCH, because it implies a size limit. FIDO mandates that there must be one certificate per 100,000 devices. The reason for that is if it's too big, the severity of the impact is huge. If it's too small then device becomes a hardwire tracker, which is why privacy. Every device gives you 1/100,000 point that can be used together with other info to track you. – Ackermann Yuriy Oct 04 '21 at 08:41
  • 1
    Which is why Browsers strip attestation. Attestation is useless in 99% of the cases. You simply do not need it. But in 1% of the cases it is invaluable, which is why if you need it, you must request explicit user permission via attestation: direct. If you want more in-depth read, take a look at this article https://medium.com/webauthnworks/webauthn-fido2-demystifying-attestation-and-mds-efc3b3cb3651 – Ackermann Yuriy Oct 04 '21 at 08:45
0

My guess is "because separation of concerns".

The FIDO2 standard is made up of:

W3C WebAuthn: https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/

FIDO Alliance CTAP2: https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html

The former governs how browser applications interact with the lower levels and the latter controls how the browser/OS interacts with compliant authenticators.

To support this layering there will neccessarily be some mapping and translation going on just as there is to allow WebAuthn data structures to be serialized as JSON to go over the wire.

mackie
  • 4,996
  • 1
  • 17
  • 17