Cryptographic workstation based on PKCS # 11 tokens. Obtaining certificates for EGAIS. Part 4

And now, when I almost added the generation of self-signed certificates to the cryptographic workstation based on PKCS # 11 cryptoarmpkcs tokens and was ready to start writing the article, I received a letter like this:

We are the UZNIREK CA, we had difficulty issuing ES in the pkcs # 11 format for EGAIS, the portal does not understand the ES in the Znamerek CSP format, we ask you to help in this problem.

I did not know all the intricacies of working with EGAIS, but since it was about PKCS # 11, I suggested using the cryptoarmpkcs utility to generate a request and install a certificate on the token after it was received from the CA. The answer I received was somewhat distracting:

Alas, the fact is that we recorded ES on RuToken 2.0 through CryptoPro CSP, but with all the proper settings, the EGAIS portal did not see the ES on the key medium, the client contacted us in support and we found that the problem is not the key certificate is written in that format, here is the manual dev.rutoken.ru/display/KB/RU1051

.

I (and not only me) have repeatedly written that many use cryptographic tokens with the support of Russian cryptography as ordinary flash drives . And this was just the case when the key and certificate did not get to the token as PKCS # 11 objects. It was a shame that they did not take the advice and did not even try to create a request. But then I decided to put everything aside and figure out how and on what certificates for EGAIS Rosalkogolregulirovanie are issued. And we will consider only cryptographic tokens PKCS # 11. The biggest disappointment is access to EGAIS only through the Windows OS and IE browser. On the other hand, the generation of a certificate request and certificate installation can also be carried out under any OS if it has drivers / libraries for the corresponding token.



At least PKCS # 11 tokens JaCarta, RutokenECP-2.0, the LS11SW2016 software token and even the cloud token have support on MS Windows, Linux, and OS X. And not only on these OSs.



In fact, we must pay tribute to the developers of EGAIS. They proposed an interesting technology that allows for access to use personal certificates (certificate plus key pair) stored on cryptographic tokens with support for Russian cryptography, and protect the channel on RSA certificates. Although if they said A, then one could say B, i.e. protect the channel on GOST-ov algorithms. The only sad thing is that all this is tailored only under MS Windows (or am I mistaken?), Or rather, under Internet Explorer. And utilities generating certificate requests for EGAIS are tied to one or another token.



But the cryptoarmpkcs utility is multi-platform. Moreover, it is able to work with any PKCS # 11 cryptographic token that supports Russian cryptography.



So, what is the peculiarity of the certificate request for EGAIS? The main feature is the mandatory presence in the distinguished name of the certificate holder (DN subject) of an additional field unstucturedName (UN) (oid - 1.2.840.113549.1.9.2). If the owner of the certificate is an individual entrepreneur, then the line “KPP =” is written in this field, and if the owner is a legal entity, then the following line is written in this field:

PPC = reason_code_of_tax_account_account:







In this regard, the requirement on the first page of the certificate request tab was added the EGAIS button:







Another feature is that holders of certificates for EGAIS can be licensees of the FSRAP declaration system (oid - 1.2.643.3.6.78.4.4). This also needs to be considered when creating a request:







After all the fields of the certificate request are filled in and you have confirmed the correctness of the data, a key pair will be generated and a request will be created:







If you look at the request, then in it you can see the oid (Extetnded Key Usage), which are required for the EGAIS Rosalkogolregulirovanie:







Here you should pay attention (in the previous screenshot) to the key pair label. In PKCS # 11 terminology, this is the CKA_LABEL attribute for the public and private key. It is in this way that a label (key name) is created by the EGAIS query generator for JaCarta from CenterInform FSUE:







Traditionally triple certificate x public_key x private key

on the token is associated through the attribute CKA_ID

:

The most common way to specify CKA_ID is to use the hash function value from the public key value. It is this method for linking a triple of objects that is used in the NSS (Network Security Services) project. In this case, the SHA1 algorithm is used as a hash function.

Unfortunately, both CKA_LABEL and CKA_ID can be set / changed at any time with any value. Thus, there is always the possibility that the certificate will be associated with another person’s private key. No need to explain what the consequences of this will be.



In general, is there a strict mathematical algorithm that allows you to connect the triple CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY into a single whole?

Yes, such an algorithm based on cryptographic mechanisms (CKM_) of the token exists .



Unfortunately (although you can objectively understand it), it considers a bunch in a triple through CKA_LABEL, formed by the above-mentioned method. Moreover, for the private and public keys SKA_ID is formed in a similar way. For keys, this is just a disaster, because however neither CKA_ID nor CKA_LABEL are bound in any way to the key itself. This also applies to the certificate after it is installed on the token. If in the traditional formation of CKA_ID as a hash from the public key, you can always check whether one matches the other, then when setting CKA_ID and CKA_LABEL in the manner described above, this cannot be done.



A question may arise, but how to check compliance for a private key? The answer is simple - by calculating the value of the public key against the private one. As for the certificate, the value of its public key is, of course, in it. Moreover, the certificate itself contains the CKA_ID value for both the certificate holder (Certificate Subject Key Identifier) ​​and the certificate issuer (Certificate Authority Key Identifier):







The most unpleasant thing was that when installing the certificate, it is not the presence of the private key that is checked, but only the public key is sufficient. In this case, the certificate will be installed, but there will be no private key on it. One more problem. This is a public key search by TIN. Imagine a person has one TIN and several keys for various certificates. Which one belongs to? After that, it becomes clear the requirement for JaCarta to have only one certificate and one key pair:

This error may be due to certificate duplication. In the JaCarta Unified Client in administrator mode, on the GOST tab After entering the PIN code, one public key, one private key and a certificate should be visible. In this case, the key duplication is visible. You need to remove the extra ones. Re-insert the media into the usb connector and try installing the UTM again. If the error persists, initialize Jacarta according to link 1 and go through the generation process again.

Let's hope that this shortcoming will be eliminated. You may ask how the cryptoarmpkcs utility for EGAIS installs the certificate. For full compatibility for JaCarta, we have maintained the ideology that CKA_ID and CKA_LABEL for keys are the same. But only after installing the certificate on the token and its binding in the key pair. Until that moment, the CKA_ID of the key pair is kept equal to the hash value from the public key.

After installing the certificate, you can use it to sign documents .



Now it remains to complete the finalization of the creation of self-signed certificates and the cryptoarmpkcs utility, and with it this series of articles will be completed: