How does FIDO work
FIDO (Fast IDentity Online) Alliance was created in July 2012 to solve the problem of supporting strong authentication devices on the Internet, as well as to simplify the lives of users who are forced to create and remember user names and passwords. The FIDO Alliance plans to change the current situation with authentication by developing specifications that define a set of mechanisms that supplant dependence on passwords and ensure secure authentication of users of Internet services. The new standard on device security and browser plug-ins will allow any website or cloud application to interact with a wide range of existing and future devices to ensure secure user authentication.
To ensure the safety of users, the FIDO project integrates hardware, software and Internet services.
If anyone is not familiar with FIDO, the translation of the site section "How FIDO Works" is below. And now some small comments.
')
Our team developed a solution for hardware authentication on web-resources . The solution turned out quite successful, it is used in workflow systems and in SaaS licensing mechanisms. The technical part of the FIDO project is quite similar to our developments and looks quite doable. However, from the description on the FIDO website it becomes clear that they do not yet have a clear understanding of how to do it. Yes, and the concept itself raises a number of questions.
Security
FIDO Alliance assumes the following mechanism for distributing authentication devices. At the production stage, devices get an identification number and secret. This information is placed by the manufacturer in the FIDO Repository. When registering a new user, the service requests the identification number of the device and, from this number, receives from the FIDO Repository the data necessary to verify the user during authentication. This data is cached by the Internet service in the Validation Cache to reduce the load on the FIDO Repository.
Unfortunately, nothing is said about the cryptographic algorithms and protocols used so far. However, by indirect signs (the term OTP is found in the text, as well as under the scheme with the Repository), we can assume that it is planned to use symmetric algorithms. For me, this solution seems somewhat outdated. The safe distribution of symmetric keys, which the repository apparently should be doing, looks dubious. Logically, each device when registering on a new Internet service should generate a new key on its own. That is, for each service its own key and no global identification numbers. In addition, in order not to store any secret keys on the server, it seems reasonable to use asymmetric algorithms.
FIDO involves the use of two basic types of devices for authentication. In their terminology, these are Identification tokens and Authentication tokens. The first option does not require owner authentication. That is, while the device is connected, authentication is transparent to the user. Undoubtedly convenient. However, this mechanism can be used by anyone with access to the device, for example, the wife will be able to read the husband's correspondence. I think it is still impossible to refuse the second factor.
Privacy
Sadly, using a global identifier also allows you to build a connection between different accounts by device number, and not everyone will like it. At present, there are already serious problems with privacy on the Internet, and this approach also exacerbates this problem. It seems that there should be no global identifiers, there is no need for them in general.
Access recovery
The concept says nothing about the mechanisms of interaction in case of loss of the hardware device. A convenient and safe solution to this issue is very important, since it can cause a serious increase in the load on technical support.
PR
The solution will obviously be claimed by some part of the users conducting any commercial activity on the Internet. However, for the widespread, widespread use of strong authentication, you need not only to ensure security, but also to offer a solution that will be convenient and fashionable. Popularization of the developed solution can be one of the most costly parts of this project. In this regard, the participation in this alliance is not only of developers, but of services such as PayPal and Google, which looks very encouraging.
And here is the translation.
FIDO Authenticators
Users will have a FIDO Authenticator or token ( any hardware authentication device that supports FIDO mechanisms - interpreter ), which they have chosen, or which has been issued to them to use any service. For example, devices such as a biometric scanner or USB media with password access. Users can choose the type of FIDO Authenticator that best meets their requirements.
FIDO Authenticators will be issued in two main versions.
Identification tokens will have unique IDs, identifiers will be tied to the user's Internet account. After linking to the account, they will be available to the server as an identifier without the need for any action by the user. Thus, only one authentication factor will be provided.
Authentication tokens may require the user to perform some action to prove that he is the legal owner of the token. These actions may include entering a password, entering a PIN code, or providing biometric data. These authenticators will provide two-factor user authentication using the principle of "what you have" and "what you know" or the biometric factor "who you are."
When a user connects his FIDO Authenticator to a web resource account, a connection is established between the Authenticator, the relying party and the Validation Cache. After creating a connection, one-time passwords (OTP) are used to verify the subscriber. Since the OTP password is used only once, it cannot be used for replay attacks if someone captures a session with an intrusion into the system or listens to Internet traffic.
Each authenticator will have a built-in ID and an initial value that will uniquely identify and verify its authenticity. Cryptographic operations will occur on board the Authenticator. Thus, even if the machine is infected with malware, the FIDO Authenticator can still be trusted.
FIDO Plugin
User browsers will have a FIDO plugin. The plugin will be able to recognize the available FIDO Authenticators that are connected to the user's system. Including built-in authenticators and USB connectors.
When the user connects to the website, the browser will inform the server about the available FIDO Authenticators as part of the browser information. Sites that support the FIDO technology will be able to recognize the presence of an authenticator and respond accordingly. Based on the information received, the relying party (website) initiates an authentication mechanism.
FIDO plugin can be distributed through various channels, including:
Browser Add-On - Browser developers can have a plugin as an add-on that users can download and connect to their browser.
FIDO Authenticators - If a user buys a FIDO authenticator with a built-in USB drive, the plug-in can be located on it.
Vendors - Vendors can distribute a plug-in with new machines, and also include a plug-in as part of software updates for existing machines. These updates will allow the use of FIDO authentication on existing machines with suitable hardware capabilities.
Device Specific Module
A special device module (DSM) will interact with the browser plugin on the one hand, and with the hardware FIDO Token on the other. DSM converts plug-in commands to commands that are specific to each type of token. Sharing FIDO software into a plugin and DSM allows you to create a universal browser plugin that supports a wide range of hardware devices. In addition, it will allow hardware solution providers to focus only on developing the part of the software that is necessary to support their devices and does not require to implement the entire software stack.
Relying Party / Website
As the name implies, the relying party uses token verification for authentication.
The website recognizes the presence of the FIDO Token, determines whether it is tied to an account, and if not, presents the user with the ability to link a new token to his account.
For example, having determined that the token is tied to an account, the web site will add the message “Login with FIDO” to the login page. If the token was defined as a fingerprint scanner, the message may be “swipe finger to log in with FIDO”.
Depending on the server’s policy, user preferences, and account history, Identification tokens can greatly simplify login. The website can simply identify the existing user and show the “Welcome back Debbie!" Instead of the login window, based only on information from the FIDO token. Of course, the user can change the login parameters by determining for himself how dangerous this can be for his account.
Validation cache
Validation Cache will check the encrypted information and one-time passwords received from tokens, to be sure of the authenticity of the token. The relying party will use Validation Cache to verify the information received from each token.
It is worth noting that the presence of Validation Cache on the website of the relying party will allow you to receive a response faster, avoid delays in response or attacks. Validation Cache will regularly receive updates from the FIDO Repository about new devices made by token suppliers.
FIDO Repository
The FIDO Repository is a token exchange center. Token manufacturers will report data for each FIDO token produced in the Repository. The information stored in the Repository is used to verify the OTP generated by the token. The Repository will regularly update the Validation Cache on every site that uses FIDO. Repository will support a large number of sites and have replication mechanisms to ensure uninterrupted service. A website can use more than one Repository.
FIDO Repository will interact with developers to ensure the relevance and availability of the token database. Using the FIDO Repository will allow web sites to have no contact with each token supplier. When connecting to the FIDO Repository, information about all existing tokens will be available to the web service.
Examples of using
User connection
When a user with a new token for the first time enters a site that supports FIDO technology, the site will prompt the user to bind the FIDO token to their account to increase the level of security in the future. Information about the user's browser will inform the site that the user has a FIDO token, and will also inform the site of the type of token. If the site supports FIDO, it will query the token in the background. Depending on the policy, the site will offer the user to connect the FIDO token to their account.
The order of actions may differ depending on the type of User Authenticator, but all types will be supported through the same plugin.
Fingerprint scanner : the user runs his finger over the sensor. The authenticator performs the crypto operations, the data goes to DSM, and then to the browser plugin.
Password-protected tokens : the user enters the correct password for the token.
Unique device identifier : Since this is not Authentication tokens, all the user needs to do is click the OK button to connect the identifier.
When the user agrees to connect the token and authenticates to it (if necessary), the global token ID and user ID are encrypted and sent back to the site. The site uses Validation Cache to verify the token. After checking the token, the site binds the unique token ID to the user account for future use.
User authentication
After the user has linked his Token to the account, he can use it instead of the login and password of the account. Below are three examples, but in the future, FIDO will support a wider range of FIDO tokens.
Fingerprint reader
The user goes to the website, his account is tied to a token with a fingerprint reader.
The browser informs the site that the user has a FIDO token with a fingerprint reader for authentication, the website presents to the user a version of the authentication page that supports FIDO. The website may show the message "Scan your finger to enter FIDO" The user scans their fingerprints. FIDO token recognizes the user. The user’s biometric data never leaves the reader. The global ID and authentication data is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier and a user identifier. Thus, two-factor authentication is provided, since the presence of a token with a reader by the user is the first factor and the passage of biometric authentication is the second factor.
If a user used a token with a fingerprint reader with more than one account, the site will ask the user for the name of the account to which he wants to access.
Password protected tokens
The user goes to the website, his account is associated with a password-protected token. This may be a USB token or a module installed on the motherboard (TPM). The browser informs the site that the user has a FIDO token with a password, the website sets up the FIDO authentication page. The website may present the user with a message “Click here to login securely with FIDO”.
When a user clicks on the “FIDO Login” button, the plugin displays a local window (not a browser window) to enter the token's password. This password is for local authentication in FIDO token. This password is not accessible through a web browser and must be transferred only to the token.
FIDO token authenticates the user. The global ID and authentication data is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier and a user identifier. Thus, two-factor authentication is provided, since the presence of a token by the user is the first factor, and knowledge of the password from the token is the second factor. If a user has used a token with more than one account, the site will ask the user for the name of the account to which he wants to access.
Identifiers
The user goes to the website, his account is associated with the Identification token. This may be built-in hardware, additional software or hardware solutions that do not require knowledge of the PIN code or password, as they provide only identification. The browser informs the site that the user has Identification token available for authentication. The website will request identification data from the plugin. Data exchange with the server occurs in the background, without user interaction. Global ID Identification token is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier. If there is only one account associated with an identifier, then the user enters his account without a password. This type of authentication is one-factor, since for authentication it is enough only to own the identifier.
If site policy requires two-factor authentication, then the user may be required to enter their password. As a second factor, without additional user interaction, the presence of an Identification token is checked.
New Types of Authenticators
One of the goals of FIDO is to expand the range of devices. The intention is that all security devices that comply with the plug-in FIDO interface should be available to all websites without changing the code. This will make it easy to connect new types of tokens to the system.
To add a new authentication type, the developer must create a DSM device and test it with a plugin. Then the developer must transfer to the FIDO Repository the data needed to test the new devices. The repository will ensure that the data will be accessible to all Validation Cache relying parties.
When a new authenticator appears on the site for the first time, the site will verify the authenticator with the help of Validation Cache. The website may ask the user to perform any additional steps to authenticate the user, without knowing the details of these actions, since the interaction takes place through the plugin and DSM. When the user performs the necessary actions, the credentials will be connected to the user account.
To ensure the safety of users, the FIDO project integrates hardware, software and Internet services.
If anyone is not familiar with FIDO, the translation of the site section "How FIDO Works" is below. And now some small comments.
')
Our team developed a solution for hardware authentication on web-resources . The solution turned out quite successful, it is used in workflow systems and in SaaS licensing mechanisms. The technical part of the FIDO project is quite similar to our developments and looks quite doable. However, from the description on the FIDO website it becomes clear that they do not yet have a clear understanding of how to do it. Yes, and the concept itself raises a number of questions.
Security
FIDO Alliance assumes the following mechanism for distributing authentication devices. At the production stage, devices get an identification number and secret. This information is placed by the manufacturer in the FIDO Repository. When registering a new user, the service requests the identification number of the device and, from this number, receives from the FIDO Repository the data necessary to verify the user during authentication. This data is cached by the Internet service in the Validation Cache to reduce the load on the FIDO Repository.
Unfortunately, nothing is said about the cryptographic algorithms and protocols used so far. However, by indirect signs (the term OTP is found in the text, as well as under the scheme with the Repository), we can assume that it is planned to use symmetric algorithms. For me, this solution seems somewhat outdated. The safe distribution of symmetric keys, which the repository apparently should be doing, looks dubious. Logically, each device when registering on a new Internet service should generate a new key on its own. That is, for each service its own key and no global identification numbers. In addition, in order not to store any secret keys on the server, it seems reasonable to use asymmetric algorithms.
FIDO involves the use of two basic types of devices for authentication. In their terminology, these are Identification tokens and Authentication tokens. The first option does not require owner authentication. That is, while the device is connected, authentication is transparent to the user. Undoubtedly convenient. However, this mechanism can be used by anyone with access to the device, for example, the wife will be able to read the husband's correspondence. I think it is still impossible to refuse the second factor.
Privacy
Sadly, using a global identifier also allows you to build a connection between different accounts by device number, and not everyone will like it. At present, there are already serious problems with privacy on the Internet, and this approach also exacerbates this problem. It seems that there should be no global identifiers, there is no need for them in general.
Access recovery
The concept says nothing about the mechanisms of interaction in case of loss of the hardware device. A convenient and safe solution to this issue is very important, since it can cause a serious increase in the load on technical support.
PR
The solution will obviously be claimed by some part of the users conducting any commercial activity on the Internet. However, for the widespread, widespread use of strong authentication, you need not only to ensure security, but also to offer a solution that will be convenient and fashionable. Popularization of the developed solution can be one of the most costly parts of this project. In this regard, the participation in this alliance is not only of developers, but of services such as PayPal and Google, which looks very encouraging.
And here is the translation.
How does FIDO work
FIDO Authenticators
Users will have a FIDO Authenticator or token ( any hardware authentication device that supports FIDO mechanisms - interpreter ), which they have chosen, or which has been issued to them to use any service. For example, devices such as a biometric scanner or USB media with password access. Users can choose the type of FIDO Authenticator that best meets their requirements.
FIDO Authenticators will be issued in two main versions.
Identification tokens will have unique IDs, identifiers will be tied to the user's Internet account. After linking to the account, they will be available to the server as an identifier without the need for any action by the user. Thus, only one authentication factor will be provided.
Authentication tokens may require the user to perform some action to prove that he is the legal owner of the token. These actions may include entering a password, entering a PIN code, or providing biometric data. These authenticators will provide two-factor user authentication using the principle of "what you have" and "what you know" or the biometric factor "who you are."
When a user connects his FIDO Authenticator to a web resource account, a connection is established between the Authenticator, the relying party and the Validation Cache. After creating a connection, one-time passwords (OTP) are used to verify the subscriber. Since the OTP password is used only once, it cannot be used for replay attacks if someone captures a session with an intrusion into the system or listens to Internet traffic.
Each authenticator will have a built-in ID and an initial value that will uniquely identify and verify its authenticity. Cryptographic operations will occur on board the Authenticator. Thus, even if the machine is infected with malware, the FIDO Authenticator can still be trusted.
FIDO Plugin
User browsers will have a FIDO plugin. The plugin will be able to recognize the available FIDO Authenticators that are connected to the user's system. Including built-in authenticators and USB connectors.
When the user connects to the website, the browser will inform the server about the available FIDO Authenticators as part of the browser information. Sites that support the FIDO technology will be able to recognize the presence of an authenticator and respond accordingly. Based on the information received, the relying party (website) initiates an authentication mechanism.
FIDO plugin can be distributed through various channels, including:
Browser Add-On - Browser developers can have a plugin as an add-on that users can download and connect to their browser.
FIDO Authenticators - If a user buys a FIDO authenticator with a built-in USB drive, the plug-in can be located on it.
Vendors - Vendors can distribute a plug-in with new machines, and also include a plug-in as part of software updates for existing machines. These updates will allow the use of FIDO authentication on existing machines with suitable hardware capabilities.
Device Specific Module
A special device module (DSM) will interact with the browser plugin on the one hand, and with the hardware FIDO Token on the other. DSM converts plug-in commands to commands that are specific to each type of token. Sharing FIDO software into a plugin and DSM allows you to create a universal browser plugin that supports a wide range of hardware devices. In addition, it will allow hardware solution providers to focus only on developing the part of the software that is necessary to support their devices and does not require to implement the entire software stack.
Relying Party / Website
As the name implies, the relying party uses token verification for authentication.
The website recognizes the presence of the FIDO Token, determines whether it is tied to an account, and if not, presents the user with the ability to link a new token to his account.
For example, having determined that the token is tied to an account, the web site will add the message “Login with FIDO” to the login page. If the token was defined as a fingerprint scanner, the message may be “swipe finger to log in with FIDO”.
Depending on the server’s policy, user preferences, and account history, Identification tokens can greatly simplify login. The website can simply identify the existing user and show the “Welcome back Debbie!" Instead of the login window, based only on information from the FIDO token. Of course, the user can change the login parameters by determining for himself how dangerous this can be for his account.
Validation cache
Validation Cache will check the encrypted information and one-time passwords received from tokens, to be sure of the authenticity of the token. The relying party will use Validation Cache to verify the information received from each token.
It is worth noting that the presence of Validation Cache on the website of the relying party will allow you to receive a response faster, avoid delays in response or attacks. Validation Cache will regularly receive updates from the FIDO Repository about new devices made by token suppliers.
FIDO Repository
The FIDO Repository is a token exchange center. Token manufacturers will report data for each FIDO token produced in the Repository. The information stored in the Repository is used to verify the OTP generated by the token. The Repository will regularly update the Validation Cache on every site that uses FIDO. Repository will support a large number of sites and have replication mechanisms to ensure uninterrupted service. A website can use more than one Repository.
FIDO Repository will interact with developers to ensure the relevance and availability of the token database. Using the FIDO Repository will allow web sites to have no contact with each token supplier. When connecting to the FIDO Repository, information about all existing tokens will be available to the web service.
Examples of using
User connection
When a user with a new token for the first time enters a site that supports FIDO technology, the site will prompt the user to bind the FIDO token to their account to increase the level of security in the future. Information about the user's browser will inform the site that the user has a FIDO token, and will also inform the site of the type of token. If the site supports FIDO, it will query the token in the background. Depending on the policy, the site will offer the user to connect the FIDO token to their account.
The order of actions may differ depending on the type of User Authenticator, but all types will be supported through the same plugin.
Fingerprint scanner : the user runs his finger over the sensor. The authenticator performs the crypto operations, the data goes to DSM, and then to the browser plugin.
Password-protected tokens : the user enters the correct password for the token.
Unique device identifier : Since this is not Authentication tokens, all the user needs to do is click the OK button to connect the identifier.
When the user agrees to connect the token and authenticates to it (if necessary), the global token ID and user ID are encrypted and sent back to the site. The site uses Validation Cache to verify the token. After checking the token, the site binds the unique token ID to the user account for future use.
User authentication
After the user has linked his Token to the account, he can use it instead of the login and password of the account. Below are three examples, but in the future, FIDO will support a wider range of FIDO tokens.
Fingerprint reader
The user goes to the website, his account is tied to a token with a fingerprint reader.
The browser informs the site that the user has a FIDO token with a fingerprint reader for authentication, the website presents to the user a version of the authentication page that supports FIDO. The website may show the message "Scan your finger to enter FIDO" The user scans their fingerprints. FIDO token recognizes the user. The user’s biometric data never leaves the reader. The global ID and authentication data is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier and a user identifier. Thus, two-factor authentication is provided, since the presence of a token with a reader by the user is the first factor and the passage of biometric authentication is the second factor.
If a user used a token with a fingerprint reader with more than one account, the site will ask the user for the name of the account to which he wants to access.
Password protected tokens
The user goes to the website, his account is associated with a password-protected token. This may be a USB token or a module installed on the motherboard (TPM). The browser informs the site that the user has a FIDO token with a password, the website sets up the FIDO authentication page. The website may present the user with a message “Click here to login securely with FIDO”.
When a user clicks on the “FIDO Login” button, the plugin displays a local window (not a browser window) to enter the token's password. This password is for local authentication in FIDO token. This password is not accessible through a web browser and must be transferred only to the token.
FIDO token authenticates the user. The global ID and authentication data is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier and a user identifier. Thus, two-factor authentication is provided, since the presence of a token by the user is the first factor, and knowledge of the password from the token is the second factor. If a user has used a token with more than one account, the site will ask the user for the name of the account to which he wants to access.
Identifiers
The user goes to the website, his account is associated with the Identification token. This may be built-in hardware, additional software or hardware solutions that do not require knowledge of the PIN code or password, as they provide only identification. The browser informs the site that the user has Identification token available for authentication. The website will request identification data from the plugin. Data exchange with the server occurs in the background, without user interaction. Global ID Identification token is encrypted and sent back to the site via DSM and the plugin.
The site verifies the data received through the Validation Cache. The website identifies the user based on a global unique identifier. If there is only one account associated with an identifier, then the user enters his account without a password. This type of authentication is one-factor, since for authentication it is enough only to own the identifier.
If site policy requires two-factor authentication, then the user may be required to enter their password. As a second factor, without additional user interaction, the presence of an Identification token is checked.
New Types of Authenticators
One of the goals of FIDO is to expand the range of devices. The intention is that all security devices that comply with the plug-in FIDO interface should be available to all websites without changing the code. This will make it easy to connect new types of tokens to the system.
To add a new authentication type, the developer must create a DSM device and test it with a plugin. Then the developer must transfer to the FIDO Repository the data needed to test the new devices. The repository will ensure that the data will be accessible to all Validation Cache relying parties.
When a new authenticator appears on the site for the first time, the site will verify the authenticator with the help of Validation Cache. The website may ask the user to perform any additional steps to authenticate the user, without knowing the details of these actions, since the interaction takes place through the plugin and DSM. When the user performs the necessary actions, the credentials will be connected to the user account.
Source: https://habr.com/ru/post/179917/
All Articles