протокол 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) транзакций для того, чтобы ТП и обслуживающий банк могли провести сверку данных каждой стороны (reconciliation). Запрос позволяет открывать новые наборы транзакций, очищать и закрывать существующие наборы транзакций, а также выяснять их статус.
  • 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 (Н2) и некоторую другую информацию. PI предназначено для платежного шлюза и включает в себя идентификатор транзакции XID, величину TranStain, представляющую собой хэшфункцию от секрета карты S и XID, хэш-функцию OI (Н,), параметрически значение CVC2/CVC2,2-ю дорожку магнитной полосы карты и другую информацию.

Далее владелец карты вычисляет хэш-функцию от последовательности, состоящей из значений хэш-функции от PI и 01 (Н), и подписывает полученное значение своим секретным ключом.

Владелец карты генерирует случайным образом симметричный ключ К,, с помощью которого он шифрует PL Значение ключа К, вместе с данными по карте (номер карты, срок ее действия и секрет карты), в свою очередь, закрываются с помощью открытого ключа Key-Exchange Key платежного шлюза. Сообщение Preq состоит из OI, зашифрованной инструкции PI, зашифрованных данных о реквизитах карты и ключе К,, цифровой подписи владельца карты.

ТП, получив сообщение PReq, проверяет сертификат владельца карты, после чего проверяет цифровую подпись владельца карты. Для проверки цифровой подписи ТП вычисляет значение хэш-функции от 01 и далее, используя значение хэш-функции для PI (Н2), вычисляет общее значение Н. После этого с помощью открытого ключа владельца карты дешифруется полученное из сообщения PReq значение цифровой подписи. Если дешифрованное значение совпадает с общим значением, — подпись была сделана владельцем сертификата открытого ключа владельца карты. Таким образом ТП аутентифицирует владельца карты.

Далее ТП подготавливает сообщение AuthReq. В это сообщение без изменений из сообщения PReq включены зашифрованная платежная инструкция PI, зашифрованный симметричный ключ К, и данные о реквизитах карты, а также цифровая подпись владельца карты. Кроме этих данных ТП формирует авторизационный запрос, содержащий информацию о размере транзакции, идентификаторе ТП, идентификатор транзакции XID, случайное число Chall-P и другую. Эта информация подписывается ключом Signing Key ТП, закрывается симметричным ключом К2, сгенерированным ТП по случайному закону, который в свою очередь закрывается открытым ключом Key-Exchange Key платежного шлюза.

Платежный шлюз, получив AuthReq, дешифрует с помощью закрытого ключа Key-Exchange Key оба симметричных ключа К, и К2, а также данные о реквизитах карты, дешифрует данные о транзакции и PI, проверяет подпись владельца карты (по аналогии с тем, как это делает ТП, для этого используется значение Н,, содержащееся в PI), проверяет на равенство значения XID из информации о транзакции и из PL. Таким образом, платежный шлюз аутентифицирует как ТП, так и владельца карты. На основании полученных данных платежный шлюз готовит стандартное сообщение (например, в формате ISO 8583) для передачи его в платежную систему на авторизацию эмитента карты.

Получив из платежной системы ответ, платежный шлюз генерирует и подписывает своим закрытым Signing Key сообщение AuthR.es (в сообщении содержится случайная величина Chall-P, также данные Capture Token, в которых платежный шлюз запрашивает у ТП ожидаемые им данные от ТП в сообщении Capture Request). Сообщение зашифровывается с помощью сгенерированного для этого симметричного ключа, который в свою очередь закрывается с помощью открытого ключа ТП.

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

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

Расчеты между ТП и обслуживающим банком осуществляются либо на основании приведенной ранее схемы электронной покупки, либо на основании дополнительного запроса Capture Request от ТП.

Относительно протокола SET имеют место следующие утверждения.

Теорема 1. Протокол SET является устойчивым протоколом ЭК.
Доказательство этой теоремы следует из приведенного описания протокола.

Таким образом, SET обладает следующими свойствами:

  • Мошеннику недостаточно знать реквизиты платежной карты для того, чтобы успешно выполнить SET-транзакцию. Помимо реквизитов карты необходимо иметь закрытый ключ владельца данной карты, а также сертификат соответствующего ему открытого ключа.
  • ТП при выполнении SET-транзакции точно знает, что владелец карты, совершающий транзакцию, является подлинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован банком-эмитентом клиента.
  • Клиент точно знает, что ТП, в котором совершается SET-транзакция, является истинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован обслуживающим банком ТП.
  • ОБ точно знает, что владелец карты и ТП являются подлинными, то есть обладают сертифицированными ключами.
  • Информация о реквизитах карты не известна ТП.
  • ТП и владелец карты имеют заверенные подписями соответственно владельца карты и ТП подтверждения факта совершения транзакции, что делает невозможным отказ от результатов операции ни одного из участников транзакции ЭК.

Теорема 2. Протокол SET является единственным открытым (известным) устойчивым протоколом ЭК. Сегодня не существует никакого другого (кроме SET) опубликованного устойчивого протокола ЭК. Другими словами, на рынке аппаратно-программных решений, реализующих устойчивый протокол ЭК, не существует альтернативы продуктам, реализующим SET. VISA International предполагает в ближайшее время опубликовать спецификации нового глобального стандарта аутентификации, называемого 3D Secure. Однако неочевидно, что этот стандарт будет определять устойчивый протокол ЭК.

Теорема 3. Протокол SET де-факто является отраслевым стандартом в области пластиковых карт.

Будучи признанным ведущими международными платежными системами (VISA, MasterCard, Europay, AmEx, Diners Club) в качестве стандарта ЭК, SET де-факто является отраслевым стандартом.

Таким образом, протокол SET является на сегодняшний день единственным открытым и устойчивым протоколом ЭК.