Транзакция

Инициализация. Владелец карты запрашивает сертификаты продавца и платежного шлюза необязательным сообщением PlnitReq. Это сообщение передается в незашифрованном виде. Продавец отвечает сообщением PlnitRes, содержащим сертификат подписи продавца, сертификат шифрования ключей платежного шлюза и идентификатор транзакции TransID. Это сообщение подписано закрытым ключом подписи продавца.

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

Данные заказа и платежная инструкция. Данные ордера заказа (order information, OI) и платежные инструкции (payment instruction, PI) передаются в сообщении PReq. Данные заказа определяют заказанные товары, платежная инструкция содержит PAN, цену предметов и идентификатор заказа TransID, если он поддерживается продавцом. В противном случае идентификатор транзакции формирует ПО на стороне владельца карты.

Дайджесты OI и PI после конкатенации шифруются закрытым ключом подписи владельца карты для создания двойной подписи сообщения PReq. Затем сообщение подписывается закрытым ключом подписи владельца карты. На рис. 14 отражен процесс создания двойной подписи сообщения PReq.

Рис. 14. Формирование двойной подписи сообщения PReq

Платежная инструкция вместе с дайджестом и двойной подписью передаются после шифрования случайным секретным ключом. Этот ключ в свою очередь шифруется открытым ключом шифрования ключей платежного шлюза, что делает его недоступным для продавца. Если владелец карты имеет сертификат подписи, он также пересылается. На рис. 15 отражена структура сообщения PReq, одного из наиболее сложных сообщений протокола.

Дадим более детальное описание сообщения PReq, которое будет свидетельствовать о сложности протокола SET и избыточности применяемых методов защиты. Следует помнить, что содержимое сообщения PReq зависит от того, имеет ли владелец карты сертификат подписи. Если владелец карты сертифицирован, сообщение PReq будет состоять из двух частей, как показано на рис. 16.

Обозначения, используемые на рис. 16, те же, что и в спецификации SET:

· оператор DD(A) означает дайджест А, преобразованный в соответствии с типом данных DigestData из PKCS#7, и обозначается как digest A;

· оператор L(A, В) - связывающий оператор, определяющий, что В присоединено к А посредством конкатенации А и дайджеста В;

· L(A,B)={A, DD(B)};

· оператор SO(s, t) определяет сигнатуру участника s сообщения t типа SignedData в соответствии с PKCS#7;

· оператор EX(r, t, p) представляет собой следующую последовательность операций: шифрование ключом DES сообщения t; добавление этого ключа и переменной p в цифровой конверт (в соответствии с PKCS#7) с OAEP, для формирования OAEP{(k, p)}; шифрование этого конверта открытым ключом получателя r алгоритма RSA;

· поля, помещенные в квадратные скобки [ ], необязательны.

Рис. 15. Структура сообщения PReq

Первый компонент сообщения PReq, PIDualSigned, содержит платежную инструкцию, направленную банку-эквайеру со всеми необходимьми признаками, достаточными для идентификации владельца карты. Вторая часть сообщения OIDualSigned содержит подписанные и зашифрованные данные заказа. В таблице 8 приведены обязательные поля, используемые на рис. 16, и их содержание. Более детальное описание данной процедуры содержится в спецификациях SET (книга 3).

Авторизационный запрос. Авторизационный запрос инициирует диалог между сервером продавца и платежным шлюзом, с одной стороны, и между шлюзом и банком-эмитентом - с другой. Сервер продавца обрабатывает сообщение PReq по-разному для случаев, когда сообщение приходит с сертификатом подписи владельца карты и без оного. Если сертификат присутствует, сервер проверяет его, отправляя на проверку по пути сертификации и проверяя сигнатуру данных заказа, используя открытый ключ владельца карты в сертификате. Затем сервер проверяет двойную подпись и в случае успеха возвращает подтверждение владельцу карты в сообщении PRes. Это сообщение передается в незашифрованном виде и подписано (для возможности проверки его целостности после получения). Сообщение должно содержать сертификат цифровой подписи продавца.

Рис. 16. Состав сообщения PReq

Таблица 8.Содержание обязательных полей сообщения PReq

Поле	Содержание
Inputs	Дайджест данных, входящих в данные заказа, и сумма заказа
OIData	Дайджест данных заказа, запрос к продавцу для проверки «свежести» сигнатуры владельца карты, бренда карты и идентификатора банка-эмитента
OIDualSigned	OIData и дайджест PIData
PANData	Номер карты, срок ее годности, секретный код и текущее время (для предотвращения словарных атак)
PIDualSigned	PISignature и ссылка на данные заказа
PIHead	Идентификатор продавца, код НМАС глобального идентификатора транзакции XID и секретный код владельца карты, идентификатор используемого ПО, информация об используемом банком-эквайером алгоритме и сертификат платежного шлюза
PISignature	Дайджест сигнатуры владельца
TransID	Идентификатор транзакции

Затем сервер продавца передает платежные инструкции в шлюз в сообщении AuthReq. Этот запрос подписан закрытым ключом подписи продавца, а все сообщение зашифрован симметричным ключом DES. Этот ключ помещен в цифровой конверт вместе с сигнатурой продавца, сертификатами шифрования и сертификатом подписи владельца карты (если он доступен). Конверт зашифрован открытым ключом шифрования платежного шлюза. Hа рис. 17 представлен состав сообщения AuthReq.

Авторизация. После получения сообщения AuthReq шлюз проверяет полученные сертификаты, передавая их вверх по пути сертификации. Затем он расшифровывает конверт с авторизационным запросом с помощью закрытого ключа (из пары ключей шифрования) для получения ключа симметричного шифрования. Этот симметричный ключ затем используется для рас шифрования запроса, чья целостность проверяется открытым ключом подписи продавца.

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

Рис. 17. Состав сообщения AuthReq

После успешного завершения этого этапа шлюз формирует авторизационный запрос и передает его в банк-эмитент по банковским сетям для обслуживания платежных карт. Эта процедура не регламентирована SET и поэтому не будет рассмотрена. Достаточно будет сказать, что банковская карта имеет лимит расходования денежных средств; таким образом, если достигнут этот лимит, авторизация будет отклонена с рекомендацией провести голосовую авторизацию. Предполагается, что ПО продавца должно уметь обрабатывать такие ситуации.

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

· ответ банка-эмитента, авторизующего платеж;

· (опционально) маркер (токен) сбора, подписанный закрытым ключом подписи платежного шлюза. Этот токен должен сопровождать любой запрос на сбор информации, ассоциированный с транзакцией для облегчения ежедневного сбора данных. Токен зашифрован вторым секретным ключом, сгенерированным шлюзом. Как и раньше, секретный ключ помещается в цифровой конверт, шифруется открытым ключом платежного шлюза. Таким образом, конверт может быть открыт только платежным шлюзом.

Когда сервер продавца получает сообщение AuthRes, он выделяет из сообщения ответ банка-эмитента и зашифрованный токен. Сервер использует свои закрытые ключи шифрования для расшифрования первого конверта (для получения секретного ключа) и расшифрования ответа на авторизационный запрос банка-эмитента.

Напротив, сервер продавца не может восстановить токен сбора, так как ключ шифрования DES остается в цифровом конверте, зашифрованном открытым ключом шлюза. Конверт, содержащий ключ DES и зашифрованный токен, сохраняется в неизменном виде и в дальнейшем используется для сопровождения запросов на сбор финансовой информации по авторизациям.

Сбор информации шлюзом. Сбор информации ‑ это процедура завершения транзакции оплаты товара, когда продавец требует кредитовать его счет. Процедура окончательного расчета (финансового возмещения) инициируется через отправку в шлюз сообщения CapReq. Это сообщение включает в себя помимо прочей информации сумму транзакции, идентификатор транзакции, ссылку на авторизацию, зашифрованный и подписанный токен сбора, а также предварительно сохраненный цифровой конверт с ключом шифрования. Так же как и все остальные сообщения SET, запрос на сбор информации зашифрован секретным ключом, который помещен в конверт и зашифрован открытым ключом шифрования платежного шлюза.

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

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

В заключение шлюз отвечает продавцу сообщением CapRes. Это сообщение содержит ответ банка-эквайера, в котором содержится сумма, на которую окончательно кредитован счет продавца. Сообщение подписано закрытым ключом подписи платежного шлюза и зашифровано закрытым ключом, который помещен в конверт, зашифрованный открытым ключом продавца. Проверка полученного сообщения сервером продавца происходит так же, как и остальные процедуры, рассмотренные ранее.