This document provides an introduction to FIDO (Fast IDentity Online), a standardized authentication framework that enables scalable and faster access to web resources without requiring users to remember complicated passwords. It discusses problems with traditional password-based authentication and outlines FIDO's two main specifications: UAF (Universal Authentication Framework), which supports passwordless authentication using built-in authenticators, and U2F (Universal Second Factor), which adds a second factor of authentication to password login. The document explains FIDO components, protocols, and architecture in detail and provides examples of how FIDO enables secure authentication flows. It also discusses next steps for further standardization and adoption of FIDO.

1. FIDO (Fast IDentity Online):
An Introduction To Standardized
Scalable Authentication Scheme
Sanjeev Verma

2. Problem of Managing online
Credentials

3. Password: Issues
• Issues:
– Simple Password Selection with insufficient
Entropy
– Difficult to Remember Passwords
– Reuse of the Same Password
– Phishing
– Easily guessed security questions
– Malware

4. FIDO (Fast IDentity Online):
What is FIDO?
• FIDO is an authentication framework that
enables
– Scalable and Faster Access to Web Resources.
– Simple way to generate, share and carry digital
identities.
• No need for users to remember complicated
passwords.

5. SSO
Federation
Authentication
User Management
Physical to Digital Identity
Scope of FIDO Alliance
Identity and Authentication
Components in a complete Identity-based eco-system

6. Why Authenticate?
• Authentication
– To unlock devices
• PC, Smart Phone, Tablet
– To unlock Virtual Resources
• Social Networking Sites: Facebook, Twitter, LinkedIn
• eCommerce Sites: Amazon, eBay
• Financial Sites: Banks, Credit Cards

7. Real World Keys
Virtual World Keys
Unlock
Virtual World ( Web)
Real World
Know
Have
Are

8. Authentication Mechanisms
• Authentication Mechanisms
– Password—``Something You Know”
– Hardware Token—``Something You Have”
– Biometric—``Something You Are”:
• Fingerprint, Face, Iris, Voice etc.

9. Why FIDO?
• Fast IDentity Online (FIDO)
– Standardized, Secure & Scalable Authentication
Framework
• Links User, Devices and Virtual Resources.
• User can identity itself to a Virtual Resource without
having to remember passwords.
• Virtual Resource Providers can use industry standard
authentication framework (FIDO) instead of building
proprietary solutions.

10. Taken From FIDO Alliance official white paper

11. FIDO Solution

12. FIDO Use Case-1

13. FIDO Use Case -2

14. FIDO Standards
• FIDO consists of two specifications:
– UAF (Universal Authentication Framework)
• Password less experience
• Supports built-in multiple authenticators
– U2F (Universal Second Factor):
• Needs Password: Login is still needed and hardware
token is used for 2nd factor authentication.
• No UI & User Authentication and Portable.
• (Currently) Supported only by Chrome Browser

15. FIDO Specs Options: UAF versus U2F
Experience
• Password less UX=UAF
(Universal Authentication
Framework):
– User Carries client device
with UAF stack installed.
– User authenticates to device
using Biometrics or PIN.
– Website can choose whether
to retain password.
• Second Factor UX=U2F
(Universal Second Factor):
– User carries U2F device with
built-in support in web-
browsers.
– User presents U2F device
– Website can simplify
password ( e.g. 4 digit PIN)

16. Taken From FIDO Alliance official white paper

17. FIDO UAF

18. FIDO UAF Authentication
• FIDO UAF authentication mechanism is based
on multi-factor authentication and involves
two steps:
– Step1: Generation and Unlocking of Application
Specific Keys through biometric authentication of
the user at device level.
– Step2: Authentication of the user to relying party
using Application Specific Keys.

19. FIDO UAF Architecture
• FIDO UAF Architecture requires
implementation of following components:
– User Device: FIDO components
• FIDO Client
• FIDO Authenticators
– Relying Party: FIDO components
• FIDO Server
• FIDO Authenticator Metadata

20. FIDO UAF High-Level Architecture
Taken From FIDO Alliance official white paper

21. USER DEVICE: UAF FIDO
COMPONENTS

22. FIDO Client Side Implementations
• FIDO Client Side
– Relying Party Application
– FIDO Client
– ASM (Authenticator Specific Module)
– Authenticators

23. RP Client
Application
FIDO Client
ASM
Authenticators
User
Verification
Secure Display
(optional)
Attestation Key
Authentication
Keys
UAF Protocol
(over TLS)
Authenticator
Commands
ASM API
FIDO Authenticator
FIDO APIs
FIDO Client Side
Implementation
Relying Party

24. FIDO Client
• FIDO Client software:
– Interacts with FIDO authenticators through UAF
ASM API.
– Interacts with user agent ( e.g. a browser or native
mobile app) to communicate with FIDO server:
– Realized through FIDO-specific browser plugin or
FIDO-specific SDK.
– Can be implemented across a range of platforms
and browsers
• Standardized interface ensures consistent experience

25. FIDO UAF Authenticator Specific
Module (ASM)
• UAF ASM
– Platform Specific Software Component:
• Allows FIDO Client to
– Discover supported Authenticators in a User Device;
– Communicate with Authenticators.
– Provides a uniform API to FIDO clients.
– Provides uniform lower layer “authenticator
plugin” API
• Facilitates the deployment of multi-vendor FIDO UAF
Authenticators and their requisite drivers.

26. FIDO UAF Authenticator
• UAF Authenticator:
– Secure entity in the device
– Can create application specific key for Relying
party
– Carries Attestation key
• Attests
– Type (e.g. fingerprint)
– Capabilities (e.g., supported crypto algorithms)
– provenance

27. Multiple Implementation Scenarios
• Scenario A
– Software Only (Android)
• Scenario B
– Software + Secure Element (micro SD, TPM)
• Scenario C
– Software + Secure Chip (Trusted Execution
Environment) +Secure Element

28. Multiple Implementation Scenarios
REE (Android) REE+SE REE+TEE+SE
Taken From FIDO Alliance official white paper

29. Relying Party: FIDO Components

30. FIDO Server Side Implementations
• FIDO Server Side
– Relying Party Web App
– FIDO Server
– FIDO Authenticator Metadata

31. FIDO UAF Server
• FIDO UAF Server:
– Interacts with the RP Web Server to communicate
FIDO UAF Protocol messages to the FIDO Client via
User Agent.
– Validates FIDO UAF authenticator attestation
against the configured authenticator metadata.
– Manages the associations of registered
Authenticators to the user account at the Relying
Party.

32. FIDO UAF Authenticator Metadata
• UAF Authenticator Metadata:
– Published by FIDO
– Contains authenticator’s attestation public key
certificates located in the authenticator metadata;
– Validates that protocol messages containing keys
and measurement data are coming from devices
with certified characteristics.

33. FIDO UAF PROTOCOL

34. FIDO UAF Protocol
• FIDO UAF Protocol involves following phases:
– Discovery
– Registration
– Authentication
– Secure Transaction Confirmation
– Deregistration

35. Discovery Phase
• Authenticator Discovery:
– This phase does not involve protocol exchange with
Relying Party Server
– Relying party transparently discovers the presence of
initialized FIDO UAF Authenticators in the device:
• Relying Party App can use Discovery APIs to gather this
information and communicate this information to the
Relying Party Server.
– User has an option to decide whether to register a
specific FIDO Authenticator at his/her Relying Party
Account.

36. Registration Phase
• Authenticator Registration:
– FIDO Client application initiates the Registration for a User’s Account at
Relying Party (RP).
– RP asks FIDO Client to register existing authenticators in the User’s device as
per RP’s specified policy of Authenticator selections.
– User is asked to register RP compliant FIDO authenticators. User then decides
to register one or multiple authenticators with his account at RP.
– User then prompted to enroll in each one of selected authenticators.
– Selected Authenticator(s) then generate RP application specific key pair
(Public, Private).
– FIDO client then returns RP application public key certificate signed by the
Attestation key and the Attestation certificate to the RP.
– FIDO server at RP first verifies the response and Attestation certificate and
stores the RP specific public key generated by the authenticator. RP generates
a unique secure ID that binds this key to the authenticator.

37. User
Agent
Web
App
Authenticator
FIDO
Client
FIDO
Server
FIDO
Authenticator
Metadata
User Device
Relying Party
1
2
4
5
3
Initiate Registration
Registration Request
+ Policy
Registration Response +
Attestation+
User’s Public Key
Enroll User &
Generate New Key Pair
(Specific to RP Web App)
Validate Response
& Attestation,
Store User’s Public
Key
Registration Phase

38. FIDO
Client
FIDO
Server
User
Login to RP Web Application
If you have these Authenticators
Register them.
Here is a proof of possession of this
Authenticator type and new key
generated for this A/C.
Select an Authenticator
Fingerprint
Authenticator
Face
Authenticator
Iris
Authenticator
TPM
Authenticator
Registration Message Flow

39. Authentication Phase
• User Authentication:
– User initiates authentication by requesting service.
– RP challenges the client with a random challenge and
asks it to select a certain authenticator(s) for the
requested service in the policy.
– User is prompted to select an authenticator based on
the RP policy.
– User authenticates to the device using the selected
authenticator to unlock RP Web App specific private
key—used to send signed response to the RP.
– RP verifies the signed response using the registered
public RP Web Application key.

40. User
Agent
Web
App
Authenticator
FIDO
Client
FIDO
Server
FIDO
Authenticator
Metadata
User Device
Relying Party
1
2
4
5
3
Initiate Authentication
Authentication Request
+ Challenge + Policy
Authentication Response
Signed by User’s RP Web App
Specific Private Key
Verify User &
Unlock Private Key
(Specific to User & RP Web App)
Validate Response
User’s RP Web App
Specific Public Key
Authentication Phase

41. FIDO
Client
FIDO
Server
User
Initiate an Authentication
If you have these Authenticators
Authenticate with them.
Authenticate Response from each
Authenticator
Authenticate to
Authenticator(s)
Fingerprint
Authenticator
Face
Authenticator
Iris
Authenticator
TPM
Authenticator
Authentication Message Flow

42. Secure Transaction Confirmation Phase
• Transaction Confirmation:
– Message Exchange Similar to Authentication
Phase.
– RP provides a secure message for confirmation if
authenticator supports it
• Basically if Authenticator supports secure display
capability—What You See is What You Sign Mode.
– Message content is decided by RP:
• Can be financial transaction, confirmation of
email/address, releasing patient record etc.

43. User
Agent
Web
App
Authenticator
FIDO
Client
FIDO
Server
FIDO
Authenticator
Metadata
User Device
Relying Party
1
2
4
5
3
Initiate Transaction
Authentication Request
+ Transaction Text
Authentication Response +
Text Hash Signed by
User’s RP Web App
Specific Private Key
Verify User, Display Text &
Unlock Private Key
(Specific to User & Web App)
Validate Response &
Text Hash Using
User’s RP Web App
Specific Public Key
Secure Transaction Confirmation Phase

44. Authentication Versus Transaction
Confirmation
Authentication
1. With Authentication the
user confirms the random
challenge.
2. Only Application needs to
be trusted once the
authenticated channel is
established.
3. It is suitable for actions
with low risk
consequences.
Transaction Confirmation
1. With Transaction Confirmation
the user also confirms human
readable content.
2. In case of Transaction
Confirmation, only the secure
display component
implementing WYSIWYS needs
to be trusted instead of entire
application.
3. This method is suitable for high-
value transactions, where non-
repudiation is required.

45. Deregistration Phase
• Deregistration:
– Relying party considers that a certain keying
material is not valid anymore.
– Relying Party tells a FIDO authenticator to forget a
specific piece ( or all) locally managed keying
material associated with a specific account.

46. FIDO
Client
FIDO
Server
Contact Relying Party Application
Deregistration Message Flow
Deregister This Authenticator
Delete local registration
Data

47. Advanced Usage: Step-Up
Authentication
• FIDO Supports Step-up authentication:
– For example
• User can login into bank with basic website login—only
can see account information.
• User may want to wire transfer money. Bank can now
ask the user to go through Biometric authentication.
– Can proceed in several steps with higher-
assurance steps with increasing transaction value.
– RP can implement risk analysis engine to support
sophisticated step-up authentication mechanisms.

48. FIDO Universal 2nd Factor (U2F)

49. FIDO U2F Protocol
• FIDO U2F:
– Adds 2nd Factor to Password-based Infrastructure of
Relying Parties (RPs).
– The presence of strong 2nd factor enables RPs to allow
simple password.
– Protocol:
• Registration
• Authentication
– U2F device acts as Physical Web Key-Chain
• No concept of a user multiple users can share a U2F device.

50. FIDO
Client
FIDO
Server
U2F
Device
Login to RP Web Application using Password (1st Factor)
Registration Request Message
(challenge)
Registration Response Message
(Public Key for the RP, Key-handle,
attestation certificate, signature)
Key-Pair Generation Request
for the origin (RP)
U2F Registration Message Flow
Signed Response
(Key-handle*, Public Key for
the origin, Attestation
Certificate, signature)
* U2F device encodes the requesting origin into the Key-handle.
(web key-chain)
User May Be Asked
To Approve Through a
UI.

51. FIDO
Client
FIDO
Server
U2F
Device
Login to RP Web Application using Password (1st Factor)
Authentication Request Message
(Key-handle, challenge)
Authentication Response Message
(signature, counter)
Authentication Request
(Key-handle, challenge, origin)
U2F Authentication Message Flow
Signed Response using Origin
Specific private key
User May Be Asked to Approve
Through a UI
(e.g. Press a U2F Device Button)
(web key-chain)

52. FIDO Specifications
• FIDO v1.0
– Publicly available:
• http://fidoalliance.org/specifications/download/
• Public announcement in December 2014.
• FIDO U2F supported by Google, DropBox, Github and
GitLab.
• UAF supported in Samsung Galaxy Phones.
– FIDO Security Certification Program in Progress.

53. FIDO Next Steps
• What is missing in FIDOv1.0:
– Universal distribution of the FIDO Client
– UAF & U2F in Practice:
• UAF has to integrate with OEM.
• U2F only supported by Chrome Browser.
• Ideally
– Every major platform ( Windows, Android, Web,..)
provides “built-in” FIDO API.

54. FIDO 2.0
• FIDO 2.0 defines Abstract APIs for native
Platforms:
– Defines what goes in and comes out of API calls.
– Platform Vendors ( Google, Microsoft and Apple)
to provide concrete APIs
• Follow Abstract APIs support.
• FIDO 2.0 defines Web APIs and standardize it
in W3C:
– FIDO will then become standard feature of all
browsers.

55. FIDO Benefit
• FIDO Specs
– Provides a unified authentication framework that
glues together any device, any authenticator or any
relying party application.
• Allowing relying parties, OEMs and Authenticator Vendors to
meet the authentication needs of various eco-systems in a
cost effective manner.
• OEMs can build innovative authentication solutions for
different eco-systems (eHealth, Mobile Payment etc.) by
integrating appropriate FIDO certified authenticators in its
devices.
– Provides a scalable and faster solution for a user to
generate, carry and manage digital identities.

56. Appendix

57. Replaced by
Physical Wallet
Electro-Mechanical
Watches
Physical Keys
Old World
Gadgets
New World
Gadgets
Smart Phone
Smart Watch

58. Proximity Based Authentication:
Promising Scheme
• Proximity-based Authentication:
– Unlock devices based on proximity.
• Interesting Video by Bionym:
– Uses ECG and Proximity-Based Authentication:
• https://www.youtube.com/watch?v=jUO7Qnmc8vE