[Из песочницы] Путешествия банковской транзакции
Некоторое время назад на Хабре уже мелькали посты о работе банкоматов: один и два, но оба они описывали принципы работы банкоматов и вообще карточного процессинга весьма поверхностно.Для интересующихся под катом много подробностей работы карточного процессинга банка (много букв).Как выглядит упрощённая схема работы работы процессингового центра банка:
Процессинг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) Само собой, все такие расчёты осуществляются в долларах, и тут играет роль курсовая разница, но это уже совсем другая история…
