Forgery of the cryptogram type

Let’s focus on another type of fraud on the part of an unscrupulous merchant. In simplified form, fraud looks like this.
When a microprocessor card holder applies to a merchant for a purchase, the merchant completes any terminal/card decision by rejecting the transaction. In this case, the cardholder either leaves the merchant with nothing, or pays for the product in cash.
Next, the fraudulent merchant sends data on the unsuccessful transaction to the servicing Bank, as if the transaction was completed successfully in offline mode. In this case, the servicing Bank is presented with all the evidence that the transaction was completed successfully: a forged cryptogram Information Data value indicating the completion of the operation by generating the TC cryptogram card, and a cryptogram value that is transparent to the servicing Bank. The cryptogram type value is also contained in the CVR object passed to the Issuer in the Issuer Application Data object. Since the terminal does not consider the contents of the Issuer Application Data object (although it could), since this object is intended for the card Issuer, we assume that the CVR data object is transparent for the terminal.
The servicing Bank forms segments based on the data received from the terminal, which it sends to the payment system, and reimburses the merchant for the “performed” operations in it.
The Issuer that received the segment must check whether the value of the cryptogram type extracted by the Issuer from the data field of the CID object (Cryptogram Information Data, Tag ‘9F27’) corresponds to the value of the corresponding bits of the CVR cryptogram type extracted from the Issuer Application Data object (the CID and IAD objects are obtained by the Issuer from the DE 55 authorization request/clearing message). These values must match. In this case, the comparison should be based on the values of bits of the cryptogram type obtained from the CVR object, provided that the cryptogram check was completed successfully (the correct value of the cryptogram means, among other things, the integrity of the data of the CVR object). If the cryptogram is correct, but there is no correspondence between the cryptogram type values in the CID and CVR objects, the Issuer must accuse the merchant of distorting the transaction authorization result. If the cryptogram on the data received by the Issuer is not correct, and the cryptogram type values in the CID and CVR objects are the same,then a possible reason for the cryptogram verification failure is a distortion of the cryptogram type value by the merchant.

In both cases, the Issuer has a reason to start an investigation on the result of the transaction completion, which may result in the Issuer’s refusal to pay (sending a chargeback message by the Issuer).
The Bank/payment system will take time to deal with the fraudulent enterprise. During this time, the fraudulent enterprise will be able to escape, which is what the fraudsters expect.
A more effective way to combat the fraud described above is to use the CDA method for offline authentication of the card application and approve a requirement for the merchant that the enterprise must provide the Signed Dynamic Application Data element and the card’s public key certificate, rather than just a cryptogram, to the servicing Bank. In this case, the servicing Bank extracts the correct value of the Cryptogram Information Data object from the Signed Dynamic Application Data element, and the fraud scheme described earlier stops working.
Summarizing the above, we can conclude that with the increase in the number of microprocessor cards and the expansion of their reception infrastructure, the level of card fraud (not the volume!) it will steadily decline. The use of microprocessor technology has proven its effectiveness in the fight against card fraud. The markets of great Britain, France, Luxembourg and Belgium, which have almost completely migrated to chip card technology, are a clear example of this.
From the point of view of technology development, payment systems implement a policy aimed at increasing the security of card transactions as much as possible. Depending on the current state of maturity of the card market, proactive decisions are made to reduce the level of card fraud. These solutions include the latest steps aimed at expanding the use of reliable card authentication methods and the use of PIN Offline on cards and terminals, optimizing the rules for switching to alternative magnetic stripe authorization, and so on.
At the same time, it is obvious that criminal structures will not accept the loss of income from card fraud and will adapt to the new conditions of life in the world of chip cards. Unfortunately for banks, fraudsters still have a lot of opportunities.
The most serious gap for the technology of microprocessor cards is the lack of synchronicity and proper speed of migration of banks on the chip. Even if the banks of a country migrate completely to the chip, but there are countries where the migration process is slow, the banks that migrated to the chip will continue to suffer financial losses. Therefore, European countries that have achieved significant results in migration to the chip, can not but be concerned about the situation in some regions, and especially in the largest market for plastic cards — in the United States. Indeed, all the efforts of the European Bank that issued the card microprocessor, will be void the ability to perform operations on a fraudulent card made on the basis of data from the magnetic strip to microprocessor cards in the “magnetic” terminal American Bank. Here, payment systems would have to act more rigidly and decisively, managing shifts of responsibility within and between regions, forcing banks to implement interbank commissions, the size of which depends on the ability of participants to support microprocessor technology.

Key management
Key management issues for the EMV microprocessor card are discussed in sections 10 and 11 of Book 2 of the EMV 4.2 standard. Significant attention is paid to the implementation and maintenance of the PKI infrastructure in these sections. The PKI infrastructure is an integral part of the payment system that works with EMV cards, and an important element that allows you to ensure a high level of security for transactions performed using microprocessor cards. Offline card authentication methods are based on the PKI infrastructure.
The payment system certification authority (CA) is controlled by the payment system and is intended for calculating public key certificates of system issuers. CA public keys are sent to service banks to verify the Issuer’s key certificates. Verification of the Issuer’s key certificate is performed during transaction processing during offline card authentication and PIN block encryption.
In addition, the Issuer can use the system key for one-time verification of the certificate of its public key obtained from the CA.
To exchange information between the Bank and the CA, you must install a secure channel that eliminates the possibility of forgery — providing the system’s public keys and the Issuer’s key certificate from a false system certification authority. In other words, the procedure for transferring the system’s public keys or the Issuer’s key certificate to the Bank must ensure the authentication of the payment system’s certification center and the integrity of the information transmitted by it.
It is necessary to pay special attention to the issue of protection against entering false system keys into the terminal application. When entering false keys in a certain terminal, fraudsters can personalize cards with these system keys and use them in terminals with previously loaded false system keys.
Each public key of the system has an expiration date, after which it must be withdrawn from use. This procedure is called the key revocation procedure. Revocation of the key may be planned (after the expiration of the system key) and accelerated (for example, due to key compromise). In the second case, the payment system notifies its participants about the change in the key validity period. Servicing banks are required to revoke system keys in all their terminals within 6 months from the date of expiration of the key.
All public keys in the system expire on December 31. If the key is revoked, the date may be different (not December 31), since the key’s validity period changes. However, the six-month period provided by the payment system to the servicing banks for revoking the key from the terminals remains in this case.
The system certification authority must distribute the new public keys of the system by January 1 next year. After that, the servicing banks must upload the new system keys to their terminals within 6 months, i.e. by June 30 of the following year.
Payment systems allow using new system keys in terminals only from January 1, despite the fact that the keys can be delivered to banks before January 1. At the same time, the payment system starts using the new system keys to create the Issuer’s public key certificates no earlier than June 30 of the same year.
Payment systems require that the validity period of all certificates used for offline card authentication and PIN block encryption, if such a key is used, be longer than the card’s validity period. This is necessary in order for the hybrid card to be able to perform a transaction on the chip during its entire lifecycle.
It is necessary to pay special attention to the issues of secure key storage in the Issuer’s system. In General, the Issuer’s system stores the following types of keys intended for IPC issuance:
IMKAC-key for generating the master key of the MKAC card, intended for output of the session key for generating application cryptograms;
IMKSMI-key for generating the master key of the IMKSMI card, which is intended for output of the session key used to ensure the integrity of data transmitted in the command and authentication of the data source;
IMKSMC-key for generating the master key of the MKSMC card, which is intended for output of the session key used to ensure the confidentiality of data transmitted in the command;
IMKIDN-key for generating the master key of the MKIDN card, intended for calculating the value of the ICC Dynamic Number;
IMKDAC-key for generating the master key of the MKDAC card, intended for calculating the value of the DAC (Data Authentication Code);
the Issuer’s key used for calculating the card’s public key certificates.

Compromising, for example, the Issuer’s key used when performing offline card authentication, leads to the possibility of creating a card that successfully authorizes transactions in offline mode. The EMV V. 4. 2 standard does not pay attention to the distribution of CRL sheets (certificate revocation sheets) to servicing banks) if the Issuer’s keys are compromised. These issues should be reflected in the operating rules of specific payment systems.
It is necessary to study the issue of the Bank’s reaction to the case of compromising its keys. The study should start with defining the settings for the card’s risk management parameters. For example, to prevent compromise of any symmetric key of a card that supports offline dynamic authentication, it is useful to set the Offline Dynamic Authentication Failed bit in the Card Issuer Action Code — Offline and Card Issuer Action Code — Online objects to 1. This will prevent the successful completion of operations using cards with compromised symmetric keys in offline mode and control the issue of compromising the Issuer’s keys and its cards on the Issuer’s host. Indeed, without knowing the asymmetric key of the card, the fake card will fail its dynamic authentication procedure, and the terminal will send the authorization operation to the Issuer, which, if it knows about the fact of compromising its symmetric key, will reject such a transaction.
Of course, the Issuer can act more radically and reliably by setting the Offline Dynamic Authentication Failed bit in the Card Issuer Action Code — Decline object to 1, thereby declaring the failure of dynamic card authentication sufficient to reject the operation. However, in this case, the card’s availability in the payment system’s terminal network may be limited. We have already mentioned the reasons for this restriction: the absence of the system key on the terminal that was used to certify the Issuer’s key, errors in the terminal application (for example, the terminal did not present a random number to the card), and so on.

Choosing the IPC hardware and software platform and its application configuration
The choice of the hardware and software platform of the microprocessor card and the configuration of its application is largely determined by the tasks formulated by the Bank’s business in its card programs. Here are a few examples to illustrate this.
If the Bank plans to use prepaid cards, it seems that most operations on such cards will be performed offline. Therefore, to avoid the possibility of fraudsters cloning SDA cards, we recommend using chips that support dynamic authentication methods for a prepaid card. Despite the fact that a card that supports dynamic authentication methods costs 30-40 cents more than a card without a cryptographic coprocessor, it makes sense to use a DDA/CDA card as a prepaid card to ensure the security of operations.
The second example is an innovative Bank that offers its clients a set of different services, including not only performing standard payment operations on the card, but also implementing loyalty schemes, client authentication methods, and so on. In such cases, it makes sense to think about using cards that support multi-layer operating systems, such as Java Card or MULTOS. Using such cards will allow the Bank to ensure the necessary level of security of data related to various applications, remote download of new applications to the card, and rapid development and implementation of new applications.

In this case, special requirements are imposed on the card characteristics. This is especially true for the size of the EEPROM memory, which should be able to store data from the multi-layer operating system and applications, as well as program codes for some downloaded applications. For example, when using a GlobalPlatform / Java Card, you should select a chip that has at least 16 KB of EEPROM memory.
Another example is a Bank that is simultaneously a member of the two largest payment systems VISA and MasterCard. In December 2005, EMVCo released the Common Payment Application (CPA) standard, which describes an application that is simultaneously supported by both leading payment systems. A Bank that has chosen the CPA application as a universal payment application, in addition to expanding the functionality of its cards in comparison with the case of using the m/Chip 4 and VSDC applications, makes it easier for itself to solve the problem of risk management and personalization of microprocessor cards, as well as unifies transaction processing on its host in both payment systems.
Finally, the last example is the introduction of a Bank card for quick customer service, for example, in a fast food restaurant or when paying for a toll road or subway. In this case, the Bank may consider using contactless cards.
Thus, if we try to generalize, the Bank’s task statement for choosing its card should include:
list of applications supported on the card and application requirements for card resources (memory, security, operation speed);
the need to develop and implement new applications that can function in the card operating environment;
need to download apps after the card is released;
terms of use of the card (in particular, restrictions on the time of operation, the typical size of the transaction, conditions for accepting the card — for example, only online authorization or only offline, working through a contact and / or contactless interface, etc.);
security requirements for transaction processing;
availability of payment system certificates confirming that the card and the card application meet the requirements of payment systems.

Today, the Bank has a large set of cards from various manufacturers. The EEPROM memory of Bank cards varies from 2 to 72 KB. The size of rewritable memory 16, 32, 64 KB is not surprising for anyone today. The ROM memory of most cards contains applications from both leading payment providers, as well as numerous additional applications — MODS, CAP/DPA, PSE, some kind of loyalty application, and so on.
Applications of leading payment systems are implemented with support for the CPS specification, which makes it easier to personalize them. In addition, the executable software modules of these applications often run in multi-instance mode, which allows you to implement multiple applications using a single software module. For cards that support the GlobalPlatform platform, the ability to use multiinstance mode, where multiple applications can be implemented using a single applet, follows from the GlobalPlatform properties.
In order to save EEPROM memory on cards, as well as for reasons of correlation between the functionality of some applications, the data sharing mode is used by several applications. Shared data can include the value of the PIN code, PTC counter, and PTL limit, as well as application keys, ATC and LATC transaction counters, and so on.
More and more cards with EEPROM memory of more than 16 KB are GlobalPlatform/Java Card cards. These cards open up opportunities for the Bank to implement new applications, not only during the card personalization process, but also after the card has been issued to its holder.
The list of questions to answer when selecting a specific card should include:
the cost of the card for the volume of purchases that the Bank is interested in;
list of applications supported by the card;
application functionality:
supported authentication and verification methods for the cardholder;
card application data that can be passed to the Issuer during the transaction;
parameters of the card application that can be changed using the issue Script Processing procedure.
It should be understood that compliance of the card application with the payment system specifications does not mean that the application supports all the functionality defined in the specification;
type of card operating environment: static (native) or multi-layer;
the main parameters of the microprocessor: the size of the EEPROM, RAM, bit rate and clock speed of the processor, interface types-contact/contactless (these parameters have the greatest impact on the speed of the card operation and at the same time on the cost of the card);
speed of read/write operations, PIN verification, RSA algorithm for the key module sizes of interest, 3DES algorithm, random number generation;
availability of tools for developing new applications;
support for secure app loading after card release, such as GlobalPlatform;
possibility of” standard ” personalization of applications, for example, by means of CPS or already developed personalization scripts used in the native operating environment of the card;
supported communication interfaces and protocols, as well as data transfer rates;
physical security features implemented on the card chip (countermeasures against SPA/DPA, DFA and Timing attack attacks, various sensors and filters to deal with power surges, clock frequency surges, etc., encryption of memory and data transmitted in data buses and addresses, etc.);
availability of a payment system certificate for compliance of the card’s payment application with the payment system’s specifications;
availability of security certificates for the card and its operating environment according to the Common Criteria and/or ITSEC criteria.

If there are answers to these questions, the specialist is able to assess the possibility of implementing the Bank’s tasks using the card in question. Sometimes you can do this by testing the card for future use. In other cases, analytical and statistical modeling of the card operation is possible. Knowing the card parameters such as the speed of read/write operations, PIN verification, RSA and 3DES algorithms, the speed of data transfer between the card and the terminal, as well as having an understanding of the operating indicators of the terminal, you can get an estimate of the transaction execution time.
Note that the most critical parameters of transaction processing time on the card side are the speed of implementation of the RSA algorithm and the speed of data exchange between the card and the terminal. To illustrate this, consider a CDA card that uses a public key for offline authentication with a module length of 1024 bits. In this case, we assume that the card Issuer has a public key with a module length of 1536 bits, and its certificate is made on the system key with a module size of 1984 bits.
In the case of a CDA card, when online authorization is performed and the transaction is approved by the Issuer, the card signs the data twice in order to authenticate itself and ensure the integrity of the information exchange between the card and the terminal. If the card supports the Encrypted PIN Offline cardholder verification method, it signs the data using the RSA algorithm three times. Assuming that the signature time on the long exponent is 150 MS, the card will take about 0.45 seconds to create Signed Dynamic Application Data and decrypt the PIN block.
Now let’s estimate the amount of data transmitted by the card to the terminal. The card must transmit to the terminal the Issuer’s key certificate (in order of size 2 KB), the card’s key certificate (in order of size 1.5 KB), and twice Signed Dynamic Application Data (in order of size 2 × 1 KB). In addition, the terminal transmits the value of the signed PIN block to the card (in order of size 1 KB). Thus, the lower estimate of the transmitted data is 6.5 Kbits. Assuming that the speed between the terminal and the card is 9600 bits / s and the communication Protocol T = 0 is used, which requires 12 bits of information to transmit one sign, we will get that it will take at least 1.02 seconds to transmit only the listed data.

Impact of migration on the Issuer’s system
To service microprocessor cards, the Issuer host must support a number of additional features compared to the magnetic stripe card Issuer host. These additional functions relate to both the authorization request processing system and the Issuer’s back-office system, which is responsible for processing clearing files and card personalization.
Additional functions for processing authorization requests in the Issuer’s system include:
output of the master keys of the MKAC, MKSMI, MKSMC, MKIDN, MKDAC card from the Issuer’s keys;
output session keys from the card keys for generating cryptograms, calculating MAC values, and encrypting confidential data;
verification of the cryptogram ARQC/TC;
checking the DAC and/or IDN values to confirm that the terminal has performed offline static or dynamic card authentication;
analysis of data received by the Issuer from the Issuer Application Data objects (CVR, values of offline card counters, DAC/IDN, other data defined by the Issuer in the Issuer Discretionary Data of the IAD object), TVR (Tag ’95’), CVM Results (Tag’ 9F34’) and making a decision on how to complete the transaction based on the results of this analysis;
checking whether the value of the cryptogram type received by the Issuer from the data field of the CID object (Cryptogram Information Data, Tag ‘9F27’) corresponds to the value of the corresponding bits of the CVR object cryptogram type extracted by the Issuer from the Issuer Application Data object (the CID and IAD objects are received by the Issuer from the DE 55 authorization request / clearing message). These values must match. In this case, the comparison should be based on the values of bits of the cryptogram type obtained from the CVR object, provided that the cryptogram check was completed successfully (the correct value of the cryptogram means, among other things, the integrity of the data of the CVR object). If the cryptogram is correct, but there is no correspondence between the cryptogram type values in the CID and CVR objects, then the Issuer must accuse the merchant of distorting the transaction end result
we recommend analyzing the Issuer Script Results data object, if this object is passed to the Issuer, so that the Issuer understands which Script Processing commands were executed successfully and what the current state of the card’s risk management parameters is as a result;
to prevent re-submission of the transaction, it is important for the Issuer to monitor the ATC value for each card and link other time-dependent parameters (more precisely, the transaction number) to the ATC, for example, ICC Dynamic Number;
the Issuer of a MasterCard chip card is recommended to reject transactions in which DE 061 (POS Data) indicates that the terminal can perform an operation on the chip, but conducts it along the magnetic stripe and the POS Entry Mode (DE022) is not equal to 80x (fallback case);
the VISA chip card Issuer is recommended to reject transactions that simultaneously meet the following conditions:
DE22. 1 = “90” or” 02” (magnetic stripe read);
DE60. 2 = ” 5” (chip capable terminal);
DE60.3 ≠ “1” (Fallback. No info about chip read error on the previous transaction in that terminal) or “2” (and Fallback. There was chip read error on previous transaction in that terminal), which indicates that the terminal can perform an operation on the chip, but conducts it on the magnetic stripe;
to combat fraud related to the unjustified use of the fallback mode on the magnetic stripe, the Issuer is recommended to control the number of operations performed in this mode for each card;
it is advisable to use different transaction processing modes in different situations: for example, all international transactions can be made online due to the appropriate selection of card risk management parameters, since it is international transactions that have the highest level of card fraud;
preparing data for a response to the servicing Bank (field DE 55): Issuer Authentication Data, including the ARPC cryptogram, and the Issuer Script Processing Template blocks.
Note that both the authorization request and the clearing message do not contain a field for transmitting the Issuer Script Results data object to the Issuer. To pass this object, you can use the Issuer Discretionary Data section of the Issuer Application Data object. To do this, the card application must support this function (today known implementations of VSDC and M/Chip 4 applications do not support it), which means that t < 0.036 seconds, i.e. the performance of HSM should have been higher than 27.7 cryptographic operations of 3DES. Thus, when migrating to the IPC while maintaining the input traffic, the minimum allowable performance of the HSM module is more than 3.6 times higher than the same indicator for a system that processes operations on magnetic stripe cards.

Impact of migration on the system of the servicing Bank
Migration to microprocessor cards has less impact on the host of the servicing Bank than on the host of the Issuer. The servicing Bank must upgrade its host application’s device management software modules in order to ensure that chip related data is received from the terminal and sent to the Issuer’s host without meaningful processing of this data. To transmit chip-related data to the Issuer’s host, a de 55 composite data element is used, specifically designed for the purposes in question in ISO 8583 messages.
The minimum set of chip data transmitted in the authorization request/clearing message from the servicing Bank to the Issuer. This data set can be expanded at the discretion of a particular payment system. The servicing Bank can optionally add CVM Results, Terminal Capabilities, Terminal Type, and so on to this data.
Note that the leading payment systems are completing work aimed at making the DE 55 data element mandatory in the clearing messages of the servicing Bank. The servicing Bank must store cryptograms of operations performed in its devices and present them at the request of the relevant issuers.
During transaction processing, the terminal can transmit different values of the random variable Unpredictable Number to the card at different stages of the operation. The authorization request must contain the value of this value contained in the data of the first GENERATE AC command. The clearing message must contain the last value of the Unpredictable Number received by the card from the terminal. The servicing Bank receives this value from the terminal.
The minimum set of chip data that should be contained in the Issuer’s response to the authorization request.

Minimum set of chip data in the authorization request and clearing message

Item number the name of the Tag Format Length bytes
1 Application Cryptogram (TC/ARQC or AAC) ‘9F26’ 8 b
2 Cryptogram Information Data ‘9F27’ b 1
3 Issuer Application Data (IAD) ‘9F10’ b Var. up 32
4 Unpredictable Number ‘9F37’ b 4
5 Application transaction counter (ATC) ‘9F36’ b 2
6 Terminal Verification Result ’95’ b 5
7 Transaction Date ‘9A’ n 3
8 Transaction Type ‘9C’ n 1
9 Amount, Authorized ‘9F02’ n 6
10 Transaction Currency Code ‘5F2A’ n 2
11 Application Interchange Profile ’82’ b 2
12 Terminal Country Code ‘9F1A’ n 2
13 Amount Other ‘9F03’ n 6

Minimum set of chip data in the Issuer’s response to the authorization request

Data element number
Format Length, bytes
1 Issuer Authentication Data ’91’ b from 8
up to 16 Provides the data required by the card to authenticate the Issuer
2 Issuer Script Template 1
Template 2
’72’ b to 128 Allows the Issuer to send commands to the card