The article deals with popular myths and scenarios of fraud with contactless payment systems using the example of a real POS terminal, PayPass / payWave cards and phones with the Google Pay / Apple Pay feature.

Topics covered:
')

• Is it really possible to steal money by leaning against a pocket with a POS terminal? - we will try to fully reproduce this scenario of fraud from beginning to end, using a real POS-terminal and payment cards in real conditions.
• What is the difference between physical and virtual Apple Pay cards? - how the physical card and the Apple Pay token are linked, and why Apple Pay is many times safer than a regular card.
• We use a hardware NFC-sniffer (ISO 14443A) - we will use the HydraNFC device to intercept data between the POS terminal and the card. Consider what confidential data can be extracted from intercepted traffic.
• We analyze the EMV protocol - what data the card exchanges with the POS terminal, the request format used, mechanisms for protecting against fraud and replay attacks.
• We investigate operations without a card (CNP, MO / TO) - in which cases it is actually (!) Possible to steal money from a card, having only the requisites, which are considered contactless, and in which it is impossible.

Attention!

The article describes in detail a hypothetical scheme of fraud, from beginning to end, through the eyes of a fraudster, in order to cover all aspects in which myths and delusions are cultivated. Despite the provocative title, the main conclusion of the article is that contactless payments are fairly safe, and attacks on them are time consuming and unprofitable .

The materials in the article are presented for informational purposes only. All scenes of the demonstration of fraud are staged and performed with the consent of the persons participating in them. All debited money from the cards were returned to their owners. Theft of money from cards is a criminal offense and is prosecuted.

How it works?

To begin with, we will consider the basic concepts: any movement of money using payment cards is possible only through intermediaries connected to the payment system, for example, VISA or MasterCard. Unlike transfers between individuals, debiting money from a card is available only to a legal entity (merchant) that has an acquiring agreement with a bank.


Transaction stages when paying via POS-terminal

The illustration above shows the classic payment scheme through the POS terminal. It is this sequence of actions that occurs when, after payment at the checkout, you are awaiting confirmation at the terminal.

1. The buyer applies / inserts / inserts the card into the POS terminal;
2. POS-terminal via the Internet transmits data to the acquiring bank;
3. The acquiring bank, through the international payment system (IPS), applies to the issuing bank and asks whether the particular cardholder can pay for the purchase;
4. The issuing bank confirms or rejects the purchase, after which the slip is printed (second check).

There are exceptions to this scheme, for example offline transactions, we will look at them further. Also, if the acquiring bank and the issuing bank are the same bank, steps 2 and 4 are performed inside the same bank.

Merchant - a person or organization providing goods or services

Acquiring bank - a bank that provides the seller with the services of accepting payments through bank cards. In this bank, usually, there is a seller’s bank account where the money debited from the card is credited.

Issuing bank - the bank that issued the card. It is the account of the cardholder, who debited the money.

The International Payment System (IPS) is an international intermediary system between banks around the world, allowing banks to make payments among themselves without entering into an agreement with each bank separately. All banks connected to the IPU, agree to work according to the same rules, which greatly simplifies the interaction. For example, Visa, MasterCard, UnionPay, American Express, WORLD (no, WORLD does not work abroad).

Cardholder - a person who has entered into a card service agreement with an issuing bank.

What is the difference between a regular Apple Pay or Google Pay card?

The procedure for linking a bank card to an Apple Pay or Google Pay system, due to the incomprehensibility of the process, often leads to confusion even among IT professionals. I have heard many different myths about this technology.

Popular Apple Pay Myths

• The card is copied to the phone
  This is not the case; the microprocessor card contains a protected memory area with cryptographic information that cannot be extracted after the card has been released. Because of this, a chip card cannot be copied, in any way, at all. For the sake of fairness, it must be said that such attacks are possible, but their value exceeds the total amount of money that most readers of this article will spend in their entire life.
• The phone connects to the Internet each time at the time of payment.
  Google Pay / Apple Pay does not connect to the Internet at the time of payment through the POS-terminal. All the necessary information is stored locally on the phone.
• For each payment a new card number is generated (PAN)
  So it may seem, if you read Apple's press releases on Apple Pay technology. But this is an erroneous interpretation of the concept of a token. In fact, the details of the virtual card remain unchanged for a long time, you can check it with the latest digits of the card number in the slip (check) when paying for purchases.
• Paying Apple Pay / Google Pay charges an additional fee.
  This is not the case; you will pay exactly as much as indicated on the price tag, and according to the terms of your agreement with the issuing bank whose card you have attached.
• Money can be written off twice
  This myth concerns not only Google Pay / Apple Pay, but also ordinary bank cards. I believe that it appeared because of the public transport payment systems, in which the terminal writes off money from a ticket each time it is presented, so you can write off funds two or more times if you do not carelessly hold the card. In the case of POS terminals, this risk does not exist, since the terminal stops exchanging with the card as soon as it receives the necessary data.

Linking a physical card to a "token" in the phone

Systems like Apple Pay operate on the basis of the EMV Payment Tokenisation Specification . The procedure for associating a physical card and phone with Apple Pay is not described publicly, so we will analyze the process based on known data:

1. The vendor (Google, Apple, Samsung) gets the card information;
2. Through the IPS, the provider asks if the card (this issuing bank) supports EMV Tokenisation;
3. On the side of the IPS, a virtual card (token) is generated, which is loaded into the secure storage in the phone. I don’t know exactly where the private key of the virtual card is generated, whether it is transmitted via the Internet or generated locally on the phone, in this case it does not matter.
4. A generated virtual token card appears in the phone, the operations for which the issuing bank interprets as operations on the first physical card. In the case of blocking a physical card, the token is also blocked.

Apple Pay allows you to read the details of a virtual card. PAN number and expire date differ from the linked Alfa Bank Russian card. By BIN of a virtual card (480099) MBNA AMERICA BANK is determined.

When paying by phone, the POS terminal sees a regular VISA or MasterCard card, and communicates with it in the same way as with a physical card. A virtual token card contains all the attributes of a regular card: PAN number, expiration date, and so on. In this case, the virtual card number and expiration date differ from the associated original card.

Scenario 1 - regular POS terminal

Scammer armed with a POS terminal

The most popular plot of fraud in the heads of ordinary people: a fraudster clings to them in the crowd with the terminal turned on and writes off money. We will try to reproduce this scenario in reality.

The conditions are as follows :

• A fraudster has a fully working ordinary POS terminal connected to an acquiring bank, the same as in stores and couriers. Terminal firmware is not modified. In our case, the Ingenico iWL250. This is a portable POS terminal with a GPRS modem that supports contactless payment, is battery operated and is fully mobile.
• The fraudster does not use additional technical means, only the POS-terminal
• The debited funds are credited to the account of the fraudster, according to all the rules of banking systems

Entity

To begin, we will need a legal entity with a checking account and connected acquiring. We, like real scammers, will not issue anything in our name, but try to buy a ready-made legal entity. face on the site for the same scam. To do this, look at the ads from the first page of Google on the request "buy ip" and "buy ooo".


Offers for sale of ready-made companies from fraudsters (clickable)

The price of the company on the black market with a current account ranges from 20 to 300 thousand rubles. I managed to find several offers of LLC with a POS-terminal from 200 thousand rubles. Such companies are issued to nominees, and the buyer receives the entire package of documents, along with the “cash card” - this is a bank card tied to the checking account of the front company. With such a card, a fraudster can cash money at an ATM.

For simplicity, we assume that the LLC + settlement account + acquiring and POS-terminal will cost the scammer 100,000 rubles . In fact, more, but we will simplify the life of our hypothetical fraudster, reducing the cost of the attack. After all, the lower the cost of the attack, the easier it is to implement.

We go to steal money

So, the fraudster received a POS terminal and is ready to go to a crowded place to lean against the victims and steal money from his pockets. In our experiment, all the victims were previously instructed about our intentions, and all attempts to write off money were made with their consent. In cases where the subjects did not have their own contactless bank cards, they were asked to put our card in the wallet. Previously, the subjects found out exactly where and how they stored their cards, so the scammer knew in advance where the contactless card was in the bag / pocket.


Video: The crook raged at the mall

In case of a successful write-off, the transaction was canceled through the terminal menu, and the money was returned to the account of the subjects. For all the time of the experiment, we tried to “steal” the money from 20 subjects in the building of the shopping center and on the street. The test result is described below.

Issue: PIN-free transaction limit

The limit on the maximum amount of the transaction without confirmation by the PIN code can be set both on the POS terminal itself (CVM Required Limit) and on the bank side. In Russia, this limit is 1000‚₽.

---

UPD In the card settings, the authorization type of the Cardholder verification methods (CVMs) can be set as a signature on the check. In this case, the contactless transaction will pass on any amount without a PIN code.

---

Our fraudster decides to write off at 999.99 rubles at a time. If a repeated attempt to write off the amount below the limit in a short time period is requested, the PIN code will also be requested and, in most cases, it will not be possible to write off 999.99 rubles several times in a row. Therefore, the most optimal strategy would be no more than one write-off from one card.


In Russia, the maximum amount of a debit without a PIN is 1000 rubles.

In fact, a lot of write-offs with the amount of 999.99 rubles in a short period of time can trigger the antifraud system on the side of the equator bank, therefore such a strategy is not optimal for a fraudster. So, in real life, he would have to choose more diverse amounts, thereby reducing the potential income.

By the way, many articles on this topic in Russian state that you can manually set your own limit on contactless operations without a PIN code. I did not manage to find such an option in the main Russian banks. Maybe you know about this opportunity? This is about contactless payments, not any chip & pin transactions.

Problem: Several cards in the wallet

This is an important point in this attack scenario, because in reality almost no one carries a single card in his pocket. In most cases, the card is stored in a wallet along with other contactless cards, such as travel tickets or other bank cards.


Specifically, my Igenico iWL250 terminal, when it detects more than one card with SAK in the action field, indicates support for the 14443-4 protocol, returns an error: “present one card”.

But not all terminals do this. For example, VeriFone Savings Bank POS Terminals choose a random card from several. Some terminals simply ignore all cards, if there are more than one, without showing error messages.


Attempt to count several cards in the wallet. The POS terminal returns an error.

Anticollision ISO 14443-3

Reading one particular card from several is not an easy task at the physical level. To solve this problem, there is a mechanism of anti-collisions. It allows you to select one card if a response was received from several cards at once. This is the very first stage of establishing communication with a contactless card in the ISO-14443A protocol. At this stage, the reader is not able to find out which of the submitted cards is banking. The only option is to choose more or less similar to a bank card, based on the answer SAK (Select Acknowledge).

The value of the bits in the SAK response

So, for example, the “Troika” card (Mifare standard) used in Moscow public transport has the value SAK = 0x08 (b00001000) , in which the sixth bit is zero. While all bank cards in the SAK answers, the sixth bit is 1, which means support for the ISO 14443-4 protocol.

Therefore, all that a terminal can do when it detects several cards at the same time is to exclude cards that do not support ISO 14443-4, and choose one similar to a bank card. Support of the ISO 14443-4 protocol, by the way, does not guarantee that this card will be a bank, but most likely there will not be any other type of cards supporting ISO 14443-4 in the wallet of an ordinary person.


A block diagram of the operation of the anticollision protocol

From personal experience: in spite of the presence of the anti-collision protocol, if there are at least three contactless cards in the wallet, it is extremely difficult to read the correct card successfully . Most attempts fail with reading errors. Moreover, it is difficult to do this on the run, clinging to other people's pockets and bags.

However, we will assume that our fraudster is very lucky, and this restriction does not bother him.

Offline vs Online Transactions

In the frightening news stories they tell about fraudsters with POS-terminals in subway cars, who write money from your pockets right on the way. In these plots it is not mentioned where the mobile Internet in the subway car is from. Perhaps his terminal supports offline transactions?

EMV specifications allow for offline transactions. In this mode, the cancellation takes place without online confirmation from the issuing bank. It works, for example, in public transport in Moscow and St. Petersburg. In order not to take a queue at the entrance to the bus, while the terminal completes the online confirmation, you are immediately skipped without checking whether you have enough money in your account to pay for the fare. At the end of the day, when the Internet appears on the terminal, the signed transactions are sent to the issuing bank. If it turns out that at this moment you have no money to pay for travel, the card will be added to the stop list at all terminals in the city. Debt can be repaid through your personal account by card number. Read more about the fare in the bus of St. Petersburg.

Personally, I was not able to get a POS terminal that supports this feature, so in the scenario with the usual “civilian” POS terminal we will not consider the possibility of offline write-offs. This does not change anything, except that the attacker will need to have Internet access at the terminal, so the attack, for example, in the metro, is much more complicated.
There are terminal models that support WiFi, and in theory our scammer could use WiFi in the subway, after taking care of buying ad-free access to the MAC address of his POS terminal, so as not to have to perform authentication through the captive portal, since on the POS- the terminal cannot do this.

Counting profit

In our scenario, the cost of the attack was 100,000 rubles. This means that in order to at least return investments, our hero needs to complete at least 100 transactions of 1 thousand rubles each. Imagine that he was rather agile and ran around the city all day, clinging to everyone in a row, so that by the end he made 120 successful write-offs. We will not take into account the acquiring commission (2% on average), the cashing commission (4-10%) and other commissions.

Can he successfully cash out using a card linked to a current account?

The reality is not so simple. Money will be credited to the fraudster account in only a few days! During this time, our fraudster should hope that none of the one hundred and twenty victims will dispute the transaction, which is highly unlikely. Therefore, in reality, the fraudster’s account will be blocked before the money is credited to it.

If a person noticed that a purchase was made on his card, which he did not make, he should contact the issuing bank and file a claim. It takes up to 30 days to consider disputable operations on the territory of Russia, and up to 60 days for operations performed abroad. During this time, the issuing bank sends a request to the acquiring bank, and if the acquiring bank confirms the fact of performing suspicious transactions, the terminal and funds in the current account of the owner of the terminal are blocked.

Alexander Paderin, Managing Director of the Information Security Center of the Ural Bank for Reconstruction and Development (UBRD)

Conclusion

The cost of the attack in our scenario is $ 100,000. In fact, it will be several times higher, so the fraudster will need much more effort in order to make a profit.

In our scenario, a fraudster always charges at 999.99 rubles, which most likely will entail the triggering of the anti-fraud system on the side of the acquiring bank. In reality, the fraudster will need to write off smaller amounts.

To at least recoup the investment, the fraudster will need to handle several hundred victims. Even if a dozen of them turn to the issuing bank and challenge the transaction, the fraudster's account is likely to be blocked. A scenario in which the acquiring bank is in collusion with a fraudster is unlikely, because a license to work with an IPU costs much more than any potential profits from this type of fraud.

Of the 20 subjects, only three managed to write off money from the card, which is 15% of the success of all attempts. These were the artificial cases in which only one card was in the pocket. In cases with a wallet and several cards, the terminal returned an error. In a scenario with a terminal that uses a modified firmware and implements an anti-collision mechanism, the percentage of successful write-offs may be higher. However, even in the case of the use of anticollisions, in real conditions on the run, it is so difficult to count one of several cards that successful write-off in such conditions can be considered luck. In reality, the share of successful write-offs will hardly be higher than 10% of the number of attempts.

So, despite the fact that in theory such an attack is possible, in practice it turns out to be unprofitable and extremely difficult to implement. The chance to get at least some profit is so small that it deprives of meaning the whole idea.

Scenario 2 - Evil POS Terminal

Suppose our scammer works at the checkout in the store or by courier with a mobile POS-terminal. In this case, he has the opportunity to catch the card data, which, in some case, may be enough to pay online.

To begin with, let's look at exactly how a contactless transaction looks and what data the card exchanges with the POS terminal. Since we are too lazy to read thousands of pages of the EMV Contactless Specifications documentation, we simply intercept the exchange at the physical level using the HydraNFC sniffer.

There is some difference between the EMV specification for MasterCard PayPass and Visa payWave. This is the difference in the format of the signature and some data. But for us it is irrelevant.

NFC sniffer

HydraNFC is a fully open-source standalone ISO-14443A sniffer that saves captured APDU commands to an SD card. The sniffer antenna is placed between the terminal and the card, and passively captures all the transmitted information.

→ Website about HydraBus and HydraNFC shild
→ firmware sources


Demonstration of the interception of exchange between the POS-terminal and the phone with Apple Pay

Looking ahead, I must say that at this level, payment by phone and a regular plastic card is no different. For a POS terminal, this is a regular VISA card. However, payment by telephone is much safer than with a physical card, and we will further examine why.

EMV protocol parsing

Here’s what a recorded dump looks like when paying for chocolates and a bottle of water with a total cost of 142.98 rubles using Apple Pay:


.

R>> — , POS-
T>> — , ( Apple Pay)

14443-A Select

. , OSI, L2, UID (Unique Identifier) MAC- .

ISO-14443:
PCD (proximity coupling device) — , POS-
PICC (proximity integrated circuit card) — ,

Apple Pay , . , , , . , , .

R>> 52 // WUPA (wake up)
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
T<< 04 00 // ATQA (Answer To Request type A) 
R>> 93 20 // Select cascade 1 (Anti Collision CL1 SEL)
T<< 08 fe e4 ec fe // UID (4 bytes) + BCC (Bit Count Check)
R>> 93 70 08 fe e4 ec fe dd 6e // SEL (select tag 0x9370) + UID + CRC16
T<< 20 fc 70  // SAK (Select Acknowledge 0x20) + CRC16 
R>> 50 00 57 cd // HALT (Disable communocaion 0x5000) + CRC16
R>> 26 // REQA
R>> 52 // WUPA
T<< 04 00 // ATQA
R>> 93 70 08 fe e4 ec fe dd 6e // SELECT
T<< 20 fc 70 // SAK
R>> e0 80 31 73 // RATS (Request Answer to Select 0xE080) + CRC16
T<< 05 78 80 70 02 a5 46 // ATS (Answer to select response)

0x52 Wake-up (WUPA), , Answer To Request type A (ATQA), 0x04 0x00. ATQA .

ATQA, , , . 0x93 0x20 Select cascade level 1 (SEL CL1) UID.

0x08 0xFE 0xE4 0xEC 0xFE, — UID Apple Pay 0xFE Bit Count Check (BCC) .

, 0x93 0x70 (SELECT). UID 0x08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0x6e CRC16.

0x20 Select Acknowledge (SAK) + 0xfc 0x70 CRC16.

SAK, UID SELECT, . , , POS- , , .

UID 4, 7 10 . , , Apple Pay, UID 4 . , Apple Pay UID , , UID . , , , UID .

0x50 0x00 HALT + 0x57 0xcd CRC16. .

, (WUPA), , SELECT. — , , - .

0xE0 0x80 Request Answer to Select (RATS) + 0x31 0x73 CRC16.

0x05 0x78 0x80 0x70 0x02 Answer to select response (ATS) + 0xA5 0x46 CRC16.

Answer to select — Answer To Reset (ATR) . .

«» , , , . SELECT ISO 14443A, NFC-, , ..

— SELECT PPSE

: EMV Contactless Specifications — PPSE and Application Management for Secure Element

EMV- PPSE (Payment System Environment). , .

, — VISA. , , . , , . JCB UnionPay. .

APDU- SELECT PPSE

'00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00'
  00 A4 04 00 //  select 
   0E //  command data (14 )
    32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 // command data 2PAY.SYS.DDF01
    00 //  

SELECT PPSE

'6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 03 10 10 87 01 01 90 00'

- TVL iso8583.info/lib/EMV/TLVs. , :


(AID). , A0000000031010, Visa International.

AID 4F. , . , AID 5 16 , 7 .

AID: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix

AID

A0000000031010 Visa International
A0000000032020 Visa International
A0000000041010 Mastercard International
A0000000043060 Mastercard International United States Maestro (Debit)

Application Priority Indicator — . , , , , . Visa International, , .

— SELECT AID

'00 A4 04 00 07 A0 00 00 00 03 10 10'
  00 A4 04 00 //  select 
   07 //  command data (7 )
    A0 00 00 00 03 10 10 // AID Visa International

, .

PDOL (Processing Options Data Object List)

'6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00'

, — PDOL (Processing Options Data Object List). .

PDOL . PDOL — . PDOL .

PDOL . , — . .

PDOL:

9F 38 18 //   PDOL.  18 (24 ) 
 9F 66 ( 04) // Terminal Transaction Qualifiers (TTQ).    . 
  9F 02 ( 06) //  
   9F 03 ( 06) //  
   9F 1A ( 02) //     ISO3166-1
   95 ( 05) // Terminal Verification Results
    5F 2A ( 02) //  ,    ,   ISO4217
     9A ( 03) //    YYMMDD
      9C ( 01) //   
       9F 37 ( 04) //   

.

— GET PROCESSING OPTIONS

'80A8000023832136A0400000000001429800000000000006430000000000064318091800E011010300'
 80 A8 00 00 //  GET PROCESSING OPTIONS (GPO)
  23 //    (35 )
   83 //  PDOL-
    21 //  PDOL- (33 )
     36 A0 40 00 // Terminal Transaction Qualifiers (TTQ)
      00 00 00 01 42 98 //   (142,98 )
       00 00 00 00 00 00 //   
        06 43 //    (643 - )
         00 00 00 00 00 // Terminal Verification Results (TVR)
          06 43 //  (643 - russian ruble) 
           18 09 18 //  (18  2018 )
            00 //  
             E0 11 01 03 //   

, , , 142,98 . (E0110103). 9F37 Unpredictable Number. . . replay .

GET PROCESSING OPTIONS

'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'

VISA , c VISA Contactless Payment Specification (VCSP).



Application Interchange Profile (AIP) — . AIP 00 40. EMV 4.3 Book 3.


, , , Reserved For Future Use (RFU). , Apple Pay, .

AIP (SDA,CDA,DDA) . — .

Application File Locator (AFL) — (SFI range of records) AID. READ RECORD.

AFL :

Short File Identifier (SFI) 0x18. . 0x18 (b00011000) b00000011, 0x3.
First record = 1
Last record = 1
.. «» №3 1 1, .

Application Transaction Counter (ATC) — , GET PROCESSING OPTIONS. 0xFFFF 0x7FFF, . , . , Apple Pay 518 (0x206) .

Application Cryptogram (AC) — , . -, . ( ) , .

Issuer Application Data (IAD) — , VISA. , .

Card Transaction Qualifiers (CTQ) — VISA c . , , .

Track 2 Equivalent Data — ! expiration date, .

Form Facto Indicator (FFI) — VISA . - . , .

Cryptogram Information Data (CID) — , .

READ DATA RECORD

'00 b2 01 1c 00'

, AFL:


, 0x1C , 0x18 (b000011), SFI, 0x04 (d100), .

READ RECORD

'70375F280206439F0702C0009F19060400100302735F3401009F241D5630303130303134363138303430313737313031333936313637363235'

Application Usage Control (AUC) — , , .

9F19 — - , — Dynamic Data Authentication Data Object List (DDOL)

EMV Tokenisation, Payment Account Reference (PAR) — () . , .

?

Apple Pay c VISA. MasterCard , . , , replay-. Magnetic Stripe (MSD), replay-, , , , , .


(PAN) (expiration date)

, expiration date. CVV , -. , PAN , !

CVV (CNP, MO/TO)

« Apple Pay » Apple Pay , , 10 . , expiration date. , . , .


Amazon CVV

, , Apple Pay Client Present (CP), . Card not present (CNP), . - !

, , Apple Pay , . 5 . :)

Apple Pay

Apple Pay vs

• Apple Pay ( ) . POS-. , «» , , , , , . Apple Pay , , .
• — Apple Pay (13,56 ), , . . Apple Pay , .
• — Card not present (CNP), , .. Apple Pay .
• — (Cardholder name) . , , . Apple Pay .

. , . .

, Apple Pay . CNP- ( ) , .

---

:

• tehpos.ru .
• , ( ) .
• aj.ru .
• Aquamine .
• JRun Digital Security .
• AlexGre EMV.
• shape EMV: iso8583.info