Обеспечение безопасности платежных систем на основе протокола SET
11.3. Регистрация
Протокол SET предполагает, что у каждого участника информационного взаимодействия должен быть сертификат. Соответственно работа в платежной системе на основе протокола SET должна начинаться с получения сертификата. Прежде чем приступить к получению сертификата, участники платежных транзакций должны выполнить следующие действия:
- держатель карты:
- получить счет в банке - участнике финансового института,
- обеспечить возможность получения пары открытый/закрытый ключ,
- приобрести URL или почту для связи с CCA,
- установить специализированную программу электронной коммерции, позволяющую идентифицировать и аутентифицировать держателя карты и поддерживающую протокол SET;
- продавец:
- получить идентификатор продавца (счет плюс дополнительная информация, необходимая для платежной системы) у представителя платежной системы или финансового института,
- обеспечить возможность получения пары открытый/закрытый ключ,
- приобрести URL или почту для связи с MCA,
- установить специализированную программу электронной коммерции, позволяющую взаимодействовать с банком в рамках платежной системы и поддерживающую протокол SET;
- платежный шлюз:
- получить идентификатор шлюза у представителя платежной системы или финансового института,
- обеспечить возможность получения пары открытый/закрытый ключ,
- приобрести URL или почту для связи с PCA,
- установить специализированную программу электронной коммерции, позволяющую идентифицировать и аутентифицировать платежный шлюз и поддерживающую протокол SET.
При первом запуске специализированной программы электронной коммерции все участники взаимодействия связываются с соответствующими центрами сертификации для получения сертификатов.
Начало регистрации держателя карты, ход процедуры сертификации представлены на рис. 11.5.
Процесс начинается с того, что программа держателя карты посылает CCA сообщение CardCInitReq, информирующее центр о начале процедуры сертификации.
Последовательность и взаимосвязь действий при формировании сообщения представлены на рис. 11.6.
Получив запрос, ЦС держателя карты формирует сообщение CardCInitRes, содержащее оригинал и подпись ответа на запрос, а также сертификаты цифровой подписи и ключа шифрования.
Получив данное сообщение, программа держателя карты извлекает из сертификата ключа для подписи сообщений, входящего в CardCInitRes, открытый ключ центра сертификации и проверяет подпись CCA. Также в состав CardCInitRes входит сертификат ключа для шифрования данных, содержащий открытый ключ центра сертификации, который в дальнейшем будет использоваться для обеспечения конфиденциальности передаваемых данных.
Следующим шагом в получении сертификата является запрос регистрационной формы, приведенный на рис. 11.7.
Запрос содержит в себе PAN держателя карты, поэтому должен передаваться в зашифрованном виде. Для зашифрования используется сеансовый ключ, сгенерированный случайным образом. После зашифрования сеансовый ключ шифруется на открытом ключе для шифрования данных CCA, извлеченном из сертификата на предыдущем этапе, и присоединяется к зашифрованному запросу, образуя сообщение RegFormReq. Данное сообщение отсылается центру сертификации. Получив RegFormReq, ЦС применяет свой закрытый ключ для расшифрования сообщений и получает сеансовый ключ, которым расшифровывает запрос. По PAN держателя карты извлекается соответствующая форма, которая зашифровывается и подписывается центром сертификации и отсылается в сообщении RegFormRez держателю карты, как показано на рис. 11.8.
Получив сообщение RegFormRes, программа держателя карты расшифровывает его при помощи сеансового ключа, проверяет подпись формы, используя открытый ключ для проверки сообщений CCA, после чего выводит форму на экран, предоставляя возможность держателю карты заполнить ее. После того как форма заполнена, программа держателя карты формирует пару открытый/закрытый ключ и случайное число для предотвращения переборных атак. Затем программа формирует CertReq, представляющее собой зашифрованные на сеансовом ключе оригинал и подпись сообщения, состоящего из заполненной формы, открытого ключа проверки подписи держателя карты и случайно сгенерированного числа для предотвращения переборных атак. Сообщение CertReq отправляется центру сертификации. Процесс формирования сообщения схематично представлен на рис. 11.9.
Получив CertReq, центр сертификации извлекает из него запрос и проверяет правильность подписи, а следовательно, и корректность открытого ключа проверки подписи держателя карты. При положительном результате проверки CCA заполняет поля сертификата (см. табл. 11.1) ключа проверки подписи держателя карты значениями, указанными в форме, добавляет срок начала и окончания действия сертификата, а также значение, связывающее сертификат и данные пользователя:
В завершении ССА подписывает сертификат своим секретным ключом подписи, шифрует на сеансовом ключе, получая тем самым сообщение CertRes, которое отправляет держателю карты.
Держатель карты расшифровывает сообщение CertRes и получает сертификат. Держатель карты проверяет подлинность сертификата путем применения открытого ключа центра сертификации для проверки подписи, а также вычисляя значение, связывающее сертификат и данные пользователя.
Процедуры получения сертификатов для продавца и платежного шлюза практически идентичны процедуре регистрации продавца за тем исключением, что для регистрации последних требуются другие центры сертификации (для продавцов - MCA, для платежных шлюзов - PCA), другие типы сертификатов и другое число ключей (см. табл. 11.2). Кроме этого несколько отличается формат команд, посылаемых вновь регистрирующимися участниками соответствующим центрам сертификации.
11.4. Платежная транзакция
После того как держатель карты (покупатель) выбрал соответствующую услугу, он отправляет продавцу запрос на предоставление сертификата. В ответ на этот запрос продавец высылает свой сертификат, сертификат платежного шлюза и идентификатор транзакции. Далее транзакция производится в соответствии с алгоритмами, описанными в разделах 11.2.1 и 11.2.2, а именно:
- держатель карты формирует ордер заказа для продавца и платежную инструкцию для банка, формирует двойную электронную подпись, зашифровывает сообщение и отправляет продавцу;
- продавец расшифровывает полученное сообщение, проверяет двойную подпись, соглашается с условиями сделки путем внесения соответствующих добавлений в двойную подпись, зашифровывает полученное сообщение и отправляет его платежному шлюзу;
- платежный шлюз проверяет двойную подпись, удостоверяется, что продавец и покупатель согласны с условиями сделки, извлекает предназначенные ему платежные инструкции и осуществляет перевод средств со счета на счет, о чем информирует продавца;
- продавец, получив сообщение о переводе средств, осуществляет доставку товара или предоставление услуги.
11.5. Интеграция SET и SSL
Одним из недостатков протокола SET является вычислительная сложность, что делает использование данного протокола слишком дорогим для небольших платежных систем. Одним из вариантов решения данной проблемы является схема комбинированного использования SET и SSL, приведенная на рис. 11.10.
Идея такого объединения заключается во введении еще одного участника платежной транзакции - посредника. Взаимодействие между покупателем, продавцом и посредником осуществляется при помощи быстрого протокола SSL, взаимодействие между центром сертификации, платежным шлюзом и посредником - при помощи протокола SET. Таким образом, для держателя карты и продавца посредник выступает в двух ролях - сервера SSL и центра сертификации SSL, для платежного шлюза посредник является продавцом с точки зрения SET.
В случае данной схемы центр сертификации формирует сертификаты покупателя и продавца, которые передает для хранения посреднику. Тогда для аутентификации покупателя продавца и держателя карты достаточно пройти аутентификацию у посредника, что можно сделать при помощи SSL-сертификатов, встроенных практически в любой браузер. Кроме этого данный подход позволяет продавцу отказаться от использования специализированной программы электронной коммерции.