Travel Banking Transaction

Some time ago, posts about the operation of ATMs flashed on Habré: one and two , but both of them described the principles of operation of ATMs and card processing in general very superficially.
For those interested in under the cat a lot of details of the card processing of the bank (a lot of letters).

How does the simplified scheme of the work of the processing center of the bank:


')

Processing

FrontEnd is 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 performed using the 3DES algorithm .

Connect 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 in the local network of one provider. This is a mandatory VISA requirement. To connect, the provider runs its own fiber-optic cable to the bank for the main communication channel and for the backup one. Installs end routers and allocates one port on each (primary and backup). Router management is carried out only by the provider.

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

Application layer
The application layer communication is carried out according to a special protocol developed at VISA in times immemorial.

In addition to all this, all messages must be transmitted encrypted. For 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 the exchange of files with information about all transactions made during the transaction day. That is, if the ATMs of Bank "A" were served cards not of Bank "A." More on this is slightly lower in the “Alien Client in our ATM” scenario.

It is necessary to tell a little about HSM.

HSM

HSM is a classic black box. During initialization, it generates a closed and open component of the master key of the bank. Nobody ever sees the 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 key compromise, the module's memory self-destructs without the possibility of recovery.

Three parts of the open master key components 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.
When 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
• and so on

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:

• 4 - 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, here is described how the card number is validated.

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

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

Now we have a connection with VISA and cards have been issued; in other words, we issued cards. It remains for us to do the acquiring.

ATMs

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

Three manufacturers are well known:

• NCR
• Wincor Nixdorf GmBH (formerly Siemens Nixdorf)
• Diebold (former IBM)

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

When a software is installed on the ATM that manages all its numerous devices, it is necessary to prepare the ATM for operation.

Preparing ATM

Training

ATM must be trained to issue notes. There is a special procedure for this: the ATM counts 10 sheets from each cassette and invites the operator to enter the actual number of sheets counted. If the actual quantity is different, the ATM will correct the optocouplers in the issue path and will suggest that you repeat the procedure.

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

Encryption keys

The ATM download 2 encryption keys:
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 open and closed components of each key are generated, after which the open component is written into FrontEnd, and the closed component is loaded into an ATM.
Both keys are loaded into the PIN keyboard (EPP Encrypted Pin Pad) and stored only there. In fact, EPP is such a small HSM that cannot generate keys, but can store them very well. When I worked closely with ATMs - the EPP had 7 levels of protection against physical intrusion.

After that, we write down the processing address, set up a VPN or whatever the telecommunications fighters will think up, and you can download the ATM operation script.

Scenario

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

Thus, we need to load several FITs into an ATM:

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

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

So, we have fully 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. Client chooses: issue, 100 rubles
4. The ATM encrypts the PIN with a master key;
5. Encrypts the entire message with the communication key and sends it to FrontEnd;
6. FrontEnd receives the message;
7. ID identifies the ATM (each ATM connects to its own port, so the ID get no problems);
8. Decrypts the message of the open component of the communication key;
9. BIN understands that our card;
10. Decrypts the PIN block with the open component of the master key;
11. It processes the request for write-off (is there any money, are the limits not exhausted, and so on);
12. Encrypts the message with the open component of the communication key;
13. Sends an ATM;
14. ATM decrypts the message;
15. Reports the result to the client;
16. Notifies the host that money has been issued (also with encryption and all the rest).

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

1. The host sends an encrypted PIN block, master key and checksum to the HSM;
2. HSM decodes a PIN block;
3. Verifies the checksum after decryption with the sent;
4. Encrypts an open PIN block using IWK and counts 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 - froze on its authorization limit (the amount available for withdrawal) of 100 rubles, but its current account did not change at all.

It is worth explaining a little here: there are no customer accounts in the processing - money flows along so-called “authorization limits”. In fact, the authorization limit is nothing more than a client's card account, but it does not 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 real current account of the client in processing. The difference of the authorization limit is that:

1. processing limits apply to the authorization limit: a limit on a one-time issue, a limit on a daily issue, and so on;
2. The authorization limit can be changed during the trading day, the current account is only at the moment of closing the trading 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 operational day closes. All card authorizations and hold amounts are unloaded from FrontEnd and loaded into BackEnd, where money flows through current customer 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 less than 100 rubles).

Now it is more difficult: Alien 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 the balance and issue;
3. Client chooses: issue, 200 rubles
4. ATM encrypts the PIN with a master key;
5. Encrypts the message with the communication key;
6. Sends a message to FrontEnd;
7. FrontEnd decrypts the message with the open component of the communication key;
8. Determines that the BIN is not ours and you need to send it to VISA;
9. FrontEnd encrypts the message with the AWK component (since 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, according to BIN, determines which bank it is;
11. Encrypts the message with the IWK component (as it refers to the issuer) of the bank that issued this card and sends the message;
12. The issuing bank receives the message:
13. Decrypts the message with the help of the closed IWK component (it is immediately clear that our card, BIN does not make sense to look);
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 component IWK and sends it to VISA;
17. VISA decrypts the open component IWK of the issuing bank, encrypts the open component AWK of our bank and sends it to us;
18. We decrypt the message with a closed AWK component;
19. Write the result of the transaction;
20. Encrypt the open component of the communication key of the ATM you need and send a message to it;
21. The ATM receives the message, decrypts it and gives the customer money;
22. Notifies the host that 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 an authorization, that is, no one transferred real money to anyone. Now we need to receive a financial message about this transaction and receive a refund from another bank: 200 rubles of our money, which we gave it to the client.

1. We send a report to VISA (offline, slowly and sadly) that it’s not our client who received the card number so that he received 200 rubles at our ATM;
2. VISA sends a request to the issuing bank to transfer 200 rubles to us and another 0.5% of the transaction amount, but not less than $ 3 by VISA itself for conducting the transaction through itself. This is the so-called interchange fee;
3. The issuing bank receives files from VISA, closes its transaction day in processing, then closes the day in the Automated Banking System and translates it through a correspondent. VISA bank to our account of our 200 rubles;
4. Calculated from VISA (covers interchange fee)

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

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

UPD2: And I discovered an article describing the software architecture for ATMs (XFS) in more detail: habrahabr.ru/post/93507