Electronic signature (hereinafter referred to as ES), according to the Federal Law of the Russian Federation No. 63-FZ of March 25, 2011 "On Electronic Signature", is defined as information in electronic form, which is attached to other information in electronic form (signed information) or otherwise associated with such information and which is used to identify the signer of the information. The specified normative act replaced the Federal Law of the Russian Federation No. 1-FZ dated January 10, 2002 "On Electronic Digital Signature", which had lost its legal force on July 1, 2013.
The law of March 25, 2011 distinguishes two types of electronic signature: simple and enhanced. The latter can be qualified or unskilled. If a simple ES only confirms that a given electronic message was sent by a specific person, then a strengthened unqualified ES allows not only to unambiguously identify the sender, but also to confirm that no one has changed it since the document was signed. In what follows, we will talk about reinforced unqualified ES. A message with an unqualified electronic signature can be equated to a paper document signed with one's own hand, if the parties have agreed on this in advance, as well as in cases specially provided for by law.
On the one hand, ES is used to confirm the authorship of the document - this is its meaning for the sender of the document. On the other hand, an electronic signature, if recognized as legally significant, ensures that the author does not repudiate the signed document, which in turn is important for the recipient of the document. In the event of a disputable situation, an analysis of conflicts can always be carried out, which will unambiguously determine the author of the signed document and make him responsible for the signed document.
Analysis of conflicts related to electronic signature
The main problem in the analysis of conflicts in sports situations based on documents signed by the electronic signature is the proof of the fact that "information in electronic form, which is attached to other information in electronic form (signed information)" is a legally significant electronic signature of a specific person under a specific document.
The use of cryptographic methods allows us to solve this problem. If a person is given a unique electronic key and then special transformations are made using this electronic key and an electronic document, then the result of these transformations (and this is the electronic signature) will be unique for this pair (key-document). Thus, the task of the first stage in the analysis of conflicts - to reveal whether a given signature was generated using a given electronic key or not - is solved by cryptographic methods.
The second stage in the analysis of conflicts is to prove that this electronic key is the property of a specific person. This proof gives the ES legal significance. To solve this organizational problem - accounting for issued keys - PKI (Public Key Infrastructure) is used.
Giving ES legal value using PKI
The law "On Electronic Signatures" distinguishes between an ES key and an ES verification key. An electronic signature key is a unique sequence of characters used to create an electronic signature. An electronic signature verification key is a unique sequence of characters that is uniquely associated with an electronic signature key and is used to verify the authenticity of an electronic signature. The ES key is derived from the ES key, but the reverse operation is impossible. Thus, there is a one-to-one correspondence between the ES key and the ES verification key. The ES key must be created by the client himself and kept secret. It is this key that is used to sign documents with an electronic signature. The ES verification key is used to verify the ES and is distributed to everyone who wants to verify the signature.
The main element of PKI is the Certificate Authority. The Certification Center maintains a register of correspondence between keys and persons who own these keys. To register the key, the client takes the public part of his key to the CA along with his identification data and receives a certificate of conformity confirming his ownership of this particular key. The Certificate of Conformity contains the ES verification key and the client's identification data, and is signed by the ES of the Certification Authority. Thus, the CA certifies that the client has been verified and is who it claims to be. Upon receipt of the certificate, the client, in turn, signs special documents on the validity of the issued certificate with his hand signature. These documents are the main link between a specific person and the "set of electronic symbols", his electronic signature.
Thus, the signer's certificate is sufficient to verify the signature and identify the signer. That is, the signer signs the document with his ES key, and then sends to the recipient this signed document and his certificate containing the ES verification key. Thus, the recipient will be able to verify that the signature was actually made with the signer's ES key and will receive the signer's identification data from the certificate. The client must protect his ES key from compromise. It is for this purpose that various hardware key storages with an increased level of protection are created, for example, a ruToken USB device.
Russian standard EP
EDS standards are two-tier. At the first level, the electronic signature is located directly from the document. The second level contains the ES and all the documents required to give the ES legal significance: the signer's certificate or a chain of certificates, the time of signature creation, etc.
The Russian standard for electronic code of the first level is GOST 34-10.2012. The Russian standard for ES of the second level is PKCS # 7 with the ability to add TSA timestamps.
Spheres of application of EP
- Internet bank
- electronic marketplace
- corporate document management systems
- submission of reports to various federal services
- Copyright
WEB-site with electronic signature
Formulation of the problem
Suppose your organization has made a decision to switch to a web-based electronic document management system. At the same time, the main places where ES is required are:
- ES files of arbitrary format when they are uploaded to the website by the user through the input form
- ES of the text data entered by the user into the input form on the website
- Electronic signature of the document posted on the website by several users
- cryptographic protection of data transmission between the user's workplace and the website
- user authentication using a digital certificate to access his personal account
- cryptographic protection of information stored on the server
Solution scheme
Creation of a certification center
select a server on which the Certification Authority will be deployed. Optionally, timestamping and online certificate status checking services can be deployed. In order to save money, the CA and the specified services can use one server, which must be available online. We will discuss the feasibility of these services below.
install the MagPro CryptoPacket product on the server
create a CA key and an application for a CA root certificate using the mkkey utility from MagPro CryptoPacket. The key can be created on a secure device, for example, on a ruToken. After the CA key is created, it is required to ensure its security by organizational methods. The safest option is to store the key on the ruToken device and connect it to the server only when issuing certificates. The CA certificate is a file. This file will subsequently be issued to all CA clients when they receive a certificate.
create a root CA certificate using the openssl utility from MagPro CryptoPacket.
create a directory structure in the file system in which issued user certificates, issued server certificates, and certificate applications will be stored in the form of files. Organizational methods (such as using ACLs) should provide the correct permissions for these directories. Certificates will be issued as PEM files. Keep in mind that the names of the certificate files are best kept clear to make it easier to find the certificates later.
PKCS # 10 Certificate Key Generation and Enrollment
To obtain a certificate by a CA user, two schemes can be used: centralized and remote. With a centralized scheme, the user comes to the CA and he is given a file containing the key and certificate. Then he adds this file to a USB flash drive. This scheme is simple and convenient, but unsafe, as it allows the CA employees to find out the user key. But in some cases, the use of this scheme is justified.
The most secure scheme for obtaining a certificate is distributed. The user creates a key, creates a PKCS # 10 certificate request, which contains his ES verification key and identification data. The user signs this application with his ES key and takes it to the CA. The CA verifies the signature on the application, verifies the user's identification data, for example, with passport data, and issues a certificate. Then the certificate is printed out and the user manually signs the document confirming the compliance of the issued certificate.
As part of the solution under discussion, keys are generated and an order is created using a special program from the MagPro CryptoPacket. This program is included in the CryptoTunnel user kit.
This program has a flexible configuration system, with which you can create applications for completely different types of certificates, expand the standard set of identification information, add roles and user rights to certificates, for example, to delimit access to web resources; add various attributes to the application.
After creating the key, the user must ensure that it is stored securely.
Types of certificates for electronic signature on the WEB-site
Several types of certificates will be used in our portal:
root CA certificate
This certificate is used to validate all other certificates for members of the Web portal.
TLS Server Authentication Certificate
This certificate is used to verify the server by the client when creating a secure TLS connection when transferring signed documents to a website
TLS client authentication certificate
This certificate is used to verify the client by the server and for the client to access his personal account when creating a secure TLS connection when transferring signed documents to the website
client's ES certificate
The client adds this certificate to his electronic signature, and thus, the verifying party can verify the signature and identify the signer
OCSP server signing certificate
With this certificate, the OCSP server adds to its signed response to verify it
TSA server signing certificate
With this, the TSA server adds a certificate to its signed response to verify it and give it legal significance.
All these types of certificates can be created using a utility from MagPro CryptoPacket and CA based on MagPro CryptoPacket.
Obtaining a certificate at the CA
Upon receipt of an application from a user, the CA administrator creates a backup copy of his application. Then it checks the application and, using the openssl utility, creates a user certificate, signs it on the CA key and also ensures its backup. In addition, to ensure legal significance, the administrator prints out information from the certificate (this information is obtained using the openssl.exe utility) and receives a manual user signature under this printout. Then it issues the user his certificate in a file.
So, at the moment, we were able to deploy the CA and learned how to create user keys, accept applications for certificates from them and issue certificates upon received applications. The user confirms the receipt and compliance of the certificate with his manual signature, and therefore it can be argued that we have deployed PKI, which ensures the legal significance of the user's electronic signature
The next task is to use the deployed PKI for solving an applied problem - organizing the secure transfer of signed electronic documents to a Web site using a browser and receiving them for processing on a Web site.
Electronic signature verification and storage module (server)
Typically, a website is deployed on some kind of web server (Apache, IIS, nginx, etc.). This site contains a personal account for each user who is registered on the site. To access the personal account, the user must go through the authentication procedure. Typically, authentication consists of entering the login and password agreed upon during user registration.
In addition, a web input form is used to upload electronic documents to the server.
In order to "tie" the verification of the electronic signature of documents uploaded to the site to this system, to ensure the protection of connections between the user's browser and the site, as well as to ensure strict cryptographic authentication of the user for access to the personal account, the MagPro CryptoServer product should be installed on the server.
The architectural solution will look like this:
CryptoServer is installed in front of the protected Web server. In this case, the Web server is configured in such a way that it accepts incoming connections only from the CryptoServer (see the setup instructions). The CryptoServer accepts incoming HTTS connections, decrypts them and forwards them to the Web server. In addition, the CryptoServer adds the X509-Cert header to the HTTP request, in which it transmits the digital certificate of the client that has passed the authentication procedure. This certificate is then used to access the client to his personal account. To check the electronic signature under the transferred documents, the CryptoServer includes the openssl utility, which allows you to check different types of signatures, get a signer's certificate or a chain of certificates from a PKCS # 7 envelope, etc. To check the electronic signature, the web page for receiving documents must call this utility.
Electronic signature generation module (client)
The main task of the user when accessing the website is to upload electronic documents and text data to the website, as well as download electronic documents from the website. To secure a web connection with a website using the SSL / TLS protocol and for online signing of data transmitted to the website, CryptoTunnel should be used at the client's workstation.
The main advantages of the CryptoTunnel:
- provides protection of web connections between any browser and a website using the SSL / TLS protocol with support for Russian cryptoalgorithms
- allows you to authenticate a user using a digital certificate to access the user's personal account
- allows you to sign documents online when they are uploaded to the site without using CSP and Active X
- Supports Online Certificate Status Checker (OCSP)
- supports obtaining trusted timestamps under the digital signature (TimeStamp)
- Supports various USB Tokens and smart cards for storing keys
- does not require installation on custom locations, distributed by copying
- can be stored on a regular flash drive and run from it
- does not require system administrator rights to work
- supports work with any web browser (Internet Explorer, Mozilla FireFox, Google Chrome, Opera, Apple Safari, etc.)
- does not have a "binding" to one computer - the user can use one set for use in the office and at home - saving money
- has a simple and straightforward user interface that eliminates the need for user training
- allows you to minimize the cost of technical support for users
- can run on a wide range of operating systems (cross-platform solution)
These are ALL the actions that need to be performed in order for CryptoTunnel to start signing data and files transmitted through the Web form. No need to write any additional scripts, call Active X, etc.
Organization of multiple electronic signatures
Multiple ES is required if the document must be signed by several persons. In this case, the document is usually posted on the site in such a way that it is available only to users whose electronic signature is required. This sharing of access is ensured by authenticating users with a digital certificate.
When using the CryptoTunnel, the user does not have to download the document, and then sign and upload the document to the server again - the CryptoTunnel will do all these operations automatically when he clicks on the button on the web page.
OCSP Service
It often happens that the CA revokes a user's certificate (for example, if the user's key was stolen by an intruder). At the same time, other users should be notified about the revocation of this certificate, so that they stop trusting it. There are several ways to notify users of a review.
The simplest method is to distribute revocation lists (CRLs). That is, the CA creates and periodically updates a special file that users also periodically download.
Another way is to use the online certificate status checker service, the OCSP service. To check the status of any certificate, CryptoTunnel and CryptoServer automatically form an OCSP request, send this request to the service over the network. The service verifies the certificate, signs the verification result with its ES and returns a response to the client. The client looks at the answer, checks the signature under it and decides whether to trust this certificate or not.
The OCSP service can be created using the openssl utility from MagPro CryptoPacket. Please note that the choice between CRL and OCSP is always at the discretion of the site builders. CRL is slightly cheaper, OCSP is slightly safer.
It should be discarded that CryptoTunnel and CryptoServer support both OCSP and CRL.
TSA Timestamp Service
The main purpose of the time stamp service is to confirm the fact that the document was signed with electronic signature no later than the time specified in the time stamp.
To create a timestamp, CryptoTunnel creates a TSA request, to which it attaches a hash from the digital signature; sends this request to the TSA service. The TSA service adds the current time to this hash and signs the result with its ES. This creates a trusted timestamp.
To create an online service of trusted time stamps, use the MagPro TSA product. In this case, the URL of the timestamp service is specified by the web page that contains the web signature form
The TSA client side is built into the CryptoTunnel. Upon receipt of a timestamp on the electronic signature, all actions are performed automatically, without involving the user.
Arbitrator
The arbiter is a special program that is used in the analysis of conflicts by electronic signature.
The arbiter allows you to visualize the identity of the certificate that is in the PKCS # 7 signature; visualize the chain of trust and the creation time of the digital signature (TimeStamp). To analyze the conflict, the Arbitrator checks the signature under the specified document and finds out whether it was made by the owner of the certificate.
It should be noted that for the very possibility of resolving conflicts, documents and their signatures must be stored in an electronic archive for a long time.
Protection of personal data on the WEB-site
The data exchanged between the client's browser and the site may contain personal data and confidential information. If all users of the site are interested in protecting confidential information, then the protection of personal data is a requirement of the Federal Law 152-FZ "On Personal Data".
When using the site, data is at risk when it is transmitted over the Internet and when it is subsequently stored on the site's server.
Transfer protection between client and server
The Internet is an insecure transmission channel. The main threat when transmitting data over the Internet is the "man in the middle" attack, that is, an attacker connects to the line between the client and the server and replaces the transmitted information. The only way to protect data on the Internet is to encrypt that data. Since encryption is a cryptographic method of protecting information, it is subject to the requirements of the FSB for the means of cryptographic protection of information - the presence of an FSB certificate.
SSL / TLS is used to encrypt communications between the user's browser and the website (Web connections). CryptoTunnel provides data protection for this protocol that fully complies with the requirements of the FSB. Thus, "CryptoTunnel" is a certified solution that fully meets the requirements for technical means of protecting personal data.
Storage protection
When storing data in the electronic archive of the site, these data must be stored in encrypted form. The creation of a secure electronic archive is a topic for a separate article.
1. The process of signing a document. Electronic signature verification algorithm
The process of signing a document is as follows. At the first step, a special function (hash function) is built that resembles a checksum; it identifies the contents of the document (a "digest" of the document is created). In the second step, the author of the document encrypts the contents of the hash function with his personal private key. The encrypted hash function is placed in the same message as the document itself. A digital signature is a derivative of a “digest” and a private private key, which guarantees its absolute uniqueness (see Fig. 14.1).
Rice. 14.1 - Algorithm for EDS formation
The hash function used in the algorithm must satisfy a number of requirements, namely:
Any message of any length must be converted to a binary sequence
fixed length;
The resulting hashed version of the message must depend on each bit of the original message and on their order;
The hashed version of the message cannot be restored by any means.
message.
Electronic signature verification algorithm
The algorithm for verifying an electronic signature is as follows. In the first step, the recipient of the message builds his own version of the hash function of the signed document.
At the second stage, the hash function contained in the message is decrypted using the sender's public key. The third step is to compare the two hash functions. Their coincidence guarantees both the authenticity of the content of the document and its authorship (see Figure 14.2).
Rice. 14.2 - EDS verification
An electronic digital signature, like any other data, can be transferred along with
signed, that is, data protected by it. In addition, the digital signature allows you to make sure that the data was not altered (accidentally or intentionally) during transmission to the addressee.
Encryption and electronic signature can be used successfully together. First, you can sign the document with your private private key, and then encrypt it with the recipient's public key. The signature proves the identity, encryption protects the letter from prying eyes.
2. Authentication
Public key cryptography provides reliable services for distributed identification, authentication, and authorization. Problems of this kind arise in case of any fact of access of the subject (user of the system) to information. In particular, when a client connects to a server in an open channel (Internet). The client and server credentials are present in the corresponding public key certificates issued by a single certification authority, or certification authorities from the same hierarchy. Thus, when the client connects to the server, mutual identification can be performed.
Authentication - checking that a client or a server owns the identifier presented to it - can be implemented on the basis of PKI and corresponding public key certificates.
Authentication is possible in several ways.
1. The server sends to the client an authentication request encrypted with the client's public key obtained from the client's public key certificate. The client decrypts the request with the private private key and returns it to the server, confirming in such a way that it is the owner of the corresponding private key and, therefore, the identity in the certificate belongs to it.
2. The server sends a plaintext authentication request. The client responds to the request by signing it with his own electronic digital signature.
The server verifies the client's EDS using the public key obtained from the client's public key certificate and verifies that the client actually has the corresponding private private key.
The described scheme is called a proof-of-possession protocol, since the sender proves that he owns the private key required for decryption and creation of an electronic digital signature.
3. Session Shared Secret Key Negotiation Public key cryptography also allows two parties to agree on a shared secret session key when exchanging information over insecure communication channels.
The scheme for generating a shared session key is as follows. First, the client and server generate one random number each, which is used as half of their shared secret session key. The client then sends its half of the private key to the server, encrypted with the public key obtained from the server's public key certificate. The server sends its half to the client, encrypted with the public key obtained from the client's public key certificate. Each of the parties decrypts the received message with the missing half of the secret key, and creates a shared secret from these two halves. By executing such a protocol, the parties can use a shared secret key to encrypt subsequent messages.
4. Encryption without first exchanging a symmetric secret key Public key encryption technology can encrypt large amounts of data if the parties exchanging information do not have a shared key. Existing public key encryption algorithms require significantly more computational resources than symmetric algorithms, so they are inconvenient for encrypting large amounts of data. However, it is possible to implement a combined approach using both symmetric encryption and public key encryption.
First, an encryption algorithm with a secret key is selected (GOST 28147-89, DES, etc.), then a random session key is generated, which will be used to encrypt the data. The sender then encrypts this session key using the recipient's public key. It then sends the encrypted key and encrypted data to the recipient. The recipient decrypts the session key with their private private key and uses it to decrypt the data.
Confirmation of EDS trust
Upon receipt of a message signed with EDS, the question of trusting this signature arises (does this EDS really belong to the sender of the message). The integrity of the signature can be verified using the sender's known public key and cryptographic algorithms. However, it is necessary to make sure that the public key used for verification really belongs to the subject whose name is signed the message.
If it is possible to find the sender's public key certificate issued by a CA that is trusted, then a convincing
confirmation that the sender's public key really belongs to the sender. Thus, it is possible to make sure that the public key belongs to this particular sender if a certificate is found that: · has a cryptographically valid signature of its publisher;
Confirms the relationship between the sender's name and the sender's public key;
Issued by a trusted certification authority.
If such a sender's public key certificate was found, then the authenticity of this certificate can be verified using the public key of the certification authority.
However, the question arises of checking the ownership of the public key to this certification authority. You need to find a certificate confirming the authenticity of this certification authority. Thus, in the process of checking the certificate, the progress along the certification path takes place. At the end of the chain of certificates leading from the sender's public key certificate through a number of CAs, there is a certificate issued by the CA that has full trust. Such a certificate is called a trusted root certificate because it forms a root (topmost node) in the public-key-identity hierarchy that is believed to be trusted.
If there is explicit trust in a given trusted root certificate, then there is an implicit trust in all certificates issued by the trusted root certificate and all CAs certified by it.
A set of trusted root certificates that are explicitly trusted is the only information that needs to be obtained in a reliable way. This set of certificates is the basis of the trust system and the rationale for the reliability of the public key infrastructure.
In general, when verifying a certificate, it is necessary to check the following certificate fields:
Certificate type - the certificate is allowed to use in this mode.
· Validity - the certificate is valid at the moment.
Integrity - the digital signature of the CA that issued the certificate is correct.
Legitimacy - the certificate has not been revoked.
· Confidence - the root CA certificate is present in the "trusted
root CAs ".
Prohibitions - CTLs do not prohibit the use of a certificate for this task.
BASIC CONCEPTS
KSKPEP
–Qualified certificate of the electronic signature verification key.
CEP- qualified electronic signature.
Crypto Provider – means of protection of cryptographic protection of information. A program with the help of which the closed part of an electronic signature is generated and which allows you to work with an electronic signature. This checkbox is set automatically.
Exported key – the ability to copy an electronic signature to another medium. If there is no check mark, copying the electronic signature will be impossible.
Paintwork- left mouse button.
PKM- right mouse button.
CRM-AGENT- an application developed by CA specialists to simplify the procedure for generating a key pair, creating a request and writing a certificate.
After visiting the certification center and going through the identity verification procedure, the CA sent a letter to the e-mail you specified in the application, containing a link for generation. If you have not received letters, please contact your manager or the Technical Support of the CA using the contact number from this manual.
Open the link to generate from an email in one of the recommended browsers:Google chrome, Mozilla Firefox, Yandex Browser... If you are already in one of the above browsers, click on the link Paintwork or PKM> "Open link in a new tab". The generation page (Fig. 1) will open in a new window.
When you open the link, an initial warning will appear. Check it out if you use a carrier to store the CEP.Jacarta LT ... Learn more about media inbelow. If you are using a different medium, then click the button "Close".
Fig. 1 - Generation page
Click on the link"Download the application" to start downloading. If nothing happened after clicking, click on the link PKM > "Open link in a new tab"... After downloading the application, start the installation.
It is recommended to disable your antivirus software before downloading the program !
During the installation process « crm - agent » a message asking for access will appear (Fig. 2).
Fig. 2 - Access request
Click the button "Yes".
After finishing the installation of the application, return to the page with the generation. A message about "Granting access" will appear (Fig. 3).
Fig. 3 - Access to the certificate store
Click on "Continue" and, in the window that appears, "Grant access"(Fig. 4).
Fig. 4 - Access to the certificate store 2
If the button did not appear "Continue"
If after installing the application « crm - agent » , the link to download the application has not disappeared, the reason may be that your security system is blocking the connection.
To eliminate the situation, you must:
Disable the antivirus installed on your computer;
Open a new tab in the browser;
Enter the address without spaces into the address bar of the browser - 127.0.0.1:90 - and go (pressEnter on keyboard);
When a browser message appears "Your connection is not secure", add the page to browser exceptions. For instance,Chrome: "Additional" - "Go to the site anyway"... For other browsers, use the corresponding developer instructions.
After the error message appears, return to the page with generation and repeat Point 2 of this manual.
If you do not have any pre-installed encryption providers, after the stage of granting access, links for downloading CryptoPRO will appear (Fig. 5).
It is important: Appendix « crm - agent » detects any encryption providers on the computer, and if you have installed a different CryptoPRO CSP program (for example,VipNET CSP ), contact the technical support specialists of the CA for consultation.
Click on the link "CryptoPRO 4.0" on the generation page or a similar link below to download the CryptoPRO installation file to your computer.
CryptoPro CSP 4.0 - version for OS Win 7/8/10
After the download is complete, openzip-archive using an appropriate archiving program (for example,Win - RAR ). Inside there will be the CryptoPRO installation file itself. Run it and install with default parameters. During the installation process, the following window may appear:
Fig. 5 - Installing CryptoPRO
Skip the window by clicking "Further"... CryptoPRO installation is complete.
Installing a driver for a token
Signatures can be stored in the computer registry, on ordinary flash drives and on specialusb-tokens. The list of tokens, pin codes and links to software are presented in the table below (Table 1).
Table 1 - Drivers for secure media
|
USB media type |
Appearance of USB-media |
Link to download drivers |
PIN |
|
ruToken |
 |