Cryptographic workstation based on PKCS # 11 tokens. Electronic signature. Part 2

    In the first part of our story, we showed how, having in our hands a cryptographic token with support for Russian cryptography, create a request for a certificate, obtain and install a certificate for a token, verify the electronic signature of the certificate and its validity against the list of revoked certificates (CRL), delete the certificate from token, change labels, etc. Having created a certificate request (having generated a key pair), received a certificate in the CA and set it to a token, nothing prevents now using a personal certificate (certificate with a key pair) for electronic signing of documents. Let's get started. First, recall where the cryptoarmp11 utility is located.

    Next, run the utility and click the “1. Sign the document” button:

    Select the file with the document that we want to sign, and select the directory where we will save the file with the signature (the end of the name of this file will be .p7s). We decide whether the signed document itself will be stored in the signature body or not (attached / disconnected signature). And the most significant, we determine the format of the signature. In my opinion, you can adhere to the following rules. If this is an internal corporate document flow , where strict control over computers is carried out, then it is enough to use the CAdes signature format-BES, which includes in addition to the mathematical signature in accordance with GOST R 34.10-2012 and the time of formation of the signature (field "Current time"). If there is no strict control over computers (everyone can set any time on their computer), and the date of signing the document is important, then you must use the CAdes-T or CAdes-XLT1 format. When using the CAdes-T and CAdes-XLT1 formats, the external side is involved (similar to attracting a natarius) - a time stamp server. With CAdes-T format, the response of the time stamp server is added to the file with electronic signature (see the "TSP server" field). This answer (and this is also a document in PKCS # 7 format, signed by the TSP server) allows you to determine at what point in time the document was signed. Keep in mind that often only a mathematical signature is checked, and the validity of the signature itself by time stamps is omitted. To verify the validity of the signature, of course, verification of the validity of the certificates is required. And so, in order to simplify this work, the CAdes-XLT1 signature format implies the inclusion in the signature file of all evidence of signature validity at the time of its creation. These are certificates, including certificates of CA, time stamp servers, ocsp-servers, as well as lists of revoked certificates and responses of OCSP-servers. We will not dwell on this. Who wants to find the appropriate literature. including CA certificates, time stamp servers, ocsp servers, as well as lists of revoked certificates and OCSP server responses. We will not dwell on this. Who wants to find the appropriate literature. including CA certificates, time stamp servers, ocsp servers, as well as lists of revoked certificates and OCSP server responses. We will not dwell on this. Who wants to find the appropriate literature.

    So, we decided on the format of the signature and clicked the button “Sign the document”. Next, we need to enter another PIN-code for the token, then a warning appears about the beginning of the formation of the signature and the need to be patient and, finally, the signature will be created:

    What does it take to create the signature? This, of course, is the mathematical calculations themselves and the collection of various data (certificates, CRLs, OCSP server responses, time stamps). Everything, the signature is created. Upon receipt of the certificate in the CA, be sure to find out the address of the time stamp server of your CA. If links to certificates of certification authorities (certificate chain ), to lists of revoked certificates, as well as OCSP server are taken from the certificates, then the address of the time stamp server will have to be entered manually (field "TSP Server").

    How to make sure that the signature is created correctly and the document can be transferred to the case. On the Internet you can find various sites to verify the signature. Some of them check only the disconnected signature, others check everything and inform well:

    But in either case, this does not guarantee you that your signature will be accepted at the organization where you present the signed document, for example, on the State Service website. This is due to the fact that in different ways evidence of the validity of the signature in XLT1 format can be stored and verified. So, for example, on the website of the State Service it is required that the evidence of the validity of the certificate of the time stamp server is stored in the signature received from the server. And if they are not there, then, despite the fact that they may be present in the signature of the document, the signature on the website of the State Services will be invalidated. Everything is fine with our signature:

    Go to the page “2. Working with ES (PKCS7)” and immediately select the file with the created signature:

    When loading a signature, the utility fills in the appropriate fields on the main window. The screenshot displays this well. It shows when the signature was generated on the user's computer (field “Signing Date:”), when this date was verified on the time stamp server (field “Date of receipt of the time stamp”) and when all evidence of validity was collected (field “Date of approval of the label time ”).

    What operations can be performed on a signature is also clear. Of greatest interest here is the addition of a signature to a previously signed document. To do this, just select a certificate to add a new signature (analogue of document vising) and do not forget about choosing a TSP server:

    And if you look who signed the document, then there are now two signatories. And both signatures were successfully verified on the public services website:

    In my opinion, the utility corresponds to the aspirations of having a utility for signing documents, having on hand "certificates on tokens with an unrecoverable key that they can read everything themselves."

    However, we decided to go further and include in this utility a page for working with the PKCS # 12 container , which is becoming increasingly popular. And if now for signing a document you need the PKCS # 11 token and a library for it, then when using PKCS # 12 you will only need the container itself. And of course the utility that we talked about today. But this utility is absolutely self-sufficient and, unlike various CSPs, does not patch any kernel and works on any platform. Therefore, we move on to the third part .

    Also popular now: