Choosing the IPC hardware and software platform
The choice of the hardware and software platform of the microprocessor card and the configuration of its application is largely determined by the tasks formulated by the Bank in its card programs. Here are a few examples to illustrate this.
If the Bank plans to use prepaid cards, it is obvious that most operations on such cards will be performed offline. Therefore, to avoid the possibility of fraudsters cloning SDA cards, it is advisable to use chips that support dynamic authentication methods for a prepaid card. Despite the fact that a card that supports dynamic authentication methods costs 30-40 cents more than a static card, it makes sense to use a DDA/CDA card as a prepaid card to ensure the security of operations.
The second example is an innovative Bank that offers its clients a set of different services, including not only the ability to perform standard payment operations on the card, but also the implementation of loyalty schemes, customer identification, etc. In such cases, it makes sense to think about using cards that support multi-layer Java Card and MULTI0S operating systems. Using such cards will allow the Bank to provide the necessary level of security for data related to various applications, remotely upload new applications to the card, and quickly develop and implement new applications.
In this case, there are obvious requirements for the size of eepr0m memory, which must be able to store data from the multi-layer operating system and applications, as well as program codes for certain applications. For example, when using a Java Card, you should choose a chip that has at least a 16-bit microprocessor and at least 16 KB of EEPR0M memory.
Another example is a Bank that is simultaneously a member of the two largest payment systems VISA and MasterCard. In July 2005, EMVCo released a draft of the Common Payment Application (CPA), which is simultaneously supported by both payment systems. The Bank that has chosen the SRA application as a universal payment application, while maintaining the functionality of the M/Chip 4 and VIS 1.4.x applications, makes it easier to solve the problem of risk management and personalization of microprocessor cards, as well as unifies transaction processing on its host in both payment systems.
Finally, the last example is the introduction of a Bank card for quick customer service, for example, in a fast food restaurant or when paying for a toll road or subway. In this case, the Bank may consider using contactless cards.
Thus, the problem of card selection should include:
a list of applications that are supported on the card;
ability to develop new applications and download them after the card is released;
the terms of the transaction (in particular, the characteristic size of the transaction amount, the conditions for the admission card time limit of the operation, the specific hardware used, reception cards, etc.);
security requirements of transaction processing;
availability of payment system certificates confirming the compatibility of card applications with payment system standards.
The list of the main parameters of the IPC that you should pay attention to when choosing a specific type of card in order to solve the task set by the Bank should look like this:
the cost of the card for the volume of purchases you are interested in;
list of apps supported by the card;
application functionality (including support for cardholder authentication and verification methods).
type of card operating environment: static or multi-layer;
the RAM size, bit depth, and processor clock speed (have the greatest impact on the speed of operations performed by the card and at the same time on the cost of the card);
speed of read / write operations, PIN verification, RSA and 3DES algorithms, random number generation;
availability of tools for developing new applications;
eepr0m size;
availability of coprocessors for performing cryptographic operations 3DES and RSA, speed of performing cryptographic operations at the required key sizes;
power supply voltage values supported by the card (5, 3, 1.8 volts);
supported communication interfaces and data transfer rates;
implemented means of physical security of the chip (countermeasures against SPA/DPA, DFA and Timing attack attacks, the presence of various sensors and filters to deal with power surges, jumps in the supplied clock frequency, etc., encryption of memory and data transmitted in data buses and addresses, etc.);
availability of the payment system certificate for compliance with the payment system specifications for the payment application;
certifications according to the criteria of the Common Criteria and (or) ITSEC.
If these data are available, the specialist is able to assess the possibility of implementing the Bank’s tasks on a specific card. Sometimes you can do this by testing the card for future use. In other cases, you will need to simulate the operation of the card when using Bank applications on it. Knowing the card parameters such as the speed of read/write operations, PIN verification, RSA and 3DES algorithms, the speed of data transfer between the card and the terminal, as well as having an understanding of the operating indicators of the terminal, you can get an estimate of the transaction execution time.
Note that the most critical parameters of transaction processing time from the point of view of the card are the speed of implementation of the RSA algorithm and the speed of data exchange between the card and the terminal. To illustrate this, consider a CDA card that uses a public key for signing with a 1024-bit module. In this case, we assume that the card Issuer has a public key for signing with the module 1536 bits, and its certificate is made on the system key of the size of 1984 bits.
In the case of a CDA card, when online authorization is performed and the transaction is approved by the Issuer, the card signs the data twice in order to authenticate itself and ensure the integrity of the information exchange between the card and the terminal. If the card supports the Encrypted PIN Offline cardholder verification method, it signs the data using the RSA algorithm for the third time. Assuming that the signature time is 150 MS, the card will take about 0.45 seconds to create Signed Dynamic Application Data and encrypt the PIN block.
Now let’s estimate the amount of data transmitted by the card to the terminal. The card must transmit to the terminal the Issuer’s key certificate (in order of size 2 KB), the card’s key certificate (in order of size 1.5 KB), and twice Signed Dynamic Application Data (in order of size 2×1 KB). In addition, the card transmits the value of the signed PIN block to the terminal (in order of size 1 KB). Thus, the lower estimate of the transmitted data is 6.5 Kbits. Assuming that the speed between the terminal and the card is 9600 bits / s and the communication Protocol T=0 is used, which requires 12 bits of information to transmit one sign, we will get that data transfer will take at least 1.02 seconds.
Impact of migration on the Issuer’s system
To serve the IPC, the Issuer’s host must support a number of additional functions in comparison with the host that processes transactions made only on magnetic stripe cards. These additional functions relate to both the authorization request processing system and the Issuer’s back office system, which includes a clearing file processing system and card personalization.
Additional functions in the authorization request processing system (front-end system) include:
withdrawal of the card’s master keys from the ICAC Issuer’s keys,
MK MK MK •
output session keys from the card keys for generating cryptograms, calculating MAC values, and encrypting confidential data;
checking the ARQC cryptogram;
checking the DAC and IDN values to confirm that the terminal has performed offline static or dynamic card authentication;
analyze data obtained from the Issuer Application Data (CVR, TVR, if this data is present in the IAD), and make decisions on how to complete the transaction based on this data;
analysis of the CVM Results data object (Tag ‘9F34’), if it is transmitted to the Issuer by the servicing Bank; this data object provides the Issuer with information about how verification of the cardholder ended and what method was used for this purpose;
we recommend analyzing the Issuer Script Results data object, if it is passed by the servicing Bank, in order to understand which Script Processing commands were executed successfully and what the current state of the card parameters is;
to prevent re-representation of transaction data, it is important to monitor the PBX values for each card in the Issuer’s system and link other parameters that depend on time (more precisely, on the transaction number) to the PBX, such as ICC Dynamic Number;
the Issuer is recommended to reject transactions in which (in MasterCard terminology) 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 (Fallback case);
to combat fraud using the magnetic stripe Fallback mode, the Issuer is recommended to control the number of operations performed in this mode for each card;
it is advisable to use different card acceptance profiles in different situations: for example, all international transactions can be made online by selecting the appropriate NDCF parameter, since it is for international transactions that the highest level of card fraud is observed;
preparing data for a response to the servicing Bank (field 055): Issuer Authentication Data, including ARQC, and script Processing Template themes.
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’s host. To transmit this object, the card must be programmed in such a way that the next transaction after executing the Script Processing procedure is performed in authorization mode on the Issuer’s host, and the card includes the Issuer Script Results element in the Issuer Application Data object.
The following additional functions should be considered in the clearing file processing system:
withdrawal of the card’s master keys from the Issuer’s ICAC, MKT, and ICMS keys;
output of the session key for generating a cryptogram from the ICAC card key;
verification of the vehicle and AAS cryptogram;
checking the DAC and IDN values to confirm that the terminal has performed static or offline dynamic card authentication;
control of PBX values and use the PBX value to search for a hold on the received segment.
Major changes will also affect the card personalization center. These changes will apply to the back-office data preparation system for hybrid card personalization, as well as to the application software of the card personalization machine controller and the secure interface between the data preparation center and the personalization machines.
The Bank should also pay attention to the ability of its existing HSM cryptographic modules to support the functions of processing online transactions, processing clearing files, and preparing hybrid card personalization data. HSM modules must support the RSA algorithm and a variety of diversification modes used to output card master keys and session keys.
Another aspect related to HSM that needs to be taken into account when migrating to the IPC is that the load on the HSM module that processes online authorizations changes dramatically. It should be noted that the performance of HSM can determine the capacity of the system for processing authorization requests. This is due to the fact that the lion’s share of work in additional checks falls on the HSM module.
To assess the impact of the increased load on the HSM module, we will build a simplified mathematical model.
First, we will define 5 groups of operations and their corresponding accesses to the HSM module of the issuing host. We will match each request with its complexity in the form of the number of operations
encryption using the 3DES algorithm that will be used in this request. Let’s assume that the resource-intensive AVDC algorithm that requires up to 16 3DES operations is not used to output session keys (the tree height can be equal to 8, and two 3DES encryption operations are used on each tier of the algorithm).
Group 1. Operation on-line card authentication. Complexity-b of 3DES operations.
Output of the card master key to generate the ICAC cryptogram from the corresponding key of the card Issuer. 2 operations.
Output of the session key for generating the 5kac cryptogram from the ICAC key. 2 operations.
Verification of the ARQC. 1 operation.
The formation of the ARPC. 1 operation (assuming the use of the ARPC cryptogram Format 1).
Group 2. Checking the IDN value. Complexity— 5 3DES operations.
Output of the master key of the MKT card to generate the IDN from the corresponding key of the card Issuer. 2 operations.
Checking the IDN value. 1 operation.
Group 3. Ensuring the integrity of information in the commands of the Script Processing procedure. The complexity is X+4 3DES operations, where X is the number of commands in the Script Processing procedure.
Output of the master key of the MCC card to generate the MAC value (Message Authentication Code) from the corresponding key of the card Issuer. 2 operations.
Output of the session key for generating the SKsm cryptogram from the MCG – 2 operation key.
Calculates MAC values for each command in the issue Script Processing procedure. 1 operation per command (it is assumed to use” short ” commands such as APPLICATION BLOCK, APPLICATION UNBLOCK, and CARD BLOCK).
Group 4. PIN code Verification. Complexity— 1 3DES operation.
It is assumed that the IBM 3624 or VISA PVV algorithm is used.
Group 5. Providing PIN block encryption in the PIN command
CHANGE/UNBLOCK. Complexity— 5 3DES operations.
Output of the master key of the MKSM card[ to encrypt data from the corresponding key of the card Issuer. 2 operations.
Output of the session key for generating the SKSMC cryptogram from the MCC key. 2 operations.
The encrypted PIN-block. 1 operation.
The complexity of various transactions from the point of view of the Issuer in terms of the groups used in the transaction and the number of 3DES operations. The far-right column indicates the complexity of the operation when using a magnetic stripe card.
Complexity of various operations
Type of operation Group # 3DES operations # 3DES operations for magnetic stripe
1 ATM without script 1+4 6+1=7 1
2 P0S without a script 1+2 6+3=9 0
3 ATM with a script 1+3+4 b+(X+4)+1=11+X –
4 P0S with a script 1+2+3 b+3+(X+4)=13+X –
5 ATM PIN Change 1+3+4+5 b+(1+4)+1+5=17 2
6 ATM PIN Change with a script 1+3+4+5 6+(X+4)+1+5=16+X, where X>1
Let’s make a few explanations about the types of transactions. Transaction 1 consists of operations at an ATM, such as issuing cash, obtaining a certificate of account balance, and forming a Ministry. In this case, unlike transaction 3, the Issuer does not use the Script Processing procedure.
Similarly, transactions 2 and 3 are a purchase operation in a POS terminal, respectively, without and using the script Processing procedure by the Issuer.
Transaction 5 is an operation to change the PIN code at an ATM. This operation for the microprocessor card is performed as part of the Script Processing procedure (PIN CHANGE/ UNBLOCK command).
Transaction b 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 assume that when processing one group of operations, the issuing host application occupies the HSM module for performing all operations within this group. This assumption, on the one hand, looks logical for use in the application software of the Bank’s processing center, and on the other hand, it will make it easier for us to analyze the performance model of the HSM module.
Enter the following notation:
A-the intensity of the incoming Poisson flow of the Issuer’s transactions;
a — traffic share of the Issuer attributable to transaction 1. Then, we assume that the remaining fraction 1-a accounts for the transaction 2. Thus we acknowledge the fact that these two types of transactions form the majority of operations of the Issuer and therefore, these two transactions determine the distribution function of the residence time of the group’s operations in the queue to HSM. Since only groups 1, 2, and 4 are used when executing transactions 1 and 2, we assume that these operation groups define the queue of operation groups to the HSM module;
y-the percentage of transactions 2 performed online.
A. J is the intensity of the input Poisson flow of groups 1 per HSM module. It is obvious that A ^ ccAj-e (1 -a^y, and the average processing time of this group of operations on the HSM is t^BT, where t is the average execution time of the 3DES cryptographic operation on the HSM module;
AG is the intensity of the input Poisson flow of groups #2 to the HSM module. Obviously, A2=(l-a)AjY, and the average processing time for this group of operations on the HSM is
K is the intensity of the input Poisson flow of groups #4 on the HSM module. Obviously, K3=AK}, and the average processing time for this group of operations on HSM is T3=t;
L, 4-the intensity of the input Poisson flow of requests for the formation of the Message Authentication Code value for messages circulating between the terminal and the host of the servicing Bank, to the HSM module. Let’s assume that the protocols for interaction between terminals (ATMs and POS-terminals) and the host use MACing to ensure the integrity of the transmitted data. Assuming a balance between the Bank’s issue and card acceptance, we assume that the number of transactions on the Bank’s cards in someone else’s network is approximately equal to the number of transactions processed by the Bank on someone else’s cards. Then it is obvious that K = 2 (aA.j+ (1 – a)A. rY), and the average processing time for this group of operations on the HSM is T4=t (the HSM module checks the Mac of the terminal’s authorization request and generates a MAC FOR the authorization response sent to the terminal). The share of transactions that go to another Issuer for authorization, as well as those that come from another network for authorization of the Bank considered in the model, was not taken into account. These transactions involve accessing the HSM module to retransmit PIN blocks.
We will model the queue to the HSM module with the m/G/l Queuing system, which receives a Poisson flow of intensity groups A = a:+ L2+
The average operation processing time in the M/G/l system is:
and the second moment of this time is determined by the equality:
1=1
A
P2 =
Then, according to the Pollachek-hinchin formula, the average time spent by an arbitrary group in the HSM queue is determined by the equality:
Substituting the values of X. and T. (/=1,…, 4)in the expression for p, we get: p = X;t[9a +11(1 – a) y] .
Substituting the values ^ and P2 in the expression for Tw, we get:
t ” _ Y2[39A + 47 (1-a)y]
- 2(1-p) 2 (1-p)
Then, if T is the average time spent on servicing an HSM transaction of the type / (/= 1,…, 6), we get the following formulas:
G = 2T + 7T
W
T, = 2T + 9T;
vj
T=ZT + 12T;
3 w
T=ZT + 14T; 7=4G + 17T;
w
T = 4T + 18T.
We assumed above that the number of commands in the Script Processing procedure is 1.
It is obvious that previously, when using cards with only a magnetic stripe, the host of our Bank used the HSM module as a servicing Bank as often as in the case of IPC, and when servicing the issue — only when servicing ATM traffic. In other words, in this case, only groups 3 and 4 create the load on the HSM module. Therefore, the value of system load and average maintenance time in this case are equal:
pt0) = SL;t + 2T[OIG + (1 – a)UHG ] = A.; t[3A + 2 (1 – a)y] ,
(0) _ 4;T2[3A + 2 (1-a)y]
“2(1-p)
7 – <0)=T+rj0>,
where Yy(0) is the average time for executing an ATM transaction.
We will consider the average Russian Bank that processes X. = 10 transactions per second in the hour of the highest load (this corresponds to a Bank with 500,000 cards — 1 million). Next, we assume that a = 0.8 and y = 0.8. Then we get:
p = 89, BT;
Tg =
387,2t2
(1-89, 6 t) - 7T ;
387,2t2
(1-89, 6 t)
580, 8t2
(1-89, 6 t)
580, 8t2
(1-89.6 t)
774,4T2
(1-89, 6 t)
774, 4T2 6 “ (1-89, 6 t)
p(0)= 27.2 t;
Tg =
TK =
t(0) _ W
13, 6t2 - 9T
- 12T ;
- 14T;
- 17T;
- 18T;
(1-27, 2 t)
193, BT2
(1-89, 6 t)
71(0> = t +
13, 6t2
(1-27, 2 t)’
Taking into account the requirements of payment systems, the transaction processing time on the Issuer’s host must be equal to 1 second in order.
774,4T2
(1-89, 6 t)
- 18T < 1
Taking the most time-consuming transaction, we get the inequality:
from where, after solving the quadratic inequality, we get that t<0.01 seconds, i.e. the performance of HSM must be higher than 100 cryptographic operations 3DES.
Note that when working with cards with a magnetic stripe, the issuing host only needs to ensure that the following conditions are met:
t(0)
‘1
<1,
13, 6t2
= TN
(1-27, 2 t) from which it follows that t< 0.036 seconds, i.e. the performance of HSM should be higher than 27.7 cryptographic operations of 3DES. Thus, when migrating to the IPC, in order to maintain the maximum input traffic, it is necessary to increase the performance of the HSM module by more than 3.6 times!