Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
Migration of a bank to the technology of microprocessor cards is an expensive and technically challenging task that breaks down into several subtasks. These subtasks include:
Initially, banks identified three main reasons for migrating to the IPC:
Experts at APACS, the British Interbank Association, argue that if the UK had not started migrating to a chip, its banks would have lost approximately £ 800 million in 2004, or about 60% more than they actually turned out to be. The volume of losses from card fraud of British banks in 2005, according to APACS forecasts, would have exceeded? 1 billion, i.e., the banks' savings in 2005 alone amounted to about? 0.5 billion.
According to various estimates, the migration of British banks and merchants (approximately 42% of POS terminals in the UK belong to merchants, not banks) to RPCs cost about £ 2-2.5 billion. Hence, taking into account forecasts of bank losses due to card fraud the meaning of migration to a chip for English banks was obvious.
One of the important consequences of improving the security of operations, as well as the fact that the IPC is a microcomputer capable of independently making decisions delegated to a card by its issuer, is a change in the card service regime. Here, first of all, it should be noted the possibility of increasing the share of offline IPC operations while maintaining their level of security. Indeed, the emergence of the possibility of reliable authentication of the card and verification of its holder using the PIN-code in offline mode makes the processing of the transaction even within the framework of the “card-terminal” dialogue rather safe.
There are many advantages to performing an operation offline. First of all, it should be noted that the transaction processing time has decreased. Here, however, a caveat is required due to the fact that if some characteristics of the card and terminal are not up to par, then the online authorization execution time may turn out to be less than the same time for an offline transaction. The main reason for such delays is the sometimes slow implementation of the RSA algorithm at the POS terminal.
However, on average, taking into account the savings in data transfer time, the processing of the transaction in offline mode is faster. This is especially obvious in the case of using POS-terminals operating over dial-up communication channels. Only the call of such a terminal to the host of the servicing bank takes about 20-40 seconds.
As a result of the reduction in transaction processing time, the use of cards has expanded in an environment that was previously ill-suited for their use - fast food restaurants, fare, access control, etc. In such cases, in order to further reduce the processing time of the operation, it is recommended to use IPCs with a radio interface.
The second benefit of offline transaction processing is the reduction in operating costs for processing card transactions as a result of savings in communication costs.
It is also necessary to mention the longer service life of the IPC. The magnetic properties of the magnetic stripe of the card deteriorate significantly after 2-3 years of use. As a result, and for security reasons, the life of a magnetic stripe card is typically 2 years.
The characteristics of the IPC chip are such that the card can serve excellently for 10 years or more.
Let us now consider the advantage of the IPC associated with the ability to support several different applications on one card. Of greatest interest are applications for pre-authorized debit / credit (prepaid card, possibly EMV standard), cardholder authentication when requesting access to the Internet banking system and in e-commerce transactions in accordance with the MasterCard Chip Authentication Program and VISA Dynamic Passcode Authentication, as well as e-wallet applications, user identification, PKI infrastructure and loyalty. Let's dwell on these applications in more detail.
6.1.1. Prepaid card
The essence of a prepaid card (Preauthorized Debit / Credit or PAD) is that the issuing bank allows the holder of the IPC to carry out operations offline within the limit set by him, while reliably controlling the fact that the client will not spend more than the amount available on his account in bank funds.
The idea of organizing control in general terms is as follows. The concept of "shadow account" or Shadow Account (SA) is used. A shadow account is used to control transactions performed offline using a chip. The initial SA value is set to the Upper Cumulative Domestic Offline Transaction Amount (UCOTA) set on the card.
All transactions performed in real time using a magnetic stripe or a chip are accounted for in the usual way against the so-called SA1 holds. This account reflects authorizations (x100 messages), which are recorded in the issuer's system in the form of special records called holds. When a x100 message arrives, the size of SA1 is increased by the size of the transaction amount. Financial messages (presentations) that enter the issuer's system for transactions involving the use of a magnetic stripe, or for online chip transactions, debit the client's account, find and remove the corresponding hold (delete the record), if there is one in the issuer's system. We will not dwell on the methods of finding a hold by presentation. We only note that
At each moment of time, the value of Available Amount (АА) is determined, which is equal to the difference between the current value of the client's account АС and the sum of SA1 and SA and determines the funds available for use by the client:
AA = AC - (SA + SA1).
At each moment in time, this value must be greater than or equal to 0. This is taken into account both at the next choice of the UCOTA value and when authorizing online transactions.
Unlike presentations initiated by online transactions or offline transactions performed using
Chapter 6. FEATURES OF MIGRATION ON MICROPROCESSOR CARDS 399 magnetic stripe, presentations on offline transactions associated with the use of the chip, debits AC and SA values at the same time.
When an online transaction processed using a chip occurs on a card, the Cumulative Offline Transaction Amount (COTA) counter of the amount of offline transactions performed since the last online chip transaction is transmitted in the Issuer Application Data object to the card issuer. The SA value is credited to the SOTA value.
If, after crediting SA, the Available Amount value becomes less than zero, it is necessary to decrease the value of the UCOTA counter on the card so that the Available Amount value becomes positive. This can always be done, since the COTA value, by which the Available Amount is reduced after the SA is credited, is less than the UCOTA value. At the same time, the value of UCOTA was taken into account in SA from the very beginning (in this way, this value is reserved on the client's account). Therefore, SA at the time of processing an online transaction can be reduced by the size of UCOTA by simultaneously changing the value of the UCOTA card counter to 0.
In practice, it is not necessary to decrease the SA size by the UCOTA value. Depending on the policy of the issuer, the size of SA may be changed to a lesser amount. The main thing is that after a decrease in SA, the Available Amount value becomes positive. In this case, a decrease in SA should be accompanied by a change by the same value of the value of the UCOTA counter on the card. This change of the card parameter is carried out by the issuer using the PUT DATA command of the Issuer Script Processing procedure.
Simultaneous application of a presentation to SA and AC is in this case analogous to the previously described mechanism for removing holds, adopted for cards with a magnetic stripe. The specificity of the IPC is that the issuer receives from the card the cumulative value of the funds spent with it in offline mode. Therefore, it is not possible to search for a match between a presentation and a hold.
The mechanism for removing the holds used for the IPC requires constant correction of the values of the shadow account. Indeed, the transaction sizes in the transaction and the 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 presentations at all.
The SA value correction procedure can be arranged as follows. The moments of online transactions processed using the card chip are recorded. If XI and X2 are two such consecutive points in time (XI <X2), then a correction is calculated for the value of SA at time X2 + T. Here T denotes the size of the maximum period of time during which the serving bank must present to the system a presentation on the operation performed on its device. The value of T is determined by the rules of the bank's payment system.
The correction to the SA value is calculated at time X2 + T as the difference between the COTA value sent to the issuer at time X2 and the sum of all presentations received in the time interval [XI, X2 + T] with the following parameters:
Then the calculated correction is subtracted from the current SA value. As a result of performing the described procedure, the SA values are corrected for the amount of discrepancy in the sum of the size of chip transactions in presentations and authorizations performed between two consecutive online transactions. Regular execution of the described procedure will allow, with a delay, but accurately to correct the SA values and, thus, the value of the balance available to the cardholder.
A similar prepaid card scheme is offered by VISA (VSDC + product) and MasterCard (MasterCard Pre-authorized Debit / Credit product).
6.1.2. Online wallet
Similar in nature to the prepaid card application is the e-wallet application. The meaning of this application is that a certain amount of money is electronically loaded onto the card from the client's account. Loading money from a client's account, unlike a prepaid card scheme, means that this money is debited from the account, and from that moment the bank loses control over it. In fact, this means that the bank must transfer the funds withdrawn from the client's account to the settlement bank of the electronic wallet payment system.
The loss of the bank's control over the money loaded into an electronic wallet makes it possible to realize another important property of an electronic wallet - the anonymity of transactions performed with its help. It is thanks to the anonymity that the electronic wallet becomes an analogue and substitute for cash.
With the help of an e-wallet application, purchases are made offline, which is extremely convenient, if only for reasons of saving time and costs for the operation.
Otherwise, settlements are carried out for operations performed using an electronic wallet. When making a purchase, money is debited from the client's card (the value of the counter of funds available on the card is reduced by the size of the transaction) and credited, for example, to the card of the trading terminal (options are possible when the transaction details are stored in the merchant's system together with the transaction cryptogram - a value that confirms the fact of execution operations). The moment of completion of the purchase operation using an electronic wallet application in this case is also the moment of completion of settlements between the cardholder and the merchant. The latter, in order to receive a refund for a non-cash transaction carried out on a card with an electronic wallet attachment, must only present proof of the fact of the service provided by it.
For example, if a merchant for settlements uses a card with an electronic wallet application and money for purchases made in it is transferred to this card during successful transactions, then the merchant only needs to use the "Unload card" operation in the system terminal to transfer money for purchases to your account.
In the second half of the 1990s. there has been an increased interest in the e-wallet application worldwide. Such schemes as Proton, Mondex, SORAS, CLIP, VISA Cash and others are widely known. On their basis, a large number of payment systems were created, such as GeldCarte, Minipay, Quicklink, Chipper, ChipKnip, Moneo, etc. Some of them were in the nature of national payment systems.
In 2000, in connection with the variety of electronic wallet technologies used in the market and the idea of creating a unified European system of cashless payments, the international Common Electronic Purse Standard (CEPS) appeared. This standard was intended to ensure the compatibility of electronic wallets and terminal equipment from different manufacturers while creating a unified international payment system based on electronic wallet technology. In particular, the CEPS standard describes the following list of operations:
The CEPS standard allows flexible settlement schemes for completed transactions. 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 file of transactions to the issuers of the cards involved in them. Further, settlements for the purchase operation can be made in the same way as in the case of a card with a magnetic stripe. The only difference will be that the issuer no longer debits funds from the client's account. The money is transferred to the correspondent account of the servicing bank in the settlement bank of the system from the Funds Pool account of the bank that issued the card. It is important to note the following about the Funds Pool account. To ensure control of transactions on e-wallet cards issued by the bank, the Funds Pool account is only registered with the issuer, but does not belong to it.
The incremental purchase operation is used, for example, when paying for telephone calls. In this case, the card remains in the terminal until the end of customer service, and the terminal periodically sends requests to the card to deduct the cost of the service provided since the last request of the terminal from its account. If the size of the available card balance after the next request from the terminal becomes negative, the client's service will be terminated.
The operation of downloading an electronic wallet is carried out both from the client's account in his issuing bank (Linked Load), and from a special account (Funding Account) in an arbitrary bank that is a member of the system (Funds Issuer). This load is called Unlinked Load.
The funds are loaded onto the card in a special loading device (Load Device) served by the system bank (Load Acquirer).
The use of a special account is convenient for the client, since it allows him to replenish his card account when he wants it, and where it is convenient for him, by depositing funds into his account not in his native, but in a bank nearby to him. Banks that provide services for opening Funding Accounts, as already noted, are called Funds Issuer. Often in practice the equality Funds Issuer = Load Acquirer is fulfilled, i.e. the client transfers cash to the loading bank (at this moment the bank acts as a Funds Issuer), and the latter increases the amount of available funds on the card (at this moment, the bank acts as a Load Acquirer).
When loading an Unlinked Load card, the loading bank contacts the 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 for loading cards.
Obviously, in the process of settling the Unlinked Load transaction, the loading bank will receive funds from the Funds Issuer bank account and transfer them to the card issuer's Funds Pool account. As a result, the funds loaded on the card will be reflected in the Funds Pool account of the issuing bank, since it is this account that provides settlements for all operations of the cardholder.
In the process of downloading Linked Load, the money from the client's account immediately goes to the account of the issuing bank's Funds Pool, and no interbank settlements are made.
Thus, the main difference between the e-wallet and prepaid card schemes is that after the funds are loaded into the client's e-wallet, the issuing bank loses control over the funds loaded onto the card. Usually, the funds loaded into the client's electronic wallet are debited from his bank account with the issuing bank and then transferred from the issuer's correspondent account with the system's settlement bank to the issuer's Funds Pool account with the system's settlement bank. From the issuer's Funds Pool account, money is subsequently transferred to the correspondent accounts of the servicing banks in connection with the “Purchase” operations performed in their terminal devices using bank cards.
In the case of a prepaid card, control over the client's funds remains until the issuer receives a financial message from the servicing bank.
It should be admitted that, despite the considerable time that has passed since the advent of the CEPS standard, it has not become widespread. This is primarily due to the banks' loss of interest in this means of settlement, and not to technological defects of the proposed standard. Today, some of the e-wallet ideas are used in e-money technologies that are used to pay for e-commerce transactions.
6.1.3. Cardholder authentication
As already noted, reliable cardholder authentication is an extremely demanded task when performing CNP operations, including e / mobile commerce transactions, as well as for solving the problem of controlling access to various information systems: Internet banking systems, bank contact center, etc. ... The microprocessor card is ideal for dynamic client authentication, as it is able to securely store the secret information of the cardholder used to authenticate him, as well as calculate cryptographic values depending on the parameters of the operation he performs.
Leading payment systems have repeatedly turned to the idea of using a smart card to remotely authenticate the holder of a microprocessor card. For example, the Secure Electronic Transaction (SET) e-commerce protocol Common Chip Extension proposed the idea of using the ARQC cryptogram for online card authentication. At the same time, the personal computer of the cardholder simulated the operation of the terminal and, in particular, could support the offline procedure for checking the cardholder's PIN code. Unfortunately, the SET protocol did not become widespread and the programs of international payment systems using it were stopped.
Today, payment systems use a different technology to solve the problem of cardholder authentication. This technology is called CAP (Chip Authentication Program) in the MasterCard system and DPA (Dynamic Passcode Authentication) in the VISA system. The technology is based on the CAP (Chip Authentication Program) protocol, developed by MasterCard specialists and adopted by the VISA payment system in the DPA program.
Chapter 6. FEATURES OF MIGRATION ON MICROPROCESSOR CARDS 405
It is expected that the technology will become widespread in solving the problem of cardholder authentication in e-commerce transactions performed using the 3D Secure protocol. MasterCard and VISA systems have a cross-license agreement, according to which the certification results of the 3D Secure and CAP / DPA solutions used by the bank, valid in one system, are valid in another.
The relevance of the CAP protocol for solving e-commerce problems is due to the fact that the most serious security problem of the 3D Secure protocol is its defenselessness against man-in-the-middle attacks when a cardholder uses a static password for his verification. For example, when a cardholder uses the 3D Secure protocol, fraudulent online stores can use the following procedure to compromise the cardholder's password (Fig. 6.1). The Merchant Plug-In (MPI) system of a fraudulent store, having received a response VER.es containing the dynamic address (URL) of the Access Control Server (ACS), sends a request for authentication of the PAReq cardholder not to the specified address, but to its address. SSL server. The fake SSL server then redirects this request to the card issuer's ACS URL, obtained from the VERes message, thereby pretending to be the cardholder's computer for ACS. As a result, ACS takes the false server for the personal computer of the cardholder and transmits to the false server its page intended for cardholder authentication. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value. designed to authenticate the cardholder. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value. designed to authenticate the cardholder. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value.
In order to reduce the consequences (unfortunately, it will not be possible to fully protect yourself) from such password thefts for the purpose of their further use in fraudulent operations, various schemes for generating and using dynamic passwords have been proposed, or,
Rice. 6.1. A possible way to compromise a password in the 3D Secure scheme is called One Time Password, or OTP for short. The CAP standard defines the most common OTP generation algorithm in the banking sector.
The essence of the ATS technology is as follows. It is assumed that the client has:
After choosing an option and, possibly, entering some parameters of the operation by the client on the keyboard, the reader prompts the cardholder to enter the value of his PIN-code. If the client has selected the option to generate a one-time password and the PIN-code value entered by him turned out to be correct, the reader displays on his screen a number that is a one-time dynamic password of the cardholder used to authenticate the cardholder when performing this operation. This password can, for example, be used to authenticate the cardholder with the issuing Access Control Server when the cardholder performs an e-commerce transaction using the 3D Secure protocol.
If the cardholder has chosen the option of receiving the data signature, the card uses the reader to form the signature of the data entered by the client on the screen. The received signature is used both to authenticate the cardholder (only he could form such a signature) and to ensure the integrity of the signed data. Such a signature can act as a cryptogram of the operation being performed, thereby making it impossible for the client to refuse the performed operation (non-repudiation).
If the option of preparing a response to the cardholder verification request was selected, the card uses the reader to sign a random number contained in the cardholder verification request. This ensures the authentication of the cardholder with reference to a specific operation (a random number is generated by the issuer for a specific operation).
Readers used in CAP / DPA programs can be stand-alone (no network interfaces) or plugged into the cardholder's computer. In the latter case, it is easier for the cardholder to enter the transaction parameters. They do not need to be entered through the reader's keyboard, since a computer program can do this for the card holder. In addition, in this case, if there is a special client application on the cardholder's computer, it is possible to perform online transactions on the card.
However, in most cases, banks use standalone readers. They do this for security reasons (to limit access to the card reader over the network) and because the amount of data entered by the cardholder on the reader's keyboard is small.
The general scheme for the implementation of the CAP protocol is as follows. The reader emulates the operation of the POS terminal and, after the card is inserted into the reader, initiates the operation. At the beginning of the operation, the reader can ask the cardholder for information about the size and currency of the transaction, as well as the random Challenge number, which can be the transaction details reported to the cardholder by the authenticating party. At the same time, the reader does not perform offline card authentication and risk management procedures, and in the first GENERATE command, the AC requires the card to generate an ARQC cryptogram.
The card application must support offline PIN verification - Plaintext PIN Offline and / or Encrypted PIN Offline methods. In addition, it must be personalized so that the reader selects one of the PIN Offline cardholder verification methods from the CVM list (for example, the PIN Offline method must be the first CVR rule in the CVM List; it is sufficient that this method is supported by the card and the bit 7 bytes CVM Code for all verification methods supported by the card was equal to 1). The reader itself only supports the Plaintext PIN Offline and Encrypted PIN Offline methods of cardholder verification.
If the PIN code check is successful, the reader sends the GENERATE AC command to the card, requiring the generation of the ARQC cryptogram. After completing the risk management procedures and deciding how to complete the transaction, the card can respond to the reader by generating an ARQC or AAC cryptogram. If AAS is generated, the operation ends. If an ARQC cryptogram is generated, the reader will send a second GENERATE AC command to the card, requesting the AAC cryptogram and indicating to the card the Authorization Response Code Z3 (it is impossible to send the request online, rejected offline).
In this case, the reader will ignore the response received from the card to the second GENERATE AC command (i.e., the ARQC cryptogram received in response to the first AC GENERATE command will be used to calculate the CAP Token). Based on the Z3 code, the application will set the Unable to go online flag in the CVR object. In addition, in the case of a VSDC application, without receiving a response from the issuer, the application will set the Last Online Transaction not Completed flag in the CVR object.
Having received a response from the card to the first GENERATE AC command, the reader, using the data received in the response, calculates a certain value called CAP Token, the size of which varies from 6 to 16 decimal digits. Since the CAP Token contains individual cryptogram bits, it is used to authenticate the card application. If the value of the CAP Token has successfully passed the verification procedure, then the cryptogram of the transaction, which was used to calculate the CAP Token, will also pass it with a high probability. The CAP Token value is displayed on the reader's display and is subsequently used by the cardholder to authenticate it, for example, when logging into the Internet banking system or performing an e-commerce transaction.
Thus, the CAP method implements two-factor authentication of a bank client: the latter must have a bank card (to generate a cryptogram) and know his PIN-code.
There are two important points to make here. The first concerns the application that implements cardholder authentication. This application may be a special stand-alone application used by the card issuer solely to authenticate the cardholder in accordance with the CAP protocol (this application is not used for financial transactions). Or it can be a general-purpose application used, among other things, to perform operations in POS terminals and ATMs. Payment systems recommend banks to use a special separate application to authenticate the cardholder. In the leading payment systems, a special extension of the application identifier P1X = 8002 is allocated for this separate application.
The recommendation of payment systems to use a separate application for cardholder authentication is related to several reasons. First, the use of a payment application to authenticate the cardholder may result in the transaction being rejected offline (the payment application will return the AAC cryptogram to the reader). As a result, offline new card counters may change (as, for example, in the VSDC application), which will leave an imprint on the further use of the payment application.
Secondly, the peculiarities of the implementation of the cardholder's authentication by the terminal are reflected in the behavior of the payment application. For example, as we remember, in the second GENERATE AC command, if it comes down to it, the terminal asks the card to return the AAC cryptogram, transmitting the authorization response code Z3 to the card. As a result, the Last online transaction not completed bit of the CVR object of the VSDC application will be set to 1. This fact may require the mandatory execution of the next operation using the online payment application (this bit is reset in CVR only as a result of successful authentication of the card issuer).
Third, as will be seen below, the size of the CAP Token value generated by a separate application is less than the same size for the case of using a conventional payment application. The size of the CAP Token is a critical parameter for the usability of the CAP technology.
Fourth, verifying the CAP Token value in the issuer's system (the subsystem that verifies CAP Token values is called the CAP Token Verification System, or CTVS for short) turns out to be easier if a separate application is used. When using a regular application for cardholder authentication, it is necessary to ensure synchronization of the data of the issuer's system and the CTVS (keys, card counters, etc.).
Finally, fifthly, the use of different applications improves the security of the payment service and the cardholder authentication service.
The second note concerns the behavior of the ad-hoc application. It is recommended to personalize the special application so that in response to the first GENERATE AC command, the reader always receives an ARQC cryptogram from the card. This behavior of the application allows you to minimize the amount of data that needs to be transferred to the issuer to check the CAP Token value, making the values of all bits of the CVR object predictable, and also does not change the values of offline application counters, which allows you not to worry about the values of the limits for these counters. This will be discussed in more detail below.
From the above comments, the answer to the question of why the reader does not require the return of the AAC cryptogram in the first GENERATE AC command follows. Such an approach would greatly simplify the work with the card and would reduce the spread of the values of the card response. The answer is simple. The reader requests the ARQC cryptogram from the card to try to minimize the impact of the CAP authentication procedure on the card's payment application. The request in the first GENERATE AC command for the AAC cryptogram can change the offline counters of the payment application. For example, this happens in the VSDC application in the case when a transaction is rejected offline and the corresponding conditions for changing the values of offline counters of this application are met (see clause 11.5.1 of the VIS 1.4.0 specification).
Depending on the composition of the transaction data used to calculate the cryptogram and CAP Token, the CAP scheme implies the implementation of one of four modes. Transaction data is requested from the cardholder by the reader and entered by the cardholder using the reader's keyboard. The definition of CAP protocol modes is given below.
Mode 1: to calculate the AC cryptogram, Challenge is used (required), the size and currency of the transaction (optional), only the size of the transaction (optional).
Mode 2: no transaction data is used to compute the AC cryptogram.
Mode 2 with TDS: no transaction data is used to compute the AC cryptogram. Transaction data (up to 10 fields, each with a maximum of 10 characters) is used to calculate the CAP Token. In the process of calculating the CAP Token, the MAC of the transaction data is determined. For this, the ISO 9797-1 Algorithm 1 algorithm is used, in which the previously obtained applied cryptogram is used as the key, and DES is used as the ALG algorithm.
Mode 3: Mode 3 is a special case of Mode 1, only the obligatory Challenge element is used to calculate the AC cryptogram.
The reader is required to support Mode 1 and Mode 2. Modes Mode 2 with TDS and Mode 3 are optional.
The choice of the CAP mode is made by the client at the beginning of the authentication procedure. For this, the corresponding buttons of the reader are used. Often these buttons have names familiar to the bank's client: Sign (signature of the transaction details), Identify (generation of a one-time cardholder password) and Verify (generation of a response to a cardholder verification request). In this case, each button is implemented by one of the modes of the CAP protocol. Examples of the use of CAP mods for the implementation of various functions are given in table. 6.1.
The signature function is useful for organizing services that require not only cardholder authentication, but also the security of the cardholder. 6.1. Examples of using the CAP mod
making it impossible for the client to refuse the service provided to him. An example of such a service is Internet banking. Indeed, when ordering any service on the bank's website, the card holder receives a page with a request to confirm the order and a request to insert a signature number into a certain field of the page. The signature number is generated for the decimal number present on the bank's website page, usually representing the value of some hash function from the parameters of the service provided to the client, generated by the Internet banking system. The cardholder inserts the card into the reader, by pressing the button selects the Sign option, enters the PIN-code value and the number from the bank's website page. As a result, a decimal number appears on the reader's display, which is inserted by the client into the signature field on the bank's website page.
The operation dataset used when Mode 1 is selected is defined by a special Issuer Application Flags data object (IAF, Tag '9F55'), whose data field is one byte in size and is shown in the table below. 6.2.
Table 6.2 shows how the transaction data used in Mode 1 is determined. The IAF data object also determines the need to use PSN bits when generating the CAP Token value, which will be discussed in more detail below. If the IAF data object is not present in the selected reader application, then the reader considers its default value to be '00'h.
The general scheme of transaction processing is shown in Fig. 6.2.
In response to the first GENERATE command, the AC card returns data objects CID, ATC, AC and IAD to the reader. It would be possible to provide the received data, supplemented with information on the card (PAN, PSN) and operations (size and currency of the transaction, Challenge), for verification to the issuer's system. The essence of checking the issuer would be to determine the corresponding table. 6.2. Issuer Application Flags Object Data Field Structure
Consequences of the data received by the issuer to the value of the AS applied cryptogram.
However, this method of verification is unrealizable in practice. When used, the CAP Token value can be a 104 decimal digit number. Indeed, the data fields of the CID, ATC, AC, IAD objects are 1, 2, 8 and 32 bytes, respectively (the size of the IAD data field is 32 bytes for the CPA application). This means that the CAP Token resulting from the concatenation of the listed data will have a size of 2 8 (1 + 2 + 32) = 2 344 ~ 3.58 • 1O 103... Obviously, displaying such a number on the reader's display, and even more so informing it to the issuer's system without errors, will be problematic. When using such a number, the probability of a client's error when entering it is too high, and typing it on a computer (if ATS is used in e-commerce or Internet banking) is long and laborious.
Therefore, the main task of the CAP protocol is to maximally compress the data received in response to the first command of the GENERATE AC reader in order to generate the CAP Token value from them, the value of which, despite compression, on the one hand, is difficult to guess, and with another - it is still possible to check in the CTVS system (there is enough data for verification).
To determine the data compression algorithm, consider the parameters that must be included in the CAP Token. We repeat once again that the main
Rice. 6.2. General scheme of the authentication procedure
the idea of CAP Token verification is that the CTVS issuer system can, by the CAP Token value, verify the operation cryptogram (or its individual bits), obtained as a result of the reader's dialogue with the card. This means that a prerequisite for the implementation of CAP is the ability of the CTVS to calculate on its side the cryptogram returned by the card to the reader.
To calculate the cryptogram, the CTVS system needs to know the values of the following quantities:
Tab. 6.3. Data used by the card when forming a cryptogram
As you can see from the table. 6.3, all data, except for the transaction counter of the ATC card application and CVR, are fixed, and therefore known to the card issuer.
Thus, the task of compressing the data included in the CAP Token is reduced to compressing the following data:
The cryptogram contains 64 bits of information and is a cryptographic function of the variables indicated in table. 6.3. A fraudster, not knowing the key of the card to generate the cryptogram, can only guess the meaning of the cryptogram. If we leave only n bits (out of 64 possible) in the CAP Token , then the probability of guessing them is 2 ~ n . Obviously, there is no point in making the probability of guessing the bits of the cryptogram left in the CAP Token higher than the probability of guessing the client's PIN-code (the second factor of cardholder authentication). The probability of guessing both factors will turn out to be negligible even in the case when the probability of guessing each factor will be at the level of the probability of a PIN-code being compromised.
If a 4-digit PIN-code is used and the fraudster has three attempts to guess its value, then the probability of guessing the PIN-code value is approximately equal to 3 × 10. since it is a dynamic value and will take on a different value on the next guessing attempt). Since the CAP Token is checked in the HSMs, it is desirable that the size of the portion of the cryptogram left in the CAP Token be a multiple of 8 bits (byte size). Therefore, payment systems recommend leaving at least 16 bits of the cryptogram in the CAP Token.
The PSN parameter can be used by the issuer in order to issue several cards under the same number. Often times, issuers don't use PSN. In this case, PSN will not be included in the CAP Token either. As noted above, the fact that PSN is used to generate the CAP Token is reflected by bit 7 of the IAF object.
If, nevertheless, PSN is used by the issuer, then it consists of two decimal digits (encoded with one byte). The most significant digit of the PSN is commonly used to identify different cardholders using a common card number (for example, members of the same family). The least significant digit of PSN defines the re-issue cycle of the card with this number. If, for example, the number of card re-issues is not more than 3 and the number of cardholders per card is not more than 3, then it is enough to leave the last two digits of each byte halo representing PSN from PSN in CAP Token. In this case, it will be enough to include 4 PSN bits in the CAP Token instead of the initial 8 bits.
The value of the ATC transaction counter is encoded in two bytes. Obviously, the maximum number of transactions provided in this case, equal to 65,535 operations, in practice, with a high probability, will not be achieved over the entire life cycle of the card. Indeed, if we consider a very active cardholder performing 14 transactions every day during the entire three-year card validity period, he will be able to make only 15,330 transactions. To encode the PBX in this case, it is enough to select 14 bits of the PBX.
In addition, it is possible to break PBX number into two parts: the lower m bits included in the CAP Token, and the remaining upper bits stored in CTVS not included in the CAP Token. Then, if m is large enough, when performing the next authentication of the cardholder, the CTVS system will be able to unambiguously determine the value of the ATC from the value of m . Indeed, if the received CTVS t digits of the current ATC value are greater than the last t digits of the last ATC value stored in CTVS, then to form the ATC, the upper ATC bits stored in the CTVS are added to the digits received from the CAP Token on the left. Otherwise (received by CTVS t digits of the current ATC value are not more than the last tdigits of the last PBX value stored in CTVS) CTVS increments the number representing the most significant bits of the PBX number, stores it in binary instead of the old value, and adds the new value of the most significant bits to the m bits received from the CAP Token on the left .
If m is large enough, for example, m = 7, then such a mechanism will make it possible to reliably restore the ATC value, provided that no more than 255 payment transactions are made between two consecutive cardholder authentications. In practice, this value of m is quite sufficient to restore the value of the ATC in the CTVS system.
The issuer can use different keys to generate the keys for their cards. Usually, each issuer's BIN corresponds to a certain set of its keys. This is done for ease of key management. For example, such a correspondence between BIN and issuer key sets exists in backup authorization systems of leading payment systems. In backup authorization systems, there is a limitation on the number of issuer's keys assigned to one value of its BIN. For example, in the VISA system, this number is limited to 24 keys. This means that 5 bits of information are sufficient to encode the DKI. In practice, it is often enough for the issuer to have no more than 7 keys per BIN, for which it is enough to include the three least significant bits of the DKI representation in the CAP Token.
Finally, let's look at ways to compress information for a CVR object. Obviously, the number of CVR bits that it is enough to leave in the CAP Token so that the entire CVR data object in the CTVS system can be restored from them, essentially depends on whether the application used is a special application for cardholder authentication, or it represents is the usual payment application of the issuer. Let us illustrate the above with the example of the CVR application of the VSDC payment system VISA. Table 6.4 shows the CVR bit values for the dedicated application case. Recall that this CVR value is generated by the card as a result of the risk management procedure after the first GENERATE AC command is received. It also assumes that the ad-hoc application is configured in such a way that
Tab. 6.4. CVR bit values for dedicated VSDC application
The end of the table. 6.4
It can be seen from the table that all bits of the CVR object in the case of using a dedicated application for cardholder authentication are predictable, and therefore there is no need to include them in the CAP Token.
The situation changes when using a regular payment application. Below in table. 6.5 shows the meaning of the CVR bits in this case.
The bit values indicated by x are not predictable and depend on the configuration of the VSDC application and the history of the card application. As a result, the CAP Token will need to include 10 CVR bits, the values of which are not predictable and cannot be recovered in CTVS.
Above, we discussed the data bits that must be included in the CAP Token so that it is possible to calculate the cryptogram in CTVS. Now let's dwell on the method for calculating the CAP Token. Obviously, all the bits included in the CAP Token can be obtained from the card's response to the first command GENERATE AC (CID, ATC, AC, LAD) and PSN. Indeed, DKI and CVR are included in the AID object. The ATC and cryptogram values are directly contained in the response to the AC GENERATE command.
Tab. 6.5. CVR bit values when using the VSDC payment application
Therefore, to receive a CAP Token, the reader generates a data string shown in Fig. 6.3. The string is formed from the response of the card to the GENERATE AC command, to which the PSN data element is appended to the left, if required.
Rice. 6.3. Data used to generate CAP Token
Whether a PSN is attached is determined by bit 7 of the IAF. Now, in order to obtain the CAP Token value, the Issuer Proprietary Bitmap data object (IPB, Tag '9F56') is used - It is superimposed on the reader data line and the values of the bits opposite to the IPB '1' bits are extracted from it. The resulting binary sequence is represented as a decimal number, which is the CAP Token.
The structure of the IPB object, obviously, determines the data compression mechanism we discussed above. Bits '1' correspond to those bits of the string from fig. 6.3 to be included in the CAP Token object.
If there is no IPB data object in the application, the reader uses its default value stored in the reader and determined by the payment system.
It should be recalled that the above algorithm for calculating CAP Token is valid for all CAP modes except Mode 2 with TDS. When using this mode in the line from Fig. 6.2 instead of the AS cryptogram, the MAC value is used, formed according to the algorithm described earlier.
Table 6.6 shows the values of the CAP Token size depending on the number of bits included in the CAP Token of the main CAP parameters. Table 6.6 in the column "Number of CVR bits" there is a value of 0 for a dedicated application and 10 for a normal payment application (for example, a VSDC application).
Tab. 6.6. CAP Token size
The table shows that the CAP Token size is about 3 digits longer when using a regular payment application instead of a dedicated application.
It should be reiterated that payment systems in CAP / DPA programs recommend using a dedicated application. Note also that the personalization data of the dedicated application usually only takes up 400-500 bytes of EEPROM memory. This is due to the fact that when personalizing such an application, it is not required to store the data required for dynamic card authentication and occupying a significant amount of memory (offline authentication of the application by the reader is not performed).
There are several vendors of reader solutions on the market today, including Gemalto, VASCO, Xiring, TODOS, ActivCard and others.
As noted earlier, to implement the CAP method, the card application must support the PIN Offline cardholder verification method. More precisely, the card application data (CVM List) should determine whether the PIN code can be verified. However, not all applications support this method, and therefore they cannot be used when implementing the CAP method. As a result, MasterCard came up with the idea to develop an extension of the CAP protocol in such a way that it could be used for all EMV-compliant applications, regardless of whether they can verify the cardholder's PIN or not. As a result, a version of the CAP protocol appeared, conventionally called PLA (PIN Less Application). The PLA protocol functions similarly to the CAP protocol with the only difference that it does not require the client to enter a PIN code. Thus,
The new version of the M / Chip 4 (M / Chip 4 R2) standard provides the ability to change the cardholder PIN for a separate CAP application, used only for client authentication, in an isolated reader (unconnected PCR). Moreover, if the application supports the Encrypted PIN Offline method, the reader must use this method of cardholder verification.
So far, authentication of the smart card holder using a reader has been considered. Payment systems have long been studying the possibility of using a cell phone, the most massive means in the hands of the inhabitants of our planet, to authenticate their customers. One of the solutions in this area was proposed
MasterCard. This solution is called MasterCard Mobile Authentication (MMA) and is based on the use of the CAP protocol.
The solution can be used on cell phones supporting the Java 2 Micro Edition (J2ME) operating environment. The J2ME framework (especially when using the MIPD 2.0 profile) covers procedures for safely loading, activating, upgrading, and executing phone applications written in an abbreviated version of the Java language called MIDlets.
To implement the MMA protocol, an autonomous application (midlet) is loaded onto the phone, which implements the CAP algorithm in its distributed version (further we will understand that the MMA protocol is a version of the CAP, in which the client's PIN is checked not in the phone application, but indirectly on the server issuer). This appendix contains an encrypted card key for generating an application cryptogram. A double key (112 bits) is used. Below we will denote the key of the card for generating the applied cryptogram K AC .
To ensure the confidentiality of the K AC key during its transmission from the issuer's server and during storage on the phone, it is encrypted using the PBE (Password-Based Encryption) algorithm defined in the PKCS # 5 standard. The private key of the PBE algorithm (the 3DES algorithm is used for data encryption) is the client's mobile PIN (the client's PIN, used only for client authentication via a cell phone), padded with zero bytes on the right.
If it is necessary to generate a password, the client opens a midlet that implements MMA on his phone and enters his mobile PIN-code. Using the PIN-code value, the MIDlet creates a key to decrypt the K AC key and discloses it. Next, using this key, the MIDlet calculates the CAP Token value in accordance with the CAP algorithm described above. In this case, before calculating the CAP Token value, the MIDlet can ask the client to set the CAP protocol mode. When selecting Mode 1, Mode 2 with TDS, or Mode 3, the client will have to enter additional transaction data required by the MIDlet to calculate the CAP Token value.
The MMA algorithm implements two-factor client authentication: the client must have the issuer's midlet loaded on his phone along with the encrypted secret key K AC and must know the value of the mobile PIN-code.
If the client entered an incorrect value of the mobile PIN-code, then the decrypted value of the K AC key will be incorrect, and, therefore, the CAP Token value will not be successfully verified in the CTVS system.
The client has several attempts to enter the correct PIN-code value, after unsuccessful use of which the client is blocked in the CTVS system and further use of the MIDlet on his phone to authenticate the client will become impossible.
Note that the MMA protocol allows you to authenticate any client of any information system, including a bank client. At the same time, the client does not need to have a bank card. In the case of MMA, the phone simultaneously plays the role of a card and a reader!
6.1.4. Other IPC applications
Let's talk first about an application called Open Data Storage (ODS). Many users need a secure medium for their personal data, such as passwords, addresses, names of frequently used files, memorable dates, purchase details, etc. To do this, the ODS application is loaded onto the card.
The application has its own set of commands, such as: select a directory, create a file, get data, write data, delete data, check PIN, etc. In addition, there is an open application programming interface (API) for the ODS application, which is used computer programs to communicate with the ODS application.
An example of using ODS is a bonus scheme. On the POS terminal, you can implement an application that supports the open API to ODS, which, when the cardholder makes a purchase, will calculate the amount of the bonus based on the data on the transactions previously performed by the client and the characteristics of the current transaction. Data on previously processed transactions is stored on the card in the ODS application. The new bonus value can be written to the card with the same POS terminal application.
Another use case for ODS is surfing the Internet. Using a program installed on your computer, you can retrieve from the card memory the web addresses of sites that are popular with the card holder.
A card that supports the ODS application can be considered as a backup for storing personal and other data, usually contained in the cell phone or PDA of the card holder.
An important feature of the ODS application is that the card data is stored securely. To access this data, you need to know the value of the cardholder's PIN.
Both leading payment systems have developed specifications for open memory applications. In MasterCard, the ODS application was named MODS (MasterCard Open Data Storage), and in VISA - V3S (VISA Smart Secure Storage).
Loyalty programs implemented by joint efforts of banks and trade and service enterprises are popular in the world today. To implement such programs, a special loyalty application is placed on the bank card. After the payment application, the bonus application is the most common on bank cards.
Obviously, the IPC is a convenient tool for the implementation of loyalty programs, since it allows you to store information about the purchases of its holder, which is necessary for the terminal to calculate the amount of the bonus / discount offline without accessing the central database. This reduces the time and cost of performing operations using bonus schemes and increases their reliability.
The XLS (Extended Loyalty System) application from the Welcome company, which offers a comprehensive solution for the loyalty system on the market, has become very popular in the world. The XLS application is stored in the ROM of a number of leading card vendors. The XLS application allows real-time implementation of both the discount scheme received by the client during the next transaction, and the cumulative bonus scheme that the client can use to purchase goods and services in retail outlets participating in the bonus program. During the next transaction, the amount of the bonus increases depending on how long the client has used the trading network, how many times he has used it and how much money he spent in it.
An interesting step towards the implementation of loyalty programs has been taken by the MasterCard payment system. The new MasterCard specification for the payment application M / Chip 4 (M / Chip 4 R2) introduces the concept of integrated memory IDS (Integrated Data Storage), which allows the M / Chip 4 application to store data from other applications (for example, loyalty applications) accompanied by operators different from the bank. In this case, the terminal has the ability to read the data associated with the loyalty program (using the GET DATA command), and update them based on the results of the operation using the special PUT DATA command, executed outside the Issuer Script Processing procedure. It is important to understand that the terminal installed in a merchant participating in the loyalty program may not accept MasterCard cards.
In conclusion, we note that many non-payment applications can be successfully emulated by the EMV application. Indeed, the EMV application provides reliable data storage with ensuring the integrity of the most important static data, mutual authentication of the application and its issuer, offline dynamic authentication of the application, generation of a cryptogram of the operation, which is a proof of the fact of its execution, and, finally, the dialogue of an external system with a card in the language of a well-known a set of commands and responses to them.
Social applications (pension, transport, tax, medical, bonus, etc.) are popular in Russia. Virtually all of them can be implemented using the EMV application. Moreover, most of these applications do not require their offline dynamic authentication.
The only exception is sometimes a medical application, which sometimes requires offline authentication of an external system (for example, a doctor) at the very beginning of an operation. As we recall, the EMV standard does not provide terminal authentication. However, this disadvantage is easily circumvented. It is enough to load a special applet on a card that supports a social application (we assume that the card supports GlobalPlatform and Java Card), which performs two main functions. Firstly, the applet, based on the pre-deployed PKI infrastructure, authenticates the external system (for example, a doctor), and secondly, it prepares issuer scripts for the external system, which the external system uses to change the parameters of a medical application (for example, writes medical prescription data ).
The already familiar VSDC and M / Chip 4 applications, which are present on most bank cards, can be used as an EMV application. To use them as a tool for implementing social programs, you must first agree with the payment system - the owner of the rights to the payment application. In the case when, along with social applications, a payment application is also present on the card, reaching an agreement with the payment system is quite realistic.
We also note the simplicity of the technical implementation of the scheme described above. The point is that many card manufacturers implement applications
M / Chip 4 and VSDC in multi-instance mode. In this mode, one executable module can be used to implement multiple applications with their own AIDs and datasets. The multiinstance mode is an integral part of the card supporting the GlobalPlatform. Therefore, using different instances of the applet, it is possible to implement both a payment application and social applications on the card.
The use of the EMV application for emulating social applications opens up broad prospects for operators of social programs to use the developed infrastructure for accepting bank cards to implement these programs. This leads to significant savings in the implementation of social card programs.
- statement of the problem of emission migration and maintenance of microprocessor cards;
- selection of the IPC hardware and software platform, card supplier and configuration of its application;
- modernization of the hardware and software complex of the central system designed to process authorization and clearing messages, both from the side of card issuance and from the side of their servicing;
- modernization of the card personalization system;
- modernization of the terminal network for servicing cards;
- testing and certification of the bank for compliance with the requirements of payment systems related to servicing and issuing microprocessor cards.
Statement of the problem of migration to the IPC
The statement of the problem of bank migration to IPC technology can vary widely - from the formal implementation of the recommendations of payment systems for migration to IPC technology, reflected in their adopted responsibility shifts (Chip & PIN Liability Shift) and changes in interbank fees, to the introduction of a commercially attractive multi-application card capable of simultaneously support multiple applications that perform a variety of functions.Initially, banks identified three main reasons for migrating to the IPC:
- 1) a radical increase in the safety of operations performed using IPC in comparison with cards with a magnetic stripe;
- 2) changing the mode of servicing cards and reducing the cost of servicing them;
- 3) the ability to use several applications on one card.
Experts at APACS, the British Interbank Association, argue that if the UK had not started migrating to a chip, its banks would have lost approximately £ 800 million in 2004, or about 60% more than they actually turned out to be. The volume of losses from card fraud of British banks in 2005, according to APACS forecasts, would have exceeded? 1 billion, i.e., the banks' savings in 2005 alone amounted to about? 0.5 billion.
According to various estimates, the migration of British banks and merchants (approximately 42% of POS terminals in the UK belong to merchants, not banks) to RPCs cost about £ 2-2.5 billion. Hence, taking into account forecasts of bank losses due to card fraud the meaning of migration to a chip for English banks was obvious.
One of the important consequences of improving the security of operations, as well as the fact that the IPC is a microcomputer capable of independently making decisions delegated to a card by its issuer, is a change in the card service regime. Here, first of all, it should be noted the possibility of increasing the share of offline IPC operations while maintaining their level of security. Indeed, the emergence of the possibility of reliable authentication of the card and verification of its holder using the PIN-code in offline mode makes the processing of the transaction even within the framework of the “card-terminal” dialogue rather safe.
There are many advantages to performing an operation offline. First of all, it should be noted that the transaction processing time has decreased. Here, however, a caveat is required due to the fact that if some characteristics of the card and terminal are not up to par, then the online authorization execution time may turn out to be less than the same time for an offline transaction. The main reason for such delays is the sometimes slow implementation of the RSA algorithm at the POS terminal.
However, on average, taking into account the savings in data transfer time, the processing of the transaction in offline mode is faster. This is especially obvious in the case of using POS-terminals operating over dial-up communication channels. Only the call of such a terminal to the host of the servicing bank takes about 20-40 seconds.
As a result of the reduction in transaction processing time, the use of cards has expanded in an environment that was previously ill-suited for their use - fast food restaurants, fare, access control, etc. In such cases, in order to further reduce the processing time of the operation, it is recommended to use IPCs with a radio interface.
The second benefit of offline transaction processing is the reduction in operating costs for processing card transactions as a result of savings in communication costs.
It is also necessary to mention the longer service life of the IPC. The magnetic properties of the magnetic stripe of the card deteriorate significantly after 2-3 years of use. As a result, and for security reasons, the life of a magnetic stripe card is typically 2 years.
The characteristics of the IPC chip are such that the card can serve excellently for 10 years or more.
Let us now consider the advantage of the IPC associated with the ability to support several different applications on one card. Of greatest interest are applications for pre-authorized debit / credit (prepaid card, possibly EMV standard), cardholder authentication when requesting access to the Internet banking system and in e-commerce transactions in accordance with the MasterCard Chip Authentication Program and VISA Dynamic Passcode Authentication, as well as e-wallet applications, user identification, PKI infrastructure and loyalty. Let's dwell on these applications in more detail.
6.1.1. Prepaid card
The essence of a prepaid card (Preauthorized Debit / Credit or PAD) is that the issuing bank allows the holder of the IPC to carry out operations offline within the limit set by him, while reliably controlling the fact that the client will not spend more than the amount available on his account in bank funds.
The idea of organizing control in general terms is as follows. The concept of "shadow account" or Shadow Account (SA) is used. A shadow account is used to control transactions performed offline using a chip. The initial SA value is set to the Upper Cumulative Domestic Offline Transaction Amount (UCOTA) set on the card.
All transactions performed in real time using a magnetic stripe or a chip are accounted for in the usual way against the so-called SA1 holds. This account reflects authorizations (x100 messages), which are recorded in the issuer's system in the form of special records called holds. When a x100 message arrives, the size of SA1 is increased by the size of the transaction amount. Financial messages (presentations) that enter the issuer's system for transactions involving the use of a magnetic stripe, or for online chip transactions, debit the client's account, find and remove the corresponding hold (delete the record), if there is one in the issuer's system. We will not dwell on the methods of finding a hold by presentation. We only note that
At each moment of time, the value of Available Amount (АА) is determined, which is equal to the difference between the current value of the client's account АС and the sum of SA1 and SA and determines the funds available for use by the client:
AA = AC - (SA + SA1).
At each moment in time, this value must be greater than or equal to 0. This is taken into account both at the next choice of the UCOTA value and when authorizing online transactions.
Unlike presentations initiated by online transactions or offline transactions performed using
Chapter 6. FEATURES OF MIGRATION ON MICROPROCESSOR CARDS 399 magnetic stripe, presentations on offline transactions associated with the use of the chip, debits AC and SA values at the same time.
When an online transaction processed using a chip occurs on a card, the Cumulative Offline Transaction Amount (COTA) counter of the amount of offline transactions performed since the last online chip transaction is transmitted in the Issuer Application Data object to the card issuer. The SA value is credited to the SOTA value.
If, after crediting SA, the Available Amount value becomes less than zero, it is necessary to decrease the value of the UCOTA counter on the card so that the Available Amount value becomes positive. This can always be done, since the COTA value, by which the Available Amount is reduced after the SA is credited, is less than the UCOTA value. At the same time, the value of UCOTA was taken into account in SA from the very beginning (in this way, this value is reserved on the client's account). Therefore, SA at the time of processing an online transaction can be reduced by the size of UCOTA by simultaneously changing the value of the UCOTA card counter to 0.
In practice, it is not necessary to decrease the SA size by the UCOTA value. Depending on the policy of the issuer, the size of SA may be changed to a lesser amount. The main thing is that after a decrease in SA, the Available Amount value becomes positive. In this case, a decrease in SA should be accompanied by a change by the same value of the value of the UCOTA counter on the card. This change of the card parameter is carried out by the issuer using the PUT DATA command of the Issuer Script Processing procedure.
Simultaneous application of a presentation to SA and AC is in this case analogous to the previously described mechanism for removing holds, adopted for cards with a magnetic stripe. The specificity of the IPC is that the issuer receives from the card the cumulative value of the funds spent with it in offline mode. Therefore, it is not possible to search for a match between a presentation and a hold.
The mechanism for removing the holds used for the IPC requires constant correction of the values of the shadow account. Indeed, the transaction sizes in the transaction and the 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 presentations at all.
The SA value correction procedure can be arranged as follows. The moments of online transactions processed using the card chip are recorded. If XI and X2 are two such consecutive points in time (XI <X2), then a correction is calculated for the value of SA at time X2 + T. Here T denotes the size of the maximum period of time during which the serving bank must present to the system a presentation on the operation performed on its device. The value of T is determined by the rules of the bank's payment system.
The correction to the SA value is calculated at time X2 + T as the difference between the COTA value sent to the issuer at time X2 and the sum of all presentations received in the time interval [XI, X2 + T] with the following parameters:
- the transaction was performed offline using a chip;
- the date of the transaction, fits within the time interval [XI, X2].
Then the calculated correction is subtracted from the current SA value. As a result of performing the described procedure, the SA values are corrected for the amount of discrepancy in the sum of the size of chip transactions in presentations and authorizations performed between two consecutive online transactions. Regular execution of the described procedure will allow, with a delay, but accurately to correct the SA values and, thus, the value of the balance available to the cardholder.
A similar prepaid card scheme is offered by VISA (VSDC + product) and MasterCard (MasterCard Pre-authorized Debit / Credit product).
6.1.2. Online wallet
Similar in nature to the prepaid card application is the e-wallet application. The meaning of this application is that a certain amount of money is electronically loaded onto the card from the client's account. Loading money from a client's account, unlike a prepaid card scheme, means that this money is debited from the account, and from that moment the bank loses control over it. In fact, this means that the bank must transfer the funds withdrawn from the client's account to the settlement bank of the electronic wallet payment system.
The loss of the bank's control over the money loaded into an electronic wallet makes it possible to realize another important property of an electronic wallet - the anonymity of transactions performed with its help. It is thanks to the anonymity that the electronic wallet becomes an analogue and substitute for cash.
With the help of an e-wallet application, purchases are made offline, which is extremely convenient, if only for reasons of saving time and costs for the operation.
Otherwise, settlements are carried out for operations performed using an electronic wallet. When making a purchase, money is debited from the client's card (the value of the counter of funds available on the card is reduced by the size of the transaction) and credited, for example, to the card of the trading terminal (options are possible when the transaction details are stored in the merchant's system together with the transaction cryptogram - a value that confirms the fact of execution operations). The moment of completion of the purchase operation using an electronic wallet application in this case is also the moment of completion of settlements between the cardholder and the merchant. The latter, in order to receive a refund for a non-cash transaction carried out on a card with an electronic wallet attachment, must only present proof of the fact of the service provided by it.
For example, if a merchant for settlements uses a card with an electronic wallet application and money for purchases made in it is transferred to this card during successful transactions, then the merchant only needs to use the "Unload card" operation in the system terminal to transfer money for purchases to your account.
In the second half of the 1990s. there has been an increased interest in the e-wallet application worldwide. Such schemes as Proton, Mondex, SORAS, CLIP, VISA Cash and others are widely known. On their basis, a large number of payment systems were created, such as GeldCarte, Minipay, Quicklink, Chipper, ChipKnip, Moneo, etc. Some of them were in the nature of national payment systems.
In 2000, in connection with the variety of electronic wallet technologies used in the market and the idea of creating a unified European system of cashless payments, the international Common Electronic Purse Standard (CEPS) appeared. This standard was intended to ensure the compatibility of electronic wallets and terminal equipment from different manufacturers while creating a unified international payment system based on electronic wallet technology. In particular, the CEPS standard describes the following list of operations:
- loading the wallet;
- unloading the wallet (to the account of the cardholder with the issuing bank);
- purchase operation;
- currency exchange operation;
- operation to cancel the last purchase;
- an incremental purchase transaction (see below).
The CEPS standard allows flexible settlement schemes for completed transactions. 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 file of transactions to the issuers of the cards involved in them. Further, settlements for the purchase operation can be made in the same way as in the case of a card with a magnetic stripe. The only difference will be that the issuer no longer debits funds from the client's account. The money is transferred to the correspondent account of the servicing bank in the settlement bank of the system from the Funds Pool account of the bank that issued the card. It is important to note the following about the Funds Pool account. To ensure control of transactions on e-wallet cards issued by the bank, the Funds Pool account is only registered with the issuer, but does not belong to it.
The incremental purchase operation is used, for example, when paying for telephone calls. In this case, the card remains in the terminal until the end of customer service, and the terminal periodically sends requests to the card to deduct the cost of the service provided since the last request of the terminal from its account. If the size of the available card balance after the next request from the terminal becomes negative, the client's service will be terminated.
The operation of downloading an electronic wallet is carried out both from the client's account in his issuing bank (Linked Load), and from a special account (Funding Account) in an arbitrary bank that is a member of the system (Funds Issuer). This load is called Unlinked Load.
The funds are loaded onto the card in a special loading device (Load Device) served by the system bank (Load Acquirer).
The use of a special account is convenient for the client, since it allows him to replenish his card account when he wants it, and where it is convenient for him, by depositing funds into his account not in his native, but in a bank nearby to him. Banks that provide services for opening Funding Accounts, as already noted, are called Funds Issuer. Often in practice the equality Funds Issuer = Load Acquirer is fulfilled, i.e. the client transfers cash to the loading bank (at this moment the bank acts as a Funds Issuer), and the latter increases the amount of available funds on the card (at this moment, the bank acts as a Load Acquirer).
When loading an Unlinked Load card, the loading bank contacts the 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 for loading cards.
Obviously, in the process of settling the Unlinked Load transaction, the loading bank will receive funds from the Funds Issuer bank account and transfer them to the card issuer's Funds Pool account. As a result, the funds loaded on the card will be reflected in the Funds Pool account of the issuing bank, since it is this account that provides settlements for all operations of the cardholder.
In the process of downloading Linked Load, the money from the client's account immediately goes to the account of the issuing bank's Funds Pool, and no interbank settlements are made.
Thus, the main difference between the e-wallet and prepaid card schemes is that after the funds are loaded into the client's e-wallet, the issuing bank loses control over the funds loaded onto the card. Usually, the funds loaded into the client's electronic wallet are debited from his bank account with the issuing bank and then transferred from the issuer's correspondent account with the system's settlement bank to the issuer's Funds Pool account with the system's settlement bank. From the issuer's Funds Pool account, money is subsequently transferred to the correspondent accounts of the servicing banks in connection with the “Purchase” operations performed in their terminal devices using bank cards.
In the case of a prepaid card, control over the client's funds remains until the issuer receives a financial message from the servicing bank.
It should be admitted that, despite the considerable time that has passed since the advent of the CEPS standard, it has not become widespread. This is primarily due to the banks' loss of interest in this means of settlement, and not to technological defects of the proposed standard. Today, some of the e-wallet ideas are used in e-money technologies that are used to pay for e-commerce transactions.
6.1.3. Cardholder authentication
As already noted, reliable cardholder authentication is an extremely demanded task when performing CNP operations, including e / mobile commerce transactions, as well as for solving the problem of controlling access to various information systems: Internet banking systems, bank contact center, etc. ... The microprocessor card is ideal for dynamic client authentication, as it is able to securely store the secret information of the cardholder used to authenticate him, as well as calculate cryptographic values depending on the parameters of the operation he performs.
Leading payment systems have repeatedly turned to the idea of using a smart card to remotely authenticate the holder of a microprocessor card. For example, the Secure Electronic Transaction (SET) e-commerce protocol Common Chip Extension proposed the idea of using the ARQC cryptogram for online card authentication. At the same time, the personal computer of the cardholder simulated the operation of the terminal and, in particular, could support the offline procedure for checking the cardholder's PIN code. Unfortunately, the SET protocol did not become widespread and the programs of international payment systems using it were stopped.
Today, payment systems use a different technology to solve the problem of cardholder authentication. This technology is called CAP (Chip Authentication Program) in the MasterCard system and DPA (Dynamic Passcode Authentication) in the VISA system. The technology is based on the CAP (Chip Authentication Program) protocol, developed by MasterCard specialists and adopted by the VISA payment system in the DPA program.
Chapter 6. FEATURES OF MIGRATION ON MICROPROCESSOR CARDS 405
It is expected that the technology will become widespread in solving the problem of cardholder authentication in e-commerce transactions performed using the 3D Secure protocol. MasterCard and VISA systems have a cross-license agreement, according to which the certification results of the 3D Secure and CAP / DPA solutions used by the bank, valid in one system, are valid in another.
The relevance of the CAP protocol for solving e-commerce problems is due to the fact that the most serious security problem of the 3D Secure protocol is its defenselessness against man-in-the-middle attacks when a cardholder uses a static password for his verification. For example, when a cardholder uses the 3D Secure protocol, fraudulent online stores can use the following procedure to compromise the cardholder's password (Fig. 6.1). The Merchant Plug-In (MPI) system of a fraudulent store, having received a response VER.es containing the dynamic address (URL) of the Access Control Server (ACS), sends a request for authentication of the PAReq cardholder not to the specified address, but to its address. SSL server. The fake SSL server then redirects this request to the card issuer's ACS URL, obtained from the VERes message, thereby pretending to be the cardholder's computer for ACS. As a result, ACS takes the false server for the personal computer of the cardholder and transmits to the false server its page intended for cardholder authentication. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value. designed to authenticate the cardholder. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value. designed to authenticate the cardholder. This page contains the Personal Assurance Message, with the help of which the client authenticates his bank in the 3D Secure scheme (more precisely, the ACS server of his bank). With a page for authentication, the fraudulent server can now act as an ACS for a real bank customer, asking the latter for a static password value.
In order to reduce the consequences (unfortunately, it will not be possible to fully protect yourself) from such password thefts for the purpose of their further use in fraudulent operations, various schemes for generating and using dynamic passwords have been proposed, or,
Rice. 6.1. A possible way to compromise a password in the 3D Secure scheme is called One Time Password, or OTP for short. The CAP standard defines the most common OTP generation algorithm in the banking sector.
The essence of the ATS technology is as follows. It is assumed that the client has:
- a card with a standard EMV application supporting the PIN Offline cardholder verification method;
- a special device with a screen, a keyboard, special buttons and a card-reader for the IPC (we will further call it a reader, in the literature it is often called PCR - Personal Card Reader).
After choosing an option and, possibly, entering some parameters of the operation by the client on the keyboard, the reader prompts the cardholder to enter the value of his PIN-code. If the client has selected the option to generate a one-time password and the PIN-code value entered by him turned out to be correct, the reader displays on his screen a number that is a one-time dynamic password of the cardholder used to authenticate the cardholder when performing this operation. This password can, for example, be used to authenticate the cardholder with the issuing Access Control Server when the cardholder performs an e-commerce transaction using the 3D Secure protocol.
If the cardholder has chosen the option of receiving the data signature, the card uses the reader to form the signature of the data entered by the client on the screen. The received signature is used both to authenticate the cardholder (only he could form such a signature) and to ensure the integrity of the signed data. Such a signature can act as a cryptogram of the operation being performed, thereby making it impossible for the client to refuse the performed operation (non-repudiation).
If the option of preparing a response to the cardholder verification request was selected, the card uses the reader to sign a random number contained in the cardholder verification request. This ensures the authentication of the cardholder with reference to a specific operation (a random number is generated by the issuer for a specific operation).
Readers used in CAP / DPA programs can be stand-alone (no network interfaces) or plugged into the cardholder's computer. In the latter case, it is easier for the cardholder to enter the transaction parameters. They do not need to be entered through the reader's keyboard, since a computer program can do this for the card holder. In addition, in this case, if there is a special client application on the cardholder's computer, it is possible to perform online transactions on the card.
However, in most cases, banks use standalone readers. They do this for security reasons (to limit access to the card reader over the network) and because the amount of data entered by the cardholder on the reader's keyboard is small.
The general scheme for the implementation of the CAP protocol is as follows. The reader emulates the operation of the POS terminal and, after the card is inserted into the reader, initiates the operation. At the beginning of the operation, the reader can ask the cardholder for information about the size and currency of the transaction, as well as the random Challenge number, which can be the transaction details reported to the cardholder by the authenticating party. At the same time, the reader does not perform offline card authentication and risk management procedures, and in the first GENERATE command, the AC requires the card to generate an ARQC cryptogram.
The card application must support offline PIN verification - Plaintext PIN Offline and / or Encrypted PIN Offline methods. In addition, it must be personalized so that the reader selects one of the PIN Offline cardholder verification methods from the CVM list (for example, the PIN Offline method must be the first CVR rule in the CVM List; it is sufficient that this method is supported by the card and the bit 7 bytes CVM Code for all verification methods supported by the card was equal to 1). The reader itself only supports the Plaintext PIN Offline and Encrypted PIN Offline methods of cardholder verification.
If the PIN code check is successful, the reader sends the GENERATE AC command to the card, requiring the generation of the ARQC cryptogram. After completing the risk management procedures and deciding how to complete the transaction, the card can respond to the reader by generating an ARQC or AAC cryptogram. If AAS is generated, the operation ends. If an ARQC cryptogram is generated, the reader will send a second GENERATE AC command to the card, requesting the AAC cryptogram and indicating to the card the Authorization Response Code Z3 (it is impossible to send the request online, rejected offline).
In this case, the reader will ignore the response received from the card to the second GENERATE AC command (i.e., the ARQC cryptogram received in response to the first AC GENERATE command will be used to calculate the CAP Token). Based on the Z3 code, the application will set the Unable to go online flag in the CVR object. In addition, in the case of a VSDC application, without receiving a response from the issuer, the application will set the Last Online Transaction not Completed flag in the CVR object.
Having received a response from the card to the first GENERATE AC command, the reader, using the data received in the response, calculates a certain value called CAP Token, the size of which varies from 6 to 16 decimal digits. Since the CAP Token contains individual cryptogram bits, it is used to authenticate the card application. If the value of the CAP Token has successfully passed the verification procedure, then the cryptogram of the transaction, which was used to calculate the CAP Token, will also pass it with a high probability. The CAP Token value is displayed on the reader's display and is subsequently used by the cardholder to authenticate it, for example, when logging into the Internet banking system or performing an e-commerce transaction.
Thus, the CAP method implements two-factor authentication of a bank client: the latter must have a bank card (to generate a cryptogram) and know his PIN-code.
There are two important points to make here. The first concerns the application that implements cardholder authentication. This application may be a special stand-alone application used by the card issuer solely to authenticate the cardholder in accordance with the CAP protocol (this application is not used for financial transactions). Or it can be a general-purpose application used, among other things, to perform operations in POS terminals and ATMs. Payment systems recommend banks to use a special separate application to authenticate the cardholder. In the leading payment systems, a special extension of the application identifier P1X = 8002 is allocated for this separate application.
The recommendation of payment systems to use a separate application for cardholder authentication is related to several reasons. First, the use of a payment application to authenticate the cardholder may result in the transaction being rejected offline (the payment application will return the AAC cryptogram to the reader). As a result, offline new card counters may change (as, for example, in the VSDC application), which will leave an imprint on the further use of the payment application.
Secondly, the peculiarities of the implementation of the cardholder's authentication by the terminal are reflected in the behavior of the payment application. For example, as we remember, in the second GENERATE AC command, if it comes down to it, the terminal asks the card to return the AAC cryptogram, transmitting the authorization response code Z3 to the card. As a result, the Last online transaction not completed bit of the CVR object of the VSDC application will be set to 1. This fact may require the mandatory execution of the next operation using the online payment application (this bit is reset in CVR only as a result of successful authentication of the card issuer).
Third, as will be seen below, the size of the CAP Token value generated by a separate application is less than the same size for the case of using a conventional payment application. The size of the CAP Token is a critical parameter for the usability of the CAP technology.
Fourth, verifying the CAP Token value in the issuer's system (the subsystem that verifies CAP Token values is called the CAP Token Verification System, or CTVS for short) turns out to be easier if a separate application is used. When using a regular application for cardholder authentication, it is necessary to ensure synchronization of the data of the issuer's system and the CTVS (keys, card counters, etc.).
Finally, fifthly, the use of different applications improves the security of the payment service and the cardholder authentication service.
The second note concerns the behavior of the ad-hoc application. It is recommended to personalize the special application so that in response to the first GENERATE AC command, the reader always receives an ARQC cryptogram from the card. This behavior of the application allows you to minimize the amount of data that needs to be transferred to the issuer to check the CAP Token value, making the values of all bits of the CVR object predictable, and also does not change the values of offline application counters, which allows you not to worry about the values of the limits for these counters. This will be discussed in more detail below.
From the above comments, the answer to the question of why the reader does not require the return of the AAC cryptogram in the first GENERATE AC command follows. Such an approach would greatly simplify the work with the card and would reduce the spread of the values of the card response. The answer is simple. The reader requests the ARQC cryptogram from the card to try to minimize the impact of the CAP authentication procedure on the card's payment application. The request in the first GENERATE AC command for the AAC cryptogram can change the offline counters of the payment application. For example, this happens in the VSDC application in the case when a transaction is rejected offline and the corresponding conditions for changing the values of offline counters of this application are met (see clause 11.5.1 of the VIS 1.4.0 specification).
Depending on the composition of the transaction data used to calculate the cryptogram and CAP Token, the CAP scheme implies the implementation of one of four modes. Transaction data is requested from the cardholder by the reader and entered by the cardholder using the reader's keyboard. The definition of CAP protocol modes is given below.
Mode 1: to calculate the AC cryptogram, Challenge is used (required), the size and currency of the transaction (optional), only the size of the transaction (optional).
Mode 2: no transaction data is used to compute the AC cryptogram.
Mode 2 with TDS: no transaction data is used to compute the AC cryptogram. Transaction data (up to 10 fields, each with a maximum of 10 characters) is used to calculate the CAP Token. In the process of calculating the CAP Token, the MAC of the transaction data is determined. For this, the ISO 9797-1 Algorithm 1 algorithm is used, in which the previously obtained applied cryptogram is used as the key, and DES is used as the ALG algorithm.
Mode 3: Mode 3 is a special case of Mode 1, only the obligatory Challenge element is used to calculate the AC cryptogram.
The reader is required to support Mode 1 and Mode 2. Modes Mode 2 with TDS and Mode 3 are optional.
The choice of the CAP mode is made by the client at the beginning of the authentication procedure. For this, the corresponding buttons of the reader are used. Often these buttons have names familiar to the bank's client: Sign (signature of the transaction details), Identify (generation of a one-time cardholder password) and Verify (generation of a response to a cardholder verification request). In this case, each button is implemented by one of the modes of the CAP protocol. Examples of the use of CAP mods for the implementation of various functions are given in table. 6.1.
The signature function is useful for organizing services that require not only cardholder authentication, but also the security of the cardholder. 6.1. Examples of using the CAP mod
| Function | Usage example | CAP mods used to implement the function |
| 3D Secure | CNP transactions | Mode 1, Mode 3 |
| Identify | e-banking login | Mode 2 |
| Sign | E-commerce transactions | Mode 2 with TDS |
| Verify | e-banking login | Mode 3 |
making it impossible for the client to refuse the service provided to him. An example of such a service is Internet banking. Indeed, when ordering any service on the bank's website, the card holder receives a page with a request to confirm the order and a request to insert a signature number into a certain field of the page. The signature number is generated for the decimal number present on the bank's website page, usually representing the value of some hash function from the parameters of the service provided to the client, generated by the Internet banking system. The cardholder inserts the card into the reader, by pressing the button selects the Sign option, enters the PIN-code value and the number from the bank's website page. As a result, a decimal number appears on the reader's display, which is inserted by the client into the signature field on the bank's website page.
The operation dataset used when Mode 1 is selected is defined by a special Issuer Application Flags data object (IAF, Tag '9F55'), whose data field is one byte in size and is shown in the table below. 6.2.
Table 6.2 shows how the transaction data used in Mode 1 is determined. The IAF data object also determines the need to use PSN bits when generating the CAP Token value, which will be discussed in more detail below. If the IAF data object is not present in the selected reader application, then the reader considers its default value to be '00'h.
The general scheme of transaction processing is shown in Fig. 6.2.
In response to the first GENERATE command, the AC card returns data objects CID, ATC, AC and IAD to the reader. It would be possible to provide the received data, supplemented with information on the card (PAN, PSN) and operations (size and currency of the transaction, Challenge), for verification to the issuer's system. The essence of checking the issuer would be to determine the corresponding table. 6.2. Issuer Application Flags Object Data Field Structure
| B8 | B7 | B6 | B5-b1 | Bit value |
| X | Amount and currency indicator. Used only in Mode 1 | |||
| 0 | Neither the size of the transaction, nor its currency are used to generate the AS | |||
| 1 | Either the size of the transaction or the size and currency of the transaction are used to generate the AS | |||
| X | PAN Sequence Number Indicator | |||
| 0 | PSN is not included in CAP Token | |||
| 1 | PSN bits are included in the CAP Token | |||
| X | Ignore Currency Indicator. Used only for Mode 1 | |||
| 0 | Transaction size and currency are used if b8 = 1 | |||
| 1 | Only transaction size is used if b8 = 1 | |||
| xxxxx | Reserved bits | |||
| 00000 | Not used |
Consequences of the data received by the issuer to the value of the AS applied cryptogram.
However, this method of verification is unrealizable in practice. When used, the CAP Token value can be a 104 decimal digit number. Indeed, the data fields of the CID, ATC, AC, IAD objects are 1, 2, 8 and 32 bytes, respectively (the size of the IAD data field is 32 bytes for the CPA application). This means that the CAP Token resulting from the concatenation of the listed data will have a size of 2 8 (1 + 2 + 32) = 2 344 ~ 3.58 • 1O 103... Obviously, displaying such a number on the reader's display, and even more so informing it to the issuer's system without errors, will be problematic. When using such a number, the probability of a client's error when entering it is too high, and typing it on a computer (if ATS is used in e-commerce or Internet banking) is long and laborious.
Therefore, the main task of the CAP protocol is to maximally compress the data received in response to the first command of the GENERATE AC reader in order to generate the CAP Token value from them, the value of which, despite compression, on the one hand, is difficult to guess, and with another - it is still possible to check in the CTVS system (there is enough data for verification).
To determine the data compression algorithm, consider the parameters that must be included in the CAP Token. We repeat once again that the main
Rice. 6.2. General scheme of the authentication procedure
the idea of CAP Token verification is that the CTVS issuer system can, by the CAP Token value, verify the operation cryptogram (or its individual bits), obtained as a result of the reader's dialogue with the card. This means that a prerequisite for the implementation of CAP is the ability of the CTVS to calculate on its side the cryptogram returned by the card to the reader.
To calculate the cryptogram, the CTVS system needs to know the values of the following quantities:
- PAN and PSN to generate a card key for generating a cryptogram. This key is calculated using the issuer's key stored in the CTVS system. The card number is transmitted to the issuer separately from the CAP Token within the transaction, within which the cardholder is authenticated. The PSN value (or its individual bits), if used by the issuer, must be included in the CAP Token;
- the issuer key index Derivation Key Index (DKI), which CTVS uses to determine the issuer key for generating the cryptogram. This index is part of the IAD object returned to the reader in response to the AC GENERATE command;
- ATC transaction number returned to the reader in response to the AC GENERATE command;
- CVR card data returned to the reader as part of the IAD;
- transaction and reader data transmitted to the card in the GENERATE AC command in accordance with the CDOL1 list.
Tab. 6.3. Data used by the card when forming a cryptogram
| Data item | Meaning |
| Amount, Authorized, Tag 'F02' | Default 00 00 00 00 00 00 |
| Amount, Other, Tag '9F03' | 00 00 00 00 00 00 |
| Terminal Country Code, Tag '9F1A' | 00 00 |
| Terminal Verification Results, Tag '95' | 80 00 00 00 00 |
| Transaction Currency Code, Tag '5F2A' | Default 00 00 |
| Transaction Date, Tag '9A' | 00 00 00 |
| Transaction Type, Tag '9C' | 00 |
| Unpredictable Number, Tag '9F37' | Default 00 00 00 00 |
| Application Interchange Profile, Tag '82' | XX XX |
| Application Transaction Counter (АТС), Tag '9F36' | XX XX |
| Card Verification Results (CVR) | The data field of this object is 4 bytes for VSDC, 5 bytes for CPA and 6 bytes for M / Chip 4 |
As you can see from the table. 6.3, all data, except for the transaction counter of the ATC card application and CVR, are fixed, and therefore known to the card issuer.
Thus, the task of compressing the data included in the CAP Token is reduced to compressing the following data:
- ARQC cryptogram generated by the card in response to the first command of the reader GENERATE AC;
- PSN;
- automatic telephone exchange;
- DKI;
- CVR.
The cryptogram contains 64 bits of information and is a cryptographic function of the variables indicated in table. 6.3. A fraudster, not knowing the key of the card to generate the cryptogram, can only guess the meaning of the cryptogram. If we leave only n bits (out of 64 possible) in the CAP Token , then the probability of guessing them is 2 ~ n . Obviously, there is no point in making the probability of guessing the bits of the cryptogram left in the CAP Token higher than the probability of guessing the client's PIN-code (the second factor of cardholder authentication). The probability of guessing both factors will turn out to be negligible even in the case when the probability of guessing each factor will be at the level of the probability of a PIN-code being compromised.
If a 4-digit PIN-code is used and the fraudster has three attempts to guess its value, then the probability of guessing the PIN-code value is approximately equal to 3 × 10. since it is a dynamic value and will take on a different value on the next guessing attempt). Since the CAP Token is checked in the HSMs, it is desirable that the size of the portion of the cryptogram left in the CAP Token be a multiple of 8 bits (byte size). Therefore, payment systems recommend leaving at least 16 bits of the cryptogram in the CAP Token.
The PSN parameter can be used by the issuer in order to issue several cards under the same number. Often times, issuers don't use PSN. In this case, PSN will not be included in the CAP Token either. As noted above, the fact that PSN is used to generate the CAP Token is reflected by bit 7 of the IAF object.
If, nevertheless, PSN is used by the issuer, then it consists of two decimal digits (encoded with one byte). The most significant digit of the PSN is commonly used to identify different cardholders using a common card number (for example, members of the same family). The least significant digit of PSN defines the re-issue cycle of the card with this number. If, for example, the number of card re-issues is not more than 3 and the number of cardholders per card is not more than 3, then it is enough to leave the last two digits of each byte halo representing PSN from PSN in CAP Token. In this case, it will be enough to include 4 PSN bits in the CAP Token instead of the initial 8 bits.
The value of the ATC transaction counter is encoded in two bytes. Obviously, the maximum number of transactions provided in this case, equal to 65,535 operations, in practice, with a high probability, will not be achieved over the entire life cycle of the card. Indeed, if we consider a very active cardholder performing 14 transactions every day during the entire three-year card validity period, he will be able to make only 15,330 transactions. To encode the PBX in this case, it is enough to select 14 bits of the PBX.
In addition, it is possible to break PBX number into two parts: the lower m bits included in the CAP Token, and the remaining upper bits stored in CTVS not included in the CAP Token. Then, if m is large enough, when performing the next authentication of the cardholder, the CTVS system will be able to unambiguously determine the value of the ATC from the value of m . Indeed, if the received CTVS t digits of the current ATC value are greater than the last t digits of the last ATC value stored in CTVS, then to form the ATC, the upper ATC bits stored in the CTVS are added to the digits received from the CAP Token on the left. Otherwise (received by CTVS t digits of the current ATC value are not more than the last tdigits of the last PBX value stored in CTVS) CTVS increments the number representing the most significant bits of the PBX number, stores it in binary instead of the old value, and adds the new value of the most significant bits to the m bits received from the CAP Token on the left .
If m is large enough, for example, m = 7, then such a mechanism will make it possible to reliably restore the ATC value, provided that no more than 255 payment transactions are made between two consecutive cardholder authentications. In practice, this value of m is quite sufficient to restore the value of the ATC in the CTVS system.
The issuer can use different keys to generate the keys for their cards. Usually, each issuer's BIN corresponds to a certain set of its keys. This is done for ease of key management. For example, such a correspondence between BIN and issuer key sets exists in backup authorization systems of leading payment systems. In backup authorization systems, there is a limitation on the number of issuer's keys assigned to one value of its BIN. For example, in the VISA system, this number is limited to 24 keys. This means that 5 bits of information are sufficient to encode the DKI. In practice, it is often enough for the issuer to have no more than 7 keys per BIN, for which it is enough to include the three least significant bits of the DKI representation in the CAP Token.
Finally, let's look at ways to compress information for a CVR object. Obviously, the number of CVR bits that it is enough to leave in the CAP Token so that the entire CVR data object in the CTVS system can be restored from them, essentially depends on whether the application used is a special application for cardholder authentication, or it represents is the usual payment application of the issuer. Let us illustrate the above with the example of the CVR application of the VSDC payment system VISA. Table 6.4 shows the CVR bit values for the dedicated application case. Recall that this CVR value is generated by the card as a result of the risk management procedure after the first GENERATE AC command is received. It also assumes that the ad-hoc application is configured in such a way that
Tab. 6.4. CVR bit values for dedicated VSDC application
| Byte number | Bits | The purpose of the bits and their possible meanings | The expected value of the bits |
| Byte 1 | Bits 8-1 | CVR data field length | 00000100 |
| Byte 2 | Bits 8-7 |
11- value is not used | ten |
| Bits 6-5 |
| ten | |
| Bit 4 | 1 = Issuer authentication succeeded and failed | 0 | |
| Bit 3 | 1 = Offline PIN verification performed | 1 | |
| Bit 2 | 1 = PIN Offline verification failed | 0 | |
| Bit 1 | 1 = terminal cannot send transaction to issuer (unable to go online) | 0 |
The end of the table. 6.4
| Byte number | Bits | The purpose of the bits and their possible meanings | The expected value of the bits |
| Byte 3 | Bit 8 | 1 = last online transaction not completed | 1 |
| Bit 7 | 1 = PTL exceeded | 0 | |
| Bit 6 | 1 = offline counters exceeded | 0 | |
| Bit 5 | 1 = new card | 1 | |
| Bit 4 | 1 = Issuer authentication failed on the last transaction | 0 | |
| Bit 3 | 1 = Issuer authentication failed after online authorization | 0 | |
| Bit 2 | 1 = App blocked by card due to PTL exceeded | 0 | |
| Bit 1 | SDA failed on the last transaction and the transaction was rejected offline | 0 | |
| Byte 4 | Bits 8-5 | The number of Issuer Script Processing commands processed in the last transaction | 0000 |
| Bit 4 | 1 = Issuer Script Processing failed on the last transaction | 0 | |
| Bit 3 | 1 = DDA / CDA failed on the last transaction and the transaction was rejected offline | 0 | |
| Bit 2 | 1 = offline dynamic authentication has been performed | 0 | |
| Bit 1 | Not used | 0 |
It can be seen from the table that all bits of the CVR object in the case of using a dedicated application for cardholder authentication are predictable, and therefore there is no need to include them in the CAP Token.
The situation changes when using a regular payment application. Below in table. 6.5 shows the meaning of the CVR bits in this case.
The bit values indicated by x are not predictable and depend on the configuration of the VSDC application and the history of the card application. As a result, the CAP Token will need to include 10 CVR bits, the values of which are not predictable and cannot be recovered in CTVS.
Above, we discussed the data bits that must be included in the CAP Token so that it is possible to calculate the cryptogram in CTVS. Now let's dwell on the method for calculating the CAP Token. Obviously, all the bits included in the CAP Token can be obtained from the card's response to the first command GENERATE AC (CID, ATC, AC, LAD) and PSN. Indeed, DKI and CVR are included in the AID object. The ATC and cryptogram values are directly contained in the response to the AC GENERATE command.
Tab. 6.5. CVR bit values when using the VSDC payment application
| Byte number | Bits | The purpose of the bits and their possible meanings | The expected value of the bits |
| Byte 1 | Bits 8-1 | CVR data field length | 00000100 |
| Byte 2 | Bits 8-7 |
| 10 |
| Bits 6-5 |
| NS | |
| Bit 4 | and failed 1 = Offline PIN verification performed | 0 | |
| Bit 3 | 1 = PIN Offline verification failed | 1 | |
| Bit 2 | 1 = terminal cannot send transaction | 0 | |
| Bit 1 | to the issuer (unable to go online) | 0 | |
| Byte 3 | Bit 8 | 1 = last online transaction not completed | X |
| Bit 7 | 1 = PTL exceeded | 0 | |
| Bit 6 | 1 = offline counters exceeded | X | |
| Bit 5 | 1 = new card | X | |
| Bit 4 | 1 = Issuer authentication failed on the last transaction | X | |
| Bit 3 | 1 = Issuer authentication failed after online authentication | 0 | |
| Bit 2 | 1 = App blocked by card due to PTL exceeded | 0 | |
| Bit 1 | SDA failed on the last transaction and the transaction was rejected offline | X | |
| Byte 4 | Bits 8-5 | The number of Issuer Script Processing commands processed in the last transaction | Oohx |
| Bit 4 | 1 = Issuer Script Processing failed on the last transaction | X | |
| Bit 3 | 1 = DDA / CDA failed on the last transaction and the transaction was rejected offline | X | |
| Bit 2 | 1 = offline dynamic authentication has been performed | 0 | |
| Bit 1 | Not used | 0 |
Therefore, to receive a CAP Token, the reader generates a data string shown in Fig. 6.3. The string is formed from the response of the card to the GENERATE AC command, to which the PSN data element is appended to the left, if required.
| ; psn | CID | ATC | AC | IAD |
| -_________ h A__________ | ||||
| 1 byte | 1 byte | 2 bytes | 8 bytes |
|
Rice. 6.3. Data used to generate CAP Token
Whether a PSN is attached is determined by bit 7 of the IAF. Now, in order to obtain the CAP Token value, the Issuer Proprietary Bitmap data object (IPB, Tag '9F56') is used - It is superimposed on the reader data line and the values of the bits opposite to the IPB '1' bits are extracted from it. The resulting binary sequence is represented as a decimal number, which is the CAP Token.
The structure of the IPB object, obviously, determines the data compression mechanism we discussed above. Bits '1' correspond to those bits of the string from fig. 6.3 to be included in the CAP Token object.
If there is no IPB data object in the application, the reader uses its default value stored in the reader and determined by the payment system.
It should be recalled that the above algorithm for calculating CAP Token is valid for all CAP modes except Mode 2 with TDS. When using this mode in the line from Fig. 6.2 instead of the AS cryptogram, the MAC value is used, formed according to the algorithm described earlier.
Table 6.6 shows the values of the CAP Token size depending on the number of bits included in the CAP Token of the main CAP parameters. Table 6.6 in the column "Number of CVR bits" there is a value of 0 for a dedicated application and 10 for a normal payment application (for example, a VSDC application).
Tab. 6.6. CAP Token size
| Number of AC bits | Number of ATC bits | DKI Bits | Number of PSN bits | Number of CVR bits | CAP Token size in numbers |
| 16 | fourteen | 5 | 5 | ten | 16 |
| 16 | fourteen | 5 | 5 | 0 | 13 |
| 16 | fourteen | 0 | 0 | 0 | ten |
| 16 | 7 | 0 | 0 | 0 | 7 |
| 16 | 7 | 0 | 0 | ten | ten |
| 12 | 7 | 0 | 0 | 0 | 6 |
The table shows that the CAP Token size is about 3 digits longer when using a regular payment application instead of a dedicated application.
It should be reiterated that payment systems in CAP / DPA programs recommend using a dedicated application. Note also that the personalization data of the dedicated application usually only takes up 400-500 bytes of EEPROM memory. This is due to the fact that when personalizing such an application, it is not required to store the data required for dynamic card authentication and occupying a significant amount of memory (offline authentication of the application by the reader is not performed).
There are several vendors of reader solutions on the market today, including Gemalto, VASCO, Xiring, TODOS, ActivCard and others.
As noted earlier, to implement the CAP method, the card application must support the PIN Offline cardholder verification method. More precisely, the card application data (CVM List) should determine whether the PIN code can be verified. However, not all applications support this method, and therefore they cannot be used when implementing the CAP method. As a result, MasterCard came up with the idea to develop an extension of the CAP protocol in such a way that it could be used for all EMV-compliant applications, regardless of whether they can verify the cardholder's PIN or not. As a result, a version of the CAP protocol appeared, conventionally called PLA (PIN Less Application). The PLA protocol functions similarly to the CAP protocol with the only difference that it does not require the client to enter a PIN code. Thus,
The new version of the M / Chip 4 (M / Chip 4 R2) standard provides the ability to change the cardholder PIN for a separate CAP application, used only for client authentication, in an isolated reader (unconnected PCR). Moreover, if the application supports the Encrypted PIN Offline method, the reader must use this method of cardholder verification.
So far, authentication of the smart card holder using a reader has been considered. Payment systems have long been studying the possibility of using a cell phone, the most massive means in the hands of the inhabitants of our planet, to authenticate their customers. One of the solutions in this area was proposed
MasterCard. This solution is called MasterCard Mobile Authentication (MMA) and is based on the use of the CAP protocol.
The solution can be used on cell phones supporting the Java 2 Micro Edition (J2ME) operating environment. The J2ME framework (especially when using the MIPD 2.0 profile) covers procedures for safely loading, activating, upgrading, and executing phone applications written in an abbreviated version of the Java language called MIDlets.
To implement the MMA protocol, an autonomous application (midlet) is loaded onto the phone, which implements the CAP algorithm in its distributed version (further we will understand that the MMA protocol is a version of the CAP, in which the client's PIN is checked not in the phone application, but indirectly on the server issuer). This appendix contains an encrypted card key for generating an application cryptogram. A double key (112 bits) is used. Below we will denote the key of the card for generating the applied cryptogram K AC .
To ensure the confidentiality of the K AC key during its transmission from the issuer's server and during storage on the phone, it is encrypted using the PBE (Password-Based Encryption) algorithm defined in the PKCS # 5 standard. The private key of the PBE algorithm (the 3DES algorithm is used for data encryption) is the client's mobile PIN (the client's PIN, used only for client authentication via a cell phone), padded with zero bytes on the right.
If it is necessary to generate a password, the client opens a midlet that implements MMA on his phone and enters his mobile PIN-code. Using the PIN-code value, the MIDlet creates a key to decrypt the K AC key and discloses it. Next, using this key, the MIDlet calculates the CAP Token value in accordance with the CAP algorithm described above. In this case, before calculating the CAP Token value, the MIDlet can ask the client to set the CAP protocol mode. When selecting Mode 1, Mode 2 with TDS, or Mode 3, the client will have to enter additional transaction data required by the MIDlet to calculate the CAP Token value.
The MMA algorithm implements two-factor client authentication: the client must have the issuer's midlet loaded on his phone along with the encrypted secret key K AC and must know the value of the mobile PIN-code.
If the client entered an incorrect value of the mobile PIN-code, then the decrypted value of the K AC key will be incorrect, and, therefore, the CAP Token value will not be successfully verified in the CTVS system.
The client has several attempts to enter the correct PIN-code value, after unsuccessful use of which the client is blocked in the CTVS system and further use of the MIDlet on his phone to authenticate the client will become impossible.
Note that the MMA protocol allows you to authenticate any client of any information system, including a bank client. At the same time, the client does not need to have a bank card. In the case of MMA, the phone simultaneously plays the role of a card and a reader!
6.1.4. Other IPC applications
Let's talk first about an application called Open Data Storage (ODS). Many users need a secure medium for their personal data, such as passwords, addresses, names of frequently used files, memorable dates, purchase details, etc. To do this, the ODS application is loaded onto the card.
The application has its own set of commands, such as: select a directory, create a file, get data, write data, delete data, check PIN, etc. In addition, there is an open application programming interface (API) for the ODS application, which is used computer programs to communicate with the ODS application.
An example of using ODS is a bonus scheme. On the POS terminal, you can implement an application that supports the open API to ODS, which, when the cardholder makes a purchase, will calculate the amount of the bonus based on the data on the transactions previously performed by the client and the characteristics of the current transaction. Data on previously processed transactions is stored on the card in the ODS application. The new bonus value can be written to the card with the same POS terminal application.
Another use case for ODS is surfing the Internet. Using a program installed on your computer, you can retrieve from the card memory the web addresses of sites that are popular with the card holder.
A card that supports the ODS application can be considered as a backup for storing personal and other data, usually contained in the cell phone or PDA of the card holder.
An important feature of the ODS application is that the card data is stored securely. To access this data, you need to know the value of the cardholder's PIN.
Both leading payment systems have developed specifications for open memory applications. In MasterCard, the ODS application was named MODS (MasterCard Open Data Storage), and in VISA - V3S (VISA Smart Secure Storage).
Loyalty programs implemented by joint efforts of banks and trade and service enterprises are popular in the world today. To implement such programs, a special loyalty application is placed on the bank card. After the payment application, the bonus application is the most common on bank cards.
Obviously, the IPC is a convenient tool for the implementation of loyalty programs, since it allows you to store information about the purchases of its holder, which is necessary for the terminal to calculate the amount of the bonus / discount offline without accessing the central database. This reduces the time and cost of performing operations using bonus schemes and increases their reliability.
The XLS (Extended Loyalty System) application from the Welcome company, which offers a comprehensive solution for the loyalty system on the market, has become very popular in the world. The XLS application is stored in the ROM of a number of leading card vendors. The XLS application allows real-time implementation of both the discount scheme received by the client during the next transaction, and the cumulative bonus scheme that the client can use to purchase goods and services in retail outlets participating in the bonus program. During the next transaction, the amount of the bonus increases depending on how long the client has used the trading network, how many times he has used it and how much money he spent in it.
An interesting step towards the implementation of loyalty programs has been taken by the MasterCard payment system. The new MasterCard specification for the payment application M / Chip 4 (M / Chip 4 R2) introduces the concept of integrated memory IDS (Integrated Data Storage), which allows the M / Chip 4 application to store data from other applications (for example, loyalty applications) accompanied by operators different from the bank. In this case, the terminal has the ability to read the data associated with the loyalty program (using the GET DATA command), and update them based on the results of the operation using the special PUT DATA command, executed outside the Issuer Script Processing procedure. It is important to understand that the terminal installed in a merchant participating in the loyalty program may not accept MasterCard cards.
In conclusion, we note that many non-payment applications can be successfully emulated by the EMV application. Indeed, the EMV application provides reliable data storage with ensuring the integrity of the most important static data, mutual authentication of the application and its issuer, offline dynamic authentication of the application, generation of a cryptogram of the operation, which is a proof of the fact of its execution, and, finally, the dialogue of an external system with a card in the language of a well-known a set of commands and responses to them.
Social applications (pension, transport, tax, medical, bonus, etc.) are popular in Russia. Virtually all of them can be implemented using the EMV application. Moreover, most of these applications do not require their offline dynamic authentication.
The only exception is sometimes a medical application, which sometimes requires offline authentication of an external system (for example, a doctor) at the very beginning of an operation. As we recall, the EMV standard does not provide terminal authentication. However, this disadvantage is easily circumvented. It is enough to load a special applet on a card that supports a social application (we assume that the card supports GlobalPlatform and Java Card), which performs two main functions. Firstly, the applet, based on the pre-deployed PKI infrastructure, authenticates the external system (for example, a doctor), and secondly, it prepares issuer scripts for the external system, which the external system uses to change the parameters of a medical application (for example, writes medical prescription data ).
The already familiar VSDC and M / Chip 4 applications, which are present on most bank cards, can be used as an EMV application. To use them as a tool for implementing social programs, you must first agree with the payment system - the owner of the rights to the payment application. In the case when, along with social applications, a payment application is also present on the card, reaching an agreement with the payment system is quite realistic.
We also note the simplicity of the technical implementation of the scheme described above. The point is that many card manufacturers implement applications
M / Chip 4 and VSDC in multi-instance mode. In this mode, one executable module can be used to implement multiple applications with their own AIDs and datasets. The multiinstance mode is an integral part of the card supporting the GlobalPlatform. Therefore, using different instances of the applet, it is possible to implement both a payment application and social applications on the card.
The use of the EMV application for emulating social applications opens up broad prospects for operators of social programs to use the developed infrastructure for accepting bank cards to implement these programs. This leads to significant savings in the implementation of social card programs.
