Безопасный протокол электронных платежей SET
Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. “SET - Secure Electronic Transaction Specification”). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет. Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:
Аутентификация. Все участники кредитных операций идентифицируются с помощью электронных подписей. Это касается клиента-покупателя, продавца, банкира, выдавшего кредитную карточку, и банкира продавца.
Конфиденциальность. Все операции производятся в зашифрованном виде.
Целостность сообщений. Информация не может быть подвергнута модификации по дороге в противном случае это будет сразу известно.
Подсоединение. SET позволяет подключить к базовому сообщению дополнительный текст и послать его одному из партнеров.
Безопасность.
Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях.- Совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.
- Независимость от транспортного протокола. Безопасность операций не должна зависеть от уровня безопасности транспортного протокола. Такие гарантии особенно важны, так как протокол SET ориентирован для работы в Интернет.
- Регистрацию держателя карточки
- Регистрацию продавца
- Запрос покупки
- Авторизацию платежа
- Перевод денег
- Кредитные операции
- Возврат денег
- Отмену кредита
- Дебитные операции
| Этап | Действие |
| 1 | Владелец карты просматривает позиции каталога продавца:
|
| 2 | Владелец карты выбирает понравившийся товар или услугу. |
| 3 | Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов). |
| 4 | Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт. |
| 5 | Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов. |
| 6 | Продавец запрашивает платежную авторизацию от эмитента карты. |
| 7 | Продавец посылает подтверждение заказа. |
| 8 | Продавец доставляет заказанный товар или услугу |
| 9 | Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты. |
Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов 5, 6, 7 и 9. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях. Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие. Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры - код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму. Каждая цифра номера умножается на его “вес”.
Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы). Схема взаимодействия субъектов в протоколе SET показана на рис. 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.
- Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.
- Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе - номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).
- Продавец выделяет часть, адресованную банкиру, и направляет ее по месту назначения.
Программа SET WEB- сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка. - Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.
- Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.
- Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.
- WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.
- Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.
- Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).
Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование. В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.
Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы. Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче).
Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже. Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы. Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.
Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА. Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу. После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу. Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца. SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный.
В рамках протокола используются следующие значения символов-префиксов участников сделки:
| Символы-префиксы | Участник сделки |
| C | Владелец карты (Cardholder) |
| M | Продавец (Merchant) |
| P | Расчетный центр (Payment Gateway) |
| CA | Сертификационный центр (Certificate Authority) |
С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes). Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты. Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:
| XID | 20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения). |
| RRPID | 20-байтовое число, которое однозначно идентифицирует запрос. |
| locallD-M | 1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца |
| paySysID | 1-64 байтовый идентификатор транзакции |
| MerOrderNum | 1-25 байтовый номер заказа продавца |
| Держатель карты (Cardholder) | Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги. |
| Продавец (Merchant) | Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей. |
| Эмитент (Issuer) | Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции. |
| Получатель (Acquirer) | Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент. |
| Расчетный центр (Payment Gateway) | Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем. |
| Платежная система (Brand) | Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.) |
| Сертификационный центр (Certificate Authority -CA) | Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА - гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем. |
Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq). В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции. Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются. Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты). Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard). Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты. Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов.
Банк продавца получает свои сертификаты из платежной системы (brand). Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы. Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583). Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.
- Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).
- Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.
Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы. Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций. Информация о счете владельца карты для продавца шифруется его общедоступным ключом. Доступ продавца к этой информации является опционным, (см. замечания выше). При выборе данной опции должны быть приняты меры для обеспечения конфиденциального хранения этих данных на сервере продавца. Как минимум эта информация должна храниться в зашифрованном виде и к ней должен быть ограниченный доступ. Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения. Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью. Цифровой конверт сообщения (MessageWrapper). MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется. Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1. Таблица 4.6.2.1. Поля MessageWrapper
| Название поля | Описание |
| Message-Wrapper | {MessageHeader, Message, [MWExtension]}} |
| MessageHeader | {Version, Revision, Date, [MessageID], [RRPID], SWIdent} |
| Version | Версия SET-сообщения |
| Revision | Подтип SET-сообщения |
| Date | Дата генерации сообщения |
| MessageID | {[LID-C], [LID-M], [XID]} |
| RRPID | Идентификатор, позволяющий объединять в пары запросы и отклики |
| SWIdent | Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов |
| Message | < PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error> |
| LID-C | Локальный идентификатор, генерируемый системой владельца карты или для его системы |
| LID-M | Локальный идентификатор, генерируемый системой продавца или для его системы |
| XID | Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes) |
| MWExtension | Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности. |
Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений. При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа. При описании протокола используется нотация представленная в таблице 4.6.2.2. Таблица 4.6.2.2. Нотация протокола SET
| Понятие | Нотация | Описание | |
| Группа (tuple) | {A,B,C} | Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы | |
| Компонент | T={A,B,C} | Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т. | |
| Упорядоченное объединение | A|B|C | Служит для обозначения упорядоченного объединения элементов A,B и C | |
| Опционное значение | [A] | Значение A является опционным | Допускается любое вложение этих скобок |
| Выбор | <A,B,C> | Обозначает, что должно присутствовать одно из значений A,B или C | |
| Опционный выбор | [<A,B,C>] | То же, что и предыдущее, но сам выбор опционен | |
| Кратное использование | {A+} | Группа содержит один или более элементов A | |
| {A*} | Группа содержит нуль или более элементов A | ||
| {[A]+} | Означает, что группа содержит:один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать) | ||
| Исключающее ИЛИ | Е | Обозначает операцию исключающее ИЛИ | |
| Нотация | Оператор | Описание | ||
| H(t) | хэш | 160-битовый хэш группы t | ||
| HMAC(t,k) | Ключевой хэш-механизм | 160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1 HMAC(t,k) = H(k Е opad) | H((k Е ipad)|t)),где ipad - байт 0х36, повторенный 64 раза;opad - байт 0х5С, повторенный 64 раза; аЕ - знак операции исключающее ИЛИ. | ||
| L(t1,t2) | Связь | Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)} | ||
| Нотация операторов цифровой подписи | ||||
| S(s,t) | Подписанное сообщение | Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7. | ||
| Нотация операторов двойной цифровой подписи | ||||
| SO(s,t) | Только подпись | Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. | ||
| Нотация операторов шифрования | ||||
| E(r,t) | Асимметричное шифрование (цифровой конверт) | Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData. | ||
| EH(r,t) | Шифрование целостности | Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте. | ||
| EX(r,t,p) | Дополнительное шифрование | Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t - группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p - параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r. | ||
| EXH(r,t,p) | Дополнительное шифрование с обеспечением целостности | Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH | ||
| EK(k,t) | Симметричное шифрование посредством ключа k | Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData | ||
| Нотация операторов инкапсуляции | ||||
| Enc(s,r,t) | Простая инкапсуляция с подписью | Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData | ||
| EncK(k,s,t) | Простая инкапсуляция с подписью и предоставленным ключом | Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData. | ||
| EncX(s,r,t,p) | Дополнительная инкапсуляция с подписью | Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP | ||
| EncB(s,r,t,b) | Простая инкапсуляция с подписью с загрузкой | Подписанное зашифрованное сообщение с загрузкой (baggage) | ||
| EncBX(s,r,t,p,b) | Дополнительная инкапсуляция с подписью и загрузкой | Подписанное, Е-шифрованное составное сообщение с загрузкой | ||
OAEP - Bellare-Rogaway Optimal Asymmetric Encryption Padding
HMAC - ключевой хэш-механизм, базирующийся на алгоритме SHA-1. В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 -(BLmod 8) октетов. Каждый из байтов заполнителя содержит код 8 -(BLmod 8). Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах - 030303. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES. SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP. Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.
| Шаг | Действие |
| 1 | Алиса запускает программу вычисления дайджеста сообщения, которое она намерена послать Бобу. Этот дайджест будет использован для проверки отсутствия модификации сообщения в процессе его транспортировки от Алисы к Бобу. |
| 2 | Алиса шифрует дайджест сообщения с использованием своего секретного ключа, формируя цифровую подпись. |
| 3 | Формируется псевдослучайный код (симметричный ключ) и с помощью его шифруется сообщение, цифровая подпись и сертификат Алисы, который содержит в себе ее общедоступный ключ. Чтобы дешифровать данное сообщение Бобу будет нужен указанный выше симметричный ключ. |
| 4 | Сертификат Боба, который Алиса должна была получить заранее, содержит копию общедоступного ключа Боба. Чтобы гарантировать безопасность пересылки симметричного ключа, Алиса должна зашифровать его с использованием общедоступного ключа Боба. Зашифрованный таким способом симметричный ключ заносится в одно из полей цифрового конверта (иногда единственное поле), куда в свою очередь будет вложено зашифрованное сообщение. |
| 5 | Алиса посылает сообщение Бобу. При этом в его состав входит: Сообщение, зашифрованное с применением симметричного ключа, цифровая подпись, сертификат и асимметрично зашифрованный симметричный ключ (цифровой конверт). |
| 6 | Боб получает сообщение от Алисы, дешифрует ключ-конверт с привлечением своего секретного ключа и получает в свое распоряжение симметричный ключ. |
| 7 | Боб использует симметричный ключ для дешифрования текста сообщения, подписи Алисы и ее сертификата. |
| 8 | Осуществляется дшифрация подписи Алисы с привлечением ее общедоступного ключа, который берется из ее сертификата. В результате получается дайджест посланного сообщения. |
| 9 | Боб независимо вычисляет дайджест полученного сообщения с привлечением того же алгоритма, что был использован Алисой. |
| 10 | Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису. |
В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи. Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту). Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения.
Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения. В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца). Важным принципом при анализе работы программ SET является идемпотентность - реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы. XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения.
Его длина составляет 20 байт. BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product. Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ. Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq. Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers. Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.
- SignedData для вложения подписанной информации
- EnvelopedData для инкапсуляции зашифрованных данных
- EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма
- DigestedData для инкапсуляции хэшированных или связанных данных
SignedData Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest. Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.
| Шаг | Действие |
| 1 | Генерация сообщения SET |
| 2 | Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0) |
| 3 | Вложить код даты, включая время. |
| 4 | Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается. |
| 5 | Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса. |
| 6 | Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта |
| 7 | Вкладывается Message |
| 8 | Производится DER-кодирование вложенного сообщения |
| 9 | Сообщение передается на транспортный уровень |
| Шаг | Действие |
| 1 | Извлекается цифровой конверт сообщения |
| 2 | Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode. |
| 3 | Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений |
| 4 | Произвести DER-декодирование сообщения |
| 5 | Если сообщение содержит SignedData, произвести следующее:
|
| 6 | Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData |
| 7 | Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается. |
| 8 | Обработать сообщение |
| 9 | Актуализовать системный журнал с учетом состояния транзакции |
Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:
- Контроль сертификатов X.509
- Контроль сертификатов SET
- Обработку CRL (Certificate Revocation List)
- Обработку BrandCRLIdentifier (BCI)
| Шаг | Действие |
| 1 | Верифицировать каждый сертификат в цепи согласно правилам X.509 |
| 2 | Проверить то, что расширения KeyUsage, CertificatePolicies, PriviteKeyUsage и AuthorityKeyIdentifier находятся в согласии c Х.509. |
| 3 | Если получено новое значение BCI:а. Проверить его подпись, используя сертификат CRL центра сертификации платежной системыб. Проверить, что BrandName в BCI соответствует тому, что проверено в цепочке сертификациив. Проверить, что дата NotAfter меньше текущей датыг. Проверить SequenceNum. Если оно больше чем SequenceNum из кэша BCI запомнить BCI и проверить, что все CRL, содержащиеся в BCI находятся в кэше CRL. Запомнить любой CRL, который пока нет в кэше |
| 4 | Провести верификацию для каждого нового полученного CRL, |
| 5 | Проверить каждый сертификат |
