Путешествия банковской транзакции

Некоторое время назад на Хабре уже мелькали посты о работе банкоматов: один ^[1] и два ^[2], но оба они описывали принципы работы банкоматов и вообще карточного процессинга весьма поверхностно.
Для интересующихся под катом много подробностей работы карточного процессинга банка (много букв).

Как выглядит упрощённая схема работы работы процессингового центра банка:

Процессинг

FrontEnd — отвечает за online сообщения: общение с банкоматами и POS-терминалами, передача авторизаций карт в VISA.
BackEnd — отвечает за offline: закрытие операционного дня, обмен финсообщениями с VISA.
HSM ^[3] (Hardware Security Module) — модуль работы с ключами безопасности (подробнее описано ниже)

Все шифрование производится с помощью алгоритма 3DES ^[4].

Подключение к VISA

Банк имеет два типа подключения к VISA:

• online
• offline

Online-подключение

Транспортный уровень
Подключение к VISA осуществляется через вполне конкретного провайдера, в 2006 году это бы Equant и его партнёры в России Golden Telecom, как обстоят дела сейчас — я не в курсе.

Получается, что VISA доступна в локальной сети одного провайдера. Это обязательное требование VISA. Для подключения провайдер прокладывает в банк собственный оптоволоконный кабель для основного канала связи и для резервного. Устанавливает конечные маршрутизаторы и выделяет по одному порту на каждом (основной и резервный). Управление маршрутизаторами осуществляется только провайдером.

Итак, связь транспортного уровня с VISA установлена, далее прикладной уровень.

Прикладной уровень
Связь прикладного уровня осуществляется по специальному протоколу, разработанному в VISA в незапамятные времена.

Кроме всего этого все сообщения должны передаваться зашифрованными. Для этого специальные люди — офицеры безопасности — генерируют ключевые последовательности заданной длины на HSM и результаты отправляются в VISA.

Оффлайн-подключение

Оффлайн-подключение — это не что иное, как обмен файлами с информацией обо всех транзакциях, совершённых за операционный день. То есть, если в банкоматах банка «А» были обслужены карты не банка «А». Подробнее об этом чуть ниже в сценарии «Чужой клиент в нашем АТМ».

Стоит немного рассказать про HSM.

HSM

HSM — это классический чёрный ящик. При инициализации он генерирует закрытую и открытую компоненту мастер-ключа банка. Закрытую компоненту никто никогда не видит, она всегда остаётся в памяти HSM.

Сам модуль имеет многочисленные уровни защиты от взломов: программного и физического. При малейшем намёке на компрометацию ключа память модуля самоуничтожается без возможности восстановления.

Три части открытой компоненты мастер-ключа записываются на 3 магнитные карты и выдаются офицерам безопасности банка.

Итак, связь с VISA установлена, и всё работает. Теперь нам надо выпускать карты.
При вступлении в VISA банку выдаются так называемые БИНы (Bank Identification Number): то есть подмножества номеров карт доступных для выпуска. Для VISA они всегда начинаются на 4.

БИНы распределены по карточным продуктам, например:

• VISA Classic: 400001
• VISA Gold: 400002
• VISA instant issue: 400003
• и так далее

Формат номера выглядит так: допустим, у нас есть карта с номером: 4408 0412 3456 7890

Номер карты состоит из:

• 4ХХХХХ — код VISA
• 4488(04) — код банка (код карточного продукта)
• 12 3456 7890 — номер лимита авторизации. Подробнее о лимите авторизации ниже.

Для интересующихся вот здесь ^[5] описано, как происходит валидация номера карты.

Для каждого БИНа генерируется пара ключей: IWK (issuer working key) и AWK (acquirer working key). Процедура генерации и передачи результата в VISA аналогична описанной выше.

После этого всё это добро прописывается в FrontEnd и BackEnd процессинга. В BackEnd для выпуска карт и их эмбоссирования, вo FrontEnd для обслуживания авторизаций.

Теперь у нас есть связь с VISA и есть выпущенные карты; другими словами, мы осуществили эмиссию карт. Нам осталось сделать эквайеринг.

Банкоматы

Не буду повторяться и описывать, что находится внутри банкомата, это уже описали здесь. Скажу только, что протокол NDC+ (NCR Direct Connect) разработан чёрт знает сколько лет назад корпорацией NCR ^[6] — одним из ведущих производителей банкоматов на сегодняшний день.

Широко известны три производителя:

• NCR
• Wincor Nixdorf GmBH (бывший Siemens Nixdorf)
• Diebold (бывший IBM)

Да, и Siemens и IBM когда-то давно производили банкоматы, но впоследствии продали этот бизнес Wincor Nixdorf и Diebold соответственно.
Ваш покорный слуга является сертифицированным инженером как раз таки Wincor Nixdorf. Однако, у нас был один стародавний IBM, который был выпущен ещё до продажи бизнеса и который работал.
Не скажу, что работал он как часы, ибо его всё время приходилось подкручивать и подлаживать, чтобы он хоть как-то дышал, но для него можно было купить запчасти. Правда, стоили они в три раза дороже чем аналогичные для Wincor Nixdorf.
Итак, мы выяснили что есть два протокола по которому работают банкоматы. Мне довелось работать лишь с NDC+, про DDC я только слышал, но никогда не видел.
Поскольку я близко знаком только с Wincor Nixdorf, предположим, что наш банк купил именно их.

Когда на банкомат поставлен софт ^[7], который управляет всеми его многочисленными устройствами — надо подготовить банкомат к работе.

Готовим банкомат

Обучение

Банкомат надо обучить выдавать купюры. Для этого есть специальная процедура: банкомат отсчитывает по 10 листов из каждой кассеты и предлагает оператору ввести реальное количество отсчитанных листов. Если реальное количество отличается — банкомат откорректирует оптопары в тракте выдачи и предложит повторить процедуру.

Из опыта у меня всего пару раз банкомат ошибался, то есть, как правило, они с завода уже неплохо откалиброваны.

Ключи шифрования

В банкомат загружают 2 ключа шифрования:
мастер-ключ (MASTER KEY) — используется для шифрования ПИН-блока введённого клиентом.
коммуникационный ключ (COMM KEY) — для шифрования пакета к FrontEnd процессинга.

На HSM генерируются открытая и закрытая компонента каждого ключа, после чего открытая компонента прописывается во FrontEnd, а закрытая загружается в банкомат.
Оба ключа загружаются в ПИН-клавиатуру (EPP Encrypted Pin Pad) и хранятся только там. По сути EPP — это такой маленький HSM, который не умеет генерировать ключи, но умеет очень хорошо их хранить. Когда я плотно работал с банкоматами — EPP имели 7 ступеней защиты от физического проникновения.

После этого прописываем адрес процессинга, настраиваем VPN или что там придумают бойцы телекоммуникаций, и можно загружать сценарий работы банкомата.

Сценарий

Про сценарий уже было сказано в статье, на которую я ссылался, хочу лишь немного добавить.
Весь сценарий банкомата основан на так называемых ФИТах (Financial Institution Table).
FIT — не что иное, как БИН банка выданный VISA.
Например: для нашего родного банка мы позволим делать переводы с карты на карту, возможность просмотреть детали по вкладу и внести наличные на карточный счёт в дополнение к обычным возможностям (баланс, выдача наличных), а для всех остальных только баланс и выдача.

Таким образом, мы должны загрузить неколько ФИТов в банкомат:

• 400001, 400002, 400003 — позволим всё и вся
• 999999 — только выдача и баланс

Сценарий проверяет номер карты клиента и работает по первому совпадению в ФИТ-таблице.

Итак, мы полностью подготовили весь комплекс к работе, осталось самое главное: совершить транзакцию.

Транзакиця

Самый простой сценарий: наш клиент в нашем АТМ:

1. Клиент вставляет карту в АТМ;
2. АТМ видит что клиент наш и выдаёт ему опции;
3. Клиент выбирает: выдача, 100 рублей
4. Банкомат шифрует ПИН-блок мастер-ключом;
5. Шифрует всё сообщение коммуникационным ключом и отправляет в FrontEnd;
6. FrontEnd получает сообщение;
7. по ID определяет банкомат (каждый банкомат подключается на свой собственный порт, так что ID получить проблем никаких);
8. Расшифровывает сообщение открытой компонентой коммуникационого ключа;
9. по БИН понимает, что карта наша;
10. Расшифровывает ПИН-блок открытой компонентой мастер-ключа;
11. Обрабатывает запрос на списание (есть ли деньги, не исчерпаны ли лимиты и всё такое прочее);
12. Зашифровывает сообщение открытой компонентой коммуникационого ключа;
13. Отправляет банкомату;
14. Банкомат расшифровывает сообщение;
15. Сообщает результат клиенту;
16. Уведомляет хост, что деньги выданы (так же с шифрованием и всем прочим).

Стоит отметить, что всё шифрование на стороне хоста осуществляется при помощи HSM.
То есть шаги 8 и 9 в деталях выглядят так:

1. Хост отправляет зашифрованный ПИН-блок, мастер-ключ и контрольную сумму на HSM;
2. HSM расшифровывает ПИН-блок;
3. Сверяет контрольную сумму после расшифровки с присланной;
4. Зашифровывает открытый ПИН-блок при помощи IWK и считает контрольную сумму;
5. Если контрольные суммы открытого ПИН-блока и зашифрованного IWK равны — ПИН введён верно.

Клиент получает свои 100 рублей и уходит довольный, однако это только половина дела.

В этот момент FrontEnd установил клиенту hold — заморозил на его лимите авторизации (доступная к снятию сумма) 100 рублей, но его текущий счёт никак не изменился.

Здесь стоит немного пояснить: в процессинге нет счетов клиентов — движение денег происходит по так называемым «лимитам авторизации». Фактически, лимит авторизации — не что иное, как карточный счёт клиента, но он никак не фигурирует в плане счетов и бухгалтерском балансе.

Другими словами, лимит авторизации есть техническая сущность, которая отражает состояние реального текущего счёта клиента в процессинге. Отличие лимита авторизации в том, что:

1. на лимит авторизации действуют лимиты процессинга: лимит на единоразовую выдачу, лимит на ежедневную выдачу и так далее;
2. лимит авторизации может изменяться в течение операционного дня, текущий счёт только в момент закрытия операционного дня.

Вечером текущего дня или утром следующего дня (но, как правило, это делается ночью) закрывается операционный день. Все авторизации карт и суммы холдов выгружаются из FrontEnd и загружаются в BackEnd, где и происходит движение денег по текущим счетам клиентов. После этого финальные отчёты выгружаются в Автоматизированную Банковскую Систему, где хранятся текущие счета клиентов. На основании этих отчётов происходит реальное движение денег, а также во FrontEnd — новые лимиты авторизации (наш клиент из примера выше получает новый лимит авторизации, который меньше на 100 рублей).

Теперь сложнее: Чужой клиент в нашем АТМ:

1. Клиент вставляет карту в АТМ;
2. АТМ понимает что клиент чужой, показывает ему только баланс и выдачу;
3. Клиент выбирает: выдача, 200 рублей
4. АТМ шифрует ПИН-блок мастер-ключом;
5. Шифрует сообщение коммуникационным ключом;
6. Отправляет сообщение на FrontEnd;
7. FrontEnd расшифровывает сообщение открытой компонентой коммуникационого ключа;
8. Определяет что БИН не наш и надо его отправить в VISA;
9. FrontEnd зашифровывает сообщение компонентой AWK (так как мы в данном случае эквайер) и отправляет в VISA;
10. VISA получает от нас сообщение, расшифровывает его второй компонентой нашего AWK и по БИНу определяет какого банка это карта;
11. Зашифровывает сообщение компонентой IWK (так как обращается к эмитенту) того банка, который выпустил эту карту и отправляет сообщение;
12. Банк-эмитент получает сообщение:
13. Расшифровывает сообщение при помощи закрытой компоненты IWK (тут сразу понятно что карта наша, БИН смотреть нет смысла);
14. Расшифровывает ПИН-блок;
15. Авторизует карту (даёт добро на выдачу 200 рублей);
16. Зашифровывает сообщение закрытой компонентой IWK и отправляет в VISA;
17. VISA расшифровывает открытой компонентой IWK банка-эмитента, зашифровывает открытой компонентой AWK нашего банка и отправляет нам;
18. Мы расшифровываем сообщение закрытой компонентой AWK;
19. Записываем результат транзакции;
20. Зашифровываем открытой компонентой коммуникационого ключа нужного банкомата и отправляем ему сообщение;
21. Банкомат получает сообщение, расшифровывает его и выдаёт клиенту деньги;
22. Уведомляет хост, что деньги выданы (опять же, шифрую все сообщения);
23. Мы уведомляем банк-эмитент, что деньги успешно выданы;

Это была только авторизация, то есть реальных денег никто никому не перечислил. Теперь нам надо получить финсообщение об этой транзакции и получить возмещение от другого банка: 200 рублей наших денег, которые мы выдали его клиенту.

1. Мы отправляем в VISA отчёт (оффлайном, медленно и печально) о том, что не наш клиент с номером карты таким-то получил 200 рублей в нашем банкомате;
2. VISA отправляет требование банку-эмитенту перечислить нам 200 рублей и ещё 0,5% от суммы транзакции, но не менее $3 самой VISA за то, что она провела транзакцию через себя. Это есть так называемый interchange fee;
3. Банк-эмитент получает файлы от VISA, закрывает свой операционный день в процессинге, потом закрывает день в Автоматизированной Банковской Системе и переводит через корр. банк VISA на наш счёт наших 200 рублей;
4. Рассчитывается с VISA (покрывает interchange fee)

Само собой, все такие расчёты осуществляются в долларах, и тут играет роль курсовая разница, но это уже совсем другая история…

Автор: retgoat

Источник ^[8]