Реализация транзакций в протоколе set
Опишем теперь типы транзакций, используемых в протоколе SET. В протоколе SET сообщения, с помощью которых реализуются различные транзакции, имеют парный характер (запрос-ответ), Payment Initialization Request/Response Messages. Эта пара сообщений используется для взаимной аутентификации владельца карты и торговой точки, для передачи владельцу карты от торговой точки необходимых сертификатов и списков CRL, а также предоставления информации торговой точки о том, карта какой платежной системы будет использоваться при проведении покупки.
Purchase Order Request/Response Messages. Эта пара сообщений служит для передачи в защищенной сессии от владельца карты к торговой точке информации о заказе (сумма покупки, валюта, номер торговой точки и т. п.) и реквизитах карты владельца карты.
Authorization Request/Response Messages. Запрос Authorization Request инициируется торговой точкой и передается платежному шлюзу для передачи ему данных по транзакции и реквизитам карты. В дальнейшем эти данные будут использованы для формирования сообщения, передаваемого эмитенту карты через платежную сеть.
Gateway Certificate Request/Response Messages. Эта пара сообщений позволяет торговой точке запросить у платежного шлюза его сертификат Key-Exchange Key.
Batch Administration Request/Response Messages. Эта пара сообщений используется для администрирования наборов (batch) транзакций для того, чтобы торговая точка и обслуживающий банк могли провести сверку данных каждой стороны. Запрос позволяет открывать новые наборы транзакций, открывать и закрывать существующие наборы транзакций, а также выяснять их статус.
Inquiry Request/Response Messages. С помощью этой пары сообщений владелец карты может выяснить статус выполнения электронной покупки (получена позитивная авторизация, сделан заказ, в процессе доставки, товар доставлен и т. п.). Inquiry Request может быть отправлен владельцем карты в любое время и любое количество раз.
Authorization Reversal Request/Response Messages. Пара сообщений используется для того, чтобы отменить ранее, проведенную авторизацию. Эта пара сообщений может также использоваться для того, чтобы скорректировать размер транзакции в ранее выполненной авторизации.
Capture Request/Response Messages. Сообщение Capture Request передается от торговой точки к платежному шлюзу и запрашивает у обслуживающего банка платеж за сделанную покупку. Размер запрашиваемого платежа должен быть ранее авторизован банком-эмитентом владельца карты с помощью сообщений Authorization Request/Response. Обычно торговая точка инициирует запрос Capture Request после выполнения заказа, связанного с электронной покупкой.
Credit Request/Response Messages. Эта пара используется для того, чтобы вернуть ранее сделанный платеж обслуживающего банка в адрес торговой точки.
Credit Reversal/Response Messages. Эта пара сообщений позволяет торговой точке отменить кредит в пользу обслуживающего банка.
Рассмотрим теперь подробнее, каким образом реализуется операция электронной покупки с использованием протокола SET.
Владелец карты инициирует покупку с помощью сообщения PinitReq. В этом сообщении владелец карты передает торговой точке сформированный им идентификатор парой сообщений PinitReq/PinitRes, идентификатор транзакции LID-C, сгенерированный владельцем карты для учета в системе владельца карты, идентификатор платежной системы Brand ID, карточкой которой владелец карты собирается совершить электронную покупку, BIN карточки (первые 6 цифр номера карты), язык, используемый владельцем карты для совершения операции, параметрические «отпечатки» сертификатов, списков CRL и каталога BCI, хранящихся в системе владельца карты, случайное число Chall-C, сгенерированное владельцем карты, параметрический идентификатор транзакции в системе торговой точки.
В ответном сообщении PinitRes торговая точка формирует следующие данные:
· копирует из запроса владельца карты данные LID-C и язык;
· генерирует глобальный идентификатор транзакции XID;
· копирует из запроса PinitReq «отпечатки» сертификатов, списки отозванных сертификатов, каталоги BCI, Chall-C;
· генерирует случайное число Chall-M;
· на основании Brand ID, BIN и сертификата владельца карты выбирает соответствующий платежный шлюз и вставляет в сообщение сертификат Key-Exchange Key этого платежного шлюза;
· вставляет в сообщение текущий каталог BCI, если в запросе клиента «отпечаток» каталога BCI отсутствовал либо присутствовал «отпечаток» уже неактуального каталога (напомним, что в соответствии с принятыми в протоколе SET соглашениями наряду с BCI в поле CRL данных SignedData передаются также ассоциированные с данным BCI списки CRL);
· некоторые другие данные.
Торговая точка подписывает данные своим закрытым ключом Signing Key и направляет сформированное таким образом сообщение владельцу карты.
Остальные этапы реализации электронной покупки будут описаны менее детально.
Владелец карты проверяет полученные сертификаты открытого ключа подписи торговой точки и открытого ключа Key-Exchange Key платежного шлюза, после чего проверяется цифровая подпись торговой точки в полученном сообщении. Таким образом, владелец карты аутентифицирует торговую точку.
После этого владелец карты начинает формирование сообщения PReq. Это сообщение состоит из двух частей: инструкции по заказу (Order Instruction, OI) и платежной инструкции (Payment Instruction, PI).
OI предназначено для торговой точки и включает в себя значение Chall-M из сообщения PinitRes, идентификатор транзакции XID, размер транзакции и валюту транзакции, идентификатор торговой точки, идентификатор batch, к которому должна быть отнесена покупка, номер заказа в системе магазина, хэш-функцию от PI и некоторую другую информацию. PI предназначено для платежного шлюза и включает в себя идентификатор транзакции XID, величину TranStain, представляющую собой хэш-функцию от секрета карты S и XID, хэш-функцию OI , параметрическое значение CVC2/CVC2, 2-ю дорожку магнитной полосы карты и другую информацию.
Далее владелец карты вычисляет хэш-функцию от последовательности, состоящей из значений хэш-функции от PI и OI, и подписывает полученное значение своим секретным ключом.
Владелец карты генерирует случайным образом симметричный ключ К1, с помощью которого он шифрует PI. Значение ключа К1 вместе с данными по карте (номер карты, срок ее действия и секрет карты), в свою очередь, закрываются с помощью открытого ключа Key-Exchange Key платежного шлюза. Сообщение Preq состоит из OI, зашифрованной инструкции PI, зашифрованных данных о реквизитах карты и ключе К1, цифровой подписи владельца карты.
Торговая точка, получив сообщение PReq, проверяет сертификат владельца карты, после чего проверяет цифровую подпись владельца карты. Для проверки цифровой подписи торговая точка вычисляет значение хэш-функции от OI и далее, используя значение хэш-функции для PI , вычисляет общее значение Н. После этого с помощью открытого ключа владельца карты дешифруется полученное из сообщения PReq значение цифровой подписи. Если дешифрованное значение совпадает с общим значением, — подпись была сделана владельцем сертификата открытого ключа владельца карты. Таким образом: торговая точка аутентифицирует владельца карты.
Далее торговая точка подготавливает сообщение AuthReq. В это сообщение без изменений из сообщения PReq включены зашифрованная платежная инструкция PI, зашифрованный симметричный ключ К1 и данные о реквизитах карты, а также цифровая подпись владельца карты. Кроме этих данных торговая точка формирует авторизационный запрос, содержащий информацию о размере транзакции, идентификаторе торговой точки, идентификатор транзакции XID, случайное число Chall-P и другую. Эта информация подписывается ключом Signing Key торговой точки, закрывается симметричным ключом К2 сгенерированным торговой точкой по случайному закону, который в свою очередь закрывается открытым ключом Key-Exchange Key платежного шлюза.
Платежный шлюз, получив AuthReq, дешифрует с помощью закрытого ключа Key-Exchange Key оба симметричных ключа К1 и К2, а также данные о реквизитах карты, дешифрует данные о транзакции и PI, проверяет подпись владельца карты (по аналогии с тем, как это делает торговая точка, для этого используется значение Н, содержащееся в PI), проверяет на равенство значения XID из информации о транзакции и из РI. Таким образом, платежный шлюз аутентифицирует как торговую точку, так и владельца карты. На основании полученных данных платежный шлюз готовит стандартное сообщение (например, в формате ISO 8583) для передачи его в платежную систему на авторизацию эмитента карты.
Получив из платежной системы ответ, платежный шлюз генерирует и подписывает своим закрытым Signing Key сообщение AuthRes (в сообщении содержится случайная величина Chall-P, также данные Capture Token, в которых платежный шлюз запрашивает у торговой точки ожидаемые им данные от торговой точки в сообщении Capture Request). Сообщение зашифровывается с помощью сгенерированного для этого симметричного ключа, который в свою очередь закрывается с помощью открытого ключа торговой точки.
Торговая точка дешифрует симметричный ключ, проверяет цифровую подпись платежного шлюза и формирует сообщение PRes, содержащее Chall-C, подписывая его своим закрытым Signing Key.
Владелец карты, получив сообщение PRes, проверяет цифровую подпись торговой точки. На этом процесс электронной покупки может быть закончен.
Расчеты между торговой точкой и обслуживающим банком осуществляются либо на основании приведенной ранее схемы электронной покупки, либо на основании дополнительного запроса Capture Request от торговой точки.
- Оглавление
- История становления электронного банкинга
- Основные определения интернет-банкинга
- Основные услуги, предоставляемые посредством интернет-банкинга
- Преимущества интернет банкинга по сравнению с обычным банковским обслуживанием
- Интернет-банкинг корпораций
- Основные определения электронных платежных систем
- Участники электронных платежей
- Классификация моделей электронных платежей
- Механизмы поддержки проведения электронных платежей
- Требования к платежным системам организации, занимающиеся наблюдением за соблюдением законности в области информационной безог
- Руководящие документы в области информационной безопасности
- Основные понятия криптографии
- Криптографические алгоритмы
- Шифрование с закрытым ключом
- Шифрование с открытым ключом
- Модель osi, место протокола ssl
- Основные сведения о протоколе ssl
- Алгоритм работы ssl
- Использование сертификатов в протоколе ssl
- Основные сведения о протоколе set
- Архитектура системы центров сертификации протокола set
- Процедуры генерации, обновления и отзыва сертификатов по протоколу set
- Реализация транзакций в протоколе set
- Модель трех доменов
- Модель 3d secure
- Интернет-кредитование
- Тенденции развития интернет-банкинга
- Мобильная коммерция, устройства и технологии
- Мобильная коммерция, сети передачи данных
- Смарт-карты
- Виртуальные платежные карты
- Электронный маркетинг
- Интернет-магазины с точки зрения электронной коммерции
- Архитектура интернет-магазинов
- История европейского валютного союза
- Первый этап Европейской интеграции
- Второй этап европейской интеграции
- Третий этап Европейской интеграции
- Четвертый этап Европейской интеграции
- Новейшая история Европейской интеграции
- Электронные системы межбанковских операций, основные понятия
- Система электронных банковских расчетов Saggitattarie
- Система электронных банковских расчетов chips
- Система электронных банковских расчетов chaps
- Система электронных банковских расчетов цб рф
- Система электронных банковских расчетов FedWire
- Платежная система есцб Target
- Правовые основы функционирования европейских платежных систем
- Система клиринговых расчетов ева
- Локальные rtgs системы
- Всемирная межбанковская система swift, цели создания и история
- Всемирная межбанковская система swift, архитектура
- Всемирная межбанковская система swift, сообщения
- Определение swot анализа, пример
- Матрица стратегий использования swoTaHariH3a
- Цифровые водяные знаки
- Система сетевых денег
- Система Yandex Деньги
- Система WebMoney Transfer
- Примеры платежных систем