Features of migration to microprocessor cards

Migration of a Bank to issue and service MPC is an expensive and technically complex task that falls into several subtasks. These include:
setting the migration task for the IPC;
selecting the IPC hardware and software platform, card provider, and application configuration;
upgrading the application software of the Central transaction processing system (both online and clearing messages);
upgrading the card personalization system;
upgrade of terminal equipment;
the modernization of cryptographic hardware (Hardware Security Module or HSM).
Setting the migration task for the IPC
Setting the task of migrating a Bank to IPC technology can vary in a wide range from meeting the requirements of payment systems, which are implicitly expressed in the accepted Shifts of responsibility (Chip&PIN Liability Shift) and changes in commissions, to offering the client a multi-payment card that can support several functions at once, not all of which are payment.

From the very beginning banks identified three main reasons for migration to the MPC:
drastic increase in the security of operations performed using IPC compared to magnetic stripe cards;
changing the environment and characteristics of accepting plastic cards;
multiple apps can be used on the same card.
One of the most important tasks of migration is to improve the security of Bank card transactions. As indicated in paragraph 1.5.1, this task is very relevant for most regions of the world and requires immediate solutions. The largest card market in Europe— the UK market-is a good example of this. The losses of English banks from card fraud in 2004 amounted to approximately 505 million pounds. And this is despite the fact that in January 2005 59% of English Bank cards (about 76.8 million cards) were IPCS with PIN Offline support, and 74% of all POS terminals in the country (about 860 thousand terminals in total) support the EMV standard.
Experts from APACS, the British interbank Association, say that if the UK had not started migrating to chip, the losses of its banks in 2004 would have been approximately 800 million pounds, i.e. about 60% more than in reality.
According to various estimates, the migration of English banks and trading companies (about 42% of POS terminals belong to trading companies, not banks)to the IPC will cost about 2-2. 5 billion pounds. Hence, taking into account the current losses of banks, the business case for migration to the chip is obvious due to increased security of card operations.
One of the important consequences of improving the security of operations, as well as the fact that the IPC is a microcomputer that can independently make decisions delegated to the card by its Issuer, is the change in the conditions for accepting cards. Here, first of all, we should note the offline nature of IPC operations. Indeed, the possibility of reliable card authentication and verification of the PIN code of its holder in offline mode makes the transaction processing even within the “card—terminal” dialog quite secure.
Performing an operation in offline mode has many advantages. First of all, it should be noted that the transaction processing time is reduced. Here, however, a caveat is required, due to the fact that if some characteristics of the card and terminal are not up to scratch, the time for online authorization may be less than the same time for an offline transaction. The main reason for such delays is probably the slow implementation of the

RSA algorithm on the POS terminal.
However, in General, due to saving time on data transfer, processing operations in offline mode is faster. This is especially evident in the case of POS terminals operating over switched communication channels. Only dialing such a terminal to the host of the servicing Bank takes about 20-40 seconds.
As a result of reduced transaction processing time, the use of cards has expanded in an environment that was previously poorly adapted for their use — fast food restaurants, fare payment, access control, etc. In such cases, to further reduce the processing time of the operation, we recommend using an IPC with a radio interface.
The second advantage of offline transaction processing is a reduction in transaction processing costs for card transactions as a result of savings on communication costs.
It is also necessary to mention the longer service life of the IPC. The magnetic properties of the card’s magnetic stripe deteriorate significantly after 2-3 years of use. As a result, and for security reasons, the service life of a magnetic stripe card is usually 2 years.
The characteristics of the IPC chip are such that the card can serve perfectly for 10 years or more.
Let’s now consider the advantage of IPC associated with the ability to support several different applications on a single card. The most popular applications are pre – authorized debit/credit (prepaid card, possibly EMV standard), cardholder authentication in e-Commerce transactions CAP (Chip Authentication Program), as well as e-wallet applications, user identification, PKI infrastructure and loyalty. Let’s look at these applications in more detail.

Prepaid card
The essence of a prepaid card (Preauthorized Debit/Credit or PAD) is that the issuing Bank allows the IPC holder to perform operations offline within a certain limit, while reliably controlling the fact that the customer will not spend more than the funds available on his account. The idea of organizing control in General terms is as follows. The concept of a “shadow account” or Shadow Account (SA) is used. A shadow account is used to control operations performed offline using a chip. The initial value of SA is set to the value of the Upper Cumulative Domestic Offline Transaction Amount (UCOTA) set on the card.
All operations performed in real time using a magnetic stripe or chip are accounted for in the usual way by the so-called SA1 holds account. This account reflects authorizations (Huo messages), which are recorded in the Issuer’s system in the form of special records called Hondas. When the Huo message arrives, the size of SA1 increases by the amount of the transaction amount. Financial messages (presentations) received in the Issuer’s system for transactions related to the use of magnetic stripe, or for online chip transactions, debit the client’s account, find and remove (delete the record) the corresponding hold, if any. We will not dwell on the ways to find a hold on the present. Note only that reliable methods of searching for such compliance exist and are used in the processing systems of many issuing banks.
At each time, the Available Amount value is determined, which is equal to the difference between the current value of the AC client’s account and the amount of SA1 and SA, and determines the funds available for the client’s use. This value must be greater than or equal to 0 at any given time. This is taken into account both when selecting the UC0TA value and when authorizing online transactions.
Unlike presentments generated by online transactions or offline transactions performed using a magnetic stripe, presentments for offline transactions involving the use of a chip debit values

AC and SA simultaneously. When an online transaction processed using a chip occurs on the card, the value of the counter for the amount of offline transactions performed since the last online chip transaction, the Cumulative Offline Transaction Amount (COTA), is passed in the Issuer Application Data object to the card Issuer. The SA value is credited to the value of the HONEYCOMB.
If the Available Amount value becomes less than zero after crediting the SA, you must reduce the value of the UC0TA counter on the card so that the Available Amount value becomes positive. This can always be done, since the value of the CELL by which the Available Amount is reduced after crediting SA is less than the value of UC0TA. The UC0TA value is “accounted for” in SA from the very beginning (this way this value is reserved on the client’s account). Therefore, the SA at the time of processing an online transaction can be reduced by the size of UC0TA, while changing the value of the UC0TA card counter to 0.
In practice, there is no need to reduce the size of the SA by UC0TA. Depending on the Issuer’s policy, the SA size may be reduced by a smaller amount. The main thing is that after reducing the SA, The available Amount becomes positive. In this case, the decrease in SA must be accompanied by a change to the same value of the value of the UC0TA counter on the card. This change to the card parameter is performed by the Issuer using the UPDATE RECORD command in the Script Processing procedure.
Simultaneous application of the fragment to the SA and AC is in this case an analog of the previously described mechanism of “removing holds”, adopted for cards with a magnetic stripe. The specific feature of the IPC is that the Issuer receives from the card the cumulative value of funds spent offline using it. Therefore, it is not possible to find a match between the presentation and the hold.
The hold-down mechanism used for IPC requires constant correlation. Indeed, the size of the operation in the transaction and presentation may differ slightly due to the exchange rate difference that exists between the days of processing the authorization request and the presentation. Some authorizations may not be accompanied by comments at all.

The correlation procedure can be arranged as follows. The moments of performing online operations processed using the card chip are recorded. If XI and x2 are two such consecutive moments of time (X1<x2), then a correction is calculated for the value of the value SA at time x2+T. Here T indicates the maximum period of time during which the servicing Bank must submit a transaction report to the system from the moment of execution of this operation. The amount of T is determined by the rules of the Issuer’s payment system.
The correction to the SA value is calculated at time x2+T as the difference between the value of the HONEYCOMB sent to the Issuer at time x2 and the sum of all segments received in the time interval [XI, x2+T] with the following parameters:
the transaction is performed offline using a chip;
the transaction execution time is set in the interval between the transaction execution times [XI, x2].
For the first online transaction processed using a card chip, the value XI is assumed to be -°°, and the value x2 is assumed to be the moment when this transaction is completed.
Then the calculated correction is subtracted from the current SA value. As a result, the resulting SA values are adjusted for the amount of discrepancy between the amount of chip transactions in the presents and authorizations performed between two consecutive online transactions. Regular execution of the described procedure will allow you to correct the SA values with delay, but accurately, and thus-the value of the balance available to the cardholder.
Today, a similar prepaid card scheme is offered by VISA (VSDC+ product) and MasterCard (MasterCard Pre-authorized Debit/Credit product).
E-wallet
Similar in nature to the prepaid card app is the e-wallet app. The meaning of this application is that the card is loaded from the client’s account.
a certain amount of money is required. Loading money from the client’s account, in contrast to the prepaid card scheme, means that this money is debited from the account, and from this moment the Bank loses control over it. Physically, this means that the Bank must transfer funds withdrawn from the client’s account to the settlement Bank of the e-wallet system.
The loss of the Bank’s control over the money loaded into the e — wallet makes it possible to implement another very important property of the e-wallet-the anonymity of operations performed with its help. It is thanks to anonymity that an electronic wallet becomes an analog and substitute for cash.
Using the e-wallet app, purchases are made offline, which is extremely convenient, if only for reasons of saving time and reducing transaction costs.
Otherwise, payments are also made for operations performed using an electronic wallet. When making a purchase, money is debited from the customer’s card (the value of the counter of funds available on the card is reduced by the transaction size) and credited, for example, to the trading terminal card (there are options when the merchant’s system stores the transaction details along with the transaction certificate — the amount confirming the operation). The moment of making a purchase operation using the e-wallet application in this case is also the moment when payments between the cardholder and the merchant are completed. The latter, in order to receive a refund for a non-cash transaction made using a card with an e-wallet application, must only present proof of the transaction.
If a merchant uses a card with an e-wallet application for payments and money for purchases is transferred to this card, then the merchant only needs to use the “card Unloading” operation in the system terminal to transfer money for purchases to their account.
In the second half of the 1990s, there was an increased interest in the e-wallet application. Such schemes as Proton, Mondex, soras, CLIP, VISA are widely known

Cash and others. A large number of payment systems such as GeldCarte, Minipay, Quicklink, Chipper, ChipKnip, etc. have been created on their basis. Some of them were in the nature of national payment systems.
In 2000, due to the variety of e-wallet technologies and the idea of creating a single European system of non-cash payments, the international standard Common Electronic Purse Standard (CEPS) appeared. This standard was designed to ensure compatibility of e-wallets and terminal equipment from different manufacturers when creating a single international system based on e-wallet technology. In particular, the ceps standard describes the following list of operations:
loading your wallet;
unloading the wallet (to the cardholder’s account in the issuing Bank);
purchase operation;
the operation of the currency exchange;
operation for canceling the last purchase;
the operation of increasing purchases.
All purchase operations are performed offline. In this case, the card and the terminal perform a mutual authentication procedure using an asymmetric encryption algorithm (note that in the EMV standard, only the card is authenticated by the terminal). Each successful operation has a transaction certificate generated by the card. This certificate is a means of ensuring that the cardholder cannot refuse to perform the operation.
The CEPS standard allows flexible payment schemes for completed operations. For “Purchase” operations, the terminal generates a file of all successful transactions made on it, which is transmitted to the servicing Bank. The latter, in turn, sends the transaction file to the issuers of the participating cards. Further, payments for the purchase operation can be made in the same way as in the case of a normal card with a magnetic stripe. The only difference will be that the issuing Bank no longer debits funds from the client’s account. Money is transferred to the servicing Bank from the Funds Pool account of the card issuing Bank.

The incremental purchase operation is used, for example, when paying for phone calls. In this case, the card remains in the terminal until the end of the service provided to the client, and the terminal periodically sends requests to the card for debiting the available balance on it in accordance with the amount received by the client at the time of forming the service request and its cost.
The e-wallet loading operation is performed both from the client’s account in its issuing Bank (Linked Load) and from a special account (funding account) in an arbitrary participating Bank of the system (Funds Issuer). This type of loading is called Unlinked Load.
Funds are loaded to the card in a special loading device operated by the system’s Bank (Load Acquirer).
The ability to use a special account is important for the client, as it allows him to top up the available balance of his card when he wants it, and where it is convenient for him, by depositing funds to his account not in his native Bank, but in a nearby Bank. Banks that provide services for opening a funding account, as already noted, are called Funds Issuer. In practice, the equality Funds Issuer = Load Acquirer is often fulfilled, i.e. the client transfers cash to the loading Bank (here the Bank acts as the Funds Issuer), and it increases the amount of available funds on the card (here the Bank acts as the Load Acquirer). When loading an Unlinked Load card, the loading Bank contacts the card issuing Bank (Card Issuer) to perform mutual authentication of the card and its issuing Bank (the loading Bank acts as an intermediary and organizer of this procedure) and the Funds Issuer Bank to obtain authorization to load the card.
It is obvious that in the settlement process for Unlinked Load transaction loads the Bank will have to obtain funds from Bank account Funds Issuer and the card Issuer with the account Bank. Funds loaded to the card must be stored in the funds Pool account of the issuing Bank, since this account provides settlements for all cardholder transactions.
During the Linked Load loading process, money from the client’s account is transferred to the funds Pool account of the issuing Bank, and no interbank payments are made.

Thus, the main difference between the e-wallet scheme and the prepaid card scheme is that when the wallet is loaded from the client’s account, the issuing Bank loses control over the funds loaded to the card. For example, these funds can be debited from the Issuer’s correspondent account in the system’s settlement Bank and credited to the Funds Pool account. From the Funds Pool account, money is transferred to the correspondent accounts of servicing banks for “Purchase”operations performed in the system.
In the case of a prepaid card, control over the client’s funds is maintained until the Issuer receives a financial message from the servicing Bank.
It should be recognized that despite the considerable time that has passed since the introduction of the ceps standard, it has not been widely adopted. This is primarily due to the loss of interest of banks in this means of payment, and not to technological defects in the proposed standard. Today, the ideas of e-wallets are being spread in the e-money technology, which is used for payment for e-Commerce operations.

Client authentication
As already mentioned, reliable client authentication is an extremely popular task when performing MO/TO operations, including e-Commerce transactions, as well as when accessing Internet banking services, etc.a Microprocessor card is an ideal means of dynamic client authentication, since it is able to safely store the cardholder’s secret information used for authentication.
Leading payment systems have repeatedly addressed the idea of using a smart card for remote authentication of the cardholder. For example, the Common Chip Extension V. l of the e-Commerce Protocol SET (Secure Electronic Transaction) proposed the idea of using the ARQC cryptogram for online card authentication. In this case, the cardholder’s personal computer simulated the operation of the terminal and, in particular, could provide verification of the cardholder’s PIN code. Unfortunately, about-
yukol was not distributed and programs of international payment systems using this Protocol were stopped.
Today, payment systems have adopted a different technology to solve the problem of client authentication. This technology is called CAP (Chip Authentication Program) in the MasterCard system and TBA (Token Based Authentication) in the VISA system. It is expected that the technology will become widespread when solving the problem of cardholder authentication in e-Commerce operations performed using the 3D Secure Protocol. MasterCard and VISA systems have a cross – licensing agreement, according to which the Bank’s certification for 3D Secure and cap/TVA products, which is valid in one system, is valid in the other.
The meaning of the technology is as follows. It is assumed that the client has a card that supports a standard EMV attachment, as well as a special device with a card reader for IPC (we will call it a reader). After the customer has inserted the card into the reader, the latter offers the cardholder to choose one of two options: getting a signature or a one-time password. To implement the SAR program, the cardholder selects the option of generating a one-time password. After that, the reader prompts the cardholder to enter the PIN code value. If the entered PIN code value is correct, the reader gives the cardholder a number that is a one-time dynamic password for the client to perform this operation. This password can, for example, be used to authenticate the cardholder by the Issuer’s Access Control Server when it performs an e-Commerce operation using the 3D Secure Protocol.
The implementation of the SAR program is as follows. After the card is inserted into the reader, it emulates the operation of the POS terminal and initiates the transaction. Offline card authentication is not performed during the operation. The card must be able to support offline PIN verification. In this case, the card application must be personalized so that the reader chooses this method of cardholder verification from the CVM list (for example, the Offline PIN method should be the first CVR rule in the CVM List).

If the PIN verification was successful, the reader sends the GENERATE AC command to the card, requiring the card to generate an AAC (Application Authentication Cryptogram) cryptogram. The result of the command execution by the card is displayed as an eleven-digit decimal number. This number has the format XXXYYYYZZZZ, where XXX is a three-digit decimal number obtained from the transaction counter of the PBX card, YYYY is a four — digit decimal number obtained from the CVR* value generated from the variable part of the Card Verification Results data element, and ZZZZ is a four — digit number generated from the AAC cryptogram.
We describe the algorithms for generating values XXX, YYYY, and ZZZZ. The remainder of the decimal representation of the PBX is taken as the number XXX. To find the number YYYY, first construct a two-byte CVR * value. Assuming that the card uses CVR in the format of a CCD application (see clause 4.10.1), the CVR * value is generated, for example, using the following algorithm:
CVR* byte X bit 4, 3, 2, 1 = CVR byte 2, bit 8, 7, 6, 5 (Low Order Nibble of PIN Try Counter);
CVR* byte 1, bit 5 = CVR byte 4, bit 3 (Offline Data Authentication failed on Previous Transaction);
CVR* byte 1, bit 6 = CVR byte 4, bit 2 (Go Online on Next Transaction);
CVR* byte 1, bit 7 = CVR byte 4, bit 4 (Issuer Script Processing failed);
CVR* byte 1, bit 8 = CVR byte 2, bit 1 (Last Online Transaction not completed);
CVR* byte 2, bit 1 = CVR byte 1, bit 1 (Issuer Authentication failed);
CVR* byte 2, bit 2 = CVR byte 3, bit 8 (Lower Offline Transaction Count Limit exceeded);
CVR* byte 2, bit 3 = CVR byte 3, bit 7 (Upper Offline Transaction Count Limit exceeded);
CVR* byte 2, bit 4 = CVR byte 3, bit 6 (Lower Cumulative Offline Amount Limit exceeded);
CVR*
CVR* byte 2, bit 5 = CVR byte 3, bit 5 (Upper Cumulative Offline Amount Limit exceeded); byte 2, bit 6, 7, 8 = 0.

Then the resulting CVR* value is represented in decimal notation. Since the CVR * value is encoded with thirteen bits, its decimal representation does not exceed the number 213 – 1 = 8191. The decimal representation of CVR* is the number YYYY.
Another thing is also important. The CVR value* contains only variable CVR parameters for the operation performed with the reader! All other CVR parameters are easily restored by the Issuer based on an understanding of the operation processing procedure on the reader:
without offline card authentication;
with Offline PIN verification;
the PTL parameter cannot be exceeded, because otherwise the PIN code would not be checked and the number would not appear on the reader display;
Offline PIN verification was successful for the reason specified in the previous paragraph;
the operation is performed offline without attempting to be processed in real time;
the procedure for Issuer Script Processing was not performed.
In other words, having the CVR * value at its disposal,
the Issuer will easily build the CVR element.
Finally, to get THE zzzz number, the reader takes the last two bytes of the AAC cryptogram and represents them as a decimal number. The remainder of this number divided by 10,000 is considered as 7777.
Values of data elements passed by the reader to the card in the GENERATE command, according to the CD0L1 list.
All data, with the exception of the card transaction counter (PBX) and CVR, is fixed, and therefore known to the card Issuer.
Therefore, if you pass an eleven-digit number XXXYYYYZZZZ to the Issuer, the Issuer will use IT to check the cryptogram of the AAC card. In this way, it will prove the authenticity of the card used in the operation and verify its holder, since the number is displayed on the reader’s display if and only if the PIN verification is successfully completed.

Data used by the card when forming the AAS

Data element Value
Amount, Authorized 00 00 00 00 00 00
Amount, Other 00 00 00 00 00 00
Terminal Country Code 00 00
Terminal Verification Results 00 00 00 00 00
Transaction Currency Code 00 00
Transaction Date 00 00 00
Transaction Type 00
Unpredictable Number 00 00 00 00
Application Interchange Profile XX XX
Application Transaction Counter (PBX) XX XX
Card Verification Results (CVR) XX XX XX XX XX

Checking the correctness of the AAC cryptogram using the number XXXYYYYZZZZ is performed as follows. First of all, the Issuer restores the CVR value based on the yyyy number. We have previously explained how this can be done. Next, the Issuer can restore the number of PBX by the number XXX. The PBX number is encoded in two bytes and can reach a maximum value of 65535. The number XXX contains only the last three digits of the PBX number. To restore the two highest digits of this number, they must be stored in the Issuer’s system. However, this is not required in practice. The number of operations performed on the card during its service life, in the vast majority of cases, does not exceed thousands. Therefore, three digits XXX is enough to restore the PBX.
Note that to implement a cap, the EMV card application must support the Issuer Application Data element in response to the GENERATE AC command in order to be able to tell the reader the CVR value.
When the cardholder selects the signature generation option, they are asked to enter an eight-digit decimal number on the reader’s keyboard. After that, everything continues as in the case of selecting the option to get a one-time password, except that in CD0L1, the Unpredictable Number data element is determined to be equal to the number entered by the cardholder.
The signature function is extremely useful for organizing services that require not only authentication of the cardholder, but also ensuring that the customer cannot refuse the service provided to them. An example of such a service is Internet banking. Indeed, logging into the website of the Bank, the card holder when ordering any service receives a page request order confirmation and query to insert into a certain box number, the signature obtained using the presence on page eight-digit number (for some hash function from the parameters established by the Bank), customer card and reader. By filling in the page field with a signature number and confirming the request, the customer signs that they have ordered the selected service.

Note that for the implementation of the SAR program/TVA payment systems recommend using a separate EMV application on the card in order not to mix the risk management parameters of the cardholder authentication application and the payment application. We are mainly talking about the VCC (velocity checking count) counter, which increases by 1 when performing an operation in accordance with the cap/TVA program, thereby affecting the pattern of using the application to pay for various services. On the contrary, if the EMV application is only used for cardholder authentication, then when building a CVR*, you could limit yourself to defining the first four bits of the first byte (use only the RTS value).
Today, there is a large number of readers on the market that cost no more than 10 euros. Some of them are:
Digipass 800 (VASCO);
X-Sign (Xiring);
Ecode (T0D0S);
ActivSolo (ActivCard);
AOS Hagenuk;
SCM Microsystems.