GB/T 27909.3-2011 Banking Key Management (Retail) Part 3: Asymmetric Cryptography Systems and Key Management and Life Cycle GB/T27909.3-2011 |tt||Standard compression package decompression password: www.bzxz.net
This part specifies the protection technology of symmetric and asymmetric keys when asymmetric cryptographic mechanisms are used in retail financial service environments, and also describes the life cycle management related to asymmetric keys. This part is applicable to technologies that comply with the principles described in GB/T27909.1. The retail financial service environment of this part is limited to the interfaces between the following entities: ———Card acceptance device and acquirer; ———Acquirer and issuer; ———Integrated Circuit Card (ICC) and card acceptance device.
class="f14" style="padding-top:10px; padding-left:12px; padding-bottom:10px;"> GB/T27909 "Key Management for Banking (Retail)" is divided into the following three parts:
———Part 1: General principles;
———Part 2: Symmetric cryptography and its key management and life cycle;
———Part 3: Asymmetric cryptography systems and its key management and life cycle.
This part is the third part of GB/T27909. This
part is drafted according to the rules given in GB/T1.1-2009.
This part is modified to adopt the international standard ISO11568-4:2005 "Key Management for Banking (Retail) Part 4: Asymmetric cryptography systems and its key management and life cycle" (English version).
The following modifications were made when adopting ISO11568-4:
--- "Approved algorithms in Appendix A of ISO11568-4" was deleted.
This part also made the following editorial modifications:
a) For international standards cited in normative references, if there are corresponding national standards, the national standards are quoted instead;
b) The ISO foreword was deleted.
This part was proposed by the People's Bank of China.
This part is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180).
The responsible drafting unit of this part: China Financial Electronicization Company. The
participating drafting units of this part: People's Bank of China, Industrial and Commercial Bank of China, Agricultural Bank of China, Bank of China, Bank of Communications, China Everbright Bank, China UnionPay Co., Ltd.
The main drafters of this part are: Wang Pingwa, Lu Shuchun, Li Shuguang, Zhao Zhilan, Zhou Yipeng, Zhao Hongxin, Cheng Guanzhong, Liu Yao, Yu Guodong, Yang Zengyu, Huang Faguo.
The following documents are indispensable for the application of this document. For any dated referenced document, only the dated version applies to this document. For any undated referenced document, the latest version (including all amendments) applies to this document.
GB/T27909.1 Key management for banking business (retail) Part 1: General principles (GB/T27909.1—2011, ISO11568-1:2005, MOD)
GB/T27909.2 Key management for banking business (retail) Part 2: Symmetric cryptography and its key management and life cycle (GB/T27909.2—2011, ISO11568-2:2005, MOD)
GB/T17964—2000 Information security technology Block cipher algorithm working mode (ISO/IEC10116:1997, IDT)
GB/T20547.2 Security encryption equipment for banking business (retail) Part 2: Checklist for security compliance of equipment used in financial transactions (GB/T20547.2—2006, ISO13491-2:2005, MOD)
GB/T21078.1 Management and security of personal identification numbers for banking services Part 1: Basic principles and requirements for online PIN processing in ATM and POS systems (GB/T21078.1—2007, ISO9564-1:2002, MOD)
GB/T21079.1 Banking security encryption equipment (retail) Part 1: Concepts, requirements and evaluation methods (GB/T21079.1—2007, ISO13491-1:1998, MOD)
ISO/IEC9796-2:2002 Information technology security techniques Digital signature scheme for message recovery
ISO/IEC10118 (all parts) Information technology security techniques Hash functions
ISO/IEC11770-3 Information technology security techniques Key management Part 3: Mechanisms using asymmetric techniquesISO/IEC14888-3 Information technology security techniques Signatures with appendix Part 3: Mechanisms based on discrete logarithmsISO15782-1:2003 Banking certificate management Part 1: Public key certificates
ISO/IEC15946-3:2002 Information technology security techniques Cryptography based on elliptic curves Part 3: Key generation
ISO16609:2004 Banking: Requirements for message authentication using symmetric techniques
ISO/IEC18033-2 Information technology security techniques Cryptography algorithms Part 2: Asymmetric cryptography
ANSIX9.42-2003 Public key cryptography for financial services Symmetric key protocol using discrete logarithm cryptographyPreface
III
Introduction IV
1 Scope1
2 Normative references1
3 Terms and definitions2
4 Use of asymmetric cryptography in retail financial services systems3
4.1 Overview3
4.2 Establishment and storage of symmetric keys3
4.3 Storage and distribution of asymmetric public keys3
4.4 Storage and transmission of asymmetric private keys3
5 Technologies for providing key management services4
5.1 Overview4
5.2 Key encryption4
5.3 Public key authentication5
5.4 Key separation techniques5
5.5 Key verification6
5.6 Key integrity techniques6
6 Asymmetric key lifecycle7
6.1 Key Lifecycle Phases7
6.2 Key Lifecycle --- Generation Phase7
6.3 Key Storage10
6.4 Distribution of Public Keys12
6.5 Transmission of Asymmetric Key Pairs12
6.6 Authenticity Before Use14
6.7 Use14
6.8 Revocation of Public Keys14
6.9 Replacement14
6.10 Public Key Invalidation15
6.11 Destruction of Private Keys15
6.12 Deletion of Private Keys15
6.13 Archiving of Public Keys15
6.14 Termination of Private Keys15
6.15 Erasure Summary 16
6.16 Optional Lifecycle Processes 16
References 17

ICS 35.240.40
National Standard of the People's Republic of China
GB/T 27909.3—2011
Banking-Key management(retail)-Part 3:Asymmetric cryptosystems-Key management and life cycle(ISO 11568-4:2007,MOD)
2011-12-30 Issued
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China Standardization Administration of China
2012-02-01 Implementation
1 Scope
2 Normative references
3 Terms and definitions
4 Use of asymmetric cryptography in retail financial service systems4.1 Overview
1.2 Establishment and storage of symmetric public keys
4.3 Storage and distribution of asymmetric public keys
4.4 Storage and transmission of asymmetric private keys
5 Technologies for providing cryptographic management services
5.1 Overview
Key encryption
Public key
Key separation technology
Key verification address
Key integrity technology
6 Asymmetric key life cycle
Phase after phase of key life cycle
Key life cycle
Key storage
Distribution of public keys
Generation phase
Transmission of asymmetric key pairs
Authenticity before use,
Revocation of public keys
Invalidation of public keys
Destruction of private keys
Deletion of private keys
Archival of public keys
Termination of private keys
Erasure summary
Optional life cycle processes
References
TTKANTKACA
GB/T 27909.3-2011
CB/T27909 Banking Business Key Management (Retail)\ is divided into the following three parts: Part 1: General principles; Part 2: Symmetric cryptography and its key management and life cycle Part 3: Asymmetric cryptography system and its key storage management and life cycle. This part is Part 3 of GB/T27909. This part is drafted in accordance with the rules given in GB/T 1.1-2009. GB/T 27909.3-2011
This part adopts the international standard IS011568-4, 2005 Banking Business Key Management (Retail) Part 4: Asymmetric cryptography system and its key storage management and life cycle (English version). The following changes were made when adopting ISO 11568-4: "Algorithms approved in Appendix A of ISO 11568-4" were removed. The following editorial changes were also made: a) International standards cited in normative references were replaced with national standards if they had corresponding national standards; b) ISO Preface.
This part is proposed by the People's Bank of China.
This part is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180), and the responsible drafting unit of this part is China Financial Electronicization Company. Participating drafting units of this part: People's Bank of China, Industrial and Commercial Bank of China, Agricultural Bank of China, Bank of China, Bank of Communications, China Everbright Bank. China UnionPay Co., Ltd.
The main drafters of this part: Wang Pingwa, Lu Shuchun, Li Shuguang, Zhao Zhilan, Zhou Yipeng, Zhao Hongxin, Cheng Guanzhong, Liu Ban, Yu Guodong, Zeng Yu, Huang Faguo.
TTTKANTKACA
GB/T27909.3—2011
GB/T27909 describes the security management process of keys in the retail financial services environment. These keys are used to protect messages such as between acquirers and acceptors, and between acquirers and issuers. This part describes the key management requirements applicable in the field of retail financial services, typical The service types include point-of-sale/point-of-service (POS) debit and credit authorization and automated teller machine (ATM) transactions: When the key management technologies described in various parts of GB/T 27909 are used in combination, the key management services summarized in GB/T 27909.1 can be provided.
These services include:
Key separation
Prevention of key replacement:
Key authentication.
-Key synchronization;
Key integrity +
-Key confidentiality:
Detection of key leakage.
This part describes the key life cycle involved in key security management when using asymmetric cryptographic mechanisms. Based on the key management principles, services and technologies described in Part 1 of the standard and this part, this part also specifies the requirements and implementation methods for each stage in the key life cycle. This part does not involve the key management and life cycle of symmetric cryptographic mechanisms. For content in this regard, see GB/T 27909.2. This part is GB/T 27909, GB/T 21078.1, GB/T 20547, ISO 9564-2, ISO 9564-3, IS( 9564-4, ISO/TR19038 and other standards that describe the security requirements in the financial services sector. TTKANYKAcA
1 Scope
Key management for banking (retail)
Part 3, Asymmetric cryptographic systems and their
Key management and life cycle
GB/T 27909.3—2011
This part specifies the protection techniques for symmetric and asymmetric cryptographic mechanisms when using asymmetric cryptographic mechanisms in retail financial services environments, and also describes the life cycle management associated with asymmetric keys. This part applies to technologies that comply with the principles described in GB/T 27909.1. The retail financial service environment of this part is limited to the interface between the following entities: - Card acceptance equipment and acquirer:
- Acquirer and card issuer:
- Integrated Circuit Card (ICC) and card acceptance equipment. 2 Normative references
The following documents are indispensable for the application of this document. For all references with a date, only the version with the date applies to this document. This is an undated reference document, the latest version of which (including all amendments) applies to this document: GB/T27909.1 Banking business key management (retail) Part 1: General principles GB/T27909.1-2011 IS0 11568-1:2005, M0D)
GB/T27909.2 Banking business key management (retail) Part 2: Symmetric cryptography and its key management and life cycle (GB/T 27909.2-2011.IS0 11568-2:2005, MOD) GB/1179642000 Information security technology Block cipher algorithm working mode (IS0/IEC10116:19971DT) GB/T20547.2 Banking business security equipment (signing) Part 2: Equipment security compliance test list for financial transactions (GB/T20547.2--2006, ISO 13491-2:2005.M0D) GB/T 21078.1 Management and security of personal identification numbers for banking services Part 1: Basic principles and requirements for online PIN processing in ATM and POS systems (GB/T 21078.1—2007, ISO 9564-1; 2002, M0D) GB/T 21079.1 Banking security encryption equipment (retail) Part 1: Concepts, requirements and evaluation methods (GB/T 21079.12007, ISO 13491-1:1998, M0D) 1S0/IEC9796-2:2002 Information technology security techniques Digital signature schemes for message recovery IS0/IEC10118 (all parts) Information technology security techniques Hash functions IS0/IEC11770-3 Information technology security techniques Cryptographic algorithms Part 3: Mechanisms using asymmetric techniques ISO/IEC14888-3 Information technology security techniques Signatures with appendix Part 3: Mechanisms based on discrete logarithms 1SO15782-1:2003 Banking certificate management Part 1: Public key certificates IS0/IEC 15946-3:2002 Information technology security techniques Cryptography based on elliptic curves Part 3: Generation of cryptographic algorithms
1S0166092004 Banking, message authentication requirements using symmetric techniques IS0/IEC18033-2 Information technology security techniques Cryptographic algorithms Part 2: Asymmetric cryptography ANSI X9.42-2003 Public key cryptography for financial services Symmetric encryption protocol using discrete logarithm cipher 1
TTKANYKACA
CB/T 27909.3—2011
3 Terms and definitions
The terms and definitions defined in GB/T27909.1 and GB/T27909.2 and the following terms and definitions apply to this document. 3.1
Asymmetric cipher
A cipher in which the encryption key and the decryption key are not separate, and it is computationally infeasible to derive the decryption key from the encryption key. 3.2
Asymmetric cryptosystemasymunetric cryptogystemA cryptosystem consisting of two complementary operations, each of which uses a different but related key, namely a public key and a private key, to encrypt or decrypt, and it is computationally infeasible to derive the decryption key from the encryption key. 3.3
asymmetricekeypairgenexatorasymmetricekeypairgenexatorA secure cryptographic device used to generate asymmetric keys. 3.4
certificatecertificate
A certificate of an entity signed privately by the certificate authority that issued the certificate, thereby ensuring that it cannot be forged. 3.5
certification authority (CA)
certification authorily(CA)An entity trusted by one or more parties to create, issue, and revoke certificates. Note: Optionally, a certification authority may also create and distribute secret certificates to entities. 3.6
communicating party
sends or receives public certificates, used to communicate with the owner of a public key. 3.7
computationallyinfeasibleA computation that is theoretically possible, but is infeasible in terms of the time or resources required to perform the computation. 3.8
credentials
authentication data of an entity, including at least the unique identifier and public key of that entity. NOTE Other data may also be included.
cryptoperiod
a specific period of time during which a particular key is authorized for use or remains valid in a given system. 3.10
digital signature systemdigital signature systeman asymmetric cryptographic system that provides for the generation and verification of digital signatures. 3.11
hash functionhash function
a one-way function that maps an arbitrary set of strings to a set of bit strings of fixed length. NOTE A collision-resistant hash function is a function such that it is computationally infeasible to create multiple different inputs that map to the same output. 2
TTTKANYKAA
Independent communicationGB/T 27909.3—2011
refers to the process that allows an entity to reversely verify the credentials and the positive authentication of the identification document before generating a certificate (such as callback, visual authentication, etc.). 3.13
key agreement
The process of establishing a shared key between entities in a way that the key value cannot be predicted. 3.14
key sharing componentkey share
One of the parameters related to the cryptographic key (at least 2 parameters). When generating the cryptographic key, only when the number of parameters reaches the threshold can the key be combined to form a key. If the number of parameters is less than the threshold, no information about the key can be provided. 3.15
Non-repudiation of origin The property that the originator of a message and its associated cryptographic check value (mathematical signature) cannot deny that he or she has sent the message to an acceptable degree of confidence.
4 Use of asymmetric cryptographic systems in retail financial services systems 4.1 Overview
Asymmetric cryptographic systems include asymmetric cryptography, digital signature systems, and key agreement systems. In retail financial services systems, asymmetric cryptographic systems are mainly used for key management: first, for key management of symmetric cryptography, and second, for key management of the asymmetric cryptographic system itself. This chapter describes these applications of asymmetric cryptographic systems. Chapter 5 describes the technologies used in these applications related to key management and certificate management. Chapter 6 describes how these technologies and methods are applied to the security and implementation requirements of the key pair life cycle. 4.2 Establishment and storage of symmetric keys
Symmetric cryptographic keys can be established through key transmission or key agreement. The key transmission or key agreement mechanism is shown in ISO/IEC11770-3. The mechanism should ensure the authenticity of the communicating parties. For storage requirements of symmetric keys, see GB/T 27909.2. 4.3 Storage and distribution of asymmetric public keys
The public key of an asymmetric key pair needs to be distributed to one or more users or stored by them for subsequent use as an encryption key and/or signature verification key, or for use in a key negotiation mechanism. Although this key does not need to be protected from disclosure, the distribution and storage process should ensure the authenticity and integrity of the key as described in 5.6.1. For asymmetric public key distribution mechanisms, see ISO/IEC11770-3. 4.4 Storage and transmission of asymmetric private keys bZxz.net
The private key of an asymmetric key pair does not need to be distributed to any entity. In some cases, it can only be stored in the secure cryptographic device that generated it.
If it must be exported from the device where it was generated (for example, to be transferred to another secure cryptographic device that is prepared for use or backup), at least one of the following techniques should be used to prevent leakage: - Encrypt with another key in the manner specified in 5.2 (see 5.2) TTTKAONYKACA
GB/T27909.3—2011
- If encryption is not performed and it is to be exported outside the secure cryptographic device, a variable key splitting algorithm should be used to split the private key of the asymmetric key pair into several secret components: - Export to another secure cryptographic device that is prepared for use, or to a secure transmission device used for this purpose. If the communication path is not sufficiently secure, the transmission should only be allowed in a secure environment. One of the techniques defined in 5.6.2 should be used to ensure the integrity of privacy. 5. Techniques that provide key management services
5.1 Overview
This clause describes a number of techniques that can be used alone or in combination to provide the key management services described in GB/T 27909.1. Some techniques can provide multiple key management services. Asymmetric key pairs should not be used for multiple purposes, but if they are used, for example, in digital signatures and encryption, then special key separation techniques should be used to ensure that the system is not attacked by using key pair transformations. The selected technology should be implemented in a secure cryptographic device, and the function of the cryptographic device should ensure that the implementation of the technology can achieve the intended purpose. The security and management requirements of secure cryptographic devices are shown in GB/T 21079. 5.2 Key encryption
5. 2.1 Overview
Key encryption is a technique that uses one key to encrypt another key. The encrypted key obtained in this way can be stored securely outside the secure cryptographic device. The key used to implement this encryption technology is called a key encryption key (KEK). Two different encryption scenarios involving asymmetric keys and asymmetric cryptography are described here, namely: a) symmetric key encryption with asymmetric cryptography; b) asymmetric key encryption with symmetric cryptography. 5.2.2 Symmetric key encryption with asymmetric cryptography Encryption with the public key of an asymmetric cryptography is typically used to distribute the secret key through an insecure channel. The encrypted secret key may be a working key or may itself be an encryption key (KEK), so that a combined key hierarchy structure as described in GB/T27909.2 can be established in combination with symmetric and asymmetric cryptographic keys. Symmetric keys should be formatted into data packets suitable for encryption operations. Since the data packet size of asymmetric cryptography is generally larger than that of symmetric cryptographic keys, more than one key can usually be included in a data packet during encryption. In addition, the data packet should also include formatting information, random padding characters and meta characters (see ISO/IEC18033-2). 5.2.3 Encrypting an Asymmetric Key with a Symmetric Cipher Asymmetric keys can be encrypted with symmetric ciphers. Since the key length of an asymmetric cryptographic system is usually larger than that of a symmetric cipher, the asymmetric key can be formatted into multiple data blocks and encrypted using the Cipher Block Chaining (CBC) mode of operation (see GB/T 17964) or equivalent operations. Known attacks should be considered when evaluating the equivalent strength of various cryptographic algorithms. In general, when the fastest known attack takes an average of 2+1T time to attack, the algorithm can be said to provide a strength of: bits, where T is the time to perform a plaintext addition and compare it with the corresponding ciphertext value.
For example, in GB/T 17964, an attack on the 112-bit 3-DEA algorithm is proposed that requires O(k) space and 212D-l operations, where is the number of known plaintext-ciphertext pairs. As discussed in reference [11], given two known plaintext-ciphertext pairs, the strength of the double-key (112-bit) 3-DEA key is reduced to 80 bits. Table 1 gives the equivalent cryptanalytic lengths recommended at the time of publication of the standard. Advances in cryptanalysis, factorization, and computational techniques should be considered when evaluating these values. Note that currently, 3-DEA keys in financial services environments are not used to protect other keys. 3-DEA cryptanalytic transformations make it impossible to collect enough plaintext-ciphertext pairs to reduce the potential cryptographic strength - therefore, it can be assumed that 112-bit 3-DEA provides sufficient security protection for 168-bit 3-DEA and 2048-bit RSA keys.
Table 1 Equivalent Strength of Encryption Algorithms
Effective Strength
5.3 Public Key Authentication
Symmetric Cipher
112-bit 3-DEA (with 24 known plaintext/ciphertext pairs)112-bit 3-DEA (without known plaintext/ciphertext pairs)168-bit 3-DEA
Abstract
Key authentication is a technology that, when used in accordance with the requirements of IS015782-1, can ensure the authenticity of a public key by creating a digital signature for the key and related valid data. Before using the public key, the recipient verifies the authenticity of the public key by verifying the digital signature. The user's public key and related valid data are collectively referred to as the user's credentials. The digital data usually includes user and key identification information, as well as validity data (e.g., key validity period). Public key certificates are issued by a third party called a "certification authority". Public key certificates are created by signing a user's credentials with a private key owned by the certification authority, which can only be used to sign certificates. Independent communication methods should be used to verify that the identity of the key and its owner are legitimate and authorized, which may require obtaining the original information through one channel and then obtaining confirmation through another different channel. The authenticity of the public key should be guaranteed during its distribution to authorized recipients or storage in a confidential database. 5.4 Key Separation Techniques
5.4.1 Overview
To ensure that stored keys are used only for their intended purpose, stored keys should be separated in one or more of the following ways: a) Physically separate the stored keys according to their intended function; 6) Store the keys encrypted by a key encryption key that is used for a specific type of confidential encryption; c) Modify the key information or send it to the encrypted key before it is stored according to its intended function. Key additional information: that is, key marking. 5.4.2 Key marking
5.4.2.1 Overview
Key marking is a technology that distinguishes the types of keys that exist outside of existing security code devices. The key value and its permissions should be bound together in a way that prevents either of them from being undetectably modified. 5.4.2.2 Explicit key marking
Explicit key marking uses a field that contains information that defines the relevant key permissions and its password type. This field and the key value should be bound together in a way that prevents either of them from being undetectably modified. 5.4.2.3 Implicit key marking
Implicit key marking does not rely on the use of an explicit segment containing information that defines the relevant key permissions and its password type, but relies on the system 5
TTTKAONYKACA
B/T 27909.3-2011
other features of the key value, such as the location of the key value in the record, or other related functions that determine and limit the permissions of the key. 5.5 Key Verification
Key verification is a technique for checking and verifying key values ​​without revealing the key value and without using public key certificates. The key verification code (KVC) used in this technique is cryptographically associated with the key through a collision-resistant one-way function. For example, the reference KVC can be obtained by operating the public key, the secret key and related data using the hash algorithm defined in ISO/IEC10118. After the KVC is generated for the first time, the key can be input into the one-way function again. If the KVC is generated later The key value is considered unchanged if it is identical to the KVC that was originally generated. Key verification can be used to determine that one or more of the following conditions have been met: a) the key has been correctly entered into the cryptographic device; b) the key has been received over the communication channel; c) the key has not been tampered with or replaced. For public keys, public keys can be distributed over insecure channels as long as the KVC can be distributed over a channel that ensures its integrity. Before installing and using the public key, the government should verify the public key by calculating KC and comparing it with K. It should be ensured that it is impossible to modify/replace the KVC and the public key (and its related data) and still keep the two consistent. This can be achieved in one of the following ways:
--by ensuring the integrity of the KVC (see ISO16509), or by storing/distributing the reference KVC independently in a way that ensures that the reference KVC is modified/replaced without being modified/replaced simultaneously with the public key (and its related data) (e.g., dual control). 5.6 Encryption Integrity Techniques
5.6.1 Public Keys
The integrity of the public key shall be ensured using one or more of the following techniques: Sign the public key and associated data using a digital signature system to create a public key certificate. The principles for creating and verifying the encryption of certificates are described in Sections 5.3 and 6.
- Generate a MAC for the public key and associated data using an algorithm defined in ISO 16609 and a key that ensures the integrity of the public key: Storing the public key in a secure cryptographic device (see ISO 16609-1 and ISO 16609-2); Distributing the public key over an unprotected channel, and distributing the public key authentication code and associated data over an integrity-protected channel, such as an authenticated channel with dual control. See Section 5.5 for key authentication - Use an authenticated encryption method.
5.6.2 Private key
Virtual uses one or more of the following techniques to ensure the integrity of the private key: - Generate MAC for the private key and related data using the algorithm defined in ISO16609 and the key that ensures the integrity of the private key; - Store the private key in a secure cryptographic device (see GB/T21079.1 and GB/T20547.2); - Use an authenticated encryption method
- Store in the form of a key component with integrity protected. - Verify whether the private key and the authenticated public key constitute a valid key pair by using the two keys in the key pair to encrypt/decrypt any data and compare the result with the expected result. This operation should be fully implemented in the secure cryptographic device and all intermediate and final conversion results should be destroyed. 6
TTTKAONATKACA
6 Asymmetric key life cycle
6.1 Phases of key life cycle
The key life cycle includes three phases:
a) Before use: In this phase, the key pair is generated and can be transmitted; GB/T 27909.3—2011
b) In use: In this phase, the public key is distributed to one or more parties for operation, and the private key is retained in the secure cryptographic device (SC1)); c) After use: In this phase, the public key in the key pair is returned and the private key is terminated. Figures 1 and 2 show schematic diagrams of the private key (S) life cycle and the public key (P) life cycle, respectively. The figure shows how the key changes its state through specific operations. For the life cycle of the public key, see ISO15782-1. A key can be considered as a single object, and its multiple instances can exist in different forms and in different locations. A distinction is made between the following operations:
- distributing a public key to a communicating party (see 6.1); transmitting a key pair to a party that does not have the ability to generate the key pair (see 6.5). And:
- destroying a single private key instance (see 6.11) - Removal of a private key from a given location destroys all instances of the key in that location (see 6.12). - - Termination of key transfer deletes the key from all locations (see 6.14). Every operation performed on a key changes the state of the key. This clause specifies the requirements for obtaining a given state or performing a given operation. 6.2 specifies the requirements for each life cycle stage. NOTE 1: Requirements for archived private keys are not included in this part of the specification. Archived private keys are used to subsequently decrypt data encrypted by the corresponding public key. NOTE 2: Subsequent requirements depend on the implementation of the key pair generation method. In particular, the requirements for each life cycle phase are different if the key pair is generated by a third-party asymmetric key pair generator or if the key pair is generated and stored by the owner. 6.2 Key life cycle - generation phase
6.2.1 Overview
The generation of an asymmetric key pair is the process of generating a new key pair for a specific asymmetric cryptographic system. The key pair consists of a secret key and its associated public key: the two keys of the asymmetric key pair are linked by a certain mathematical relationship defined in the specific asymmetric cryptographic system; and it is computationally infeasible to derive the private key from the public key. Key pair generation should be performed by the owner of the key pair or its agent. Each private key and private key component should be generated in such a way that it is not possible to predict any private key, nor to determine that some private keys are more likely than other private keys in the possible private key nest, see reference [4. Random or pseudo-random values ​​should be introduced in the process of generating secret keys and private key components.
Asymmetric key pairs should be generated in a way that preserves the confidentiality of the private key and the integrity of the public key. The generation of asymmetric key pairs for non-repudiation services should be able to prove the integrity of the public key and the confidentiality of the private key to a third party. The private key should not exist in a readable form.
If the key pair is generated by a system that does not use the key pair, the key pair and all related confidential seed elements should be immediately erased after confirming that the transmission has been completed! .-The integrity of the key should be ensured.
Asymmetric key pairs should include a rotation period when generated to establish the life cycle of the key pair. GB/T 27909.3—2011
The length of an asymmetric key pair should be large enough to make attacks computationally infeasible. The generation of asymmetric key pairs should be completed by a certification authority (CA), the key pair owner, or a third-party authorized agency. 6.2.2 to 6.2.4 describe the roles and responsibilities of the key pair generation agency. Item Letter Party 1 or third party
Before use
Communication Party 1
After use
Description:
Sell(s) -
Sensitive
State:
Condition:
Information:
A public key:
A private key-
Get (8)
Generate (PS)
Continue to generate
Store (optional)
Active
Store (s)
Backed up
Delete (S)
Deleted
Terminate (S)
Terminated
A transfer (PS) Optional
Use (e, $)
Revoke (P)
Revoked
Figure 1 Private key life cycle
Revocation information
Revocation method 2
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.