Banking - Procedures for message encipherment (wholesale) - General principles
Some standard content:
ICS 35.240.40
National Standard of the People's Republic of China
GB/T20544--2006
Banking
Message encryption procedures (wholesale)
General principles
Banking--Procedures for message encipherment (wholesale) --General principles
(ISO 10126-1:1991,MOD)
Published on September 18, 2006
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 March 1, 2007
GB/T20544--2006
Normative references
Terms and definitions
Encryption and decryption of the entire message and the elements to be encryptedTransparent transmission of encrypted data
Processing order
8 Encryption algorithm verification procedure
Appendix A (informative appendix) Filtering example, purpose
Appendix B (informative appendix) Filtering-Expansion coefficient of selected filter Appendix C (informative appendix) Encryption and decryption examples of elements to be encrypted C.1 Independent encryption and decryption of elements to be encrypted C.2 Encryption and decryption between elements to be encrypted and ciphertext strings C.3 Encryption and decryption between elements to be encrypted and ciphertext substrings 9
GB/T 20544-2006
This standard modifies the international standard ISO10126-1:1991 "Encryption procedures for banking business messages (wholesale) Part 1: General principles" English version).
Taking into account my country's national conditions, the following modifications were made when adopting ISO10126-1: a) "Part 1" was deleted from the name of the standard, and the normative reference document ISO10126-2:1991 was deleted. Because the algorithm described in ISO10126-2 does not comply with the relevant regulations of my country's cryptographic management department and is not suitable for adoption as a national standard, Part 1 constitutes the entirety of this standard.
b) "The specific algorithms applicable to this part are described in Part 2" was deleted from the introduction. "(Cryptographic block chains described in 10126-2)" was deleted from 6.7. Because the algorithm does not comply with the relevant regulations of my country's cryptographic management department. c) Delete "IS010126-1 Appendix A Approval Procedure for Cryptographic Algorithms", and explain in Chapter 8 that the relevant regulations of my country's cryptographic management department should be followed.
For ease of use, the following editorial changes have been made to ISO10126-1: a) For international standards cited in normative reference documents, those with corresponding national standards have been changed to reference national standards. b) Delete the ISo foreword.
Appendices A, B, and C of this standard are informative appendices. This standard was proposed by the People's Bank of China. || tt||This standard is managed by 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, Venusstar Co., Ltd., Beijing Technology and Business University. The main drafters of this standard are: Tan Guoan, Yang Xian, 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, Zhang Dedong. This standard is formulated for the first time. ||t t||GB/T20544---2006
This standard specifies the method of encryption and decryption of the entire (or part of) financial wholesale message application layer for the purpose of providing confidentiality. The level of security provided by this standard depends on the following two points: a) the security of the encryption algorithm and the specific implementation of the algorithm in the standard push program b) the operation of a secure key management system. The corresponding international standard for key management is described in ISO8732. 1 Scope
Banking
Message encryption procedure (wholesale)
General principles
GB/T 20544—2006
The procedures defined in this standard are intended to protect by cryptographic means financial messages (whole messages or encrypted elements) exchanged in any communications architecture. Such architectures include store and forward and telegram environments, and any number of nodes and public or private networks. Because encrypted text would impede the flow of communication over existing wholesale financial networks, this standard establishes methods to allow encrypted messages to be transmitted over multiple networks without being misinterpreted as communications protocol information such as STX (start of text) and EOT (end of text). The confidentiality of financial message data, whether structured or unstructured, is protected by this standard. The techniques described do not address integrity protection (i.e., protection against modification, substitution, and re-sensitization). Data integrity protection is discussed in ISO 8730 and ISO 8731. 2 Normative references The following documents, as amended by the amendments (excluding errata) or revisions to this standard, are not applicable to this standard. However, the latest versions of these documents may be used. All GB/T 1988—1 Information technology ISO 8730:1990 Banking business messages ISO 8731-1:1987 Banking business ISO 8731-2:1987 Banking business ISO 8732:1988 Banking business confidentiality 3 Terms and definitions The following terms and definitions apply to the character encoding baudot standard.
The scope of discussion of the proposed document is to replace the use of a placeholder coding sub-section (wholesale) requirements for text authentication.
The referenced document is pending, and all subsequent studies submitted by the parties to the agreement based on this standard are applicable to this standard.
S0/IEC 646119910
DEA protocol
Text authentication algorithm
A five-character information encoding scheme including optional start and end bits): CITT characters are numbered 2 each. 3.2
Blockblock
A unit of data of a specific length.
Ciphertextciphertext
Encrypted information.
Communicating pair
Two logical groups that have agreed on exchanging data. 3.5
cryptographickey
keykey
GB/T 20544--2006
Parameter used together with an algorithm for the purpose of encryption or decryption. 3.6
dataunitdataunit
K-bit binary vector, denoted as (B1, B2, *, BK). 3.7
decipherment
The inverse process of reversible encryption.
enciphered elementenciphered elementThe element to be encrypted bypassing encryption.
encipherment
The cryptographic conversion process performed to generate ciphertext data. 3. 10
encipherment elementThe group of consecutive plaintext characters to be encrypted.
filtering
The process of encoding binary text into a format that is insensitive to control characters. 3. 12
Financial message
Communication containing information with financial implications. 3.13
Initialization Vector()
Initialization vector
A number that serves as the encryption starting point for a data sequence. The initialization vector improves security by introducing additional cryptographic variance; and helps synchronize cryptographic devices.
Initial Text Sequence (ITS) An n-bit binary vector that can be used as a message prefix. 3.15
Logical party
One or more physical parties that form a member of a communicating pair. 3.16
Message
Communication containing one or more transactions or related information. 3.17
most significant bit(s)The leftmost bit of a binary vector.
octet
foctet
A group of 8 binary digits labeled B1, B2, ·, B8 from left to right. 3.19
padding
One or more binary bits appended to a message so that the message contains an estimated length of 2
integer multiples of the number of bits required by the filtering process or encryption algorithm.
plaintext
Unencrypted information.
receiverreceiver
A logical entity authorized to decrypt a received message. 3.22
sender
A logical entity responsible for generating encrypted messages. 4 Application
4.1 Protection provided
GB/T 20544—2006
The confidentiality of financial message data is protected using this standard. This standard provides methods for protecting structured and unstructured message data. Confidentiality protection is provided between two logical parties. The communicating logical parties are the receiver and the sender. 4.2 General operation
4.2.1 Processing
The sender of a financial message produces ciphertext by applying the cryptographic process described in Clause 5 to the entire plaintext message or the element to be encrypted in the message, and using a secure key management system. The message is then forwarded to the receiver, who decrypts the ciphertext by applying the decryption procedure described in Clause 5. Note that the cryptographic process is sensitive to the sequence of encrypted plaintext; the order must be the same when encrypting and decrypting. If decryption of the entire message or the element to be encrypted is subsequently required, the audit log should include sufficient information to retrieve the keys, messages and other information used in the cryptographic process. When both authentication and encryption are required for financial messages, message authentication shall precede encryption, and encryption and authentication shall use different keys. 4.2.2 Communication methods
This standard shall be used to encrypt entire financial messages or encrypted elements transmitted over any number of nodes in public or private networks and over a variety of communication media.
5 Encryption and decryption of entire messages and encrypted elements 5.1 Overview
This standard allows four encryption methods, namely, encryption of entire messages and three encryption methods for encrypted elements. Several messages using different keys, different operating modes or encryption (see 5.3) and filtering (see Chapter 6) methods may be combined in a single transmission. 5.2 Encryption and decryption of entire messages
When the entire message is to be encrypted, all plaintext, except for header and trailer information (e.g., information added by the network for transmission), shall be encrypted. The entire initial text sequence (if present), including the MAC and padding fields (if present), shall be encrypted as a unit. After encryption, the ciphertext shall be filtered in accordance with Clause 6. When the entire message is decrypted, all ciphertext shall be decrypted as a unit. bzxz.net
5.3 Encryption and decryption of encrypted elements
This standard allows three methods to be used to encrypt and decrypt the encrypted elements in a message. Method 1: The encrypted elements are encrypted independently to become encrypted elements. The encrypted elements are decrypted independently to become encrypted elements (see 5.3.2). Method 2 The encrypted elements are concatenated together and encrypted as a single data string. The resulting ciphertext string is transmitted as a single string in the message. The ciphertext string is decrypted and the resulting encrypted elements are inserted into the message text (see 5.3.3.1). Method 3: The encrypted elements are concatenated together and encrypted as a single data string. The resulting ciphertext string is divided into ciphertext substrings and transmitted in the message. The ciphertext substrings are concatenated together and decrypted as a single string. The resulting ciphertext is inserted into the message text (see 5.3.3.2).
After encryption, the ciphertext shall be filtered according to clause 6. Examples of the above three methods are detailed in Annex C. Each ciphertext element in a particular message shall use the same key, algorithm, mode of operation, and filters (if implemented). Encryption of a ciphertext element does not provide the same protection as encryption of the entire message. For example, the context of an encrypted element may provide clues to an unauthorized party about its underlying plaintext. 5.3.1 Field delimiters
Explicit or implicit delimiters are required to separate ciphertext elements, encrypted elements, ciphertext strings, and ciphertext substrings. The delimiters for individual ciphertext elements allow the application to determine which ciphertext elements are to be encrypted. The delimiters for encrypted elements, ciphertext strings, and ciphertext substrings allow the application to determine which ciphertext is to be decrypted. Each ciphertext element may be delimited in the plaintext in an explicit or implicit manner. After encryption, a message may contain multiple encrypted elements, a ciphertext string, or multiple ciphertext substrings, and each encrypted element or ciphertext substring may be separated in the message in an explicit or implicit manner. Ciphertexts in a message may be separated explicitly or implicitly. 5.3.2 and 5.3.3 describe three methods for processing encrypted elements using explicit delimiters. Implementation schemes using implicit delimiters shall process encrypted elements, ciphertext strings, and ciphertext substrings in a manner equivalent to the above three methods. 5.3.1.1 Implicit Delimiters
If the encrypted element is an encrypted element,
distinguish it, and the sender and receiver have previously agreed on its use. 5.3.1.2 Explicit Delimiters
If there is no accompanying delimiter, it shall
start and end. a) To-be-encrypted elements: QE- and -EQ
For example: QC- and -c
For example: Qc- including encrypted elements -
c) Ciphertext strings and substrings: QQ and
For example: Qa-string-CQ
Separators
Or: QQa-substring-cQ
5.3.2 Implementation of encryption and decryption of elements to be encrypted 5.8 The positions of the elements to be encrypted are fixed or they are implicitly separated according to the format rules for identification purposes.
The encrypted elements, ciphertext strings and ciphertext substrings
The elements to be encrypted, 8- and -EQ shall not be included in the encryption process/shall be replaced by the encrypted element separators QC- and -CQ respectively. Before the QC- and -CQ delimiters are added, the encrypted elements may be filtered as described in Section 6. Each encrypted element shall be placed in the same position as the corresponding encrypted element in the ciphertext. The encrypted element may be longer than the corresponding encrypted element for the following reasons:
a) The encryption mode requires padding of the plaintext before encryption. b) Overwriting may have been performed which results in data expansion.
The receiver shall perform reverse filtering (if necessary) on all encrypted elements separated by the QC- and -CQ delimiters and decrypt them separately. Each plaintext encrypted element shall be replaced by the corresponding encrypted element. The QC- and -CQ delimiters shall be replaced by the QE- and -EQ delimiters, respectively.
5.3.3 Encryption and Decryption of Concatenated Encrypted Elements The encrypted elements shall be combined in sequence and encrypted as a single data string. After encryption, the ciphertext shall be filtered as described in Section 8.
5.3.3,1 The ciphertext string (now method 2 of 5.3) formed by encrypting the concatenated elements to be encrypted and their -EQ delimiters can be placed in the message as a single ciphertext string. The ciphertext string shall be delimited by QC- and -CQ delimiters. The QE- delimiter is retained in the plaintext portion of the message as a position marker. GB/T 20544--2006
The receiver decrypts the ciphertext delimited by QC- and -CQ delimiters into a single data string to produce a combination of concatenated elements to be encrypted, each of which ends with a -EQ delimiter. Each element to be encrypted and its -EQ delimiter shall be placed in sequence after the corresponding QE- delimiter in the plaintext message. For example, the first element to be encrypted and its -EQ delimiter shall be placed after the first QE- delimiter in the plaintext message; the second element to be encrypted and its -EQ delimiter shall be placed after the second QE- delimiter in the plaintext message. QC- and -CQ delimiters and ciphertext shall be deleted.
5.3.3.2 Ciphertext substring (see 5.Method 3) The ciphertext formed by encrypting the connected elements to be encrypted without any separators can be divided into multiple ciphertext substrings, which are inserted into the message to replace the elements to be encrypted. When inserting a ciphertext to replace a specific ciphertext element, except for the last element to be encrypted containing the remaining ciphertext bits, each bit of the element to be encrypted will be replaced by a single ciphertext bit selected in sequence. Each ciphertext substring should be separated by QC- and -CQ separators, and QC- and -CQ separators replace the QE- and -EQ separators of message A respectively. The receiver combines all ciphertext substrings in sequence, but not including their corresponding separators, into a ciphertext string. Then, the ciphertext string is decrypted and divided into elements to be encrypted. This ciphertext element is inserted into the message to replace the ciphertext substring. For example, if the first ciphertext substring of the message is 16 bits, then these bits will be replaced by the ciphertext substring after the ciphertext string is decrypted. All the digits of the ciphertext substring after the ciphertext string is decrypted will be replaced by QE- and -EQ respectively.
Transparent Transmission of Encrypted Data
6.1 Introduction
The first ciphertext substring of the message is 40 bits long, and this continues until the last
ciphertext substring. Finally
, the QC- and CQ-delimiters will be 93
, respectively, in the message. The background is a pseudo-random binary string. Therefore: The encryption process
T1988--1998 The communication system that supports the coding may a)
or recognize it as a control function.
FF or end of file).
b) Implementing the audot character encoding
string
baudot features
might have an adverse effect on the operation of the transport service
certain cipher
interpretations of certain parts of the pseudo-random binary output (e.g., spurious XON/XO-identified as BT or EOT strings used as control strings in transport services) may produce undesirable results or corruption of string-sensitive communication systems.
Therefore, examples of various sugar techniques are described in the appendix to this standard. The effects of various filters are compared.
6.2 No filtering
If the transport service is transparent to control words and control strings, then no transport filters need to be used. However, if explicit delimiters as described in 5.3.3.2 are used, it is important to avoid the presence of these delimiters in the ciphertext (see 6.9). 6.3 Hexadecimal Filtering
Filtering shall be performed by converting each 4 bits of the ciphertext into hexadecimal characters, which are then transmitted using the character encoding used by the network. The first example in Appendix A describes a hexadecimal filter. 6.4 GB/T 1988-1998 Filter
Networks that use a character encoding consistent with GB/T1988--1998 and do not translate lowercase letters into uppercase letters may use the 94-character filter described in this clause. Example 2 in Appendix A describes a GB/T1988-1998 filter. The binary data stream is divided into groups of 13-bit data units. Each data unit is constructed as an unsigned binary integer. If necessary, the last data unit should be padded to 13 bits (see 6.6). The two characters corresponding to the 13-bit number can be found in Table 1. Decoding is accomplished by reversing this process. 5
GB/T 20544--2006
Original input
Table 1 GB/T1988-1998 filter (showing the sequence of permitted characters) Filter form
Original input
Filter form
Original input
Filter form
This table can meet the needs of this filter (Table 1 shows the first 95 values in the table). The first column consists of the numbers 0
8191 in sequence. The second column converts the original input into the first 8192 possible non-space, non-hyphen printable character pairs in GB/T1988-1998 Table 11, arranged in dictionary order. According to GB/T1988--1998, the first character in the filter form character pair can be modified for national use and has a different representation from other countries. However, this standard uses these elements only as a tool to convert 13-bit vectors into 14-bit vectors and does not require the printing of these characters. Therefore, the use of different national representations does not cause conflicts. 6.5 Transparent filtering process for baudnt networks
Communication systems implementing baudot character encoding interpret or recognize certain pseudo-random binary output as strings used as control strings in the transmission service.
To be transparent to baudot, the above filter maps to the following 20-letter alphabet: ADEGHI-JKLMOPQREUVWXY
Note 1: The missing characters (i.e., BCFNTZ) are control-sensitive characters. 6
GB/T 20544-2006
The filter maps each 13-bit data unit to 3 or 4 characters from the 20-letter alphabet. The final data unit is right-padded to a multiple of 13 bits (see 6.6). For encoding purposes, each 13-bit data unit is interpreted as an unsigned binary integer. If the data unit is less than 7980, the 13-bit string will be mapped into a 3-letter group, as shown in Table 2. The table consists of: the first column is the 13-digit number 0 to 7979, and the other column is 7980 3-letter groups in lexicographic order, starting with "ADA", Table 2 GB/T1988-1998/baudot filter (data unit value less than or equal to 7979) original input
filter form
If the data unit value is greater than or equal to 7980, it will be mapped into a 4-letter group starting with "AA", as shown in Table 3. Table 3 GB/T1988-1998/baudot filter (data unit value between 7980 and 8191, including 7980 and 8191) original input
filter form
The first column consists of numbers 7980 to 8191 in order; and the second column consists of 4-letter groups in lexicographic order. To decode, check the first two letters. If the first two letters are "AA", then Table 3 is referenced to find the corresponding 13-digit number using 4 letters. If the first two letters are not "AA", then Table 2 is referenced to find the corresponding 13-digit number using 3 letters. This process is then repeated, with each new string of 13 digits concatenated to the end of the data stream. 6.6 Filter Padding Generation
When using the bit-by-bit or byte-by-byte encryption methods, the GB/T 1988-1998 and GB/T 1988--1998/baudot filters described in 6.4 and 6.5, respectively, require that the ciphertext be padded to a multiple of 13 bits. The padding field shall be divided into two subfields (see Figure 1).
Padding Field
Padding Count
Figure 1 Filter Padding Field Format
GB/T 20544--2006
The length of the first subfield shall be from 0 to 12 bits, including any content. The second subfield shall be 4 bits long and shall contain an unsigned binary value between 3 and 15 equal to the total number of bits in the padding field, including the count subfield itself, minus one. If less than 4 bits are required to pad the ciphertext to a multiple of 13 bits, then an additional 13 bits shall be added, of which 9 bits are random and the other 4 bits are the padding count. The padding count shall be one less than the total number of bits in the padding field (including the padding count subfield itself). Further information on filter padding is given in Table 4.
Table 4 Filter Padding (for GB/T1988-1998 and GB/T1988-T998/baudot filters only) Number of ciphertext bits in the last 13-bit data unit 13
6.7 Filter Padding Elimination (for GB/T1988-1998 and GB/T1988-T998/baudot filters only) Number of ciphertext bits in the last 13-bit data unit 13
6.7 Filter Padding Elimination (for GB/T1988-1998 and GB/T1988-T998/baudot filters only) The number of binary digits padded is the number of binary digits in the padding field. The padding count (4 binary digits) 998 and GB/T allow padding to be a multiple of 13 digits. When receiving oxygen, it is discarded before decryption. 6.8 User-defined filter This standard allows user-defined filters. 6.9 Elimination of explicit delimiters If the explicit delimiter described in 5.3 is used, 6.5. The filter described in
can be
filtered, or can be used to
multiples of
998/baudol filters). If GB/T1988--1998 or higher is used, the ciphertext should be randomized before passing it through the packet filter. The remaining bits after a 64-bit block should be determined by the packet filter. The filter should be determined by the effective agreement between
and the receiver. Avoiding hyphens is very important. Use 6.3, 6.4 or no hyphens. However, if a user-defined text filter that passes hyphens is not used, an additional step should be taken to eliminate these delimiters. One technique to achieve this is to insert the GB/T1988--1998 character DEE (Da Super Link Escape). DLE should be inserted into the ciphertext after each hyphen. When a message is received, one or more DLE characters after the hyphen should be deleted before processing.
Processing Order
See Figure 2.
7.1 Encryption
Encryption processing is very sensitive to the order in which messages are processed. When processing messages for transmission, the following order should be followed for the selected encryption method:
Select the data to be encrypted;
b) Add encryption padding (where required); c) Encrypt;
d) Filter (optional),
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.