GM/T 0125.3-2022JavaScript Object Notation Web cryptographic application syntax specification—Part 3:Data encryption (English PDF)

3.1 Authenticated encryption with associated data; AEAD

Encryption of plaintext, which can specify additional authenticated data and provide integrity verification for ciphertext and additional authenticated data.

NOTE. the algorithm using this mechanism is also called AEAD algorithm. AEAD algorithm accepts two inputs, plaintext and additional authenticated data, and produces two outputs, which are respectively ciphertext and authentication tag.

3.2 Additional authenticated data; AAD

Input of AEAD algorithm, which is data that is integrity protected but not encrypted.

3.3 Authentication tag

Output of AEAD algorithm, which is used to ensure the integrity of ciphertext and additional authenticated data.

3.4 Content encryption key; CEK

Symmetric key of AEAD algorithm, which is used to encrypt plaintext to produce ciphertext and authentication tag.

3.5 JWE encrypted key

The ciphertext value obtained after encrypting CEK using key-encrypted key algorithm.

3.6 JWE initialization vector

The initialization vector value used by the encryption algorithm.

3.7 JWE AAD

Additional authenticated data of the JWE data structure, which only exists in JSON serialization.

3.8 JWE ciphertext

The ciphertext part of the output of the content encryption algorithm.

3.9 JWE authentication tag

The tag part of the output of the content encryption algorithm, which is used to ensure the integrity of the JWE ciphertext and JWE additional authenticated data.

3.10 JWE protected header

JSON object, which contains integrity-protected header parameters. The integrity of these header parameters is protected by authenticating encryption operations.

NOTE. these parameters apply to all recipients of the JWE. For JWE compact serialization, it contains the entire JOSE header. For JWE JSON serialization, it is part of the JOSE header.

3.11 JWE shared unprotected header

JSON object, which contains header parameters that are not integrity protected.

NOTE. these parameters apply to all recipients of JWE and are not integrity protected. They exist when using JWE JSON serialization.

3.12 JWE per-recipient unprotected header

JSON object, which contains header parameters that are not integrity protected. They are unique parameters to each recipient of JWE.

NOTE. these header parameter values are not integrity protected. They exist when using JWE JSON serialization.

3.13 JWE compact serialization

Serialization represented by JWE using a compact URL-safe character string form.

3.14 JWE JSON serialization

Serialization represented by JWE using a JSON structure.

NOTE. unlike JWE compact serialization, JSON serialization can support multiple recipients.

3.15 Key encryption

The process of encrypting a key.

NOTE. the key here generally refers to the content encryption key CEK.

6.1 Overview

JWE is a data structure that uses the mode of JSON to represent data encryption.

JWE consists of JOSE header, JWE key ciphertext, JWE initialization vector, JWE additional authenticated data, JWE ciphertext and JWE authentication tag.

JWE encryption is divided into two serialization formats. compact serialization and JSON serialization. Compact serialization only supports one encrypted recipient, and JSON serialization can support one or more encrypted recipient.

JWE uses AEAD algorithm to ensure the confidentiality and integrity of plaintext messages and the integrity of JWE protected header and JWE additional authenticated data. First, specify or generate CEK, use the encryption algorithm with integrity verification to encrypt the plaintext algorithm. This header parameter is required, and its value shall comply with GM/T 0125.1.If the value of "alg" is an unsupported algorithm, or the recipient does not have a key that can be used with that algorithm, then, the encrypted content is unusable.

The value of "alg" is an ASCII character string, which is case-sensitive. If a key-encrypted key algorithm is used, this header parameter is required.

6.2.2.3 "enc" (encryption algorithm) header parameter the "enc" header parameter is used to identify the content encryption algorithm used. The value of this header parameter shall comply with GM/T 0125.1.If the value of "enc" is an unsupported algorithm, then, the encrypted content is unusable.

The value of "enc" is an ASCII character string, which is case-sensitive, and this header parameter is required.

6.2.2.4 "jku" (JWK Set URL) header parameter the "jku" header parameter is a URI character string that references a set of JSON-structured public keys, where the private key corresponding to each public key is used to digitally sign the JWS. The public key shall be encoded in the JWK set format. This header parameter is optional and shall be set as a protected header parameter.

6.2.2.5 "jwk" (JSON Web Key) header parameter the "jwk" header parameter is a JSON object which is used to identify the public key for JWE encryption or to determine the private key for decryption. This header parameter is optional, and its value shall comply with GM/T 0125.4.

6.2.2.6 "kid" (key ID) header parameter the "kid" header parameter is used to identify the public key for JWE encryption or the private key for decryption. This header parameter is optional, and its value is expressed as a character string, which is case-sensitive. When used with JWK, the "kid" value is used to match the "kid" parameter value of the JWK.

6.2.2.7 "x5u" (certificate URL) header parameter the "x5u" header parameter is used to identify the encryption certificate URL associated with the key-encrypted key. Its value is a character string in the form of URI. The resource shall provide a representation of the certificate or certificate chain in the form of PEM encoding, with each certificate separated by the following delimiters.

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----the first certificate shall be the encryption certificate associated with JWE key-encrypted key.

This document can be extended to define new header parameters. To prevent conflicts, it is forbidden to duplicate newly defined header parameter names with already defined header names. New header parameters shall be introduced with caution to avoid causing non-interoperability between JWS.

6.2.4 User-defined header parameters

The two parties of JWS application can agree on interoperable header parameter names. Unlike defined parameter names, self-defined header parameter names of different applications may conflict and shall be used with caution.

7.1 Overview

The JWE key-encrypted key algorithm is an algorithm used to encrypt or decrypt CEK. The algorithm is identified by the "alg" header parameter of the JOSE header, and the identifier value shall comply with GM/T 0125.1.

This document specifies the implementation requirements for the two key-encrypted key algorithms. SM2 public key encryption and SM9 encryption.

7.2 SM2 Public Key Encryption Algorithm

This Chapter describes the relevant requirements for the SM2 public key encryption algorithm.

The encryption and decryption calculation method of the SM2 public key encryption algorithm shall comply with GB/T 32918, and the specified hash algorithm is the SM3 algorithm. The calculation method and steps of the SM3 hash algorithm shall comply with GB/T 32905.

The output data format of the encryption result of this algorithm shall comply with GB/T 35276.

The value of the JWE key ciphertext is the output of the encryption result.

7.3 SM9 Encryption Algorithm

This Chapter describes the relevant requirements for the SM9 encryption algorithm.

The encryption and decryption process of the SM9 encryption algorithm shall comply with GB/T 38635.The specified hash algorithm is the SM3 algorithm, and the calculation method and steps of the SM3 hash algorithm shall comply with GB/T 32905.The specified key length of the message authentication code function is 256 bits.

The output data format of the encryption result of this algorithm shall comply with GM/T 0080.

The value of the JWE key ciphertext is the output of the encryption result.

k) If JSON serialization is used and the application sets the additional authenticated data value A1, set the content encryption algorithm authenticated data A to. ASCII (JWE protected header encoding)||'.'||base64url (additional authenticated data A1 set by the application), otherwise, set the additional authenticated data A of the content encryption algorithm to. ASCII (JWE protected header encoding).

l) If the "zip" header parameter is set, in accordance with the zip algorithm, zip the plaintext message M to generate the zipped data MZ. Set the plaintext message M to MZ.

m) In accordance with the content encryption algorithm, use CEK, JWE initialization vector IV and additional authenticated data A to encrypt the plaintext message M, and output the JWE ciphertext and JWE tag.

n) Output the serialization result.

1) The compact serialization result is the following concatenated character string base64url (UTF8 (JWE protected header)) || '.' || base64url (JWE key ciphertext)||'.'||base64url (JWE initialization vector)||'.'||base64url (JWE ciphertext)||'.'||base64url (JWE tag);

2) See 12.3 for the JSON serialization result.

See Appendix A for an example of message encryption.

9.3 Message Decryption Process

The message decryption process is the reverse of the encryption process. If any of the steps fails, then, decryption fails.

When there are multiple recipients, it is up to the application program to decide which recipient's encrypted content will accept the JWE after successful decryption. In some cases, the JWE is valid only when all recipients' encrypted content can be successfully decrypted and verified, otherwise it is considered invalid. In other cases, the JWE is accepted as long as the encrypted content of a per-recipient is successfully decrypted and verified.

In order to obtain the decrypted plaintext M, the decryption process is as follows.

a) If JWE compact serialization is used, use the '.' delimiter to parse the JWE protected header, JWE key ciphertext, JWE initialization vector, JWE ciphertext and JWE tag in order. If parsing fails, then, decryption fails.

b) If JWE JSON serialization is used, parse as described in 12.3.

c) Verify whether using base64url to decode the JWE protected header, JWE key ciphertext, JWE initialization vector, JWE ciphertext, JWE tag and JWE additional authenticated data is successful. If decoding fails, then, decryption fails.

d) Verify whether the JWE protected header complies with UTF-8 encoding. If verification fails, then, decryption fails.

e) If compact serialization is used, use the JWE protected header as the JOSE header. If JWE JSON serialization is used, use the union set of the JWE protected header, JWE shared unprotected header and the corresponding JWE per-recipient unprotected header parameters as the JOSE header for each recipient. All of these headers shall be fully valid JSON objects. JOSE header parameter names cannot be repeated. If there are repeated header parameters, then, decryption fails.

f) If the JOSE header uses the "crit" header parameter value, in accordance with the parameter value definition, perform the corresponding processing.

g) Get the "enc" header parameter from the JOSE header and determine the content encryption algorithm.

h) Get the "alg" header parameter from the JOSE header to determine the key-encrypted key algorithm.

i) Get the user-related key and identifier information from the JOSE header.

j) In accordance with the key-encrypted key algorithm, decrypt the JWE key ciphertext to obtain the CEK. The length of the CEK shall meet the length required by the content encryption algorithm. When there are multiple recipients, each recipient decrypts its own corresponding JWE key ciphertext.

k) If JWE JSON serialization is being used, repeat this process [steps h) ~ j)].

l) Calculate the protected header encoding value as base64url [UTF8 (JWE protected header)]. If the JWE protected header does not exist, set it to an empty string.

m) Set the additional authenticated data input of the content encryption algorithm to.

ASCII (protected header encoding value). If JSON serialization is used and there is a JWE additional authenticated data value, the additional authenticated data input of the algorithm is set to. ASCII (protected header encoding value)||'.'||base64url (JWE additional authenticated data).

n) In accordance with the content encryption algorithm, use CEK, JWE initialization vector, JWE additional authenticated data and JWE tag as algorithm input parameters to decrypt the JWE ciphertext, output the decrypted plaintext M and verify the JWE tag. If the JWE tag verification is incorrect, then, the decryption fails.

o) If "zip" exists in the protected header, in accordance with the zig algorithm, unzip the decrypted plaintext M and generate the unzipped plaintext.

p) When there is no recipient who successfully decrypts, JWE shall be considered invalid.

12.1 Overview

JWE has two data representation forms, which are respectively compact serialization and JSON serialization. Compact serialization only supports one encrypted recipient, while JSON serialization can support one or more encrypted recipient.

12.2 Compact Serialization

JWE compact serialization represents encrypted content as a compact URL-safe character string.

Its general form is as follows.

base64url (UTF8 (JWE protected header))||'.'|| base64url (JWE key ciphertext)||'.'|| base64url (JWE initialization vector)||'.'|| base64url (JWE ciphertext)||'.'|| base64url (JWE tag) JWE compact serialization only supports one recipient and does not use JWE shared Appendix A (informative) JWE Examples A.1 Overview in this Appendix, all integers involved are in big-endian format.

In this Appendix, plaintext is encoded in UTF-8.

In this Appendix, random keys are represented by hexadecimal values.

In this Appendix, in order to verify the correctness of the example, the original text of the recipient's SM2 private key is given and represented by base64url encoding. In practical application, the recipient's key is generated by the cryptographic module and stored in the cryptographic module.

A.2 JWE Serialization Example Based on "SGD_SM2_3" and "SGD_SM4_CCM" A.2.1 Overview this example demonstrates the JWE generation process and output using the "SGD_SM2_3" algorithm to encrypt the key, "x5t#sm3" to identify the certificate, and "SGD_SM4_CCM" to encrypt the message content.

This example does not use additional authenticated data (compact serialization does not support the input of additional authenticated data).

A.2.2 Input parameters the input parameters include the following contents.

a) Data M to be encrypted. message encryption Hexadecimal representation. 6D65737361676520656E6372797074696F6E

b) Encryption key algorithm. "SGD_SM2_3"

c) Content encryption algorithm. "SGD_SM4_CCM"

d) Recipient's SM2 key.

Use the following JWK format to represent.