Лекция 11:

Обеспечение безопасности платежных систем на основе протокола SET

< Лекция 10 || Лекция 11: 12 || Лекция 12 >

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

Для устранения указанных недостатков VISA International совместно с MasterCard был разработан протокол SET - Secure Electronic Transaction[3GPP TR 21.905: Vocabulary for 3GPP Specifications.], ориентированный на платежные системы с использованием пластиковых карт.

Протокол SET помимо четырех сущностей, характерных для любой платежной системы - покупателя, продавца, банка-эмитента и банка-эквайера, вводит две новые - центр сертификации (ЦС, CA - Certificate Authority) и платежный шлюз (Payment Gateway) ( рис. 11.1).

Взаимодействие участников платежной транзакции при помощи протокола SET

Рис. 11.1. Взаимодействие участников платежной транзакции при помощи протокола SET

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

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

11.1. Сертификация в протоколе SET

Система сертификации[3GPP TR 21.905: Vocabulary for 3GPP Specifications.] в протоколе SET представляет собой пятиуровневую структуру, представленную на рис. 11.2.

Система сертификации в протоколе SET

Рис. 11.2. Система сертификации в протоколе SET

Головной центр сертификации (RCA - Root CA) выполняет следующие функции:

  • формирование сертификатов для брендовых ЦС;
  • генерация сертификатов для собственных открытых ключей;
  • формирование и рассылка списка отозванных сертификатов (CRL - Certificate Revocation List) для брендовых ЦС.

Брендовые центры сертификации (BCA - Brand CA) являются ЦС платежных систем. По аналогии с головным ЦС они формируют сертификаты для ЦС более низкого уровня и помогают в рассылке CRL. Геополитические центры сертификации (GCA - Geo-Political CA) предназначены для упрощения процедуры взаимодействия брендового ЦС и географически распределенных центров сертификации владельцев карт, а именно:

  • ЦС держателя карты (CCA - Cardholder CA);
  • ЦС продавца (MCA - Merchant CA);
  • ЦС платежного шлюза (PCA - Payment Gate CA).

Центры сертификации владельцев карт занимаются формированием, распространением, поддержкой и аннулированием сертификатов. Сертификат представляет собой электронный документ, удостоверяющий подлинность указанного в нем открытого ключа. В соответствии со стандартом X.509.3 (ISO/IEC 9594-8[EMV ICC Specification for Payment Systems.]) сертификат имеет определенные поля, представленные в табл. 1.1.

Таблица 11.1. Основные поля сертификата
Поле Описание
Version версия протокола Х.509 (равна 3)
Serial Number уникальный серийный номер сертификата
Algorithm Identifier алгоритм, используемый для подписи сертификата
Issuer Name имя ЦС, выпустившего сертификат
Validity.NotBefore дата начала действия сертификата
Validity.NotAfter дата окончания действия сертификата
Subject Name имя владельца сертификата
Algorithm алгоритм, в соответствии с которым сгенерирован открытый ключ
Subject Public Key Info значение сертифицируемого открытого ключа
Signature подпись

Кроме указанных полей в сертификате присутствуют значения, необходимые для применения перечисленных в сертификате алгоритмов.

В протоколе SET предусмотрено четыре типа ключей, используемых участниками платежных транзакций:

  • ключ для подписи сообщения (Digital Signature Key);
  • ключ для шифрования данных (Data Encipherment Key);
  • ключ для подписи сертификата (Certificate Signature Key);
  • ключ для подписи списка отозванных сертификатов (CRL Signature Key).

Право на обладание определенным ключом предоставляется участникам протокола, перечисленным в табл. 11.2.

Таблица 11.2. Принадлежность ключей участникам протокола SET
Участник протокола Тип ключа
Ключ для подписи сообщения Ключ для шифрования данных Ключ для подписи сертификата Ключ для подписи CRL
Держатель карты +
Продавец + +
Платежный шлюз + +
ЦС держателя карты + + +
ЦС продавца + + +
ЦС платежного шлюза + + + +
Геополитический ЦС + +
Брендовый ЦС + +
Головной ЦС + +

11.2. Архитектура SET

Так же как и SSL, SET является надстройкой над транспортным уровнем, однако, в отличие от SSL, шифрует не все данные, предаваемые транспортному уровню, а только те, что относятся к платежным транзакциям. Все остальные данные, передаваемые транспортному уровню, проходят без изменений ( рис. 11.3).

Структура протокола SET

увеличить изображение
Рис. 11.3. Структура протокола SET

Для осуществления подобного взаимодействия используется специальная программа электронной коммерции, на которую возлагаются следующие функции:

  • поиск товаров и услуг в Интернете;
  • согласование параметров заказа (цена, срок доставки);
  • формирование заказа;
  • подготовка и передача параметров, необходимых SET для организации защищенного взаимодействия участников платежной транзакции.

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

11.2.1. Схема двойной электронной подписи

При совершении транзакции покупатель С формирует два сообщения:

  • m_1 - описание заказа для продавца С, содержащее все необходимые данные для отгрузки товара или предоставления услуги;
  • m_2 - инструкции платежному шлюзу G, содержащие в том числе платежные реквизиты покупателя.

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

Для достижения поставленной задачи покупатель формирует сообщение m_3, представляющее собой объединение хеш-образов сообщений m_1 и m_2:


.

Затем покупатель применяет хеш-функцию к сообщению m_3 и зашифровывает результат на своем секретном ключе SK_C, получая тем самым двойную электронную подпись:


После этого покупатель формирует сообщение:


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

Продавец, получив указанное сообщение, проверяет подпись покупателя. Для этого он извлекает из сообщения m_1 и h (m_2) и вычисляет значение


Затем продавец вычисляет h`_3 и сравнивает его со значением h (m_3), которое он получает из DoubleSign, зашифровав последнее на открытом ключе покупателя PK_C:


В случае совпадения h (m_3) и h`_3 продавец убеждается в целостности сообщения и при согласии с условиями сделки извлекает предназначавшиеся ему данные m_1 и h (m_2) из Order_C, формируя тем самым сообщение


которое отсылает платежному шлюзу.

Получив данное сообщение, платежный шлюз извлекает из него фрагмент PK_G \{m_2 || h (m_2)\}, расшифровывает его на своем секретном ключе SK_G и получает платежные инструкции


После этого шлюз извлекает из полученного от продавца сообщения h (m_1) и вычисляет значение


Затем платежный шлюз вычисляет  и сравнивает его со значением h (m_3), которое он получает из DoubleSign, зашифровав последнее на открытом ключе покупателя PK_C:


Совпадение h (m_3) и  означает, что, во-первых, платежные инструкции подписаны действительно покупателем, а во-вторых, что продавец согласен с условиями сделки.

Удостоверившись в корректности подписи, шлюз осуществляет предписанные ему платежные инструкции.

11.2.2. Криптографическая защита сообщений

Процесс защищенного взаимодействия двух абонентов показан на рис. 11.4.

Обеспечение безопасности передаваемых данных в протоколе SET

увеличить изображение
Рис. 11.4. Обеспечение безопасности передаваемых данных в протоколе SET

Абонент А формирует сообщение p, затем хеширует его и зашифровывает на своем секретном ключе SK_A, получая тем самым подпись сообщения Sign. Объединив оригинал сообщения и подпись, абонент А получает сообщение Order, которое шифрует на сеансовом ключе Key, сгенерированном случайным образом. Полученное сообщение c является одной из частей отправляемого сообщения Datagram. Второй частью Datagram является Ciphered Key - сеансовый ключ, зашифрованный на открытом ключе PK_B абонента B. Сообщение Datagram передается на транспортный уровень и отправляется абоненту B. Получив указанное сообщение, абонент B извлекает из него зашифрованный сеансовый ключ Ciphered Key и расшифровывает его на своем секретном ключе SK_B. Затем абонент B извлекает из Datagram фрагмент c и расшифровывает его при помощи сеансового ключа, получая тем самым сообщение Order. Далее следует проверка подписи абонента А путем расшифрования sign с использованием PK_A - открытого ключа абонента А и сравнения полученного хеш-образа h (p) с хеш-образом сообщения p.

Протокол SET поддерживает четыре криптографических алгоритма:

  • RSA - для формирования и проверки электронной цифровой подписи передаваемого сообщения, а также для зашифрования и последующего расшифрования сеансового ключа;
  • DES - для зашифрования и последующего расшифрования инструкций продавцу и платежному шлюзу с прикрепленной двойной цифровой подписью;
  • SHA- для хеширования информации;
  • HMAC-SHA-1 — для формирования кода аутентификации сообщения.
< Лекция 10 || Лекция 11: 12 || Лекция 12 >