The FIDO SolutionHow FIDO Works
-
FIDO combines hardware, software and internet services to provide a secure user experience.
FIDO AuthenticatorsA FIDO user will have a FIDO Authenticator or token that they chose or was given to them. This could be any authenticator type that supports FIDO such as a built-in finger scan or a USB memory drive with a password. Users may pick the authenticator type that best suits their needs.
FIDO Authenticators will come in two basic variations.
- Identification tokens will be unique identifiers that can be connected to the user’s internet accounts. Once they are connected to the account, they will be transparently presented each time the account is accessed as an identifier without the user needing to anything else. This will provide single factor authentication.
- Authentication tokens can ask the user to perform an explicit action to prove it is really the token owner. These actions could include entering a password, PIN or finger swipe. These authenticators will provide two factor authentication with the token being “something you have” and the password being “something you know” or the biometric being “something you are”.
When the user connects their FIDO Authenticator to an online account, a relationship is established between the Authenticator, the Relying Party and the Validation Cache. Once the relationship is created the Authenticator and the Validation Cache will only exchange one time passwords (OTP) to validate the other party in communication. Because OTPs are used only once, they cannot be used for replay attacks if someone is capturing communication in a compromised system or by listening to internet traffic.
Each authenticator will have an embedded identifier and seed value that will allow it to be uniquely identified and validated. FIDO Authenticator will encrypt traffic onboard the Authenticator. So, while a machine may be compromised by malware the identity of the FIDO Authenticator can still be trusted.
Browser Plugin
Browsers on the user’s system will have a FIDO plugin. The plug-in will recognize available FIDO Authenticators that are connected to the user’s system. This includes built-in authenticators and USB authenticators that are dynamically inserted.
When the user connects to an internet site the presence of the FIDO Authenticator will be reported to the site as part of the browser information. FIDO-enabled websites will recognize the presence of the authenticator and respond accordingly. The use of FIDO information and triggering authentication challenges is controlled by the Relying party.
The FIDO plug-in will be made available through a variety of channels including:
- Browser Add-On - The browser developers will have this as an add-on that users can download to plug into their browser.
- FIDO authenticators – If a user buys a FIDO authenticator to add to their computer it can come with the plug-in. For example, a FIDO USB memory drive could have the plug-in software on it.
- System Vendors – System vendors can distribute the plug-in with new machines and include the plug-in when they push out software updates to existing machines. These updates will allow existing machines with suitable hardware to be FIDO enabled.
Device Specific Module
The Device Specific Module (DSM) interfaces with the Browser Plug-in on one side and with the FIDO Token hardware on the other. The DSM maps commands from the plug-in into commands that are specific to the token type. The DSM allows the Browser Plug-in to be generic and support a wide variety of token types. The DSM also allows token vendors to focus only on building their token specific content rather than needing to build an entire software stack.
Relying Party / Website
As the name says, the Relying Party relies on the token validation to be secure. Websites and network applications are “Relying Parties”.
The website is responsible for recognizing the presence of a FIDO token and whether it is already connected to an account or if the user should be offered the chance to connect a new token to their account.
For example, a recognized token that has an account associated would cause an additional notification like “Login with FIDO” to be added to the login page. Or if the token was a recognized finger scan token, the message could be “swipe your finger for FIDO login”.
Depending on the Relying Party’s policy, the user preferences and account history Identification tokens can greatly simplify login. A website could choose to simply recognize a returning user and show a “Welcome back Debbie!” instead of a login box, based only on the FIDO token information. Of course, the user may want to opt in/out of this behavior and the Relying Party will need to decide how risky it might be for the account.
Validation Cache
The Validation Cache will check the encrypted information and one time passwords from the tokens to ensure that a token is not being spoofed. The Relying Party will use the Validation Cache to check information that it receives from each token.
Note that the Validation Cache is at the Relying Party's website so that the response is immediate and not subject to internet delays or attacks. The Validation Cache will regularly pull updates from the Repository to get new token information as the tokens are produced by the vendors.
FIDO Repository
A FIDO Repository is a clearinghouse for token information. The Repository receives new token information from the token vendors when the tokens are created. This information will allow the validation of the unique OTP stored in each new token. The Repository will regularly update the Validation Cache at each website that uses FIDO. Repositories will support many website and will be replicated to ensure contined service. A website may use more than one Repository.
A FIDO Repository will coordinate with token vendors to ensure that current token information is available. The Repository will make it easier for websites to enable FIDO because they won’t need coordination with every token vendor. By connecting to a repository this coordination and current token information will be handled already.
Use Cases
User Binding
- When a user goes to a website (a Relying Party) that supports FIDO with a new token, the site will suggest that the user bind their FIDO token to their account for better security in the future. The browser information presented to the website will tell the website that the user has a FIDO token and what type of token it is.
- If the website uses FIDO, it will quietly and quickly query the plug-in about the token. Depending on the website policies, the website will present web content that suggests the user should connect their FIDO token to their account.
- The content and experience will differ depending on the type of user token but all are supported through the same plug-in.
- Finger scan : The user swipes their finger on the sensor. The token encrypts and release information for the Device Specific Module to pass to the Browser Plugin.
- Password Protected Token : The user enters the correct password for the token.
- Device ID Token : Since this is not an authentication token there is no challenge for the user to answer. The user simply clicks Ok to connect the token.
- When the user agrees to connect the token and passes the authentication step (if needed) the global unique token id and a user identifier for the token is encrypted and sent back to the website. The website uses the Validation Cache to validate the token. Once the token is validated, the website connects the token’s unique identifier to the users account for future reference.
User Authentication Experience:
Once the user has connected their Token to a web account they can use FIDO instead of an account id and password. The following shows three example experiences but there will be a wide variety of FIDO tokens that will provide similar experiences.
Finger Scan Experience
- A user goes to a website that they have connected to their FIDO finger scan token.
- The browser information tells the website that the user has a FIDO finger scan token available for authentication, so the website customize the page to tell the user that FIDO is an option. The website could present a message like “Swipe for secure login with FIDO” The user swipes their finger.
- The FIDO token recognizes the user. The user’s biometric never leaves the token. The global unique token id and a user identifier for the token is encrypted and sent back to the website through the Device Specific Module and plug-in.
- The website validates the information from the finger scan token through the Validation Cache The website looks up the user’s account based on the global unique id and user id. Then the user is logged into their account. This login will be a two factor login because having the token is one factor and passing the biometric challenge is a second factor.
- If the user has connected their finger to more than one account the website will ask the user which account they would like to access.
Password Protected Token Experience
A user goes to a website that they have connected to their password-protected authenticator. This could be a USB token or could be built into their system on the motherboard.
The browser information tells the website that the user has a FIDO password token available for authentication, so the website customizes the page to tell the user that FIDO is an option. The website could present a message like “Click here for secure FIDO Login”.
When the user clicks the “FIDO Login” button, the plug-in will pop up a secure local window (not a browser window) for the user to enter the password for their token. This password is to locally unlock the FIDO token. This password should not be accessible by the web browser and should only be sent to the token.
The FIDO authenticator validates the password. The global unique token id and a user identifier for the token is encrypted and sent back to the website through the Device Specific Module and plug-in.
The website validates the information from the token through the Validation Cache The website looks up the user’s account based on the global unique id and user id. Then the user is logged into their account. This login will be a two factor login because having the token is one factor and knowing the password is a second factor. If the user has connected their token to more than one account the website will ask the user which account they would like to access.
ID Token Experience
-
A user goes to a website that they have connected to their Identification Token.
This could be builtin hardware, an add-on device or a software identifier that does not require a pin or password since it only provides identification.
The browser information tells the website that the user has a FIDO Identification token available for authentication. The website will query the plug-in for the id token’s information. This will happen quickly and quietly with no user interaction. The global unique token id for the token is encrypted and sent back to the website through the Device Specific Module and plug-in.
The website validates the information from the token through the Validation Cache. The website looks up the user’s account based on the global unique id. If there is only one account connected to the token and the website’s policy permits it, then the user is logged into their account immediately without a password. This login will be a single factor login because the token is the only factor.
If the website’s policy requires two factors, then the user can be prompted for their password. The token id will be passed quietly behind the scene as a second factor with no additional user interaction.
New Authenticator Type
One of FIDO’s goals is inclusion. The intention is to allow all security tokens that conform to the FIDO plug-in interface should be usable across all websites with zero code changes. So when security token vendors have a new token type it is easy to incorporate.
To add a new authenticator type the authenticator developer needs to build a Device Specific Module for their authenticator and test it with the plug-in. The authenticator developer then needs to provide a FIDO Repository with the information required to validate their new authenticator. The Repository will ensure that the information is distributed to the Validation Caches at the Relying Pary sites.
When a new authenticator appears at a website for the first time, the website will validate the authenticator with the Validation Cache. The website can ask the user to perform any token specific challenge to authenticate the user without knowing the details of the challenge since this is triggered by the plug-in and handled by the Device Specific Module. When the user completes the challenge, the authenticator information can be connected to the user’s account.