GM/T 0130-2023 PDF English
Search result: GM/T 0130-2023
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GM/T 0130-2023 | English | 440 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Certificateless and implicit-certificate-based public key mechanisms based on the SM2 algorithms
| Valid |
GM/T 0130-2023: PDF in English (GMT 0130-2023) GM/T 0130-2023
GM
CRIPTOGRAPHIC INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 35.030
CCS L 80
Certificateless and implicit-certificate-based public key
mechanisms based on the SM2 algorithms
ISSUED ON: DECEMBER 04, 2023
IMPLEMENTED ON: JUNE 01, 2024
Issued by: State Cryptography Administration
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 6
4 Symbols and abbreviations ... 7
4.1 Symbols ... 7
4.2 Abbreviations ... 9
5 Mechanism parameters and auxiliary functions ... 10
5.1 Overview ... 10
5.2 Elliptic curve system parameters ... 10
5.3 Auxiliary functions ... 11
5.4 User identification information ... 12
6 Key generation mechanism and process ... 12
6.1 Master key generation mechanism ... 12
6.2 User key pair generation mechanism ... 12
6.3 User key pair generation process ... 13
6.4 User key pair verification mechanism ... 14
6.5 User key pair verification process ... 15
7 Digital signature mechanism ... 16
7.1 Digital signature generation mechanism ... 16
7.2 Verification mechanism of digital signature ... 16
8 Public key encryption mechanism ... 16
8.1 Encryption mechanism ... 16
8.2 Decryption mechanism ... 17
Appendix A (Informative) Mechanism data example ... 18
Appendix B (Informative) Application example of mechanism in implicit certificate
application ... 26
Appendix C (Informative) Application example of the mechanism in the industrial
Internet identity resolution system ... 31
Appendix D (Informative) Deterministic generation method of user key of key
generation center ... 35
References ... 36
Certificateless and implicit-certificate-based public key
mechanisms based on the SM2 algorithms
1 Scope
This document specifies the certificateless and implicit certificate public key
mechanism based on the SM2 algorithm, including key generation and verification
mechanism, digital signature mechanism, public key encryption mechanism.
The digital signature mechanism specified in this document is applicable to digital
signatures and verification in commercial cryptographic applications; the encryption
mechanism is applicable to message encryption and decryption in commercial
cryptographic applications. The mechanism specified in this document is particularly
suitable for application environments with limited bandwidth and computing resources.
2 Normative references
The contents of the following documents constitute the essential terms of this document
through normative references in the text. Among them, for dated references, only the
version corresponding to that date applies to this document; for undated references, the
latest version (including all amendments) applies to this document.
GB/T 32918.1-2016 Information security technology - Public key cryptographic
algorithm SM2 based on elliptic curves - Part 1: General
GB/T 32918.2-2016 Information security technology - Public key cryptographic
algorithm SM2 based on elliptic curves - Part 2: Digital signature algorithm
GB/T 32918.4-2016 Information security technology - Public key cryptographic
algorithm SM2 based on elliptic curves - Part 4: Public key encryption algorithm
GB/T 32918.5-2017 Information security technology - Public key cryptographic
algorithm SM2 based on elliptic curves - Part 5: Parameter definition
GB/T 32905 Information security techniques - SM3 cryptographic hash algorithm
GB/T 32915 Information security technology - Randomness test methods for binary
sequence
UA: Partial public key generated by user A
a, b: Elements in Fq, which define an elliptic curve E on Fq
x‖y: Concatenation of x and y, where x and y can be bit strings or byte strings
xG, yG: The x-axis value and y-axis value of point G
[x]: Top function, the smallest integer not less than x. For example, [7] = 7, [8.3] =
(r, s): Sent signature
(r', s'): Received signature
[k]P: k-times point of the point P on the elliptic curve, that is, [k]P = (P + P + ... +
P)/k, where k is a positive integer
ENC (param, M, PA): Public key encryption algorithm, which uses the elliptic curve
system parameters param and public key PA to encrypt the message M
DEC (param, C, dA): Public key decryption algorithm, which uses the elliptic curve
system parameters param and private key dA to decrypt the ciphertext C
SIGN (param, ZA, M, dA): Digital signature generation algorithm, which uses the
elliptic curve system parameters param, hash value ZA, private key dA to sign the
message M and output (r, s)
VERIFY (param, ZA, PA, M', (r', s')): Digital signature verification algorithm, which
uses the elliptic curve system parameters param, hash value ZA, public key PA to
verify the signature (r', s') of message M' and output the correctness of the signature
4.2 Abbreviations
The following abbreviations apply to this document.
CA: Certificate Authority
COER: Canonical Octet Encoding Rules
GHR: Global Handle Registry
KGC: Key Generation Center
LHS: Local Handle Service
5 Mechanism parameters and auxiliary functions
5.1 Overview
The public key mechanism specified in this document includes key generation and
verification mechanism, digital signature mechanism, public key encryption
mechanism. Among them, the key generation and verification mechanism includes the
generation mechanism of the master key and the generation and verification mechanism
and process of the user key pair. The master key is generated by KGC, including the
system master private key and the system master public key. The user's private key and
declared public key are jointly generated by KGC and the user. The user discloses his
user identity and declared public key; his actual public key is calculated and generated
by the elliptic curve system parameters, the system master public key, the user identity,
the user's declared public key according to the method specified in this document.
The key generation mechanism specified in this document is a mechanism that can be
used to generate the key data required in the implicit certificate application. The key
data includes the CA's key pair, the user's public key recovery data and the private key.
The verification mechanism can be used to verify the correctness of the user's public
key recovery data and private key in the implicit certificate. Implicit certificates are
used to distribute user identities, public key recovery data, etc.
The digital signature mechanism and public key encryption mechanism without
certificates and based on implicit certificates are constructed, based on the standard
basic digital signature algorithm (SIGN and VERIFY) and basic public key encryption
algorithm (ENC and DEC), respectively. This document specifies that the basic digital
signature algorithm and basic public key encryption algorithm are the SM2 elliptic
curve public key cryptography algorithm specified in GB/T 32918.2-2016 and GB/T
32918.4-2016. The digital signature mechanism specified in this document can realize
the digital signature and verification of messages. The public key encryption
mechanism specified in this document can realize the encryption and decryption of
messages. The data examples of the specified mechanism are shown in Appendix A.
The format of the user identifier in the certificateless public key mechanism can refer
to GM/T 0090. The format and encoding method of the implicit certificate and the
correspondence between the implicit certificate content and the entity identifier in this
document are not within the scope of this document. The application reference
examples of the implicit certificate public key mechanism and the certificateless public
key mechanism are shown in Appendix B and Appendix C, respectively.
5.2 Elliptic curve system parameters
The elliptic curve system parameters include the scale q of the finite field Fq (when q =
5.4 User identification information
User A has an identification IDA of length entlenA bits, where ENTLA is two bytes
converted from the integer entlenA. The KGC of the key generation mechanism
specified in this document, the signer and verifier of the digital signature mechanism,
the sender in the public key encryption mechanism all use a cryptographic hash
algorithm, to obtain the hash value HA of user A. According to the method given in
4.2.6 and 4.2.5 of GB/T 32918.1-2016, the data types of the coordinates xG, yG of the
elliptic curve equation parameters a, b, G and the coordinates xPub, yPub of Ppub are
converted into bit strings, to calculate HA = H256 (ENTLA‖IDA‖a‖b‖xG‖yG‖
xPub‖yPub).
6 Key generation mechanism and process
6.1 Master key generation mechanism
KGC uses the random number ms∈[1, n - 1] as the system master private key, to
calculate the system master public key Ppub = [ms]G.
KGC shall take necessary security measures to ensure the security of the master private
key ms.
Note: In the implicit certificate system, ms and Ppub are the signature private key and signature
public key of the CA, respectively.
6.2 User key pair generation mechanism
User A and KGC work together to generate the user's key pair: User private key dA and
declaration public key WA. Both shall implement the following operation steps:
A1: User A generates a random number d'A∈[1, n - 1] using a random number
generator;
A2: User A calculates UA = [d'A]G and submits the identifiers IDA and UA to KGC;
KGC1: KGC calculates HA = H256(ENTLA‖IDA‖a‖b‖xG‖yG‖xPub‖yPub);
KGC2: KGC generates a random number w∈[1, n - 1] using a random number
generator;
KGC3: KGC calculates WA = [w]G + UA;
KGC4: KGC converts the data types of WA coordinates xWA and yWA into bit strings
7 Digital signature mechanism
7.1 Digital signature generation mechanism
Let the message to be signed be M. In order to obtain the digital signature (r, s) of
message M, user A as the signer shall implement the following operation steps.
A1: In the certificateless system, according to the method given in 4.2.6 and 4.2.5 of
GB/T 32918.1-2016, the data type of the coordinates xWA and yWA of WA is
converted into a bit string; SIGN (param, HA, xWA‖yWA‖M, dA) is executed and
the signature (r, s) is output. In the implicit certificate system, SIGN (param, ZE,
ICA‖M, dA) is executed and the signature (r, s) is output, where ZE is an empty
string.
7.2 Verification mechanism of digital signature
In order to verify the received message M' and its digital signature (r's'), user B as the
verifier shall implement the following operation steps:
B1: Calculate HA = H256(ENTLA‖IDA‖a‖b‖xG‖yG‖xPub‖yPub);
B2: Convert the data types of coordinates xWA and yWA of WA into bit strings
according to the methods given in 4.2.6 and 4.2.5 of GB/T 32918.1-2016, calculate
λ = H256(xWA‖yWA‖HA) mod n; convert the data type of λ into an integer according
to the methods given in 4.2.4 and 4.2.3 of GB/T 32918.1-2016;
B3: Calculate PA = WA + [λ]Ppub;
B4: In the certificateless system, execute VERIFY[param, HA, xWA‖yWA‖M', PA,
(r', s')] and output the result. In the implicit certificate system, execute VERIFY
[param, ZE, ICA‖M', PA, (r', s')] and output the result, where ZE is an empty string.
Note: The SM2 digital signature verification mechanism involves the point multiplication
calculation of the public key PA. If the mechanism implementation allows, the calculation of PA
in step B3 can be postponed to the digital signature verification stage and a fast method can be
used to calculate the sum of multiple point multiplications.
8 Public key encryption mechanism
8.1 Encryption mechanism
Let the message to be sent be a bit string M. In order to encrypt the plaintext M and
- canRequestRollover indicates that the certificate can be used to sign request
messages for another certificate with the same permissions;
- encryptionKey contains the public key used for encryption, and the certificate
holder holds the corresponding private key;
- verifyKeyIndicator contains public key recovery data that can be used to recover
the public key.
For specific data type definitions, see reference [6]. The certificate data is encoded using
the Regular Octet Encoding Rules (COER) [10].
B.3 Implicit certificate and key generation process
B.3.1 CA initialization
The CA performs the following process according to the master key generation
mechanism specified in 6.1, which is consistent with the system initialization process
of the standard CA.
a) CA generates the system private key ms; the system public key Ppub = [ms]G;
b) CA applies for a CA certificate from its root CA using [ms]G as its signature
public key.
The certificate application process in step b) is the standard certificate application
process; the generated certificate is the CA certificate issued by the root CA for the CA.
If there is no root CA, the CA can generate a self-signed CA certificate.
B.3.2 Correspondence between implicit certificate data and user identification
information IDA in the specification
The IDA in this document includes at least the data field from the id field to the
encryptionKey field in ToBeSignedCertificate. If the encryptionKey field exists and is
a common public key, IDA includes the data field; otherwise, IDA does not include the
data field. The encoding format of the data field included in IDA is consistent with the
encoding format of ToBeSignedCertificate. The order of the data fields included in IDA
is consistent with the order of the corresponding fields in ToBeSignedCertificate.
B.3.3 Application and generation of implicit certificates
The entity applies for an implicit certificate according to the user key pair generation
mechanism specified in 6.2 and performs the following process.
a) The entity executes steps A1 and A2 in 6.2, generates a random number d'A∈[1, n
- 1], calculates UA = [d'A]G.
b) The entity generates an implicit certificate application: including public key data
UA and other information; submits the implicit certificate application to the CA.
c) After the CA verifies the legitimacy of the implicit certificate application, it
generates the other parts of the implicit certificate, except the key
verifyKeyIndicator, that is, the part from id to encryptionKey. If the
encryptionKey field exists and is a common public key, the key is generated
according to the common key generation method. If the encryptionKey field
exists and is an encrypted public key of the implicit certificate type, the key is
generated according to the generation mechanism specified in 6.2. CA constructs
IDA according to the method of B.3.2; executes steps KGC1 ~ KGC5 in 6.2;
obtains tA and WA.
d) CA encodes WA as the data of the data field verifyKeyIndicator in the implicit
certificate, to generate a complete implicit certificate.
e) If the entity generates an encrypted public-private key pair (Q, c) during the
certificate application process and provides the encrypted public key Q in the
certificate application, tA and the implicit certificate are encrypted using the
public key Q to form the ciphertext C and then returned to the entity. If the entity
does not provide the encrypted public key Q, UA is used as the encrypted public
key to perform the encryption operation; the encrypted result is returned to the
entity.
f) The entity uses the decryption private key c (if Q = UA, then c = d'A) to decrypt
the ciphertext C returned in e), to obtain tA and the implicit certificate.
g) The entity performs steps A3 and A4 in 6.2, to calculate the complete signature
private key dA and obtain the declared public key WA from the data field
verifyKey-Indicator of the implicit certificate;
h) The entity verifies the legitimacy of the user key pair according to the steps
specified in 6.4; then verifies the legitimacy of the implicit certificate.
B.4 Process of signing message data using implicit certificate and private key
When it is necessary to sign message data, the entity performs data signature calculation
according to the digital signature process in the implicit certificate system specified in
7.1.
B.5 Process of verifying message signature using implicit certificate
The basic process of verifying message signature by the entity is as follows:
a) According to the method of B.3.2, IDA is formed according to the content of the
implicit certificate; the public key restoration data is extracted from
verifyKeyIndicator as WA; the public key [ms]G is extracted from the root
certificate of the CA as Ppub;
Appendix C
(Informative)
Application example of the mechanism in the industrial Internet identity
resolution system
C.1 Overview
This Appendix describes an application example of the certificateless public key
mechanism. The example describes a possible way, to use the key mechanism specified
in this document to generate a key pair in the industrial Internet identity resolution
system and use the digital signature mechanism to authenticate entities and protect the
security of identity resolution data. The content in this Appendix is for reference only.
The specific application specifications are specified separately by relevant standards.
C.2 Industrial Internet identity resolution system and related keys
The Industrial Internet Handle identity resolution system [7] manages Handles in the
Handle namespace and can be used for identity resolution in the industrial Internet. The
Handle system provides two types of services: Handle resolution service and Handle
management service. The Handle resolution process includes two main processes: 1)
Query the global Handle registration authority (GHR) to resolve the service information
of the naming authority in the Handle. 2) Query the local Handle service (LHS) based
on the result of process 1) to resolve the Handle value. The Handle management service
is used to create, update, delete Handle value records. The Handle system includes at
least three components:
a) Global Handle Registry (GHR): Manages and resolves the service information of
the local Handle service in the Handle mode of the naming authority;
b) Local Handle Service (LHS): Manages and resolves the Handle under its
responsible namespace in the Handle mode;
c) Client: Query or manage Handle and Handle value records.
According to the different access rights, the Handle value records in the Handle system
can be divided into two categories: public access Handle value records and controlled
access Handle value records. Public access Handle value records have no data
confidentiality requirements, but may have security requirements for data integrity and
data source authenticity. For example, the naming authority Handle value record
includes service site list information. The integrity of the information data and the
authenticity of the data source are critical to the security of the Handle system. When
querying or managing controlled access Handle value records that require additional
authorization, it is necessary to authenticate the identity of the client and authorize
according to the access control permission requirements. This type of controlled access
Handle value record may be sensitive; the operation process may also need to protect
the confidentiality and integrity of the data.
The Handle system has at least the following three types of keys:
a) GHR's public-private key pair: Used to provide data integrity and data source
authenticity for the naming authority Handle resolution;
b) LHS's public-private key pair: Used to provide data integrity and data source
authenticity for local Handle resolution;
c) Handle management key: Used for identity authentication when accessing
controlled access Handles, identity authentication during secure session
establishment, session key transfer, etc.
The GHR's public-private key pair is generated by the GHR management agency and
released to the public, through the Handle value of the < HS_SITE> type of Handle
"0.NA/0.NA". The LHS's public-private key pair is generated by the LHS management
agency. The LHS's public key is released to the public, through the Handle value of the
< HS_SITE> type of Handle "0.NA/LHSN.A." (such as "0.NA/10"); its format is the
same as the public key in the < HS_SITE> of the GHR. When the Handle client queries
the < HS_SITE>Handle value of "0.NA/10", it can request GHR to digitally sign the
query response. After receiving the query result, the client uses GHR's public key to
verify GHR's signature; if the signature is valid, it accepts LHS's public key.
Identity authentication is required when accessing a controlled Handle. The Handle
system uses the < HS_ADMIN> type Handle value, to define the management authority
of a Handle and the key Handle reference used for identity authentication. The data
field < AdminRef> in the < HS_ADMIN> type Handle value points to the Handle and
index of the Handle management key for client authentication.
C.3 Method for the global Handle registration authority to use the certificateless
digital signature mechanism
The public and private key pair of GHR can be generated using the key generation
mechanism and process specified in Chapter 6. The generation process uses GHR's
Handle "0.NA/0.NA" as IDA. According to the provisions of reference [8], the
generated declared public key WA can be published, through the < PublicKeyRecord>
data field in the < HS_SITE> record of the "0.NA/0.NA" Handle. Reference [7]
stipulates that the format of the < PublicKeyRecord> field is: < PublicKeyRecord> = 4-
byte integer | UTF8-encoded key type | 2 bytes reserved | public key data byte array.
When using the key generated by this document, the UTF8-encoded key type value is
the UTF-8-encoded algorithm identifier "ECS-SM2"; the public key data byte array is
the result value of WA encoded in the elliptic curve point encoding method specified in
GB/T 35276.
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
PDF Preview: GM/T 0130-2023
|