What is the difference between USB U2F and regular USB token?

Question

USB

What is the difference between USB U2F and a regular USB token issued through Rostelecom for authentication in government services, etc.? Or just the differences between U2F and a regular "pre-U2F era" USB token?
UPD: At the same time I read Habr and materiel.

Answer 1

Classic tokens such as JaCarta PKI, eToken Pro and others are tied to a PKI infrastructure and certificates that are authenticated by a CA server. They are used to access serious resources that require an enhanced qualified electronic signature. This is when a user physically goes to a certification center, confirms his identity with a passport, after which he is issued a certificate with a private key, which are written to the memory of the token. Or, classic tokens are used in corporate systems, when certificates are issued to users by an internal enterprise certificate authority for VPN authentication.
U2F, in turn, is a simplified system that is not tied to PKI, and the token operates with public / private key pairs in its purest form without binding in the form of a certificate. U2F is adapted specifically to work with all sorts of lightweight web services and tightly integrates with the browser.
For example, you can change gmail authentication to use a U2F token. U2F is also supported by services such as google drive, YouTube, GitHub, WordPress, Facebook and others, and the U2F token itself can contain up to 500 key pairs - one key pair for each resource. If the service does not support the U2F protocol, then you can integrate the token with it through two-factor authentication providers, such as Duo Security.
The procedure for linking a U2F token to a resource is very simple and is done with a couple of clicks. When accessing the resource for the first time, the user must register by entering a username and password. The token then generates a key pair and transmits the public key to the service server.
When connecting to a web service where the user's U2F token is already registered, after entering the login and password, the server generates an additional request to the token called a challenge. By pressing the token button, the user confirms the access to the resource and the token selects the desired key pair, signs the request with the private key and sends it to the server, which verifies the signature and grants or denies access. If it is not clear, then I propose to recall the principle of asymmetric encryption - if something is encrypted with a private key, it can only be decrypted with a public key from the same key pair. When registering, that is, binding a U2F token to a web resource, the public key generated on the token was transferred to the server. The private key remains on the token. Now, when authenticating, the server sends a challenge, which is encrypted on the user's token with a private key and sent back to the server. If the server can decrypt the challenge with the previously received public key, then the challenge was encrypted with a valid U2F token, that is, the token that was originally registered and from which the public key was originally received.
Based on this, we can say that the classic token is used for serious resources and serious operations. That is, having taken possession of a token with an enhanced qualified electronic signature, an attacker can rewrite the apartment to another person through public services. U2F tokens are intended for simpler operations, such as accessing gmail or Facebook