Banking—Key management (retail)—Part 5:Key life cycle for public key cryptosystems
Some standard content:
ICS 35.240.40
National Standard of the People's Republic of China
GB/T 21082.5--2007/ISO 11568-5:1998Banking-Key management (retail)-Part 5 : Key life cycle for public key cryptosystems(ISO 11568-5:1998, IDT)
Published on September 5, 2007
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China Administration of Standardization of the People's Republic of China
Implementation on December 1, 2007
Normative references
3 Terms and definitions
4 General requirements
Generation of asymmetric key pairs
Authenticity before use
Public key authentication
4.4 Transmission of asymmetric key pairs
Malkey storage
Key retrieval
Distribution of public keys
Public key certificate verification
Key usage
Public key registration ·
Revocation of public key
Replacement of key·
Destruction of private key
Deletion of private key
Termination of private key
Archiving of public key
Recovery of key pair
5 Implementation requirements
Generation of asymmetric key pair
Authenticity before use
Public key verification
5.4 Transmission of asymmetric key pair
Key storage
Retrieval of key
Public key distribution
5.8 Public key verification
5.9 Key use
Public key registration
Revocation of public key
Replacement of key
GB/T 21082.5—2007/ISO 11568-5:19986
GB/T 21082.5—2007/ISO 11568-5:19985.13
Revocation of private key
Delete of private key
Termination of private key
Archive of public key
Recovery of key pair
GB/T21082.52007/IS011568-5;1998GB/T21082 Banking business key management (retail) 3 is divided into the following 6 parts: Part 1 Introduction to key management;
Part 2 Key management technology for symmetric cryptography: Part 3 Key life cycle of symmetric cryptography; Part 4
Key management technology using public key cryptography; Key life cycle of public key cryptography: Part 5
Part 6 Key management scheme.
This part is Part 5 of GB/T21082. This part is equivalent to the international standard IS011568-5:1998 Banking business key management (retail) Part 5: Key life cycle of public key cryptographic systems (English version). For ease of use, the following editorial changes have been made to this part of IS011568-3:1998: a) For international standards cited in normative references, if there are corresponding national standards, the national standards are quoted instead. h) The ISO foreword is deleted.
This part is proposed by the People's Bank of China.
This part is managed by the National Financial Standardization Technical Committee. 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, China Construction Bank, China Merchants Bank, and North China Institute of Computing Technology Venusstar Co., Ltd.
The main drafters of this part are: Lie Guoan, Yang Zi, Lu Shuchun, Li Shuguang, Lin Zhong, Zhang Qirui, Shi Shuiheng, Zhao Hongxin, Li Hongxin, Xu Wei, Dong Yongle, Wang Linwen, Zhou Yi, Xiong Shaojun. This part is formulated for the first time.
CB/T21082.5--2007/ISO11568-5:1998 cited
GB/T21082 describes the process of secure management of keys used to protect messages such as between acquiring banks and card acceptors, or between acquiring banks and card issuers in a retail banking environment. Key management for integrated circuit cards is not included in the GB/T21082 standard. Given that key management in wholesale banking transaction environments is characterized by key exchange in a relatively high-security environment, the key management requirements described in this standard are applicable to accessible areas in retail banking services. Such typical services include debit and credit authorization at point of sale/point of service (POS) and ATM transactions. This part of GB/T 21082 describes the key life cycle in the security management of public key cryptographic systems. Public key cryptographic systems use public keys. These keys are collectively referred to as key pairs in this part of GB/T 21082. Chapter 4 states the common security requirements for each stage of the key pair life cycle, using the key management services and technologies described in 15011568-1:1994 and 15011568-4:1998. Chapter 5 specifies the requirements for the implementation of these security requirements in the following stages: Key life cycle package 1. Active phase Key pairs are generated and can be transmitted. 2. Active phase: During this period, public keys are distributed to at least one or more parties for use in support of the public key of the key pair, and the public key in the key pair is archived and the private key is terminated.
3. Post-activity phase
The life cycle of a private key (S) is shown in Figure 9 and the life cycle of a public key (P) is shown in Figure 1 and Figure 2, respectively. The specific operation of a key is to change its state. The key can be recognized as a single object, and a clear distinction can be made between multiple objects:
The figure shows that a key pair exists in multiple different locations in different forms before
. In the following operations, the public key is distributed to the communication party;
In the implementation method that is not capable of generating a key pair, the key pair is transmitted to its owner. In the case of the owner
destroying a single private key;
destroying the key from a given location, that is, destroying the key. At the termination of the private key, the key is deleted from the original location. TV
's food
includes
activation phase
activity phase
communication party 1
post-activity phase
destruction (S)
cancel
acquisition (s)
communication party 1 or the second
generation (P,8)
activity
storage (S)
backup
particular (S)
deletion
prohibition (S)
final correction
GB/T 21082. 5—2007/IS0 11568-5: 1998 Newly generated
Transmission (PS)Optional
Use P,)
Revoke (P)
Delete (S)
Figure 1 Private key life cycle
Revoked
(P,Figure 2)
Communicating party 2
Revocation information／
GB/T21082.5-2007/1SO 11568-5:1998 Special activity phase
(S, see Figure 2)
Communicating party 1 or third party
Generate (P, S)
Newly generated
Owned
Authenticated
Optional third party
Activity phase
Authentication (P)
Authenticated
Backed up
Communicating party 1
Cancel (P)
Post-activity phase
Revoked
Restore (P)
Accepted
Verified (S)
Archived
Owner (P)
Returned
Public key life cycle
Returned party 1
Storage (P)
Use (P, S)
1Scope
GB/T21082.5—2007/IS011568-51998 Banking Key Management (Retail) Part 5: Key Lifecycle of Public Key Cryptography This part describes in detail the security requirements in the retail banking environment, as well as the implementation methods for the private and public keys of asymmetric key pairs at each stage of the key lifecycle. This part is applicable to any institution that implements key management technology and manages public key cryptography systems for data protection.
2 Normative references
The clauses in the following documents become clauses of this standard through reference to this part of GB/T 21082. For any dated referenced document, all subsequent amendments (excluding errata) or revisions are not applicable to this part. However, parties to agreements based on this part are encouraged to study whether the latest versions of these documents can be used. For undated references, the latest versions apply to this part:
GB/T 17901.1—1999 Information technology security techniques Key management Part 1, Framework (idtIS0/IEC11770-1:1996)
GB/T 21082.4--2007
Banking key management (retail) Part 4: Key management techniques using public key cryptography
1S08908:1993 Vocabulary and data elements for banking and related financial services ISO95G1-1:2002 Management and security of personal identification numbers for banking Part 1: Principles and techniques for protecting personal identification numbers (PIV)
ISO 11568-1:1994
Banking key management (retail) Part 1: Introduction to key management 150 11568-2:1994
Key management for banking (quarterly announcements) Part 2: Key management techniques for symmetric cryptography ISO0O11568-3:1994: Key management for banking (retail) Part 3: Key lifecycle for symmetric cryptography IS0/IEC11770-3:1999 Information technology security techniques Key management Part 3: Mechanisms using asymmetric techniques IS013491 (all parts) Secure cryptographic equipment for banking (zero announcements) 3 Terms and definitions
The terms and definitions established in the ISO8908:1993 standard and the following apply to this part. 3.1
Asymmetric key pair generator A secure cryptographic device used to generate an asymmetric key pair. 3.2
Communicating party
The party that receives the public key and is used to communicate with the owner of the public key. 3.3
Independent communication refers to the process that allows an entity to reversely verify the correctness of the credentials and authentication documents before generating a certificate (for example: callback, visual authentication, etc.).
GB/T 21082.5—2007/ISO 11568-5:19984 General requirements
Each operation performed on the key changes the state of the key. This clause specifies the requirements for obtaining a specific state or performing a specific operation.
The requirements applicable to each stage of the life cycle are specified in the following subclauses. It is worth noting that the requirements thereafter may depend on the implementation process of generating the key pair. In particular, these requirements will be different when the key pair is generated by a third-party asymmetric key pair generator or when the key pair owner generates and stores his own key pair. 4.1 Generation of asymmetric key pairs
Generation of asymmetric key pairs is the process of generating a new key pair that can be used in a specific asymmetric cryptographic system, consisting of a private key and an associated public key. Other asymmetric key information may also be generated during this process: the input to this process may also require pre-set values.
Key pair generation should be completed by the owner of the key pair or his agent. Each private key component should be generated in such a way that it is not feasible to predict any private key or to determine that some private keys are more likely than others in the set of possible private keys: where appropriate, the process of generating private keys and private key components should be combined with random or pseudo-random values according to the characteristics of the symmetric cryptographic algorithm: Asymmetric key pairs should be generated in a way that ensures the confidentiality of private keys and the integrity of public keys. For asymmetric key pairs used for non-repudiation services, it should be possible to prove the integrity of the public key and the confidentiality of the private key to a third party. The private key should not be available to anyone in an understandable form at any time during the generation process. If the key pair is not used by the system, such as: a) after confirming that the transmission has been completed, the key pair and all related confidential seed elements should be deleted immediately; b) in addition, the integrity of the private key should be ensured.
Asymmetric key pairs should have a validity period when generated to establish the life cycle of the key pair. The key pair generation process should comply with the requirements specified in GB/T21082.4-2007. Note: Additional information, such as owner identity, key type, and validity period should be incorporated into the public key to avoid repudiation through public key replacement. 4.2 Authenticity before use
The authenticity of the public key should be ensured before use and throughout its life cycle. Appropriate assurance should be provided through certification. 4.3 Public key certification
Public key certification is the process of establishing proof of association between the public key and other related information and the owner through a trusted third party called a certification authority.
Key certification and certification authorities are detailed in GB/T21082.4-2007. The CA public key used to verify the certificate should be transmitted to the owner of the key pair in an authenticated manner. 4.4 Transmission of asymmetric key pairs
The transmission of asymmetric key pairs is the process of passing the key pair and public certificate to the owner of the key pair. This process occurs when the owner of the key does not have the ability to generate a key pair. The identity of the owner should be authenticated before the key pair is transmitted. 4.4.1 Transmission of private keys
Private keys can only be transmitted in one of the following forms specified in this section: a) plaintext private key,
h) private key component 1
e) encrypted private key.
4.4.1.1 Plaintext private key
The general requirements for transmitting and loading plaintext private keys are: a) The key transmission process should not disclose any part of the plaintext encryption; 2
GB/T 21082.5—2007/ISO 11568-5:1998b) The transmission and loading of keys shall be carried out in accordance with the principles of dual control and key segmentation; the plaintext private key may be transmitted only when the secure cryptographic device has authenticated at least two authorized persons, such as by means of a password; the plaintext private key may be loaded into the secure cryptographic device only when it is certain that the secure cryptographic device has not been subjected to any computational modification that may lead to the leakage of the key or sensitive data before use; the plaintext private key may be transmitted between secure cryptographic devices only when it is certain that there is no access device at the interface of the secure cryptographic device that may lead to the leakage of any element of the transmitted key; when a device is used to transmit the private key between the cryptographic device that generates the key and the cryptographic device that uses the key, this device shall be a secure cryptographic device. After the key is transferred to the Japanese standard equipment, the key transmission equipment should not retain any information that may leak the key.
4.4.1.2 Private key component
The general requirements for the transmission and loading of private key components are: a) The transmission process of the key component should not disclose any part of the key component to any unauthorized individual; b) The key component can only be loaded into the secure cryptographic device when it is confirmed that the secure cryptographic device has not been tampered with in any way that may cause the leakage of keys or sensitive data before use: The key component can only be transferred into the secure cryptographic device when it is confirmed that there is no stealing device at the interface of the secure cryptographic device that may cause the leakage of the transmitted component:
d) The transmission and loading process of the key should be carried out in accordance with the principles of dual control and key division. 4.4.1.3 Encrypted private key
The encrypted key can be automatically transmitted and loaded electronically through the communication channel. Encryption of the key using the secret encryption key should be performed in the secure cryptographic device.
In this case, the requirements described in ISO11568-2:1994 and GB/T21082.4-2007 should be used. The transmission process of encrypted private keys should prevent the secret from being replaced or changed. 4.4.2 Transmission of public keys
The transmission technology of public keys should ensure the authenticity of the keys. These technologies should be the same as those used in the transmission of private keys. 4.5 Key storage
During the storage of keys, unauthorized disclosure and replacement of keys should be prevented. Key distribution should be provided. The storage of private keys requires confidentiality and integrity. The storage of public keys requires authenticity and integrity. 4.5.1 Permitted private key forms
Private keys may only be stored in the forms defined in 4.4.1. 4.5.1.1 Plaintext private keys
Plaintext private keys may only exist in secure cryptographic devices. 4.5.1.2 Key components
Private keys in the form of at least two separate key components shall be protected in accordance with the principles of key separation and dual control. Each bit of the resulting key shall be a function of all the key components, and different key component patterns shall be used when the same key value must be generated on multiple occasions. If new components are generated, the values of any of these key components shall not be the same except by accident. Key components shall be accessible only to authorized individuals or groups of persons for the minimum time necessary. If a key component is in a human-understandable form (e.g. printed in plain text in a key envelope), then the component shall be known only to an authorized person at a point in time and for only the time required to enter the key component into the secure cryptographic device:
A person who has access to one component of a key cannot access any other component of the key. Key components should be stored in a manner that provides a high probability of detection of unauthorized access. If key components are stored in an encrypted form, all requirements for encrypted keys should apply. 4.5.1.3 Encrypted private keys
The encryption of keys using a secret encryption key should be performed in a secure cryptographic device. In this case, the requirements specified in ISO 11568-2:1991GB/T21082.4-2007 should apply. 4.5.2 Permitted public key forms
There is no confidentiality requirement for the storage of public keys in asymmetric cryptography, but authenticity and integrity are required. Any attempt to replace or modify any public key or related information should be detectable. In view of these requirements, public keys may only be stored in the following forms: a) plaintext within a certificate; b) encrypted, since the public key does not need to be kept confidential and the use of the encrypted component is accordingly not valuable. 4.5.2.1 Plaintext public keys If the public key is not authenticated, it should be stored in a manner that provides adequate protection to ensure that modifications to the key value and its identity can be detected. It is strongly recommended that the public key be authenticated when it is stored electronically. 4.5.2.2 Encrypted public keys Although confidentiality is not required for public keys, one way to ensure the authenticity and integrity of the public key is to store it in encrypted form. In this case, the requirements specified in ISO 11568-2:1994 and GB/T 21082.4-2007 should be used. 4.5.3 Protect the key from being replaced during storage When the plaintext public key is not stored in the form of a certificate, or its certificate has been verified and no certificate is required for use, the integrity and authenticity of the key should be guaranteed according to the method described in 5.5.3 and the technology described in GB/T21082.4-2007. 4.5.4 Provisions for key distribution
To ensure that a given key can only be used on a specified date, the key should be distributed according to the method specified in 5.5.4 and the technology described in GB/T21082.4-2007 (such as key tagging). 4.5.5 Key backup
Key backup is a copy of the stored key, the purpose of which is to restore the key when it is accidentally destroyed but there is no suspicion of leakage. The backup copy should be saved in one of the allowed key storage forms. The level of security control for all backup copies of private keys should be the same as or higher than that of the currently used keys:
If the backup copy of the private key is retained in a secure cryptographic device, access to the stored value should be controlled by effective user authentication (such as access identifiers and passwords or other means) to prevent unauthorized use of the key. 4.6 Key retrieval
The requirements for retrieving the public key from the backup are the same as the requirements for public key distribution described in 4.7, and the requirements for reinstalling the private key from the backup are the same as the requirements for private key transmission. 4.7 Public key distribution
Public key distribution is the process of transmitting the public key to the communication party who is ready to use the public key. The public key can be distributed manually or automatically through a communication channel. The process of distributing the public key should ensure the integrity and authenticity of the public key: the public key should be prevented from being replaced during the distribution process, preferably using key authentication methods. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public key certificate verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. The key verification will be described in 5.8. 4.9 Key use
GB/T21082.4-2007 describes the use of asymmetric private keys and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise specified, the following requirements apply to both keys of a key pair.
The unauthorized use of keys should be prevented, so: a) A key can only be used for one function; b) A key can only be used for the intended function in the intended location: The private key should exist in the minimum location to keep the system running effectively; d) At the end of the cryptographic period or when it is known or suspected that the private key has been leaked, the use of the key pair should be stopped; e) The public key can only be used when its authenticity and integrity have been verified and correct. 4.10 Public Key Registration
Public key registration is the process by which a key pair owner registers appropriate credentials and the corresponding public key with an authorized authority for the purpose of authenticity. It is worth noting that the authorized authority may be a certification authority that provides proof of authenticity using a public key certificate. Each country shall provide proof of authenticity for their public key. Key pair owners shall register their own public key with an organization such as a certification authority. 4.11 Revocation of Public Key
Revocation of public key is the process of terminating the use of a public key after the public key is generated and used. The public key shall no longer be used for revocation.
has a valid period that determines the life cycle of the key pair. When private information is discovered beyond the validity period, the corresponding key pair will be revoked.
The public key should be revoked in the following circumstances.
For various
reasons, the authorized entity can stop the use of asymmetric key pairs. In this case, the public key user
is notified that a public
key has been deleted and should immediately stop using the public key after receiving such notification. The revoked public key may need to be used to verify previously signed information
to be restored.
4.12 Key replacement
Key replacement should occur
a) Cryptographic period
t||When the validity period expires
b) when the disclosure is known or suspected
or when it is necessary
, the public key and private key of the key pair shall be replaced. If the key pair is used as a key encryption key, the keys under the key pair shall also be replaced in the case of key replacement. In the case of key replacement, the corresponding key certificate shall also be as specified in GB/T21082.4-2007 The key should be replaced within the time it is believed that a successful dictionary attack could be carried out on the data encrypted by the key, or within the time it takes to determine the private key through a cryptanalytic attack. This will depend on the specific implementation methods and technologies available at the time of the attack. If it is believed or known that the key used for decryption has been compromised, the communicating parties should be notified that the key pair should no longer be used. The key pair should be replaced in all operational locations where the key exists, and the replaced key should no longer be activated for use.
Key pairs should only be replaced by distributing new public keys. Key replacement requires the destruction of the old private key. 4.13 Destruction of private keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operational location so that the key can be restored to use at a later time. 1) The appropriate knowledge can be active, such as broadcasting to all public key users that a public key has been revoked, or it can be passive, such as publishing a revocation announcement in a normally accessible database.2 Key components
The privacy of a key in the form of at least two separate key components shall be protected according to the principles of key separation and dual control. Each bit of the resulting key shall be a function of all the key components, and different key component cases shall be used when the same key value must be generated on multiple occasions. If new components are generated, the value of any of these key components shall not be the same, except by accident. Key components shall be accessible only to authorized individuals or groups of persons for the shortest time necessary. If a key component is in a human-understandable form (e.g. printed in plain text in a key envelope), it shall be known only to an authorized person at a certain point in time, and only for the time required to enter the key component into a secure cryptographic device:
A person who has access to one component of a key cannot access any other component of the key. Key components shall be stored in a manner that provides a high probability of detection of unauthorized access. If the key components are stored in an encrypted form, all requirements for encrypted keys shall apply. 4.5.1.3 Encrypted private keys Encryption of keys using a cryptographic key shall be performed in a secure cryptographic device. In this case, the requirements specified in ISO 11568-2:1991 shall apply. 4.5.2 Permitted public key forms There is no requirement for confidentiality in the storage of public keys in asymmetric cryptography, but authenticity and integrity are required. Any attempt to replace or modify any public key or related information should be detectable. In view of these requirements, public keys can only be stored in the following forms: a) plaintext cryptography in certificates; b) encrypted keys, since the public key does not need to be kept confidential, the use of the cryptographic component is accordingly no longer valuable. 4.5.2.1 Plain public keys
If the public key is not authenticated, it should be stored in a manner that provides adequate protection to ensure that modifications to the key value and its identity can be detected. It is strongly recommended that the public key be authenticated when it is stored electronically. 4.5.2.2 Encrypted public keys
Although public keys do not need to be confidential, one way to ensure the authenticity and integrity of public keys is to store them in encrypted form. In this case, the requirements specified in ISO 11568-2:1994 and GB/T 21082.4-2007 should be used. 4.5.3 Protecting keys from being altered during storage When a plain public key is not stored in a certificated form, or its certificate has been verified and is not required for use without verification of the certificate, the integrity and authenticity of the key should be ensured according to the methods described in 5.5.3 and the techniques described in GB/T 21082.4-2007. 4.5.4 Provisions for key distribution
To ensure that a given key can only be used on a specified date, key distribution should be performed according to the methods specified in 5.5.4 and the techniques described in GB/T 21082.4-2007 (such as key tagging). 4.5.5 Key backup
A key backup is a copy of a stored key, the purpose of which is to restore the key when it is accidentally destroyed but not suspected of being leaked. The backup copy should be stored in one of the allowed key storage forms. The security control level of all backup copies of keys should be the same as or higher than that of the currently used keys:
If the backup copy of the private key is retained in a secure cryptographic device, effective user authentication (such as access identifiers and passwords or other means) should be used to control access to the stored value to prevent unauthorized use of the key. 4.6 Key retrieval
The requirements for retrieving a public key from a backup are the same as those for public key distribution described in 4.7, and the requirements for reinstalling a private key from a backup are the same as those for private key transmission. 4.7 Distribution of public keys
Public key distribution is the process of transmitting public keys to the communication parties who are ready to use the public keys. Public keys can be distributed manually or automatically through communication channels. The process of distributing public keys should ensure the integrity and authenticity of the public keys: the public keys should be prevented from being replaced during the distribution process, and it is best to use key authentication methods. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public key certificate verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. Key verification will be described in 5.8. 4.9 Use of keys
GB/T21082.4-2007 describes the use of asymmetric private keys and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise stated, the following requirements apply to both keys of a key pair.
Unauthorized use of keys should be prevented so that: a) a key can only be used for one function; b) a key can only be used for its intended function in the intended location; private keys should exist in the minimum number of locations necessary to keep the system running effectively; d) key pair usage should be stopped at the end of the cryptographic period or when the private key is known or suspected to have been compromised; e) public keys may only be used if their authenticity and integrity have been verified and are correct. 4.10 Public Key Registration
Public key registration is the process by which the owner of a key pair registers appropriate credentials and the corresponding public key with an authorized authority for the purpose of authenticity. It is worth noting that the authorized authority can be a certification authority that provides proof of authenticity using public key certificates. Each country provides proof of the authenticity of their public key. The key pair owner shall register their own public key with the key pair owner organization, such as the certification authority. 4.11 Revocation of public key The revocation of public key is due to the following reasons: a) public key has been leaked b) private key has been leaked c) various business reasons. The public key shall no longer be used when it is generated and revoked. There is a specific period that determines the life cycle of the key pair. When the private key is found to be infected, the corresponding key shall be revoked. In the following cases, the public key shall be revoked.
For various
reasons, an authorized entity
may discontinue the use of an asymmetric key pair. In this case, a public key user
is informed that a public
key has been revoked and should immediately discontinue use of the public key upon receipt of such notification. The revoked public key may need to be restored to verify previously signed messages.
4.12 Key Changes
Key changes should occur
a) Cryptographic Period||t t||When the validity period expires
b) when the disclosure is known or suspected
or when it is necessary
, the public key and private key of the key pair shall be replaced. If the key pair is used as a key encryption key, the keys under the key pair shall also be replaced in the case of key replacement. In the case of key replacement, the corresponding key certificate shall also be as specified in GB/T21082.4-2007 The key should be replaced within the time it is believed that a successful dictionary attack could be carried out on the data encrypted by the key, or within the time it takes to determine the private key through a cryptanalytic attack. This will depend on the specific implementation methods and technologies available at the time of the attack. If it is believed or known that the key used for decryption has been compromised, the communicating parties should be notified that the key pair should no longer be used. The key pair should be replaced in all operational locations where the key exists, and the replaced key should no longer be activated for use.
Key pairs should only be replaced by distributing new public keys. Key replacement requires the destruction of the old private key. 4.13 Destruction of private keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operational location so that the key can be restored to use at a later time. 1) The appropriate notification can be active, such as broadcasting to all public key users that a public key has been revoked, or it can be passive, such as publishing a revocation announcement in a normally accessible database.2 Key components
The privacy of a key in the form of at least two separate key components shall be protected according to the principles of key separation and dual control. Each bit of the resulting key shall be a function of all the key components, and different key component cases shall be used when the same key value must be generated on multiple occasions. If new components are generated, the value of any of these key components shall not be the same, except by accident. Key components shall be accessible only to authorized individuals or groups of persons for the shortest time necessary. If a key component is in a human-understandable form (e.g. printed in plain text in a key envelope), it shall be known only to an authorized person at a certain point in time, and only for the time required to enter the key component into a secure cryptographic device:
A person who has access to one component of a key cannot access any other component of the key. Key components shall be stored in a manner that provides a high probability of detection of unauthorized access. If the key components are stored in an encrypted form, all requirements for encrypted keys shall apply. 4.5.1.3 Encrypted private keys Encryption of keys using a cryptographic key shall be performed in a secure cryptographic device. In this case, the requirements specified in ISO 11568-2:1991 shall apply. 4.5.2 Permitted public key forms There is no requirement for confidentiality in the storage of public keys in asymmetric cryptography, but authenticity and integrity are required. Any attempt to replace or modify any public key or related information should be detectable. In view of these requirements, public keys can only be stored in the following forms: a) plaintext cryptography in certificates; b) encrypted keys, since the public key does not need to be kept confidential, the use of the cryptographic component is accordingly no longer valuable. 4.5.2.1 Plain public keys
If the public key is not authenticated, it should be stored in a manner that provides adequate protection to ensure that modifications to the key value and its identity can be detected. It is strongly recommended that the public key be authenticated when it is stored electronically. 4.5.2.2 Encrypted public keys
Although public keys do not need to be confidential, one way to ensure the authenticity and integrity of public keys is to store them in encrypted form. In this case, the requirements specified in ISO 11568-2:1994 and GB/T 21082.4-2007 should be used. 4.5.3 Protecting keys from being altered during storage When a plain public key is not stored in a certificated form, or its certificate has been verified and is not required for use without verification of the certificate, the integrity and authenticity of the key should be ensured according to the methods described in 5.5.3 and the techniques described in GB/T 21082.4-2007. 4.5.4 Provisions for key distribution www.bzxz.net
To ensure that a given key can only be used on a specified date, key distribution should be performed according to the methods specified in 5.5.4 and the techniques described in GB/T 21082.4-2007 (such as key tagging). 4.5.5 Key backup
A key backup is a copy of a stored key, the purpose of which is to restore the key when it is accidentally destroyed but not suspected of being leaked. The backup copy should be stored in one of the allowed key storage forms. The security control level of all backup copies of keys should be the same as or higher than that of the currently used keys:
If the backup copy of the private key is retained in a secure cryptographic device, effective user authentication (such as access identifiers and passwords or other means) should be used to control access to the stored value to prevent unauthorized use of the key. 4.6 Key retrieval
The requirements for retrieving a public key from a backup are the same as those for public key distribution described in 4.7, and the requirements for reinstalling a private key from a backup are the same as those for private key transmission. 4.7 Distribution of public keys
Public key distribution is the process of transmitting public keys to the communication parties who are ready to use the public keys. Public keys can be distributed manually or automatically through communication channels. The process of distributing public keys should ensure the integrity and authenticity of the public keys: the public keys should be prevented from being replaced during the distribution process, and it is best to use key authentication methods. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public key certificate verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. Key verification will be described in 5.8. 4.9 Use of keys
GB/T21082.4-2007 describes the use of asymmetric private keys and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise stated, the following requirements apply to both keys of a key pair.
Unauthorized use of keys should be prevented so that: a) a key can only be used for one function; b) a key can only be used for its intended function in the intended location; private keys should exist in the minimum number of locations necessary to keep the system running effectively; d) key pair usage should be stopped at the end of the cryptographic period or when the private key is known or suspected to have been compromised; e) public keys may only be used if their authenticity and integrity have been verified and are correct. 4.10 Public Key Registration
Public key registration is the process by which the owner of a key pair registers appropriate credentials and the corresponding public key with an authorized authority for the purpose of authenticity. It is worth noting that the authorized authority can be a certification authority that provides proof of authenticity using public key certificates. Each country provides proof of the authenticity of their public key. The key pair owner shall register their own public key with the key pair owner organization, such as the certification authority. 4.11 Revocation of public key The revocation of public key is due to the following reasons: a) public key has been leaked b) private key has been leaked c) various business reasons. The public key shall no longer be used when it is generated and revoked. There is a specific period that determines the life cycle of the key pair. When the private key is found to be infected, the corresponding key shall be revoked. In the following cases, the public key shall be revoked.
For various
reasons, an authorized entity
may discontinue the use of an asymmetric key pair. In this case, a public key user
is informed that a public
key has been revoked and should immediately discontinue use of the public key upon receipt of such notification. The revoked public key may need to be restored to verify previously signed messages.
4.12 Key Changes
Key changes should occur
a) Cryptographic Period||t t||When the validity period expires
b) when the disclosure is known or suspected
or when it is necessary
, the public key and private key of the key pair shall be replaced. If the key pair is used as a key encryption key, the keys under the key pair shall also be replaced in the case of key replacement. In the case of key replacement, the corresponding key certificate shall also be as specified in GB/T21082.4-2007 The key should be replaced within the time it is believed that a successful dictionary attack could be carried out on the data encrypted by the key, or within the time it takes to determine the private key through a cryptanalytic attack. This will depend on the specific implementation methods and technologies available at the time of the attack. If it is believed or known that the key used for decryption has been compromised, the communicating parties should be notified that the key pair should no longer be used. The key pair should be replaced in all operational locations where the key exists, and the replaced key should no longer be activated for use.
Key pairs should only be replaced by distributing new public keys. Key replacement requires the destruction of the old private key. 4.13 Destruction of private keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operational location so that the key can be restored to use at a later time. 1) The appropriate knowledge can be active, such as broadcasting to all public key users that a public key has been revoked, or it can be passive, such as publishing a revocation announcement in a normally accessible database.13 Destruction of Private Keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operating location so that the key can be restored for use in the future. 1) This can be active, such as broadcasting to all public key users that a public key has been revoked, or passive, such as publishing a revocation notice in a normally accessible database.13 Destruction of Private Keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operating location so that the key can be restored for use in the future. 1) This can be active, such as broadcasting to all public key users that a public key has been revoked, or passive, such as publishing a revocation notice in a normally accessible database.5—2007/ISO 11568-5:1998 All requirements for encrypted private keys shall apply. 4.5.1.3 Encrypted private keys
Encryption of private keys using encrypted private keys shall be performed in secure cryptographic devices. In this case, the requirements specified in ISO°11568-2:1991 GB/T21082.4-2007 shall apply. 4.5.2 Permissible public key forms
There is no requirement for confidentiality in the storage of public keys in asymmetric cryptography, but authenticity and integrity are required. Any attempt to replace or modify any public key or related information should be detectable. In view of these requirements, public keys can only be stored in the following forms: a) plaintext encrypted in certificates;
b) encrypted keys,
Since the public key does not need to be kept confidential, the use of the encrypted component is accordingly no longer valuable. 4.5.2.1 Plain public keys
If the public key is not authenticated, it should be stored in a manner that provides adequate protection to ensure that modifications to the key value and its identity can be detected. It is strongly recommended that the public key be authenticated when it is stored electronically. 4.5.2.2 Encrypted public keys
Although public keys do not need to be confidential, one way to ensure the authenticity and integrity of public keys is to store them in encrypted form. In this case, the requirements specified in ISO 11568-2:1994 and GB/T 21082.4-2007 should be used. 4.5.3 Protecting keys from being altered during storage When a plain public key is not stored in a certificated form, or its certificate has been verified and is not required for use without verification of the certificate, the integrity and authenticity of the key should be ensured according to the methods described in 5.5.3 and the techniques described in GB/T 21082.4-2007. 4.5.4 Provisions for key distribution
To ensure that a given key can only be used on a specified date, key distribution should be performed according to the methods specified in 5.5.4 and the techniques described in GB/T 21082.4-2007 (such as key tagging). 4.5.5 Key backup
A key backup is a copy of a stored key, the purpose of which is to restore the key when it is accidentally destroyed but not suspected of being leaked. The backup copy should be stored in one of the allowed key storage forms. The security control level of all backup copies of keys should be the same as or higher than that of the currently used keys:
If the backup copy of the private key is retained in a secure cryptographic device, effective user authentication (such as access identifiers and passwords or other means) should be used to control access to the stored value to prevent unauthorized use of the key. 4.6 Key retrieval
The requirements for retrieving a public key from a backup are the same as those for public key distribution described in 4.7, and the requirements for reinstalling a private key from a backup are the same as those for private key transmission. 4.7 Distribution of public keys
Public key distribution is the process of transmitting public keys to the communication parties who are ready to use the public keys. Public keys can be distributed manually or automatically through communication channels. The process of distributing public keys should ensure the integrity and authenticity of the public keys: the public keys should be prevented from being replaced during the distribution process, and it is best to use key authentication methods. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public key certificate verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. Key verification will be described in 5.8. 4.9 Use of keys
GB/T21082.4-2007 describes the use of asymmetric private keys and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise stated, the following requirements apply to both keys of a key pair.
Unauthorized use of keys should be prevented so that: a) a key can only be used for one function; b) a key can only be used for its intended function in the intended location; private keys should exist in the minimum number of locations necessary to keep the system running effectively; d) key pair usage should be stopped at the end of the cryptographic period or when the private key is known or suspected to have been compromised; e) public keys may only be used if their authenticity and integrity have been verified and are correct. 4.10 Public Key Registration
Public key registration is the process by which the owner of a key pair registers appropriate credentials and the corresponding public key with an authorized authority for the purpose of authenticity. It is worth noting that the authorized authority can be a certification authority that provides proof of authenticity using public key certificates. Each country provides proof of the authenticity of their public key. The key pair owner shall register their own public key with the key pair owner organization, such as the certification authority. 4.11 Revocation of public key The revocation of public key is due to the following reasons: a) public key has been leaked b) private key has been leaked c) various business reasons. The public key shall no longer be used when it is generated and revoked. There is a specific period that determines the life cycle of the key pair. When the private key is found to be infected, the corresponding key shall be revoked. In the following cases, the public key shall be revoked.
For various
reasons, an authorized entity
may discontinue the use of an asymmetric key pair. In this case, a public key user
is informed that a public
key has been revoked and should immediately discontinue use of the public key upon receipt of such notification. The revoked public key may need to be restored to verify previously signed messages.
4.12 Key Changes
Key changes should occur
a) Cryptographic Period||t t||When the validity period expires
b) when the disclosure is known or suspected
or when it is necessary
, the public key and private key of the key pair shall be replaced. If the key pair is used as a key encryption key, the keys under the key pair shall also be replaced in the case of key replacement. In the case of key replacement, the corresponding key certificate shall also be as specified in GB/T21082.4-2007 The key should be replaced within the time it is believed that a successful dictionary attack could be carried out on the data encrypted by the key, or within the time it takes to determine the private key through a cryptanalytic attack. This will depend on the specific implementation methods and technologies available at the time of the attack. If it is believed or known that the key used for decryption has been compromised, the communicating parties should be notified that the key pair should no longer be used. The key pair should be replaced in all operational locations where the key exists, and the replaced key should no longer be activated for use.
Key pairs should only be replaced by distributing new public keys. Key replacement requires the destruction of the old private key. 4.13 Destruction of private keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operational location so that the key can be restored to use at a later time. 1) The appropriate knowledge can be active, such as broadcasting to all public key users that a public key has been revoked, or it can be passive, such as publishing a revocation announcement in a normally accessible database.5—2007/ISO 11568-5:1998 All requirements for encrypted private keys shall apply. 4.5.1.3 Encrypted private keys
Encryption of private keys using encrypted private keys shall be performed in secure cryptographic devices. In this case, the requirements specified in ISO°11568-2:1991 GB/T21082.4-2007 shall apply. 4.5.2 Permissible public key forms
There is no requirement for confidentiality in the storage of public keys in asymmetric cryptography, but authenticity and integrity are required. Any attempt to replace or modify any public key or related information should be detectable. In view of these requirements, public keys can only be stored in the following forms: a) plaintext encrypted in certificates;
b) encrypted keys,
Since the public key does not need to be kept confidential, the use of the encrypted component is accordingly no longer valuable. 4.5.2.1 Plain public keys
If the public key is not authenticated, it should be stored in a manner that provides adequate protection to ensure that modifications to the key value and its identity can be detected. It is strongly recommended that the public key be authenticated when it is stored electronically. 4.5.2.2 Encrypted public keys
Although public keys do not need to be confidential, one way to ensure the authenticity and integrity of public keys is to store them in encrypted form. In this case, the requirements specified in ISO 11568-2:1994 and GB/T 21082.4-2007 should be used. 4.5.3 Protecting keys from being altered during storage When a plain public key is not stored in a certificated form, or its certificate has been verified and is not required for use without verification of the certificate, the integrity and authenticity of the key should be ensured according to the methods described in 5.5.3 and the techniques described in GB/T 21082.4-2007. 4.5.4 Provisions for key distribution
To ensure that a given key can only be used on a specified date, key distribution should be performed according to the methods specified in 5.5.4 and the techniques described in GB/T 21082.4-2007 (such as key tagging). 4.5.5 Key backup
A key backup is a copy of a stored key, the purpose of which is to restore the key when it is accidentally destroyed but not suspected of being leaked. The backup copy should be stored in one of the allowed key storage forms. The security control level of all backup copies of keys should be the same as or higher than that of the currently used keys:
If the backup copy of the private key is retained in a secure cryptographic device, effective user authentication (such as access identifiers and passwords or other means) should be used to control access to the stored value to prevent unauthorized use of the key. 4.6 Key retrieval
The requirements for retrieving a public key from a backup are the same as those for public key distribution described in 4.7, and the requirements for reinstalling a private key from a backup are the same as those for private key transmission. 4.7 Distribution of public keys
Public key distribution is the process of transmitting public keys to the communication parties who are ready to use the public keys. Public keys can be distributed manually or automatically through communication channels. The process of distributing public keys should ensure the integrity and authenticity of the public keys: the public keys should be prevented from being replaced during the distribution process, and it is best to use key authentication methods. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public key certificate verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. Key verification will be described in 5.8. 4.9 Use of keys
GB/T21082.4-2007 describes the use of asymmetric private keys and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise stated, the following requirements apply to both keys of a key pair.
Unauthorized use of keys should be prevented so that: a) a key can only be used for one function; b) a key can only be used for its intended function in the intended location; private keys should exist in the minimum number of locations necessary to keep the system running effectively; d) key pair usage should be stopped at the end of the cryptographic period or when the private key is known or suspected to have been compromised; e) public keys may only be used if their authenticity and integrity have been verified and are correct. 4.10 Public Key Registration
Public key registration is the process by which the owner of a key pair registers appropriate credentials and the corresponding public key with an authorized authority for the purpose of authenticity. It is worth noting that the authorized authority can be a certification authority that provides proof of authenticity using public key certificates. Each country provides proof of the authenticity of their public key. The key pair owner shall register their own public key with the key pair owner organization, such as the certification authority. 4.11 Revocation of public key The revocation of public key is due to the following reasons: a) public key has been leaked b) private key has been leaked c) various business reasons. The public key shall no longer be used when it is generated and revoked. There is a specific period that determines the life cycle of the key pair. When the private key is found to be infected, the corresponding key shall be revoked. In the following cases, the public key shall be revoked.
For various
reasons, an authorized entity
may discontinue the use of an asymmetric key pair. In this case, a public key user
is informed that a public
key has been revoked and should immediately discontinue use of the public key upon receipt of such notification. The revoked public key may need to be restored to verify previously signed messages.
4.12 Key Changes
Key changes should occur
a) Cryptographic Period||t t||When the validity period expires
b) when the disclosure is known or suspected
or when it is necessary
, the public key and private key of the key pair shall be replaced. If the key pair is used as a key encryption key, the keys under the key pair shall also be replaced in the case of key replacement. In the case of key replacement, the corresponding key certificate shall also be as specified in GB/T21082.4-2007 The key should be replaced within the time it is believed that a successful dictionary attack could be carried out on the data encrypted by the key, or within the time it takes to determine the private key through a cryptanalytic attack. This will depend on the specific implementation methods and technologies available at the time of the attack. If it is believed or known that the key used for decryption has been compromised, the communicating parties should be notified that the key pair should no longer be used. The key pair should be replaced in all operational locations where the key exists, and the replaced key should no longer be activated for use.
Key pairs should only be replaced by distributing new public keys. Key replacement requires the destruction of the old private key. 4.13 Destruction of private keys
When an instance of a private key is no longer required to be in active use, it should be destroyed. Electronic instances of private keys can be destroyed by erasing. However, information will still reside in the operational location so that the key can be restored to use at a later time. 1) The appropriate knowledge can be active, such as broadcasting to all public key users that a public key has been revoked, or it can be passive, such as publishing a revocation announcement in a normally accessible database.3 and the techniques described in GB/T 21082.4-2007 to ensure the integrity and authenticity of the key. 4.5.4 Provisions for key dispersion
To ensure that a given key can only be used on a specified date, key dispersion should be carried out according to the methods specified in 5.5.4 and the techniques described in GB/T 21082.4-2007 (such as key tagging). 4.5.5 Key backup
Key backup is a copy of the stored key, the purpose of which is to restore the key when it is accidentally destroyed but not suspected of being leaked. The backup copy should be stored in one of the allowed key storage forms. The security control level of all backup copies of the private key should be the same as or higher than that of the currently used key:
If the backup copy of the private key is retained in a secure cryptographic device, effective user authentication (such as access identifier and password or other means) should be used to control access to the stored value to prevent unauthorized use of the key. 4.6 Key Retrieval
The requirements for retrieving a public key from a backup are the same as those for public key distribution described in 4.7, and the requirements for reinstalling a private key from a backup are the same as those for private key transmission. 4.7 Public Key Distribution
Public key distribution is the process of transmitting a public key to a communication party that is ready to use the public key. Public keys can be distributed manually or automatically through a communication channel. The process of distributing public keys should ensure the integrity and authenticity of the public key: the public key should be prevented from being replaced during the distribution process, and it is best to use a key authentication method. Note: Key authentication is described in GB/T210B2.4:—2007. 4.8 Public Key Certificate Verification
The public key certificate verification process refers to the communication party verifying that the received public key belongs to the intended owner and will be used for the specified purpose. Key verification will be described in 5.8. 4.9 Use of keys
GB/T21082.4-2007 describes the use of asymmetric private and public keys. 4
GB/T21082.5-2D07/ISO11568-5:1998 In an asymmetric cryptographic system, each key in a key pair is used for a separate function. Unless otherwise specified, the following requirements apply to both keys of a key pair.
Unauthorized use of keys should be prevented, so: a) a key can only be used for one function; b) a key can only be used for the intended function in the intended location; the private key should exist in the minimum location to keep the system running effectively; d) the use of the key pair should be stopped at the end of the cryptographic period or when it is known or suspected that the private key has been leaked; e) the public key can only be used when its authenticity and integrity have been verified and are correct. 4.10 Public key registration
Public key registration is the process by which the key pair owner registers the appropriate credentials and the corresponding public key with the authorized agency for the purpose of authenticity. It is worth noting that the authorized institution can be a certification body that provides authenticity proof using a public key certificate. Each country provides authenticity proof of their public key. Key pair owners should register their own public keys with the key pair owner institution, such as the certification body. 4.11 Revocation of public keys Revocation of public keys is due to the following reasons: a) public key is leaked b) private key is leaked c) various business reasons. The process of revocation is to terminate the use of public keys. The public key should no longe
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.