Using FIDO UAF Protocol to authorize through Push Notifications

  • Gust - Trainee Software Development
    Gust de Backer
    Trainee Software Development

This blog is a result of Gust’s graduation research. 

Passwords are inconvenient because people forget them and they can easily be hacked. In the financial world, it is important to have a secure authentication and authorization method that does not rely on passwords. Therefore, I'm going to explain the following to you: 

  1. How to deploy push notifications as an authorization method. 
  2. Why the FIDO Alliance open standard is important. 
  3. How we deployed push notifications as an authorization method. 

Let's get started... 

What is the most convenient and secure authorization method? 

There are 4 different categories in authentication: 

  • Knowledge-based: based on “what you know”. Examples of this method are a PIN code or a password. 
  • Token-based: based on ownership of “what you have”. Example of this method is a credit card. 
  • Biometric: based on the physical state of “what you are”, like fingerprint or facial recognition. 
  • User doing-based: based on the physical acts or “what you do”, like a keystroke pattern or a voice unlock. 

    After examining multiple authentication methods, these are the top 2FA methods: 

    • SMS codes: receive a code via SMS and enter it somewhere else. 
    • Biometrics: verify yourself with something physical of your body. 
    • TOTP: enter the code (generated from a shared private key) from the authenticator app somewhere else. 
    • Push notifications: authenticate yourself with a unique private key stored securely in an app. 

      From these methods, Push Notifications came out as the safest and convenient authorization method: 

      Push Notifications on mobile

      Source: Medium 

      Of course, a best practice would be not to create your own implementation, but to use standards... 

      Why use FIDO Alliance as an open standard? 

      FIDO Alliance is the current industry standard for simple and strong authentication. Its standard is used by many large companies to provide, instead of passwords, a secure password-less experience to users: 

      FIDO Alliance Password-less

      Source: FIDO Alliance 

      It is simple because: 

      • Users no longer need to remember a password 
      • It works with all devices 
      • One device can be used for authentication 

      It is secure because: 

      • It is based on public-key cryptography 
      • The private keys are not shared and remain on one device 
      • It makes use of biometrics 
      • By using relying party specific keys, no links can be made between different services or accounts 

      All well and good, but how does it work? 

      I am going to explain it to you. 

      How does it work? 

      The FIDO UAF protocol offers 4 different operations that can be performed: 

       1. Registration 

      The registration process requires a mobile application with a FIDO client library and a server where the public key can be stored. To start the process the user must be first logged in through the application: 

      Registration FIDO UAF Protocol

      Source: FIDO UAF Protocol Specification

      Step 1: After logging in with the existing credentials (+ 2FA method), the mobile application initiates a request to the server. 

      Step 2: The mobile application receives the response and prompts the user with a push notification to verify that the device may be used for authentication. 

      Step 3: If the user approves the push notification an asymmetric cryptographic key pair will be generated. 

      Step 4: The private key will be securely stored on the users mobile device and the mobile application will send the public key back to the server where it is stored next to the authenticated user. 

      This process marks the device as trusted to authenticate. 

      2. Authentication 

      Authentication FIDO UAF Protocol

      Source: FIDO UAF Protocol Specification

      Step 1: After initiating an authentication request a unique, securely random, short-lived, and one-time use transaction identifier will be created by the server.

      Step 2: A push notification will be sent to the user’s registered device with the identifier as part of the notification request payload. 

      Step 3: After receiving the push notification on the mobile device the request will be verified by checking if the request is valid. That will be done by sending a request to the server to see whether the incoming payload is stale or invalid. 

      Step 4: After approving the push notification the application will use its private key to sign the request payload that was obtained in the first step and will send the cryptographic signature and transaction identifier back to the server to verify. (Denying an attempt will follow the same path.) 

      Step 5: If the server verifies the signature with the user's public key, then the attempt will be approved. 

      3. Transaction 

      Transaction FIDO UAF Protocol

      Source: FIDO UAF Protocol Specification

      The difference between authentication and a transaction is that in the case of authentication the user confirms a random challenge and in the case of a transaction the user confirms a human-readable content to create a What You See Is What You Sign (WYSIWYG) scenario. 

       4. Deregistration 

      06.Deregistation-FIDO-UAF-Protocol.png

      Source: FIDO UAF Protocol Specification

      If the user chooses to deregister their device, the private key will be deleted on the client-side and the public key on the server-side. If the user chooses to deactivate the 2FA method via their account then it will only delete the public key, which automatically makes the private key unusable. 

      What are the advantages? 

      eBay nicely describes it: 

      • The public key is only shared with the server, there are no shared secrets. The private key will never be sent from the client to the server. 
      • The system is not vulnerable to server-side attacks, because the server only stores the public key.
      • There will be no sensitive data passed over the wire, because during the authentication process, only signed data along with the transaction identifier will be sent to the server.
      • The payload of the push notification doesn't need to be encrypted, because it only contains a transaction identifier. Therefore, there is no need for a complex setup of end-to-end TLS.
      • As long as no secret or sensitive data is sent over the wire, FIDO UAF is not susceptible for man-in-the-middle attacks.
      • FIDO2 is the second iteration for simpler and stronger authentication, FIDO 1.0 was the first.
      • It is not just a 2FA product, but it is the basis of passwordless authentication, step-up authentication, trusted device management, and much more. 
      • GDPR-proof, because no transmission of biometric data to the relying party is necessary.
      • Protection against cloned authenticators and fraud, because the amount of signs is counted.

      How did we implement it? 

      During my internship, I worked on the Micropayments SaaS Platform (MSP), and my assignment was to find a secure and convenient method to authorize a micropayment. 

      Using the eBay code as a foundation, I made a Proof of Concept that also integrates the requirements ISAAC had for the MSP (see video below). With this Proof of Concept and my research, I was able to prove that Push Notifications according to the FIDO UAF Protocol are a feasible solution to authorize micropayments. 

      Please accept marketing cookies to view this content.