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.
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.
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)
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
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
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.
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.
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.
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.
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.
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.
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.
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
