Некоторое время назад на Хабре уже мелькали посты о работе банкоматов: один и два, но оба они описывали принципы работы банкоматов и вообще карточного процессинга весьма поверхностно.
Для интересующихся под катом много подробностей работы карточного процессинга банка (много букв).
Как выглядит упрощённая схема работы работы процессингового центра банка:
Процессинг
FrontEnd — отвечает за online сообщения: общение с банкоматами и POS-терминалами, передача авторизаций карт в VISA.
BackEnd — отвечает за offline: закрытие операционного дня, обмен финсообщениями с VISA.
HSM (Hardware Security Module) — модуль работы с ключами безопасности (подробнее описано ниже)
Все шифрование производится с помощью алгоритма 3DES.
Подключение к 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 — номер лимита авторизации. Подробнее о лимите авторизации ниже.
Для интересующихся вот здесь описано, как происходит валидация номера карты.
Для каждого БИНа генерируется пара ключей: IWK (issuer working key) и AWK (acquirer working key). Процедура генерации и передачи результата в VISA аналогична описанной выше.
После этого всё это добро прописывается в FrontEnd и BackEnd процессинга. В BackEnd для выпуска карт и их эмбоссирования, вo FrontEnd для обслуживания авторизаций.
Теперь у нас есть связь с VISA и есть выпущенные карты; другими словами, мы осуществили эмиссию карт. Нам осталось сделать эквайеринг.
Банкоматы
Не буду повторяться и описывать, что находится внутри банкомата, это уже описали здесь. Скажу только, что протокол NDC+ (NCR Direct Connect) разработан чёрт знает сколько лет назад корпорацией NCR — одним из ведущих производителей банкоматов на сегодняшний день.
Широко известны три производителя:
- NCR
- Wincor Nixdorf GmBH (бывший Siemens Nixdorf)
- Diebold (бывший IBM)
Да, и Siemens и IBM когда-то давно производили банкоматы, но впоследствии продали этот бизнес Wincor Nixdorf и Diebold соответственно.
Ваш покорный слуга является сертифицированным инженером как раз таки Wincor Nixdorf. Однако, у нас был один стародавний IBM, который был выпущен ещё до продажи бизнеса и который работал.
Не скажу, что работал он как часы, ибо его всё время приходилось подкручивать и подлаживать, чтобы он хоть как-то дышал, но для него можно было купить запчасти. Правда, стоили они в три раза дороже чем аналогичные для Wincor Nixdorf.
Итак, мы выяснили что есть два протокола по которому работают банкоматы. Мне довелось работать лишь с NDC+, про DDC я только слышал, но никогда не видел.
Поскольку я близко знаком только с Wincor Nixdorf, предположим, что наш банк купил именно их.
Когда на банкомат поставлен софт, который управляет всеми его многочисленными устройствами — надо подготовить банкомат к работе.
Готовим банкомат
Обучение
Банкомат надо обучить выдавать купюры. Для этого есть специальная процедура: банкомат отсчитывает по 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 — только выдача и баланс
Сценарий проверяет номер карты клиента и работает по первому совпадению в ФИТ-таблице.
Итак, мы полностью подготовили весь комплекс к работе, осталось самое главное: совершить транзакцию.
Транзакиця
Самый простой сценарий: наш клиент в нашем АТМ:
- Клиент вставляет карту в АТМ;
- АТМ видит что клиент наш и выдаёт ему опции;
- Клиент выбирает: выдача, 100 рублей
- Банкомат шифрует ПИН-блок мастер-ключом;
- Шифрует всё сообщение коммуникационным ключом и отправляет в FrontEnd;
- FrontEnd получает сообщение;
- по ID определяет банкомат (каждый банкомат подключается на свой собственный порт, так что ID получить проблем никаких);
- Расшифровывает сообщение открытой компонентой коммуникационого ключа;
- по БИН понимает, что карта наша;
- Расшифровывает ПИН-блок открытой компонентой мастер-ключа;
- Обрабатывает запрос на списание (есть ли деньги, не исчерпаны ли лимиты и всё такое прочее);
- Зашифровывает сообщение открытой компонентой коммуникационого ключа;
- Отправляет банкомату;
- Банкомат расшифровывает сообщение;
- Сообщает результат клиенту;
- Уведомляет хост, что деньги выданы (так же с шифрованием и всем прочим).
Стоит отметить, что всё шифрование на стороне хоста осуществляется при помощи HSM.
То есть шаги 8 и 9 в деталях выглядят так:
- Хост отправляет зашифрованный ПИН-блок, мастер-ключ и контрольную сумму на HSM;
- HSM расшифровывает ПИН-блок;
- Сверяет контрольную сумму после расшифровки с присланной;
- Зашифровывает открытый ПИН-блок при помощи IWK и считает контрольную сумму;
- Если контрольные суммы открытого ПИН-блока и зашифрованного IWK равны — ПИН введён верно.
Клиент получает свои 100 рублей и уходит довольный, однако это только половина дела.
В этот момент FrontEnd установил клиенту hold — заморозил на его лимите авторизации (доступная к снятию сумма) 100 рублей, но его текущий счёт никак не изменился.
Здесь стоит немного пояснить: в процессинге нет счетов клиентов — движение денег происходит по так называемым «лимитам авторизации». Фактически, лимит авторизации — не что иное, как карточный счёт клиента, но он никак не фигурирует в плане счетов и бухгалтерском балансе.
Другими словами, лимит авторизации есть техническая сущность, которая отражает состояние реального текущего счёта клиента в процессинге. Отличие лимита авторизации в том, что:
- на лимит авторизации действуют лимиты процессинга: лимит на единоразовую выдачу, лимит на ежедневную выдачу и так далее;
- лимит авторизации может изменяться в течение операционного дня, текущий счёт только в момент закрытия операционного дня.
Вечером текущего дня или утром следующего дня (но, как правило, это делается ночью) закрывается операционный день. Все авторизации карт и суммы холдов выгружаются из FrontEnd и загружаются в BackEnd, где и происходит движение денег по текущим счетам клиентов. После этого финальные отчёты выгружаются в Автоматизированную Банковскую Систему, где хранятся текущие счета клиентов. На основании этих отчётов происходит реальное движение денег, а также во FrontEnd — новые лимиты авторизации (наш клиент из примера выше получает новый лимит авторизации, который меньше на 100 рублей).
Теперь сложнее: Чужой клиент в нашем АТМ:
- Клиент вставляет карту в АТМ;
- АТМ понимает что клиент чужой, показывает ему только баланс и выдачу;
- Клиент выбирает: выдача, 200 рублей
- АТМ шифрует ПИН-блок мастер-ключом;
- Шифрует сообщение коммуникационным ключом;
- Отправляет сообщение на FrontEnd;
- FrontEnd расшифровывает сообщение открытой компонентой коммуникационого ключа;
- Определяет что БИН не наш и надо его отправить в VISA;
- FrontEnd зашифровывает сообщение компонентой AWK (так как мы в данном случае эквайер) и отправляет в VISA;
- VISA получает от нас сообщение, расшифровывает его второй компонентой нашего AWK и по БИНу определяет какого банка это карта;
- Зашифровывает сообщение компонентой IWK (так как обращается к эмитенту) того банка, который выпустил эту карту и отправляет сообщение;
- Банк-эмитент получает сообщение:
- Расшифровывает сообщение при помощи закрытой компоненты IWK (тут сразу понятно что карта наша, БИН смотреть нет смысла);
- Расшифровывает ПИН-блок;
- Авторизует карту (даёт добро на выдачу 200 рублей);
- Зашифровывает сообщение закрытой компонентой IWK и отправляет в VISA;
- VISA расшифровывает открытой компонентой IWK банка-эмитента, зашифровывает открытой компонентой AWK нашего банка и отправляет нам;
- Мы расшифровываем сообщение закрытой компонентой AWK;
- Записываем результат транзакции;
- Зашифровываем открытой компонентой коммуникационого ключа нужного банкомата и отправляем ему сообщение;
- Банкомат получает сообщение, расшифровывает его и выдаёт клиенту деньги;
- Уведомляет хост, что деньги выданы (опять же, шифрую все сообщения);
- Мы уведомляем банк-эмитент, что деньги успешно выданы;
Это была только авторизация, то есть реальных денег никто никому не перечислил. Теперь нам надо получить финсообщение об этой транзакции и получить возмещение от другого банка: 200 рублей наших денег, которые мы выдали его клиенту.
- Мы отправляем в VISA отчёт (оффлайном, медленно и печально) о том, что не наш клиент с номером карты таким-то получил 200 рублей в нашем банкомате;
- VISA отправляет требование банку-эмитенту перечислить нам 200 рублей и ещё 0,5% от суммы транзакции, но не менее $3 самой VISA за то, что она провела транзакцию через себя. Это есть так называемый interchange fee;
- Банк-эмитент получает файлы от VISA, закрывает свой операционный день в процессинге, потом закрывает день в Автоматизированной Банковской Системе и переводит через корр. банк VISA на наш счёт наших 200 рублей;
- Рассчитывается с VISA (покрывает interchange fee)
Само собой, все такие расчёты осуществляются в долларах, и тут играет роль курсовая разница, но это уже совсем другая история…
Автор: retgoat
