August 29, 2013 at 14:58Electronic Signature Formats
This article reviews the 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 opening or use. For example, the message contains protected data, information about the hashing and signature algorithm, signature time, public key certificate, certification chain, etc. Some of these attributes are optional, but the application itself can determine the need for their presence. Each algorithm has a set of parameters that must be consistent on both sides: for GOST 34.10-2001, in addition to the public key, it is the module 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 message recipient.
RSA Laboratories, in a series of its public key cryptography standards (PKCS), has proposed a solution to this problem by defining the syntax for secure messages in the following standards:
The development of these standards was the CMS standard. In additionto the signature defined by the title of the article, CMS supports encryption, hashing, and calculation of the insert, including using Russian algorithms ( RFC 4490 ), as well as multiple encapsulation. The latter means that a CMS format message may lie inside another CMS message.
In total, CMS supports six data types:
In the framework of the article, we will consider in detail only data with electronic signature (signed data).
In order not to be confused in terminology, further the initial data that we want to transmit in a secure way will be called data , and the resulting secure CMS message will be called just a message .
Cryptographic message syntax (CMS) was first defined in PKCS # 7 , which was later published as RFC 2315 “PKCS # 7: Cryptographic Message Syntax Version 1.5” . After several more RFC versions, in September 2009, RFC 5652, “Cryptographic Message Syntax (CMS),” which is the current standard , was adopted .
The spoiler illustrates 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 Certification Revocation List (CRLs). In this case, the data being signed is not available, and the Certificates and CRLs fields, on the contrary, are present.
A message signed by Alice in CMS format will look like this (optional attributes are grayed out):
If Bob decides to completely sign the message received from Alice, then the encapsulation mechanism is used, and the message will look like this:
CMS offers two interesting attributes that expand the capabilities of conventional signatures: Signing Time and Countersignature. The first attribute determines the estimated time for signing, and the second is for signing another signature (the hash of the signature value is signed). The Countersignature attribute is a Signer Info structure with no Content Type attribute in the Signed Attributes and a Message Digest attribute that is required. The Countersignature attribute may 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:
Gallop over
CMS offers some more interesting types of messages that are not covered by the topic of this article. Therefore, literally a couple of words about the remaining types for the overall picture.
Packed data (enveloped data) is the encrypted data together with the keys encrypted for one or more recipients by which this 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 more recipients.
The hashed data (data along with its hash) is used to verify the integrity of the message and is often the content of the packed data.
Encrypted data is often used to encrypt data for local storage, sometimes with an encryption key generated from a password.
Data from an authenticated source (authenticated data) includes data along with their MAC code and encrypted authentication keys for one or more recipients. Used to protect message integrity for an unlimited number of recipients.
In the next article, we will dwell in detail on messages such as enveloped data using Russian cryptographic algorithms.
The CMS standard has many incarnations in the modern world of IT - it is based on:
The natural development of CMS ideas for messages with electronic signature has become CAdES (CMS Advanced Electronic Signature), an extended standard for CMS signed messages, which will also serve as a topic for another article of ours.
The CMS / PKCS # 7 standard with the support of Russian cryptographic algorithms is implemented in certified by CIPF of our partners:
In addition, the CMS standard with Russian cryptography is implemented in the Open Source OpenSSL application.
Our company supported CMS with Russian cryptography in the Rutoken Plug- in product . Rutoken plugin is intended 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 opening or use. For example, the message contains protected data, information about the hashing and signature algorithm, signature time, public key certificate, certification chain, etc. Some of these attributes are optional, but the application itself can determine the need for their presence. Each algorithm has a set of parameters that must be consistent on both sides: for GOST 34.10-2001, in addition to the public key, it is the module 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 message recipient.
RSA Laboratories, in a series of its public key cryptography standards (PKCS), has proposed a solution to this problem by defining the syntax for secure messages in the following standards:
The development of these standards was the CMS standard. In addition
In total, CMS supports six data types:
- just data
- data with electronic signature (signed data),
- Packed data
- hashed data (digested data),
- encrypted data
- authenticated data
In the framework of the article, we will consider in detail only data with electronic signature (signed data).
In order not to be confused in terminology, further the initial data that we want to transmit in a secure way will be called data , and the resulting secure CMS message will be called just a message .
CMS Standard (PKCS # 7 and RFC 5652): Theory
A bit of history
Cryptographic message syntax (CMS) was first defined in PKCS # 7 , which was later published as RFC 2315 “PKCS # 7: Cryptographic Message Syntax Version 1.5” . After several more RFC versions, in September 2009, RFC 5652, “Cryptographic Message Syntax (CMS),” which is the current standard , was adopted .
The spoiler illustrates 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 the signatories: the value of the signature and the information necessary to verify its authenticity.
- The data type is not regulated in any way, it only clarifies that the data can be a message in CMS format, that is, a message signed by Alice can be entirely signed by Bob.
- You can sign not only data, but also some attributes of the message - the message hash (digest message), the signing time (signing time), the value of another signature (countersignature).
- The public key of the signatory 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 Certification Revocation List (CRLs). In this case, the data being signed is not available, and the Certificates and CRLs fields, on the contrary, are present.
A message signed by Alice in CMS format will look like this (optional attributes are grayed out):
- The CMS Version syntax version depends on certificates, the type of data to be signed, and information about signers
- Digest Algorithms includes the identifiers of the hash algorithms used and the parameters associated with them.
- Encapsulated Content contains the signed data (Content) along with its type (Content Type). Content may not be present, type may 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. Signing certificates may also be present.
- CRLs (Certificate Revocation List) provides certificate revocation status information sufficient to determine the validity of a signatory certificate.
- Information about each signatory is contained in structures of the Signer Info type, which can be any number, including zero (in the absence of a signature).
- The CMS Version syntax version is determined by the Signer ID value.
- Signer ID defines the public key of the signatory (subjectKeyIdentifier) or the certificate of its public key required for signature authentication (issuerAndSerialNumber).
- Digest Algorithm defines the hash algorithm and all associated parameters used by the signer.
- Signed Attributes contain attributes that require a signature. The field may be absent only when signing simple data (Content Type = id-data), while signing other data (for example, Content Type = id-SignedData) must be present with at least two required attributes - the type (Content Type) and the data hash (Message Digest).
- Signature Algorithm contains the identifier of the signature algorithm along with its parameters.
- Signature Value contains the value of the hash signed by the private key for the data (Content) and attributes for the signature (Signed Attributes).
- Unsigned Attributes contains the remaining attributes that do not require a signature.
If Bob decides to completely sign the message received from Alice, then the encapsulation mechanism is used, and the message will look like this:
CMS offers two interesting attributes that expand the capabilities of conventional signatures: Signing Time and Countersignature. The first attribute determines the estimated time for signing, and the second is for signing another signature (the hash of the signature value is signed). The Countersignature attribute is a Signer Info structure with no Content Type attribute in the Signed Attributes and a Message Digest attribute that is required. The Countersignature attribute may 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:
Gallop over Europe remaining types
CMS offers some more interesting types of messages that are not covered by the topic of this article. Therefore, literally a couple of words about the remaining types for the overall picture.
Packed data (enveloped data) is the encrypted data together with the keys encrypted for one or more recipients by which this 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 more recipients.
The hashed data (data along with its hash) is used to verify the integrity of the message and is often the content of the packed data.
Encrypted data is often used to encrypt data for local storage, sometimes with an encryption key generated from a password.
Data from an authenticated source (authenticated data) includes data along with their MAC code and encrypted authentication keys for one or more recipients. Used to protect message integrity for an unlimited number of recipients.
In the next article, we will dwell in detail on messages such as enveloped data using Russian cryptographic algorithms.
CMS in real life
The CMS standard has many incarnations in the modern world of IT - it is based on:
- S / MIME Secure Email Standard ( RFC 3851 )
- extended security services for S / MIME ( RFC 2634 , by the way, here additional CMS attributes and triple wrapping technology based on multiple encapsulation are described: data is signed, then encrypted and re-signed),
- extended formats for the submission of information on revoked certificates ( RFC 5940 ), etc.
The natural development of CMS ideas for messages with electronic signature has become CAdES (CMS Advanced Electronic Signature), an extended standard for CMS signed messages, which will also serve as a topic for another article of ours.
How to put into practice?
The CMS / PKCS # 7 standard with the support of Russian cryptographic algorithms is implemented in certified by CIPF of our partners:
- CryptoPro CSP Crypto-Pro
- VipNet CSP company Infotex
- SignalCom CSP or Message-PRO of SignalCom and others.
In addition, the CMS standard with Russian cryptography is implemented in the Open Source OpenSSL application.
Our company supported CMS with Russian cryptography in the Rutoken Plug- in product . Rutoken plugin is intended for use in browsers, all cryptographic operations are performed in hardware, "on board" a USB token.