Digital workflow enters our lives with confident steps and if for legal entities this is already a harsh everyday life, then many individuals might not have encountered this yet. But over time, staying on the sidelines is becoming increasingly difficult and you need to adapt to changing conditions, otherwise you can get not very pleasant consequences.



The conclusion of contracts is a common thing. They are enclosed in banks, in hospitals, when buying furniture, paying for training. Read the contract, check the details of the legal entity with which the contract is concluded, make sure that you have a seal and signature - a standard procedure that reduces the risk of fraud. However, the acquired skills of working with paper contracts cannot just go into the digital world due to the specifics of electronic documents.



In this article I want to talk about my experience of acquaintance with Russian electronic signatures (E-signatures), which are used to sign contracts with individuals, including insurance companies, as well as the pitfalls that I stumbled upon.



For me, this story began at the conclusion of an agreement with the insurance company LLC IC Sberbank Insurance. After execution, some facts seemed suspicious to me (a small spoiler: everything turned out to be good) and I began to figure out how to verify that the received document was really issued by an insurance company, and not by some third parties.

Chapter One: ES Testing

All manipulations with a PDF document are given in a clean version of Windows 10, the Russian home edition, as the most likely environment for a simple user. The software suite used in the article is also unprofessional and affordable for everyone.



To start, I opened the document in the Foxit Reader, which I use as the main one:















It looks very, very suspicious - the document is not clear who modified it, the certificate is also not trusted. The system cannot verify the trust chain for this certificate and marks it invalid.



In addition to the name of the organization to which the certificate was issued, the name of the issuing organization, LLC ITK, is also visible. Searching for “ITK Certificate LLC” led me to the Install Root Certificate page of the Certification Authority of ITK LLC . This is the official website of Internet Technologies and Communications LLC, which is one of the certification centers issuing certificates of electronic certificates.



Follow the instructions: we need to follow the link and download from Google Drive (!) RAR archive (!!) “Root Qualified.rar” (which still needs to be found than opened, I had to install 7-zip) and we see 2 certificates there: root and intermediate. The root was issued by the Ministry of Telecommunications and Communications to itself, and the intermediate one was issued by the ministry to ITK LLC. Install them, agree to the addition of the root certificate (out of the corner of my eye noting that sha1 the fingerprint of the installed key and the picture in the instructions is the same, but there is nothing about this comparison in the installation points).









Again, open the certificate from the document. And the miracle did not happen, the chain of trust from the root to the final is not built!



We study EPs in more detail: Foxit Reader has additional information about signature properties:









Yeah, the GOSTovsky hash algorithm, ES was created in CryptoPro PDF. Perhaps Windows does not know about GOST encryption and therefore it needs an additional cryptographic provider.



We go to the CryptoPro website, register, download a trial version of CryptoPro CSP 5.0 for 3 months. What will happen next is not entirely clear, maybe everything will turn into a pumpkin, let's see.



Again, open the ES certificate view:









It looks better already. It can be seen that the system considers the certificate valid, a chain is built from the root certificate through an intermediate one.



The verification message has improved a bit, but still, Foxit Reader cannot verify the certificate (probably it’s in the GOST algorithm):









In Adobe Acrobat Reader DC, verification is also not successful:









And it seems that you can stop here: Foxit Reader confirms that the document has not been changed after signing, you can use your hands to verify that the certificate is confirmed by the system and is valid. But still I want to bring the matter to the end so that at least one program says: yes, the document is valid, everything is fine.



We recall that the policy is signed in the CryptoPro PDF program. It is likely that since she can create such signatures, she must certainly check them. We put.



+1 trial version for 90 days, although it seems that the installation inscription reassures you that you do not need a license when using the product in Adobe Acrobat Reader DC.









Hooray, the long-awaited message that everything is fine.



To summarize the subtotal. To verify the validity of the electronic signature on the document:

• Find out which certification center issued the certificate by which the document was signed, install its intermediate and, if there is none, root certificate (in our case, from the rar archive from Google Drive);
• Install a cryptographic provider in the system (there are probably other cryptographic providers who will teach Windows GOST cryptographic algorithms) CryptoPro CSP with a trial for 3 months and unknown after;
• To verify the signature from Adobe Acrobat Reader DC, install CryptoPro PDF (without CSP it is not installed).

Here is an algorithm that emerges from a surface analysis of the topic for the evening. The problem of verifying the digital signature has been resolved, but the difficulties that the average user may have are obvious:

• It is necessary to somehow find and download the root and intermediate certificates. It is not clear where it can be downloaded officially, and a network search can lead to the installation of left certificates through which scammers can attack an unlucky user;
• You need to understand what software is missing in the system and where to get it; nothing works out of the box. This article provides examples based on CryptoPro products only because this name was found in the information on the creation of electronic signatures. It is necessary to study the topic in the search for analogues;
• The check fully worked only in Adobe Acrobat Reader DC, in Foxit Reader the ES check is incomplete, there is no long-awaited green tick. Need to dig further, there are probably solutions.

Chapter Two: Another EP

Rummaging through the mail, I found another electronic contract. By a lucky chance, they also turned out to be an insurance policy, but this time eOSAGO from Tinkoff Insurance JSC. We open the certificate, look at the organization that issued the certificate. She turns out to be Tinkoff Bank JSC. Yes, it turns out they have their own CA, which issues certificates to subsidiaries (Sberbank also has its own CA, but it is not used in subsidiaries).



According to the developed algorithm, we go to the search system with the request “Tinkoff certificate”, we find the official site of the CA Tinkoff Bank JSC . Here we are greeted with an abundance of links to root certificates, lists of revoked certificates, and even video instructions for installing them. Download the “Chain of root certificates of CA Tinkoff Bank GOST R 34.10.2012” CA, this time the link does not lead to a third-party service, but to the bank’s website. The P7B file format is not very well known, but Windows opens without installing third-party software and displays the certificates in it. Here we have the familiar root certificate from the Ministry of Communications (another, not the same as in the first case) and an intermediate certificate from the CA bank.









We put both, check the certificate in the policy. But no, the certificate is not trusted, because The system cannot confirm the certificate provider. On the site of the CA there were 2 links to 2 chains of certificates, one for GOST R 34.10.2001, the other for GOST R 34.10.2012. The policy was released this year, it would be more logical to sign it with a more modern cryptographic algorithm (especially since there is already a version of GOST from 2018, the algorithms are updated quite often), but let's check the old one.









There are already 3 certificate files in the new P7B file. You can put all 3, but it is worth noting that we put the certificate of the “Head Certification Authority” in the first chapter from the RAR of the ITK LLC archive, they are identical. And the cryptoPro CSP put the certificate with the not-so-saying name “UTs 1 IS GUTs”. a checkmark about installing root certificates was installed by default in its installer. The only new one is the certificate of Tinkoff Bank JSC, which we put.



After installing the certificates from the “Chain of root certificates of CA CA Tinkoff Bank GOST R 34.10.2001”, the path in the certificate was drawn and the system joyfully announced that it was trusted. Adobe Acrobat Reader DC also confirmed that the signature is valid.









This is where the adventures with checking the ES on eOSAGO policy end. It is noticeable that after the necessary software is already installed in the system, and the user understands the principles of work and the search for intermediate certificates, then verification of the signature takes less time.



But the problem areas are still visible: you need to search the Internet for official sites of certification authorities, to understand the instructions for installing certificates. Even with root certificates installed, you must look for an intermediate, otherwise the chain of trust will not be complete and the system will not be able to confirm the authenticity of the signature.

Chapter Three: A little about root and intermediate certificates

Having done all this work, I had a feeling that the whole system was not built very securely, it requires a lot of additional operations and trust from many factors from the user: from a search system that may not give the official site of the CA to the first line, to the work of the CA staff itself, which uploads certificates without checksums to third-party web services in proprietary container formats.



For more information, I went to the website of the Ministry of Communications and Communications and found such a page . There you can download the XLS file, which will list all currently accredited CAs, as well as CAs with suspended and terminated accreditation. The accredited list includes 494 CAs, which is a lot.



However, just a list is not enough, you need at least links to the sites of these CAs, and you also need to find root certificates directly from the source, the Ministry of Communications. The next point in the search for this information was pravo.gov.ru , which lists links to some root certificates. The page is accessible only via the http protocol, again there are no checksums.



Looking closely, you can see that the first 4 links lead to the portal https://e-trust.gosuslugi.ru . It is not clear why the subdomain of the public services site has become central in the system of root certificates, but it seems that all relevant information on root and intermediate certificates is given here.



On the page of the main CA https://e-trust.gosuslugi.ru/MainCA there are 10 root certificates from the Ministry of Communications, for different GOST algorithms and with different validity periods. Key snapshots are immediately available, you can verify that no one has replaced the downloaded certificate. The site itself is certified by Thawte .



On the page of accredited CAs https://e-trust.gosuslugi.ru/CA there is a complete list of intermediate certification centers, you can download their certificates, check the cast. In addition, all information is available in XML format. At one time, you can get a file with data on all intermediate CAs, as well as their certificates and links to get a list of revoked certificates.



Certificates have a revocation list distribution point (CRL) field that specifies the path to get the list of revoked certificates. When checking the ES on a document, in addition to installing the intermediate and root certificates, you must also install the last list of revoked certificates and update it before each verification (this procedure is automated by specialized software, but regular tools seem to not be able to). Each certificate has a path to such a list on the e-trust portal and it may differ from what is written in the certificate itself. What to believe? Not quite clear.











In conclusion of the article, I would like to note that checking electronic documents on electronic documents is within the power of everyone, but this is not a completely trivial process that requires some knowledge. It is possible that in the future this process will be simplified. In addition, the question of checking ES on mobile devices remains open, and after all, they have now become the main tool of users, having long been ahead of personal computers.



After writing this article, there are several open questions that I would like to discuss with the community:

1. CryptoPro analogues, especially opensource tools for creating and checking ES;
2. adding ES validation not only in Adobe Acrobat Reader DC, but also in Foxit Reader and others;
3. problems that remain outside the scope of this article, which are also important and require attention, but did not appear in my case.

UPD 0 : In the comments, they suggested an online service on the government services portal for checking electronic documents: https://www.gosuslugi.ru/pgu/eds . Unfortunately, it did not work in my case, but it can be useful.



UPD 1 : After writing the article, they told me that there is another cryptographic provider, ViPNet CSP, which can also help with GOST cryptographic algorithms in the system. Simultaneous installation of it with CryptoPro CSP is in question.



KDPV: edar, Pixabay