Bank Transaction Travel

image

Some time ago, Habré had already flashed positions on the work of ATMs: one and two , but they both describe the operation of ATMs and card processing generally very superficial.
For those interested under the cut, there are many details of the card processing of the bank (many letters).

What does a simplified scheme of work of a bank processing center look like:

image

Processing

FrontEnd - responsible for online messages: communication with ATMs and POS-terminals, transfer of card authorizations to VISA.
BackEnd - responsible for offline: closing the trading day, exchanging financial messages with VISA.
HSM (Hardware Security Module) - a module for working with security keys (described in more detail below).

All encryption is done using the 3DES algorithm .

Connection to VISA

The bank has two types of connection to VISA:
  • online
  • offline


Online connection

Transport level
Connection to VISA is carried out through a very specific provider, in 2006 it was Equant and its partner in Russia - Golden Telecom, as things are now - I do not know.

It turns out that VISA is available on the local network of one provider. This is a required VISA requirement. To connect, the provider lays its own fiber-optic cable in the bank for the main communication channel and for the backup. Installs end routers and allocates one port on each (primary and backup). Routers are managed only by the provider.

So, the connection of the transport layer with VISA is established, then the application layer.

Application level
Communication of the application level is carried out according to a special protocol developed in VISA from time immemorial.

In addition to all this, all messages must be transmitted encrypted. To do this, special people - security officers - generate key sequences of a given length on the HSM and the results are sent to VISA.

Offline connection

An offline connection is nothing more than an exchange of files with information about all transactions completed during a business day. That is, if non-Bank A cards were served at ATMs of Bank A. More on this in the scenario “Alien client in our ATM” below.

It’s worth a little talk about HSM.

Hsm

HSM is a classic black box. Upon initialization, it generates a closed and open component of the bank master key. No one ever sees a closed component; it always remains in the HSM memory.

The module itself has numerous levels of protection against hacking: software and physical. At the slightest hint of a compromised key, the module’s memory self-destructs without the possibility of recovery.

Three parts of the open component of the master key are recorded on 3 magnetic cards and issued to bank security officers.

So, the connection with VISA is established, and everything works. Now we need to issue cards.
Upon joining VISA, the Bank is issued the so-called Bank Identification Number: that is, a subset of the card numbers available for issue. For VISA, they always start at 4.

BINs are distributed by card products, for example:

  • VISA Classic: 400001
  • VISA Gold: 400002
  • VISA instant issue: 400003
  • etc


The format of the number looks like this: let's say we have a card with the number: 4408 0412 3456 7890

The card number consists of:

  • 4XXXXX - VISA code
  • 4408 (04) - bank code (card product code)
  • 12 3456 7890 - authorization limit number. Read more about the authorization limit below.


For those interested, it is described here how the validation of the card number occurs.

For each BIN, a key pair is generated: IWK (issuer working key) and AWK (acquirer working key). The procedure for generating and transmitting the result in VISA is similar to that described above.

After that, all this stuff is registered in FrontEnd and BackEnd processing. In BackEnd for the issue of cards and their embossing, in FrontEnd for servicing authorizations.

Now we have a connection with VISA and have issued cards; in other words, we issued cards. We only have to do acquiring.

ATM

I will not repeat and describe what is inside the ATM, it is already described here. I can only say that the NDC + (NCR Direct Connect) protocol was developed by the devil knows how many years ago NCR Corporation , one of the leading ATM manufacturers today.

Three manufacturers are widely known:

  • Ncr
  • Wincor Nixdorf GmBH (formerly Siemens Nixdorf)
  • Diebold (formerly IBM)


Yes, both Siemens and IBM once produced ATMs for a long time, but subsequently sold this business to Wincor Nixdorf and Diebold respectively.
Your humble servant is a certified engineer just the same Wincor Nixdorf. However, we had one old-time IBM, which was released before the sale of the business and which worked.
I can’t say that he worked like a clock, because he had to tighten it all the time and adjust it so that he could breathe somehow, but you could buy spare parts for him. True, they cost three times more than the similar ones for Wincor Nixdorf.
So, we found out that there are two protocols by which ATMs work. I happened to work only with NDC +, I only heard about DDC, but I never saw it.
Since I am only familiar with Wincor Nixdorf, suppose that our bank bought them.

When software is installed on the ATM that controls all of its many devices, you need to prepare the ATM for work.

Cooking ATM

Training

An ATM must be trained to issue bills. There is a special procedure for this: the ATM counts 10 sheets from each cartridge and prompts the operator to enter the actual number of sheets counted. If the actual quantity is different, the ATM will correct the optocouplers in the delivery path and offer to repeat the procedure.

From experience I only had a couple of times the ATM was wrong, that is, as a rule, they are already well calibrated from the factory.

Encryption keys

2 encryption keys are loaded into the ATM:
master key (MASTER KEY) - used to encrypt the PIN block entered by the client.
communication key (COMM KEY) - to encrypt the packet to FrontEnd processing.

On HSM, the public and private components of each key are generated, after which the public component is registered in FrontEnd, and the private component is downloaded to the ATM.
Both keys are downloaded to the EPP Encrypted Pin Pad and stored only there. In essence, EPP is such a small HSM that cannot generate keys, but can store them very well. When I worked closely with ATMs - EPPs had 7 levels of protection against physical penetration.

After that, we prescribe the processing address, set up a VPN or whatever telecommunication fighters will come up with, and you can download the ATM operation scenario.

Scenario

About the script has already been said in the article to which I referred, I want to add only a little.
The entire ATM scenario is based on the so-called FITs (Financial Institution Table).
FIT is nothing but a BIN of a bank issued by VISA.
For example: for our native bank, we will allow you to make transfers from card to card, the ability to view the details of the deposit and deposit cash into the card account in addition to the usual options (balance, cash withdrawal), and for all others only balance and issue.

Thus, we need to load some FITs into the ATM:

  • 400001, 400002, 400003 - let's allow everything and everyone
  • 999999 - only extradition and balance


The script checks the client card number and works by the first match in the FIT table.

So, we have completely prepared the whole complex for work, the most important thing remains: to complete the transaction.

Transaction

The simplest scenario: our client in our ATM:

  1. The client inserts the card into the ATM;
  2. ATM sees that our client and gives him options;
  3. The client chooses: issuance, 100 rubles
  4. The ATM encrypts the PIN block with a master key;
  5. Encrypts the entire message with a communication key and sends it to FrontEnd;
  6. FrontEnd receives the message;
  7. identifies an ATM by ID (each ATM connects to its own port, so there are no problems getting the ID);
  8. Decrypts the message with the open component of the communication key;
  9. according to BIN, understands that our card;
  10. Decrypts the PIN block with the open component of the master key;
  11. Processes a request for write-off (is there money, are there any limits exhausted, and so on);
  12. Encrypts the message with the open component of the communication key;
  13. Sends to an ATM;
  14. ATM decrypts the message;
  15. Reports the result to the client;
  16. Notifies the host that the money has been issued (also with encryption and everything else).


It is worth noting that all host-side encryption is done using HSM.
That is, steps 8 and 9 in detail look like this:

  1. The host sends the encrypted PIN block, master key and checksum to the HSM;
  2. HSM decrypts the PIN block;
  3. Checks the checksum after decryption with the sent one;
  4. Encrypts an open PIN block using IWK and reads the checksum;
  5. If the checksums of the open PIN block and the encrypted IWK are equal, the PIN is entered correctly.


The client receives his 100 rubles and leaves satisfied, but this is only half the battle.

At this point, FrontEnd set the client to hold - it froze 100 rubles on its authorization limit (the amount available for withdrawal), but its current account did not change.

Here it’s worth a little clarification: there are no customer accounts in processing - money flows according to the so-called “authorization limits”. In fact, the authorization limit is nothing more than a client’s card account, but it doesn’t appear in the chart of accounts and balance sheet.

In other words, the authorization limit is a technical entity that reflects the state of the client’s real current account in processing. The difference in the authorization limit is that:

  1. the authorization limit is subject to the processing limits: limit for one-time issuance, limit for daily issuance, and so on;
  2. the authorization limit may change during the operational day, the current account only at the time of closing the operational day.


In the evening of the current day or in the morning of the next day (but, as a rule, this is done at night), the trading day closes. All card authorizations and hold amounts are downloaded from FrontEnd and uploaded to BackEnd, where the money flows on customers' current accounts. After that, the final reports are uploaded to the Automated Banking System, where current customer accounts are stored. Based on these reports, there is a real movement of money, as well as in FrontEnd - new authorization limits (our client from the example above receives a new authorization limit, which is 100 rubles less).

Now it’s more difficult: Another client in our ATM:

  1. The client inserts the card into the ATM;
  2. ATM understands that the client is a stranger, shows him only balance and issuance;
  3. The client chooses: issuance, 200 rubles
  4. ATM encrypts the PIN block with a master key;
  5. Encrypts the message with a communication key;
  6. Sends a message to FrontEnd;
  7. FrontEnd decrypts the message with the public component of the communication key;
  8. Determines that the BIN is not ours and must be sent to VISA;
  9. FrontEnd encrypts the message with AWK (as we are an acquirer in this case) and sends it to VISA;
  10. VISA receives a message from us, decrypts it with the second component of our AWK, and identifies which bank this card is by BIN;
  11. Encrypts the message with the IWK component (as it addresses the issuer) of the bank that issued this card and sends the message;
  12. The issuing bank receives the message:
  13. Decrypts the message using the closed IWK component (it is immediately clear that our card, BIN, it makes no sense to watch);
  14. Decrypts the PIN block;
  15. Authorizes the card (gives the go-ahead for the issuance of 200 rubles);
  16. Encrypts the message with the closed IWK component and sends it to VISA;
  17. VISA decrypts with the open component IWK of the issuing bank, encrypts with the open component AWK of our bank and sends it to us;
  18. We decrypt the message with the closed AWK component;
  19. We write the result of the transaction;
  20. We encrypt with the open component of the communication key of the desired ATM and send him a message;
  21. The ATM receives a message, decrypts it and gives the client money;
  22. Notifies the host that the money has been issued (again, I encrypt all messages);
  23. We notify the issuing bank that the money has been successfully issued;


It was only authorization, that is, no one transferred real money to anyone. Now we need to get a financial message about this transaction and get a refund from another bank: 200 rubles of our money, which we issued to its client.

  1. We send a report to VISA (offline, slow and sad) that not our client with the card number got 200 rubles at our ATM;
  2. VISA sends a request to the issuing bank to transfer 200 rubles and another 0.5% of the transaction amount to us, but not less than $ 3 of VISA itself because it conducted the transaction through itself. This is the so-called interchange fee;
  3. The issuing bank receives files from VISA, closes its processing day in processing, then closes the day in the Automated Banking System and transfers it through correspondent. VISA bank to our account of our 200 rubles;
  4. Calculated with VISA (covers interchange fee)


Of course, all such calculations are made in dollars, and the exchange rate difference plays a role, but this is a completely different story ...

UPD: In the comments, Comrade Spewow provided a link to an article about HSM and cryptography

UPD2: And I found an article where more details The ATM software architecture (XFS) is described: habrahabr.ru/post/93507

Also popular now: