Electronic signature formats
The article is devoted to the review of CMS (Cryptographic Message Syntax) standards for signed messages.
The CMS standard describes the structure of cryptographic messages, which include protected data along with the information necessary for their correct discovery or use. For example, the message contains protected data, information about the hashing algorithm and signature, signature time, public key certificate, certification chain, etc. Some of these attributes are optional, but the application itself can determine the need for them. Each algorithm has a set of parameters that must be matched on both sides: for GOST 34.10-2001, in addition to the public key, it is the modulus p , the coefficients of the elliptic curve a and b, and the order of the cyclic subgroup of points of the elliptic curve q . And all this needs to be somehow conveyed to the addressee of the message.
RSA Laboratories, in a series of its public key cryptography standards (PKCS), proposed a solution to this problem by defining the syntax for protected messages in the following standards:
The development of these standards has become the CMS standard. CMS, in addition to thespecific title of the article , also supports encryption, hashing, and calculation of imitations, including Russian algorithms ( RFC 4490 ), as well as multiple encapsulation. The latter means that the message of the CMS format may lie within another CMS message.
In total, the CMS supports six data types:
Within the framework of the article we will consider in detail only data with an electronic signature (signed data).
')
In order not to be confused in terminology, the source data, which we want to transmit in a secure way, will be called data , and the resulting secure CMS message will simply be a message .
The cryptographic message syntax (CMS) was first defined in PKCS # 7 , which was later published as a recommendation of RFC 2315 "PKCS # 7: Cryptographic Message Syntax Version 1.5" . After a few more versions of the RFC in September 2009, RFC 5652 “Cryptographic Message Syntax (CMS)” was adopted, which is the current standard.
Under the spoiler is illustrated the hard fate of the standard.
The signature described by the CMS standard is characterized by the following features:
Electronic signature data is not only used to sign content and is often used to distribute certificates and Certificate Revocation Lists (CRLs). In this case, the signed data is missing, and the fields Certificates and CRLs, on the contrary, are present.
A message signed by Alice in the CMS format will look like the following (optional attributes are grayed out):
If Bob decides to fully sign the message from Alice, then the encapsulation mechanism is used, and the message will look like this:
CMS offers two interesting attributes that extend the capabilities of a regular signature: Signing Time and Countersignature. The first attribute defines the estimated time of the signature, and the second is intended to sign another signature (the hash of the signature value is signed). The Countersignature attribute is a Signer Info structure with the Content Type attribute missing in Signed Attributes and the Message Digest attribute that is necessarily present. The Countersignature attribute can have its own Countersignature attribute.
If Bob decides to sign only the data transmitted by Alice, and at the same time sign Alice's signature, the message will look like this:
Galloping
CMS offers some more interesting types of messages not covered by the topic of this article. Therefore, literally a couple of words about the remaining types for the overall picture.
Enveloped data is encrypted data, along with keys encrypted for one or more recipients, with which the data was encrypted. The combination of an encrypted message with one encrypted encryption key for one recipient is called a digital envelope. This type is used as an envelope with (signed) data for one or several recipients.
Hash data (data with its own hash) is used to check the integrity of the message and is often the contents of the packed data.
Encrypted data is often used to encrypt data for local storage, sometimes with an encryption key generated from a password.
The data from the authenticated source (authenticated data) includes the data along with its MAC code and encrypted authentication keys for one or more recipients. Used to protect the integrity of messages for an unlimited number of recipients.
In the next article we will focus on messages like enveloped data using Russian cryptoalgorithms.
The CMS standard has many incarnations in the modern IT world - it is based on:
The logical development of CMS ideas for messages with electronic signature has become CAdES (CMS Advanced Electronic Signature), an advanced standard of signed CMS messages, which will also be the subject of another of our articles.
The CMS / PKCS # 7 standard with the support of Russian cryptoalgorithms is implemented in certified partners of our partners:
In addition, the CMS standard with Russian cryptography is implemented in the Open Source application OpenSSL.
Our company supported CMS with Russian cryptography in the product Rutoken Plugin . The Rutoken Plugin is designed for use in browsers, all cryptographic operations are performed in hardware, on board a USB token.
What is CMS for?
The CMS standard describes the structure of cryptographic messages, which include protected data along with the information necessary for their correct discovery or use. For example, the message contains protected data, information about the hashing algorithm and signature, signature time, public key certificate, certification chain, etc. Some of these attributes are optional, but the application itself can determine the need for them. Each algorithm has a set of parameters that must be matched on both sides: for GOST 34.10-2001, in addition to the public key, it is the modulus p , the coefficients of the elliptic curve a and b, and the order of the cyclic subgroup of points of the elliptic curve q . And all this needs to be somehow conveyed to the addressee of the message.
RSA Laboratories, in a series of its public key cryptography standards (PKCS), proposed a solution to this problem by defining the syntax for protected messages in the following standards:
The development of these standards has become the CMS standard. CMS, in addition to the
In total, the CMS supports six data types:
- just data
- signed data (signed data)
- packed data (enveloped data),
- hashed data (digested data)
- encrypted data
- authenticated data.
Within the framework of the article we will consider in detail only data with an electronic signature (signed data).
')
In order not to be confused in terminology, the source data, which we want to transmit in a secure way, will be called data , and the resulting secure CMS message will simply be a message .
CMS Standard (PKCS # 7 and RFC 5652): Theory
A bit of history
The cryptographic message syntax (CMS) was first defined in PKCS # 7 , which was later published as a recommendation of RFC 2315 "PKCS # 7: Cryptographic Message Syntax Version 1.5" . After a few more versions of the RFC in September 2009, RFC 5652 “Cryptographic Message Syntax (CMS)” was adopted, which is the current standard.
Under the spoiler is illustrated the hard fate of the standard.
Watch
PKCS # 7 / CMS Evolution
PKCS # 7 / CMS Evolution
Signature in CMS format (signed data type)
The signature described by the CMS standard is characterized by the following features:
- Data can be signed by several parties (multiple signature). In this case, the message will contain several SignerInfo structures with information about signatories: the value of the signature and the information necessary for verifying its authenticity.
- The data type is not regulated in any way, it only clarifies that a CMS format message can be used as data, that is, a message signed by Alice can be entirely signed by Bob.
- It is possible to sign not only data, but also some attributes of the message - message hash (digest message), signing time (the signing time), the value of another signature (countersignature).
- The signer's public key may be uncertified.
- The signature may be absent altogether.
Electronic signature data is not only used to sign content and is often used to distribute certificates and Certificate Revocation Lists (CRLs). In this case, the signed data is missing, and the fields Certificates and CRLs, on the contrary, are present.
A message signed by Alice in the CMS format will look like the following (optional attributes are grayed out):
- Version of CMS Version syntax depends on certificates, type of data to be signed and information about signers
- Digest Algorithms includes identifiers of the hashing algorithms used and their associated parameters.
- Encapsulated Content contains the data to be signed (Content) along with their Type (Content Type). Content may be missing, type is not.
- Certificates is intended for a chain of certificates reflecting the certification path from the certification authority that issued the certificate to each of the signatories. Certificates of signatories may also be present.
- CRLs (Certificate Revocation List) provides certificate revocation status information sufficient to determine the validity of the signer's certificate.
- Information about each signer is contained in the structures of the Signer Info type, which can be any number, including zero (in the case of no signature).
- The CMS Version syntax version is determined by the Signer ID value.
- The Signer ID identifies the signer's public key (subjectKeyIdentifier) or its public key certificate, which is required for signature verification (issuerAndSerialNumber).
- Digest Algorithm defines the hashing algorithm and all associated parameters used by the signer.
- Attributes that require a signature are placed in Signed Attributes. The field can be absent only when signing simple data (Content Type = id-data), when signing other data (for example, Content Type = id-SignedData) must be present with at least two mandatory attributes - the type (Content Type) and the data hash (Message Digest).
- The Signature Algorithm contains the signature algorithm identifier along with its parameters.
- The Signature Value contains the value of the private key-signed hash of the data (Content) and Signature Attributes.
- In Unsigned Attributes, the remaining attributes that do not require a signature are placed.
If Bob decides to fully sign the message from Alice, then the encapsulation mechanism is used, and the message will look like this:
CMS offers two interesting attributes that extend the capabilities of a regular signature: Signing Time and Countersignature. The first attribute defines the estimated time of the signature, and the second is intended to sign another signature (the hash of the signature value is signed). The Countersignature attribute is a Signer Info structure with the Content Type attribute missing in Signed Attributes and the Message Digest attribute that is necessarily present. The Countersignature attribute can have its own Countersignature attribute.
If Bob decides to sign only the data transmitted by Alice, and at the same time sign Alice's signature, the message will look like this:
Galloping Europe for the remaining types
CMS offers some more interesting types of messages not covered by the topic of this article. Therefore, literally a couple of words about the remaining types for the overall picture.
Enveloped data is encrypted data, along with keys encrypted for one or more recipients, with which the data was encrypted. The combination of an encrypted message with one encrypted encryption key for one recipient is called a digital envelope. This type is used as an envelope with (signed) data for one or several recipients.
Hash data (data with its own hash) is used to check the integrity of the message and is often the contents of the packed data.
Encrypted data is often used to encrypt data for local storage, sometimes with an encryption key generated from a password.
The data from the authenticated source (authenticated data) includes the data along with its MAC code and encrypted authentication keys for one or more recipients. Used to protect the integrity of messages for an unlimited number of recipients.
In the next article we will focus on messages like enveloped data using Russian cryptoalgorithms.
CMS in real life
The CMS standard has many incarnations in the modern IT world - it is based on:
- S / MIME Secure Email Standard ( RFC 3851 ),
- Advanced security services for S / MIME ( RFC 2634 , by the way, here are described the additional attributes of CMS and the technology of triple "wrapping" based on multiple encapsulation: the data is signed, then encrypted and signed again),
- Extended formats for presenting information about revoked certificates ( RFC 5940 ), etc.
The logical development of CMS ideas for messages with electronic signature has become CAdES (CMS Advanced Electronic Signature), an advanced standard of signed CMS messages, which will also be the subject of another of our articles.
How to put into practice?
The CMS / PKCS # 7 standard with the support of Russian cryptoalgorithms is implemented in certified partners of our partners:
- CryptoPro CSP Company Crypto Pro
- Infotex VipNet CSP
- SignalKom CSP or Message-PRO company SignalCom, etc.
In addition, the CMS standard with Russian cryptography is implemented in the Open Source application OpenSSL.
Our company supported CMS with Russian cryptography in the product Rutoken Plugin . The Rutoken Plugin is designed for use in browsers, all cryptographic operations are performed in hardware, on board a USB token.
Source: https://habr.com/ru/post/191866/
All Articles