Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
Card authentication (more precisely, card application) is a key element in ensuring the security of card transactions. Only solutions and data from a proven card can be trusted. Card authentication is an effective means of combating such type of fraud as counterfeit cards (see clause 6.6.1).
Let us briefly recall the general information about card authentication methods. Card authentication methods are divided into offline and online. The latest version of the EMV standard (v.4.2) distinguishes between three offline card authentication methods:
The SDA method ensures the integrity of the application-critical static data, as well as the impossibility of creating a card from a "white sheet". During static authentication, the card transmits to the terminal for verification the Signed Static Application Data value, which is a signature of critical static application data and, in its essence, is a chip analog of the CW / CVC values used to ensure the integrity of the card number, service code and period stored on the magnetic stripe of the card. actions. An example of a list of critical data recommended for signing is shown in Table. 3.14.
Dynamic card authentication methods (DDA and CDA) consist in the terminal verifying the signature calculated by the card provided to the card by the terminal (with the obligatory use of a random number generated by the terminal) in accordance with the DDOL list stored on the card. In this case, the successful result of card authentication guarantees, at the level of cryptographic strength of the RSA algorithm, the fact that the card contains a chip personalized by the issuer authorized by the payment system to issue cards of this system. To implement dynamic methods of card authentication, the microcircuit card must support the RSA algorithm, which in turn requires a special cryptographic coprocessor in the microcircuit and therefore increases the cost of the card.
The CDA method, in addition to dynamic card authentication, additionally ensures the integrity of the most critical data of information exchange between the card and the terminal (CID, transaction and terminal details). This is achieved by combining the card authentication procedure with the processing of the GENERATE AC command, during which the most important data for making a decision on how to complete the transaction is exchanged between the card and the terminal. As a result, the card signs a dataset that includes the hash value from the data circulating between the card and the terminal during the processing of the GET PROCESSING OPTIONS and GENERATE AC commands.
Another advantage of the CDA method is the reduction in the processing time of the operation (on average by several tens of milliseconds) compared to the case of using a card that supports the DDA method to process the same operation. This reduction in time in the case of using the CDA method is due to the absence of a separate INTERNAL AUTHENTICATE command during transaction processing, which is used to authenticate the card application in the DDA method.
The choice of the offline authentication method is made by the terminal based on the AIP data object (Tag '82') and the terminal capabilities determined by the value of the third byte of the Terminal Capabilities element (Tag '9F33').
Payment system rules require payment system applications on the card to support the online authentication method and the offline authentication method. At the same time, from the point of view of offline authentication, applications must support at least the SDA static authentication method. Starting from January 1, 2011, new cards issued by banks in the MasterCard Europe and VISA Europe regions must support the DDA method (in France this solution has been effective since January 1, 2007). At the same time, new cards should not support the SDA method (bit 5 of byte 1 of the data field of the AIP object is 0, and the card does not have a Signed Static Application Data object).
Moreover, VISA Europe prohibits issuers from using SDA cards from January 1, 2015.
At the end of 2008, in countries such as Belgium, Norway, Italy, Portugal, Great Britain, almost all issued cards support only the SDA method (they are SDA cards). In contrast, France and Switzerland are dominated by (over 80%) DDA cards.
For individual transactions, the offline authentication mechanism of the card application may not be used. This, for example, applies to transactions from ATMs, which are processed online, and therefore use mutual online authentication of the card and the issuer.
Offline authentication is also not used in cardholder authentication operations in CAP / DPA programs. According to the VISA and MasterCard rules, offline authentication may not be used in all operations performed from terminals that process transactions only in online mode (Online Only terminals).
At the time of this writing (end of 2009), according to VISA and MasterCard rules, all chip terminals in the world must support offline SDA and DDA card authentication methods (in Europe, this rule has been in effect since January 1, 2005).
Effective January 1, 2011, all new offline capable terminals in MasterCard across all regions must support the CDA method. According to EMVCo, at the beginning of 2009, more than 70% of terminals that have passed Approval Level 2 certification support CDA. Thus, from now on, all new offline capable MasterCard terminals will support all three methods of offline card authentication. So far, nothing is known about a similar VISA solution.
The decision on mandatory support of the CDA method by the commissioned MasterCard terminals means that CDA cards of this system, after some time required for all MasterCard terminals to support this method, may not support the method.
DDA. Today this support is required, as not all terminals support CDA.
As previously explained, dynamic authentication methods automatically include static authentication functionality (ensuring the integrity of critical static application data), which is implemented as part of the card's public key certificate validation procedure. Therefore, the MasterCard payment system allows its DDA card issuing banks not to support the SDA method. The VISA payment system, for reasons of ensuring high quality of card acceptance, allows its banks to refuse to support the SDA method on DDA cards in the VISA Europe region only from January 1, 2011. From that time, all new cards in the VISA Europe region must not support SDA. Starting from 2015, all VISA Europe bank cards must only support the DDA method and / or optionally CDA.
Since the issuer learns about the result of card authentication from the TVR data ultimately received from the merchant, the EMV standard provides for a mechanism for the issuer to verify that the terminal has completed the card authentication procedure. This mechanism protects the issuer from unscrupulous merchants / service banks claiming through the TVR data object that the card has been authenticated when the terminal has not actually authenticated it.
The reason for this deception may be the unwillingness of the serving bank / merchant to upgrade the terminals to support the RSA algorithm used for card authentication. Support for the RSA algorithm requires additional costs for upgrading the terminal. These costs are associated at least with changes in the terminal software, and often with the modernization of its hardware platform. To support RSA, the terminal must have a sufficiently powerful processor (preferably a 32-bit RISC processor) and / or a cryptographic coprocessor in order to quickly (about 1-3 seconds) perform the procedures for verifying certificates of the issuer and card, as well as the Signed Dynamic Application element Data. To perform these checks, a software implementation of the RSA algorithm can be used.
A cryptographic processor is required when the terminal supports the Enciphered Offline PIN cardholder verification method. In this case, the PIN-block is encrypted, which, in accordance with the requirements of payment systems, must be performed by specialized processors. Typically, such a cryptographic processor is implemented within a special PIN-PAD device.
Another reason for the merchant's refusal to perform card authentication is as follows. The merchant is interested in serving the customer, especially not caring about the reliability of his authentication. If the formal rules of customer service established by the payment system are met, the issuer is responsible for the result of the operation. The servicing bank in this case is guaranteed to receive a refund for servicing the cardholder.
The mechanism for checking by the issuer that the terminal has performed the card authentication procedure is as follows. When describing card authentication methods, it was noted that the terminal can store Data Authentication Code (DAC) values in case of static authentication and ICC Dynamic Number (IDN) in case of DDA / CDA in data objects with tags '9F45' and '9F4C', respectively. If the issuer includes the values of these tags in the CDOL1 and CDOL2 lists, then the card receives the DAC and IDN values when it processes the AC GENERATE command. The resulting values can be sent by the card to the issuer in the Issuer Application Data object.
In the case of an online transaction, the issuer can verify the fact that the terminal has authenticated the card during the authorization of the transaction and, based on the verification data, decide on how to complete the transaction. In the case of an offline transaction, the fact that the terminal has performed card authentication is verified by the clearing message received by the issuer. If a dispute arises over a certain payment transaction, the issuer can use a negative result of checking the DAC or IDN values to initiate a non-compliance case (refusal to pay) in the payment system.
Thus, for the issuer to verify that the terminal has performed card authentication, it is necessary:
For a prepaid card application, verification by the issuer of the fact that the terminal has performed card authentication is especially relevant, since offline card authentication is the main mechanism for ensuring the security of transactions with such cards.
Along with offline authentication, all cards and on-line-capable terminals are required to support the so-called online card authentication or, as it is sometimes called, Online Mutual Authentication. The idea behind mutual authentication is that the card and the terminal authenticate each other using the ARQC and ARPC cryptogram validation mechanism. Cryptograms are cryptographic values generated using the card's secret key, transaction number, a random number generated by the terminal, as well as some details of the transaction, terminal and card. In the case of ARPC, the issuer's authorization response code is also added to the listed data. Without knowing the secret key of the card for generating the cryptogram, it is impossible to calculate the ARQC / ARPC values,
Online authentication is the most secure way to authenticate a card. This is due to the fact that it is carried out directly by the issuer, without an intermediary in the form of a terminal. In addition, for online authentication, the 3DES algorithm is used with a double key of 112 bits, the cryptographic strength of which corresponds to the cryptographic strength of the RSA algorithm with an asymmetric key modulus used for offline authentication of the card application of more than 1700 bits. The use of asymmetric keys of this length on a card is still quite rare. Typically, keys with a modulus of 1024, 1152, or 1408 bits are used.
Due to the high reliability of online authentication, payment systems allow on bank terminals that process transactions only in real time (on-line only terminals: ATMs and some POS terminals) not to support offline card authentication procedures.
From the above, it follows that from the point of view of ensuring the security of card transactions, the most reliable method of offline authentication is CDA. Next, in decreasing order of reliability, are the DDA and SDA methods. It is this priority scale that the terminal uses when choosing the highest priority authentication method supported by the card and the terminal at the same time.
The SDA method does not protect the IPC from cloning its chip in order to use the cloned card in offline operations. Cloning of an IPC chip is understood as the procedure for fraudsters to create an analogue of a bank card (based on the data of a real card issued by a certain bank of the payment system) for the purpose of unauthorized use of this analogue in the terminal network of the payment system using chip technology.
At the same time, the chip terminal cannot establish the fact that the card is cloned under certain conditions (in the case of processing a transaction in offline mode), which allows fraudsters to make payment transactions, damaging the card issuer on the basis of which the cloned card was created.
To clone an SDA-card, you just need to have a microprocessor card with a programmer for it and be familiar with the EMV standard. Knowledge of the EMV standard is required to develop a card application that meets the requirements listed below.
The application supports the SELECT, GET PROCESSING OPTIONS, READ RECORD commands in a standard way. In response to the VERIFY command, the application always responds by confirming that the cardholder's PIN is correct, regardless of the value entered by the cardholder during the operation.
In response to the GENERATE command, the AC card responds as follows:
After placing an application with the properties described above on the card, the pre-stolen personalization data of the real SDA card is loaded onto the IPC, including the FCI Template ADF file of the application, AIP, AFL and file records, the identifiers of which are defined in the AFL. Linear file data includes a Signed Static Application Data object, which is the critical card data signed by the issuer.
Theft of real card data is carried out in a standard way (in exactly the same way as it is done for cards with a magnetic stripe) in appropriately prepared POS terminals (terminals that store the data of the cards used in them) or special devices - skimmers.
When purchasing 100 microcontrollers and a programmer for them, the cost of cloning 100 cards is about $ 500-1000 or $ 5-10 per card.
Suppose now that the fraudsters got hold of the data of a real card that supports offline dynamic authentication and the SDA method. Real card data was obtained by fraudsters when using the card in a terminal that implements only the SDA method (the terminal can be specially configured by the fraudsters to support only the SDA method). In this case, fraudsters can clone such a card, transferring the same application data of a real card to the IPC blank, which is used when cloning an SDA card.
Obviously, if the card cloned in this way is used in a terminal that supports only the SDA method, then the fraudsters have every chance of success, provided that the terminal approves the transaction in offline mode (the terminal asks for the TC cryptogram in the GENERATE AC command). That is why payment systems require DDA method support by all offline capable POS terminals. As noted, terminals that process transactions only online may not support offline card authentication at all.
The following question arises: "Is it possible to clone a DDA / CDA card to a card with static authentication when using the cloned card in a terminal that supports DDA / CDA dynamic authentication methods?" The issue is relevant given the fact that all today's terminals must support the DDA method and the trend of migration of cards to cards that support the method of dynamic offline authentication.
The answer to this question is generally negative, because to clone a DDA / CDA card, you need to know the secret key of the card.
At the same time, in some cases, if the card is incorrectly personalized, cloning of the DDA / CDA card is possible. If the DDA / CDA card supports the SDA method and does not store an SDA Tag List data object, then the card can be cloned! Indeed, having at its disposal the open card data (data communicated by the card to the terminal when processing an operation in a terminal that supports only the SDA method), they can be transferred to the cloned card by changing the data field of the AIP object. The change consists in the fact that in the first byte of the data field of the AIP object, bits 2 and 6 must be set equal to 0, and bit 7 equal to 1. Thus, the card informs the terminal that it only supports the SDA method.
In this way, a cloned card can be successfully used by fraudsters when processing a transaction offline. Indeed, in this case, the terminal will always choose the SDA method to process the operation on the cloned card. In this case, the modification of the AIP object will pass unnoticed for the terminal, since the AIP object does not fall into the list of signed data, the integrity of which is checked as part of the card authentication procedure using the SDA method. Let us remind the reader that the AIP data object (Tag '82') can be included in the list of signed data only if the SDA Tag List object is supported by the card.
Therefore, if the card application simultaneously supports offline dynamic and static authentication, the SDA Tag List object must be present among the personalization data of the application! Otherwise, the DDA / CDA card can be cloned.
It's funny that the presence of an SDA Tag List object on a DDA / CDA card, which also supports the SDA method, is still not a mandatory requirement in M / Chip Select 4 and VSDC applications.
To avoid cloning a DDA / CDA card without thinking about personalizing the card, given that all offline-capable POS terminals must support the DDA method, you can follow the following recommendation. The DDA / CDA card must not support the SDA method (the functionality of the SDA method, i.e. ensuring the integrity of critical application data, is supported during the card key certificate verification process). In particular, the card must not contain a Signed Static Application Data object. In this case, even if the card does not contain an SDA Tag List element, it is impossible to clone it to the SDA card, since the required issuer data - the Signed Static Application Data object - is missing.
Despite the fact that a DDA card, when properly personalized, does not allow cloning, it does not ensure the integrity of information exchange between the card and the terminal. As a result, attacks called "two-chip attacks" are possible and consist of the following. A printed circuit board is used that contains two chips: one is a banking chip and the other is an intermediary chip. A bank chip is a microchip that implements a bank payment application that supports the DDA method and is personalized by the bank. The intermediary chip controls the exchange of data between the bank chip and the terminal, modifying it if necessary. It is this chip that is inserted into the terminal's reader and exchanges information with it. It analyzes the data of the terminal commands, as well as the card's responses to these commands, and, if necessary, modifies them in a way beneficial to the fraudster.
Here are the simplest examples of possible data modification. If the terminal in the GENERATE AC command requested the TS cryptogram, and the card represented by the banking application decides to process the transaction online or reject it offline, then the intermediary chip changes the unprotected Cryptogram Information Data in such a way that it turns out that the bank chip responds to the terminal with the TS cryptogram. Thus, the transaction is approved despite the fact that by the decision of the card, delegated to it by the issuer, it must either be rejected or transferred to the issuer for authorization.
Another example. The intermediary chip, having received the value of the transaction size from the terminal (for example, € 2000), changes it to the value at which the card is ready to approve the transaction offline (for example, € 20).
Such an intermediary chip is called wedge device in the literature. The wedge device can be implemented not only in the printed circuit of a plastic card, but also on the side of the POS terminal. The main thing is that the device acts as an intermediary for information exchange between the card and the terminal.
The problem of ensuring the integrity of information exchange between the card and the terminal is solved by using CDA cards. Such cards include CID objects, ICC Dynamic Number, cryptogram (TC or ARQC), Transaction Data Hash Code and Unpredictable Number objects in the data signed by the card (see n. 3.12.2.2). The Transaction Data Hash Code element is a hash function of information circulating between the card and the terminal during the processing of the GET PROCESSING OPTIONS and GENERATE AC commands.
Therefore, it is impossible to modify information exchange in a way that is imperceptible for the terminal.
CDA cards have several weaknesses. First, as noted in clause 3.16.3, the size of a CDA card key module under certain circumstances may not exceed 205 bytes. Today, this limitation is not onerous, since mostly smaller card keys are used. However, this limitation may become sensitive in the future. Payment systems have already begun distributing their 248 byte keys, allowing issuers and cards to use keys of comparable size.
The second weakness of CDA cards is associated with the fact that if the service bank / payment system does not manage the loading of the system keys to the terminals inaccurately, it may happen that the serving bank does not implement any of the system keys on its terminals on time. In this case, all CDA-cards of issuers, whose open asymmetric keys are certified on the system key that is absent on the terminal, simply cannot be serviced on this terminal.
Indeed, having received a response from the card to the GENERATE AC command, the terminal will not be able to recover data from Signed Dynamic Application Data and will be forced to reject the transaction. This will also happen in the case when the card, in response to the GENERATE AC command, returns the ARQC cryptogram to the terminal for processing the transaction in real time. Without knowing the system key, it is impossible to recover the ARQC cryptogram from the Signed Dynamic Application Data object, and the transaction will have to be rejected.
Note that in the case of a DDA card, in the absence of the corresponding system key on the terminal, the transaction could be performed online.
Thus, the CDA method in case of failure of card authentication, unlike all other authentication methods, deprives it of the opportunity to apply for authorization to the issuer.
Now we will formulate general recommendations regarding the choice of the card authentication method.
1. The age of SDA cards is drawing to a close. They will be phased out in Europe starting January 1, 2011. They are being replaced by cards with dynamic authentication. So that CDA cards do not have to simultaneously support DDA and CDA methods, as is the case today, from that time on, all new offline capable terminals will be required to support the CDA method.
SDA cards in circulation today should be used primarily for online authorization. From time to time, if the transaction size is limited, they can also be used in offline authorization mode.
Even more stringent requirements are imposed on cross-boarder transactions made using SDA cards. This is due to the fact that the risks for international transactions are much higher than for domestic transactions. Therefore, it is desirable to perform most of these operations in real time.
Another possibility for using SDA cards today is their use in CAP / DPA programs. When using these programs, offline card authentication is carried out using the ARQC cryptogram, and the offline authentication mechanism is not used at all.
2. CDA-cards should be preferred to DDA-cards, since they, in addition to card authentication, ensure the integrity of information exchange between the card and the terminal. In addition, operations using the CDA method are slightly faster than using the DDA method.
CDA cards are issued by all major card providers today. In terms of cost, CDA cards are equivalent to DDA cards, since both types of offline authentication require an RSA cryptographic coprocessor, and the EEPROM requirements are the same for both types of cards. In this regard, it is advisable to choose a card that simultaneously supports both of these authentication methods and does not support the SDA method (in the VISA system in the VISA Europe region, this will be officially allowed from January 1, 2011). At the present stage of EMV technology implementation, the simultaneous support of DDA and CDA methods will allow avoiding a situation when the terminal cannot perform offline dynamic card authentication due to the fact that it does not support the CDA method.
3. As noted above, it is desirable that dynamic authentication cards do not support SDA. This avoids the possibility of cloning the DDA / CDA card to the SDA card, regardless of how the card is personalized, since the Signed Static Application Data object will not be present on the card.
4. If, nevertheless, a card with dynamic authentication supports the SDA method (including contains Signed Static Application Data), it must store an SDA Tag List object (Tag '9F4') 4. As a fallback method for offline card authentication, use the mutual online card and issuer authentication method. It is recommended in this way to define the Issuer Action Codes tables used by the terminal to decide how to complete the operation, so that in the event that the offline card authentication fails or fails, the offline transaction could only be rejected.
5. For prepaid card products, you should use cards that implement dynamic authentication (DDA / CDA) and support verification of the fact of card authentication by ICC Dynamic Number. This will avoid cases where fraudsters clone a DDA / CDA card to an SDA card and use such a card at their pre-installed merchants that do not support offline authentication methods in violation of the payment system's rules.
6. According to Book 2 of the EMV standard (v.4.2), the keys of the issuer and the card can have only two values of the open exponent - 3 and 2 16 + 1. Without compromising security, it is recommended to select the value of the open exponent of the card and the issuer equal to 3. This will reduce time of signature verification for static and dynamic card authentication. The time for verification of the card signature by the terminal, as shown in Appendix B, behaves like O (log k? Log 2 n) from the length of the open exponent k and the length of the modulus npublic key of the card. The reduction in the time of signature verification with dynamic card authentication is due to the fact that today the card performs the RSA algorithm much faster than a POS terminal. The average RSA signature time on a card with a public key modulus n is 1024 bits and a closed exponent, in order of n, is 20-800 milliseconds (this time is O (log 3 n)), and on a terminal even with a 32-bit processor computation of the signature takes a few seconds. Thus, to minimize the overall execution time of dynamic authentication, it is better to use the open exponent of the card and the issuer equal to 3.
The amount of computation required to implement the SDA, DDA and CDA authentication methods is shown in Table. 6.7.
It should be noted that the complexity of computation using the RSA algorithm on the terminal and on the card (see the second and third columns) are different. The complexity of calculations using the RSA algorithm on the terminal is O (log 2 n), and on the card - O (log 3 n).
The last row of the table corresponds to the case when a transaction made using a CDA card was approved by the issuer.
Tab. 6.7. The amount of computation to implement various card authentication methods
If the transaction was rejected by the issuer or was approved offline, then the indicators specified in the second row of the table are correct for it. In the case when the transaction is declined offline, operations using the RSA algorithm by the terminal and the card are not performed, unless the transaction is declined due to the failure of card authentication using the CDA method.
Let us briefly recall the general information about card authentication methods. Card authentication methods are divided into offline and online. The latest version of the EMV standard (v.4.2) distinguishes between three offline card authentication methods:
- SDA (Static Data Authentication);
- DDA (Dynamic Data Authentication);
- CDA (Combined Dynamic Data Authentication / AC Generation).
The SDA method ensures the integrity of the application-critical static data, as well as the impossibility of creating a card from a "white sheet". During static authentication, the card transmits to the terminal for verification the Signed Static Application Data value, which is a signature of critical static application data and, in its essence, is a chip analog of the CW / CVC values used to ensure the integrity of the card number, service code and period stored on the magnetic stripe of the card. actions. An example of a list of critical data recommended for signing is shown in Table. 3.14.
Dynamic card authentication methods (DDA and CDA) consist in the terminal verifying the signature calculated by the card provided to the card by the terminal (with the obligatory use of a random number generated by the terminal) in accordance with the DDOL list stored on the card. In this case, the successful result of card authentication guarantees, at the level of cryptographic strength of the RSA algorithm, the fact that the card contains a chip personalized by the issuer authorized by the payment system to issue cards of this system. To implement dynamic methods of card authentication, the microcircuit card must support the RSA algorithm, which in turn requires a special cryptographic coprocessor in the microcircuit and therefore increases the cost of the card.
The CDA method, in addition to dynamic card authentication, additionally ensures the integrity of the most critical data of information exchange between the card and the terminal (CID, transaction and terminal details). This is achieved by combining the card authentication procedure with the processing of the GENERATE AC command, during which the most important data for making a decision on how to complete the transaction is exchanged between the card and the terminal. As a result, the card signs a dataset that includes the hash value from the data circulating between the card and the terminal during the processing of the GET PROCESSING OPTIONS and GENERATE AC commands.
Another advantage of the CDA method is the reduction in the processing time of the operation (on average by several tens of milliseconds) compared to the case of using a card that supports the DDA method to process the same operation. This reduction in time in the case of using the CDA method is due to the absence of a separate INTERNAL AUTHENTICATE command during transaction processing, which is used to authenticate the card application in the DDA method.
The choice of the offline authentication method is made by the terminal based on the AIP data object (Tag '82') and the terminal capabilities determined by the value of the third byte of the Terminal Capabilities element (Tag '9F33').
Payment system rules require payment system applications on the card to support the online authentication method and the offline authentication method. At the same time, from the point of view of offline authentication, applications must support at least the SDA static authentication method. Starting from January 1, 2011, new cards issued by banks in the MasterCard Europe and VISA Europe regions must support the DDA method (in France this solution has been effective since January 1, 2007). At the same time, new cards should not support the SDA method (bit 5 of byte 1 of the data field of the AIP object is 0, and the card does not have a Signed Static Application Data object).
Moreover, VISA Europe prohibits issuers from using SDA cards from January 1, 2015.
At the end of 2008, in countries such as Belgium, Norway, Italy, Portugal, Great Britain, almost all issued cards support only the SDA method (they are SDA cards). In contrast, France and Switzerland are dominated by (over 80%) DDA cards.
For individual transactions, the offline authentication mechanism of the card application may not be used. This, for example, applies to transactions from ATMs, which are processed online, and therefore use mutual online authentication of the card and the issuer.
Offline authentication is also not used in cardholder authentication operations in CAP / DPA programs. According to the VISA and MasterCard rules, offline authentication may not be used in all operations performed from terminals that process transactions only in online mode (Online Only terminals).
At the time of this writing (end of 2009), according to VISA and MasterCard rules, all chip terminals in the world must support offline SDA and DDA card authentication methods (in Europe, this rule has been in effect since January 1, 2005).
Effective January 1, 2011, all new offline capable terminals in MasterCard across all regions must support the CDA method. According to EMVCo, at the beginning of 2009, more than 70% of terminals that have passed Approval Level 2 certification support CDA. Thus, from now on, all new offline capable MasterCard terminals will support all three methods of offline card authentication. So far, nothing is known about a similar VISA solution.
The decision on mandatory support of the CDA method by the commissioned MasterCard terminals means that CDA cards of this system, after some time required for all MasterCard terminals to support this method, may not support the method.
DDA. Today this support is required, as not all terminals support CDA.
As previously explained, dynamic authentication methods automatically include static authentication functionality (ensuring the integrity of critical static application data), which is implemented as part of the card's public key certificate validation procedure. Therefore, the MasterCard payment system allows its DDA card issuing banks not to support the SDA method. The VISA payment system, for reasons of ensuring high quality of card acceptance, allows its banks to refuse to support the SDA method on DDA cards in the VISA Europe region only from January 1, 2011. From that time, all new cards in the VISA Europe region must not support SDA. Starting from 2015, all VISA Europe bank cards must only support the DDA method and / or optionally CDA.
Since the issuer learns about the result of card authentication from the TVR data ultimately received from the merchant, the EMV standard provides for a mechanism for the issuer to verify that the terminal has completed the card authentication procedure. This mechanism protects the issuer from unscrupulous merchants / service banks claiming through the TVR data object that the card has been authenticated when the terminal has not actually authenticated it.
The reason for this deception may be the unwillingness of the serving bank / merchant to upgrade the terminals to support the RSA algorithm used for card authentication. Support for the RSA algorithm requires additional costs for upgrading the terminal. These costs are associated at least with changes in the terminal software, and often with the modernization of its hardware platform. To support RSA, the terminal must have a sufficiently powerful processor (preferably a 32-bit RISC processor) and / or a cryptographic coprocessor in order to quickly (about 1-3 seconds) perform the procedures for verifying certificates of the issuer and card, as well as the Signed Dynamic Application element Data. To perform these checks, a software implementation of the RSA algorithm can be used.
A cryptographic processor is required when the terminal supports the Enciphered Offline PIN cardholder verification method. In this case, the PIN-block is encrypted, which, in accordance with the requirements of payment systems, must be performed by specialized processors. Typically, such a cryptographic processor is implemented within a special PIN-PAD device.
Another reason for the merchant's refusal to perform card authentication is as follows. The merchant is interested in serving the customer, especially not caring about the reliability of his authentication. If the formal rules of customer service established by the payment system are met, the issuer is responsible for the result of the operation. The servicing bank in this case is guaranteed to receive a refund for servicing the cardholder.
The mechanism for checking by the issuer that the terminal has performed the card authentication procedure is as follows. When describing card authentication methods, it was noted that the terminal can store Data Authentication Code (DAC) values in case of static authentication and ICC Dynamic Number (IDN) in case of DDA / CDA in data objects with tags '9F45' and '9F4C', respectively. If the issuer includes the values of these tags in the CDOL1 and CDOL2 lists, then the card receives the DAC and IDN values when it processes the AC GENERATE command. The resulting values can be sent by the card to the issuer in the Issuer Application Data object.
In the case of an online transaction, the issuer can verify the fact that the terminal has authenticated the card during the authorization of the transaction and, based on the verification data, decide on how to complete the transaction. In the case of an offline transaction, the fact that the terminal has performed card authentication is verified by the clearing message received by the issuer. If a dispute arises over a certain payment transaction, the issuer can use a negative result of checking the DAC or IDN values to initiate a non-compliance case (refusal to pay) in the payment system.
Thus, for the issuer to verify that the terminal has performed card authentication, it is necessary:
- when personalizing the card application, include the tags '9F45' and '9F4C' in the CDOL1 and CDOL2 lists;
- include tags '9F45' and '9F4C' in the Issuer Application Data object returned in response to the AC GENERATE command; this option is supported at the level of the payment system;
- provide for checking the DAC and IDN values in the issuer's system (in the subsystem for processing authorization requests and clearing messages).
For a prepaid card application, verification by the issuer of the fact that the terminal has performed card authentication is especially relevant, since offline card authentication is the main mechanism for ensuring the security of transactions with such cards.
Along with offline authentication, all cards and on-line-capable terminals are required to support the so-called online card authentication or, as it is sometimes called, Online Mutual Authentication. The idea behind mutual authentication is that the card and the terminal authenticate each other using the ARQC and ARPC cryptogram validation mechanism. Cryptograms are cryptographic values generated using the card's secret key, transaction number, a random number generated by the terminal, as well as some details of the transaction, terminal and card. In the case of ARPC, the issuer's authorization response code is also added to the listed data. Without knowing the secret key of the card for generating the cryptogram, it is impossible to calculate the ARQC / ARPC values,
Online authentication is the most secure way to authenticate a card. This is due to the fact that it is carried out directly by the issuer, without an intermediary in the form of a terminal. In addition, for online authentication, the 3DES algorithm is used with a double key of 112 bits, the cryptographic strength of which corresponds to the cryptographic strength of the RSA algorithm with an asymmetric key modulus used for offline authentication of the card application of more than 1700 bits. The use of asymmetric keys of this length on a card is still quite rare. Typically, keys with a modulus of 1024, 1152, or 1408 bits are used.
Due to the high reliability of online authentication, payment systems allow on bank terminals that process transactions only in real time (on-line only terminals: ATMs and some POS terminals) not to support offline card authentication procedures.
From the above, it follows that from the point of view of ensuring the security of card transactions, the most reliable method of offline authentication is CDA. Next, in decreasing order of reliability, are the DDA and SDA methods. It is this priority scale that the terminal uses when choosing the highest priority authentication method supported by the card and the terminal at the same time.
The SDA method does not protect the IPC from cloning its chip in order to use the cloned card in offline operations. Cloning of an IPC chip is understood as the procedure for fraudsters to create an analogue of a bank card (based on the data of a real card issued by a certain bank of the payment system) for the purpose of unauthorized use of this analogue in the terminal network of the payment system using chip technology.
At the same time, the chip terminal cannot establish the fact that the card is cloned under certain conditions (in the case of processing a transaction in offline mode), which allows fraudsters to make payment transactions, damaging the card issuer on the basis of which the cloned card was created.
To clone an SDA-card, you just need to have a microprocessor card with a programmer for it and be familiar with the EMV standard. Knowledge of the EMV standard is required to develop a card application that meets the requirements listed below.
The application supports the SELECT, GET PROCESSING OPTIONS, READ RECORD commands in a standard way. In response to the VERIFY command, the application always responds by confirming that the cardholder's PIN is correct, regardless of the value entered by the cardholder during the operation.
In response to the GENERATE command, the AC card responds as follows:
- if the terminal requests ARQC or AAC, the card responds with an AAC cryptogram, the value of which is an arbitrary 16-bit hexadecimal number;
- if the terminal requests a vehicle, the card returns the vehicle to the terminal and uses an arbitrary 16-bit hexadecimal number as the cryptogram value.
After placing an application with the properties described above on the card, the pre-stolen personalization data of the real SDA card is loaded onto the IPC, including the FCI Template ADF file of the application, AIP, AFL and file records, the identifiers of which are defined in the AFL. Linear file data includes a Signed Static Application Data object, which is the critical card data signed by the issuer.
Theft of real card data is carried out in a standard way (in exactly the same way as it is done for cards with a magnetic stripe) in appropriately prepared POS terminals (terminals that store the data of the cards used in them) or special devices - skimmers.
When purchasing 100 microcontrollers and a programmer for them, the cost of cloning 100 cards is about $ 500-1000 or $ 5-10 per card.
Suppose now that the fraudsters got hold of the data of a real card that supports offline dynamic authentication and the SDA method. Real card data was obtained by fraudsters when using the card in a terminal that implements only the SDA method (the terminal can be specially configured by the fraudsters to support only the SDA method). In this case, fraudsters can clone such a card, transferring the same application data of a real card to the IPC blank, which is used when cloning an SDA card.
Obviously, if the card cloned in this way is used in a terminal that supports only the SDA method, then the fraudsters have every chance of success, provided that the terminal approves the transaction in offline mode (the terminal asks for the TC cryptogram in the GENERATE AC command). That is why payment systems require DDA method support by all offline capable POS terminals. As noted, terminals that process transactions only online may not support offline card authentication at all.
The following question arises: "Is it possible to clone a DDA / CDA card to a card with static authentication when using the cloned card in a terminal that supports DDA / CDA dynamic authentication methods?" The issue is relevant given the fact that all today's terminals must support the DDA method and the trend of migration of cards to cards that support the method of dynamic offline authentication.
The answer to this question is generally negative, because to clone a DDA / CDA card, you need to know the secret key of the card.
At the same time, in some cases, if the card is incorrectly personalized, cloning of the DDA / CDA card is possible. If the DDA / CDA card supports the SDA method and does not store an SDA Tag List data object, then the card can be cloned! Indeed, having at its disposal the open card data (data communicated by the card to the terminal when processing an operation in a terminal that supports only the SDA method), they can be transferred to the cloned card by changing the data field of the AIP object. The change consists in the fact that in the first byte of the data field of the AIP object, bits 2 and 6 must be set equal to 0, and bit 7 equal to 1. Thus, the card informs the terminal that it only supports the SDA method.
In this way, a cloned card can be successfully used by fraudsters when processing a transaction offline. Indeed, in this case, the terminal will always choose the SDA method to process the operation on the cloned card. In this case, the modification of the AIP object will pass unnoticed for the terminal, since the AIP object does not fall into the list of signed data, the integrity of which is checked as part of the card authentication procedure using the SDA method. Let us remind the reader that the AIP data object (Tag '82') can be included in the list of signed data only if the SDA Tag List object is supported by the card.
Therefore, if the card application simultaneously supports offline dynamic and static authentication, the SDA Tag List object must be present among the personalization data of the application! Otherwise, the DDA / CDA card can be cloned.
It's funny that the presence of an SDA Tag List object on a DDA / CDA card, which also supports the SDA method, is still not a mandatory requirement in M / Chip Select 4 and VSDC applications.
To avoid cloning a DDA / CDA card without thinking about personalizing the card, given that all offline-capable POS terminals must support the DDA method, you can follow the following recommendation. The DDA / CDA card must not support the SDA method (the functionality of the SDA method, i.e. ensuring the integrity of critical application data, is supported during the card key certificate verification process). In particular, the card must not contain a Signed Static Application Data object. In this case, even if the card does not contain an SDA Tag List element, it is impossible to clone it to the SDA card, since the required issuer data - the Signed Static Application Data object - is missing.
Despite the fact that a DDA card, when properly personalized, does not allow cloning, it does not ensure the integrity of information exchange between the card and the terminal. As a result, attacks called "two-chip attacks" are possible and consist of the following. A printed circuit board is used that contains two chips: one is a banking chip and the other is an intermediary chip. A bank chip is a microchip that implements a bank payment application that supports the DDA method and is personalized by the bank. The intermediary chip controls the exchange of data between the bank chip and the terminal, modifying it if necessary. It is this chip that is inserted into the terminal's reader and exchanges information with it. It analyzes the data of the terminal commands, as well as the card's responses to these commands, and, if necessary, modifies them in a way beneficial to the fraudster.
Here are the simplest examples of possible data modification. If the terminal in the GENERATE AC command requested the TS cryptogram, and the card represented by the banking application decides to process the transaction online or reject it offline, then the intermediary chip changes the unprotected Cryptogram Information Data in such a way that it turns out that the bank chip responds to the terminal with the TS cryptogram. Thus, the transaction is approved despite the fact that by the decision of the card, delegated to it by the issuer, it must either be rejected or transferred to the issuer for authorization.
Another example. The intermediary chip, having received the value of the transaction size from the terminal (for example, € 2000), changes it to the value at which the card is ready to approve the transaction offline (for example, € 20).
Such an intermediary chip is called wedge device in the literature. The wedge device can be implemented not only in the printed circuit of a plastic card, but also on the side of the POS terminal. The main thing is that the device acts as an intermediary for information exchange between the card and the terminal.
The problem of ensuring the integrity of information exchange between the card and the terminal is solved by using CDA cards. Such cards include CID objects, ICC Dynamic Number, cryptogram (TC or ARQC), Transaction Data Hash Code and Unpredictable Number objects in the data signed by the card (see n. 3.12.2.2). The Transaction Data Hash Code element is a hash function of information circulating between the card and the terminal during the processing of the GET PROCESSING OPTIONS and GENERATE AC commands.
Therefore, it is impossible to modify information exchange in a way that is imperceptible for the terminal.
CDA cards have several weaknesses. First, as noted in clause 3.16.3, the size of a CDA card key module under certain circumstances may not exceed 205 bytes. Today, this limitation is not onerous, since mostly smaller card keys are used. However, this limitation may become sensitive in the future. Payment systems have already begun distributing their 248 byte keys, allowing issuers and cards to use keys of comparable size.
The second weakness of CDA cards is associated with the fact that if the service bank / payment system does not manage the loading of the system keys to the terminals inaccurately, it may happen that the serving bank does not implement any of the system keys on its terminals on time. In this case, all CDA-cards of issuers, whose open asymmetric keys are certified on the system key that is absent on the terminal, simply cannot be serviced on this terminal.
Indeed, having received a response from the card to the GENERATE AC command, the terminal will not be able to recover data from Signed Dynamic Application Data and will be forced to reject the transaction. This will also happen in the case when the card, in response to the GENERATE AC command, returns the ARQC cryptogram to the terminal for processing the transaction in real time. Without knowing the system key, it is impossible to recover the ARQC cryptogram from the Signed Dynamic Application Data object, and the transaction will have to be rejected.
Note that in the case of a DDA card, in the absence of the corresponding system key on the terminal, the transaction could be performed online.
Thus, the CDA method in case of failure of card authentication, unlike all other authentication methods, deprives it of the opportunity to apply for authorization to the issuer.
Now we will formulate general recommendations regarding the choice of the card authentication method.
1. The age of SDA cards is drawing to a close. They will be phased out in Europe starting January 1, 2011. They are being replaced by cards with dynamic authentication. So that CDA cards do not have to simultaneously support DDA and CDA methods, as is the case today, from that time on, all new offline capable terminals will be required to support the CDA method.
SDA cards in circulation today should be used primarily for online authorization. From time to time, if the transaction size is limited, they can also be used in offline authorization mode.
Even more stringent requirements are imposed on cross-boarder transactions made using SDA cards. This is due to the fact that the risks for international transactions are much higher than for domestic transactions. Therefore, it is desirable to perform most of these operations in real time.
Another possibility for using SDA cards today is their use in CAP / DPA programs. When using these programs, offline card authentication is carried out using the ARQC cryptogram, and the offline authentication mechanism is not used at all.
2. CDA-cards should be preferred to DDA-cards, since they, in addition to card authentication, ensure the integrity of information exchange between the card and the terminal. In addition, operations using the CDA method are slightly faster than using the DDA method.
CDA cards are issued by all major card providers today. In terms of cost, CDA cards are equivalent to DDA cards, since both types of offline authentication require an RSA cryptographic coprocessor, and the EEPROM requirements are the same for both types of cards. In this regard, it is advisable to choose a card that simultaneously supports both of these authentication methods and does not support the SDA method (in the VISA system in the VISA Europe region, this will be officially allowed from January 1, 2011). At the present stage of EMV technology implementation, the simultaneous support of DDA and CDA methods will allow avoiding a situation when the terminal cannot perform offline dynamic card authentication due to the fact that it does not support the CDA method.
3. As noted above, it is desirable that dynamic authentication cards do not support SDA. This avoids the possibility of cloning the DDA / CDA card to the SDA card, regardless of how the card is personalized, since the Signed Static Application Data object will not be present on the card.
4. If, nevertheless, a card with dynamic authentication supports the SDA method (including contains Signed Static Application Data), it must store an SDA Tag List object (Tag '9F4') 4. As a fallback method for offline card authentication, use the mutual online card and issuer authentication method. It is recommended in this way to define the Issuer Action Codes tables used by the terminal to decide how to complete the operation, so that in the event that the offline card authentication fails or fails, the offline transaction could only be rejected.
5. For prepaid card products, you should use cards that implement dynamic authentication (DDA / CDA) and support verification of the fact of card authentication by ICC Dynamic Number. This will avoid cases where fraudsters clone a DDA / CDA card to an SDA card and use such a card at their pre-installed merchants that do not support offline authentication methods in violation of the payment system's rules.
6. According to Book 2 of the EMV standard (v.4.2), the keys of the issuer and the card can have only two values of the open exponent - 3 and 2 16 + 1. Without compromising security, it is recommended to select the value of the open exponent of the card and the issuer equal to 3. This will reduce time of signature verification for static and dynamic card authentication. The time for verification of the card signature by the terminal, as shown in Appendix B, behaves like O (log k? Log 2 n) from the length of the open exponent k and the length of the modulus npublic key of the card. The reduction in the time of signature verification with dynamic card authentication is due to the fact that today the card performs the RSA algorithm much faster than a POS terminal. The average RSA signature time on a card with a public key modulus n is 1024 bits and a closed exponent, in order of n, is 20-800 milliseconds (this time is O (log 3 n)), and on a terminal even with a 32-bit processor computation of the signature takes a few seconds. Thus, to minimize the overall execution time of dynamic authentication, it is better to use the open exponent of the card and the issuer equal to 3.
The amount of computation required to implement the SDA, DDA and CDA authentication methods is shown in Table. 6.7.
It should be noted that the complexity of computation using the RSA algorithm on the terminal and on the card (see the second and third columns) are different. The complexity of calculations using the RSA algorithm on the terminal is O (log 2 n), and on the card - O (log 3 n).
The last row of the table corresponds to the case when a transaction made using a CDA card was approved by the issuer.
Tab. 6.7. The amount of computation to implement various card authentication methods
| Authentication method | Terminal calculations | Calculations on the card |
| SDA | 2 • RSA + 2 • SHA-1 | - |
| DDA | 3 • RSA + 3 • SHA-1 | 1 • RSA + 1 • SIIA-1 |
| CDA | 4 • RSA + 4 • SHA-1 | 2 • RSA + 2 • SHA-1 |
If the transaction was rejected by the issuer or was approved offline, then the indicators specified in the second row of the table are correct for it. In the case when the transaction is declined offline, operations using the RSA algorithm by the terminal and the card are not performed, unless the transaction is declined due to the failure of card authentication using the CDA method.
