The Use of Rutoken Technology for User Registration and Authentication in the System (Part 1)

Good day! I want to share my experience on this topic.

RUTOKEN is a hardware and software solution in the field of authentication, information protection, and electronic signatures. Essentially, it is a flash drive that can store authentication data used by the user to log into the system.

In this example, RUTOKEN EDS 2.0 is used.

To work with this RUTOKEN, it is necessary to install the driver on Windows..

For Windows, installing just the driver provides everything needed for the OS to recognize your RUTOKEN and work with it.

You can interact with RUTOKEN in various ways. Access can be obtained from the server side of the application or directly from the client side. This example will consider interaction with RUTOKEN from the client's part of the application.

The client part of the application interacts with the RUTOKEN through the RUTOKEN plugin. This is a program that is separately installed on each browser. For Windows, just download and install the plugin, available at this link..

That's it! Now we can interact with RUTOKEN from the client part of the application.

This example discusses the idea of implementing a user authorization algorithm in the system using the challenge-response scheme.

The essence of the idea is as follows:

1. The client sends an authorization request to the server.
2. In response to the client's request, the server sends a random string.
3. The client appends this string with random 32 bits.
4. The client signs the resulting string with its certificate.
5. The client sends the encoded message to the server.
6. The server checks the signature, obtaining the original unencoded message.
7. The server detaches the last 32 bits from the received unencoded message.
8. The server compares the received result with the message that was sent during the authorization request.
9. If the messages are identical, the authorization is considered successful.

In the algorithm mentioned above, there is a concept of a certificate. Within the framework of this example, it is necessary to understand some cryptographic theory. There is an excellent article on this topic on Habr..

In this example, we will use asymmetric encryption algorithms. To implement asymmetric algorithms, it is necessary to have a key pair and a certificate.

A key pair consists of two parts: a private key and a public key. The private key, as its name suggests, must be kept secret. We use it to decrypt information. The public key can be shared with anyone. This key is used to encrypt data. Thus, any user can encrypt data using the public key, but only the owner of the private key can decrypt this information.

A certificate is an electronic document that contains information about the user to whom the certificate belongs, as well as the public key. With a certificate, a user can sign any data and send it to a server, which can verify this signature and decrypt the data.

To properly sign a message with a certificate, it must be correctly created. For this, a key pair is first created on the Rutoken, and then the certificate must be linked to the public key of this key pair. The certificate must have exactly the public key that is on the Rutoken, which is crucial. If we simply create a key pair and a certificate directly on the client side of the application, how will the server then be able to decrypt this encrypted message? It knows nothing about either the key pair or the certificate.

If we delve deeper into this topic, we can find interesting information on the internet. There are certain certification authorities that we inherently trust. These certification authorities can issue certificates to users, and they install those certificates on their servers. After that, when a client connects to this server, it sees this particular certificate and recognizes that it was issued by a certification authority, meaning that this server can be trusted. There is also plenty of information on the internet about how to configure everything correctly. For example, you can start with this..

Returning to our task, the solution seems obvious. We need to establish our own certificate authority somehow. But first, we need to understand what basis the certificate authority should use to issue a certificate to a user, given that it knows nothing about them (for instance, their first name, last name, etc.). There's something called a certificate request. You can find more details about this standard, for example, on Wikipedia. ru.wikipedia.org/wiki/PKCS
We will use version 1.7 — PKCS#10.

Let's describe the certificate generation algorithm on Rutoken (source — documentation):

1. On the client side, we create a key pair and save it on Rutoken (the saving process happens automatically).
2. On the client side, we generate a certificate request.
3. We send this request from the client to the server.
4. Upon receiving the certificate request on the server, we issue the certificate using our certificate authority.
5. We send this certificate back to the client.
6. On the client side, we save the certificate on Rutoken.
7. The certificate must be bound to the key pair that was created in the first step.

It now becomes clear how the server will decrypt the client's signature, as it issued the certificate itself.

In the next part, we will detail how to set up your own certificate authority based on a full-fledged open-source cryptographic library called OpenSSL.

Source: habr.com