|
US$859.00 · In stock Delivery: <= 7 days. True-PDF full-copy in English will be manually translated and delivered via email. GB/T 17901.3-2021: Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 17901.3-2021 | English | 859 |
Add to Cart
|
7 days [Need to translate]
|
Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques
| Valid |
GB/T 17901.3-2021
|
PDF similar to GB/T 17901.3-2021
Basic data | Standard ID | GB/T 17901.3-2021 (GB/T17901.3-2021) | | Description (Translated English) | Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L80 | | Word Count Estimation | 46,490 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration |
GB/T 17901.3-2021: Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques ---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Information technology - Security techniques - Key management - Part 3.Mechanisms using asymmetric techniques
ICS 35.040
L80
National Standards of People's Republic of China
Information technology security technology key management
Part 3.Mechanisms using asymmetric technology
Released on 2021-03-09
2021-10-01 implementation
State Administration of Market Supervision and Administration
Issued by the National Standardization Management Committee
Table of contents
Foreword Ⅲ
1 Scope 1
2 Normative references 1
3 Terms and definitions 1
4 Symbols and abbreviations 2
5 Requirements 3
6 Key Derivation Function 4
7 Remainder multiplication 4
8 Key Commitment 4
9 Key confirmation 5
10 Key Management Framework 6
10.1 Summary 6
10.2 Key agreement between two parties 6
10.3 Three-party key agreement 6
10.4 Secret key transmission 7
10.5 Public key transmission 7
11 Key Agreement 7
11.1 Key agreement mechanism 1 7
11.2 Key agreement mechanism 2 8
11.3 Key agreement mechanism 3 9
11.4 Key agreement mechanism 4 10
11.5 Key agreement mechanism 5 11
11.6 Key agreement mechanism 6 11
11.7 Key agreement mechanism 7 12
11.8 Key agreement mechanism 8 14
11.9 Key agreement mechanism 9 14
11.10 Key agreement mechanism 10 15
11.11 Key agreement mechanism 11 16
11.12 Key agreement mechanism 12 16
12 Key transfer 17
12.1 Key delivery mechanism 1 17
12.2 Key delivery mechanism 2 18
12.3 Key delivery mechanism 3 19
12.4 Key delivery mechanism 4 20
12.5 Key delivery mechanism 5 21
12.6 Key delivery mechanism 6 23
13 Public key transfer 24
13.1 Public key delivery mechanism 1 24
13.2 Public key delivery mechanism 2 25
13.3 Public key delivery mechanism 3 26
Appendix A (Normative Appendix) Object Identifier 27
Appendix B (informative appendix) Key establishment mechanism features 32
Appendix C (informative appendix) Examples of key derivation functions 34
Appendix D (informative appendix) Examples of function F, sets S1 and S2 35
Appendix E (informative appendix) Example of key establishment mechanism based on elliptic curve 36
Appendix F (informative appendix) Patent information related to the adopted international standards 37
Reference 41
Information technology security technology key management
Part 3.Mechanisms using asymmetric technology
1 Scope
This part of GB/T 17901 defines the requirements of a key management mechanism based on asymmetric cryptography, key derivation functions, and remainder formulas.
Multiplication, key commitment, key confirmation, key management framework, key agreement, key transfer, public key transfer.
This part intends to achieve the following objectives.
a) Establish a shared key through key agreement for symmetric encryption between entity A and entity B. In the key agreement mechanism,
The key is calculated from the data exchanged between entity A and entity B, and no entity can determine the value of the shared key in advance.
b) Establish a shared key through key transfer, which is used for symmetric encryption between entity A and entity B. In the key delivery mechanism,
The key is selected by entity A, and passed to entity B using asymmetric password protection technology.
c) Pass the public key of entity A to other entities through key transfer. In the public key delivery mechanism, the public key of entity A is authenticated and then transmitted
To other entities, but without confidentiality.
Some mechanisms defined in this section are based on the authentication mechanism corresponding to GB/T 15843.3-2016.
This section does not include the following key management content.
a) Key lifetime management;
b) The mechanism for generating or determining asymmetric key pairs;
c) Key storage, archiving, and deletion mechanisms.
This section applies to the development of systems that use asymmetric technology to achieve key management, and can also guide the detection of such systems.
Note. The mechanism defined in this section does not involve the distribution of the entity's private key, and the key exchange message is signed by the public key signature system.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. For undated reference documents, the latest version (including all amendments) is applicable to this document.
GB/T 15843.3-2016 Information Technology Security Technology Entity Authentication Part 3.Mechanisms Using Digital Signature Technology
GB/T 17901.1-2020 Information Technology Security Technology Key Management Part 1.Framework
GB/T 25069 Information Security Technical Terms
GB/T 32905 Information Security Technology SM3 Cipher Hash Algorithm
GB/T 32918.1 Information Security Technology SM2 Elliptic Curve Public Key Cryptography Algorithm Part 1.General Principles
GB/T 32918.2 Information Security Technology SM2 Elliptic Curve Public Key Cryptography Algorithm Part 2.Digital Signature Algorithm
GB/T 32918.3-2016 Information Security Technology SM2 Elliptic Curve Public Key Cryptography Algorithm Part 3.Key Exchange Protocol
GB/T 32918.4 Information Security Technology SM2 Elliptic Curve Public Key Cryptographic Algorithm Part 4.Public Key Cryptographic Algorithm
3 Terms and definitions
The following terms and definitions defined in GB/T 17901.1-2020 and GB/T 25069 apply to this document.
3.1
Elliptic curve cryptographic algorithm elipticcurvescryptosystem
The rational points on the elliptic curve are used to form a public key cryptographic algorithm that is difficult to calculate the discrete logarithm of the ellipse on the Abel additive group.
3.2
Token
A message composed of data fields related to a specific communication contains information transformed using cryptographic techniques.
3.3
Keycommitment
The process of confirming one's own public key or key token to the other party.
3.4
Key confirmation keyconfirmation
The process by which an entity is convinced that another identified entity has the correct key.
4 Symbols and abbreviations
4.1 Symbols
The following symbols apply to this document.
A, B, C. the identification of entities A, B, and C.
BE. Encrypted data block.
BS. signed data block with signed data block.
CertA. Entity A's public key certificate.
DA(). The private decryption transformation function of entity A.
dA. Entity A's private decryption key.
E. Elliptic curve, given the equation Y 2=X 3 aX b in the domain GF(pm), when p >3 and m is a positive integer, given in the domain
The equation Y 2 XY=X 3 aX 2 b on GF(2m), or the equation Y 2=X 3 aX 2 b on the field GF(3m), there is an additional
The reference point OE is called the point of infinity, which is recorded as E/GF(pm), E/GF(2m), or E/GF(3m).
EA(). The public encryption transformation function of entity A.
eA. The public encryption key of entity A.
F(). Key agreement function.
FP(). Pair-based key agreement function.
F(h,g). Use the parameter h and the public parameter g as the input key agreement function.
G. Take n as the point on the order E.
GF(pm), GF(2m), GF(3m). a finite field with a prime number p >3 and m is a positive integer pm, 2m, 3m.
g. Common parameters shared by all entities used by the key agreement function F.
Hash(). hash function.
hA. Entity A's private key agreement key.
j. The remainder formula used in the remainder multiplication.
K. The key of the symmetric encryption system.
KT. Key token.
KTA. Entity A's key token.
KTAi. The key token sent by entity A after the i-th interaction is processed.
KAB. The key shared between entity A and entity B.
kdf(). Key derivation function.
l. The value used in the remainder multiplication.
M. Data message.
MACK(Z). MAC algorithm output with key K and random data string Z as input.
n. The prime factor of the sequence of the elliptic curve E in a finite field.
OE. The infinity point of the elliptic curve.
P. The point on the elliptic curve E.
PX. Entity A's public key agreement key on elliptic curve E.
PKIA. Entity A's public key information.
parameter. The parameter used by the key derivation function.
pA, pB. the public key agreement keys of entities A and B.
q. Prime power pm of prime number p≠3 and m≥1.
r. randomly generated number.
rA. The random number of the key agreement mechanism of entity A.
S1, S2, S3.element collection.
SA. Entity A's private signature transformation function.
sA. Entity A's private signature key.
T. Trusted third party.
TVP. A parameter that changes with time, such as a random number, a timestamp, or a serial number.
Texti. Include the i-th text, data or other information in a data block.
VA(). The public verification transformation function of entity A.
vA. Entity A's public verification key.
w(). One-way function.
X(P). The x coordinate of point P.
Y(P). The y coordinate of point P.
√q. The square root of a positive number q.
∑. Digital signature.
π(P).(X(P)mod2ρ/2⌉) 2ρ/2⌉, where ρ= log2n⌉, X(P) is the x coordinate of point P.
4.2 Abbreviations
The following abbreviations apply to this document.
CA. Certificate Authority (CertificateAuthority)
MAC. Message Authentication Code (MessageAuthenticationCode)
5 requirements
This section requires the entities involved to know each other's purported identities. This can be achieved through the standard included in the exchange of information between the two entities.
Identifier to achieve, or it is obvious from the context in which the mechanism is used. Authentication means checking that a received identifier is
Whether the known (trusted) or expected value is the same. See Appendix A for the object identifiers of the mechanisms specified in this section.
If a public key belongs to an entity, then the entity should ensure that it has the corresponding private key (see GB/T 17901.1-2020 for key registration).
In this section, all those involved in the use of cryptographic technology to solve the requirements of confidentiality, integrity, authenticity, and non-repudiation shall comply with the requirements of cryptographic related countries
Home standards and industry standards. Among them, algorithms involving the use of elliptic curve signature verification and public key encryption and decryption are in accordance with GB/T 32918.2
And GB/T 32918.4.
6 Key derivation function
For symmetric cryptosystems, it is not recommended to use the shared secret derived from Chapter 10 without any further processing. Pass the key
The generation function can derive the shared key. It is recommended to use a one-way function as the key derivation function, such as the use of a hash function.
It is difficult to distinguish the key generated by the key derivation function from the randomly generated key. But the key derivation function needs to enter a shared secret and a
The group key derives parameters and generates a key of the required length for output.
In order for the two parties participating in the same key establishment mechanism to negotiate a common key, the key derivation function should be agreed in advance. Reach
The method of this agreement is beyond the scope of this section.
See Appendix C for examples of key derivation functions.
7 Remainder multiplication
This chapter only applies to mechanisms that use elliptic curve cryptographic algorithms. The key agreement mechanism described in Chapter 11 and the descriptions in Chapter 12 and Chapter 13
The key transmission mechanism of all requires the user's private key or key token to be mixed with the public key or key token of another entity. In ellipse
In the curve cryptographic algorithm, if the public key or key token of another entity is not valid (that is, it is not a point on the elliptic curve, or
hit".
There are two options to prevent "little subgroup attacks" and similar attacks.
One method is to use public key authentication to verify the public key and key token received from the other party (see the provisions of this section). another
One method is to verify the public key by using remainder multiplication. The remainder multiplication will be specified in Chapter 11.J and l defined below
The value of will be used in the remainder multiplication.
There are two options when using remainder multiplication.
a) If it is not required to be compatible with entities that do not use the remainder multiplication, then set j =
Public key verification or remainder multiplication is particularly suitable for the following situations.
a) The entity's public key has not been verified;
b) The key token is not verified;
c) The user's public key hopes to be used for a long time.
If the public key of another entity has been verified and the remainder is small, and the information that can be leaked is quite limited, these tests do not need to be completed.
8 Key Commitment
The mechanism of establishing a key through a one-way function of the secret key agreement protocol key is described in Chapter 11.However, an entity
It is possible to know the public key or key token of another entity before choosing its own private key. Therefore, the public keys of other entities and
Within the interval of selecting your own private key, you can generate 2s private key negotiation key candidate values at the cost of controlling s two of the keys to be established.
The value of the base bit.
The way to solve the problem is to use the key commitment, which needs to add an additional information or protocol interaction to complete the protocol. Key inheritance
The execution of the promise can be achieved by allowing the first entity to perform hash transformation on its own public key or key token and send the hash code to the second entity;
The second entity then replies with its own public key or key token, and then the first entity replies with its own public key or key token to the second entity.
Two entities can perform a hash transformation on it and verify whether the hash code is equal to the value sent by the first entity before.
9 Key confirmation
The explicit key confirmation process is by adding an additional message to a key establishment protocol that provides implicit key authentication, so it provides
Explicit key authentication and entity authentication. Explicit key confirmation can be added to any method that does not contain itself. Key confirmation is usually
It is achieved by exchanging a value, which can be calculated correctly only when the key establishment calculation is successful with a high probability. Slave entity
The key confirmation from A to entity B is calculated by entity A and sent to entity B to confirm entity A's calculation. If required
For mutual key confirmation, each entity needs to send a different value to the other party.
Implicit key confirmation is to provide key confirmation in the subsequent use of the established key. When a certain error occurs, it will be detected immediately.
In this case, no explicit key confirmation is required. If an entity is not online (e.g. in a single-round communication protocol, store and forward (email
File) scenario], it is impossible for another entity to obtain key confirmation. However, sometimes the established key is used later, or the key is established
The entity of the process does not know whether the generated key will be used immediately. In these cases, it is usually necessary to use an explicit key confirmation method,
Otherwise, once the error is detected, it may be too late to correct it. Explicit key confirmation can be regarded as a "firm" security attribute in the key establishment process.
It can be regarded as a conservative protocol design.
The steps for using MAC to provide key confirmation are as follows.
Entities A and B first perform one of the key establishment procedures adopted in Chapter 11 and Chapter 12 of this part, and expect to share one
The MAC key KAB, the steps performed are as follows.
a) Entity B generates an octet string message M, including. message identifier octet 0x02, entity B identifier, real
The identifier of entity A, corresponding to the octet string KTB of the key token of entity B (if not present, omitted), corresponding to entity A
The octet string KTA of the key token of the key token (if it does not exist, omit), corresponding to the key of entity B to establish the public key pB (if it does not exist
In, omitted), the public key pA corresponding to the key establishment of entity A (if not present, omitted), and optional additional text Text1 (such as
If it exists), that is. M=02|B|A|KTB|KTA|pB|pA|Text1, where 0x02 is the message sequence number.
b) Entity B calculates KB=kdf(KAB), uses the shared key KB, and uses a suitable MAC mechanism to calculate the message M
MACKB(M).
c) Entity B sends message M and MACKB(M) to entity A.
d) Entity A calculates KA=kdf(KAB), uses the received message M to calculate MACKA(M), and verifies that MACKB(M)=
MACKA(M).
e) Assuming MAC verification, entity A has received the key confirmation from entity B (that is, entity A knows that KA=KB). For mutual key
Confirmed, entity A continues to execute the protocol and generates an octet string of message M', which consists of several parts. message identifier octets
Group 0x03, the identifier of entity A, the identifier of entity B, the octet string KTA corresponding to the key token of entity A
(If it does not exist, omit), the octet string KTB corresponding to the key token of entity B (if it does not exist, omit), corresponding to the actual
The key establishment public key pA of the entity A (if not present, omitted), the key establishment public key pB corresponding to the entity B (if it does not exist, save
Omitted), and optional additional text Text2 (if present), namely. M'=03|A|B|KTA|KTB|pA|pB|
Text2, where 0x03 is the message sequence number.
f) Entity A uses the shared key KA and uses a suitable MAC mechanism to calculate MACKA(M').
g) Entity A sends M'and MACKA(M') to entity B.
h) For message M', entity B uses KB to verify MACKA(M'). Assuming MAC verification, entity B has received entity A's key
Confirm (ie entity B knows that KA=KB).
Other methods of confirming the key can also be used. If the shared key is used for data encryption, then one entity can use some features known to another entity.
The specified plaintext is encrypted and sent to the entity, such as a binary block of all 0s or all 1, but it should be noted that when the key is subsequently used, it is no longer encrypted
It is the same plaintext used in key confirmation.
10 Key Management Framework
10.1 Summary
This chapter contains a high-level description of the key establishment mechanism framework, and defines four mechanisms (two-party key agreement, three-party key agreement, private key
Transmission and public key transmission) and their respective usage requirements. See Appendix B for the characteristics of these mechanisms.
10.2 Key agreement between two parties
This clause applies to the key agreement mechanism for key agreement between the two parties described in 11.1 to 11.11.The key agreement between the two parties is a two
In the process of establishing a shared key between entities, neither party can determine the value of the shared key in advance. Key agreement mechanism can provide implicit keys
Authentication; under the condition of key establishment, implicit key authentication means that only the identified entity can have the correct sharing after the mechanism is implemented
Key.
The key agreement between A and B takes place under the condition that both parties share a piece of content. The content includes two sets S1, S2 and
A key agreement function F. Function F should meet the following requirements.
a) F. S1×S2→S2 maps the element (h,g)∈S1×S2 to the element of S2, written as y=F(h,g);
b) F satisfies exchange.
F(hA,F(hB,g))=F(hB,F(hA,g));
c) It is difficult to calculate F(h1,F(h2,g)) from F(h1,g), F(h2,g) and g, which means that F(.,g) is a one-way function;
d) Entity A and B share a common element g in S2, which is public;
e) The entity under this setting can efficiently calculate the function value F(h,g) and effectively generate random elements in S1.In a specific secret
In the key negotiation, some conditions can be further included.
Note 1.Appendix D and Appendix E give examples of key agreement function F.
Note 2.As described in Chapter 6, the shared key is further processed during the actual implementation of the key agreement mechanism.
Note 3.Generally speaking, if the received function value F(h,g) is a weak value, the agreement will be terminated.
10.3 Three-party key agreement
This clause applies to the key agreement mechanism for key agreement between three parties described in 11.12.The three-party key agreement is in three entities A,
A shared key is established between B and C, and any one of the three parties cannot determine the value of the shared key in advance. The key between the three entities A, B, and C
Negotiation occurs under the condition that three parties share a piece of content, the content includes three sets S1, S2, S3, key agreement function F and FP. Key
The negotiation functions F and FP should meet the following requirements.
a) F. S1×S2→S2 maps the element (h,g)∈S1×S2 to the element of S2, written as y=F(h,g);
b) F satisfies exchange.
F(hA,F(hB,g))=F(hB,F(hA,g));
c) It is difficult to calculate F(h1,F(h2,g)) from F(h1,g), F(h2,g) and g, which means that F(.,g) is a one-way function;
d) FP. S1×S2×S2→S3 maps the element (hC,F(hA,g),F(hB,g)) ∈ S1×S2×S2 to the element of S3 and writes it as.
z=FP(hC,F(hA,g),F(hB,g));
e) FP meets exchangeability.
FP(hC,F(hA,g),F(hB,g))=FP(hC,F(hB,g),F(hA,g))=FP(hB,F(hA,g),F (hC,g))
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 17901.3-2021_English be delivered?Answer: Upon your order, we will start to translate GB/T 17901.3-2021_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 7 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GB/T 17901.3-2021_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 17901.3-2021_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|