Certification Center CAFL63 created on the basis of. To store data (requests, certificates, settings, etc.), the SQLite3 DBMS is used. The CA has a graphical interface developed in Tcl / Tk.

CAFL63 was developed taking into account the requirements of the Federal Law of April 6, 2011. No. 63-FZ "On electronic signature", as well as "Requirements for the form qualified certificate electronic signature verification key "approved by order of the FSB of Russia dated December 27, 2011 No. 795.

Its structure includes a Registration Center (CR), which is responsible for receiving applications for certificates from citizens. Today, certificates are issued for legal entities, individuals and individual entrepreneurs. Applications are accepted electronically in PKCS # 10, CSR (Certificate Signing Request) or SPKAC format. Note that the CSR format is a PKCS # 10 PEM-encoded request with the header ----- BEGIN REQUEST CERTIFICATE -----.

A request is a completed questionnaire, the purposes for which a certificate is needed, the user's public key, signed (signed) with the user's private key. Further, with a package of documents certifying, in particular, the identity of the applicant, and with an electronic medium on which the request is stored (I emphasize, it is better to store the request, the private key in another place), the citizen comes to the CR CA.

The CR checks the documents, the request (filled data, the correctness of the electronic signature, etc.), and if everything went well, they accept the request, approve it and send it to the Certification Center (CA).

In the event that the applicant came without a ready-made request, then he, together with an employee of the CR, goes to a separate workplace where a request for a certificate is prepared. The prepared request on electronic media, as already mentioned, is sent to the CR. What should the applicant remember here? First and foremost, the applicant must pick up the media with the generated private key!

The approved request on electronic media is transmitted to the CA, where a certificate is issued on its basis.

This is a schematic diagram of the work of the TC. The details will become clear below. One remark, for the sake of convenience of demonstration, the utility for preparing the request, the CR and the CA are combined into one demo complex. But there are no problems with functional separation. The simplest solution is to have a CAFL63 instance at each workplace and use only the required functionality.

When the project was in full swing, the SimpleCA project caught my eye. The study of this project was very helpful in the final implementation of the CAFL63 TC.

Download the CAFL63 distribution kit for Win32 / Win64, Linux_x86 / Linux_x86_64 platforms.

So, we launch the CAFL63 utility - the CAFL63 start page appears on the screen:

We start our work by pressing the "Create DB" button. The CA database is created by means of the cross-platform SQLite3 DBMS. The UC DB contains several tables. The main table - mainDB - contains only one record, which stores the root certificate, a private key encrypted with a password, and the CA settings. There are two tables associated with certificate requests: the current reqDB requests and the reqDBArc request archive. Three tables are created for certificates: the new certificates table certDBNew, the certificate archive table CertDB, and the certificate revocation table CertDBRev. All request and certificate tables use the hash value (sha1) from the public key as the primary key. This turned out to be very convenient, for example, when searching for a certificate by request or vice versa. The database has another table crlDB, which stores lists of revoked certificates. And so, we clicked the "Create DB" button:

The creation of the CA begins with the selection of the directory in which we will store the database, and setting the password for access to the private key of the CA. Pressing the "Next" key, we go to the page for selecting the type and parameters of the key pair for the CA:

Having decided on the key pair for the root certificate of the CA being created, we proceed to filling out the form with information about the owner (we skipped the first screenshot):

Note that the CAFL63 utility has a certain "intelligence" and therefore controls not only the presence of data in the fields, but also the correctness (red highlight - incorrectly) filling in such fields as TIN, PSRN, SNILS, OGRNIP, email address, etc.

After filling in the fields with information about the owner of the CA, you will be asked to decide on the system settings of the CA:

If you are not going to work with Russian cryptography, you can use regular OpenSSL. To work with Russian cryptography, you must specify the appropriate version, modification of OpenSSL. Read the README.txt in the downloaded distribution for more details. Also, in accordance with FZ-63, it is proposed to set information about the certification of the CA itself and the cryptographic information system used by it.

After filling in all the fields correctly, you will once again be asked to check their accuracy and press the "Finish" button:

After clicking the "Finish" button, a CA database will be created, in which the following will be saved: CA root certificate, private key, system settings. And the start page of the CAFL63 utility will reappear on the screen. Now, when we have created a database of the newly created CA, we press the "Open DB" button, select the directory with the database and get into the main working window of the CA:

By clicking the "View CA CA" button, we make sure that this is exactly our root certificate.

The next step is to prepare templates / profiles of applications for legal entities, individuals and individual entrepreneurs ( Tools-\u003e Settings-\u003e Certificate Types-\u003e New ):

After specifying the name of the new profile, you will be asked to determine its composition:

After preparing the profiles, the CA is ready to receive applicants and applications from them. As noted above, the applicant can come either with a ready-made application for a certificate or without it.

If the applicant comes with a ready-made application, then after checking his documents, the application is imported into the CA database. To do this, select the "Certificate Requests" tab on the main working window, click the "Request Import / CSR" button and select the file with the request. After that, a window with information about the request will appear:

After reviewing the request and making sure it is filled in correctly, you can click the "Import" button to enter it into the database. Immediately, we note that when you try to re-enter the request in the CA database, the following message will be displayed:

Requests in the CA database are marked (column “Type”) either as “Locale” created at the CA, or as “Import” created by the applicant himself, and the time of receipt of the application at the CA is also recorded. This can be useful when dealing with conflict situations.

If the applicant came without an application and asks to create it, then first of all it is necessary to decide ( Settings-\u003e Types of Certificates-\u003e Individual-\u003e Edit ) with a key pair type ( -\u003e Key Pair ), for what purpose ( -\u003e Key Usage ) a certificate is required:

A key pair can be created both by means of the "LIRSSL-CSP" cryptographic information system (OpenSSL button) and saved in a file, or on a PKCS # 11 token (PKCS # 11 button). In the latter case, you must also specify the library for accessing the token (for example, rtpkcs11ecp for the RuToken ECP token or ls11cloud for).

After you have decided on the profile and clicked the "Next" button, the further procedure is not much different from issuing a root certificate. One important note: remember where you store the private key and the password for accessing the key. If a PKCS # 11 token / smartcard is used as a cryptographic information protection tool to generate a key pair, then it must be connected to the computer:

The created or imported application is located in the CA database and is displayed in the main window on the "Requests for certificates" tab. The received requests are at the stage of "consideration" (column "Status" of the tab "Requests for a certificate" and "Archive of Requests"). For each newly received request, a decision must be made (context menu when you right-click on the selected request):

Each request can be denied or approved:

If the request is rejected, then it is moved from the table of current requests reqDB to the table of the archive of requests reqDBArc and, accordingly, disappears in the tab "Requests for certificates" and appears in the tab "Archive of requests".

The approved application remains in the reqDB table and on the "Requests for certificates" tab until the certificate is issued, and then it also goes to the archive.

The procedure for issuing a certificate, the "Issue certificate" menu item) differs little from the procedure for creating an application:

The issued certificate immediately appears on the Certificates tab. In this case, the certificate itself enters the certDBNew table of the CA database and remains there until it is published. A certificate is considered published after it is exported to a SQL dump of new certificates, which is sent to a public service. Publishing the certificate moves it from the certDBNew table to the certDB table.

If you right-click on the selected line in the "Certificates" tab, a menu with the following functions will appear:

If the request was created at the CA with the generation of a key and its saving in a file, then you need to form a PKCS # 12 container and transfer it to the applicant:

You should pay attention to the "friendly name" - quotes in it must be escaped:

After the PKCS # 12 secure container is created, the applicant's private key file is destroyed.

So, the UC began its life, issued the first certificate. One of the tasks of the CA is to organize free access to issued certificates. The publication of certificates, as a rule, goes through web services. CAFL63 also has such a service:

To publish certificates and lists of revoked certificates on a public service, the CA either pre-uploads certificates to files (Certificates-\u003e Export certificates), or makes a SQL dump of the entire certificate table, from which you can create a certificate database and load a list of certificates into it, and then make a SQL dump of new certificates, from which they will be added to the database of the public service:

The fundamental function of the CA is to publish a list of revoked certificates, similar to how the Ministry of Internal Affairs does it with respect to expired passports. The certificate can be revoked at the request of the owner. The main reason for revocation is the loss of the private key or loss of trust in it.

To revoke a certificate, just select it on the "Certificates" tab, right-click and select the "Certificate revocation" menu item:

The revocation process is the same as for creating a request or issuing a certificate. The revoked certificate gets into the cerDBRev table of the CA database and appears in the “Revoked certificates” tab.

It remains to consider the last function of the CA - issuing a CRL - a list of revoked certificates. The CRL list is generated on the Revoked Certificates tab by clicking the Create SOS / CRL button. All that is required here from the administrator is to enter the CA password and confirm his intention to issue the CRL:

The released CRL goes into the crlDB table of the database and is displayed on the "CRL / COC" tab. To view the CRL or export it for publication on a public service, you must, as always, select the required line, right-click and select the menu item:

Download distribution kit CAFL63 for Win32 / Win64, Linux_x86 / Linux_x86_64 platforms. Moreover, it all works successfully on the Android platform.

Readers are invited to research work, in the course of which a number of problems with the use of EDS tools arising among Linux users are revealed. In particular, the following not quite obvious points were clarified:

• the opportunity to obtain and use a personal electronic digital signature certificate for access to public services is currently provided only for a fee by commercial organizations;
• electronic signature data carriers issued to end users by different authorized organizations may be incompatible both with each other and with portals that provide access to services, including government ones;
• the level of security of electronic signature data carriers, massively issued to end users, as a rule, is significantly reduced in relation to the technological level available today;
• for most OS users from the Register of Domestic Software, EDS mechanisms on the Unified Portal of Public Services are not available due to incompatibility software EPGU and software of authorized organizations issuing personal electronic signature certificates;
• in some cases, developers of portals providing government services, recommend using operating systems that are not included in the Registry, as well as software and configurations that knowingly reduce the security of user data.

The authors of the work expect that the results obtained will be useful to users of solutions that use EDS mechanisms, integrators implementing appropriate solutions, and will also be taken into account by organizations responsible for the provision of state information services and for the implementation of specific mechanisms for the EDS infrastructure, as well as by the developers of the corresponding software and hardware.

What is it about

The article is devoted to the support of electronic digital signature (EDS) of documents in OS ALT, as well as the specifics of the use of EDS in the Russian Federation.

The main task is to understand what needs to be done for an “ordinary user” ™ - it does not matter, an individual or a legal entity - acting on a general basis, so that, working in the OS from the Registry of domestic software, to fully use the capabilities of electronic trading platforms and portals of public services. Full use means, first of all, the ability to authenticate at the corresponding site using a certificate placed on a separate physical medium, and the ability to electronically sign documents generated in the site interface.

A number of research works have already been carried out on this topic, the result of which was the conclusion that, in principle, everything works. It is important to understand here that most of the studies of compatibility with the portals of state services of the Russian Federation of modern cryptographic tools running under the Linux OS were carried out in laboratory conditions. For example, if there are special agreements between the researcher and the certification center issuing the certificate. Unfortunately, based on the results of such work, it is difficult to judge the real possibilities of persons acting on a general basis.

How it all works

In order to enter the site without entering a username and password, but simply connecting a hardware token to the USB connector, it is necessary that a specialized software stack works correctly in the operating system: support for physical devices, cryptographic algorithms, software interfaces, formats and protocols of data exchange. At the same time, the compatibility of cryptographic algorithms, formats and protocols must also be ensured outside the OS responsibility - in the certification center issuing the certificate and on the site to which access must be provided.

And if we are also talking about the websites of government agencies, it is also necessary that the crypto tools used are certified for appropriate use in the Russian Federation.

Basic mechanisms

The EDS technology officially used in the Russian Federation is based on the public key infrastructure. Let's consider its work with an example.

For clarity, let us consider the mechanism of action of universal algorithms suitable for both electronic signatures and encryption. These algorithms include, among other things, the RSA Internet standard and the Russian GOST R 34.10-94, which operated in the Russian Federation as an electronic signature standard until 2001. More modern EDS algorithms, which include the current GOST R 34.10-2001 and GOST R 34.10-2012, are usually specialized. They are intended solely for signing documents, and are not suitable for encryption. Technically, the difference between specialized algorithms is that the hash is not encrypted in their case. Instead of encrypting it, other calculations are also performed on it using the private key, the result of which is stored as a signature. When verifying the signature, the corresponding complementary calculations are performed using the public key. The loss of universality in this case is a payment for higher cryptographic strength. The example below with a universal algorithm is perhaps a little less relevant, but probably more understandable to an unprepared reader.

Document signature

So, for the formation of an electronic signature in the public key infrastructure, an asymmetric encryption scheme is used, which is characterized by the use of a key pair. What is encrypted with one of these keys can only be decrypted with the other key in the pair. One of the keys of the pair is called secret, or private, and is kept as secret as possible, the other is called public, or open, and freely distributed - usually as part of a certificate. In addition to the key, the electronic signature certificate includes information about the owner of the certificate, as well as the signature of the key, together with information about the owner, made by a certain trusted party. Thus, the certificate already contains an electronic signature confirming the compliance of the information about the owner of his pair of keys.

Organizationally, this signature is performed by a certification center (CA) - legal entity, to which authority has been delegated to establish and confirm the correspondence of the owner and the key. Compliance is established after the presentation of paper documents, and it is confirmed precisely by means of an electronic signature, which is convenient to consider just on the example of making a certificate.

The CA also has a key pair for signing client certificates. Confirmed information about the owner of the certificate in the form of a specially designed table is combined into one document with its public key. This document then goes through two transformations. The document is first hashed into a unique, fixed-length (hash) character sequence. Further, the received hash is encrypted with the private key of the certification authority. The result of encryption is the actual electronic signature. It is attached to the signed document, in this case, information about the user and his key, and is distributed with him. All this together - a document with information about the user and his public key, as well as the signature of this document with the public key of the CA, is issued in a special way and is called a user certificate.

Just as in the case of user data in the certificate, the electronic signature of any other document is issued. For example, a file with an application for a service. The file is hashed, the resulting hash is encrypted with the user's secret key and attached to the document. The result is a signed document.

Signature verification

As is usually the case with asymmetric encryption, what is encrypted with one key can only be decrypted with the other key in the pair. So, in the case of a certificate, an encrypted hash of a document containing the user's public key and verified information about the user can be decrypted using the certification authority's public key, which is freely distributed as part of the certification authority's certificate. Thus, anyone who receives a CA certificate will be able to obtain a decrypted hash from the user certificate. Since the hashing function gives a unique result, applying it to a document containing a user's public key and information about it, you can check whether these two hashes match. If there are, then we have before us the same document that was signed by the certification center, and the information contained in it can be trusted. If not, then the signature does not correspond to the document, and we have a fake.

The situation with the verification of the CA certificate is exactly the same - it is also signed with some kind of key. As a result, the chain of signed certificates ends with a "root" certificate that is signed by itself. Such a certificate is called self-signed. For officially accredited certification centers of the Russian Federation, the root certificate is the certificate of the Head certification center of the Ministry of Telecom and Mass Communications.

In addition to information about the user and his public key, the certificate includes some additional data - in particular, the certificate validity period. If at least one certificate in the chain has expired, the signature is considered invalid.

Also, the signature will be considered invalid if the client certificate is revoked by the certification authority. The ability to revoke a certificate is useful, for example, in situations where a private key is leaked. The analogy with contacting the bank in case of loss of a bank card is appropriate.

Services of certification centers

So, the certification authority confirms with its signature the correspondence of a certain public key to a certain set of records. Theoretically, the CA costs for signing one certificate are close to zero: the signature itself is a well-automated, not very expensive computational operation on modern equipment. At the same time, CA services are paid. But, unlike CAs that issue certificates for websites, money here is not made entirely out of thin air.

The first component of the cost of the certificate is the overhead of servicing an accredited CA. These include: the cost of a CA certificate, which is also paid, the cost of a license for certified software, the cost of providing organizational measures to protect personal data, and so on. This is how the value of, for example, a personal certificate of an individual is determined. Which makes it possible to sign local files, documents on government service websites and mail messages.

The second term of the certificate value appears when a user wants to use his certificate, for example, to work on electronic trading platforms. According to the current regulations, the site of the electronic trading platform authenticates the client if two conditions are met: firstly, of course, if the certificate has not expired, the certificate has not been revoked and its signature is valid. And secondly, if the certificate clearly states that it is intended to work on a specific site. This entry looks like a regular entry in the same table that stores the rest of the certificate data. For each such entry in each user certificate, the certification authority gives a certain amount. Which he seeks to compensate at the expense of the owner of the certificate. Therefore, certificates that enable entry to electronic trading platforms are more expensive.

Threats and attacks

In contrast to encryption, in the case of an electronic signature, the main task of an attacker is not to obtain the decrypted text, but to the ability to forge or electronically sign an arbitrary document. That is, relatively speaking, not to decryption, but to encryption. Conditionally - because modern specialized EDS algorithms, as mentioned above, do not encrypt the hash of a document, but perform mathematical operations that are similar in meaning, but differ in technical terms.

According to the standards adopted in the Russian Federation, when electronically signing documents, cryptographic algorithms are used that comply with the State Standard of the Russian Federation (GOST R). At the time of this writing (the second half of 2016), for none of the algorithms related to digital signatures and having the status of a standard in the Russian Federation, there are no attack methods that are significantly different in complexity from a simple search. In practice, this means that for an attacker whose level of access to computing resources is lower than that of a large state, it is easier to try to steal the key than to break the algorithm and forge the signature.

Thus, in the case of an electronic signature, the main attack vectors are aimed at obtaining the secret key by the attacker. If the key is stored in a file on disk, it can be stolen at any time by obtaining the appropriate read access. For example, using a virus. If the key is stored in an encrypted form, it can be obtained at the time of use - for example, when the program performing the electronic signature has already decrypted the key and processes the data with it. In this case, the task becomes much more complicated - you need to find a vulnerability in the program, or you will have to decrypt the key yourself. Despite the significant complication of the task, it still remains quite realistic. For specialists in the relevant field, it belongs to the category of routine.

To make it even more difficult for an attacker to obtain a private key, you can place the secret key on a separate hardware medium so that the key never leaves the physical device. In this case, an attacker can only gain access to the key by stealing the physical device. The loss of the device will be a signal to the owner that the key has been stolen. In any other case - and this is the most important nuance - the theft of the key may go unnoticed, and the owner of the key will not find out in time that it is necessary to urgently contact the CA and revoke his certificate.

Here again, the analogy with a bank card is appropriate, which is an authentication means for accessing a bank account. As long as the owner has it, he is calm. If the card is lost, you need to block it urgently. At the same time, the attacker's task is not to steal the card, but to secretly make a copy of it so that the owner does not block access. For modern hardware tokens, cloning methods are currently unknown.

Tokens

At the moment, the generally accepted term for the individual physical devices used to store electronic signature keys is a token. Tokens can be connected to a computer via USB, Bluetooth, or through special reader devices. Most modern tokens use the USB interface. But the main difference between token types is not in the connection interface. Tokens can be divided into two types - those that are actually used only as a key store, and those that "know" to perform cryptographic operations by their own means.

Tokens of the first type differ from ordinary flash drives in fact only in that data can be read from them only with the help of special software. For the rest, it is an ordinary external data storage, and if we store a secret key in it, then anyone who gets the right to access the device and knows how to read the key from it can steal it. Such tokens are called software tokens and have practically no advantages over storing the key on a computer disk - the owner of the key also cannot be sure that he knows all the places where his secret key is stored.

Tokens of the second type are called hardware tokens, and their main difference is that the secret key is non-retrievable - it never leaves the token's limits. To do this, a special set of software is placed on the token, which is activated when the token is connected to the computer. In essence, such a token is an independent computing device with its own processor, memory and applications that exchanges data with a computer.

The secret key never leaves the limits of the hardware token, because it is generated directly on the token itself. To sign a document, the hash of the document is loaded into the token, calculations are made right on board the token using the secret key stored there, and the finished signature is unloaded back. Thus, knowing the location of the token, we always know the location of the secret key.

One of the main characteristics of a hardware token is the set of supported cryptographic algorithms. For example, if we want to use a hardware token to authenticate with our home computer, any modern token will do. And if we want to authenticate on the State Services portal, then we need a token that supports cryptographic algorithms certified in Russia.

Below are the lists of supported cryptographic mechanisms for eToken and JaCarta GOST tokens. To request a list of mechanisms, an open utility pkcs11-tool was used with the "-M" parameter (from the word "mechanism"), which can act as a client application for any library that implements the PKCS # 11 interface in its direction. As PKCS # 11 libraries, libeToken.so and libjcPKCS11.so.1 are used for eToken and JaCarta, respectively. The library for eToken is distributed as part of the SafeNet software, the library for JaCarta is available for download from the website of the company Aladdin R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Supported mechanisms: DES-MAC, keySize \u003d (8,8), sign, verify DES-MAC-GENERAL, keySize \u003d ( 8,8), sign, verify DES3-MAC, keySize \u003d (24,24), sign, verify DES3-MAC-GENERAL, keySize \u003d (24,24), sign, verify AES-MAC, keySize \u003d (16,32 ), sign, verify AES-MAC-GENERAL, keySize \u003d (16,32), sign, verify RC4, keySize \u003d (8,2048), encrypt, decrypt DES-ECB, keySize \u003d (8,8), encrypt, decrypt , wrap, unwrap DES-CBC, keySize \u003d (8,8), encrypt, decrypt, wrap, unwrap DES-CBC-PAD, keySize \u003d (8,8), encrypt, decrypt, wrap, unwrap DES3-ECB, keySize \u003d (24,24), hw, encrypt, decrypt, wrap, unwrap DES3-CBC, keySize \u003d (24,24), hw, encrypt, decrypt, wrap, unwrap DES3-CBC-PAD, keySize \u003d (24.24), hw, encrypt, decrypt, wrap, unwrap AES-ECB, keySize \u003d (16.32), encrypt, decrypt, wrap, unwrap AES-CBC, keySize \u003d (16.32), encrypt, decrypt, wrap, unwrap AES-CBC -PAD, keySize \u003d (16.32), encrypt, decrypt, wrap, unwrap mechtype-0x1086, keySize \u003d (16.32), encrypt, decrypt, wrap, unwrap mec htype-0x1088, keySize \u003d (16.32), encrypt, decrypt, wrap, unwrap RSA-PKCS-KEY-PAIR-GEN, keySize \u003d (1024.2048), hw, generate_key_pair RSA-PKCS, keySize \u003d (1024.2048 ), hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap RSA-PKCS-OAEP, keySize \u003d (1024,2048), hw, encrypt, decrypt, wrap, unwrap RSA-PKCS-PSS, keySize \u003d (1024,2048), hw, sign, verify SHA1-RSA-PKCS-PSS, keySize \u003d (1024,2048), hw, sign, verify mechtype-0x43, keySize \u003d (1024,2048), hw, sign, verify mechtype -0x44, keySize \u003d (1024.2048), hw, sign, verify mechtype-0x45, keySize \u003d (1024.2048), hw, sign, verify RSA-X-509, keySize \u003d (1024.2048), hw, encrypt , decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap MD5-RSA-PKCS, keySize \u003d (1024,2048), hw, sign, verify SHA1-RSA-PKCS, keySize \u003d (1024,2048), hw, sign , verify SHA256-RSA-PKCS, keySize \u003d (1024,2048), hw, sign, verify SHA384-RSA-PKCS, keySize \u003d (1024,2048), hw, sign, verify SHA512-RSA-PKCS, keySize \u003d (1024 , 2048), hw, sign, verify RC4-KEY-GEN, keySize \u003d (8.204 8), generate DES-KEY-GEN, keySize \u003d (8,8), generate DES2-KEY-GEN, keySize \u003d (16,16), generate DES3-KEY-GEN, keySize \u003d (24,24), generate AES -KEY-GEN, keySize \u003d (16,32), generate PBE-SHA1-RC4-128, keySize \u003d (128,128), generate PBE-SHA1-RC4-40, keySize \u003d (40,40), generate PBE-SHA1- DES3-EDE-CBC, keySize \u003d (24,24), generate PBE-SHA1-DES2-EDE-CBC, keySize \u003d (16,16), generate GENERIC-SECRET-KEY-GEN, keySize \u003d (8.2048), hw, generate PBA-SHA1-WITH-SHA1-HMAC, keySize \u003d (160,160), hw, generate PBE-MD5-DES-CBC, keySize \u003d (8,8), generate PKCS5-PBKD2, generate MD5-HMAC-GENERAL, keySize \u003d (8.2048), sign, verify MD5-HMAC, keySize \u003d (8.2048), sign, verify SHA-1-HMAC-GENERAL, keySize \u003d (8.2048), sign, verify SHA-1-HMAC , keySize \u003d (8.2048), sign, verify mechtype-0x252, keySize \u003d (8.2048), sign, verify mechtype-0x251, keySize \u003d (8.2048), sign, verify mechtype-0x262, keySize \u003d (8 , 2048), sign, verify mechtype-0x261, keySize \u003d (8.2048), sign, verify mechtype-0x272, keySize \u003d (8.2048), sign, verify mechtype-0x271, keySize \u003d (8.2 048), sign, verify MD5, digest SHA-1, digest SHA256, digest SHA384, digest SHA512, digest mechtype-0x80006001, keySize \u003d (24,24), generate $ pkcs11-tool --module / usr / local / lib64 / libjcPKCS11.so. 1 -M Supported mechanisms: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, sign, verify GOSTR3410-WITH-GOSTR3411, hw, sign, verify mechtype-0x1204, hw, derive GOSTR3411, hw, digest20 mechtype-0x12 , generate mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

It can be seen that the list of supported mechanisms for eToken is very long, but it does not include GOST algorithms. The list of supported JaCarta mechanisms includes only GOST algorithms, but in the amount necessary to implement the EDS functionality on a hardware token.

It is important to understand that modern hardware tokens can usually be used as software tokens as well. That is, they usually have a small piece of memory accessible from the outside, which, if desired, can be used to record and store an externally generated secret key. Technologically, this makes no sense, but in fact this method is used, unfortunately, quite widely. Unfortunately, because often the token owner does not know that his modern hardware token, honestly bought not for a nominal fee, is used as a software one.

Rutoken S and Rutoken Lite are examples of software-only tokens. Examples of hardware tokens that do not support Russian-certified cryptographic algorithms are eToken devices; as supporting Russian cryptography - "Rutoken EDS", "JaCarta GOST".

Crypto providers

The software that provides the operator with access to cryptographic functions - electronic signature, encryption, decryption, hashing - is called a cryptographic provider, a provider of cryptographic functions. In the case of a hardware token, the crypto provider is implemented directly on the token, in the case of a software token or in the case of storing keys on a computer disk, in the form of a regular user application.

From the point of view of the security of user data, one of the main attack vectors is directed at the encryption provider - it is in the memory of the encryption provider that the secret key is contained in decrypted form. In the event of a successful attack, an attacker will be able to replace the application code with his own and take a copy of the secret key, even if the key is normally stored encrypted. Therefore, in the case of using cryptography to perform a legally binding electronic signature, the state seeks to protect citizens from possible leakage of secret keys. This is expressed in the fact that to work with a qualified electronic signature, it is officially allowed to use only crypto providers that have the appropriate certificate and have passed, therefore, the appropriate checks.

Crypto providers certified on the territory of the Russian Federation for EDS include, in particular: Rutoken EDS, JaCarta GOST, CryptoPro CSP"," LISSY-CSP "," VipNet CSP ". The first two are implemented directly on hardware tokens, the rest as custom applications. It is important to understand that when purchasing a hardware token certified in the Russian Federation, we are already acquiring a crypto provider certified in the Russian Federation, and there is no need - technological and legal - to buy another crypto provider.

In addition to the set of supported algorithms, cryptographic providers also differ in the set of cryptographic functions - encryption and decryption of documents, signing and verification of signatures, the presence of a graphical user interface, and so on. Moreover, of this entire set of functions, a certified crypto provider must perform only those that relate directly to the implementation of cryptographic algorithms. Anything else can be done by a third party application. This is exactly how cryptographic providers work on hardware tokens: the user interface is implemented by a third-party application that is not subject to mandatory certification. An application that implements a user interface communicates with a cryptographic provider using a token through another standard interface - PKCS # 11. At the same time, from the user's point of view, working with keys occurs, for example, directly from the Firefox html browser. In fact, the browser uses a special software layer through the PKCS # 11 interface, which implements mechanisms for accessing a specific hardware token.

In addition to the term "cryptographic provider", there is another term close in meaning - "means of cryptographic information protection" (CIPF). There is no clear distinction between the two. The first term is less official, the second is more often used in relation to certified technical solutions. Since this document mainly describes technological rather than formal aspects, we will often use the term "cryptographic provider".

Implementation of mechanisms

Electronic signature algorithms

At the moment, in the Russian Federation, only two signature algorithms and two hashing algorithms are officially allowed to be used for a qualified electronic signature. Until the end of 2017, it is allowed to use GOST R 34.10-2001 together with the GOST R 34.11-94 hashing algorithm. Since the beginning of 2018, it is allowed to use only GOST R 34.10-2012 and hashes according to GOST R 34.11-2012. In situations where the mandatory use of GOST algorithms is not required, you can use any available algorithms.

For example, now most of the websites accessible via the HTTP protocol do not know how to use GOST algorithms for mutual authentication of the client and server. In case of interaction with one of such sites, the client side will also have to apply the algorithms of "foreign production". But, for example, if you want to use a hardware token as a key store for authentication on the State Services website, you will have to choose a token with EDS support in accordance with GOST.

The need to use Russian algorithms when interacting with government agencies is not due to a desire to restrict citizens in their choice. The reason is that the state, having invested in the development of these algorithms, is responsible for their cryptographic strength and the absence of undeclared capabilities in them. All cryptographic algorithms standardized in the Russian Federation have been independently audited several times and have convincingly proven their worth. The same can be said for many other common cryptographic algorithms. But, unfortunately, the absence of undeclared capabilities in them cannot be proved with the same ease. It is quite clear that from the point of view of the state, it is unreasonable to use untrusted means, for example, to process personal data of citizens.

Interfaces, formats and protocols

To ensure compatibility when working with electronic signatures, a number of international standards have been developed regarding data storage and provision of access to them. The main standards include:

• PC / SC - low-level interface for access to cryptographic devices, including software and hardware tokens;
• PKCS # 11 - a high-level interface for interacting with hardware cryptographic modules, can be considered as a unified interface for accessing cryptographic providers;
• PKCS # 15 - a format of a container with electronic signature keys intended for storage on a physical device;
• PKCS # 12, PEM - formats of containers with electronic signature keys intended for storage in files, binary and text, respectively;
• PKCS # 10 - format of a document - a signature request sent by the client to the CA to obtain a signed certificate.

It is important to understand that standards such as PKCS # 11 or PKCS # 15 were originally developed without taking into account the specifics of cryptographic facilities certified in the Russian Federation. Therefore, in order to implement full-fledged support for domestic cryptography, the standards had to, and still have to, be refined. The process of adopting amendments to the standards is long, therefore, until the finalized standards were finally adopted, their implementations appeared that were incompatible with each other. This also applies to crypto providers certified in the Russian Federation. So, now all certified crypto providers have incompatible implementations of the container for storing keys on the token. As for the data exchange standards - PKCS # 10, PKCS # 12, PEM - their implementations, fortunately, are usually compatible with each other. Also, there is usually no discrepancy in the interpretation of the PC / SC standard.

The issues of finalizing standards, developing recommendations, ensuring compatibility in the field of digital signatures in the Russian Federation are currently being dealt with by a special organization - the Technical Committee for Standardization "Cryptographic information security" (TK 26), which includes experts, representatives of government agencies, developers of crypto providers and other interested faces. One can argue about the effectiveness of the committee's work, but even the very existence of such a platform is extremely important.

Software part

The software stack for working with electronic signature consists of the following components:

• implementation of an interface for low-level access to storage of containers with keys - for example, a PC / SC interface for accessing physical devices - tokens;
• a module that implements the PKCS # 11 interface for interacting with a cryptographic provider - for example, executed on a hardware token;
• a cryptographic provider that implements the appropriate cryptographic algorithms and performs actions with them - for example, an electronic signature or data encryption;
• a user application that interacts with the other - in relation to the cryptographic provider - side with the PKCS # 11 module, and performs operations on behalf of the user, such as electronic signature or authentication.

Stack example:

• the cryptcp command line application from the CryptoPro CSP software interacts with the libcppksc11.so library through the PKCS # 11 interface and enables signing documents with the user's secret key; the functions of the cryptographic provider are fully implemented in the components of the CryptoPro CSP software, the cryptographic provider of the hardware token is not used.

Another example:

• open source software pcsc-lite implements the PC / SC interface for interaction with the hardware token "Rutoken EDS";
• the libcppksc11.so library from the CryptoPro CSP software provides interaction with the container placed on the token, which stores the user's private key and certificate;
• the CryptoPro EDS Browser plugin application, which is part of the Firefox html browser, interacts with the libcppksc11.so library through the PKCS # 11 interface and provides the ability to sign documents in the browser interface on electronic sites trading platforms; the functions of the cryptographic provider are fully implemented in the components of the CryptoPro CSP software, the cryptographic provider of the hardware token is not used.

Third example:

• open source software pcsc-lite implements the PC / SC interface for interaction with the hardware token "Rutoken EDS";
• the librtpksc11.so library produced by the Aktiv company provides interaction with the token's crypto provider;
• the token's crypto provider performs the functions of signing the data transmitted to it with a secret key; the secret key does not leave the token limits;
• the "Rutoken Plugin" application, which works as part of the Firefox html browser, interacts with the librtpksc11.so library through the PKCS # 11 interface and provides the ability to sign documents in the browser interface on compatible sites; at the same time, the functions of the crypto provider are fully implemented on the hardware token.

The choice of a specific implementation of the stack at the moment is determined, first of all, by three factors - the intended area of \u200b\u200bapplication of the digital signature, the level of technical literacy of the user and the willingness of the certification authority to work with a request to sign a certificate.

In addition to the above set of user-side software, there are two more applications, the features of which must be taken into account. The first is the software that serves the certification authority. The second is the software we want to be compatible with. For example, the website of the State Services. Or software for signing electronic documents.

If the certification authority where we plan to obtain a certificate is not ready to work with signature requests in the PKCS # 10 format and knows how to work only with software tokens (that is, it treats any token as software), we have no choice. As a rule, in this case, the CA software will generate a key pair for us, write it to the token, immediately generate a signature request based on the public key and our personal data, sign it, and save the certificate to the token. At the same time, the certificate and key will be in a closed format container known only to the UC software developer. Accordingly, to access the container with keys, you will have to buy a crypto provider from the same developer. And the scope of EDS application will be limited by the software capabilities of one specific developer. There is no point in buying a hardware token in this case - you can get by with a software one. In this case, the token must be carried to the CA.

If the certification authority in which we plan to obtain a certificate is ready to work with signature requests in the PKCS # 10 format, then we don't care what software is used in this CA. We will be able to use the crypto provider that is compatible with our target applications. For example, with electronic trading platforms or the website of the State Services. In this case, you do not need to carry the token to the CA, it is enough to generate a signature request and present it there along with your paper documents; get a certificate, and save it on a token by yourself using the chosen encryption provider.

Unfortunately, very few CAs at the moment (end of 2016) are ready to work with a request for signature. In part, this situation is due to the insufficient level of technical training of users who are not able to ensure that the request for a signature is executed properly - with all the necessary attributes and their values \u200b\u200bindicated. This guide is also aimed at solving this problem.

Hardware part

Among the tokens presented on the Russian market are the following:

Hardware carriers with support for Russian cryptography: Rutoken EDS, JaСarta GOST, MS_KEY K.

Let's consider as an example the lists of supported cryptographic mechanisms of hardware Rutoken EDS and software Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Supported mechanisms: RSA-PKCS-KEY-PAIR-GEN, keySize \u003d (512.2048), hw, generate_key_pair RSA-PKCS, keySize \u003d ( 512,2048), hw, encrypt, decrypt, sign, verify RSA-PKCS-OAEP, keySize \u003d (512,2048), hw, encrypt, decrypt MD5, digest SHA-1, digest GOSTR3410-KEY-PAIR-GEN, hw , generate_key_pair GOSTR3410, hw, sign, verify mechtype-0x1204, hw, derive GOSTR3411, hw, digest GOSTR3410-WITH-GOSTR3411, hw, digest, sign mechtype-0x1224, hw, wrap, unwrap mechtype-0x1221, hw, decrypt mechtype-0x1222, hw, encrypt, decrypt mechtype-0x1220, hw, generate mechtype-0x1223, hw, sign, verify $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -Morted Supp mechanisms:

As you can see, the lists of supported cryptographic mechanisms Rutoken Lite is empty, unlike Rutoken EDS, which includes GOST and RSA algorithms.

Hardware tokens without Russian cryptography support, as mentioned above, include, in particular, JaCarta PKI and eToken.

Considering the relatively low prices for hardware tokens with support for Russian cryptography, we can confidently recommend using them. In addition to the clear advantage in the form of a non-retrievable secret key, the hardware token also includes a certified encryption provider. That is, it is possible to organize the work with the token in such a way that there is no need to additionally purchase expensive software.

Of recent developments, I would like to note Rutoken EDS 2.0 with support for the GOST R 34.10-2012 standard.

Application

User tools

Open tools

Open source software currently allows you to implement an almost complete software stack for working with digital signatures.

PCSC lite

The PC / SC implementation, developed within the PCSC lite project, is the reference for the Linux operating system. It is part of any of the options of the software stack for working with digital signatures considered in this document. In what follows, if a specific implementation option is not specified, we will assume it is enabled by default.

Opensc

The library that implements the PKCS # 11 interface, as well as a set of applied tools that use its functionality, was developed as part of the OpenSC project. The toolkit supports many hardware tokens, including Rutoken EDS, support for which was added by the specialists of the Aktiv company, which develops tokens of the Rutoken family.

Using the OpenSC utilities, you can perform on a hardware token, in particular, the following actions:

• initialize token - reset settings to their original state;
• set administrator and user PIN codes (if supported);
• generate a key pair (if supported by the PKCS # 11 library);
• import a certificate signed by a certification authority to a token.

The PKCS # 11 library from the OpenSC suite allows performing a full set of operations with an electronic signature on supported tokens. Supported tokens also include Rutoken EDS.

It is important to understand here that for Rutoken EDS there are two different options for software support that are not compatible with each other in terms of the key storage format on the token. When using the PKCS # 11 library from the OpenSC, we can use the open software stack, and when using the free closed library produced by the company "Aktiv", we can use the closed "Asset" stack.

OpenSSL

In order to fully use the EDS capabilities, in addition to the PKCS # 11 library itself, custom applications must be implemented that provide the operator with access to the library functions and token capabilities. A striking example of such an implementation is open source software from the OpenSSL project. It supports, in particular, the following functions:

• data encryption;
• decryption of data;
• document signature;
• verification of the signature;
• generating a request for signing a certificate;
• import of the certificate;
• export of the certificate.

In addition, using OpenSSL, you can implement the functionality of a full-fledged certification authority, including:

• issuing client certificates by signing PKCS # 10 signature requests;
• revocation of client certificates;
• registration of issued and revoked certificates.

The only flaw in OpenSSL that does not yet allow the implementation of a fully functional version of the EDS software stack based on open source software is the absence of an open module for interacting with PKCS # 11 libraries with support for GOST algorithms. There is a closed implementation of such a module made by the Aktiv company, but it is not included in the basic OpenSSL distribution, and therefore, with the release of new versions of OpenSSL, compatibility is periodically broken. The open source implementation of this module does not yet support GOST algorithms.

Firefox

In addition to OpenSSL, the well-known html browser Firefox is also able to interact with PKCS # 11 libraries. To connect the PKCS # 11 library, you need to go to the "Preferences" settings management menu, then select "Advanced" in the vertical list on the left, select "Certificates" in the horizontal list, click the "Security Devices" button, in the dialog box that appears, click the "Load ". Another window will appear with the option to select the path to the file with the PKCS # 11 library and the option to enter a local name for that particular library. You can load several different PKCS # 11 modules this way for different types of physical and virtual devices.

Unfortunately, Firefox's functionality is not yet sufficient to sign documents in the website interface. Therefore, for a full-fledged open EDS software stack with GOST support, there is still a lack of a plug-in (plug-in) that allows you to access objects on a token from the site software. We hope that such a plugin will be written in the near future. Or open.

CryptoPro

In versions of CryptoPro CSP up to 4.0 inclusive, manual management of local caches is used to store user certificates and CA certificates. For a full-fledged work with a user certificate, it is necessary that its copy is in one local cache, and the complete chain of CA certificates up to and including the root is in another. Technologically, this feature of CryptoPro, strictly speaking, is not entirely justified: it makes sense to check the chain during authentication; the fact of the validity of the certificate does not affect the possibility of signing. Moreover, if this is our own certificate and we know where it came from. In the beta versions of CryptoPro CSP, fresh at the time of this writing, according to the developers, automatic loading of the CA certificate chain is implemented. But making sure that the local user certificate cache contains only the one that is currently being used seems to still have to be manually monitored.

Third-party developers are attempting to write graphical interfaces for CryptoPro CSP to facilitate routine user operations. An example of such a utility is the rosa-crypto-tool, which automates the signing and encryption of documents. Package in distributions ALT.

CryptoPro UC

Lissi SOFT software is characterized by strict adherence to standards and technical specifications. Crypto providers, including unique ones, are designed as PKCS # 11 libraries. According to the developers, they fit well with open source software, also focused on supporting standards. For example, with html-browsers and utilities from the OpenSSL suite.

Lissi SOFT products are also of interest in terms of organizing access to public service websites. First of all - compatibility with "IFCPlugin" - a browser plug-in that implements EDS mechanisms on the State Services portal. Secondly, the ability of the software of certification authorities to work with requests for signing a certificate in the PKCS # 10 format.

Browsers

Sometimes, to access sites where we plan to use electronic signature mechanisms, we have to use other technologies that use Russian cryptography. For example, GOST algorithms can be used to organize an encrypted data transmission channel. In this case, it is necessary to support the corresponding algorithms in the browser. Unfortunately, the official builds of Firefox and Chromium do not yet fully support Russian cryptography. Therefore, you have to use alternative assemblies. Such assemblies are, for example, in the arsenal of crypto-tools of the companies "CryptoPro" and "Lissi SOFT", as well as in the distributions Alt.

Websites

Among the sites that require the use of electronic signature technologies, we are primarily interested in sites providing government services, as well as electronic trading platforms (ETP). Unfortunately, some ETPs do not yet support working with OS from the Registry of domestic software. But the situation is gradually changing for the better.

The use of digital signatures for web sites usually boils down to the authentication and signature of documents generated in the site interface. In principle, authentication looks the same as the signature of any other document: the site on which the client wants to authenticate generates a sequence of characters that it sends to the client. The client sends back the signature of this sequence, executed using his private key, and his certificate (certificate - a little earlier). The site takes the public key from the client certificate and verifies the signature of the original sequence. The same happens when signing documents. Here, instead of an arbitrary sequence, the document itself appears.

Public services

As a result of the study, it turned out that as of December 14, 2016, most of the federal trading floors - "", "RTS-tender" and "Sberbank-AST" are ready for use in workplaces running Linux operating systems. The remaining two sites do not yet even provide the ability to log in with a client certificate. Whether their developers are planning any measures to ensure compatibility, unfortunately, has not yet been found out.

At the same time, in the official instructions of all sites except for the "United Electronic Trading Platform", the Windows operating system is indicated as the only supported one. Official answers from technical support services confirm this information. The instruction on the website of the "United Electronic Trading Platform" describes how to configure the browser without specifying a specific operating system.

The results of the study are summarized in the table:

Electronic marketplace	Login with user certificate	The ability to sign a document in the site interface	Documentation for working with the platform for OS from the Registry
Sberbank - Automated trading system	Yes	Yes	No
Unified electronic trading platform	Yes	Yes	Yes

For ETPs providing compatibility with Linux, the only supported crypto-tool at the moment is the Cades plugin, which can only use CryptoPro CSP as a crypto provider. Thus, the good news is that it is very easy to get a token for access to electronic trading platforms - most CAs issue them. Bad news - the token will be software and will not be compatible with the State Services website.

For the rest of the trading platforms, the only means of access to the EDS functionality is a Windows OS component called CAPICOM. Etersoft specialists carried out a research work, as a result of which the theoretical possibility of running CAPICOM in the Wine environment was clarified.

Other sites

In addition to the listed sites that use EDS directly - to enter the site and sign documents generated in the site interface, there are a number of sites that provide the ability to download documents previously signed with a qualified electronic signature. An example is the website of the Main Radio Frequency Center. Access to the site is carried out by login and password, and documents are prepared and signed in advance - in the user OS interface. Thus, to work with such sites, only the functionality of local document signing is needed. That is, there are practically no restrictions on the choice of a crypto provider in this case.

An example of a ready-made solution

Unfortunately, at the moment, the authors of this document do not know how to use the same token simultaneously on the State Services website and on electronic trading platforms. Therefore, you have to make two tokens with two key pairs and two certificates, respectively. This is not prohibited by law, but technically feasible. Financially, it is also quite realistic: one token will be, for example, a hardware Rutoken EDS, the other - some old eToken model, which can now be found for a nominal fee.

Access to the website of the State Services

To access the State Services, take the Rutoken EDS and perform the following actions:

1. download the "Rutoken plugin" software from the page following the link;
2. install the Rutoken plugin - copy the plugin files (npCryptoPlugin.so and librtpkcs11ecp.so) to ~ / .mozilla / plugins /;
3. go to the website with the Registration Center software and, according to the instructions, perform the following actions - initialize the token, generate a pair of keys, generate and save a file with a signature request in PKCS # 10 format;
4. we will contact the CA, ready to issue us a certificate upon request for signature, we will receive the certificate in the form of a file;
5. in the interface of the Registration Center, save the certificate from the received file on the token;
6. download the "deb" format package using the link - the IFCPlugin-x86_64.deb file;
7. using the "Midnight Commander" software (mc command) we will "enter" the package file as in the directory;
8. copy the contents of the directory CONTENTS / usr / lib / mozilla / plugins to the local directory ~ / .mozilla / plugins;
9. in the Firefox browser on the State Services website, follow the links "Login" and "Login using electronic means".

The main problem in implementing this instruction is to find a certification authority that is ready to work with a signature request.

Access to electronic trading platforms

To access the sites of electronic trading platforms that support work in Linux, perform the following steps:

1. with any token officially sold in the Russian Federation, we will contact any certification center using the CryptoPro UC software, and we will receive a user certificate and a secret key stored on the token in a container of the format supported by CryptoPro software;
2. in accordance with the instructions, install the CryptoPro CSP and Cades plugin software for the Chromium browser;
3. using the Chromium browser, we will go to the websites of electronic trading platforms and start working with them according to the official instructions.

The possibility of signing documents in the form of files will be available through the CryptoPro console utilities and through third-party wrapper applications such as the already mentioned rosa-crypto-tool.

REGULATIONS

Certification center

-Soft "

1. Information about the Certification Center ............................................ ....................................... 2

2. Terms and definitions ............................................. .................................................. ........... 2

3. General provisions .............................................. .................................................. .................... 4

4. Rights and obligations of the parties ............................................ .................................................. ..... 6

5. Rules for using the services of the Certification Center ........................................... .... nine

6. Other conditions .............................................. .................................................. ....................... 13

7. Remuneration of the Certification Center ............................................. ........................... 21

8. Dispute Resolution .............................................. .................................................. ................. 21

9. Responsibility of the parties .............................................. .................................................. ......... 21

1. Information about the Certification Center

Agent - representative Certification Centerperforming on behalf of Certification Center the procedure for identifying a user or a trustee by identifying with a passport or other identity document, acceptance and verification of documents submitted by the user to Verification Center.

Electronic signature - information in electronic form, which is attached to other information in electronic form (information to be signed) or otherwise related to such information and which is used to identify the person signing the information.

Electronic signature verification key certificate - electronic document or a paper document issued by U credible center or a trusted person Certification center and confirming the ownership of the electronic signature verification key to the owner of the electronic signature verification key certificate.

Qualified certificate of the electronic signature verification key (hereinafter - the certificate) - certificate of the electronic signature verification key issued by an accredited Certification center or a trustee of an accredited Certification center.

Owner of the electronic signature verification key certificate - a person who, in accordance with the procedure established by these Regulations, has been issued a certificate of the electronic signature verification key.

Electronic signature key - a unique sequence of characters used to create an electronic signature.

Electronic signature verification key - a unique sequence of characters, uniquely associated with the key of the electronic signature and intended to verify the authenticity of the electronic signature (hereinafter - verification of the electronic signature).

Means of electronic signature - encryption (cryptographic) means used to implement at least one of the following functions - creation of an electronic signature, verification of an electronic signature, creation of an electronic signature key and an electronic signature verification key.

Single register - general structured reference, including:

· Lists of revoked certificates for signing keys for ordering participants issued by Authorized Certification Authorities, and specifying the distribution points of the CRL.

Compromise of an electronic signature key - loss of confidence that the used electronic signature key ensures the security of information.

Certificate Authority User (hereinafter referred to as the user) - an individual who has joined the Regulations and is registered in Certification Center (if a legal entity or an individual entrepreneur joins the Regulations, an individual who is an authorized representative of a legal entity, an individual entrepreneur)

User of an Authorized Certification Authority - an individual who is a participant in the placement of an order, or an individual who is an authorized representative of a legal entity that is a participant in the placement of an order, registered in the certification center and owning the certificate of the electronic signature verification key issued by the certification center;

Alias - the fictitious name of an individual, which this person knowingly and legally accepts for registration with Certification Center.

Electronic document - a document in electronic form, signed (secured) with an electronic signature and having equal legal force with a document on paper, signed by handwritten signatures of authorized persons and a certified seal.

Working day of the Certification Center (hereinafter - working day) - the period from 09:00 to 18:00 every day of the week, excluding weekends and holidays. Weekends and holidays are determined taking into account the postponement of days on the basis of decisions of the Government of the Russian Federation.

Certificate Authority Register - set of documents Certification Center in electronic and / or paper form, including the following information:

Register of applications for accession to the Regulation Certification Center;

Register of applications for user registration in Certification Center;

· Register of registered users of the CA;

· Register of applications for the production of a certificate of the electronic signature verification key;

· Register of applications for cancellation (revocation) of the electronic signature verification key certificate;

· Register of applications for suspension / renewal of the electronic signature verification key certificate;

· Register of applications for confirmation of the authenticity of an electronic signature in an electronic document;

Register of applications for confirmation of the electronic signature of an authorized person Certification Center in issued certificates;

· Register of certificates of keys for verification of electronic signature;

· A register of issued CRLs.

Certificate Revocation List (CRL) - an electronic document with an electronic signature of an authorized person Certification Center, which includes a list of serial numbers of certificates that at a certain point in time were revoked or suspended.

Authorized representative - an individual who is empowered by a legal or natural person to use the services Certification Center.

Authorized person of the Certification Center - an individual who is an employee Certification Center and endowed Certification Center powers to certify certificates of keys for verification of electronic signatures and a list of revoked certificates.

Authorized operator of an electronic site (Authorized operator) - an operator of an electronic site that has entered into an authorization agreement with a certification center, obliged to ensure the use of certificates of keys for verifying electronic signatures produced on electronic sites Certification center.

3. General Provisions

3.1. Subject of the Regulation

This Regulation Certification Center (hereinafter the Regulation) determines the conditions for the provision and rules for using the services Certification Center, including rights, duties, responsibility Certification Center and users Certification Center, data formats, main organizational and technical measures aimed at ensuring work Certification Center.

3.2. Accession to the Regulations

3.2.1. The certification center registers individuals and authorized representatives of legal entities only if the specified person has entered into a public offer agreement for the provision of services of the certification center "LISSY-Soft".

3.2.2. Registration of CA users means entering registration information about CA users in the register of the Registration Center of the Certification Center.

3.3. Changes to the Regulations

3.3.1. Changes (additions) to the Regulations, including annexes to it, are made Certification Centerunilaterally.

3.3.2. Notification of changes (additions) to the Regulations is carried out Certification Centerby obligatory posting of the specified changes (additions) on the website Certification Center by the address -
http: // ca. soft. ***** with the obligatory introduction of the revision number and the date of changes.

3.3.3. All changes (additions) made Certification Center to the Regulations on its own initiative and not related to changes in the current legislation of the Russian Federation enter into force and become binding after two months from the date of posting these changes and additions to the Regulations on the website Certification Center at the address - http: // ca. soft. *****

3.3.4. All changes (additions) made Certification Center in the Regulations in connection with a change in the current legislation of the Russian Federation come into force simultaneously with the entry into force of the amendments (additions) to these acts.

3.3.5. Any changes and additions to the Regulations from the moment of entry into force equally apply to all persons who have joined the Public Offer Agreement for the provision of services Certification center, including those who acceded to the Agreement earlier than the date of entry into force of the changes (additions). In case of disagreement with the changes (additions), the Party to the Agreement has the right, prior to the entry into force of such changes (additions), to terminate the Public Offer Agreement in the manner provided for in clause 11 of the Public Offer Agreement.

3.3.6. All appendices, changes and additions to these Regulations are its integral and integral part.

3.4. Services provided by the Certification Center

In the course of its activity Verification Center provides consumers (CA users) with the following types of services:

Entry into the register Certification Center user registration information Certification Center(hereinafter - CA users).

· Production of certificates of keys for verifying the electronic signature of CA users in electronic form and copies of certificates of keys for verifying the electronic signature of CA users on paper.

· Maintaining a register of produced certificates of keys for checking the electronic signature of CA users.

· Provision of copies of certificates of electronic signature verification keys in electronic form, which are in the register of produced certificates of electronic signature verification keys, at the request of CA users.

· Cancellation (revocation) of certificates of keys for verification of electronic signatures upon requests from owners.

· Suspension and renewal of validity of certificates of keys for verification of electronic signatures upon requests of owners.

· Providing CA users with information about revoked and suspended certificates of electronic signature verification keys.

· Confirmation of the authenticity of electronic signatures in electronic documents upon requests from CA users.

Confirmation of the authenticity of the electronic signatures of the authorized person Certification Center in the certificates of electronic signature verification keys produced by him at the request of the CA users.

4. Rights and obligations of the parties

4.1. Verification Center has the right to:

4.1.1. Refuse to revoke (revoke) the certificate of the key for verifying the electronic signature of the CA user if the established period of validity of the electronic signature key corresponding to this certificate has expired.

4.1.2. Refuse to suspend the validity of the certificate of the electronic signature verification key of the CA user if the established validity period of the electronic signature key corresponding to this certificate has expired.

4.1.3. Refuse to renew the validity of the certificate of the electronic signature verification key of the CA user in the event that the established validity period of the electronic signature key corresponding to this certificate has expired.

4.1.4. Revoke (revoke) the certificate of the key for verifying the electronic signature of the CA user in the event of an established fact of compromise of the corresponding electronic signature key, notifying the owner of the revoked (revoked) certificate and indicating justified reasons.

4.1.5. Suspend the validity of the certificate of the verification key for the electronic signature of the CA user, notifying the owner of the certificate, whose validity is suspended, and indicating justified reasons

4.1.6. Refuse to produce the certificate of the key for verifying the electronic signature of the CA user if the cryptographic information protection tool used by the CA user to generate a request for the certificate of the electronic signature verification key is not supported Certification Center.

4.2. User Certification Center has the right to:

4.2.1. Retrieve a list of revoked electronic signature verification keys issued by Certification Center.

4.2.2. Obtain a key certificate for verification of an authorized person's electronic signature Certification Center.

4.2.3. Apply a key certificate for verifying the electronic signature of an authorized person Certification Center to verify the electronic signature of an authorized person Certification Center in certificates of keys for verification of electronic signatures produced by the Certification Center.

4.2.4. Apply the user's digital signature verification key certificate Certification Center for verification of the electronic signature of electronic documents in accordance with the information specified in the certificate of the electronic signature verification key.

4.2.5. Apply a certificate revocation list for electronic signature verification keys produced by Certification Center, to check the status of certificates of keys for verification of electronic signature.

4.2.6. Contact Verification Center for confirmation of the authenticity of electronic signatures in electronic documents.

4.2.7. Contact Verification Center for confirmation of the authenticity of the electronic signature of the authorized person Certification Center in the certificates of electronic signature verification keys produced by him.

4.2.8. To store the electronic signature key, use a medium supported by the cryptographic information protection tool used certified in accordance with the certification rules of the Russian Federation and complying with the requirements of the legislation, regulatory legal documents of the Russian Federation.

4.2.9. Use the provided Certification Center software for transmission over communication lines in Verification Center a request for the issue of a certificate of an electronic signature verification key in electronic form.

4.2.10. Contact Verification Center to revoke (revoke) the certificate of the electronic signature verification key during the validity period of the corresponding electronic signature key.

4.2.11. Contact Verification Center to suspend the validity of the certificate of the electronic signature verification key during the validity period of the corresponding electronic signature key.

4.2.12. Contact Verification Center to renew the validity of the certificate of the electronic signature verification key during the validity period of the corresponding electronic signature key and the period for which the validity of the certificate was suspended.

4.3. Duties Certification Center

4.3.1. Verification Center is obliged to use for the production of the electronic signature key of the authorized person Certification Center and the formation of an electronic signature only means of cryptographic protection of information certified in accordance with the certification rules of the Russian Federation.

4.3.2. Verification Center is obliged to use an authorized person's electronic signature key Certification Center only for signing the certificates issued by it for verification of the electronic signature of CA users and certificate revocation lists.

4.3.3. Verification Center is obliged to take measures to protect the electronic signature key of the authorized person Certification Center from unauthorized access.

4.3.4. Verification Center is obliged to organize his work according to GMT (Greenwich Mean Time), taking into account the time zone of the city of Moscow. Verification Center is obliged to synchronize in time all its software and technical means of ensuring activities.

4.3.5. Verification Center is obliged to ensure the registration of CA users in accordance with the registration procedure set out in these Regulations. Verification Center is obliged to ensure the uniqueness of the registration information of users Certification Center, used to identify owners of certificates for electronic signature verification keys.

4.3.6. Verification Center is obliged to ensure the production of a certificate of the key for verifying the electronic signature of the registered user of the CA in accordance with the procedure specified in these Regulations.

4.3.7. The Certification Center is obliged:

· Ensure the uniqueness of the serial numbers of the produced certificates of keys for verifying the digital signature of the CA users;

· Ensure the uniqueness of the values \u200b\u200bof the keys for verifying the electronic signature in the issued certificates of the CA users;

4.3.8. Verification Center is obliged to cancel (revoke) the certificate of the electronic signature verification key at the request of the user Certification Center to cancel (revoke) the certificate of the electronic signature verification key no later than the business day following the business day during which the application was submitted, enter information about the revoked (revoked) certificate in the list of revoked certificates indicating the date and time of entry and the reason for revocation.

4.3.9. Verification Center is obliged to suspend the validity of the certificate of the electronic signature verification key at the request of the CA user to suspend the validity of the certificate of the electronic signature verification key no later than the working day following the working day during which the application was submitted, enter information about the suspended certificate in the list of revoked certificates indicating the date and time entry and sign of suspension.

4.3.10. Verification Center is obliged to renew the validity of the certificate of the electronic signature verification key at the request of the CA user to renew the validity of the certificate of the electronic signature verification key (in case of receipt of the application during the period for which the certificate was suspended) and no later than the business day following the business day during which an application has been submitted to exclude information about the certificate whose validity has been suspended from the list of revoked certificates.

4.3.11. Verification Center is obliged to revoke (revoke) the certificate of the electronic signature verification key if the established period for which the validity of this certificate has been suspended has expired.

4.3.12. The Certification Center is obliged to keep the register of the Certification Center.

4.4. Obligations of the user Certification Center

4.4.1. The CA user is obliged to keep the electronic signature key secret, take all possible measures to prevent its loss, disclosure, distortion and unauthorized use.

4.4.2. The CA user is obliged not to use the electronic signature key if the user becomes aware that this key is being used or was previously used by other persons.

4.4.3. The CA user is obliged to use the electronic signature key only in accordance with the scopes specified in the certificate of the electronic signature verification key corresponding to this key.

4.4.4. The CA user is obliged to immediately contact Verification Center with an application for cancellation (revocation) of the certificate of the electronic signature verification key in case of loss, disclosure, distortion of the electronic signature key, as well as if the user becomes aware that this key is used or was previously used by other persons.

4.4.5. The CA user is obliged not to use the electronic signature key associated with the certificate of the electronic signature verification key, the application for cancellation (revocation) of which was submitted to Verification Center, during the time calculated from the time of filing the application for cancellation (revocation) of the certificate to the time of the official notification of the user about the cancellation (revocation) of the certificate.

4.4.6. The CA user is obliged not to use the electronic signature key associated with the certificate of the electronic signature verification key, the application for the suspension of which is submitted in Verification Center, during the time calculated from the time of filing an application for suspension of the certificate to the time of the official notification of the user about the suspension of the certificate.

4.4.7. The CA user is obliged not to use the electronic signature key associated with the certificate of the electronic signature verification key, which has been canceled (revoked) or suspended.

4.4.8. The CA user is obliged to regularly, at least once every 10 days, view the Internet page Certification Centerlocated at http: // ca. soft. ***** for changes in the Regulations.

5. Rules for using the services of the Certification Center

5.1. User registration

Verification Center carries out registration of individuals and authorized representatives of legal entities only if the specified person has joined the Public Offer Agreement in accordance with clause 3.2 of these Regulations.

User registration in Certification Center and the production of the first certificate of the electronic signature verification key is carried out on the basis of an application for registration upon the personal arrival of the user undergoing the registration procedure, or his authorized representative at the office Certification Center or to the Agent's office.

The application form for registration is given in Appendices No. 2.1, 2.2 to these Regulations. The user who is an authorized representative of the Party that acceded to the Regulations (if the Party to the Regulations is a legal entity) must provide a power of attorney issued in his name in the form of Appendix No. 3.1 of these Regulations.

User registration in Certification Center can be carried out by an authorized representative of the CA user, acting on the basis of a power of attorney for registration in Certification Center... Power of attorney for registration in Certification Center should be drawn up in the form of Appendices No. 4.1, 4.2 of these Regulations.

Responsible officer Certification Center carries out the procedure for identifying the person undergoing the registration procedure by identifying the person with the passport. After positive identification of the person undergoing the registration procedure, the responsible officer Certification Center accepts documents, reviews them and makes decisions on them.

In case of refusal to register, the user is notified of this, indicating the reason for rejection of the application.

When making a positive decision, the responsible employee Certification Center performs registration actions to enter registration information into the register Certification Center, produces a key certificate for verification of an electronic signature.

5.2. Production and receipt of the certificate of the electronic signature verification key

The formation of the certificate of the key for verifying the user's electronic signature is carried out Certification Center on the basis of a request for the production of a certificate of the electronic signature verification key. A request for the production of a user certificate is submitted electronically using the CA user's software.

Processing of a request for a certificate of an electronic signature verification key must be carried out no later than the working day following the working day during which the request was accepted Certification Center.

If it is impossible to generate a request for the production of an electronic signature verification key certificate in electronic form, the production of CA users' certificates is carried out on the basis of a user application containing the information necessary to identify the owner of the electronic signature verification key certificate. An application for the production of a certificate of the electronic signature verification key in paper form is submitted to Verification Center upon personal arrival of the user at the office Certification Center or to the Agent's office.

The application form for the production of a certificate of the electronic signature verification key is given in Appendices No. 5.1, 5.2 to these Regulations.

5.3. Cancellation (revocation) of the certificate of the key for verifying the electronic signature of the CA User

Cancellation (revocation) of the electronic signature verification key certificate is carried out at the request of its owner submitted to the Certification Center, or at the request of the Party that has acceded to the Public Offer Agreement (if the Party to the Agreement is a legal entity) to revoke the power of attorney of the representative of the Party to the Agreement registered in the Certification Center.

To cancel (revoke) the certificate of the electronic signature verification key, the user submits an application to Verification Center in paper or electronic form for cancellation (revocation) of the certificate.

The paper application form for cancellation (revocation) of the certificate of the electronic signature verification key is given in Appendix No. 7.1, 7.2 to these Regulations.

A party that has acceded to the Regulation, which is a legal entity, has the right to cancel (revoke) certificates of keys for verifying the electronic signature of its authorized representatives registered in the Certification Center . Cancellation (revocation) of certificates of keys for verifying the electronic signature of CA Users who are authorized representatives of a Party that acceded to the Regulations is carried out by revoking the power of attorney, on the basis of which the Certification Center services were provided to the CA User. The application form for revoking the power of attorney is given in Appendix No. 11 to these Regulations.

An application for cancellation (revocation) of the electronic signature verification key certificate in electronic form is generated and submitted to Verification Center using the CA user's software and is an electronic document in PKCS # 7 format. A request to revoke a certificate is used as the data being signed, and the electronic signature is carried out on the current key of the user's electronic signature.

The application is accepted and considered only during the working day of the Certification Center.

The processing of an application for cancellation (revocation) of the certificate of the electronic signature verification key and the official notification of the CA User about the cancellation (revocation) of the certificate of the electronic signature verification key must be carried out no later than the business day following the business day during which the application was accepted by the Certification Center.

The official notification of the fact of cancellation (revocation) of the certificate of the electronic signature verification key is the publication of the list of revoked certificates containing information about the revoked (revoked) certificate. The time of revocation (revocation) of the electronic signature verification key certificate is the time of publication of the list of revoked certificates containing information about the revoked (revoked) certificate indicated in the thisUpdate field of the issued list of revoked certificates.

Information about the location of the list of revoked certificates is recorded in the signature key certificates issued by the Certification Authority in the CRL Distribution Point field.

5.4. Suspending / renewing the validity of the electronic signature verification key certificate

5.4.1. Suspension of validity of the electronic signature verification key certificate

To suspend the validity of the electronic signature verification key certificate, the user submits an application to Verification Center in paper or electronic form to suspend the certificate.

The paper application form for suspension of the electronic signature verification key certificate is given in Appendix No. 8.1, 8.2 to these Regulations.

An application for suspension of the validity of the electronic signature verification key certificate in electronic form is generated and submitted to Verification Center using the CA user's software and is an electronic document in PKCS # 7 format. As the data to be signed, a request to suspend the certificate is used, and the electronic signature is carried out on the current user's electronic signature key.

The validity of the certificate is suspended for a period calculated in calendar days. The minimum period for suspension of a certificate is 10 days.

Submission of an application for the suspension of the certificate issued in paper form in Verification Center and its consideration is carried out only during the working day.

The processing of the application for the suspension of the certificate and the notification of the user about the suspension of the certificate must be carried out no later than the working day following the working day during which the application was submitted to Verification Center.

The time of suspension of the certificate of the electronic signature verification key is the time of the official notification of the user about the suspension of the validity of this certificate.

The time of signing the electronic document, on the basis of which the suspension of the certificate of the user's electronic signature verification key was carried out, is the time when the document was entered into the register Certification Center.

If during the period of suspension of the validity of the key certificate of the user's electronic signature verification in Verification Center no application is received from the CA user to renew the certificate, the certificate is canceled (revoked) Certification Center.

5.4.2. Renewal of the electronic signature verification key certificate

To renew the validity of the certificate of the electronic signature verification key, the user submits an application to Verification Center in paper or electronic form for the renewal of the certificate.

The paper application form for renewal of the certificate of the electronic signature verification key is given in Appendix No. 9.1, 9.2 to these Regulations.

An application for the renewal of the certificate of the electronic signature verification key in electronic form is generated and submitted to Verification Center using the CA user's software and is an electronic document in PKCS # 7 format. As the data to be signed, a request for the renewal of the certificate is used, and the electronic signature is carried out on the current key of the user's electronic signature.

System requirements

• Internet access
• Operating system: Windows 8, 7, XP SP 3/2
• Processor: 1.6 GHz or higher
• RAM: 512 MB
• One of the supported crypto providers: CryptoPro CSP 3.6 or higher, LISSI CSP, VIPNet CSP, Signal-COM CSP
• Screen resolution: at least 800x600 px

Use a certified crypto provider

For the Ekey.Signature program to work, the presence of a cryptographic information protection tool (CIPF) at the workplace that encrypts documents according to GOST algorithms is mandatory. CryptoPro CSP systems not lower than 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP can be used as cryptographic protection devices.

Cryptographic protection tools are compatible with Ekei. Signature, but incompatible with each other. Only one CIPF can be installed at one workplace.

Use antivirus

Install a popular antivirus in your workplace and update it regularly. Antivirus protects against viruses, spyware and eliminates most security threats on its own.

Protect access to electronic signature and workplace with a password

By using Ekei.Signature and cryptographic protections, protect your computer from physical access by unauthorized persons. Use password access.

To access the electronic signature, use a complex password. A good password guarantees the security of your data. A good way to remember your password is to keep typing it when performing digital signature operations.

A great place to store your password is in your memory. It is not advisable to write down the password anywhere. Do not store the password next to the physical carrier of the electronic signature, do not store the password in the system.

Use only licensed and current programs

The programs installed at your workplace are periodically updated to improve the stability and safety of your work.

Install software updates only from official sites, check site addresses and information about the program publisher before installing.

Installing Ekei Signature

1. Download

2. To start installing the program, run the installation file. If you start UAC, you need to allow changes to the Ekey transfer program.

Preparing files for Rosreestr

1. Select the type of operation "Rosreestr" in the main program window or in the context menu of the file.

3. Add a report using the "Attach file (s)" button or drag and drop the file using the mouse.
4. Click the Generate button.
6. After the operation is completed, the signature file will be saved in the same directory as the original file, the detached signature file is valid only if the original file is present.

Preparation of a container for the FFMS of Russia, the Bank of Russia Service, the Central Bank

1. Select the type of operation "FFMS of Russia".

2. Select a personal certificate.

3. Add a report with the xtdd or smcl extension using the "Attach file (s)" button or drag and drop the file using the mouse.

5. If necessary, enter the password for the private key container

7. To add a co-signature, attach the previously generated container, select the required certificate and click the Generate button.

8. To send reports to the portal of the Bank of Russia Service (FFMS), click the add button, in the menu that appears, select the required container with the report and click the upload to the portal button.

FSIS TP Ministry of Regional Development of Russia

1. Select the type of operation "FSIS TP".

2. Select a personal certificate.

3. Add a report using the "Attach file (s)" button or drag and drop the file using the mouse.

4. Click the Generate button.

5. If necessary, enter the password for the private key container

6. In the save menu that appears, select the location to save the operation result.

Roskomnadzor register (zapret-info.gov.ru)

1. Select the operation Roskomnadzor register

2. Select a personal certificate

3. To find out the time of the last update of the registry, click "Time of the last update of unloading from the registry"

4. To send a request, click "send request"

Fill in the fields to generate a request.

5. To get the result of request processing, click "Request for result"

For automatic unloading of the registry, you must check the "Unload automatically" checkbox, set the required unloading period and specify the directory to save the unloading results.

ISED

1. Select the type of operation "ISED".

2. Add a report using the "Attach file (s)" button or drag and drop the file using the mouse.

3. Select recipient certificates

4. Click the Generate button.

5. In the save menu that appears, select the location to save the operation result.

Signing files

1. Select the operation type "Sign manually".

2. Select a personal certificate.

4. Select the required signature options.

5. Click the "Sign" button.

6. If necessary, enter the password for the private key container

Explanations:

Save signature in a separate file

When the flag is set, a detached electronic signature will be created If the flag is absent, the signature will be added to the end of the file (in this case, the document and the electronic signature will be stored together)

Archive files

Do I need to archive files after signing

Expansion - The default signature file extension is sig, you can also specify your extension

Encoding - Choose the Der or Base-64 encoding you need

Disable service headers- When Base-64 encoding is selected (Headers are used for compatibility with third party software).

File encryption

1. Select the operation type "Encrypt manually".

2. Select a personal certificate.

3. Add the file using the "Attach file (s)" button or drag and drop the file using the mouse.

4. Select the required encryption options.

5. Add or select from the existing recipient certificates (to whom the file will be encrypted)

6. Click the "Encrypt" button.

7. If necessary, enter the password for the private key container

8. In the save menu that appears, select the location to save the operation result. Explanations:

Encoding

Choose the Der or Base-64 encoding you need

Expansion

The extension that the final file will have (by default enc), you can also specify your extension. Disable service headers - If Base-64 encoding is selected (required for compatibility with third-party software).

Archive files before encryption

If you need to archive files before encryption, check the corresponding section.

In case of adding multiple files, all files will be packed into one archive.

Decrypting files

1. Select the operation type "Decrypt".

2. Select a personal certificate.

3. Add the file using the "Attach file (s)" button or drag and drop the file using the mouse.

4. Click the "Decrypt" button.

5. If necessary, enter the password for the private key container

6. In the save menu that appears, select the location to save the operation result.

Signature verification

1. To start verification of the signature, use a verification method convenient for you.

• By double clicking on the file containing the signature.
• Select the type of operation "Check signature" in the main menu of the program.
• Through the context menu of the file to be checked.

2. Add the file using the "Attach file (s)" button or drag and drop the file using the mouse.

3. Click the "Check" button.

After clicking the "Check" button, a window appears with the result of signature verification. In it, you can view the signature tree, print the verification result and open the source file for viewing.

Also, during the scan, you can view the contents of files with the extension: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Explanations:

Unsign files

If an attached signature was created, then using this option, you can get the original file that does not contain any signatures.

Add signature

1. Select the type of operation "Add signature".

2. Select a personal certificate.

4. Click the "Sign" button.

5. If necessary, enter the password for the private key container

6. In the save menu that appears, select the location to save the operation result.

Verify signature

1. Select the type of operation "Verify signature".

2. Select a personal certificate.

3. Add the signature file using the "Attach file (s)" button or drag the file using the mouse.

4. Click the "Verify" button.

5. If necessary, enter the password for the private key container

6. In the menu that appears, select the signature you want to certify

7. In the save menu that appears, select the location to save the operation result.

Automatic update

When an update becomes available, a corresponding inscription appears in the upper right corner of the running Ekey Signature application. To initiate the update, left-click on it.

After the update process is complete, click "OK" in the message that some changes will take effect only after a reboot. Click the Finish button. Then it is recommended to restart the computer. A reboot is first of all required for the updates related to the work of the Windows context menu to take effect.

Automatic installation of root certificates

If there is no root certificate in the store, when the Ekey Signature application is launched, a corresponding error is displayed in the user log. In this case, sign a file with the "problematic" personal certificate. When performing the signing operation, a dialog box will be displayed with a proposal to install the missing root certificate. To install the missing root certificate, click "Yes".

Credit