One of the central objects of the public key infrastructure (Public Key Infrastructure - PKI / PKI) along with the key pair is the certificate, which today is in fact an analogue of a civil passport.
Having a certificate in hand, a citizen can get access to the portal of
state services , pay taxes, protect his
email , sign and encrypt documents and much more.
The certificate, as well as a
passport , is issued on the basis of an application and the provision of a number of documents. The list of documents for obtaining a certificate is available on any certification center that is
accredited by the Ministry of Communications (the new name is the Ministry of Digital Development, Communications and Mass Communications). The application for a passport has the applicant’s handwritten signature. At the time of receipt of the passport, the applicant will put his signature in the passport, which will be certified by the employee of the passport office and the official stamp. The photograph and the owner’s ability to reproduce his or her signature and allow him to be identified as the owner of a particular passport.
In a similar way, the receipt of the certificate of the electronic signature key (CLEP) also occurs. First, a citizen who wants to receive a certificate must acquire the “skill” in affixing a handwritten signature. This “skill” is realized through the applicant’s receipt of a key pair, which contains a public key or an electronic signature verification key (KEPP) and a private key or electronic signature key, which, in fact, allows you to generate an electronic signature and sign an electronic document. The identification of the electronic signature under the document is carried out according to the following algorithm. From the certificate is determined by what key (GOST R 34.10-2001, GOST R 34.10-2012 with a key length of 64 or 128 bytes) the document was signed. The type of key determines the hashing algorithm that was used when signing the document. This can be GOST R 34.11-94 or GOST R 34.11-2012 with a hash length of 256 or 512 bits. According to the selected algorithm is considered a hash from the source document. And by the value of the calculated hash from the source document, the public key (KPED) and its parameters (all of this is taken from the certificate of the CEIED) and the authenticity of the electronic signature under the document is checked.
To create a key pair, various means of cryptographic information protection (CIPS) are used, supporting cryptographic algorithms GOST R 34.10-2001 and GOST R 34.10-2012. It should be remembered that the use of the signature scheme GOST R 34.10-2001 for the formation of a signature after December 31, 2018 is not allowed! SKZI, which implement various cryptographic algorithms and protocols can be both software and hardware. Access to SKZI is carried out through cryptographic interfaces. The absolute majority of certified cryptographic cryptographically sensitive software with Russian cryptography supports either the universal cryptographic interface
PKCS # 11 , which is supported on all platforms, or the CSP and CryptoAPI interface from Microsoft on MS Windows (hereinafter MS CSP). It is these two cryptographic interfaces that are supported, for example, by the Government
Services portal. It is these two types of SKPI that will be considered further:
It should be borne in mind that if there is a desire or need to work with an electronic signature not only on the Windows platform, but also on other platforms (Linux, macOS, etc.), then select PKCS # 11 tokens with support for Russian cryptography.
In addition to the main function associated with generating a request, the utility provides functions for working with tokens and certificates:
Combined field (combobox) “Select a token:” on the main window contains a list of available SKPIs for generating a key pair. If the request generation utility is running on the Windows platform and CSP crypto-providers with Russian cryptography support are installed on it, the virtual MS_CSP will be defined in the list of available CRPDs (“Select a token:”). So, if there is a desire to use MS CSP cryptographic provider, then it must be installed in the system before running the utility.
To add support for the new PKCS # 11 token, just select the “Tokens Management-> Add Token” menu item. Adding support for a new token consists in selecting the PKCS # 11 library for the token / smartcard type to be connected and setting a convenient name (nickname). When adding support for a new type of tokens (as well as when launching the utility, if support for tokens was previously added) with a connected (inserted) token, a PIN code will be required to access it:
But this will happen only if the token is not only connected, but in working condition, i.e. initialized Check the token and, if necessary, initialize it, change the PIN code to access it, etc. conveniently
p11conf utility:
By selecting the item “Management of Tokens-> Token Mechanisms”, you can see the cryptographic mechanisms of one or another token, for example, is there any support for the GOST R 34.10-2012 algorithm. For the MS_CSP virtual token, all CSP providers that support GOST algorithms and the mechanisms they support are listed:
If the selected token does not support the selected type of key pair, the corresponding message will be displayed:
Before proceeding directly to filling in the request fields, you need to decide for what purposes a certificate is needed, i.e. specify the "Role of the certificate." Today, there are more than a dozen such roles:
And each role is associated with many different OIDs included in the certificate. So, for example, to access the Gosuslug portal, the following oid-s are needed:
{} {clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 1.2.643.5.1.28.3, 1.2.643.3.202.1.8}
OIDs for other roles (for example, Platform Gazprombank, Alcohol Consumer, etc.) can be found in the utility source code (variable oid_roles_bad, operator:
set oid_roses_bad {. . .}
).
The presence of such a number of oids is difficult to understand. We are talking about qualified certificates in which there are OIDs of the TIN, OGRN, SNILS, etc., which uniquely identify both an individual and a legal entity and, it seems, this would be enough to access the Government Services portal, and other also. But, Dura lex, sed lex - The law is harsh, but it is the law.
In the field “Name of SKZI” you must specify the name of SKZI (token / smartcard, CSP), which is written in the certificate of conformity (not to be confused with certificate X509) of the FSB of Russia or other similar document, a copy of which must be provided at the time of acquisition of SKZI. Subsequently, the value of this field will be included in the certificate.
So, having decided on the SKZI and the key pair, you can begin to fill in the electronic application / certificate request for the electronic signature verification key (CLEP):
The first to fill out the field "Common Name", in which the full name of the future certificate holder is entered. For an individual, this is a full name as in the passport. For a legal entity, this is the name of a company from Incorporation. This information for a legal entity will automatically be duplicated in the field “Name of the organization” (“O”):
When filling out the form, the correctness of filling in the TIN, OGRN, SNILS fields is checked (if you enter a number, the field turns red, the fields filled in correctly turn greenish), e-mail addresses:
After filling in all the fields of the request and clicking the “Finish” button, a certificate request will be received:
In the process of creating a request, a key pair will be generated on the selected token. At the same time, if the virtual token “MS_CSP” is selected as the token, which, in turn, supports various media for storing the key pair, you will also be asked to select a specific carrier:
Recall that the key pair contains two keys: private and open. The public key, which is also called the electronic signature verification key, is sent to the certificate request. To view the generated request, which also contains the public key, use the menu "Certificates-> View request":
The private key remains with the applicant on his token, the PIN code (password) from which must be stored as the pupil of His eye. And since there is a
one-to-one correspondence between public and private keys, one can always check to whom the certificate request belongs, and later the certificate itself, the signature on the document, etc.
Now with all the necessary documents, with a generated request on the flash drive, you can go to the nearest certification authority and receive a certificate. So the request comes in for issuing a certificate to one of the CAs, created with the Federal Law of April 6, 2011. №63- “About electronic signature”:
The request to the TC will pass through the stages of import, review, approval and issuance of a certificate for this request:
The issued certificate will be published on one of the CA services, from where it can be downloaded. And now it is enough that the issued certificate be exported to the applicant's flash drive:
And now, when the certificate is received, it remains to put it on SKZI (PKCS # 11, MS CSP) (Certificates-> Import x509):
You can make sure that the certificate is on a token, by viewing the contents of the token / smart card (Certificates-> View x509 on the token):
Well, so that it was “armor” (Give me such a PAPER! Final Paper, Armor. (Dog's Heart c / f)), connect the token to the
Firefox browser with support for Russian cryptography and find the certificate issued in personal certificates (among such certificates, for which the token has a private key):
The CreateCSRCAFL63 utility is developed on
Tcl / Tk . To access the MS CSP cryptographic functions and PKCS # 11 tokens, the cwapi package has been developed, which implements the requirements for C libraries from Tcl. Implementing these requirements is
not difficult , but sometimes it takes a lot of time because of its routine. And here the public
SWIG utility comes to the rescue
. , which allows you to create interface modules between C / C ++ libraries and other languages. This is not only Tcl, but also Java and others. The project is very well documented and has excellent examples. To use it is not difficult. In our case, a simple cwapi.i source file for the swig utility was written to get the interface module:
%module cwapi %inline %{ #include "cwapi.h" %} %include "cwapi_SWIG.h"
The cwapi.h file contains descriptions of functions from the main cwapi project:
#ifdef __cplusplus extern "C" { #endif int CW_Initialize (char *configdir); int CW_Finalize (); int addp11mod (char *nickname, char *library); int remp11mod (char *nickname); char * lmod (); char * ltok (); char * lcert (char *token, int priv_cert); char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role); char* viewx509 (char *nickname, int CertOrReq); char* x509pem (char *nickname); char* x509fromfile(char *token, char *infile, char *trusts); int delcert (char *nickname, int priv_cert); int p12tofile (char *token, char *nickname, char *outfile); char* p12fromfile(char *token, char *infile); char* lmech(char* token); char* tinfo(char* token); #ifdef __cplusplus } #endif
Running the command:
$export SWIG_LIB=/usr/local/swig-3.0.12/Lib $/usr/local/swig-3.0.12/swig -tcl8 -o cwapi_wrap.c cwapi_.i $
in the file cwapi_wrap.c we get the ready interface module. Add it to the cwapi project, rebuild it and get a new package, which is used in this utility.
It is very convenient to use the
freewrap utility to get the distribution, and the cwapi library is also included directly in the distribution. The utility source code and distributions are available for Windows and Linux platforms.
I would like to mention one more utility, namely
tcl2c . This utility “wraps” tcl / tk code into C code.
To get the executable code, just run the command:
$cc -o create_csr_ create_csr.c -ltcl -ltk $
The distribution kit for the Linux platform also includes the C language distribution kit with the static connection of the cwapi package.