Impact of migration on the issuer's system

[Tomcat]

To service microprocessor cards, the issuer host must support a number of additional features over the magnetic stripe card issuer host. These additional functions relate to both the authorization request processing system and the issuer's back-office system, which is responsible for processing clearing files and personalizing cards.

Additional functions for processing authorization requests in the issuer's system include:

• withdrawal of master keys of the card MK AC, MK SMI, MK SMC, MK IDN, MK DAC from the keys of the issuer;
• withdrawal of session keys from the card keys for generating a cryptogram, calculating MAC values and encrypting confidential data;
• verification of the ARQC / TC cryptogram;
• checking the DAC and / or IDN values to confirm that the terminal is performing offline static or dynamic card authentication;
• analysis of data received by the issuer from Issuer Application Data objects (CVR, offline card counters, DAC / IDN, other data specified by the issuer in the Issuer Discretionary Data of the IAD object), TVR (Tag '95'), CVM Results (Tag '9F34' ) and making a decision on the method of completing the transaction based on the results of this analysis;
• checking whether the value of the cryptogram type received by the issuer from the data field of the CID object (Cryptogram Information Data, Tag '9F27') matches the value of the corresponding bits of the cryptogram type of the CVR object extracted by the issuer from the Issuer Application Data object (the CID and IAD objects are obtained by the issuer from DE 55 authorization request / clearing message). These values must match. In this case, the comparison should be based on the values of the bits of the cryptogram type obtained from the CVR object, provided that the verification of the cryptogram was completed successfully (the correct value of the cryptogram means, among other things, the integrity of the data of the CVR object). If the cryptogram is correct, but there is no correspondence between the values of the cryptogram type in the CID and CVR objects, then the issuer must accuse the merchant of distorting the result of the end of the transaction (see details in clause 6.
• it is recommended to analyze the Issuer Script Results data object, if this object is transferred to the issuer, so that the issuer understands which commands of the Script Processing procedure were executed successfully and what, as a result, is the current state of the card's risk management parameters;
• to combat repeated submission of a transaction, it is important for the issuer to monitor the value of the ATC for each card and to link other time-dependent (more precisely, the operation number) parameters to the ATC, for example, ICC Dynamic Number;
• the issuer of the MasterCard chip card is recommended to reject transactions in which DE 061 (POS Data) indicates that the terminal can perform an operation on the chip, but conducts it along the magnetic stripe, and the POS Entry Mode (DE022) is not equal to 80x (case of fallback );
• the issuer of the VISA chip card is advised to reject transactions in which the following conditions are met at the same time:
• - DE22.1 = “90” or “02” (magnetic stripe read);
• - DE60.2 - “5” (chip capable terminal);
• - DE60.3 “1” (Fallback. No info about chip read error on previous

transaction in that terminal) or “2” (Fallback. There was chip read error on previous transaction in that terminal), which indicates that the terminal can perform an operation on the chip, but conducts it along the magnetic stripe;

• in order to combat fraud associated with unjustified use of the fallback mode on the magnetic stripe, the issuer is recommended to organize control of the number of transactions performed in this mode on each card;
• it is advisable to use different modes of transaction processing in different situations: for example, all international transactions can be made online due to the appropriate choice of card risk management parameters, since it is for international transactions that the highest level of card fraud is observed;
• preparation of data for a response to the serving bank (field DE 55): Issuer Authentication Data, including ARPC cryptogram, and Issuer Script Processing Template blocks.

Note that both the authorization request and the clearing message do not contain a field for transmitting the Issuer Script Results data object to the issuer. It is possible to use the Issuer Discretionary Data section of the Issuer Application Data object to transfer this object. To do this, the card application must support this function (currently known implementations of VSDC and M / Chip 4 applications do not support it).

The issuer's back-office system should take into account the following additional functions:

• withdrawal of master keys of the card MK AC, MK IDN, MK DAC from the keys of the issuer;
• output of the session key for generating a cryptogram from the key of the MK AS card ;
• checking the value of the TS cryptogram;
• checking the DAC and IDN values to confirm that the terminal is performing static or offline dynamic card authentication;
• control of ATC values and use of ATC values to search for a hold by the received presentation;
• preparation of personalization data for hybrid cards;
• preparation of scripts for personalizing hybrid cards.

A bank embarking on the issuance of microprocessor cards should also pay attention to the ability of the HSM cryptographic modules at its disposal to support the functions of processing online transactions, processing clearing files and preparing personalization data for hybrid cards. HSMs must support RSA and a variety of diversification modes used to derive card master keys and session keys.

Another HSM-related aspect that needs to be taken into account when migrating to an IPC is that the load on the HSM that handles online authorizations changes dramatically. It should be noted that the performance of the HSM can determine the throughput of the entire authorization request processing system. This is due to the fact that the lion's share of the work in the additional checks described above falls on the HSM module.

To assess the influence of the increased load on the HSM module, we construct a simplified mathematical model.

To begin with, let's define 5 groups of operations and the corresponding calls to the HSM module of the issuer's host. We will assign each request to its complexity in the form of the number of encryption operations using the 3DES algorithm that will be used in this request. We will assume that the resource-intensive AVDK algorithm (see section 3.16.2) is not used to output session keys, which requires up to 16 3DES operations (the tree height can be 8 and at each tier of the algorithm two 3DES encryption operations are used). This assumption is legitimate, since the AVDK algorithm is now excluded from the EMV standard and is not supported by leading payment systems.

Group No. 1. Operation of online card authentication. Complexity - 6 3DES operations.

• 1. Derivation of the master key of the card for generating the cryptogram MK AS from the corresponding key of the card issuer. 2 operations.
• 2. Derivation of the session key for generating the SK AC cryptogram from the MK AS key . 2 operations.
• 3. ARQC check. 1 operation.
• 4. Formation of ARPC. 1 operation (assuming Format 1 ARPC cryptogram)

Group No. 2. Checking the IDN value. Complexity - 5 3DES operations.

• 1. Derivation of the MK IDN card master key to generate IDN from the corresponding key of the card issuer. 2 operations.
• 2. Checking the IDN value. 1 operation.

Group No. 3. Ensuring the integrity of information in the commands of the Script Processing procedure. Complexity - X + 4 3DES operations, where X is the number of instructions in the Script Processing procedure.

• 1. Withdrawing the master key of the MK SMI card to generate the MAC (Message Authentication Code) value from the corresponding key of the card issuer. 2 operations.
• 2. Outputting the session key for generating the MAC SK SMI value from the MK SMI key . 2 operations.
• 3. Calculation of MAC values for each command of the Issuer Script Processing procedure. 1 operation per one command (it is supposed to use "short" commands such as APPLICATION BLOCK, APPLICATION UNBLOCK, CARD BLOCK).

Group No. 4. PIN-code check. Complexity - 1 3DES operation. It is assumed that the algorithm is IBM 3624 or VISA PW.

Group No. 5. Ensuring encryption of the PIN-block in the PIN CHANGE / UNBLOCK command. Complexity - 5 3DES operations.

• 1. Derivation of the master key of the MK SMC card for data encryption from the corresponding key of the card issuer. 2 operations.
• 2. Derivation of the session key for data encryption SK SMC from the MK SMC key . 2 operations.
• 3. Encryption of the PIN-block. 1 operation.

Table 6.9 shows the complexity of the implementation of various transactions in the system in terms of the groups used in the transaction and the number of 3DES operations. The column on the far right indicates the complexity of the operation in the case of using a magnetic stripe card.

Tab. 6.9. The complexity of the implementation of various operations

No.	Type of transaction	Groups	Number of 3DES operations	Number of 3DES operations for magnetic stripe
1	ATM without script	1 + 4	6 + 1 = 7	1
2	POS without script	1 + 2	6 + 3 = 9	0
3	ATM with script	1 + 3 + 4	6+ (X + 4) + 1 = 11 + X	-
4	POS with script	1 + 2 + 3	6 + 3 + (X + 4) = 13 + X	-
5	ATM PIN Change	1 + 3 + 4 + 5	6 + (1 + 4) + 1 + 5 = 17	2
6	ATM PIN Change co script	1 + 3 + 4 + 5	6+ (X + 4) + 1 + 5 = 16 + X, where X> 1	-

Let's make a few clarifications on the types of transactions. Transaction 1 represents such operations at an ATM as issuing cash, obtaining a certificate of the account balance, and forming a ministry statement. In this case, unlike transaction 3, the issuer does not use the Script Processing procedure.

Similarly, transactions 2 and 3 represent a purchase operation in a POS terminal, respectively, without and using the Script Processing procedure by the issuer.

Transaction 5 is an ATM PIN change operation. This operation for the microprocessor card is performed within the Script Processing procedure (PIN CHANGE / UNBLOCK command).

Transaction 6 repeats transaction 5 in everything, but in the Script Processing procedure, in addition to changing the PIN-code, other issuer commands are also used.

In our mathematical model, we will assume that when processing one group of operations, the issuer's host application occupies the HSM module to perform all operations within this group. This assumption, on the one hand, looks logical from the point of view of the functioning of the application software of the issuer's processing center, and on the other hand, it makes it easier for us to analyze the performance model of the HSM module.

Let us introduce the following notation:

- the intensity of the input Poisson flow of transactions of the issuer;

a is the share of the issuer's traffic attributable to transactions 1. Then we will assume that the remaining share 1 - a falls on transactions 2. Thus, we recognize the fact that it is these two types of transactions that form the majority of the issuer's transactions, and thus these two transactions define the distribution function of the time the group of operations is in the queue to the HSM. Since when performing transactions 1 and 2, only groups 1, 2 and 4 are used, we will assume that it is these groups of operations that determine the queue to the HSM module;

y is the proportion of transactions 2 performed online;

Xj is the intensity of the input Poisson flow of groups No. 1 to the HSM module. It is obvious that X] = X ( + (1 - a) X, y, and the average processing time of this group of operations on the HSM is = 6t, where m is the average time for the HSM module to perform a 3DES cryptographic operation;

X 2 is the intensity of the input Poisson flow of groups No. 2 to the HSM module. Obviously, X 2 - (1 - a) X, y, and the average processing time of this group of operations on HSM is equal to m 2 = Зт;

X 3 is the intensity of the input Poisson stream of groups No. 4 to the HSM module. Obviously, X 3 = aX b and the average processing time of this group of operations on the HSM is m 3 - m;

X 4 is the intensity of the input Poisson flow of requests to the HSM module to generate the Message Authentication Code value for messages circulating between the terminal and the host of the serving bank. Suppose that the protocols for the interaction of terminals (ATMs and POS terminals) with the host use MACing to ensure the integrity of the transmitted data. Assuming that the issue of the bank and the acceptance of cards are balanced, we will assume that the number of transactions with bank cards in another's network is approximately equal to the number of transactions processed by the bank using other people's cards. Then it is obvious that X 4 = 2 (aX, 4- (1 - a) X, y), and the average processing time of this group of operations on HSM is m 4= t (the HSM module checks the MAC of the authorization request of the terminal and generates the MAC for the authorization response sent to the terminal). The share of transactions leaving for authorization to another issuer, as well as those coming from a foreign network for authorization of the bank considered in the model, was not taken into account. These transactions are associated with calls to the HSM module for relaying PIN blocks.

We will simulate the queue to the HSM module by a queuing system M / G / l, at the input of which a Poisson flow of groups of operations of intensity A - A., + X, + X, + X 4 arrives . The average processing time of a group in the M / G / l system is equal to: and the second moment of this time is determined by the equality:

q 2 = ——

2 A

Then, in accordance with the Pollachek-Khinchin formula, the average time spent by an arbitrary group in the queue to the HSM is determined by the equality:

T = ——, where p = VXjj.

w 2 (1-p) I1 ? 1 '

Substituting the values of X, u (i = 1, ..., 4) into the expression for p, we get:

p = X] T [9a + 11 (1 - a) y].

Substituting the values of pj and q 2 into the expression for T w , we get:

m _ _ X, m 2 [39a + 47 (1 - a) y]

w 2 (1-p) 2 (1-p)

Chapter 6. FEATURES OF MIGRATION ON MICROPROCESSOR CARDS 499

di

Then, if Т, is the average time spent on servicing an HSM transaction of type i (i = 1, 6), we obtain the following formulas:

T 1 = 2T W 4- 7t;

T 2 = 2T W + 9t;

T 3 = 3T W + 12t;

T 4 = 3T W + 14t;

T 5 = 4T W + 17t;

T 6 = 4T W + 18t.

Above, we assumed that the number of commands in the Script Processing procedure is 1.

Obviously, earlier, when using cards with only magnetic stripe, the host of our bank accessed the HSM module as a servicing bank as often as in the case of an IPC, and when servicing the issue, only when servicing ATM traffic. In other words, in this case the load on the HSM module is created only by groups 3 and 4. Therefore, the value of the system load and the average service time in this case are equal to:

p (0) = aX, m + 2m [aA.! + (1 - a) yA.,] = A. [T [3a + 2 (1 - a) y],

(0) = X 1 t 2 [Za + 2 (1-a) y] w 2 (1 - p)

T $ o) = t + T®,

where T { 0) is the average execution time of an ATM transaction.

We will consider an average Russian bank, which processes L. during the hour of the greatest load, = 10 transactions per second (corresponds to a bank with 500,000 - 1 million cards). In what follows, we will assume that a = 0.8 and y = 0.8. Then we get:

p = 89.6 m;

• 193.6t 2
• (1-89.6t) '

^ 87 ^ + 7 T ;

• (1 - 89.6t)
• 387.2t 2 , _
• --------- h 9t; (1 - 89.6t)

T X W

T-

T 2

580.8t

"(1-89.6t)

580.8t

"(1-89.6t)

• 774.4t 2
• (1 - 89.6t)

+ 17t;

• 774.4t 2
• (1 - 89.6t)

+ 18t;

p t0) = 27.2m;

• 13.6t 2
• (1 -27.2t) '
• 13.6 t 2 tn -----------.
• (1 - 27.2t)

Taking into account the requirements of payment systems, the processing time of a transaction on the issuer's host should be equal in order to 1 second.

Taking the most time-consuming transaction, we get the inequality: whence, after solving the quadratic inequality, we get that m <0.01 seconds, that is, the HSM performance should be higher than 100 3DES cryptographic operations.

• 774.4t 2
• (1 - 89.6t)

+ 18t <1,

Note that earlier, when working with cards with a magnetic stripe, it was enough for the issuer's host to satisfy the inequality:

• 13.6t 2
• (1 - 27.2t)

from which it follows that t <0.036 seconds, that is, the HSM performance should have been higher than T7.7 of 3DES cryptographic operations. Thus, when migrating to an IPC while maintaining input traffic, the minimum permissible performance of the HSM module is more than 3.6 times higher than the same indicator in the case of a system that processes operations with magnetic stripe cards!