Authorization scheme using electronic digital signatures instead of password protection

In my previous topic “Passwords is the last century, further new methods of authorization and storage of personal data are required” I told about the existing problems of using passwords in the network and methods of building authorization using EDS. In this topic, I want to give a detailed authorization scheme on the Internet using EDS, providing a high level of security from fraudsters and cybercriminals.

The scheme presented here will also be considered within the framework of the authorization model using a single authorization center for any Internet resources described in detail in the previous article. Therefore, for a better understanding of the process, I will cite a small quote from the previous article:

From a security point of view, the use of USB tokens protected by a pin with a 3-try code and (optionally) an integrated fingerprint scanner can provide the best protection today. In the process of authorization, you can use the transfer to a single authorization center a digital copy of a biometric fingerprint signed by a personal digital signature (cryptographic transformation with a private key). At the same time, it is not possible to pull out a digital copy of the biometric fingerprint and the keys used from the USB token in any way, and only the person who has the second public key pair can decrypt the transmitted data. To protect against interception, at each authorization, the transmitted data must be unique, for example, at each authorization, along with a copy of the biometric fingerprint, also encrypt the random string and the value of the successful authorization counter. It is even better if personal sets of public and private keys are created and saved for each day during the whole period of key use (for example, within 10-20 years) and the token during authorization checks the date with its servers and signs the data with the necessary key for the current date . At the same time, the public keys should also be reliably protected and located only on the authorization server (for example, in the internal server of the single authorization center, which verifies the accuracy of the received data, but does not have direct access to the Internet).

Each USB token must have its own unique number. And when generating a pair of public / private keys, the USB token number should be stored in conjunction with these keys. This will allow the authorization server by token number to match the necessary public keys in the authorization process.
')
So, consider how the authorization process should take place:
1) The user encrypts a digital copy of the biometric fingerprint + the value of the authorization counter + a random string with its USB token. A unique USB token number is added to the received data and sent to the web server for authorization.
2) The web server receives the user's message and adds its unique token number to it. The received data is sent to a single authorization center.
3) The authorization center server decrypts the received message using the user's public key. If, as a result of the decryption, the server receives the correct digital copy of the user's biometric fingerprint, the message is encrypted with the authentic key. If successful, the random user string is also stored on the server in conjunction with the current authorization sequence number.
4) The authorization server encrypts its positive verdict + random user string using the public key of the web server and sends it back with a response message. In case of a negative verdict, the server encrypts the response message using a new random string.
5) The web server decrypts the received message with its token and receives a positive or negative authorization command.
6) If authorization is successful, the web server returns a random string in open form to the user. The resulting string is checked against the sent string, and if the USB token matches, the successful authorization count increases by one unit.


Note that the value of the successful authorization counter in the USB-token cannot under any circumstances be greater than on the server. And if the value is less, the server should verify the received random user string with the saved string using the specified authorization number. This will make it easy to identify the offender. If these lines match, then there is an attempt to falsify with sending intercepted traffic from the previous authorization, which means the server should deny access, promptly notify the security specialists and enter the violator's IP address in the list of monitored. If these lines are different, then during the last authorization, the web server did not return a random string to the user, which means the server must allow access, reduce the karma of the guilty web server and add a special code to the random user string to adjust the counter of successful authorizations.

Benefits:
1) The open and closed pair of keys can be changed at least every day, if the tokens can use different keys depending on the date.
2) It is useless to intercept traffic if, with each authorization, the counter of successful authorizations and a random string are encrypted with biometric data. Checking the readings of the counter and a random string will allow determining falsification.
3) Attempting to redirect the authorization process to a fake server also does nothing if the public key pair is only in the authorization center and is reliably protected. The fake server will not be able to return its verdict encrypted with the public key of the web server.
4) No vulnerabilities of the used authorization scripts on the sites can compromise the authorization process.
5) Hacking a web server will not allow users to get biometric fingerprints and digital signatures. In fact, in this scheme, each authorization participant is only interested in its own security and is not responsible for the safety of another participant.
6) If the values ​​of the successful authorization counters do not match, the server can accurately determine whether the authorization is being attempted to compromise or, during the last authorization, the web server did not return a random string to the user.
7) In essence, a secure SSL connection is not required in this case, because all sensitive data is transmitted in encrypted form. But still the use of a secure SSL protocol further increases the degree of security.

Disadvantages:
1) Use 2-fold encryption and decryption of data required to confirm the authenticity of each of the participants.
2) The key size should be as large as possible in order not to heavily load the server during the authorization process.
3) Tokens used on web servers should provide high speed data decryption. Especially if the sites have a high level of attendance, then instead of using USB-tokens, you need to provide high-performance expansion cards or reliable software tokens (for sites located on virtual servers).
4) Authorization centers should be built from high-performance clusters that are “unsinkable” to DDoS attacks.

Text revised and revised on March 11, 2015