Terminals with EMV specifications

Today, most terminals except ATMs, SAT1 – and SAT2-terminals support the ability to perform transactions in offline mode, i.e. they belong to the second class of terminals. The offline mode of the terminal includes support for offline card authentication methods (SDA support is mandatory everywhere, DDA support is mandatory in Europe, and CDA is recommended), risk management procedures (checking the value of Terminal Floor Limit stop lists, Random Transaction Selection, and Velocity Checking procedures), and storing and uploading transaction data.
Online-only terminals may not support all of the features listed above. The experience of many countries shows that the cost of such a terminal is lower than the cost of an online / offline terminal (according to Spain, on average by 30 euros). Therefore, some banks, especially in countries with low cost of communications, have chosen these terminals. The use of terminals of this class is not prohibited by payment systems, although it contradicts the desire of some issuers to switch to an offline method of servicing their cards.
It is also worth noting that online transactions are generally safer than offline ones. In particular, cloned cards cannot be used in Online only terminals.
The servicing Bank should strive to ensure that its terminals simultaneously support all types of offline card authentication, thereby enabling the Issuer to use any authentication method on its card. In this case, the Issuer can choose the most effective authentication method for each of its card products, without worrying about possible restrictions on the” availability ” of the product in the terminal network of banks of the payment system.
Today, most of the chip terminals used support the SDA and D0A methods. Therefore, the conversation about the universality of the terminal in terms of support for card authentication methods comes down to the terminal’s support for the CDA method. According to the cost criterion, a terminal that supports DDA and a terminal that supports CDA are almost identical. Therefore, the cost of making a decision by the servicing Bank to migrate to terminals that support CDA is mainly determined by the Bank’s costs for certification in payment systems for connecting terminals with new software.
It is expected that in the next few years, almost all chip terminals that allow offline authorization mode will be able to support the CDA method.
We have already mentioned that from the point of view of payment systems, the PIN Offline cardholder verification method is the most preferable. In this regard, payment systems are gradually but persistently implementing rules aimed at ensuring that terminals that support IPC reception are equipped with PIN-PAD devices necessary for entering the PIN code. In addition to the already mentioned Chip & PIN Liability Shift, payment systems set a period (depending on the region where the servicing Bank is located) before which all terminals that accept IPC must be equipped with a PIN-PAD. If the servicing Bank does not meet this requirement before the deadline, it loses the ability to pay interbank commissions at more favorable rates set for banks servicing the IPC.
One of the serious “holes” in the security model of operations performed using IPC is the practical possibility of a fraudster creating a false public key of the system. Having produced certificates of the Issuer’s key under a false key, you can then issue fake cards that will work successfully in terminals with a loaded false key.
A natural way to combat this type of fraud is to create a signature of the system keys entered in the terminal on the key of the servicing Bank (possibly a symmetric key). This signature ensures the integrity of the system’s key information on the terminal. In this case, if you do not have the key of the servicing Bank, you cannot successfully create/use a false public key of the system.
Unfortunately, to circumvent the mentioned protection of public keys of the system, a fraudster may not go along the path of compromising the secret key of the servicing Bank. To commit fraud, it is enough for the user to upload a fake executable module to the terminal, which, unlike the application of the servicing Bank, will not verify the signature of the key used. In this case, the protection described above does not work.
To prevent a fraudster from replacing the terminal application, you need to connect the resources of the operating system and the terminal’s cryptoprocessor. With regard to ensuring the integrity of the terminal application, we only note that for terminals that accept IPC, this problem is solved using a special IPC that performs the function of controlling access to operations, such as deleting/loading executable files.
The problem of ensuring the integrity of the terminal application is not far-fetched. According to experts, in the field of security of card transactions, as the security of cards increases, the attention of fraudsters will increasingly turn to the environment of their service. The terminal is a close environment of the card and therefore will undoubtedly become a target for attacks. Since the terminal today is actually a personal computer, the same methods will be used for attacks as in the case of a PC. In particular, the use of special programs (similar to spyware, Trojan horse, keyboard/screen logger, viruses) will allow the fraudster to get information about the card that interests him (for example, recording the second track of the card’s magnetic stripe, the value of the random sequence of the terminal and the random number of the card used to encrypt the PIN block, the value of the encrypted PIN block, etc.).
The problem of replacing the Bank’s real POS terminal with a terminal installed by fraudsters is also important. The cost of the terminal is small— 400-600 dollars. Therefore, such a substitution is very plausible when a fraudster colludes with the cashier of a commercial enterprise (there are cases of installing even false ATMs!). There may also be cases when a merchant uses a POS terminal only for the purpose of collecting information about cards.
If a false terminal is used, not only the contents of the magnetic track of the card can be recorded, but also the PIN code of the card holder. Taking into account the use of hybrid cards with a magnetic stripe in practice, having received information about the magnetic track of the card and the value of its PIN code, a fraudster can produce “white” cards for their use in an ATM.
To solve the problem of a false terminal when processing transactions online, MAC codes must be implemented everywhere for messages that circulate between the terminal and the host of the servicing Bank. This will ensure the integrity of information exchange and authentication of the POS terminal.
Information about offline transactions can also be signed for transmission to the servicing Bank. However, a fraudulent terminal may not transmit this information to the Bank. To solve the problem of a false terminal when processing offline transactions, unfortunately, there is nothing to offer other than organizational measures to combat this type of fraud.
A fairly effective way to combat terminal spoofing would be to introduce a mutual authentication procedure for the card and terminal into the EMV standard. Placing a pair of secret and public asymmetric keys of the servicing Bank and a Bank key certificate on the system key on the terminal, as well as support for the terminal authentication procedure by the card and storing the hash function values from all public keys of the system on it, will prevent the substitution of the terminal. Storing the hash function values from the system’s public keys on the card is necessary in order to avoid a situation when a fraudster invents a false system key and generates a pair of keys from the servicing Bank with a certificate calculated on the false system key for entering the terminal.
Of course, storing the hash function values from the system keys (obviously, you will have to store information about keys generated for the future, so that it does not happen that system keys unknown to the card will appear on the terminals during the card lifecycle) imposes requirements for the eepr0m memory size. The terminal must store up to two system keys. Therefore, taking into account the keys that are stored for future use and the size of the SHA-1 hash function value equal to 20 bytes, you will need to reserve about 200 bytes of EEPR0M memory for a single payment system.
In conclusion, we note that to combat cloned cards on POS terminals, you must use stop lists (currently, the use of stop lists is mandatory only on terminals
SATZ). These lists are the only way to deal with such cards, since, as previously explained, it is generally impossible to block the use of cloned cards in offline authorization mode.

Compatibility of terminal and card applications
The issue of compatibility of the Bank’s card, terminal and host applications is the cornerstone of EMV technology implementation. EMV is a complex and young standard. Therefore, suppliers of hardware, cards, and applications for the processing center host have discrepancies in the standard (which are gradually clarified as the standard is implemented), which sometimes lead to the fact that the operation cannot be processed at the terminal or is rejected by the payment network. In such cases, payment systems either reject the transaction (sometimes the card Issuer does this), or allow the card service to be switched to Fallback mode via the magnetic stripe.
To illustrate, we will mention only some of the reasons for the Fallback or unsuccessful completion of a transaction by the network/host of the Issuer, which are found in practice. These reasons are sometimes General, and sometimes very specific and are the result of errors in the terminal or card applications.
Problems on the host of the servicing Bank (data distortion and cropping, incorrect data formatting usually concerns PAN Sequence Number, issue Discretionary Data, issue Authentication Data, and issue Script Template).
Problems on the terminal (data distortion and cropping, incorrect formatting).
On some POS terminals, the change of agreement (change of convention) was processed incorrectly. For example, when servicing French cards in FRANCE, in the first response to the Reset signal, the card sent an ATR string in indirect convention mode, specifying a byte of the communication Protocol that does not correspond to EMV. The terminal, as expected, initiated a warm reset of the card( Warm Reset), to which the card now responded with an ATR fully compatible with EMV, but with the change of the agreement to direct (direct convention). The terminal did not perceive the change in the agreement and initiated a Fallback to the magnetic stripe.
The terminal attempts to get PIN Try Counter information using the GET DATA command when the card does not support offline PIN checks in CVM. The card responds to a command with an error code that causes the terminal to suggest that the merchant’s cashier switch to Fallback mode.
System keys not loaded in time for the case of a CCD card. Failure to verify Signed Dynamic Application Data means that the transaction cannot be served even in real time (the ARQC cryptogram cannot be restored from signed data).
Some terminals incorrectly generate POS Entry Mode (in terms of MasterCard) for IPC transactions in a terminal that accepts smart cards-80X instead of 05x.
Incorrect padding of fields with service characters in FCI Template when personalizing cards. The General rule is violated: padding is allowed before, after, and between TLV data inside a single FCI Template, and not inside the data objects of this template.
SDA-failure when the Issuer’s public key module size is 127 bytes-some RSA programs implemented on terminals only work with modules that are multiples of 16.
Incorrect processing of the cryptogram Information Data element by the terminal in response to the GENERATE AC command.
The terminal should ignore data that it does not understand, and not respond to them by refusing to service the card. For example, there is a known case when the terminal received FCI Issuer Discretionary Data objects (Tag ‘5F0C’) in response to the SELECT command, among which there was an issue URL object (Tag ‘5F50) that was unfamiliar to the terminal. As a result, the operation ended with the code Card Data Error (0200).
There are cases when a terminal was implemented without a PIN PAD device, and later such a device was connected to the terminal, but some configuration parameters of the terminal were not changed. As a result, in TVR, the corresponding ‘PIN PAD Not Present’ bit was set to 1, and transactions on many Japanese cards and French cards in ‘ WERE rejected. This was because the specified cards were personalized so that if they required PIN verification, and it was not provided, the transaction was rejected.
There are cases when the terminal application contained errors that led to card denial of service. For example, if the terminal “forgets” that the SDA card authentication failed after the transaction was completed, depending on the card personalization method, it either refused authorization in offline mode, or forced the transaction to be authorized in real time.
If the size of the second track of the magnetic stripe Track 2 Equivalent Data stored in the chip is not equal to an integer number of bytes, then you need to Supplement this data with service characters to obtain a size multiple of the integer number of bytes. Some servicing banks did not perceive the Padding of this data object.
There are cases when the Language Preference data element was not present in the FCI Template of the PSE directory, but was present in the FCI TempLate of the selected directory. This is contrary to EMV rules that require this data element to be the same in the FCI Template of the PSE and ADF directories. Therefore, the terminal detected this violation and rejected the transaction.
In some cases, Fallback mode is triggered when the cardholder’s confirmation is required when selecting an app, and the receiver is not able to provide the cardholder with the option to confirm the selection.
There were cases when the terminal rejected transactions if it detected data in BER-TLV encoding less than 127 bytes in size, even though the Length field was 2 bytes in size. Indeed, for encoding an element smaller than 127 bytes, it is sufficient to have a Length field of 1 byte, but EMV rules do not prohibit encoding such data with a Length field of 2 or 3 bytes.
It was discovered that some terminals rejected the transaction because the Application Label or Application Preferred Name data elements contained spaces. The terminals did this because the specified data elements have the format of alphanumeric data, and the space does not apply to alphanumeric characters. Subsequently, terminal applications were modified, since EMV refers to the encoding of printable characters for the Application Label and Application Preferred Name elements.
There were cases when, in the absence of public Key Remainder data, the terminal set only the ICC Data Missing’ bit in the verification results, without setting the ‘Offline Dynamic Data Authentication failed’ bit.
It is noted that most cards in the CD0L2 list today do not contain a reference to the Unpredictable Number element (the Tag and Length fields of this data object). If you use the CDA authentication method, this will cause authorization to be denied, because it contradicts the requirements of EMV 4.1, according to which both the CD0L1 and CD0L2 lists must mention the element Unpredictable Number.
Sometimes there are problems related to the fact that the terminal perceives the equality of public key modules of the card Issuer and the system as an error. In accordance with the EMV 3.1.1 standard, the Issuer’s key module must be strictly smaller than the system’s key module. Strict inequality was replaced with non-strict inequality in the EMV 4.0 version of the standard. However, this check has not changed in older versions of terminals and causes problems with transaction authorization.
Some older terminal models experience difficulties when working with relatively long RSA keys (for example, when working with keys whose modules are greater than or equal to 1152 bits).
It was noticed that some interfaces between the terminal and the host of the servicing Bank do not support Issuer scripts larger than 24 bytes. In accordance with EMV 4.1, the size of only one instruction block of the Issuer Script Template can be equal to 128 bytes, and the Issuer can send the card an unlimited number of such instruction blocks in the standard.
There were cases when the transaction size in the ARQC cryptogram and the “transaction Size” field of the Huo message were different, which caused the transaction to be rejected by the Issuer. The error was due to the fact that the terminal installed in the hotel transmitted the preliminary value of the transaction size to the card, and the final value was sent to the Issuer.
Incorrect processing of the encrypted PIN block when using the PIN Offline cardholder verification method.
The length of the Issuer Application Data is too long. Due to the different sizes of the specified data object, there was confusion in different payment systems when the card was personalized by the Issuer.
As noted earlier, all Fallback transactions must be conducted in real time and have POS Entry Data (DE 022) = 80x. The magnetic stripe Fallback mode is mandatory for ATM, SAT1, and SAT2 terminals. At the same time, experts note that the support of this regime by payment systems creates a significant gap in the security system of banks participating in payment systems. For example, a fraudulent store may have a “terminal” installed that will represent all hybrid card transactions as Fallback transactions. Thus, the so-called carding (using the details of stolen cards) is easily implemented in such a store.
In this regard, the leading card associations are making significant efforts to completely abandon the Fallback mode. For this purpose, payment systems and EMVCo primarily pay attention to ensuring that cards and terminals comply with EMV standards and payment system requirements. From the very beginning of implementation of the EMV standard, procedures for testing terminals and cards, as well as integration tests, were developed to ensure that the entire cycle of performing an IPC operation meets the requirements of payment systems.

EMVCo has developed and published a list of tests to verify that terminals comply with EMV specifications. All these tests are divided into two parts — Type Approval Level 1 and Type Approval Level 2. The Type Approval Level 1 tests check that the physical and electrical characteristics of the card reader (more precisely, in terms of the EMV standard-the IFM terminal interface module) correspond to the characteristics defined in Book 1 of the EMV standard. Type Approval Level 2 tests determine whether the terminal application core meets the EMV standard. Checked the logical level of the terminal with a card: processing of terminal commands and their answers, the correct formation of various data items, the correct response of the terminal on the read card data, the correct execution of terminal risk management, script processing, etc.
Note that payment systems have developed specifications for the introduction of contactless cards based on ISO 14443 (Proximity Payments). The specifications specify the parameters of the ISO 14443 transport layer. This should soon affect the specifications of the Type Approval Level 1 tests.
The company EMVCo has accredited the lab to perform the test, terminals and software. As of mid-2005, EMVCo uses 7 laboratories for testing on Type Approval Level I and 13 laboratories for testing on Type Approval Level 2.the Average testing time for the approval Level I Tour is 1.6 days, for Type Approval Level 2 — 3.1 days.
After successful completion of testing, EMVCo publishes a Letter of confirmation of the completed certification (Letter of Approval) and places the certified product in the list published on the company’s website www.emvco.com.
Certification of card applications for compliance with the specifications of payment system applications is carried out by accredited laboratories of the corresponding payment systems.
In addition to card certification, payment systems also conduct integrated tests that allow to assess the overall performance of the Bank’s processing center in terms of processing transactions under the IPC, both in terms of issue and in terms of servicing in the Bank’s terminals. This checks the correctness of all the transaction processing links. In case of testing by the servicing Bank, the correctness of transaction processing during its servicing on the terminal, information exchange between the terminal and the host of the servicing Bank, sending an authorization request to the payment network, receiving a response from the network, and delivering the authorization response to the terminal are checked.
Integral testing of the Issuer microprocessor card checks the processing of a transaction, starting from the moment of receipt of the authorization message from the network to sending the network authentication response.
Real-world security analysis
IPC operations
When assessing the real security of operations performed using IPC, we took into account the fact that today in the world most of the terminal equipment for card servicing accepts only cards with a magnetic stripe, and most of the issued cards are cards with a magnetic stripe only. This fact has a significant impact on the security of card transactions, if only because many transactions are still processed using a security-sensitive magnetic stripe technology. Indeed, if we denote the share of microprocessor cards A, and the share of terminals capable of servicing MPC-B, then as a rough estimate of the number of operations performed using the chip, we can use the value AB. For example, if A=B=70% (values A and B show a fairly Mature stage of migration to the chip), only about half of the operations will experience the benefits of IPC technology in terms of improving their security.
Other forms of influence of the “mixed” nature of today’s card world, in which there are cards and terminals that support only the magnetic stripe, on the security of card operations will also be considered.
The analysis is an assessment of the security of operations in the context of the main types of fraud.
Fake cards
Let’s start with the most common type of fraud — fake cards. It has already been mentioned that dynamic methods of card authentication (online and offline) deal a crushing blow to this type of fraud. Not knowing the appropriate key card or the Issuer, or the system at the level of cryptographic security of the RSA algorithm in case of dynamic offline card authentication and Triple DES algorithm for online authentication chip card is impossible to forge.
At the same time, if the cards are incorrectly personalized or a weak card authentication method is selected, fraud of the “Fake card” type is possible. We will try to systematize possible ways to fake a card.
So, let’s imagine that in our left hand we have a real hybrid card issued by a member Bank of a certain payment system, and in our right hand we have a “clean” blank for a hybrid card or a card with a magnetic stripe. In addition, like any self-respecting fraudster, we have a programmer for the chip used on the card blank, a means of personalization of the card’s magnetic stripe, as well as a machine for personalization of plastic (printing, embossment, etc.).
Depending on which card is in our left hand, we will offer various methods of fraud such as “Fake card”, in which, based on the data of the left-hand card in the right hand, we will have a card that under certain circumstances can be successfully used in the payment network.
First of all, we will divide all possible methods of fraud into two classes: forgery of the chip and forgery of the magnetic stripe of the card.