Electronic signature technologies

Introduction

The introduction of electronic signature (without division into cryptoalgorithms used and the criterion of "qualification", see Law 63- , Art. 5) is usually caused by the need to control the integrity and authorship of information flows and documents generated in the system.

Under the cat described interfaces for working with electronic signature, as well as common formats of electronic signature.

According to generally accepted terminology, an electronic signature is an attribute of an electronic document, which allows to establish the fact of the integrity of an electronic document and verify that the signature belongs to the owner of the public key of the signature. Separately, it should be noted that the electronic signature has nothing to do with the confidentiality of information. That is, the signed document is still free to read.

Electronic signature is implemented on the basis of asymmetric cryptography , or public key cryptography. Asymmetric cryptographic algorithms involve the use of a pair of keys: public and private. The private key is used to generate an electronic signature, open - to verify it.
')
Special attention in the issue of working with an electronic signature should be given to the establishment of a correspondence between the public key of the signature and the person to whom it belongs. To solve this problem, there is such a thing as “ Certificate of public key of electronic signature ” (or simply “digital certificate”). Public key infrastructure (Public Key Infrastructure) is required to issue, validate, revoke and manage certificates. The question of comparing the public key and its owner is one of the most important and complex when dealing with asymmetric cryptography, since the public key is in no way an identifiable set of public information that serves to verify an electronic signature. And in the absence of a bundle of this information directly with its owner, it can always be changed by an attacker, which will allow him to generate an electronic signature and issue it as an electronic signature of another person.

Embedding electronic signatures into application systems

Crypto-resistant algorithms, adopted as national or global standards, are widely available. Their cryptoresistance is based on mathematical problems that cannot be solved in a reasonable time.

But the implementation of cryptoalgorithms, taking into account the high speed, the absence of errors and the guaranteed fulfillment of the requirements of mathematical transformations, is not an easy task for qualified developers.

If the electronic signature is used in critical applications (for example, to perform legally significant actions), the implementation of cryptographic algorithms necessarily passes the process of certification for compliance with security requirements.

In the “western” world, Common Criteria certification of solutions is widely used; in Russia, the process of certifying cryptographic protection tools is carried out by the Federal Security Service of Russia.

Additionally, the means of cryptographic protection of information (CIPS, this term is widely used in the Russian Federation) can have very different ideas: from software libraries to high-performance specialized hardware (Hardware Security Module, HSM).

It is because of the complexity of the implementation and regulation of this type of product that there is a market for solutions for cryptographic information protection, which is played by various players.

For the purpose of compatibility of various implementations, as well as simplifying their integration into the application software, several standards have been developed that relate to various aspects of working with the SKZI and directly with electronic signatures.

Interfaces for access to SKZI

To date, one industry standard of working with IMSPs and one (in fact two) proprietary interfaces by all well-known Microsoft companies have become widespread.

PKCS # 11

PKCS # 11 (Public-Key Cryptography Standard # 11) is a platform-independent software interface for working with hardware-implemented SKZI: smart cards, HSMs, cryptographic tokens. Sometimes PKCS # 11 is used to access software-implemented cryptographic libraries.

PKCS # 11 is a fairly extensive document published by RSA Laboratories, which describes a set of functions, mechanisms, algorithms and their parameters for working with cryptographic devices or libraries. This document clearly states the rules according to which the application software will work when calling cryptographic functions.

This standard is supported in many open source projects using cryptography. For example, Mozilla Firefox allows you to store certificates and private keys for authentication via SSL / TLS on tokens, working with them on PKCS # 11.

If the application software “can” work with PKCS # 11, then the manufacturer of the CMIS must implement a software library that will externally expose the interfaces described in the standard, and internally implement the necessary IPMS logic: working directly with a cryptographic device or implementing the necessary cryptographic algorithms in software. In this case, the application software must “pick up” the necessary library and perform the necessary actions in accordance with the recommendations of the standard. This provides the interchangeability of various devices and their libraries for application software and the transparent use of SKZI in various systems.



The only significant disadvantage of PKCS # 11 is the lack of recommendations for working with public key certificates, which implies either the use of proprietary extensions of the standard, or the use of other means to work with certificates.

Microsoft Crypto API 2.0

The Microsoft Windows operating system, regardless of the version, is a rather complex system, which among other things deals with the security of user and corporate data. In these tasks, cryptography is traditionally widely used.

In order to unify access to cryptographic functions, Microsoft has developed a proprietary API: Microsoft Crypto API. The Crypto API 2.0 version has become widespread. The Microsoft Crypto API paradigm is based on the use of so-called crypto-providers, or, in Russian, cryptographic providers.



The Crypto API specification describes the set of functions that the crypto-provider library should provide to the operating system, how to integrate with it, and call specifications. Thus, the manufacturer of the CIPP, which complies with the rules of the Crypto API, has the ability to integrate its solution into the Microsoft Windows operating system, and the application software accesses cryptographic functions through a unified interface.

An additional advantage is that Microsoft has implemented a fairly large number of functions over the Crypto API that are responsible for performing application tasks: working with certificates, generating various types of signatures, working with key information, etc. Also, the Crypto API, as you might guess, is tightly integrated with operating system and its internal mechanisms.

But paying for the convenience becomes the platform dependence and the need to closely integrate the solution into the operating system.

In Windows Vista, Microsoft introduced a new version of the cryptographic software interface - Microsoft CNG (Cryptography API: Next Generation). This interface is no longer based on suppliers of cryptography, but on suppliers of algorithms and suppliers of key information stores. Due to the fact that the prevalence of Windows XP is still quite high, CNG is used very little in application systems.

Proprietary Interfaces

The presence of standardized interfaces has never been an obstacle to the existence of proprietary libraries with their interfaces. An example of this is the OpenSSL library, which is handled by its own rules.

The PKCS # 11 standard suggests the possibility of using proprietary extensions. In fact, these are features added by the manufacturer that are not described in the standard. Usually they serve to perform specific operations with devices or implement the necessary, according to the manufacturer, functions.

Electronic signature formats

The interfaces described above for accessing cryptographic functions make it possible to apply for the implementation of mathematical transformations to various, as was well noted by Microsoft, “cryptographic providers”.

But there are many algorithms for generating and verifying electronic signatures. Each of these algorithms has a set of parameters that must be coordinated during development and verification. Plus to verify the signature in a good need a certificate. All these parameters must either be coordinated in the application system, or passed along with the signature.
A number of standards are also proposed for this task.

PKCS # 7

PKCS # 7 (Public-Key Cryptography Standard # 7), or CMS (Cryptographic Message Syntax) is a standard published and supported by the same RSA Laboratories, described syntax of cryptographic messages.

PKCS # 7 is also published as RFC number 2315.

The CMS syntax describes how to generate cryptographic messages, as a result of which the message becomes completely self-sufficient to open it and perform all the necessary operations.

For this purpose, the PKCS # 7 contains information about the original message (optional), hashing and signature algorithms, cryptographic algorithm parameters, signature time, electronic signature key certificate, certification chain, etc.

Most PKCS # 7 attributes are optional, but their binding nature may be determined by the application system.

Separately, it should be noted that PKCS # 7 allows you to put several signatures under one document, saving all the necessary information in the message.

The formation and verification of PKCS # 7 are implemented in cryptographic "add-ins" in the Microsoft Crypto API, which were discussed above. But the format itself is fairly well specialized and its support can be implemented natively.

XML DSig

W3C has developed and published guidelines for writing signed messages in XML format.

In fact, XML-DSig solves the same issues as PKCS # 7. The main difference is that in PKCS # 7 data is stored in structures formed in accordance with the ANS.1 markup (in fact, binary data), and in XML-DSig the data is stored in text format in accordance with the rules of the document “XML Signature Syntax and Processing ".

XML-DSig is used for web applications and web services.

Raw signature

The electronic signature formats described above are necessary for the interaction of heterogeneous systems, when information about the sender of the signed message is minimal.

When interacting within the same information system, when the information about the sender, the cryptographic algorithms used and their parameters is known to the recipient, it is more rational to use a “raw” electronic signature.

In this case, only the value of the electronic signature is actually transmitted along with the document. Information for verification is taken by the recipient from a centralized database.

This makes it possible to significantly simplify the procedure for generating and verifying signatures, since there are no steps to compose and parse messages in accordance with any format.

Conclusion

As a conclusion, I would like to note that the use of various software interfaces and electronic signature formats within the application software must comply with the functions and tasks of this software without imposing restrictions and additional requirements on the user.

Links

PKCS # 11: Cryptographic Token Interface Standard
Cryptography Reference. MSDN
Cryptography API: Next Generation. MSDN
PKCS # 7: Cryptographic Message Syntax Standard
XML Signature Syntax and Processing (Second Edition)