Technical Specifications on

Bankcard Interoperability

Part IV Data Secure Transmission Control

Version 20.1
 Part IV: Data Secure Transmission Control

Copyright
UnionPay International Co., Ltd. (“UnionPay International” or “UPI”) retains
intellectual property rights concerning this 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 document
by any legal and/or natural person is limited by the rules specified in the agreement
signed with UnionPay International. UnionPay International shall not be liable for any
errors or omissions in this document or any losses resulting therefrom. Concerning
this specifications document, UnionPay International abandons all warranties and
representations, both express and implied.
Without UnionPay International’s written consent, you may not use this 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 document to third
parties. If any legal and/or natural person used illegal means to obtain this 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 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 document
infringes on third party rights.
© 2015-2019 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.
© 2015-2019 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

THIS PAGE IS INTENTIONALLY LEFT BLANK.

UPI Confidential ii
 Part IV: Data Secure Transmission Control

TABLE OF CONTENTS

ABOUT THIS DOCUMENT .......................................................................................................... VI

SUMMARY OF UPDATES ........................................................................................................... VII

1 APPLICATION SCOPE ............................................................................................................... 1

2 REFERENCES .............................................................................................................................. 2

3 TERMS AND DEFINITIONS ...................................................................................................... 3

4 KEY MANAGEMENT AND CONTROL .................................................................................... 4

4.1 SECURITY MANAGEMENT ............................................................................................................... 4

4.1.1 Management Policies ............................................................................................................. 4

4.1.2 Data Transmission Security Control...................................................................................... 4

4.1.3 Hardware Security Module (HSM) ........................................................................................ 5

4.1.4 Data Encryption and Transmission Environment ................................................................. 5

4.2 KEYS INTRODUCTION ..................................................................................................................... 6

4.3 KEY GENERATION .......................................................................................................................... 6

4.3.1 Data Key (DK) Generation .................................................................................................... 7

4.3.2 Member Master Key (MMK) Generation ............................................................................... 7

4.3.3 Master Key (MK) Generation ................................................................................................ 7

4.4 KEY DISTRIBUTION......................................................................................................................... 7

4.4.1 Data Key (DK) Distribution ................................................................................................... 8

4.4.2 Member Master Key (MMK) Distribution ............................................................................. 8

4.5 KEY STORAGE ................................................................................................................................ 8

4.5.1 Storage of Data Key (DK)/Member Master Key (MMK) ...................................................... 8

4.5.2 Master Key Storage ................................................................................................................ 8

4.5.3 Key Documents Keeping ........................................................................................................ 8

4.6 KEY DESTROY ................................................................................................................................ 8

5 DATA ENCRYPTION .................................................................................................................. 9

5.1 PIN ENCRYPTION AND DECRYPTION .............................................................................................. 9

5.1.1 PIN Length ............................................................................................................................ 10

5.1.2 PIN Character Set ................................................................................................................ 10

UPI Confidential iii
 Part IV: Data Secure Transmission Control

5.1.3 PIN BLOCK .......................................................................................................................... 10

5.1.4 PIN Encryption Method........................................................................................................ 12

5.1.5 PIN Abnormity Processing ................................................................................................... 12

5.2 MAC CALCULATION FOR ONLINE MESSAGE ............................................................................... 12

5.2.1 Condition of MAC Usage ..................................................................................................... 12

5.2.2 Fields for MAC Calculation ................................................................................................. 12

5.2.3 MAC Block Composition ...................................................................................................... 14

5.2.4 MAC Calculation .................................................................................................................. 15

5.2.5 MAC Error Processing ......................................................................................................... 18

5.3 MAC CALCULATION OF SEQUENTIAL FILE .................................................................................. 18

5.3.1 Character Composition of MAC KEY and MAC ................................................................. 18

5.3.2 Generation of MAC KEY ...................................................................................................... 18

5.3.3 MAB Composition ................................................................................................................ 18

5.3.4 MAC Calculation .................................................................................................................. 18

5.3.5 MAC Error Processing ......................................................................................................... 19

5.4 ENCRYPTION AND DECRYPTION FOR INTERNET PAYMENT PIN OF INTERNET TRANSACTION ..... 19

5.4.1 Length of Internet Payment PIN .......................................................................................... 19

5.4.2 Character set for Internet Payment PIN .............................................................................. 19

5.4.3 Data Block of Internet Payment PIN ................................................................................... 19

5.4.4 Encryption of Internet Payment PIN .................................................................................... 20

5.4.5 Error Processing .................................................................................................................. 20

5.5 FILE ENCRYPTION AND DECRYPTION IN FLOW TRANSMISSION MODE ........................................ 21

5.5.1 File Encryption Key Generation .......................................................................................... 21

5.5.2 Encryption and Decryption for File ..................................................................................... 21

6 KEY RESET ................................................................................................................................ 22

6.1 KEY RESET REQUEST INITIATED FROM MEMBERS ....................................................................... 22

6.1.1 Transaction Flow ................................................................................................................. 22

6.1.2 Flowchart.............................................................................................................................. 23

6.1.3 Explanation on Key Reset request initiated from a Member ............................................... 23

UPI Confidential iv
 Part IV: Data Secure Transmission Control

6.1.4 Message Format ................................................................................................................... 24

6.2 KEY RESET INITIATED BY GSCS .................................................................................................. 25

6.2.1 Transaction Flow ................................................................................................................. 25

6.2.2 Flowchart.............................................................................................................................. 27

6.2.3 Description on Key Reset Initiated by GSCS ....................................................................... 27

6.2.4 Message Format ................................................................................................................... 28

6.3 SWITCHING BETWEEN NEW/OLD KEY (SYNCHRONOUS) .............................................................. 30

7 SECURITY SPECIFICATION ON UPI IC DEBIT/CREDIT STANDARD IC CARD .......... 32

7.1 SECURITY AUTHENTICATION FUNCTION ...................................................................................... 32

7.2 ALGORITHMS OF ARQC ............................................................................................................... 32

7.2.1 Generation of ARQC ............................................................................................................ 32

7.2.2 Derivation Algorithms of Key (MDK creates UDK) ........................................................... 32

7.2.3 Derivation Algorithms of Double-length Key ...................................................................... 33

7.2.4 Algorithms of ARQC ............................................................................................................. 33

7.2.5 ARPC Calculation ................................................................................................................ 36

UPI Confidential v
 Part IV: Data Secure Transmission Control

About this Document

Purpose

Part IV Specification on 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 audiences of this specification 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).

Time Expressed

UPI has operation centers in several locations including Shanghai, Beijing, and Hong
Kong. The expressions of time in this document, unless particularly indicated, are
based on “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” in this document refers to the calendar day,
and the “business day” refers to the working day subject to local regulations of the
country/region where the processing Member is located.

Replacement

Version 20.1 replaces your existing document.

Updates

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 Updates for changes in this version.

Support

Please address your questions to your UnionPay representatives.

UPI Confidential vi
 Part IV: Data Secure Transmission Control

Summary of Updates
The changes listed below are associated with the Version 20.1.

Description of Change Location

No revisions

UPI Confidential vii

 Part IV: Data Secure Transmission Control

1 Application Scope
This document applies to all UPI Network Members.

It specifies the requirements for secure transmission of data information which covers
secure data transmission, key management and encryption algorithms.

UPI Confidential 1
 Part IV: Data Secure Transmission Control

2 References
The terms and conditions of the following documents quoted in this document have
become the terms and conditions of the document. 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..

Integrated Circuit Card Specification for Payment

 EMV 4.3
Systems: Book 1 ~ Book 4

UPI Confidential 2
 Part IV: Data Secure Transmission Control

3 Terms and Definitions

The following terms and definitions apply to the document.

Data Key

Data key is a key used to encrypt PINs or calculate MACs, which could be classified
into two types, i.e. the MAC key (MAK) and the PIN key (PIK). It could also be
referred to as a working key.

HSM (Hardware Security Module)

Hardware security module is the periphery hardware equipment used for PIN
encryption and decryption, MAC calculation and validation, and key storage.

MAC (Message Authentication Code)

Message authentication code is the data used to authenticate the correctness of

message source.

MAK (MAC Key)

MAC key is a key used to generate message authentication code (MAC) data.

MMK (Member Master Key)

Member master key is an encryption key which is used to encrypt MAK and PIK, and
protected by master key (MK).

PIN Block

It is a formatted PIN block.

PIN (Personal Identification Number)

PIN is a personal password, which is the data used to verify the cardholder’s identity
for an online transaction. It shall not be presented in plaintext in any computer and
network system.

PIK (PIN key)

PIN key is a key used to encrypt PIN.

UPI Confidential 3
 Part IV: Data Secure Transmission Control

4 Key Management and Control

4.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.

4.1.1 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.

4.1.2 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
UPI Confidential 4
 Part IV: Data Secure Transmission Control

 To adopt MACs

 To adopt HSMs (requirement for all Members)

 To adopt point-to-point data encryption/decryption network mechanisms

4.1.3 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:

 To support both single-length keys (B64, which is applicable to single DES) and
double-length keys (B128, which is applicable to triple DES)

 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.

4.1.4 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.
M

m
M

Member Member
e

e
m

s
r

GSCS
b
e

s
r

HSM HSM

Figure 1 Data Encryption and Transmission Environment

HSMs in GSCS and Members’ networks form a point-to-point data

UPI Confidential 5
 Part IV: Data Secure Transmission Control

encryption/decryption structure. GSCS defines Data Keys with each Member.

4.2 Keys 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

Original Encryption/
No Key Name Abbr. Level Generation Decryption Location Length Protection Mode
Method Objective

HSM; outside of HSM,

Manually different parts of the
1 Master Key MK 1 MMK 192 bit Hardware
Input key shall be kept by
different persons

Manually
Input or Encrypted with
Member
2 MMK 2 Generated by DK HSM and Host 128 bit the MK in case of
Master Key
HSM output from HSM
randomly

data
key(PI
N
Data Key (e.g.
key— Generated by 64 bit/ 128 Encrypted with
3 PIN Key, 3 PIN Host
PIK, HSM bit MMK
MAC Key)
MAC
key--
MAK)

The generation and input procedures for MKs and MMKs shall be regulated by
relevant security policies.

4.3 Key Generation

Table 2 Key Generation

No. Key Name Generation

1 Master Key Manually generated

GSCS generates a half of the key and the Member generates the
2 Member Master Key other half; the two halves shall be combined in a HSM, or

GSCS generates randomly and hashes 2 components in the HSM,

UPI Confidential 6
 Part IV: Data Secure Transmission Control

or

UPI and the Member negotiate how to generate the MMK.

3 PIN Key Randomly generated in a HSM and pass the validity test

4 MAC Key Randomly generated in a HSM and pass the validity test

4.3.1 Data Key (DK) Generation

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.

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.

Members shall send key reset messages to GSCS if they need new keys.

4.3.2 Member Master Key (MMK) Generation

GSCS generates a half of an MMK and the Member generates the other half; The two
parties shall input and combine the two halves in their HSMs respectively, or

GSCS randomly generates 2 components in the HSM, or

UPI and the Member negotiate how to generate the MMK.

4.3.3 Master Key (MK) Generation

An MK should be input into a 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.

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 stored and protected in the HSM.

The MK will be destroyed automatically in case of any unauthorized operation to the

HSM.

4.4 Key Distribution

Table 3 Key Distribution

No. Key Name Key Distribution

1 Master Key Generated independently, no distribution needed

Delivered by security envelope, or

2 Member Master Key
Input by personnel from both UPI and the Member on site, or

UPI Confidential 7
 Part IV: Data Secure Transmission Control

UPI and the Member discuss and determine the way of

distribution.

Generated by the HSM of GSCS, and distributed in online

3 PIN Key
messages

Generated by the HSM of GSCS, and distributed in online

4 MAC Key
messagesGSCS

4.4.1 Data Key (DK) Distribution

Data Keys are generated by UPI’s HSM and distributed in online messages. For
detailed information on distribution, please refer to Section 6 of this document.

4.4.2 Member Master Key (MMK) Distribution

For Members outside Mainland China, MMKs can be distributed in three ways:

 Delivered by security envelope

 Input by personnel from both UPI and the Member on site

 UPI and the Member discuss and determine the way of distribution.

4.5 Key Storage

4.5.1 Storage of Data Key (DK)/Member Master Key (MMK)

Data Keys and Member Master Keys shall be stored in HSMs. The keys must be in
cryptograph unless they are stored in HSMs.

4.5.2 Master Key Storage

Master Keys shall be stored and protected in HSMs.

4.5.3 Key Documents Keeping

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 destroy of key shall
be under supervision with corresponding records.

4.6 Key Destroy

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 8
 Part IV: Data Secure Transmission Control

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

5.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.

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

Note 1: C- Control Code %B0000

Note 2: N- PIN Length (4-bit)

Note 3: P- 4-bit binary PIN digit

Note 4: P/F- 4-bit binary PIN digit/FILLER

Note 5: F- 4-bit %B1111 (FILLER)

Figure 2 Format of PIN Data Block 1

A typical process of PIN encryption/decryption is demonstrated in Figure 3. 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.

Terminal Acquirer GSCS Issuer Issuing Bank

1 4 7 10

2 3 5 6 8 9

HSM HSM HSM

Figure 3 Process of PIN Encryption/Decryption

In Figure 3, the encryption/decryption process between the terminal, the Acquirer,

GSCS, and the Issuer is as follows:

UPI Confidential 9
 Part IV: Data Secure Transmission Control

 －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

 －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

5.1.1 PIN Length

A PIN is composed of 4-12 numeric digits.

5.1.2 PIN Character Set

A PIN is denoted with numeric characters. The following table presents the binary
code for the PIN character set:

Table 4 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

5.1.3 PIN BLOCK

The PIN Block format shall be consistent with the PAN information format published
in ISO ANSI X9.8.

UPI Confidential 10
 Part IV: Data Secure Transmission Control

ANSIX9.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 data block is as follows:

Table 5 PIN Data Block

Location Length Description

1 1 BYTE PIN length

2 7 BYTE 4-12 digit PIN (each digit in 4 binary bits), padded with hex F

PAN data block is as follows:

Table 6 PAN Data Block

Location Length Description

1 2 BYTE %H0000

The last 12 digits of the PAN (excluding the check digit); it shall be right-
3 6 BYTE
justified with leading zeros 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: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF

XOR: 0x00 0x00 0x67 0x89 0x01 0x23 0x45 0x67

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

UPI Confidential 11
 Part IV: Data Secure Transmission Control

PIN data block: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF

PIN block: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF

XOR: 0x00 0x00 0x45 0x67 0x89 0x01 0x23 0x45

Result: 0x06 0x12 0x71 0x31 0x76 0xFE 0xDC 0xBA

PIN Block format shall be indicated in Field 53 (Security Related Control Information)
of the message.

5.1.4 PIN Encryption Method

A PIN cryptograph can be generated by the double-length key algorithm from the two
sources, i.e. 1) the PIN Block generated as above and input into the HSM and 2) the
PIK stored in the HSM. For Members outside Mainland China, double-length key
algorithm is mandatory.

5.1.5 PIN Abnormity Processing

Please see Chapter 10: Flow of Transaction Abnormalities Processing in Part I

Transaction Processing of Technical Specifications on Bankcard Interoperability.

5.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 ISO8731-1992 Approved Algorithms for

Authentication.

5.2.1 Condition of MAC Usage

MAC support is optional for Members. MAC is applicable to the 01XX, 02XX, 04XX,
08XX messages (08XX is the key exchange message). It is not applicable to other
management messages (06XX) and network management messages (08XX).

When Acquirers support MAC, they shall generate MACs in request messages. GSCS
will also generate MACs in response messages.

When Issuers support MAC, GSCS will generate MACs in request messages, and
Issuers shall generate MACs in approved response messages. (It is optional for Issuers
to generate MACs in disapproved messages)

5.2.2 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.

UPI Confidential 12
 Part IV: Data Secure Transmission Control

 Data fields representing message features, including message type, transaction

type, etc.

 Data fields relating to transaction, including card number, amount, response code,
etc.

5.2.2.1 Data Fields for Message of 01xx, 02xx, 04xx

If the following data fields are present or meet certain conditions, they should be
included in MAC calculation:

Table 7 Data Fields for MAC calculation of MTI in 01xx, 02xx and 04xx

No Field Field Name Attribute

1 0 Message-type-identifiera n4

2 2 Primary-account-numberb n...19(LLVAR)

3 3 Processing-code n6

4 4 Amount-of-Transactions n12
5 7 Transmission-date-and-time n10

6 11 System-trace-audit-number n6

7 18 Merchants-type n4
8 25 Point-of-service-condition-code n2

9 28 Amount-transaction-fee x+n 8

10 32 Acquiring-institution-identification-codec n..11(LLVAR)

11 33 Forwarding-institution-identification-coded n..11(LLVAR)

12 38 Authorization-identification-response an6

13 39 Response-code an2

14 41 Card-acceptor-terminal-identification ans8

15 42 Card-acceptor-identification-code ans15
16 90 Original-data-elements n42
a
Message-type-identifier: 0100/0110, 0200/0210, 0220/0230, 0420/0430, and
0422/0432)
b
Primary-account-number: a PAN length of 2 bytes + PAN. For Token Payment
transaction, if the value of Field 2 is a 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.
c
Acquiring-institution-identification-code: a length of 2 bytes length (n)+institution
ID with a maximum length of 11 bytes

UPI Confidential 13
 Part IV: Data Secure Transmission Control

d
Forwarding-institution-identification-code: a length of 2 bytes length
(n)+institution ID with a maximum length of 11 bytes
e
Original-data-elements: the first 20 positions only, as follows:
org-message-type n4 Original Message Type

org-system-trace-number n6 Original Message Trace No.

Original Message Transmission

org-transmission-date-time n10
Time

5.2.2.2 Data Fields for Key Management Transaction Message

Key Management Message is the request for key reset and the corresponding response
message. The MAC is composed of the following fields:

Table 8 Data Field for Key Management Transaction Message

No Field Field Name Attribute

1 0 Message-typea n4

2 7 Transmission-date-and-time n10

3 11 System-trace-audit-number n6

4 39 Response-code an2

5 53 Security-related-control-informationb n16

6 70 Network-management-information-codec n3

7 100 Receiving-institution-identification-coded n..11(LLVAR)

a
Message-type-identifier: (0800/0810)
b
For the security-related-control-information, please refer to the explanation in
Field 53 as follows:
1000000000000000 —— Reset PIN Key PIK
2000000000000000 —— Reset MAC Key MAK
c
Network-management-information-code: 101
d
Receiving-institution-identification-code: a 2-position length (n) +a maximum-11-
position institution ID

5.2.3 MAC Block Composition

5.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

UPI Confidential 14
 Part IV: Data Secure Transmission Control

 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

 Remove blanks at the beginning and ending of all fields

 Replace consecutive blanks with a single blank.

5.2.3.2 Composition of MAC Block (MAB)

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.

5.2.4 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.

5.2.4.1 MAC Calculation through MAB by HSM

5.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:

a) Execute DES operation

UPI Confidential 15
 Part IV: Data Secure Transmission Control

b) 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:

Perform DES operation on A1 with the MAK to generate B1;

XOR B1 with A2, perform DES operation on the result with the MAK to generate B2

XOR B2 with A3, perform DES operation on the result with the MAK to generate B3

XOR B3 with A4, perform DES operation on the result with the MAK to generate the
final encrypted value of 8 bytes

5.2.4.1.2 Double-Length Key Algorithm

According to ISO 9.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:

a) XOR the next group with the result generated by using the left 64 bits in the
double length-key to the first group

b) XOR the result of the Step a. with all the remaining groups repeatedly until the
last group.

c) 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:

Perform DES operation on A1 with K1 to generate B1;

XOR B1 with A2 and perform DES operation on the result with K1 to generate B2

XOR B2 with A3 and perform DES operation on the result with K1 to generate B3

XOR B3 with A4 and perform DES operation on the result with K1 to generate B4

Decrypt B4 with K2 to generate B5

UPI Confidential 16
 Part IV: Data Secure Transmission Control

Encrypt B5 with K1 to generate the final encrypted value of 8 bytes.

5.2.4.2 MAC Field Value of Online Message

5.2.4.2.1 General Transaction

The MAC field (Field 128), which is the first half of the 8-byte binary digit (a 4-byte
binary digit) calculated by DES or 3DES operation, is presented in the form of a hex
character string (eight hex characters).

5.2.4.2.2 Key Reset Transaction Initiated by GSCS

In the key 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.

5.2.4.2.2.1 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 is the first half of the 8-byte binary number (a
4-byte binary number) obtained by MAC calculation based on the single-length key
algorithm (refer to Section 5.2.4.1.1 for DES MAK reset algorithm) or double-length
key algorithm (refer to Section 5.2.4.1.2 for 3DES MAK and PIK reset algorithm),
and the second part is the first half of the 8-byte binary number (a 4-byte binary
number) obtained by Check Value calculation based on the single-length key
algorithm (refer to Section 5.2.4.1.1 for DES MAK reset algorithm) or double-length
key algorithm (refer to Section 5.2.4.1.2 for 3DES MAK and PIK reset algorithm).

5.2.4.2.2.2 MAC Calculation in Response Message

If a DES MAK is to be reset, the algorithm of MAC calculation in response message

is the same as that of the general transaction described in Section 5.2.4.1.1. There’s
no need to calculate the Check Value, but the key for the MAC calculation shall be
the newly distributed key.

If a 3DES MAK or a PIK is to be reset, the algorithm of MAC calculation in response

message is the same as that described in Section 5.2.4.1.2. There’s no need to
calculate the Check Value either, but the key used shall be the newly distributed key.

5.2.4.2.2.3 Check Value Calculation

The Check Value can be obtained by single-length key algorithm (refer to Section
5.2.4.1.1 for DES MAK reset algorithm) or double-length key algorithm (refer to
Section 5.2.4.1.2 for 3DES MAK and PIK reset algorithm) on eight-byte binary 0
with the new distributed key.

UPI Confidential 17
 Part IV: Data Secure Transmission Control

5.2.4.2.3 MAC Calculation When Double-length PIN Key is Reset

A new PIN key may be a 128-byte double-length key when the PIN key is reset, the
double-length key algorithm should apply to MAC calculation in both request
messages and response messages. Similarly, the double-length key algorithm should
apply to Check Value calculation in request messages. For MAC calculation and
Check Value calculation flow, please refer to Section 5.2.4.1.2.

5.2.5 MAC Error Processing

Please see Chapter 10: Flow of Transaction Abnormalities Processing in Part I

Transaction Processing of Technical Specifications on Bankcard Interoperability.

5.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 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.

5.3.1 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.

5.3.2 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.

5.3.3 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.

5.3.4 MAC Calculation

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 seconds half
UPI Confidential 18
 Part IV: Data Secure Transmission Control

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.

5.3.5 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 Chapter 5 Basic
Stipulations in Part III File Interface of Technical Specifications on Bankcard
Interoperability.

5.4 Encryption and Decryption for Internet Payment PIN of Internet Transaction

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 tranmission between UPI and
Members is as follows:

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

Note 1: P means password, F means filler

Note 2: N - length of Internet Payment PIN (8-bit)

Note 3: P - the 8-bit binary digits of Internet Payment PIN

Note 4: P/F - the 8-bit binary digits of Internet Payment PIN/FILLER

Note 5: F - 8-bit binary digits of internet payment PIN FILLER

Figure 4 Internet Payment PIN Data Block Format

5.4.1 Length of Internet Payment PIN

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

5.4.2 Character set for Internet Payment PIN

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

5.4.3 Data Block of Internet Payment PIN

The Internet Payment PIN should be formatted as follows:

Table 9 Format of Internet Payment PIN

UPI Confidential 19
 Part IV: Data Secure Transmission Control

Position Length Description

1 2 BYTE Length of Internet Payment PIN

The length of the Internet Payment PIN ranges from 6 to 20 digits (each
2 22 BYTE character is 1 byte digit left-justified with trailing spaces if there is any
vacancy, i.e. 0xFF)

Example:

Assuming the plaintext of the Internet Payment PIN is Hello!123:

As the Internet Payment PIN is displayed in plaintext, it is needed to be changed to the ASCII code.

Plaintext of Internet Payment

H e l l o ! 1 2 3
PIN

ASCII code 72 101 108 108 111 33 49 50 51

Hex 0x48 0x65 0x6C 0x6C 0x6F 0x21 0x31 0x32 0x33

Figure 5

As described in Figure 5, this Internet Payment PIN has 9 characters, so “09” is added
in front of the PIN, indicating the length, which ASCII code is 48 and 57; Hex code
is 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

5.4.4 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 DES or 3DES operation with the single or double length PIK saved in
HSM.

Here are 2 points to be noted:

1) The key for calculating Internet Payment PIN is the PIK;

2) The Internet Payment PIN key should be subject to the double-length key
algorithm.

5.4.5 Error Processing

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

UPI Confidential 20
 Part IV: Data Secure Transmission Control

5.5 File Encryption and Decryption in Flow Transmission Mode

5.5.1 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.

5.5.2 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 21
 Part IV: Data Secure Transmission Control

6 Key Reset
6.1 Key Reset Request Initiated from Members

6.1.1 Transaction Flow

A Member sends the request for Key Reset to GSCS. Upon receiving the request
message, GSCS shall reply immediately. Meanwhile, GSCS shall start up the Key
Renewal Module to generate a new key and send the Member the new key in a Key
Reset Message.

GSCS will drop the message in case GSCS fails to reply to the Key Reset Request or
sends Key Reset to Member.

1
2

GSCS 3 Member

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

2——Response sent by GSCS to a Member (0830)

3——Key Reset sent by GSCS to a Member (0800)

4——Response sent by a Member to GSCS (0810)

Figure 6 Flow of Key Exchange Request by a Member

UPI Confidential 22
 Part IV: Data Secure Transmission Control

6.1.2 Flowchart

Start

N
Send the request of RSI-MB-SC

Conditions to activate Y
Await, whether Error, whether
RSI-MB-SC:
time out manual processing
1. Time to conduct regular key
distribution; Y
2. Manual trigger;
3. Every N transactions.
Manual processing
N

After CUPS sends a RSI-SC-MB

response, it immediately
activates encryption module,
generates a new key, and sends
Receive KSM-SC-MB requests KSM-SC-MB request.

Get new key, verify message

MAC with new key to validate
Y the message data N

Generate KSM-MB-SC message, set RC “00”,

generate MAC with new key, send i t to CUPS, s e t
key launch timer to 0, enter time-window to switch
the key from the old to the new, and launch new key Generate KSM-MB-SC message, set RC “A7”, send it to
to encrypt message. CUPS, report failure to apply new key, have old key
remain in use or re-apply by starting from the very
beginning of the flow and then re-performing the whole
process.
Close the time-window and use new key to replace
old key upon launch time shown by the timer.

End

Note 1: RSI－MB－SC : Key Reset Application Request Message sent by a Member to UPI (0820)

Note 2: RSI－SC－MB: Key Reset Application Response Message sent by UPI to a Member (0830)

Note 3: KSM－SC－MB: Key Reset Request Message sent by UPI to a Member (0800)

Note 4: KSM－MB－SC: Key Reset Response Message sent by a Member to UPI (0810)

Figure 7 Flow of Key Exchange Request by a Member

6.1.3 Explanation on Key Reset request initiated from a Member

Phase I: Send Key Reset Request to UPI

A Member may send a key reset request (RSI-MB-SC) (0820) to UPI when necessary,
and then wait for the response message from GSCS (RSI-SC-MB) (0830). The
UPI Confidential 23
 Part IV: Data Secure Transmission Control

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 message (KSM-SC-MB) (0800), a Member shall extract the new key upon
receiving the KSM-SC-MB and verify the MAC embedded in the message (refer to
5.2.4.2.2.1 for calculation of MAC in request 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 (refer to 5.2.4.2.2.2 for
calculation of MAC in 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:

a). To replace the old key with a new one

b). To eliminate the start-up tag attached to the new key

c). 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.

6.1.4 Message Format

The message format for Key Reset Request (RSI-MB-SC) by a Member is as follows:

Table 10 Message Format of Key Reset Request

Position Field Name Description

MESSAGE-TYPE－IDENTIFIER Value “0820”
BIT-MAP b128
7 TRANSMISSION-DATE-AND-TIME System Time

UPI Confidential 24
 Part IV: Data Secure Transmission Control

11 SYSTEM-TRACE-AUDIT-NUMBER System Trace No.

33 FORWARDING-INSTITUTION-IDENTIFICATION-CODE Forwarding institution
53 SECURITY-RELATED-CONTROL-INFORMATION 1st bit: Key Type (leftmost)

1identification
PIK code
2 MAK

2nd bit: Encryption Algorithm Type

0 DES

6 3DES

3rd-16th bits: Preserved, currently

70 NETWORK-MANAGEMENT-INFORMATION-CODE fill with

Value “0”
“101”

The format of the Key Reset Request response message (RSI-SC-MB) generated by
UPI for a Member is as follows:

Table 11 Message Format of Response for Key Reset Request by a Member

Position Field Name Description

MESSAGE-TYPE－IDENTIFIER Value “0830”

BIT-MAP b128
7 TRANSMISSION-DATE-AND-TIME System Time
11 SYSTEM-TRACE-AUDIT-NUMBER System Trace No.
33 FORWARDING-INSTITUTION-IDENTIFICATION-CODE Forwarding institution ID
39 RESPONSE-CODE Response Code
53 SECURITY-RELATED-CONTROL-INFORMATION 1st bit: Key Type (leftmost)

1 PIK

2 MAK

2nd bit: Encryption Algorithm Type

0 DES

6 3DES

3rd-16th bits: Preserved, currently

70 NETWORK-MANAGEMENT-INFORMATION-CODE Value “101”
filled with “0”

A Member shall send GSCS a key Reset application request 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 request according to their own needs.

6.2 Key Reset initiated by GSCS

6.2.1 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 25
 Part IV: Data Secure Transmission Control

GSCS Member
2

1—Key Reset request sent by GSCS to Member (0800) (referred to as KSM－SC－MB)

2—Response to Key Reset request, sent by a Member to GSCS (0810) (referred to as

KSM－MB－SC)

Figure 8 Flow of Key Reset initiated by GSCS System

UPI Confidential 26
 Part IV: Data Secure Transmission Control

6.2.2 Flowchart

Start

Conditions to activate PIK and

MAK:
1. Time to conduct regular key
distribution;
2. Manual trigger;
3. Every N transactions.

Re-send KSM-SC-MB request

Generate new PIK or MAK
message without generating
additional PIK or MAK

Send KSM-SC-MB, await response N

Y Error, whether
Time out? manual processing

N
Y
Receive KSM-MB-SC message

Manual processing

Verify MAC in N
KSM-MB-SC with
new key to validate
message data

Set key launch timer to 0, enter time window to

switch the key from the old to the new, and
launch new key to encrypt various messages

Close the time window and use new key to

replace old key at the launch time shown by
the timer.

End

Note 1: KSM－SC－MB: Key Reset Request Message sent by GSCS to a Member (0800)

Note 2: KSM－MB－SC: Key Reset Response Message sent by a Member to GSCS (0810)

Figure 9 Flow of Key Reset initiated by GSCS

6.2.3 Description on Key Reset Initiated by GSCS

UPI waits for the Key Reset response message (KSM-MB-SC) (0810) from a Member
after sending a Key Reset message (KSM-SC-MB) (0800)

If there is no response from the Member within the time limit, manual processing will

UPI Confidential 27
 Part IV: Data Secure Transmission Control

be adopted directly.

Upon receiving the successful key reset response message (KSM-MB-SC) from a
Member, GSCS will check the MAC with the new key (refer to Section 5.2.4.2.2.2
for calculation of MAC in response message). 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:

a). To replace old key with new one

b). To eliminate start-up tag attached to new key

c). 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.

6.2.4 Message Format

The format of Key Reset Message initiated by GSCS is as below:

Table 12 Format of Key Reset Message initiated by GSCS

Position Field Name Description

MESSAGE-TYPE－IDENTIIER Value “0800”

BIT-MAP b128

7 RANSMISSION-DATE-AND-TIME System Time

11 SYSTEM-TRACE-AUDIT-NUMBER System Trace No.

48 ADDITIONAL-DATA-PRIVATE New Key Cryptogram

53 SECURITY-RELATED-CONTROL-INFORMATION 1st bit: Key Type (leftmost)

1 PIK

2 MAK

2nd bit: Encryption Algorithm Type

UPI Confidential 28
 Part IV: Data Secure Transmission Control

Position Field Name Description

0 DES

6 3DES

3rd-16th bits: preserved, currently

fill with “0”

70 NETWORK－MANAGEMENT－INFORMATION－ Value “101”

CODE

96 MESSAGE－SECURITY－CODE New key cryptogram with

maximum length of 8 bytes

100 RECEIVING-INSTITUTION-IDENTIFICATION-CODE Receiving institution ID

128 M AC Message Authentication Code

The format of Key Reset Response Message (KSM-MB-SC) initiated by Members

for GSCS is as below:

Table 13 Format of Key Reset Response Message initiated by Members

Position Field Name Description

MESSAGE-TYPE－IDENTIFIER Value “0810”

BIT-MAP b128

7 TRANSMISSION-DATE-AND-TIME System Time

11 SYSTEM-TRACE-AUDIT-NUMBER System Trace No.

39 RESPONSE-CODE Response Code

1st bit: Key Type (leftmost)

1 PIK

2 MAK

2nd bit: Encryption Algorithm Type

53 SECURITY-RELATED-CONTROL-INFORMATION
0 DES

6 3DES

3rd-16th bits: Preserved, currently

filled with “0”

NETWORK － MANAGEMENT － INFORMATION －

70 Value “101”
CODE

100 RECEIVING-INSTITUTION-IDENTIFICATION-CODE Receiving Institution ID

128 MAC Message Authentication Code

UPI Confidential 29
 Part IV: Data Secure Transmission Control

6.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 (Key Reset Request Message, 0800) and decrypted the
key. The MAC value in the KSM-MB-SC (Key Reset Response Message, 0810) 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 (Key Reset Response Message, 0810) 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 30
 Part IV: Data Secure Transmission Control

Time Time

Member GSCS

Transaction message, old key

Prepare for triggering key
RSI-MB-SC exchange
At T1, initiate request for key
exchange
T1
At T2, generate new key from
RSI-SC-MB T2 HSM

Transaction message B with

old key, because it is sent Transaction message A, old key
before KSM-SC-MB
KSM-SC-MB
T3 At T3, CUPS sends a new key
T4
At T4, KSM-SC-MB is Transaction message C, old key
successfully certified, launches
new key, and triggers the
time-window
KSM-MB-SC At T5, key exchange succeeds,
Receive KSM-SC-MB, T5 triggers the time-window
transaction message D with
Three new key Successful receiving
minutes KSM-MB-SC, transaction Three
At T6, replace old key with message E with new key minutes
new key, key exchange
completed, and time window T6
closed At T7, replace old key with new
T7 key, key exchange completed,
and time window closed

Figure 10 Key Reset Time and Event

UPI Confidential 31
 Part IV: Data Secure Transmission Control

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

7.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.

7.2 Algorithms of ARQC

7.2.1 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.

7.2.2 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.

a). 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.

b). 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

UPI Confidential 32
 Part IV: Data Secure Transmission Control

 To take the 16 rightmost hex digits if the length exceeds 16 digits

D2 is obtained by reversal of the above Data Block D1.

c). To perform 3DES operation on D1 with the MDK and obtain an 8-byte UDK A;
similarly, perform 3DES operation on D1 with the MDK and obtain an 8-byte
UDK B.

UDK B is put next to UDK A to create the UDK as shown in the following chart:

UDK A UDK B

UDK

Figure 11Derivation Algorithms of Key (MDK creates UDK)

7.2.3 Derivation Algorithms of Double-length Key

a). To calculate the UDK based on the MDK

b). 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

c). 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

d). To create the session key (totally 16 bytes) by combining the first eight bytes and
the last eight bytes as depicted in the following chart:

Session Key A Session Key B

Session Key

Figure 12 Derivation Algorithms of Dual-length Session Key

The Session key must meet requirements for odd parity.

7.2.4 Algorithms of ARQC

7.2.4.1 Data Source

The Issuer may decide the data source and sequence for ARQC calculation at its
UPI Confidential 33
 Part IV: Data Secure Transmission Control

discretion. The commonly-used data source and sequence can be adopted if Issuer
does not exercise its discretion. For details, please see the following table:

Table 14 Data Source of ARQC

Terminal Data involved

Data from Corresponding
No. Data Elements in Terminal Field Hash Data in Card
Terminals Message Tag
Value Computation

1 Authorized Amount 9F02

2 Other Amount 9F03

3 Terminal Country Code 9F1A

Terminal Verification
4 95
Result

Transaction Currency
5 5F2A
Code

6 Transaction Date 9A

7 Transaction Type 9C

8 Unpredictable number 9F37

Application Interchange
9 82
Profile (AIP)

Application Transaction
10 9F36
Counter (ATC)

Issuer applied Card

11 9F10
Verification Result (CVR)

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-1and, 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:

Hash Result Terminal Data (length determined by Card Data (length determined by
(20 bytes) actual content in message field) actual content in message field)

Figure 13 Source Data Sequence for ARQC Calculation

UPI Confidential 34
 Part IV: Data Secure Transmission Control

7.2.4.2 Approach for ARQC Calculation

a). To divide the above-mentioned data block into groups of 8 bytes: D1, D2, D3…

b). 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. 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:

1). 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)

2). To perform single DES ECB decryption with the SKR to generate an
MAB_C

3). To perform single DES ECB encryption with the SKL to generate a 8-digit
ARQC.

7.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:

a). 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”;

b). 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:

1). If the data object is presented in numeric format (n), bytes shall be curtailed
from the left most of the data unit;

2). If the data object is presented in other format, bytes shall be curtailed from
the rightmost of the data unit.

In case the denoted length is longer than that of the actual data, the actual data
shall be padded to the denoted length:

1). If the data object is presented in numeric format (n), a hex “0” shall be
padded from the left most of the data unit

UPI Confidential 35
 Part IV: Data Secure Transmission Control

2). If the data object is presented in other format, a hex “FF” shall be padded
from the rightmost of the data 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).

7.2.5 ARPC Calculation

ARPC is generated from ARQC. The detailed algorithm is as below:

a). 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.

b). 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 36