Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсовые / Протоколы защиты.doc
Скачиваний:
52
Добавлен:
16.04.2013
Размер:
262.66 Кб
Скачать

Реализация транзакций в протоколе set

Опишем теперь типы транзакций, используемых в протоколе SET. В протоколе SET со­общения, с помощью которых реализуются различные транзакции, имеют парный харак­тер (запрос-ответ), Payment Initialization Request/Response Messages. Эта пара сообщений используется для взаимной аутентификации владельца карты и торговой точки, для пере­дачи владельцу карты от торговой точки необходимых сертификатов и списков CRL, а также предоставления информации торговой точки о том, карта какой платежной системы будет использоваться при проведении покупки.

Purchase Order Request/Response Messages. Эта пара сообщений служит для пе­редачи в защищенной сессии от владельца карты к торговой точке информации о заказе (сумма покупки, валюта, номер торговой точки и т. п.) и реквизитах карты владельца карты.

Authorization Request/Response Messages. ЗапросAuthorizationRequest иницииру­ется торговой точкой и передается платежному шлюзу для передачи ему данных по тран­закции и реквизитам карты. В дальнейшем эти данные будут использованы для формиро­вания сообщения, передаваемого эмитенту карты через платежную сеть.

Gateway Certificate Request/Response Messages. Эта пара сообщений позволяет торговой точке запросить у платежного шлюза его сертификат Key-Exchange Key.

Batch Administration Request/Response Messages. Эта пара сообщений использу­ется для администрирования наборов (batch) транзакций для того, чтобы торговая точка и обслуживающий банк могли провести сверку данных каждой стороны. Запрос позволяет открывать новые наборы транзакций, открывать и закрывать существующие наборы тран­закций, а также выяснять их статус.

Inquiry Request/Response Messages. С помощью этой пары сообщений владелец карты может выяснить статус выполнения электронной покупки (получена позитивная авторизация, сделан заказ, в процессе доставки, товар доставлен и т. п.).InquiryRequest может быть отправлен владельцем карты в любое время и любое количество раз.

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 от торговой точки.