I will talk about the intricacies of the introduction of electronic digital signature (EDS) in information systems (IP) based on web technologies in the context of the National Certification Authority Center of the Republic of Kazakhstan (RCC RK) .


The focus will be on the creation of digital signatures under electronic documents and, accordingly, NCALayer - cryptographic provided by the NTC RK software. In particular, I will pay attention to issues related to UX and the amount of supported functionality of NCALayer.


I will divide the process into the following stages:


  • the formation of an invariable presentation of the signed document (by the signed document I will mean any data that needs to be signed, such as: agreement, order form, authentication form, etc.);
  • signing a document in the web interface using NCALayer;
  • server side signature verification;
  • (if necessary) preparation of the signature for long-term storage.

Formation of the invariable representation of the signed document


It is important for developers to understand that any change to a signed document will cause the signature under it to stop being verified. At the same time, changes can be caused not only by editing the data of the document itself, but also by updating the structure of the document or its serialization mechanism.


Consider a simple example - documents are stored as records in a database. To sign a document, it is necessary to formulate it as a single data block (of course, you can sign each field individually, but usually they don’t), you can do this, for example, in the following ways:


  • extract all fields of the record, bring them to strings and concatenate in one line;
  • form an XML or JSON representation;
  • generate a PDF document based on a template with some design containing data from the record;
  • etc.

Further, two scenarios are possible, each of which has its pitfalls:


  • IS does not store the generated view and each time for verification of the signature under the document (in particular, verification of the immutability of data) forms it;
  • The IS stores the generated view and uses it to verify the signature.

In the event that the IS does not store the generated view, developers need to ensure that in the future the generated views will be binary identical to those that were formed for the first time despite:


  • database schema changes;
  • Updates to the presentation engine (which may also depend on external libraries, which most likely do not strive to provide binary identity).

In the event that at some stage the binary identity ceases to be respected, the verification of digital signatures ceases to be carried out and the legal significance of documents in the IP will be lost.


The approach to storing the generated view in the IP database is more reliable from the point of view of ensuring the preservation of legal significance, but there is a nuance here - it is necessary to guarantee the equivalence of the data in the signed document to the data in the database record otherwise the situation may arise when the IP makes a decision ( performs the calculation) based on information that does not correspond to what was signed. That is, it is necessary either to ensure, as in the previous case, the binary identity of the generated view, then during the checks, first of all, it is necessary to form the view from the current contents of the record in the database and binary compare the new view with the saved one. Or you need a mechanism to parse the stored generated view and compare the data from it with the current contents of the record in the database. This mechanism will also have to be developed constantly in parallel with the refinements of the main IP functionality.


Signing a document in the web interface using NCALayer


For the formation of digital signatures on the client side, the NTC RK provides the only tool - certified software NCALayer which represents a WebSocket server running on CDMY0CDMY, to which you can send requests for cryptographic (as well as some related) operations. When performing some operations, NCALayer displays dialog boxes - that is, it takes part of the work of receiving user input on itself.


Description of the NCALayer API is available as part of the development kit . To experiment with interaction with NCALayer via WebSocket, you can use the KAZTOKEN mobile online documentation page (KAZTOKEN mobile repeats API NCALayer).


Interaction with NCALayer from the browser can be done directly using the WebSocket class , or you can use the ncalayer-js-client library which wraps sending commands and receiving responses to modern CDMY1CDMY challenges.


I note that all the basic functionality of NCALayer is available in the CDMY2CDMY module, I do not recommend using the CDMY3CDMY module (legacy of the Java applet), since, in my opinion, this will not give any advantages, but there are more chances to shoot yourself in the foot with it - for example you can accidentally develop an interface that will not support hardware media (tokens or smart cards) with several key pairs.


The CDMY4CDMY module takes upon itself the interaction with the user related to the choice of a specific storage that needs to be used to perform the operation (he also takes upon himself the choice of a specific certificate and the corresponding key, as well as entering a password or PIN code), but he needs specify what type of storage should be used. Storage types should be divided into two classes:


  • file types, the only type specified by the CDMY5CDMY constant is supported,
  • hardware (tokens and smart cards), to list the types whose instances are currently connected to the user's PC, use the CDMY6CDMY request.

Thus, in order to provide the user with the opportunity to work with any storage supported by NCALayer, you can use one of the following approaches:


  • flexible - send a request to CDMY7CDMY, in response to get an array of names of currently available storage types, add CDMY8CDMY to it and ask the user which one he would like to use at the moment;
  • simple - send a request to CDMY9CDMY, if he returned the array with several names, ask the user to disconnect the excess if there is one element in the array, use it if the array is empty, use CDMY10CDMY.

I recommend using the following queries to sign the data (again, to reduce the likelihood of a shot in the leg):


  • CDMY11CDMY - calculate the signature under the data and form the CMS (CAdES);
  • CDMY12CDMY - calculate the signature under the data, get the time stamp on the signature (TSP) and form the CMS (CAdES) with the embedded time stamp;
  • CDMY13CDMY - calculate the signature for an XML document, add the generated signature to the resulting document (XMLDSIG);
  • CDMY14CDMY - similar to CDMY15CDMY, but allows you to sign several XML documents at a time.

As parameters, each of them will need to pass the type of storage, type of certificate, signed data and additional modifiers.


The CDMY16CDMY module supports the following types of certificates:


  • CDMY17CDMY - certificates for authentication;
  • CDMY18CDMY - certificates for signing data.

NCLayer will allow the user to select only from those certificates that match the specified type.


A simplified example of signing an arbitrary data block using ncalayer-js-client :


async function connectAndSign(base64EncodedData) { const ncalayerClient=new NCALayerClient(); try { await ncalayerClient.connect(); } catch (error) { alert(`Не удалось подключиться к NCALayer: ${error.toString()}`); return; } let activeTokens; try { activeTokens=await ncalayerClient.getActiveTokens(); } catch (error) { alert(error.toString()); return; } const storageType=activeTokens[0] || NCALayerClient.fileStorageType; let base64EncodedSignature; try { base64EncodedSignature=await ncalayerClient.createCAdESFromBase64(storageType, base64EncodedData); } catch (error) { alert(error.toString()); return; } return base64EncodedSignature; } 

Server-side signature verification


The topic of verification of digital signatures is extensive and I did not plan to disclose it this time, but I considered it necessary to verify the verification from both a technical and legal point of view.


From a technical point of view, verification of a digital signature on the server side first of all guarantees the integrity of the received document, in the second - authorship, as well as non-repudiation. That is, even if the IS receives the signed document not directly from the user, but through some additional layers of software, the confidence that it was received exactly what the user sent is saved. Therefore, in a situation where client-side signing is implemented, and there is no possibility of verifying the signature on the server side, the introduction of a digital signature makes no sense.


From a legal point of view, you should focus on the Order of the Minister of Investment and Development of the Republic of Kazakhstan “On approval of the Verification Rules Electronic Digital Signature Authentication ” . The Order lists the necessary checks that information systems must perform to ensure the legal significance of documents signed by electronic digital signature. Digital Signature Verification is devoted to the analysis of this document, as well as to some technical issues.


It is necessary to carry out checks using certified tools, for example, using the libraries included in the development kit of the NSC RK , or you can use the ready-made solution SIGEX .


Preparing a signature for long-term storage


Verification of the signature of an electronic document includes verification of the validity of the certificate and verification of the status of revocation of the certificate. In the case when it is necessary to ensure the legal significance of the signed document upon the expiration of the certificate or in the case when the certificate was revoked some time after signing, an additional set of evidence should be collected to record the moment of signing and confirming that the certificate did not expire at the time of signing and was not recalled.


To fix the moment of signing it is customary to use TSP timestamps. The timestamp for signing can be obtained either on the client (request CDMY19CDMY integrates the timestamp in the CMS) or on the server. A timestamp will make sure that the moment of signing falls within the validity period of the certificate.


In order to make sure that the certificate was not revoked at the time of signing, you should use the CRL or OCSP response. This nuance and implementation recommendations are described in the APPENDIX B - Placing a Signature At a Particular Point in Time section of RFC 3161 .

.

Source