Technical Specifications on Bankcard Interoperability

Part IV Data Secure Transmission Control

Version 22.2

April 2022
THIS PAGE IS INTENTIONALLY LEFT BLANK.
 Part IV: Data Secure Transmission Control

Copyright
UnionPay International Co. Ltd. (“UnionPay International”) retains intellectual property rights concerning this
specifications document and all other documents referenced, attached, and produced by UnionPay International,
including but not limited to copyright, patents, trademarks, and trade secrets. Any use of this specifications
document by any legal and/or natural person is limited by the rules specified in the agreement signed by UnionPay
International Institution Services Portal (https://inst.unionpayintl.com) and UnionPay International. UnionPay
International shall not be liable for any errors or omissions in this specifications document or any losses resulting
therefrom.
Without UnionPay International’s written consent, you may not use this specifications document for uses and
purposes aside from matters involving cooperation with UnionPay International. Without UnionPay International’s
written consent, you may not download, forward, or, publically or in any other form, provide this specifications
document to third parties. If any legal and/or natural person used illegal means to obtain this specifications document,
please immediately delete it and notify UnionPay International.
UnionPay International makes no representations or warranties, including but not limited to, whether or not this
specifications document or its related documents infringe upon the intellectual property rights of third parties. The
user agrees that UnionPay International shall not be liable relating to whether or not the use of this specifications
document infringes on third party rights.

© 2012-2022 UnionPay International Co. Ltd. All rights reserved.

Trademarks
UnionPay International Co. Ltd. (“UnionPay International”) and its various forms are registered trademarks of
UnionPay International Co. Ltd. and its Affiliate(s). All other company or product names mentioned herein are
trademarks of their respective companies.

© 2012-2022 UnionPay International Co. Ltd. All rights reserved.

QR Code is a registered trademark of DENSO WAVE.

UPI CONFIDENTIAL I
 Part IV: Data Secure Transmission Control

Table of Contents
ABOUT THIS DOCUMENT ...................................................................................................................................... III
SUMMARY OF REVISIONS ...................................................................................................................................... V
1 KEY MANAGEMENT AND CONTROL ................................................................................................................ 1
1.1 SECURITY MANAGEMENT .....................................................................................................................................1
1.2 KEY INTRODUCTION.............................................................................................................................................2
1.3 KEY GENERATION ................................................................................................................................................3
1.4 KEY DISTRIBUTION ..............................................................................................................................................4
1.5 KEY STORAGE .....................................................................................................................................................4
1.6 KEY DESTRUCTION ..............................................................................................................................................4
2 DATA ENCRYPTION ......................................................................................................................................... 5
2.1 PIN ENCRYPTION AND DECRYPTION .......................................................................................................................5
2.2 MAC CALCULATION FOR ONLINE MESSAGE .............................................................................................................7
2.3 MAC CALCULATION OF SEQUENTIAL FILE ..............................................................................................................12
2.4 ENCRYPTION AND DECRYPTION FOR INTERNET PAYMENT PIN ....................................................................................13
2.5 FILE ENCRYPTION AND DECRYPTION IN FLOW TRANSMISSION MODE ..........................................................................14
3 KEY RESET .................................................................................................................................................... 15
3.1 KEY RESET REQUEST INITIATED BY MEMBERS ..........................................................................................................15
3.2 KEY RESET INITIATED BY GSCS.............................................................................................................................17
3.3 SWITCHING BETWEEN NEW/OLD KEY (SYNCHRONOUS)............................................................................................20
3.4 KEY BLOCK ......................................................................................................................................................21
4 SECURITY SPECIFICATION ON UPI IC DEBIT/CREDIT STANDARD IC CARD ....................................................... 27
4.1 SECURITY AUTHENTICATION FUNCTION .................................................................................................................27
4.2 ARQC & ARPC ...............................................................................................................................................27

UPI CONFIDENTIAL II
 Part IV: Data Secure Transmission Control

About this Document

Purpose
The Technical Specifications on Bankcard Interoperability - Part IV Data Secure Transmission Control is one of the six
parts comprising the Technical Specifications on Bankcard Interoperability. The document specifies the requirements
on data transmission security which covers secure data transmission, key management, and encryption algorithms.

Audience
The audience of this document are UnionPay International (UPI) staff and UPI Members who have adopted message
format version 2.1 (the message format version is indicated in the online message header).

Document Version
Version 22.2 replaces the previous version.

Revisions
UPI will periodically issue updates to this document, as enhancements and changes are implemented or corrections
are required. Occasionally, updates to this document will be published in an Operation Bulletin.
Please refer to the Summary of Revisions for changes in this version.

Time Expressed
UPI has operation centers in several locations, including Shanghai and Beijing. For operational purposes, the time
frame in this document, unless particularly indicated, refers to “Beijing time”. Coordinated Universal Time (UTC) is
the global standard time by which the world follows. Beijing time is 8 hours ahead of UTC. There is no Daylight Saving
Time in China.
Unless otherwise specified, the “day” mentioned in this document refers to the calendar day. The “business day”
refers to the working day subject to local regulations of the country where the processing Member is located.

Application Scope
This document applies to all UPI Members.
References
The terms and conditions in this document have quoted the following publications. Any later versions of these
publications will be applied in this document unless otherwise specified. Members are encouraged to study the latest
versions of such documents and decide whether to apply.
OR UPI Operating Regulations
UICS UnionPay Integrated Circuit Card Specifications
EMV 4.3 Integrated Circuit Card Specification for Payment Systems: Book 1 ~ Book 4

Support
Please address your questions to your UnionPay representatives.

UPI CONFIDENTIAL III

 Part IV: Data Secure Transmission Control

Word Convention
Convention Tone Implication
Shall Mandatory Must be followed without exception
Should Optional but recommended Required to follow but optional
Must Mandatory Required without exception
Must not Mandatory Not required
Could Optional Hypothetical
Can Optional Stating a capability
Cannot Optional Stating an incapability
May Optional Stating a possibility

Style Convention
Convention Description
boldface Note/emphasis
italic Publications/book titles
monospace Filename/Command

UPI CONFIDENTIAL IV
 Part IV: Data Secure Transmission Control

Summary of Revisions
Description of Changes Location
No revision in this version.

UPI CONFIDENTIAL V
 Part IV: Data Secure Transmission Control

1 Key Management and Control

1.1 Security Management
A Member must comply with UPI’s requirements for security control of data transmission.
When Members establish connectivity with UPI’s network, they should have a strict security and confidentiality
mechanism to guarantee safe and stable operation of their systems. The mechanism shall include the following items:
• Data access control
• Operation security of application systems
• Security of physical facilities that include facility rooms, equipment, communication networks, storage media,
etc.
• Security management policies

Management Policies
Data Security for the whole network entails not only technical support but also establishment and implementation
of strict key management mechanism among UPI Members in terms of business operation. The basic requirements
are as follows:
• To adopt an encryption algorithm that is secure, reliable and widely accepted by bankcard information switch
systems
• To preserve keys and implement transaction information encryption/decryption in the HSM
• To comply with national and international regulations on data security and confidentiality in the financial
industry
• To enhance personnel management
• To change keys regularly
Note: It is recommended for Members to change keys every two years.

Data Transmission Security Control

The requirements for data transmission security control are composed of the following five aspects:
• To have a key management mechanism and adopt strict and reliable key distribution procedures with technical
methods
• To have PIN encryption and conversion mechanism and ensure that PIN in plaintext will never appear in
communication lines or manually-operated storage media
• To adopt MACs
• To adopt HSMs (requirement for all Members)
• To adopt point-to-point data encryption/decryption network mechanisms

Hardware Security Module (HSM)

The functions of a HSM include PIN encryption/decryption, MAC calculation and validation, and key storage, which
shall all be done in the HSM for the purpose of guaranteeing that plaintexts of keys and PINs only appear in the HSM
for prevention of leakage. The HSM shall pass the security certification by the National Business Cryptogram
Committee (Mainland China) or local security institutions and be allowed to apply to local financial institutions. In
addition, the following requirements must also be met:

UPI CONFIDENTIAL 1
 Part IV: Data Secure Transmission Control

• To support single-length, double-length and triple length TDEA keys

• To validate and encrypt/decrypt PINs in accordance with the PIN requirements in this document
• To validate and generate MACs in accordance with the MAC requirements in this document
• To be capable of key validation
• To automatically destroy the stored key under illegal attack
Both UPI and Members shall deploy HSMs together with hosts to encrypt the transmitted data.
Data encryption/decryption between GSCS and Members’ systems shall be based on the single-length key algorithm
or the double-length key algorithm.

Data Encryption and Transmission Environment

Message data shall be encrypted before transmitted to GSCS by Members. Message data obtained by a Member
from GSCS should also be encrypted.

Member GSCS Member

HSM HSM HSM

Figure 1 Data Encryption and Transmission Environment

HSMs in GSCS and Members’ networks form a point-to-point data encryption/decryption structure. GSCS defines
Data Keys with each Member.

1.2 Key Introduction

Keys are critical data in the mechanism of data security and transmission. Keys of all levels, which are defined by
GSCS and Members, shall be unique.
The structure, generation, encryption/decryption objectives, location, length and protection mode, etc. for keys are
specified as follows:
Table 1 Table of Keys in Different Levels

Key Type Master Key Member Master Key Data Key

Abbr. MK MMK PIK for PIN Key;
MAK for MAC Key
Level 1 2 3

UPI CONFIDENTIAL 2
 Part IV: Data Secure Transmission Control

Key Type Master Key Member Master Key Data Key

Original Manually Input Manually Input; Generated by HSM
Generation Generated by HSM
Method randomly
Encryption/ MMK Data Key PIN or MAB
Decryption
Objective
Location HSM; HSM; Host
Outside of HSM, different parts Host
of the key shall be kept by
different persons
Length 192 bit 128 bit; 64 bit;
192 bit 128 bit;
192bit
Protection Mode Hardware Encrypted with the MK Encrypted with MMK
in case of output from or the derivation of
HSM MMK
The generation and input procedures for MKs and MMKs shall be regulated by relevant security policies.
A Data Key shall be encrypted with an MMK (or the derivations of an MMK) of equivalent or greater strength, i.e.,
the length of an MMK shall equal or exceed that of the Data key which the MMK protects. Members intending to
upgrade the algorithm of Data Keys used for communication with UPI shall evaluate the necessity of both upgrading
MMK and migration to key block format, i.e. Members intending to migrate to 192-bit data keys shall complete both
the upgrade of 192-bit MMK and the migration to key block format. For more information about key transmission
secure, please refer to the PCI PIN Security Requirements.
Note: Currently, the 128-bit MMK and the 192-bit MMK are only applicable to 128-bit data keys and 192-bit data
keys respectively.

1.3 Key Generation

Table 2 Information of Key Generation

Key Name Generation

Master Key a Manually generated.
Member Master GSCS generates a half of the key and the Member generates the other half, the two
Key halves shall be combined in the HSM, or;
GSCS generates randomly and hashed 2 components in the HSM, or;
UPI and the Member negotiate how to generate MMK.
Data Key b Generated in the HSM of GSCS randomly and passed the validity test.
Note a:
1) An MK should be input into an HSM manually, which is composed of three parts managed by three
persons respectively. For guarantee of correctness, each part of the key shall be input twice and these two
inputs must be identical; otherwise the inputs will be considered failed.
2) The HSM will implement a parity check after the three parts of key are input by the three persons
respectively. If no error is found in the parity check, the HSM will generate a Master Key, which shall be

UPI CONFIDENTIAL 3
 Part IV: Data Secure Transmission Control

Key Name Generation

stored and protected in the HSM.
3) The MK will be destroyed automatically in case of any unauthorized operation to the HSM.
Note b:
1) Data Keys can be classified into two groups, i.e. PIKs and MAKs, which are randomly generated in HSMs.
HSMs shall verify the validity of Data Keys upon their generation. Weak keys and semi-weak keys shall be
eliminated.
2) The HSM of GSCS generates Data Keys, which are then received and stored by Members. GSCS will initiate
key reset messages to Members if necessary.
3) Members shall send the key reset request advice 0820 message to GSCS if they need new keys.

1.4 Key Distribution

Table 3 Information of Key Distribution

Key Name Distribution

Master Key Generated independently, no distribution needed.
Member Master Key Delivered by security envelope, or;
Input by personnel from both UPI and the Member on site, or;
UPI and the Member negotiate how to distribute MMK.
Data Key Generated in the HSM of GSCS randomly and distributed in online messages.

1.5 Key Storage

Table 4 Information of Key Storage

Key Name Distribution

Master Key Stored in the HSM.
Member Master Key Stored in the HSM;
Must be in cryptograph when outside of HSM.
Data Key Stored in the HSM;
Must be in cryptograph when outside of HSM.
Note: Dedicated persons shall be appointed to input keys, test and debug key management functions, and
keep key documents respectively. The key documents shall be kept in a safe whose key shall be kept by
dedicated personnel. Usage and destruction of key shall be under supervision with corresponding records.

1.6 Key Destruction

Upon generation of new keys, the old ones shall be eliminated from the database and memory for prevention of
replacement and re-usage; meanwhile, all information, which might be used to regenerate the old keys, must be
eliminated. The records showing imitation of new keys and automatic destroy of old keys shall be updated.

UPI CONFIDENTIAL 4
 Part IV: Data Secure Transmission Control

2 Data Encryption
For secure data transmission, two cryptographies, i.e. PIN encryption and MAC, are adopted in network messages.

2.1 PIN Encryption and Decryption

PIN shall be encrypted by the sender with its PIK when the message enters GSCS from the sender’s system. PINs will
be decrypted with the sender’s PIK and encrypted with the receiver’s PIK immediately by GSCS before the message
is sent to the receiver’s system.
PIN is formatted in 64-bit binary digits for encryption/decryption. The distribution of plaintext PIN in 64-bit binary
digits is known as PIN data block. For GSCS and Members, PIN data block shall comply with ISO 9564-1 Banking--
Personal Identification Number Management and Security with its format as follows.
Table 5 Format of PIN Data Block 1

C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F

Where,
C- Control Code: %B0000 (4 bit);
N- PIN length (4 bit);
P- Binary PIN digit (4 bit);
P/F- Binary PIN digit/Filler (4 bit);
F- Filler: %B1111 (4 bit)
A typical process of PIN encryption/decryption is demonstrated in the figure below. This process guarantees that
plaintext PINs only appear in terminals and HSMs, both of which are inaccessible.
Meanwhile, the Acquirer is responsible for the key management and PIN data formatting on the terminal side.

Issuing
Terminal 1 Acquirer 4 GSCS 7 Issuer 10
Bank

2 3 5 6 8 9

HSM HSM HSM

Figure 2 Process of PIN Encryption/Description

The encryption/decryption process between the terminal, the Acquirer, GSCS, and the Issuer is as follows:
1. Terminal sending out PIN cryptograph
2. Decryption by Acquirer with key defined by both Acquirer and terminal
3. Encryption by Acquirer with key defined by both Acquirer and GSCS

UPI CONFIDENTIAL 5
 Part IV: Data Secure Transmission Control

4. Acquirer sending out PIN cryptograph

5. Decryption by GSCS with key defined by both GSCS and Acquirer
6. Encryption by GSCS with key defined by both GSCS and Issuer
7. GSCS sending out PIN cryptograph
8. Decryption by Issuer with key defined by both Issuer and GSCS
9. Encryption by Issuer with key defined by both Issuer and Issuing bank
10. Issuer sending out PIN cryptograph

PIN Length
A PIN is composed of 4~12 numeric digits.

PIN Character Set

A PIN is denoted with numeric characters. The following table presents the binary code for the PIN character set:
Table 6 Binary Code for PIN Character Set

PIN Character Binary Code

0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001

PIN Block
The PIN Block format shall be consistent with the PAN information format published in ISO ANSI X9.8.
2.1.3.1 ANSI X9.8 (with PAN information)
A PIN Block is generated with the result of “PIN data block XOR PAN data block”. For Payment Token transaction, if
Field 2 is a card number in the message, the card number will be used in the PIN Block calculation. If Field 2 is a Token
in the message, the Token will be used in the PIN Block calculation.
PIN Block format shall be indicated in Field 53 of the message.
Table 7 PIN Data Block

Position Description
Byte 1 PIN length
Byte 2~8 4~12 digit PIN (each digit in 4 binary bits), padded with trailing 0xFF.

UPI CONFIDENTIAL 6
 Part IV: Data Secure Transmission Control

Table 8 PAN Data Block

Position Description
Byte 1 0x00
Byte 2 0x00
Byte 3~8 The last 12 digits of PAN (excluding the check digit).
It shall be right-justified with leading 0x00 if the length is less than 12 digits.
 Example 1:
PIN in plaintext: 123456
PAN of magnetic stripe: 1234 5678 9012 3456 78
PAN intercepted: 6789 0123 4567
PAN data block: 0x00 0x00 0x67 0x89 0x01 0x23 0x45 0x67
PIN data block: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF
PIN Block (XOR Result): 0x06 0x12 0x53 0xDF 0xFE 0xDC 0xBA 0x98
 Example 2:
PIN in plaintext: 123456
PAN of magnetic stripe: 1234 5678 9012 3456
PAN intercepted: 4567 8901 2345
PAN data block: 0x00 0x00 0x45 0x67 0x89 0x01 0x23 0x45
PIN data block: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF
PIN Block (XOR Result): 0x06 0x12 0x71 0x31 0x76 0xFE 0xDC 0xBA

PIN Encryption Method

A PIN cryptograph can be generated as follows:
1. Generate the PIN Block as above and input it into the HSM.
2. Operate the encryption on the PIN Block by the TDEA PIK stored in the HSM.
Note: Members outside of Mainland China shall support TDEA PIN encryption method, and the key length shall be
at least double-length (128 bit).

PIN Abnormity Processing

Please see the Transaction Abnormalities Processing section in Part I Transaction Processing of the Technical
Specifications on Bankcard Interoperability.

2.2 MAC Calculation for Online Message

Message Authentication Code (MAC) calculation is used to verify the validity of message source and check whether
the message has been altered during transmission.
MAC calculation complies with ISO 8731-1992 Approved Algorithms for Authentication.

Condition of MAC Usage

MAC support is optional for Members. MAC is applicable to the 01XX, 02XX, 04XX messages and 0800/0810 key reset

UPI CONFIDENTIAL 7
 Part IV: Data Secure Transmission Control

messages. It is not applicable to administrative messages (06XX) and other network management messages (08XX).
When Acquirers support MAC, they shall generate MACs in request/advice messages. GSCS will also generate MACs
in response messages.
When Issuers support MAC, GSCS will generate MACs in request/advice messages, and Issuers shall generate MACs
in approved response messages. (It is optional for Issuers to generate MACs in disapproved messages)
Fields for MAC Calculation
The fields for MAC calculation are defined by UPI. The MAC is calculated by a mode known as Cryptogram Block
Connection (CBC).
Generally, the following data fields are involved in MAC calculation:
• Unique data fields, including trace number, date, time, etc.
• Data fields representing message features, including message type, transaction type, etc.
• Data fields relating to transaction, including card number, amount, response code, etc.
2.2.2.1 Involved Data Fields for 01xx, 02xx, 04xx Messages
If the following data fields are present or meet certain conditions, they should be included in MAC calculation:
Table 9 Involved Data Fields for MAC Calculation in 01xx, 02xx, 04xx Messages

Field Field Name Data Format Description

Message-type- n4 Note a: 0100/0110, 0200/0210, 0420/0430 and 0422/0432
identifier a
2 Primary-account- n...19(LLVAR) Note b: For Token Payment transaction, if the value of Field 2 is a
number b card number, the card number will be used in the MAC
calculation; if the value of Field 2 is a Token, the Token will be
used in the MAC calculation.
3 Processing-code n6
4 Amount-of- n12
Transactions
7 Transmission-date- n10
and-time
11 System-trace- n6
audit-number
18 Merchants-type n4
25 Point-of-service- n2
condition-code
28 Amount- x+n8
transaction-fee
32 Acquiring- an..11(LLVAR)
institution-
identification-code
33 Forwarding- an..11(LLVAR)
institution-

UPI CONFIDENTIAL 8
 Part IV: Data Secure Transmission Control

Field Field Name Data Format Description

identification-code
38 Authorization- an6
identification-
response
39 Response-code an2
41 Card-acceptor- ans8
terminal-
identification
42 Card-acceptor- ans15
identification-code
90 Original-data- n42 Note c: Only the first 20 bytes are involved in MAC calculation:
elements c
Position Sub-field Name Format
Byte 1~4 Original Message Type n4
Byte 5~10 Original Message System Trace No. n6
Byte 11~20 Original Message Transmission Time n10

2.2.2.2 Involved Data Fields for Key Reset Messages

The MAC is composed of the following fields:
Table 10 Involved Data Fields for MAC Calculation in 0800/0810 Key Reset Messages

Field Field Name Data Format Description

Message-type-identifier a n4 Note a: 0800/0810
7 Transmission-date-and-time n10
11 System-trace-audit-number n6
39 Response-code an2
53 Card-acceptor-terminal-identification ans8
70 Network-management-information-code b n3 Note b: 101
100 Receiving-institution-identification-code an..11(LLVAR)

MAC Block Composition

2.2.3.1 MAC Character Selection
The selected MAC data fields shall be further processed as follows:
• Ensure that data fields with length indicators comprise length values for MAC calculation
• Insert a blank between fields
• Replace all lowercases with capital letters
• Eliminate all characters except for letters A-Z, numbers 0-9, blank, comma, and full stop

UPI CONFIDENTIAL 9
 Part IV: Data Secure Transmission Control

• Remove blanks at the beginning and ending of all fields

• Replace consecutive blanks with a single blank.
2.2.3.2 Composition of MAC Block
After picked up from a message, data should go through MAC character selection and then composes a Message
Authentication Block (MAB). The process is as below:
The data after MAC character selection will be divided into blocks of 64 bits. If the last block is less than 64 bits in
length, it will be right-justified with leading binary zeros.
MAC Calculation
In one of the following cases, it is not necessary for the message receiver to check the MAC, and the corresponding
error message shall be returned:
• Timestamp Field missing
• Invalid Time
• Message Identifier undefined
• Invalid Key
Prior to the delivery of the message, the message fields for MAC calculation shall be extracted from the message.
After MAC characters selection, the MAB will be composed and its length will be calculated. The values of the MAB,
the MAB length and the MAK will be input into the HSM for generation of the MAC which shall be delivered together
with the message.
MAC verification shall be performed upon receipt of the message. The message can only be accepted when the new
MAC is identified as the same with the one received, otherwise the message will be declined.
2.2.4.1 MAC Calculation through MAB by HSM
2.2.4.1.1 Single-length Key Algorithm
According to ISO ANSI 9.9, an MAB shall be divided into groups of eight bytes (pad 0X00 to the right if the last group
contains less than eight bytes). The following operations will be performed with the MAK as the single-length key:
1. Execute DES operation
2. XOR the DES operation result with the eight bytes in the next group, and repeatedly DES the XOR result, and
then XOR the DES result with the following group. An eight-byte encryption value can be obtained by DES
operation on the last XOR result.
 Example：
Assuming that an MAB can be divided into 4 groups: A1, A2, A3, and A4, the operation process of a single-length key
is as followed:
1. Perform DES operation on A1 with the MAK to generate B1;
2. XOR B1 with A2, perform DES operation on the result with the MAK to generate B2
3. XOR B2 with A3, perform DES operation on the result with the MAK to generate B3
4. XOR B3 with A4, perform DES operation on the result with the MAK to generate the final encrypted value of 8
bytes
2.2.4.1.2 Double-length Key Algorithm
According to ISO ANSI X9.19, an MAB shall be divided into groups of eight bytes (pad 0X00 to the right if the last
group contains less than eight bytes). The following will be performed with the double-length key:

UPI CONFIDENTIAL 10
 Part IV: Data Secure Transmission Control

1. XOR the next group with the result generated by using the left 64 bits in the double length-key to the first group
2. XOR the result of the Step a. with all the remaining groups repeatedly until the last group.
3. Decrypt the last XOR result with the right 64 bits in the double-length key, encrypt the result of decryption with
the left 64 bits in the double-length key, and get an eight-byte encryption value.
 Example：
Assuming that an MAB can be divided into 4 groups: A1, A2, A3, and A4, and the double-length key can be divided
into 2 groups: K1 (the left 64 bits) and K2 (the right 64 bits), the operation process of double-length key is as follows:
1. Perform DES operation on A1 with K1 to generate B1
2. XOR B1 with A2 and perform DES operation on the result with K1 to generate B2
3. XOR B2 with A3 and perform DES operation on the result with K1 to generate B3
4. XOR B3 with A4 and perform DES operation on the result with K1 to generate B4
5. Decrypt B4 with K2 to generate B5
6. Encrypt B5 with K1 to generate the final encrypted value of 8 bytes.
2.2.4.1.3 Triple-length Key Algorithm
According to ANSI X9.9, an MAB shall be divided into groups of eight bytes (pad 0X00 to the right if the last group
contains less than eight bytes). The following operations will be performed with the MAK as the triple-length key:
1. Execute TDEA operation;
2. XOR the TDEA operation result with the eight bytes in the next group, and repeatedly TDEA the XOR result, and
then XOR the TDEA result with the following group. An eight-byte encryption value can be obtained by TDEA
operation on the last XOR result.
 Example:
Assuming that an MAB can be divided into 4 groups: A1, A2, A3, and A4, the operation process of a triple-length MAK
is as followed:
1. Perform TDEA operation on A1 with the MAK to generate B1;
2. XOR B1 with A2, perform TDEA operation on the result with the MAK to generate B2;
3. XOR B2 with A3, perform TDEA operation on the result with the MAK to generate B3;
4. XOR B3 with A4, perform TDEA operation on the result with the MAK to generate the final encrypted value of 8
bytes.
2.2.4.2 MAC Field Value of Online Message
2.2.4.2.1 01xx, 02xx, 04xx Messages
The MAC field (Field 128), which is the first half of the 8-byte binary digit (a 4-byte binary digit) from MAC Calculation
by HSM, is presented in the form of a hex character string (eight hex characters).
2.2.4.2.2 Key (ECB Enciphered) Reset Initiated by GSCS
In the key (ECB enciphered) reset request message initiated by GSCS and the corresponding response message, the
MAK shall be the newly distributed key. Additionally, the newly distributed PIN key shall be adopted in MAC
calculation during PIN key reset.
 MAC Calculation in Request Message
The MAC field (Field 128) of request message, an eight-byte binary number, is composed of two parts. The first part

UPI CONFIDENTIAL 11
 Part IV: Data Secure Transmission Control
is the first half of the 8-byte binary number (a 4-byte binary number) obtained by MAC calculation, and the second
part is the first half of the 8-byte binary number (a 4-byte binary number) obtained by Check Value calculation.
 MAC Calculation in Response Message
If an MAK or a PIK is to be reset, the MAC in response message is obtained by MAC calculation with the newly
distributed key.
 Check Value Calculation
The Check Value can be obtained by MAC calculation on eight-byte binary 0 with the newly distributed key.
2.2.4.2.3 Key (TR-31 Key Block) Reset Initiated by GSCS
 Field 128 in Request Message
For key (TR-31 key block) reset initiated by GSCS, Field 128 of request message, a 64-bit binary number, is composed
of two parts. The first part is the padding (32 bit ‘0’s), and the second part is the first 32 bits of the key check value
(a 32-bit binary number) obtained by Check Value calculation.
 Field 128 in Response Message
Field 128 should not be present in the Response Message.
 Check Value Calculation
The Check Value can be obtained by CMAC calculation (specified in ISO 9797-1) on all binary zero block (64-bit ‘0’s
for TDEA/DES keys) with the newly distributed key.

MAC Error Processing

Please see the Transaction Abnormalities Processing Section in Part I Transaction Processing of the Technical
Specifications on Bankcard Interoperability.

2.3 MAC Calculation of Sequential File

Sequential file refers to the file with file header (000) and file trailer (001), such as Dual-message Settlement File and
Risk Information Sharing File. Please refer to Part III File Interface of the Technical Specification on Bankcard
Interoperability for details. It is optional for sequential files to pass MAC verification. This section describes the
requirements on MAC verification.

Character Composition of MAC Key and MAC

There are two fields in a file trailer: MAC KEY and MAC, with each of them presented in the form of a string of 16
characters. There are no separators inserted between fields and no concluding symbol attached to the end of them.
Every character contained in these two strings shall be hex characters, i.e. numbers 0-9 and capital letters A-F, used
to present the 8-byte MAC key and 8-byte MAC. This presentation guarantees a convenient display and eliminates
any unprintable characters.

Generation of MAC Key

MAC KEY is a key that is generated randomly together with the generation of files. It is herein referred to as a
cryptograph encrypted with the member master key of a Member. Meanwhile, MAC KEY shall be subject to odd
check.

MAB Composition
Each record of the file (including file head and trailer records but excluding MAC Keys and MACs) shall be divided into
groups of 256 bytes and left-justified with trailing binary zeros if the length is less than 256 bytes; the MAC Block for
the sequential file is the result of performing XOR of each group.

MAC Calculation
UPI CONFIDENTIAL 12
 Part IV: Data Secure Transmission Control

An MAC is composed of two parts. It is generated as below:

The first half (4-byte binary data) of the result, which is obtained by performing DES operation on the first 128 bytes,
is presented in the form of a hex character string (eight hex characters) and regarded as the first part of the MAC
field; the second half of the result (4-byte binary data), which is obtained by performing DES operation on the last
128 bytes of the 256-byte Data Block that is also presented in the form of a hex character string (eight hex characters)
and regarded as the second part MAC field.

MAC Error Processing

In case MAC verification fails, the system will generate a reject file with a reason of MAC Verification Failure. For
details on the format, please refer to the Basic Stipulations section in Part III File Interface of the Technical
Specifications on Bankcard Interoperability.

2.4 Encryption and Decryption for Internet Payment PIN

The Internet Payment PIN of internet transaction is sent to the Issuer by online message. It must be transmitted in
cryptograph for security of the PIN. The sender performs encryption, while the receiver performs decryption.
The Internet Payment PIN is involved in encryption/decryption calculation in the form of 192-bit binary digit. The
distribution of its plaintext in this digit is known as Internet Payment PIN Data Block, whose format for transmission
between UPI and Members is as follows:
Table 11 Format of Internet Payment PIN Data Block
N N P P P P P P P/F P/F P/F P/F P/F P/F P/F P/F P/F P/F P/F P/F P/F P/F F F

Where,
N- Internet Payment PIN length (8 bit);
P- Binary Internet Payment PIN digit (8 bit);
P/F- Binary Internet Payment PIN digit/Filler (8 bit);
F- Filler (8 bit)

Length of Internet Payment PIN

The length of Internet Payment PIN ranges from 6 to 20 digits.

Character set for Internet Payment PIN

The Internet Payment PIN must be composed of ASCII coding characters, digits or symbols of other kinds.

Data Block of Internet Payment PIN

The Internet Payment PIN should be formatted as follows:
Table 12 Format of Internet Payment PIN

Position Description
Byte 1~2 Length pf Internet Payment PIN
Byte The length of the Internet Payment PIN ranges from 6 to 20 digits (each character is 1 byte digit left-
3~24 justified with trailing spaces if there is any vacancy, i.e. 0xFF)
 Example:
Assume the plaintext of the Internet Payment PIN is “Hello!123”:
As the Internet Payment PIN is displayed in plaintext, it has to be changed to the ASCII code.
Table 13 Internet Payment PIN Data Block Coding Example

UPI CONFIDENTIAL 13
 Part IV: Data Secure Transmission Control

Plaintext H e l L o ! 1 2 3
ASCII Code 72 101 108 108 111 33 49 50 51
Hex Value 0x48 0x65 0x6C 0x6C 0x6F 0x21 0x31 0x32 0x33
As described in the table above, this Internet Payment PIN has 9 characters, so “09” is added in front of the PIN,
indicating the length, ASCII coded as 48 and 57; Hex coded as 0x30 and 0x39. Then 13 spaces is padded to the right,
forming the Hex code of 0xFF. Therefore, the result of Internet Payment PIN data block is as follows:
0x30 0x39 0x48 0x65 0x6C 0x6C 0x6F 0x21 0x31 0x32 0x33 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

Encryption of Internet Payment PIN

A 24-byte cryptograph for Internet Payment PIN is obtained as follows:
1. Enter the Internet Payment PIN data block obtained as above into HSM.
2. Perform TDEA operation with the PIK saved in HSM.

Error Processing
Error processing and error response code is the same as the processing for PIN.

2.5 File Encryption and Decryption in Flow Transmission Mode

File Encryption Key Generation
The generation method for file encryption key is the same as that for MAC key. The file encryption key, encrypted by
the MMK and subject to odd check, is generated randomly when the file is transmitted. The key, with the length of
eight bytes, is generated by the HSM and encrypted with the double-length key algorithm.

Encryption and Decryption for File

As for file encryption, a file is encrypted by the DES algorithm. Data in the file shall be divided into groups of eight-
byte strings (pad F to the right if the last string contains less than eight bytes). These strings are encrypted by the
DES algorithm, and then a group of new 8-bytes strings are generated and meanwhile connected in sequence,
forming the cryptograph of the file. The cryptograph of the file is generated by directly connecting these news strings,
not considering if it can be displayed by visible characters.
As for file decryption, at first, a file key plaintext shall be generated after the file key cryptography with MMK is
decrypted. Then the file encrypted with the file key plaintext is decrypted, and the file data plaintext can be obtained.
Be aware that the last group of eight-byte-strings should be removed during the process of file decryption because
it is the file key. The MAC should be checked at last, if the file is a dual-message presentment file. A MAC value shall
be calculated by the MAC key in the file plaintext and be compared with the MAC at the end of file. If they are the
same, it means the file transmitted is correct. MAC needn’t be checked for audit trailers.

UPI CONFIDENTIAL 14
 Part IV: Data Secure Transmission Control

3 Key Reset
3.1 Key Reset Request Initiated by Members
Transaction Flow
A Member sends the 0820 Key Reset Request advice message to GSCS. Upon receiving the 0820 advice message,
GSCS shall reply the 0830 response immediately. Meanwhile, GSCS shall start up the Key Renewal Module to generate
a new key and send the Member the new key in the 0800 Key Reset request message.
GSCS will drop the message in case GSCS fails to reply to the Key Reset Request or sends Key Reset to Member.

2
Member GSCS
3

Figure 3 Processing Flow of Key Reset Request Initiated by the Member

1. Key Reset Request advice (0820) sent by a Member to GSCS

2. Response (0830) sent by GSCS to a Member
3. Key Reset request (0800) sent by GSCS to a Member
4. Response (0810) sent by a Member to GSCS

Flowchart

UPI CONFIDENTIAL 15
 Part IV: Data Secure Transmission Control

Start

Send RSI-MB-SC a N

Await, whether Error, whether

Y
time out manual processing

Conditions to active RSI-MB-SC:

1. Time to conduct regular key distribution; Y
2. Manual trigger;
3. Every N transactions
Manual processing
N
After GSCS sends RSI-SC-MB b, it
immediately actives encryption
module, generates a new key
and sends KSM-SC-MB c.

Receive KSM-SC-MB

Verify MAC
Y N
with new key

Send KSM-MB-SC d to GSCS, with RC being set

00 and MAC being calculated with the new key; Send KSM-MB-SC to GSCS, with RC
Set key launch timer to 0, enter time-window to being set A7 reporting failure to
switch the key from the old to new, and launch new apply new key;
key to encrypt message. Remain old key in use or re-do key
reset by starting from the very
beginning of the flowchart and re-
Close the time-window and use new key to replace performing the whole process.
old key upon launch time shown by the timer.

End

Figure 4 Flowchart of Key Reset Request Initiated by the Member

Note a: RSI-MB-SC, Key Reset Request advice message (0820) sent by a Member to GSCS
Note b: RSI-SC-MB, Key Reset Request advice response message (0830) sent by GSCS to a Member
Note c: KSM-SC-MB, Key Reset request message (0800) sent by GSCS to a Member
Note d: KSM-MB-SC, Key Reset request response message (0810) sent by a Member to GSCS

Explanation on Key Reset Request initiated from a Member

UPI CONFIDENTIAL 16
 Part IV: Data Secure Transmission Control

 Phase I: Send Key Reset Request to UPI

A Member may send a Key Reset Request (RSI-MB-SC) (0820) advice message to UPI when necessary, and then wait
for the response message (RSI-SC-MB) (0830) from GSCS. The Member may send the same message repeatedly if
there is no response from GSCS within specified time limit. If there is still no response from GSCS, manual processing
will be adopted.
 Phase II: Receive the new key
Since GSCS has already applied a new key in MAC calculation when delivering a Key Reset (KSM-SC-MB) (0800)
request message, a Member shall extract the new key upon receiving the KSM-SC-MB and verify the MAC embedded
in the message and then it shall reply to GSCS with a response message (KSM-MB-SC) (0810) for Key Reset. The MAC
generated by the new key shall be applied to the response message.
Upon receiving the new key, the Member shall add a start-up tag to the new key, and all messages delivered by the
Member shall be encrypted through this new key. The shift window for the new and old keys is defined as three
minutes, during which the new and old keys coexist. Within the time window, the Member performs decryption,
conversion or verification for PIN and MAC information sent from GSCS by using the new key. This operation shall be
repeated with the old key in case errors occur during PIN format or MAC verification. If an error still exists, it shall be
regarded as a material error and encryption/decryption failure. At that time, the Member should try to reset the key
again. The Member should take urgent measures to reset the key manually in case of failure again (also contacting
UPI technical support personnel by phone), while the Member shall check the encryption and decryption program
after the urgent measures are taken and may ask UPI for help. The following operations shall be carried out when
the time window is exceeded:
• To replace the old key with a new one
• To eliminate the start-up tag attached to the new key
• To finish Key Reset Application
The Member should ask UPI technical support personnel for help to look into the reason if the errors still occur during
encryption and decryption with new keys time window is exceeded.
A Member shall send GSCS a key reset request advice 0820 message right after the successful installation of MK and
MMK. Due to the fact that each request can apply for only one DK, Members shall send GSCS more than one requests
according to their own needs.
For more information about the message format, Please refer to Section 4.3 Message Definition for Security Control
Message of Part II Online Message.

3.2 Key Reset Initiated by GSCS

Transaction Flow
GSCS sends key reset request to a Member and the Member replies to GSCS upon receiving the message. In case the
Member encounters a malfunction and GSCS does not receive any response, manual processing shall be directly
adopted.

UPI CONFIDENTIAL 17
 Part IV: Data Secure Transmission Control

Member GSCS

Figure 5 Processing Flow of Key Reset Initiated by GSCS

1. Key Reset request (0800) sent by GSCS to a Member

2. Response (0810) sent by a Member to GSCS

Flowchart

UPI CONFIDENTIAL 18
 Part IV: Data Secure Transmission Control

Start

Generate a new PIK or MAK

Send KSM-SC-MB a N

Await, whether Error, whether

Y
time out manual processing
Conditions to active PIK and MAK:
1. Time to conduct regular key distribution;
2. Manual trigger; N Y
3. Every N transactions
N
Receive KSM-MB-SC b Manual processing

Verify MAC
with new key

Set key launch timer to 0, enter time-window to

switch the key from the old to new, and launch new
key to encrypt message.

Close the time-window and use new key to replace

old key upon launch time shown by the timer.

End

Figure 6 Flowchart of Key Reset Initiated by GSCS

Note a: KSM-SC-MB, Key Reset request message (0800) sent by GSCS to a Member
Note b: KSM-MB-SC, Key Reset request response message (0810) sent by a Member to GSCS

Description on Key Reset Initiated by GSCS

UPI waits for the Key Reset response (KSM-MB-SC) (0810)message from a Member after sending a Key Reset (KSM-
SC-MB) (0800) message.
If there is no response from the Member within the time limit, manual processing will be adopted directly.
Upon receiving the successful key reset response message (KSM-MB-SC) from a Member, GSCS will check the MAC

UPI CONFIDENTIAL 19
 Part IV: Data Secure Transmission Control
with the new key. If the MAC check is successful, GSCS will add a start-up tag to the new key, and all message delivered
shall be encrypted by using this new key. If the MAC check fails, GSCS will initiate manual processing, contacting the
Member to offer advice and assistance to the best of its ability.
The shift window for the new and old keys is defined as three minutes, during which the new and old keys coexist.
Within the time window, GSCS will perform decryption, conversion or verification for PIN and MAC information sent
by the Member with this new key. This operation shall be repeated with the old key in case errors found in PIN format
or MAC verification. If the error still exists, it shall be regarded as a material error and encryption/decryption failure,
and GSCS will directly contact the Member and try to offer assistance. The following operations shall be carried out
when the time window is exceeded:
• To replace old key with new one
• To eliminate start-up tag attached to new key
• To finish Key Reset
GSCS will activate manual processing by contacting the Member to look into the reason if the errors still occur during
encryption and decryption with the new key when the time window is exceeded.
For more information about the message format, Please refer to Section 4.3 Message Definition for Security Control
Message of Part II Online Message.

3.3 Switching between New/Old Key (Synchronous)

Switching between new and old keys (synchronous) refers to initiation of the new key during the process of key reset.
Members shall perform encryption or decryption with the new key only if it has received the KSM-SC-MB (0800 Key
Reset request message) and decrypted the key. The MAC value in the KSM-MB-SC (0810 Key Reset response message)
shall be generated through a decrypted new key. GSCS shall perform encryption or decryption with the new key only
if it has received and authenticated the KSM-MB-SC (0810 Key Reset response message) sent from Members. There
must be a time slot if a Member enables a key before GSCS does. The time slot is defined as the time window of
switch between the new and old keys. There will be some transactions encrypted by the old key in the time window,
and there will also be some transactions encrypted by the new key. The time window is set as three minutes.
Within the time window of three minutes, the encryption and decryption for each transaction is performed as follows:
A transaction needs to be checked and authenticated with the new key, or if the check fails, the transaction needs to
be checked and authenticated with the old key. Generally, one of the two ways will work well at least. But if the check
with the old key way fails as well, it means key reset fails; in this case, keys of both parties are asynchronous, and
manual processing should be adopted as soon as possible.
After the three minutes, the time window shall be closed. Then the encryption and decryption for all transactions
should be processed with the new key. If many transactions fail during the encryption and decryption processing
with the new key, it means key reset fails; in this case, keys of both parties are asynchronous, and manual processing
should be adopted as soon as possible.
The time points and events of key exchange are as follows:

UPI CONFIDENTIAL 20
 Part IV: Data Secure Transmission Control

Member GSCS

Messages, old key

3 minutes
time slot

3 minutes
time slot

Figure 7 Key Reset Time and Event

Note a: At T1, Member initiates RSI-MB-SC.

Note b: At T2, GSCS responds RSI-SC-MB and generates a new key in HSM.
Note c: At T3, GSCS sends a new key in KSM-SC-MB.
Note d: At T4, KSM-SC-MB is successfully certified, Member launches new key and triggers Member time-window.
Note e: At T5, KSM-MB-SC is successfully received, GSCS triggers GSCS time-window.
Note f: At T6, Member replaces old key with new key; key reset has completed, and Member time-window is closed.
Note g: At T7, GSCS replaces old key with new key; key reset has completed, and GSCS time-window is closed.

3.4 Key Block

Currently, UPI only supports the Key Block Binding Method using TDEA key derivation. The Key Block Binding Method
is the technique used to protect the secrecy and integrity of the key block. The method uses MMK to derive the Key
Block Encryption Key (KBEK) and the Key Block MAC Key (KBMK). The KBEK is used to encrypt the confidential data
to ciphertext, while the KBMK is used to generate an 8-byte MAC (16 bytes after hex-ASCII encoding) by using CMAC
algorithm.
Table 14 Key Block General Format

Sub-fields Attribute Description

Key Block an16 This sub-field is filled with the Key Block Header.
Header
The Key Block Header contains attribute information about the key and the key
block and is not encrypted.
Key Block an..64 This sub-field is filled with the hex-ASCII encoded Key Block Ciphertext which is the
Ciphertext encrypted confidential data.

UPI CONFIDENTIAL 21
 Part IV: Data Secure Transmission Control

Sub-fields Attribute Description

The confidential data before encoding contains 2-bytes Key Length, the protected
Key and the Padding. For TDEA protected Key, the confidential data is padded with
random bytes until it is a multiple of 8 bytes.
Note: For double-length TDEA PIK and double-length MAK, the length of the hex-
ASCII encoded ciphertext is 48 bytes; for triple-length TDEA PIK and triple-length
MAK, the length of the hex-ASCII encoded ciphertext is 64 bytes.
Key Block an16 This sub-field is filled with the hex-ASCII encoded 16-byte MAC that binds the
MAC Header and Ciphertext.
The following diagram illustrates how the Key Block Binding Method proceeds:

Header Key length Key Padding

KBMK CMAC

MAC IV TDEA KBEK

Header Ciphertext MAC

Figure 8 Processing Flow of Key Block Generation

1. The confidential data to be encrypted is padded on the right with 0x00 until it is a multiple of 8 bytes;
2. CMAC by triple-length TDEA is applied to the entire payload, that is, the header concatenated with the
confidential data, including padding, using the KBMK to generate an 8-byte MAC;
3. Then, the confidential data is CBC-encrypted with TDEA by using the 8-byte MAC previously generated and the
KBEK, which yields a Ciphertext;
4. The hex-ASCII Ciphertext is transmitted along with the hex-ASCII MAC and the plaintext of Header.

Key Block Header

Table 15 The Sequence and Value Information of Key Block Header

Position Definition Format Description

Byte 1 Key Block Version an1 Valid value:
ID B- Key block protected using the TDEA Key Derivation Binding
Method
Byte 2~5 Key Block Length n4 This field will contain the dynamic length of the key block. The key
block length will include the entire block, including header,

UPI CONFIDENTIAL 22
 Part IV: Data Secure Transmission Control

Position Definition Format Description

encrypted confidential data, and MAC in decimal.
Byte 6~7 Key Usage an2 The type of the protected key.
Valid values:
P0- UPI PIK
M1- MAK compliant with ANSI X9.9
M3- MAK compliant with ANSI X9.19
Byte 8 Algorithm an1 The approved algorithm for which the protected key may be used.
Valid values:
D- DES (for double-length MAK compliant with ANSI X9.19)
T- TDEA (for triple-length MAK compliant with ANSI X9.9 and
double/triple-length PIKs)
Byte 9 Mode of Use an1 The Mode of Use byte defines the operation the protected key can
perform.
Valid values:
B- Both encrypt and decrypt / wrap and unwrap
C- Both generate and verify
Byte Key Version n2 This header field is filled with 00.
10~11 Number
Byte 12 Exportability an1 Valid value:
E- Exportable
Byte Number of n2 This header field is filled with 00.
13~14 Optional Blocks
Byte Reserved n2 This header field is reserved for future use and filled with 00.
15~16

The Derivation for KBEK and KBMK

The KBEK and KBMK are derived from the MMK (also known as KBPK specified in TR-31) using CMAC algorithm. The
following table shows the input data into the CMAC function, which is executed for each 8 bytes of key material
required. The Counter is incremented for each call to CMAC as part of the derivation. In any sequence of calls to
CMAC where the Counter is incremented, the Key Usage Indicator and the Algorithm Indicator should remain
unchanged. Hence, when deriving a KBEK and a KBMK, which should be done in two distinct sequences of calls to
CMAC, each starting the Counter as 0x01.
Table 16 The Input Value for KBEK & KBMK Generation

Nibble Definition Format Description

No.
0~1 Counter 2-digit A counter that is incremented for each 8-byte block of keying material
Hex generated for a pair of encryption and MAC keys. Starts at ‘01’ for each
key being generated.
Valid values:
0x01 ~ 0x03
2~5 Key Usage 4-digit Indicates whether the key to be derived is to be used for

UPI CONFIDENTIAL 23
 Part IV: Data Secure Transmission Control

Nibble Definition Format Description

No.
Indicator Hex encryption/decryption or MAC generation/verification.
Valid values:
0x0000- KBEK (Key Block Encryption Key)
0x0001- KBMK (Key Block MAC Key)
6~7 Separator 2-digit Filled with 0x00.
Hex
8~11 Algorithm 4-digit Indicates the encryption or MAC calculation algorithm that is going to
Indicator Hex use the derived key.
Valid values:
0x0000- Double-length TDEA
0x0001- Triple-length TDEA
12~15 Length 4-digit Length, in bits, of the keying material being generated for the pair of
Hex encryption and MAC keys
Valid values:
0x0080 – Length of Double-length TDEA key
0x00C0 – Length of Triple-length TDEA key
The following diagram illustrates how to derive double-length KBEK and KBMK from a double-length MMK:
Key Derivation Data Key Derivation Data
01 00 00 00 00 01 00 C0 02 00 00 00 00 01 00 C0

MMK CMAC MMK CMAC

1st part of KBEK 2nd part of KBEK

Key Derivation Data Key Derivation Data

01 00 01 00 00 01 00 C0 02 00 01 00 00 01 00 C0

MMK CMAC MMK CMAC

1st part of KBMK 2nd part of KBMK

Figure 9 Processing Flow of the Generation of Double-length KBEK & KBMK

The following diagram illustrates how to derive triple-length KBEK and KBMK from a triple-length MMK:

UPI CONFIDENTIAL 24
 Part IV: Data Secure Transmission Control

Key Derivation Data Key Derivation Data Key Derivation Data

01 00 00 00 00 01 00 C0 02 00 00 00 00 01 00 C0 03 00 00 00 00 01 00 C0

MMK CMAC MMK CMAC MMK CMAC

1st part of KBEK 2nd part of KBEK 3rd part of KBEK

Key Derivation Data Key Derivation Data Key Derivation Data

01 00 01 00 00 01 00 C0 02 00 01 00 00 01 00 C0 03 00 01 00 00 01 00 C0

MMK CMAC MMK CMAC MMK CMAC

1st part of KBMK 2nd part of KBMK 3rd part of KBMK

Figure 10 Processing Flow of the Generation of Triple-length KBEK & KBMK

CMAC Algorithm for Key Block

The CMAC algorithm for Key Block is complied with NIST SP 800-38B. The CMAC algorithm uses the encryption key K
and the sub-key K1 derived from the encryption key K to generate the MAC. The input key K varies between MMK
and KBMK as per the specific CMAC calculation process. All the TDEA operations in CMAC are conducted with the
encryption key K.

M1 M2 ... Mn*

+ + K1
TDEA by K
TDEA by K TDEA by K

Ciphertext1 Ciphertext2 Ciphertextn

Intercept the Left-most 64 Bits

MAC

Figure 11 CMAC Calculation Process

1. Let L equal to the TDEA encryption result of 64 bits ‘0’.

2. If the left-most bit of L equals to ‘0’, then K1 equals to the result by one-bit left shifting of L. Else, K1 equals to
the XOR result of one-bit left shifting of L and a 64-bits string ‘05911011’.

UPI CONFIDENTIAL 25
 Part IV: Data Secure Transmission Control

3. Let n denote the number of MAC Blocks.

4. Let M1, M2, …, Mn-1, Mn* denote the complete MAC Blocks.
5. Let Mn equal to the XOR result between Mn* and K1, and replace Mn* as the last MAC Block.
6. Execute TDEA operation on the first MAC Block, M1.
7. XOR the TDEA operation result with the next MAC Block, and repeatedly TDEA the XOR result, and then XOR the
TDEA result with the following MAC Block until the last MAC Block Mn is XORed.
8. A 64-bits MAC can be obtained by TDEA the last XOR result.

CBC-TDEA for Key Block Encryption

The confidential part is CBC-encrypted with TDEA by using the 8-byte MAC previously generated as the input value,
IV, for the initial XOR operation instead of a 64-bits string of all ‘0’s, and the KBEK as the encryption key. This yields
the hex-ASCII Ciphertext of key block.

UPI CONFIDENTIAL 26
 Part IV: Data Secure Transmission Control

4 Security Specification on UPI IC Debit/Credit Standard IC Card

4.1 Security Authentication Function
Security authentication is a key feature of IC card. There are two levels authentication existing in IC card online
verification.
 ---Online Card Authentication (The Issuer authenticates the card)
The card creates an ARQC (Authorization Request Cryptogram) during the process of an online transaction, with
which the Issuer can authenticate the validity of the card.
 ---Online Issuer Authentication (The card authenticates the Issuer)
The Issuer creates an ARPC (Authorization Response Cryptogram) during the process of an online transaction, with
which the card can authenticate the validity of the Issuer.

4.2 ARQC & ARPC

Generation of ARQC
A Unique Derivation Key (UDK) shall be initially calculated before an ARQC can be obtained. A Session Key, which is
finally used to calculate the ARQC, can be computed through the UDK.

Derivation Algorithms of Key (MDK creates UDK)

The IC card key is a derivate of the issuing key of Issuers which is unique. The key of each IC card can be reckoned
only if the root key and derivation algorithms are recorded.
1. To designate data involved in derivation algorithms based on agreement with the Issuer:
Due to the fact that UDK is unique to each card, it shall be obtained from the unique data of card, including card
number, card serial number, region code, etc. Issuers themselves will determine the data elements, which shall
be released to GSCS in case GSCS needs to perform stand-in ARQC authentication. Data elements involved in
UDK calculation have eight bytes in total and the number of data elements involved in derivation algorithms by
Issuers shall not exceed five.
2. To extract the above-mentioned data, arrange them one after another according to the sequence stipulated by
Issuers, and generate Data Block D1 (eight bytes, including sixteen hex digits):
If the data block does not contain 16 hex digits,
• To flush right and pad 0x00 ahead in case the length is less than 16 digits
• To take the 16 rightmost hex digits if the length exceeds 16 digits
D2 is obtained by reversal of the above Data Block D1.
3. To perform TDEA operation on D1 with the MDK and obtain an 8-byte UDK A; similarly, perform TDEA operation
on D2 with the MDK and obtain an 8-byte UDK B.
4. UDK B is put next to UDK A to create the UDK as follows:
Table 17 UDK Generation

UDK
UDK A UDK B

Derivation Algorithms of Double-length Key

1. To calculate the UDK based on the MDK

UPI CONFIDENTIAL 27
 Part IV: Data Secure Transmission Control
2. To pad hex “0” to the left of the ATC (Tag 9F36) in the message to make it up to eight bytes and perform 3DES
operation on the result with the UDK to get the first eight bytes as Session Key A
3. To XOR the 16-bit ATC with a hex value of FFFF (16 bit) and pad hex “0” to the left of the result to make it up to
eight bytes, and then perform 3DES operation on the outcome with the UDK to get the last eight bytes as Session
Key B
4. To create the session key (totally 16 bytes) by combining the first eight bytes and the last eight bytes as follows:
Table 18 Dual-length Session Key Generation

Session Key
Session Key A Session Key B
The Session key must meet requirements for odd parity.

Algorithms of ARQC
4.2.4.1 Data Source
The Issuer may decide the data source and sequence for ARQC calculation at its discretion. The commonly-used data
source and sequence can be adopted if Issuer does not exercise its discretion.
Table 19 Data Source of ARQC

No. Data Element Data From Terminal Data Involved in Data in Corresponding
Terminals? Terminal Field Hash Value Card? Message Tag
Computation?
1 Authorized Amount √ √ 9F02
2 Other Amount √ √ 9F03
3 Terminal Country √ √ 9F1A
Code
4 Terminal Verification √ √ 95
Result
5 Transaction Currency √ √ 5F2A
Code
6 Transaction Date √ √ 9A
7 Transaction Type √ √ 9C
8 Unpredictable √ √ 9F37
Number
9 Application √ 82
Interchange Profile
(AIP)
10 Application √ 9F36
Transaction Counter
(ATC)
11 Issuer Applied Card √ 9F10
Verification Result
(CVR)

UPI CONFIDENTIAL 28
 Part IV: Data Secure Transmission Control
These three data sources, i.e. terminal field, Hash value for terminal field, and data in card, shall be involved in ARQC
calculation according to the universal algorithm.
The Hash value for the terminal field will be obtained through SHA-1 and, comprising 20 bytes. In the wake of the
Hash value is the terminal data and the card data, which can be arranged one after another according to the sequence
shown in the above table with their values unchanged.
Hence, the source data for ARQC calculation is arranged in the following sequence:
Table 20 ARQC Source Data Sorting

Hash Result Terminal Data Card Data

(20 bytes) (Length determined by (Length determined by
actual content in message field) actual content in message field)

4.2.4.2 Approach for ARQC Calculation

1. To divide the above-mentioned data block into groups of 8 bytes: D1, D2, D3…
2. If the length of the last data block is eight bytes, another eight bytes shall be attached to the end of it and the
data block is composed of data, i.e. 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00. In case the length of the last
data block is less than eight bytes, the vacancy shall be filled. A byte of 0x80 will be attached to the end of the
data block if it contains seven bytes; two bytes, i.e. 0x80 and 0x00, will be attached to the end of the data block
if it contains six bytes. According to this logic, if a byte of 0x80 is added but the data block is still shorter than 8
bytes, please add more 0x00's to make it up to 8 bytes.
3. To divide the Session Key (128 bits) into two types, i.e. Session Key Left (SKL, 64 bits) and Session Key Right (SKR,
64bits), and perform the followings on data blocks one by one:
• To perform single DES CBC encryption on the padded data block with the SKL (initial vector is 8 bytes, 0x00)
to generate an MAB (8 bytes)
• To perform single DES ECB decryption with the SKR to generate an MAB_C
• To perform single DES ECB encryption with the SKL to generate a 8-digit ARQC.
4.2.4.3 Data Field Composition for Terminal Hash Value Calculation
TDOL data in the card denote the data-field involved in calculation of Hash value for terminal field. The data name is
from the TDOL and the relevant data is retrieved from the message. These data are connected according to the
following rules:
1. If 1) the tag for the data object denoted in TDOL cannot not be identified, or 2) the data represented by the tag
are not the optional static data in the IC card, or 3) the tag cannot represent the data applicable to the current
transaction, the command field representing the data object shall be filled in with a hex “0”;
2. If the length denoted in TDOL entry is shorter than that of the actual data object, the data object shall be
curtailed to the denoted length:
• If the data object is presented in numeric format (n), bytes shall be curtailed from the left most of the data
unit;
• If the data object is presented in other format, bytes shall be curtailed from the rightmost of the data unit.
3. In case the denoted length is longer than that of the actual data, the actual data shall be padded to the denoted
length:
• If the data object is presented in numeric format (n), a hex “0” shall be padded from the left most of the
data unit
• If the data object is presented in other format, a hex “FF” shall be padded from the rightmost of the data

UPI CONFIDENTIAL 29
 Part IV: Data Secure Transmission Control

unit
The sequence of the data link in the message shall be identical to the order of corresponding data objects in the
TDOL.
Note: The definition of “n” is the same as that in UICS (UnionPay Integrated Circuit Card Specifications).

ARPC Calculation
ARPC is generated from ARQC. The detailed algorithm is as below:
1. To perform XOR operation on the Application Cryptogram with the response code for the Authorization
Response Cryptogram (in Tag 91). The Application Cryptogram is populated in the Tag 9F26 subfield of the
uploaded request message, generally the ARQC, or the AAC under special circumstances. Prior to XOR, the
response code for the Authorization Response Cryptogram should be left justified with six bytes trailing 0x00’s.
2. The result of the above mentioned is an 8-byte data block D1, which can lead to an 8-byte ARPC by 3DES
operation with the session key.

UPI CONFIDENTIAL 30