As a recent project needs to implement SM2 cryptographic algorithm encryption and signature message data encapsulation according to the specifications of the National Cryptography Bureau (GM/T 0010), it took some time to conduct the next research, and it is now in the text~(^_−)☆ Next, I will introduce the message syntax specification of the sm2 algorithm. As for how to implement the encapsulation of message data through the gmssl library, the editor will explain one by one in the following articles. OK, go to the topic~
First of all, we know that PKCS#7 stipulates 6 kinds of data content: plain text data (Data), signed data (Signed-data), digital envelope data (Enveloped-data), digital envelope data with signature (Signed-and-enveloped- data), Digested-data, Encrypted-data. (If you are interested, you can also take a look at rfc2315 ( https://tools.ietf.org/html/rfc2315 ), the full English documentation (*^▽^*) )
Similarly, the State Secret Bureau defined these 6 types with reference to the p7 specification (see GM/T 0010 specification http://www.doc88.com/p-7965091429139.html for details ). What is the difference between the 6 data types defined in the national secret code and the international standards? (•ิ_•ิ)?
In fact, the difference is not very big, they are all encapsulated in the pkcs7 structure (international standard message data encapsulation is realized through the pkcs7 module in openssl, while the national secret standard message data encapsulation is realized through the pkcs7 module in gmssl, GmSSL (http :// gmssl.org ) is a branch of OpenSSL that supports national encryption algorithms and standards). Then let's talk about the 6 types in the GM/T 0010 specification and the difference with RFC.
1. Type identifier definition
The various types of identifiers in the RFC are defined as follows:
| Object identifier OID | Object identifier definition | GmSSL/OpenSSL中NID |
|---|---|---|
| 1.2.840.113549.1.7.1 | Data type | NID_pkcs7_data |
| 1.2.840.113549.1.7.2 | Signature data type signedData | NID_pkcs7_signed |
| 1.2.840.113549.1.7.3 | EnvelopedData | NID_pkcs7_enveloped |
| 1.2.840.113549.1.7.4 | Signature and digital envelope data type signedAndEnvelopedData | NID_pkcs7_signedAndEnveloped |
| 1.2.840.113549.1.7.5 | DigestData | NID_pkcs7_digest |
| 1.2.840.113549.1.7.6 | Encrypted data type encryptedData | NID_pkcs7_encrypted |
The definition of each type of GM/T 0010 is shown in the following table:
| Object identifier OID | Object identifier definition | GmSSL/OpenSSL中NID |
|---|---|---|
| 1.2.156.10197.6.1.4.2 | SM2 cryptographic algorithm encryption signature message syntax specification | no |
| 1.2.156.10197.6.1.4.2.1 | Data type | no |
| 1.2.156.10197.6.1.4.2.2 | Signature data type signedData | no |
| 1.2.156.10197.6.1.4.2.3 | EnvelopedData | no |
| 1.2.156.10197.6.1.4.2.4 | Signature and data envelope data type signedAndEnvelopedData | no |
| 1.2.156.10197.6.1.4.2.5 | Encrypted data type encrypedData | no |
| 1.2.156.10197.6.1.4.2.6 | Key agreement type keyAgreementInfo | no
|
Compared with the RFC specification, there is no digest data type in the GM/T 0010 specification, and a key agreement type is added. And currently the gmssl/openssl library does not support the various types of identifiers in the GM/T 0010 specification ( note, the editor uses gmssl version 2.4.2 ). This is also one of the problems that we need to solve when we encode and construct the data of the national secret message grammar specification.
1. Basic type definition
Version
The Version type indicates the syntax version number.
Version ::= INTEGERContentEncryptionAlgorithmIdentifier
The ContentEncryptionAlgorithmIdentifier type indicates a data encryption algorithm. Its OID sees the GM/T0006 standard.
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifierFor example, the related OIDs of the SM4 algorithm defined in the gmssl library are as follows:
NID_sms4_ecb, / * OBJ_sms4_ecb 1 2 156 10197 1 104 1 * /
NID_sms4_cbc, / * OBJ_sms4_cbc 1 2 156 10197 1 104 2 * /
NID_sms4_ofb128, / * OBJ_sms4_ofb128 1 2 156 10197
110 3/4 OBJ_s 156 * 10197 1 104 4 * /
NID_sms4_cfb1, / * OBJ_sms4_cfb1 1 2 156 10197 1 104 5 * /
NID_sms4_cfb8, / * OBJ_sms4_cfb8 1 2 156 10197 1 104 6 * /
NID_sms4_ctr, / * OBJ_sms4_ID 10401_
N 104_ID / * OBJ_sms4_gcm 1 2 156 10197 1 104 8 * /
Nid_sms4_chchm, / * Obrj_sms4_ccm 1 2 156 10197 1 104 9 * /
Nid_sms4_cshts, / * Obrj_sms4_xts 1 2 156 10197 1 104 10 * /
Nid_sms4_wrap, / * Obrj_sms4_wrap 1 2 156 10197 1 104 11 * /
Nid_sms4_wrap_pd, / * Obrj_sms4_wrap_pd 1 2156 10197 1 104 12 * /
NID_sms4_ocb, / * OBJ_sms4_ocb 1 2 156 10197 1 104 100 * /
DigestAlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies the message digest algorithm . It is the SM3 algorithm in the GM/T0010 standard, and its OID is: 1.2.156.10197.1.401
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
DigestEncryptionAlgorithmIdentifier
The DigestEncryptionAlgorithmIdentifier type indicates a signature algorithm , which is SM2-1 digital signature algorithm in the GM/T0010 standard, and its OID is: 1.2.156.10197.1.301.1
DigestEncryptionAlgorithmIdentifier ::= AlgorithmIdentifierExtendedCertificatesAndCertificates
The ExtendedCertificatesAndCertificate type specifies a PKCS#6 extended certificate or an X.509 certificate. For this type, see the syntax recommended in section 6 of PKCS#6:
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate
}
IssuerAndSerialNumber
The IssuerAndSerialNumber type indicates the distinguished name of a certificate issuer and the issuer's certificate serial number, which can be used to determine a certificate and the entity and public key corresponding to the certificate.
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber
}ContentInfo
The ContentInfo type indicates the general grammatical structure of content exchange between entities, and is defined as follows:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
}
ContentType ::= OBJECT IDENTIFIERamong them:
ContentType content type. It is an object identifier, which means that it is a unique integer string assigned by the authority that defines the content type. That is, the object identifiers corresponding to the six content types: data, signedData, envelopedData, signedAndEnvelopedData, digestddata, and encryptedData. (The message syntax specification for SM2 algorithm is each type of identifier OID defined in GM/T 0010)
content content, optional
CertificateRevocationLists
The CertificateRevocationLists type indicates a collection of certificate revocation lists. Its purpose is to let the collection contain enough information to determine whether the certificate associated with the collection is still valid.
CertificateRevocationLists ::= SET OF CertificateRevocationList
2. Plaintext data type data
The data type structure is defined as follows:
Data ::= OCTET STRINGThe Data data type identifies arbitrary character strings, such as ASCII text files. In other words, such strings do not need to have any internal structure (of course they can also), they may even be DER encoded data. This type is the same as defined in rfc2315.
3. Signature data type signedData
The signedData data type consists of a number of any type and the signature value of at least one signer. Any type of data can be signed by any number of signers at the same time. The structure of the signedData data type is defined as follows:
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates[0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
crls[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos
}
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfoSee the table below for the meaning of each item in the structure
| Field Name | type of data | Explanation | Remarks |
|---|---|---|---|
| version | Version | Grammar version number | The version number in the RFC2315 v1.5 specification is 1 |
| digestAlgorithms | DigestAlgorithmIdentifiers | A collection of message digest algorithm identifiers | Can contain any number of elements, including 0. Each element identifies a message digest algorithm (and any corresponding parameters) |
| contentInfo | ContentInfo | The content of the signed data, see GM/T 0009 for the data type | In the GM/T 0010 specification, the field type is written as SM2Signature, but according to the definition in the GM/T 0009 specification, SM2Signature is the data type of the signature result, which does not match the content of the signed data stated in the meaning of the field, and the signature The value will be recorded in signerInfos. (The editor boldly guessed that the specification writer made a careless mistake (ー△ー;), it should be of type ContentInfo, that is, the original signature data) |
| certificates | ExtendedCertificatesAndCertificates | Collection of PKCS#6 extended certificate and X.509 certificate | For signed data, the signer’s certificate can be stored here |
| crls | CertificateRevocationLists | Collection of certificate revocation lists | The revocation list can be used to determine whether the certificate in the certificates domain is "hot listed", but it is not required. |
| signerInfos | SignerInfo collection | Collection of information for each signer |
The definition of the signer information structure defined by the National Secret Specification is consistent with the RFC. Only the meaning of some fields is ambiguous ( note the red part )
3.1, SignerInfo type
The SignerInfo structure is defined as follows:
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes[1] IMPLICIT Attributes OPTIONAL
}
EncryptedDigest ::= OCTET STRINGSee the table below for the meaning of each item in the structure
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar. (The version number in the RFC2315 v1.5 specification is 1) |
| issuerAndSerialNumber | IssuerAndSerialNumber | The distinguished name of a certificate issuer and the certificate serial number determined by the issuer can be used to determine a certificate and the entity and public key corresponding to the certificate. |
| digestAlgorithm | DigestAlgorithmIdentifier | The message digest algorithm for digesting the content, the SM3 algorithm is used in the GM/T 0010 specification |
| authenticatedAttributes[0] | Attributes | It is a collection of attributes signed by the signer. This field is optional. If the domain exists, the method of summarizing in the domain is to calculate the result of the summary of the original text |
| digestEncryptionAlgorithm | DigestEncryptionAlgorithmIdentifier | SM2-1 elliptic curve digital signature algorithm identifier |
| encryptedDigest | OCTET STRING | Signature result. Note that the GM/T0010 specification states that this value is SM2Signature. The encoding format is r||s. According to pkcs#7, the data entered should be SM2Signature signature value structure data after DER encoding |
| unauthenticatedAttributes | Attributes | Collection of unsigned attributes |
The definition of the signer information structure defined by the National Secret Specification is consistent with the RFC. It's just that the meaning of some fields is somewhat different ( note the red part )
4. EnvelopedData
The envelopedData data type of the digital envelope consists of encrypted data and a ciphertext of at least one recipient's data encryption key. The encrypted data is encrypted with a data encryption key, and the data encryption key is encrypted with the recipient's public key .
This type is used to make digital envelopes for the recipient's data, digestData or signedData.
The envelopedData data type structure is defined as follows:
EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo
}
RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent[0] IMPLICIT EncryptedContent OPTIONAL,
sharedInfo[1] IMPLICIT OCTET STRING OPTIONAL,
sharedInfo[2] IMPLICIT OCTET STRING OPTIONAL
}
EncryptedContent ::= OCTET STRINGThe meaning of each item in the envelopedData structure is shown in the table below
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar, (the version number in the RFC2315 v1.5 specification is 0) |
| recipientInfos | RecipientInfos | For each collection of recipient information, there must be at least one recipient. |
| encryptedContentInfo | EncryptedContentInfo | Encrypted content information |
The meanings of the encryptedContentInfo structure are shown in the following table
| Field Name | type of data | meaning |
|---|---|---|
| contentType | ContentType | Type of content |
| contentEncryptionAlgorithm | ContentEncryptionAlgorithm | Content encryption algorithm (and related parameters) |
| encryptedContent | EncryptedContent | Content encryption result, optional. If the field does not exist, its expected value must be provided by other means. The data to be filled in is the DER-encoded data of the ciphertext protection structure defined by the national secret code |
| sharedInfo | OCTET STRING | Negotiated shared information, optional |
| sharedInfo | OCTET STRING | Negotiated shared information, optional |
Compared with the RFC specification, the digital envelope structure defined in the National Secret Specification has two new fields for storing negotiated shared information.
4.1, RecipientInfo type
Each recipient information is represented by the RecipientInfo type, and its type structure is defined as follows:
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey
}
EncryptedKey ::= OCTET STRINGSee the table below for the meaning of each item in the structure
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar. (The version number in the RFC2315 v1.5 specification is 0) |
| issuerAndSerialNumber | IssuerAndSerialNumber | The distinguished name of a certificate issuer and the certificate serial number determined by the issuer can be used to determine a certificate and the entity and public key corresponding to the certificate |
| keyEncryptionAlgorithm | KeyEncryptionAlgorithmIdentifier | The algorithm for encrypting the data encryption key with the receiver’s public key is SM2-3 elliptic curve encryption algorithm |
| encryptedKey | EncryptedKey | Data encryption key cipher text SM2Cipher, see GM/T 0009 for its definition. Fill in the data should be SM2Cipher structure data after DER encoding |
The definition of the receiver information type structure is similar to that in the RFC. It's just that the meaning of some fields is somewhat different ( note the red part )
5. Signature and digital envelope data type signedAndEnvelpedData
The signedAndEnvelopedData data type consists of any type of encrypted data, at least one recipient’s data encryption key, and at least one signer’s signature. Its structure is defined as follows:
SignedAndEnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
digestAlgorithms DigestAlgorithmIdentifiers,
encryptedContentInfo EncryptedContentInfo,
certificates[0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
crls[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos
}See the table below for the meaning of each item in the structure
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar. (The version number in the RFC2315 v1.5 specification is 1) |
| recipientInfos | RecipientInfos | A collection of information for each recipient, at least one element |
| digestAlgorithms | DigestAlgorithmIdentifiers | A collection of message digest algorithm identifiers |
| encryptedContentInfo | EncryptedContentInfo | The encrypted content can be any defined data type |
| certificates | ExtendedCertificatesAndCertificates | PKCS#6 extended certificate or a collection of X.509 certificates, optional |
| crls | CertificateRevocationLists | Collection of certificate revocation lists |
| signerInfos | SignerInfos | Each signer's collection must have at least one element |
The signature and digital envelope type structure defined by the National Secret Specification are the same as in the RFC.
6. Encrypted data type encryptedData
The encryptedData data type consists of any type of encrypted data, and the data type has neither the recipient nor the encrypted data encryption key. Its structure is defined as follows:
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo
}See the table below for the meaning of each item in the structure
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar. (The version number in the RFC2315 v1.5 specification is 0) |
| encryptedContentInfo | EncryptedContentInfo | Encrypted content information |
The structure of this type in the National Secret Specification is consistent with that in the RFC.
7. Key agreement type keyAgreementInfo
The key agreement data type indicates the structure of establishing a shared secret key between two users. In this way, the value of a shared secret key can be determined.
This type is used for public parameter exchange between two users to generate a shared secret key.
KeyAgreementInfo ::= SEQUENCE {
version Version(1),
tempPublicKeyR SM2PublicKey,
userCertificate Certificate,
userID OCTET STRING
}See the table below for the meaning of each item in the structure
| Field Name | type of data | meaning |
|---|---|---|
| version | Version | The version number of the grammar. |
| tempPublicKeyR | SM2PublicKey | Temporary public key, see GM/T 0006 for structure definition |
| userCertificate | Certificate | User certificate |
| userID | OCTET STRING | User ID |
OK, GM/T 0010 specification analysis is introduced here, and the following article will talk about how to construct the message data of the SM2 algorithm. . . . . . . . . . (((┏(;￣▽￣)┛ run away after loading