Some standard content:
ICS 35. 240. 40
National Standard of the People's Republic of China
GB/T 21081—2007/IS0 13492:1998 Banking-Key management related data element (retail)
Banking-Key management related data element (retail) (IS0 13492:1998, IDT)
2007-09-05 Issued
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China Standardization Administration of the People's Republic of China
2007-12-01 Implementation
1 Scope
2 Normative references
3 Terms and definitions
4 Requirements for data elements related to key management
4.1 Concept of key set identifier
4.2 Allocation of key nest identifiers
5 Implementation in ISO 8583:1993
Annex A (Informative) Application of data elements related to transmission key management Annex B (Informative) Virtual example of key set identifier - KAONTKAca=
GB/T 21081-2007/TSO 13492:1998 Foreword
GB/T 21081—2007/ISO 13492:1998 This standard is equivalent to the international standard IS013492:1998 % Cryptographic Related Data Elements (Retail) 8 (English version). For ease of use, the following editorial changes have been made to ISO13492: a) International standards cited in normative references, if there are corresponding national standards, are replaced by national standards. b) The foreword of international standards is deleted.
Appendix A and Appendix B of this standard are informative appendices. This standard is proposed by the People's Bank of China.
This standard is under the jurisdiction of the National Financial Standardization Technical Committee. The responsible drafting unit of this standard is China Financial Electronicization Company. The participating drafting units of this standard are: People's Bank of China, Industrial and Commercial Bank of China, Agricultural Bank of China, China Merchants Bank, China UnionPay Co., Ltd., North China Institute of Computing Technology, and Venusstar Limited. The main drafters of this standard are: Tan Guoan, Yang Zi, Lu Shuchun, Li Shuguang, Wang Linli, Zhou Yipeng, Lin Zhong, Zhang Qirui, Shi Yongheng, Zhao Hongxin, Li Hongxin, Xu Wei, Zhang Yan, Dong Yongle, Xiong Shaojun, Huang Faguo, Li Jianyun. This standard was formulated by the first European Union.
GB/T21081-2007/IS013492:1998 cited
-iikAoNi kAca=
This standard describes the structure and content of key management related data elements, which can be transmitted through electronic messages in the retail banking environment to support the security management of keys. The retail banking environment includes the communication between the card receiving device and the acquiring bank, and the acquiring bank and the card issuer. The key management of the keys and related data elements used in the integrated circuit card is not applicable to this standard. This standard is compatible with the current ISO standard for bank card messages (see ISO8583).
1 Scope
GB/T21081—2007/IS013492:1998 Data Elements Related to Key Management for Banking Services (Retail) This standard specifies data elements related to key management, which are either transmitted in transaction messages (used to protect key information for current transactions) or in encryption service messages (used to protect key information for future transactions). This standard describes the requirements for applying key management related data elements within the scope of ISO8583:1993, and the following two I508583:1993 data elements should be used: security-related control information (53 bits) or key management data (96 bits). However, the transmission of key management related data is not limited to the ISO8583:1993 standard, and this standard is applicable to symmetric and asymmetric cryptographic systems. ISO11568 describes the key security management process in the zero-report banking environment. ISO9561 and ISO9807 describe security-related data, such as PIN and MAC, respectively.
2 Normative References
The clauses in the following documents become the clauses of this standard through reference in this standard. For all referenced documents with dates, all subsequent amendments (excluding incorrect insertion) or revisions are not applicable to this standard. However, parties that reach an agreement based on this standard are encouraged to study whether the latest versions of these documents can be used. For all referenced documents without dates, the latest versions are applicable to this standard. GB/T15694.1:1995 Identification card issuer identification Part 1: Numbering system (idtISO/IEC7812-1:1993)ISO/IEC7812-2:1993 Identification card issuer identification Part 2: Telephone application and registration proceduresISO 8583:1993
3 Financial transaction card exchange message specification for generating messages1SO 8908:1993
Banking and related financial services vocabulary and data elementsISO9561-1:1991 Management and security of personal identification numbers Part 1: PIN protection principles and techniquesBanking and related financial services message identification requirements (retail)1S09807:19914
ISO 11568-1:1994
Banking key copper management (retail) Part 1: Introduction to key managementISO 11568-2: 1994
1S0 11568-3:1994
Key management for banking (retail) Part 2: Key management techniques for symmetric ciphersKey management for banking (retail) Part 3: Key lifecycle for symmetric ciphersANSI X3, 92.1987
Data encryption algorithms
3 Terms and definitions
The terms and definitions given in ISO 8908:1993 and the following apply to this standard:3. 1
asymmetric cipher
asymmetric cipher
the encryption key is different from the decryption key and it is not computationally feasible to derive the decryption key from the encryption key:3.2
ciphercipher
a set of operations that perform conversions between plaintext and ciphertext or vice versa, under the control of parameters called keys. NOTE: An encryption operation is the conversion of data (plaintext) into an incomprehensible form (ciphertext). Decryption operation is the recovery of ciphertext into plaintext. 3.3
Cryptographic algorithm specifies a set of rules for implementing the encryption and decryption process of data. Past: The algorithm is designed so that it is impossible to determine the control number (such as the key) except through exhaustive search1
GB/T210812007/IS0 13492:19983.4
Cryptographic keycryptographic key
Key key
refers to the control parameter of the cryptographic algorithm that cannot be derived from the input and output data except through exhaustive search. 3.5
Cryptographic service messagecryptographic service messageA message that transmits keys or information related to control key relationships3.6
Primary keyprimary key
A key used to generate other keys in a transaction (for example, in a deformed or transformed manner). 3.7
symmetric eiphey
symmetric cipher
a cryptographic method that uses the same cipher to encrypt and decrypt.
transaction message tran
a message used to transmit related
message
is information.
4Requirements for key management related data elements
a transaction
transmits
KAONi
KAca-
related key management related data elements are usually divided into several sub-fields. This data element can be transmitted in the transaction between the communicating parties
in this transaction environment, the data element is a private domain
sub-field of the private domain is defined in a way agreed by the parties
and must be organized in a standardized way to support interoperability, but exchange.
For the exchange, the parties can use
Key management related data
Domain characteristics are not urgent transaction environment, in the environment outside, both types of transactions can be carried out. In order to distinguish between transactions using standardized representation methods and key management related data elements for private purposes, the first byte of the key management related data element should be constructed as
Special byte", open as follows
00-9F: The first sub-city of the key management data element is the exchangeable long key set identifier, see the definition in 4.1 and 4.2 for details.
A private field, where the sub-city is implicitly AO-FF: Key Management Related Data Element is a key set identifier that provides a standardized approach to managing key management information types for management systems using key set identifiers. This approach does not require the identification of specific key management technologies, nor does it require the specification of special subfields to meet the requirements of each technology. When the key management related data set identifier begins, the remainder of the data element contains new data for cryptographic processing of the transaction. The remaining bytes contain no specific structure for the subfields. Any information required to change the key on a per-transaction basis. Therefore, the information in the key set identifier is not a specific key management technology. All information will be transmitted with the key set identifier. This information may include the identification of one or more specific keys within a key set.
Key management related information that does not change from one transaction to the next does not need to be transmitted with each transaction, but can be installed and stored implicitly or with the corresponding keys. Examples of implicit information include the following: a) Key management technology used for transaction keys (e.g. static keys, unique keys for each transaction); encrypted or authenticated data format (e.g. PINBLOCK format); b)
The encryption algorithm used; || tt||d) The number of different keys used in the transaction and the purpose of each key. Unlock
In some key management schemes, it is not necessary to transmit key management related data elements in the transaction message. If such data elements need to be transmitted, please refer to the description in Appendix A for details. 4.1 Concept of key set identifier
A key set identifier is a value that can uniquely identify a key set, where a key set is a collection of related keys that are different but share some common features. The most obvious feature is: R) All keys are managed using the same key management method: GB/T 21081—2007/IS0 13492 : 1998b) All keys in a key set are encrypted (for database storage) or derived using the same high-level key: For all keys in a key set, the remaining bytes of the key management related data element (except the key set identifier) are constructed in the same way and interpreted by the same logic. The processing logic (e.g., computer software) on the acquirer host associated with any given key set can interpret the key management related data element to determine which keys are used in a transaction and how each key is used. Multiple key sets with different key set identifiers can use exactly the same processing logic, differing only in the key encryption key or root key used to decrypt or derive keys for the associated transaction. The first byte of the key set identifier is the control byte 00-9F. The assignment of key set identifiers is described in Section 4.2. The length of the key set identifier is variable, and there is no specified maximum length. The length of the key set identifier is implicit. Therefore, the key management related data element should not contain a "length" subfield before the key set identifier to indicate the length of the key set identifier. Similarly, no specific delimiter is required after the key set identifier. If the key management related data element is transmitted in a variable length field, the key management related data element may be preceded by a length field indicating the length of the entire number, see 583.1993. Since the key set identifier has a variable length for security related control information and key management data, and the length is implicit, the acquirer host may store the length of each identified key set identifier in the customer key set identifier table. For example, when the acquirer receives a transaction from a POS terminal, the host may match the key set identifier with the leftmost key management related data element in such a table entry. The key management related data element is matched to the specified length of the specific table entry. The table entry contains the key set identifier used for the key management related data element just received. 4.2 Key set identifier allocation To prevent duplicate assignment of key set identifiers, the key set identifier shall be allocated using the six-digit issuer identification code (IIN) according to TSO7812 or the six-digit institution identification code (IIC) according to d8583:1993. The ISO registration authority allocates the issuer identification code (IIN) to the issuing institution and the institution identification code (IIC) to the non-issuing institution. Since the issuer identification code (IN) and the institution identification code (IIC) are combined in the environment, they are unique in their respective environments, and the two sets of codes will not be re-selected, which ensures that if two password rings are repeated, they are still unique.
's key set identifier In a closed environment, organizations that wish to obtain a key set identifier but have not been assigned an IN or IIC code can also obtain an identifier from an organization that has been assigned an IIV or IIC. Such an organization should ensure that it does not assign a flexible key set identifier.
's issuer identification code (I)
If the organization does not need
or the organization identification code (IC) to complete more key set identifiers, the organization can directly use the issuer identification code (NIN) or the organization identification code (IC) as the key set identifier. If the organization needs additional key set identifiers, it should be
's issuer identification code (IIN) or more hexadecimal digits and concatenate them to the right of the IIN or the organization identification code (IC) to obtain multiple key set identifiers. The organization that assigns key set identifiers shall choose how many digits to concatenate with its IIN or IIC to obtain the key set identifier before assigning any key set identifier based on TTN or HIC. For example, if an organization uses a 7-digit key set identifier by concatenating a digit to the IIN or IC, then after all the first 6 such 7-digit digits have been used, the eighth digit cannot be added to obtain more key set identifiers. This is because the first 7 digits of such an 8-digit key set identifier still match the key set identifiers that have been assigned. For example, if the 7-digit key set identifier "1362047" already exists, the 8-digit key set identifier "13620475" is not allowed to exist, and vice versa, because one key set identifier is completely contained in the other key set identifier. For detailed application examples of key set identifiers, please refer to Appendix B.
5 Implementation in ISO8583:1993
When the key management related data elements specified in Chapter 1 are used together with ISO8583:1993 to convey the key management information of the current transaction message, the content of the key management related data elements shall be transmitted by using the ISO8583:1993 security related control information. The control information is a variable length binary data element with a maximum of 48 bytes. 3
GB/T21081--2007/IS013492:1998-ir KAoNi kAca=
Note 1: Examples of ISO8583:1993 messages that transmit security related control information are as follows: a request for a rights or financial transaction containing a personal identification number (PIN) data (52 bits), or a file operation, or a message containing aWhen the key management related data element is used together with ISO8583:1993 in the cryptographic service message to transmit the key information for future use, the ISO8583:1993 key management data shall be used to transmit the content of the key management related data element. The ISO8583:1993 key management data is a variable length escaped data element of up to 999 bytes. NOTE 2 Examples of messages transmitting cryptographic management data are as follows: Network management request or response, which is used to confirm the synchronization of the current cryptographic key or to rely on the key for future use: A. 1 Purpose of transmitted data Appendix A (Informative Appendix) GB/T21081--2007/IS013492:1998 Application of data elements related to key management Transmitting key management related information in transaction messages has two main purposes: a) identifying the key used to protect the current transaction message (usually only a single master key needs to be verified); b) transmitting key information used to protect future transaction messages. The second use is mainly related to the master key (or "transaction" key), or the first session key technology. It should be noted that the transmitted information is either a new session key encrypted with the master key (a new master key encrypted with the "working" key). In standard retail banking systems, master key session encryption technology is of great value when the master key is less vulnerable to penetration attacks or!
h) Upon successful decryption of the new session key, the master key itself is replaced (e.g. by transmitting a new master key encrypted under the old master key). Since this is not particularly efficient, key replacement situations are likely to occur very frequently (e.g., no more frequently than several hours), and future key information is not transmitted. For example, K follows the instructions in ISO
8583:1993 if used A.2 Data Description When two parties exchange encrypted transaction data, they should not generate any encrypted data.
a) Question 1
Question 2
Same as Question 3: What is the meaning of each
Question 4: What is the meaning of each
Question 5: In what format are the data elements input to the encryption process?
Question 6: In what format are the results of each encryption included in the transaction message?
Question 6: In what format are the results of each encryption included in the transaction message?
Question 7: In what format are the data elements input to the encryption process?
Question 8: In what format are the results of each encryption included in the transaction message?
Question 9: In what format are the results of each encryption included in the transaction message?
Question 10: In what format are the data elements input to the encryption process?
Question 11: In what format are the data elements input to the encryption process?
Question 12: In what format are the results of each encryption included in the transaction message?
Question 13: In what format are the data elements input to the encryption process?
Question 14: In what format are the results of each encryption included in the transaction message?
Question 15: In what format are the data elements input to the encryption process?
Question 16: In what format are the results of each encryption included in the transaction message?
Question 17: In what format are the results of each encryption included in the transaction message?
Question 18: In what format are the data elements input to the encryption process?
Question 19: In what format are the data elements input to the encryption process?
Question 20: In what format are the results of each encryption included in Question 7: Where is each cryptographic key located in the transaction message? Question 8: How is key management information included in the transaction message? Question 1 usually only requires verification of the master key of a cryptographic transaction. In most systems, the various keys used in a transaction are derived by extracting variations (or transformations) from a single master key. In order to comply with the requirements of this standard, the master key used by the two parties in one communication is usually different from the master key used by the two parties in another communication. It is normal for the keys to be changed frequently, even to the extent that each transaction uses a unique key. Unlike question 1, the answers to questions 2 to 8 usually do not change during the life cycle of the device, at least for a long time. Since each cryptographic device is assigned an initial key through a manual process, the answer to question 28 is usually specified when the device is installed or the initial key is distributed. Such entries are usually not changed, and the initial key distribution process is not repeated. Usually, the communicating parties retain their own shared keys stored in encrypted form (the "stored key" method). Therefore, the answers to Questions 2 to 8, if not specified when the equipment is installed, may be exchanged during the initial key distribution process and may be stored together with the encryption key. Thus, it is usually not necessary to convey these details in a transaction message. Not only are the answers to Questions 2 to 8 usually fixed over time, they are usually the same for all parties connected by the electronic data processing (EDP) equipment. However, as mentioned above, the master encryption key (Question 1) is usually different for each two communicating parties and changes over time.
A3 Explicit Key Identification
The primary purpose of conveying key management related information in a transaction message is to identify the key used to protect the message, which requires the presence of key management related data elements in each such transaction message. Therefore, efficiency is very important, and such data elements should preferably be transmitted in the form of basic bitmaps. In addition, as discussed later, when data elements are used as key identifiers, standardized construction of data elements is required.
Including key verification information of a specified type in each transaction message is called explicit key authentication. Another type is called implicit key authentication. With implicit key authentication, the key to be used for the transaction message in question is determined from other transaction-related information. For example, the key to be used may be determined by the communication line on which the message is received, or by a "terminal identifier" included in the message for other purposes. In fact, all host-to-host transaction messages use implicit key authentication, and many terminal-to-host transaction messages also use implicit key authentication.
A,3.1 Explicit Key Authentication Features
The features of explicit key authentication make it very useful in POS environments, where a large number of POS are connected to a single host. In this environment, the key may not be associated with the terminal itself, but may be associated with a physically separate PIN pad (FINPad) that is installed or replaces the terminal. Using explicit key authentication may not require key management, which is otherwise required. A POS terminal can be installed with a PIN pad connected to it without considering the key management requirements. In such a terminal, each transaction message contains a key identifier that uses the key used in the verification message: there is no need to establish a key relationship before the first transaction of this terminal. If the terminal PIN pad is invalid and replaced, there is no need to notify the acquiring host of the replacement before the first transaction using the new PIN pad. An additional benefit of explicit key authentication is that it prevents the loss of PIN synchronization. Such a loss occurs because the caller uses a different key than the recipient expects. Explicit key authentication in the transaction message can eliminate any such misunderstanding. Another benefit of explicit key authentication is that it allows the use of "derivative keys" as an alternative to conventional stored key techniques, whereby the acquiring host stores (encrypted) keys for each terminal connected to it (in a PO5 environment for example). With derived key techniques, such secret storage is no longer necessary. The host maintains a relatively small number of root keys, each of which is shared by many POS. When the host receives a transaction from such a terminal, it is able to derive the key used at that terminal by encrypting the key identifier contained in the transaction using the correct root key. In a simple example, the key identifier can be encrypted with the root key, and the resulting ciphertext is the terminal key. It is important to note that all such terminal-related keys are unique (assuming that all keys have unique key identifiers), and knowing the key of one terminal does not provide any usable information about other terminals. With this technique, the host does not have to maintain a database for storing encrypted terminal-related keys, because any such key can be derived using the key identifier in the transaction or the common root key. Eliminating such a database simplifies the operational and operational process of key management.
Note that the key identifier is public and does not provide an attacker with information to determine any relevant milions. A.3.2 Key Sets
When using explicit key authentication in a Guard OS terminal, the concept of using a key set is very convenient. Many (e.g., thousands) terminals can use keys from a single key set. Although all keys in a key set are different (unless by accident), all of them have the following common properties:
) If the master key of the key set is stored in encrypted form in the host database, the same key encryption key is used to decrypt all of the master keys in the key set. If the master keys in the key set are derived, the host will use the same root key to cryptographically calculate all of these master keys:
b) the management method of the master keys in the key set is the same; 6
GB/T 21081—2007/ISO 13492:1998) any additional keys are derived from the related master key in exactly the same way (e.g., by using the same transformation); d) the key management related data elements that verify the key set encryption are constructed in the same way and interpreted by the same logic; e) all devices that store the keys in the key set implement the same answers to questions 2 to 8 listed in A, 2. Alternatively, the key management-related data element specifies the implementation of any item, and the implementation of any item may be different for different devices. For each key set, it is necessary for the host to store high-level keys for decrypting or deriving each master key: it is also necessary to store information about how to use the key to implement the required cryptographic function (this information can be in the form of a computer program, a parameter sequence, or a combination of the two. When using secret storage technology, each key set also requires a key list. When using key generation technology, it is not necessary to store each terminal information to determine the terminal-related key (however, some terminal information should be stored for auditing and control purposes, but the accidental loss of such terminal information does not affect the host's ability to determine the terminal secret): therefore, the concept of key sets can be used to minimize and systematize A3.3 Key Identification
When using both dense and explicit key identification, it is useful to identify the key and the key set to which it belongs. This is referred to as the key set identifier as described in 4.1 and 4.2. When used, the key set identifier forms the most significant (leftmost) part of the key identifier.
When using the key set identifier, the key identifier may contain two or three fields, as follows: a) a key set identifier; b) a device identifier; c) a key change counter (optional). The device identifier identifies a specific device that is keyed within the scope of the indicated key set. For stored key systems, the device identifier can be used to locate the key associated with the device in the host key table for the specified key set. For derived key systems, the device identifier uses the root key of the key set to cryptographically calculate the key originally entered into the device. In systems that automatically rekey, the key change counter may be included in the key identifier. The key change counter keeps track of how many key changes have occurred since the initial key was entered: When a key change occurs for each transaction, this field becomes the transaction counter. The key change counter (or transaction counter) is needed when dynamic key changes occur in derived key techniques. The key change counter (or transaction counter) is also helpful if dynamic key changes occur in stored key techniques (to detect cryptographic desynchronization and restore synchronization).
No standardized method is required to represent the device identifier and key change counter. The representation of these fields is fixed for all key sets (as described in the definition of key sets above). Therefore, the association between all key sets is the computer software and/or parameters that define the security-related subfields.
It should be noted that the key set identifiers assigned in accordance with this standard provide a standardized method in which explicit key identification can be used with non-standardized security and key management technologies: Explicit key identification, when used in a POS environment, is usually only used in terminal-initiated transaction messages. Once the acquiring host receives the transaction message initiated by the terminal, the host determines (based on the key identifier in the message) the current master key associated with the terminal, and then uses this key or another related key to cryptographically protect the data sent back to the terminal. Since the terminal already knows the key, there is no need to send a key identifier back to the terminal.
GB/T21081—2007/ISO13492:1998 Appendix B
(Informative Appendix)
Key Set Identifiers to be used Example
- KAONT KAca-
The following is an example of how an acquirer can determine the key set identifier applicable to a specific transaction from multiple key set identifiers. In this example, assume that the acquirer recognizes the following five key set identifiers: Key set identifier
127165
12716632
1271664
1271771
127178
When the acquirer receives a transaction with a key management related data element starting with 12716648159300.\, the acquirer must determine which of the five key set identifiers listed above applies to the transaction. The determination process requires the following steps: Step 1: Check the first key set identifier. Is the first 6 digits of the key management related data 127165? If not, proceed to step 2.
Step 2. Check the second key set identifier. Is the first 8 digits of the key management related data 12716632? If not: proceed to step 3.
Step 3: Check the third key set identifier. Are the first 7 digits of the key management related data 1271664? Yes. Based on the results of this verification process, the acquirer determines that the third key set identifier is applicable to this transaction and the other two key set identifiers no longer need to be evaluated for their applicability. o2, this is called a key set identifier. When used, the key set identifier forms the most significant (leftmost) part of the key identifier.
When a key set identifier is used, the key identifier may contain two or three fields, as follows: a) a key set identifier; b) a device identifier; c) a key change counter (optional). The device identifier identifies a specific device that is keyed within the scope of the indicated key set. For stored key systems, the device identifier can be used to locate the key associated with the device in the host key table for the specified key set. For derived key systems, the device identifier uses the root key of the key set to cryptographically calculate the key originally entered into the device. In systems where key changes are performed automatically, the key change counter may be included in the key identifier. The key change counter records how many key changes have occurred since the initial key was entered: when a key change occurs once per transaction, this field becomes a transaction counter. When automatic key changes occur in derived key techniques, a key change counter (or transaction counter) is required. If dynamic key changes occur in stored key techniques, the use of a key change counter (or transaction counter) is also helpful (to detect cryptographic desynchronization and recover from the desynchronization).
No standardized method is required to represent the device identifier and key change counter. The representation of these fields in all key sets is fixed (as described in the definition of key sets above). Therefore, the association with all key sets is the computer software and/or parameters that define the security-related subfields.
It should be noted that the key set identifiers assigned in accordance with this standard provide a standardized method in which explicit key identification can be used in conjunction with non-standardized security and key management techniques: Explicit key identification, when used in a POS environment, is generally only used in terminal-initiated transaction messages. Once the acquiring host receives a terminal-initiated transaction message, the host determines (from the key identifier in the message) the current master key associated with the terminal and then uses this key or another related key to cryptographically protect the data transmitted back to the terminal. Since the terminal already knows the key, there is no need to send a key identifier back to the terminal.
GB/T21081—2007/ISO13492:1998 Appendix B
(Informative Appendix)
Example of key set identifier to be applied
- KAONT KAca-
The following is an example of how an acquirer determines the key set identifier applicable to a specific transaction from multiple key set identifiers. In this example, assume that the acquirer recognizes the following five key set identifiers: Key set identifier
127165
12716632
1271664
1271771
127178
When the acquirer receives a transaction with a key management related data element starting with 12716648159300.\, the acquirer must determine which of the five key set identifiers listed above applies to the transaction. The determination process requires the following steps: Step 1: Check the first key set identifier. Is the first 6 digits of the key management related data 127165? If not, proceed to step 2.
Step 2. Check the second key set identifier. Is the first 8 digits of the key management related data 12716632? If not: proceed to step 3.
Step 3: Check the third key set identifier. Are the first 7 digits of the key management related data 1271664? Yes. Based on the results of this verification process, the acquirer determines that the third key set identifier is applicable to this transaction and the other two key set identifiers no longer need to be evaluated for their applicability. o2, this is called a key set identifier. When used, the key set identifier forms the most significant (leftmost) part of the key identifier.
When a key set identifier is used, the key identifier may contain two or three fields, as follows: a) a key set identifier; b) a device identifier; c) a key change counter (optional). The device identifier identifies a specific device that is keyed within the scope of the indicated key set. For stored key systems, the device identifier can be used to locate the key associated with the device in the host key table for the specified key set. For derived key systems, the device identifier uses the root key of the key set to cryptographically calculate the key originally entered into the device. In systems where key changes are performed automatically, the key change counter may be included in the key identifier. The key change counter records how many key changes have occurred since the initial key was entered: when a key change occurs once per transaction, this field becomes a transaction counter. When automatic key changes occur in derived key techniques, a key change counter (or transaction counter) is required. If dynamic key changes occur in stored key techniques, the use of a key change counter (or transaction counter) is also helpful (to detect cryptographic desynchronization and recover from the desynchronization).
No standardized method is required to represent the device identifier and key change counter. The representation of these fields in all key sets is fixed (as described in the definition of key sets above). Therefore, the association with all key sets is the computer software and/or parameters that define the security-related subfields. wwW.bzxz.Net
It should be noted that the key set identifiers assigned in accordance with this standard provide a standardized method in which explicit key identification can be used in conjunction with non-standardized security and key management techniques: Explicit key identification, when used in a POS environment, is generally only used in terminal-initiated transaction messages. Once the acquiring host receives a terminal-initiated transaction message, the host determines (from the key identifier in the message) the current master key associated with the terminal and then uses this key or another related key to cryptographically protect the data transmitted back to the terminal. Since the terminal already knows the key, there is no need to send a key identifier back to the terminal.
GB/T21081—2007/ISO13492:1998 Appendix B
(Informative Appendix)
Example of key set identifier to be applied
- KAONT KAca-
The following is an example of how an acquirer determines the key set identifier applicable to a specific transaction from multiple key set identifiers. In this example, assume that the acquirer recognizes the following five key set identifiers: Key set identifier
127165
12716632
1271664
1271771
127178
When the acquirer receives a transaction with a key management related data element starting with 12716648159300.\, the acquirer must determine which of the five key set identifiers listed above applies to the transaction. The determination process requires the following steps: Step 1: Check the first key set identifier. Is the first 6 digits of the key management related data 127165? If not, proceed to step 2.
Step 2. Check the second key set identifier. Is the first 8 digits of the key management related data 12716632? If not: proceed to step 3.
Step 3: Check the third key set identifier. Are the first 7 digits of the key management related data 1271664? Yes. Based on the results of this verification process, the acquirer determines that the third key set identifier is applicable to this transaction and the other two key set identifiers no longer need to be evaluated for their applicability. o
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.