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

Как было показано в предыдущей главе, одним из основных недостатков протокола 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).

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

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

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

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

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

Рис. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случае совпадения и  продавец убеждается в целостности сообщения и при согласии с условиями сделки извлекает предназначавшиеся ему данные и из , формируя тем самым сообщение

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

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

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

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

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

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

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

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

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

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

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

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