Experience in using Rutoken technology for registering and authorizing users in the system (part 1)

Good afternoon I want to share my experience on this topic.

Rutoken are hardware and software solutions in the field of authentication, information security and electronic signature. In fact, this is such a flash drive that can store authentication data that the user uses to log in to the system.

In this example, Rutoken EDS 2.0 is used.

To work with this Rutoken you need install windows driver.

For windows, installing a single driver ensures that everything is installed so that the OS sees your Rutoken and can work with it.

You can interact with Rutoken in various ways. You can access it from the server side of the application, or you can directly from the client side. In this example, interaction with Rutoken from the client side of the application will be considered.

The client part of the application interacts with the root token through the root token plugin. This is a program that is separately installed on each browser. For windows, you just need to download and install the plugin, located at this link.

That's it, now we can interact with Rutoken from the client side of the application.

In this example, the idea of ​​implementing a user authorization algorithm in the system using the challenge-response scheme is considered.

The essence of the idea is as follows:

1. The client sends an authorization request to the server.
2. The server sends a random string in response to a request from the client.
3. The client pads this string with random 32 bits.
4. The client signs the received string with its own certificate.
5. The client sends the received encoded message to the server.
6. The server verifies the signature by receiving the original unencoded message.
7. The server strips the last 32 bits from the received unencoded message.
8. The server compares the received result with the message that was sent when requesting authorization.
9. If the messages are the same, then authorization is considered successful.

In the above algorithm, there is such a thing as a certificate. In this example, you need to understand some cryptographic theory. Habré has great article on the subject.

In this example, we will use asymmetric encryption algorithms. To implement asymmetric algorithms, you must 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 distributed to 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 who owns the certificate, as well as a public key. Having a certificate, the user can sign any data and send it to the server, which can verify this signature and decrypt the data.

In order to correctly sign a message with a certificate, you need to create it correctly. To do this, a key pair is first created on Rutoken, and then a certificate must be bound to the public key of this key pair. The certificate must have exactly the public key that is on Rutoken, this is important. If we simply create a key pair and a certificate immediately on the client side of the application, then how can the server then decrypt this encrypted message? After all, he knows absolutely nothing about either the key pair or the certificate.

If you delve deeper into this topic, you can find interesting information on the Internet. There are some certifying centers that we certainly trust. These certification authorities can issue certificates to users, they install these certificates on their server. After that, when the client accesses this server, he sees this very certificate, and sees that it was issued by a certification authority, which means that this server can be trusted. For more information on how to set everything up correctly, the Internet is also full of information. For example, you can start with this.

Returning to our problem, the solution seems obvious. You need to somehow make your own certification center. But before that, you need to figure out, and on the basis of what the certification center should issue a certificate to the user, because he knows nothing about it. (For example, his first name, last name, etc.) There is a thing called a certificate request. More information about this standard can be found, for example, on Wikipedia. en.wikipedia.org/wiki/PKCS
We will be using version 1.7 - PKCS#10.

Let's describe the algorithm for generating a certificate on Rutoken (original source - documentation):

1. On the client, we create a key pair and save it to Rutoken. (saving is automatic)
2. Create a certificate request on the client.
3. We send this request from the client to the server.
4. Upon receipt of a request for a certificate on the server, we issue a certificate with our certification authority.
5. We send this certificate to the client.
6. On the client, we save the certificate for Rutoken.
7. The certificate must be bound to the key pair that was created in the first step.

Now it becomes clear how the server can decrypt the client's signature, because he himself issued him a certificate.

In the next part, we'll take a detailed look at how to set up your CA based on the fully fledged open source cryptographic library openSSL.

Source: habr.com