FIDO (Fast IDentity Online):An Introduction To StandardizedScalable Authentication Scheme

Sanjeev Verma

Problem of Managing online Credentials

Password: Issues

• Issues:– Simple Password Selection with insufficient

Entropy– Difficult to Remember Passwords– Reuse of the Same Password– Phishing– Easily guessed security questions– Malware

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.

SSO

Federation

Authentication

User Management

Physical to Digital Identity

Scope of FIDO Alliance

Identity and Authentication

Components in a complete Identity-based eco-system

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

Real World Keys

Virtual World Keys

Unlock

Virtual World ( Web)

Real World

Know

Have

Are

Authentication Mechanisms

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

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.

Taken From FIDO Alliance official white paper

FIDO Solution

FIDO Use Case-1

FIDO Use Case -2

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

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)

Taken From FIDO Alliance official white paper

FIDO UAF

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.

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

FIDO UAF High-Level ArchitectureTaken From FIDO Alliance official white paper

USER DEVICE: UAF FIDO COMPONENTS

FIDO Client Side Implementations

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

RP Client Application

FIDO Client

ASM

Authenticators

User Verification

Secure Display(optional)

Attestation Key

AuthenticationKeys

UAF Protocol(over TLS)

AuthenticatorCommands

ASM APIFIDO Authenticator

FIDO APIs

FIDO Client SideImplementation

Relying Party

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

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.

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

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

Multiple Implementation Scenarios

REE (Android) REE+SE REE+TEE+SETaken From FIDO Alliance official white paper

Relying Party: FIDO Components

FIDO Server Side Implementations

• FIDO Server Side– Relying Party Web App– FIDO Server– FIDO Authenticator Metadata

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.

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.

FIDO UAF PROTOCOL

FIDO UAF Protocol

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

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.

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.

UserAgent Web

App

Authenticator

FIDOClient

FIDOServer

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

FIDO Client

FIDO Server

User

Login to RP Web Application

If you have these Authenticators Register them.

Here is a proof of possession of thisAuthenticator type and new key generated for this A/C.

Select an Authenticator

FingerprintAuthenticator

FaceAuthenticator

IrisAuthenticator

TPMAuthenticator

Registration Message Flow

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.

UserAgent Web

App

Authenticator

FIDOClient

FIDOServer

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 ResponseUser’s RP Web App Specific Public Key

Authentication Phase

FIDO Client

FIDO Server

User

Initiate an Authentication

If you have these Authenticators Authenticate with them.

Authenticate Response from eachAuthenticator

Authenticate to Authenticator(s)

FingerprintAuthenticator

FaceAuthenticator

IrisAuthenticator

TPMAuthenticator

Authentication Message Flow

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.

UserAgent Web

App

Authenticator

FIDOClient

FIDOServer

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 AppSpecific Private Key

Verify User, Display Text &Unlock Private Key(Specific to User & Web App)

Validate Response &Text Hash UsingUser’s RP Web App Specific Public Key

Secure Transaction Confirmation Phase

Authentication Versus Transaction Confirmation

Authentication1. 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 Confirmation1. 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.

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.

FIDO Client

FIDO Server

Contact Relying Party Application

Deregistration Message Flow

Deregister This AuthenticatorDelete local registrationData

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.

FIDO Universal 2nd Factor (U2F)

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.

FIDO Client

FIDO Server

U2FDevice

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 Requestfor the origin (RP)

U2F Registration Message Flow

Signed Response(Key-handle*, Public Key forthe origin, Attestation Certificate, signature)

* U2F device encodes the requesting origin into the Key-handle.

(web key-chain)User May Be AskedTo Approve Through aUI.

FIDO Client

FIDO Server

U2FDevice

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 OriginSpecific private key

User May Be Asked to ApproveThrough a UI(e.g. Press a U2F Device Button)

(web key-chain)

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.

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.

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.

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.

Appendix

Replaced by

Physical Wallet

Electro-MechanicalWatches

Physical Keys

Old WorldGadgets

New WorldGadgets

Smart Phone

Smart Watch

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