Authorization scheme using electronic digital signatures instead of password protection

In my previous topic “Passwords is the last century, new methods of authorization and storage of personal data are required in the future” I talked about the existing problems of using passwords on the network and methods for building authorization using EDS. In this topic, I want to give a detailed authorization scheme on the Internet using EDS, which provides 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 give a small quote from a previous article:

From a security point of view, the best protection to date can be provided by the use of USB tokens, protected by a PIN code from 3 attempts and (optionally) an integrated fingerprint scanner. In the authorization process, you can use the transfer to a single authorization center of a digital copy of a biometric fingerprint signed with a personal digital signature (cryptographic conversion with a private key). At the same time, it is not possible to extract a digital copy of the biometric fingerprint from the USB token and the keys used, and only the one who has the second public key pair can decrypt the transmitted data. To protect against interception during each authorization, the transmitted data must be unique, for example, at each authorization, along with a copy of the biometric fingerprint, also encrypt a random string and counter value of successful authorizations. Even better, if personal sets of public and private keys are created and saved in advance for each day during the entire period of use of the key (for example, within 10-20 years) and the authorization token checks the date with its servers and signs the data with the necessary key for the current date . At the same time, public keys must also be reliably protected and located only on the authorization server (for example, in the internal server of a single authorization center that checks the accuracy of the data received, but does not have direct access to the Internet). if personal sets of public and private keys are created and saved in advance for each day during the entire period of use of the key (for example, within 10-20 years) and the authorization token checks the date with its servers and signs the data with the necessary key for the current date. At the same time, public keys must also be reliably protected and located only on the authorization server (for example, in the internal server of a single authorization center that checks the accuracy of the received data, but does not have direct access to the Internet). if personal sets of public and private keys are created and saved in advance for each day during the entire period of use of the key (for example, within 10-20 years) and the authorization token checks the date with its servers and signs the data with the necessary key for the current date. At the same time, public keys must also be reliably protected and located only on the authorization server (for example, in the internal server of a single authorization center that checks 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 must be stored in conjunction with these keys. This will allow the authorization server to match the necessary public keys by the token number during the authorization process.

So, we will consider how the authorization process should proceed:
1) The user encrypts a digital copy of the biometric fingerprint + the value of the authorization counter + a random string with his 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 server of the authorization center decrypts the received message using the user's public key. If, as a result of decryption, the server receives the correct digital copy of the user's biometric fingerprint, then the message is encrypted with an authentic key. If the result is 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 line using the public key of the web server and sends back a response message. If the verdict is negative, 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 command for authorization.
6) Upon successful authorization, the web server returns the random string to the user in the clear, The received string is verified with the sent string and, if the USB token matches, the counter of successful authorizations increases by one unit.


It should be noted that the value of the counter of successful authorizations in the USB token under no circumstances can be more than on the server. And if the value is less, then the server must verify the random user string received with the stored string using the specified authorization number. This will make it easy to identify the offender. If these lines match, then an attempt is made to falsify with the sending of intercepted traffic from the previous authorization, which means the server must deny access, promptly notify security specialists about this, and add the IP address of the intruder to the list of monitored ones. If these lines are different, then during the last authorization the web server did not return the user’s random line to the user, so the server must allow access,

Advantages:
1) A public and private key pair 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, at each authorization, along with biometric data, the reading of the counter of successful authorizations and a random string are encrypted. Checking the counter and the random string will determine the falsification.
3) An attempt to redirect the authorization process to a fake server also does not work if the public key pair is only in the authorization center and is reliably protected. A fake server will not be able to return its verdict, encrypted with the public key of the web server.
4) No vulnerabilities of the applied authorization scripts on sites can compromise the authorization process.
5) Hacking a web server will not allow receiving biometric fingerprints and digital signatures of users. In fact, in this scheme, each authorization participant is only interested in their own security and is not responsible for the security of another participant.
6) If the counts of successful authorizations do not match, then the server can determine exactly whether the authorization is being compromised or, during the last authorization, the web server did not return a random string to the user.
7) In fact, a secure SSL connection is not required in this case, because all sensitive data is transmitted in encrypted form. Nevertheless, the use of secure SSL protocol further increases the degree of security.

Disadvantages:
1) It uses 2-fold encryption and decryption of the data necessary to confirm the authenticity of each of the participants.
2) The capacity of the keys should be as small as possible so as not to overload the server during the authorization process.
3) Tokens used on web servers should provide high speed data decryption. Especially if sites have a high level of traffic, 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, “unsinkable” to DDoS attacks.

Text revised and revised March 11, 2015