Протоколы Internet
         

SET и другие системы осуществления платежей


4.6.2 SET и другие системы осуществления платежей

Семенов Ю.А. (ГНЦ ИТЭФ)

Идеальная платежная система должна отвечать следующим требованиям:

  • Безопасность системы должна препятствовать воровству денег на всех этапах выполнения операции.

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

  • Система должна обеспечивать высокий уровень конфиденциальности для клиента.

  • Схема и реализация должны быть простыми (не нужно использовать сложных протоколов)

  • Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).

  • Система должна уметь выполнять операции с любыми долями самой мелкой денежной единицы.

  • Должна предоставлять достаточное количество данных для целей аудита.

  • Система должна быть свободной, то есть не иметь ограничений владельца.

    • Ни одна из существующих платежных систем не отвечает всем этим требованиям в полной мере. Существует много платежных схем, например:

    А. Электронные монеты

    Б. Электронные чеки

    В. Электронные переводы (трансферты)

    Разумеется, могут существовать и методы, сочетающие в себе любые комбинации этих схем. Эти методы должны работать не только с традиционными деньгами, но с их заменителями, акциями, облигациями, золотыми слитками, товарами и услугами. Во всех моделях помимо основных участников – продавца и покупателя, необходим посредник. Назовем его банкиром (кассиром). Теперь рассмотрим названные выше платежные модели более подробно.



    Модель электронных монет

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


    Модель электронных чеков



    Данная модель с хорошей точностью воспроизводит практику применения обычных чеков. Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен.



    Модель электронных переводов



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

    Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.

  • Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.


  • Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.


  • Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.




  • Банкир должен иметь возможность доказать третьей стороне, что он при работе со счетами строго следовал платежным поручениям. Это позволит ему отвести обвинения в осуществлении неавторизованных платежных операций.


  • Плательщик должен быть уверен, что платеж будет осуществлен именно тому продавцу товара или услуг, кому он хотел. Это подразумевает иммунитет системы против преднамеренных искажений платежных сообщений.


  • Система должна противостоять фальсификации расписок банкира.


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


  • Конфликты между клиентами должны разрешаться без участия банкира.


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


    • Не менее важную роль имеет конфиденциальность любых финансовых операций.

  • Посторонние лица не должны получать никакой существенной информации об активности клиентов платежной системы и банкира.


  • Получатель платежа не должен получать информации, позволяющей идентифицировать плательщика.


  • Банкир не должен получать информацию о том, какой товар или услуга оплачиваются.


    • Это не следует рассматривать как исчерпывающий список требований к безопасности и конфиденциальности.



    4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)



    Разработчики технологии WWW, HTML и XML (группа W3C;

    http://www.w3.org/TR/WD-mptp-951122    ) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint – Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.



    Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.

    При разработке протокола принимались во внимание следующие риски.

  • Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)


  • Мошенничество (например, направление фиктивного платежного поручения).


  • Неавторизованный отзыв платежа


  • Неавторизованная модификация заказа


  • Ошибка при выполнении кредитной операции


  • Дублирование платежного поручения (клиентом или третьим лицом)


  • Отказ от услуги (клиент или продавец отказываются использовать свои счета)


  • Отказ выполнения платежа


  • Недоставка (платеж получен, а товар не доставлен).


    • Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной.

    Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина.

    Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид:



    СП = [B, ID, AП, PKП, E, IП]SKB

    где B – идентификатор (имя) брокера; ID – идентификатор покупателя; AП – адрес доставки; PKП – общедоступный ключ покупателя; Е – время истечения действия сертификата ( брокер может обновлять его, например, раз в месяц); IП – дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB – секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером.

    Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии).

    Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению:

    wi = H(wi+1) для i= n-1, n-2,…,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H – представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера.



    i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца.

    Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж.

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



    4.6.2.2. MicroMint



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

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



    Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш- функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.

    k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.

    H(x1)=H(x2)=…=H(xk)=y

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

    Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов.

    Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA – программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу.



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

    Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется.

    Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996).

    Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет.

    Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.

  • Все фальшивые монеты теряют силу в конце месяца.


  • Фальшивые монеты могут быть сформированы после того, как брокер выбросил на рынок новую партию монет в начале месяца.


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




  • Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию.


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

    Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно.

    Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h – хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу.

    Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 – yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным.

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

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





    4.6.2.3. Безопасный протокол электронных платежей 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 ориентирован для работы в Интернет.

    На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:

  • Регистрацию держателя карточки


  • Регистрацию продавца


  • Запрос покупки


  • Авторизацию платежа


  • Перевод денег


  • Кредитные операции


  • Возврат денег


  • Отмену кредита


  • Дебитные операции


    • Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца.

    Практика электронной торговли позволяет выделить семь этапов сделки.

    Этап Действие 1 Владелец карты просматривает позиции каталога продавца:

  • В реальном масштабе времени на WEB-сервере


  • На CD-диске на своей рабочей станции


  • Читая бумажную версию каталога


  • Через поисковую систему посредника


    • 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 помогает реализовать следующие процедуры.



    Рис. 4.6.2.1. Схема взаимодействия субъектов протокола SET

  • Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.


  • Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе – номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).




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


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


  • Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.


  • Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.


  • WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.


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


  • Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).


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

    Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование.



    В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.



    Рис. 4.6.2.2. Регистрация владельца карты в центре сертификации

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

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



    Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже.

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



    Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.



    Рис. 4.6.2.3. Регистрация продавца.

    Продавец должен зарегистрироваться в СА до того, как он получит платежные инструкции от владельца карты или будет участвовать в транзакциях с расчетным центром. Перед посылкой запроса СА продавец должен получить его общедоступный ключ. Продавец должен также скопировать регистрационную форму в своем банке и идентифицировать получателя в запросе регистрации, посылаемом в СА. Регистрационная процедура начинается с посылки СА запроса сертификата СА, содержащего его общедоступный ключ и соответствующую регистрационную форму. СА идентифицирует банк продавца и выбирает подходящую регистрационную форму. В отклик СА вкладывается эта форма и его сертификат, содержащий общедоступный ключ. Этот сертификат продавец в дальнейшем использует в регистрационном процессе. Раз программа продавца имеет копию СА-сертификата, продавец может воспринимать платежные инструкции и обрабатывать транзакции SET. Прежде чем запрос сертификата будет обработан, продавец должен установить связь со своим банком (получателем). Продавцу нужны две пары общедоступных/секретных ключей – для ключевого обмена и для цифровой подписи. Эти ключи формируются программой продавца. Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА.

    Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу.



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

    Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца.

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

    Символы-префиксы Участник сделки
    C Владелец карты (Cardholder)
    M Продавец (Merchant)
    P Расчетный центр (Payment Gateway)
    CA Сертификационный центр (Certificate Authority)
    Рассмотрим диаграмму конечных состояний протокола SET (см. рис. 4.6.2.4).



    Рис. 4.6.2.4. Диаграмма реализации протокола SET

    Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.).

    Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным “истинно”, так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured – сделка оплачена) и заказ обрабатывается.



    Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued).

    Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена. С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes).

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

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



    XID

    		 20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения).


    RRPID

    		 20-байтовое число, которое однозначно идентифицирует запрос.


    locallD-M

    		 1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца


    paySysID

    		 1-64 байтовый идентификатор транзакции


    MerOrderNum

    		 1-25 байтовый номер заказа продавца
    <


    /p> Рассмотрим более подробно функции субъектов протокола SET.



    Держатель карты

     (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).


  • Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.


    • Каждая платежная система обеспечивает поддержку CRL в пределах зоны своей ответственности. Архитектура 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, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности.
    <


    /p> Обработка сообщения начинается с 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 является опционным (этот элемент может отсутствовать)
    Исключающее ИЛИ A

    		 Обозначает операцию исключающее ИЛИ


    Таблица 4.6.2.3

    . Операторы, используемые протоколом SET

    Нотация Оператор Описание
    H(t) хэш 160-битовый хэш группы t
    HMAC(t,k) Ключевой хэш-механизм 160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1

    HMAC(t,k) = H(k A

    opad) | H((k A

    ipad)|t)),

    где ipad - байт 0х36, повторенный 64 раза;



    opad

     – байт 0х5С, повторенный 64 раза; а

    A - знак операции исключающее ИЛИ.
    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) Дополнительная инкапсуляция с подписью и загрузкой Подписанное, Е-шифрованное составное сообщение с загрузкой
    <


    /p>

    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 –(||BL||mod 8) октетов. Каждый из байтов заполнителя содержит код 8 –(||BL||mod 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 Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису.
    <


    /p> В протоколе 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 из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.



    Рис. 4.6.2.5. SignedData

    Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest.



    Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.



    Рис. 4.6.2.6. EnvelopedData

    В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo.

    Тип EncryptedData из PKCS #7 проиллюстрирован на рис. 4.6.2.7.



    Рис. 4.6.2.7. EncryptedData

    Тип DigestedData из PKCS #7 проиллюстрирован на рис. 4.6.2.8.



    Рис. 4.6.2.8. DigestedData

    Обработка сообщений

    Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4.



    Таблица 4.6.2.4

    . Отправление сообщения

    Шаг Действие
    1 Генерация сообщения SET
    2 Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0)
    3 Вложить код даты, включая время.
    4 Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается.
    5 Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса.
    6 Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта
    7 Вкладывается Message
    8 Производится DER-кодирование вложенного сообщения
    9 Сообщение передается на транспортный уровень
    Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5.



    Таблица 4.6.2.5.

     Прием и обработка входного сообщения

    Шаг Действие
    1 Извлекается цифровой конверт сообщения
    2 Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode.
    3 Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений
    4 Произвести DER-декодирование сообщения
    5 Если сообщение содержит SignedData, произвести следующее:



      1. Актуализовать системный кэш с учетом полученных CRL.


      2. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов


      3. Проверить подпись сообщения
      6 Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData
      7 Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается.
      8 Обработать сообщение
      9 Актуализовать системный журнал с учетом состояния транзакции
      <


      /p> Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:

    1. Контроль сертификатов X.509


    2. Контроль сертификатов SET


    3. Обработку CRL (Certificate Revocation List)


    4. Обработку BrandCRLIdentifier (BCI)


      5. На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6.



      Таблица 4.6.2.6

      . Верификация сертификатов

      Шаг Действие
      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 Проверить каждый сертификат


      4.6.2.1.1. Оттиски (Thumbprints)



      Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:

    5. UnsignedCertificate


    6. UnsignedCertificateRevocationList


    7. UnsignedBrandCRLIdentifier


      8. Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7.





      Таблица 4.6.2.7.

       Посылка оттиска

      Шаг Действие
      1 Инициализировать буфер для запоминания оттисков
      2 Добавить оттиск (хэш):

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


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


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


      		11.
      3 Присылается результат работы шага 2.
      Получатель проверяет то, что отправитель владеет всеми сертификатами, CRL и BCI, необходимыми для завершения обработки сообщения. Получатель может проигнорировать оттиски и послать эту информацию запросившему. Обработка оттисков получателем представлена в таблице 4.6.23.8.



      Таблица 4.6.2.8

      . Обработка оттисков получателем

      Шаг Действие
      1 Инициализировать буфер для запоминания оттисков
      2 Для каждого из них:

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


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


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


      		14.
      3 Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике.
      <


      /p> Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.

      Шаг Действие
      1 Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t
      2 Добавить результат шага 1 в группу t
      3 Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2
      4 Послать результат работы шага 3
      Другие варианты инкапсуляции осуществляются сходным образом.

      Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования – RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9.



      Таблица 4.6.2.9.

       Процедура асимметричного шифрования

      Шаг Действие
      1 Инициализировать и загрузить информационные поля, зависимые от типа сообщения
      2 Преобразовать информационные поля, подлежащие шифрованию, в формат DER
      3 Сформировать новый ключ DES
      4 Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC.
      5 Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4.
      6 Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
      7 Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3.
      8 Применить OAEP для буфера цифрового конверта
      9 Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r
      10 Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9
      11 Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5
      12 Прислать результат шага 11
      <


      /p> Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10.



      Таблица 4.6.2.10

      . Асимметричное шифрование с гарантией целостности

      Шаг Действие
      1 Инициализировать и загрузить информационные поля, зависимые от типа сообщения
      2 Преобразовать информационные поля, подлежащие шифрованию, в формат DER
      3 Вычислить хэш SHA-1 результата шага 2
      4 Сформировать новый ключ DES
      5 Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC.
      6 Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5.
      7 Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
      8 Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5.
      9 Применить OAEP для буфера цифрового конверта
      10 Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r
      11 Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10
      12 Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6
      13 Прислать результат шага 12
      Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11.



      Таблица 4.6.2.11.

       Процедура симметричного шифрования

      Шаг Действие
      1 Инициализировать и загрузить информационные поля, зависимые от типа сообщения
      2 Преобразовать информационные поля, подлежащие шифрованию, в формат DER
      3 Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC.
      4 Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3.
      5 Прислать результат шага 4
      <


      /p> Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования.

      Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo.

      Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7.

      В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes

      последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12.





      Таблица 4.6.2.12.

       Процедура формирования цифровой подписи

      Шаг Действие
      1 Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию
      2 Преобразовать информацию, подлежащую подписанию в формат DER
      3 Использовать результат шага 2 для инициализации компонента content из ContentInfo.
      4 Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста
      5 Вычислить дайджест сообщения, используя SHA-1 для результата шага 3
      6 Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов
      7 Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута – значением дайджеста, вычисленного на этапе 5
      8 Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData
      9 Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData
      10 Если тип сообщения требует двух подписей, повторить шаги с 4 по 9
      Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13.



      Таблица 4.6.2.13.

      Процедура ключевого хэширования

      Шаг Действие
      1 Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36
      2 Установить opad равным буферу, содержащему 64 байта с кодами 0х5С
      3 Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля.
      4 Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad
      5 Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4
      6 Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора
      7 Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad
      8 Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7
      9 Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора
      10 Прислать результат работы шага 9
      <


      /p> Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP.

      Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора.

      Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14.



      Таблица 4.6.2.14.

       Процедура вычисления дайджеста сообщения.

      Шаг Действие
      1 Установить B равным адресу группы t, для которой вычисляется дайджест
      2 Установить L равным длине группы t
      3 Инициализировать 160-битный буфер для хранения хэша SHA-1
      4 Вычислить хэш SHA-1 для буфера, используя B и L
      5 Положить результат шага 4 в поле digest DigestedData
      6 Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm
      7 Установить значение версии равным нулю
      Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1.



      Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными.

      Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15.



      Таблица 4.6.2.15

      . Описание алгоритма OAEP

      Шаг Действие
      1 Подготовить дополнительные данные, как это описано в формате сообщения
      2 Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию
      3 Сформировать новый случайный ключ для DES-шифрования регулярной части данных
      4 Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block).
      5 Взять байт, содержащий код 0х03 (тип блока – BT), семь байтов нулей (байты верификации – V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB
      6 Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1
      7 Вычислить А=DB A

      H1(E-Salt)
      8 Осуществить присвоение B= E-Salt A

      H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1
      9 Присвоить I случайное значение, не равное 0х00 или 0х80
      10 Зашифровать полученный блок R с помощью RSA
      Алгоритм работа OAEP показан на рисунке 4.6.2.9.

      В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.





      Рис. 4.6.2.9. Диаграмма работы OAEP



      Обработка ошибок



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

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

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

      Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.

      Шаг Действие
      1 Сформировать ErrorTBC следующим образом:

    14. Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16)


    15. Сформировать новый ErrorNonce


    16. Если ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения.


    17. Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификата


    18. Если ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификата


    19. ErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика.


      		20.
      2 Подписать сообщение Error, если имеется сертификат подписи
      3 Вызвать формирование цифрового конверта и отправить сообщение
      <


      /p> Для сообщения Error определены следующие поля

      Имя поля Описание


      Error

      <Signed

       Error, UnsignedError >


      SignedError

      S(EE, ErrorTBS)


      UnsignedError

      ErrorTBS



      Неподписанная версия Error будет использоваться, если объект не имеет сертификата подписи


      ErrorTBS

      		 { ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg}


      ErrorCode

      		 Цифровой код, определяющий условия ошибки (см. табл. 4.6.2.16)


      ErrorNonce

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


      ErrorOID

      		 Объектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку


      ErrorThumb

      		 Оттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи


      ErrorMsg

      <MessageHeader, BadWrapper>


      MessageHeader

      		 Заголовок сообщения, которое вызвало ошибку


      BadWrapper

      		 Цифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт)


      Таблица 4.6.2.16.

       ErrorCode

      Ошибка Описание


      unspecifiedFailure

      		 Причина неудачи не фигурирует в списке стандартных ошибок


      messageNotSupported

      		 Этот вполне корректный тип сообщения не поддерживается получателем


      decodingFailure

      		 Произошла ошибка в процессе DER-кодирования сообщения


      invalideCertificate

      		 Сертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат.


      expiredCertificate

      		 Время действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат.


      revokedCertificate

      		 Сертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат.


      missingCertificate

      		 Сертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя.


      signatureFailure

      		 Цифровая подпись сообщения не может быть верифицирована


      badMessageHeader

      		 Заголовок сообщения не может быть обработан


      wrapperMsgMismatch

      		 Содержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения.


      versionTooOld

      		 Номер версии сообщения слишком стар для получателя


      versionTooNew

      		 Номер версии сообщения слишком нов для получателя


      unrecognizedExtension

      		 Сообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb

      идентифицирует сертификат


      messageTooBig

      		 Сообщение слишком длинно для получателя


      signatureRequired

      		 Неподписанная версия сообщения неприемлема


      messageTooOld

      		 Дата сообщения слишком далеко в прошлом для получателя


      messageTooNew

      		 Дата сообщения слишком близка для получателя


      thumbsMismatch

      		 Оттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне


      unknownXID

      		 Получен неизвестный RRPID


      challengeMismatch

      		 Вызов, посланный в запросе, не согласуется с вызовом в отклике
      <


      /p> Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут.



      Работа с сертификатами



      В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:

    20. Нужно сформировать пару #1 корневых ключей R1


    21. Сгенерировать сертификат для корневого ключа #1 (C1)


    22. Сформировать пару #2 корневых ключей R2


    23. Вычислить оттиск (хэш – H2) общедоступной составляющей R2


      24. С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом.

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

    24. Вычисляется общедоступная часть корневого ключа #3 (R3)


    25. Определяется оттиск R3 (хэш H3)


    26. Формируется сертификат корневого ключа #2 (C2 – содержит H3)


      27. Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.



      Рис. 4.6.2.10. Иерархия субъектов сертификации

      Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority). Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List).



      BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы.

      Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL.

      Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы.

      Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA.

      Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д.

      Любой центр сертификации выполняет следующие функции:

    27. Формирование и выдача сертификата


    28. Обновление сертификатов


    29. Контроль работоспособности сертификатов и удаление непригодных


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

      Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2).



    30. Владелец карты посылает запрос сертификата


    31. ССА производит шифрование сертификата для защиты передачи номера платежной карты в ССА


    32. Владелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССА


    33. ССА откликается посылкой формы для регистрации сертификата карты


    34. Владелец карты заполняет форму, которая включает в себя его общедоступный ключ, и посылает форму в ССА для регистрации


    35. ССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты.


      36. Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель – acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.

    36. Продавец посылает запрос сертификата в МСА.


    37. МСА откликается посылкой регистрационной формы.


    38. Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.


    39. Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу.


      40. Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации.

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



      При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.



      Рис. 4.6.2.11. Иерархия проверок



      Основной протокол



      Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект – EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего.

      Прежде чем запросить сертификат владелец карты должен выполнить следующее:

    40. Получить счет в одной из платежных систем, например, в VISA или MasterCard.


    41. Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа. Понятно, что местом его хранения не может быть оперативная память, да и дисковые накопители вряд ли можно считать приемлемым местом записи, если хотя бы теоретически к ним может быть получен доступ.


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


    43. Иметь URL или электронный почтовый адрес для связи с ССА.


    44. Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.


      45. Продавец должен иметь следующее, прежде чем посылать запрос сертификата:

    45. Идентификатор, присланный получателем (Acquirer – банк продавца)


    46. Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа.


    47. Программа продавца должна иметь определенную информацию, объем и характер которой согласуется с банком продавца.


    48. URL или электронный почтовый адрес для связи с MCA.


    49. Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.




      50. Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата:

    50. Возможностью формировать пары ключей (секретый/общедоступный) и местом их надежного храниения.


    51. Получить банковский идентификационный номер BIN (Bank ID)


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


    53. Иметь URL или электронный почтовый адрес для связи с PCA


    54. Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.


      55. После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:

    55. Приложение владельца карты посылает CardCInitReq CCA. При этом используется идентификатор платежной системы или идентификатор, полученный из стартового сообщения.


    56. ССА посылает приложению SET сообщение CardCInitRes.


    57. Приложение владельца карты посылает ССА сообщение RegFormReq.


    58. ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.


    59. Приложение владельца карты заполняет регистрационную форму, заносит свой общедоступный ключ и сертификат, подлежащий обновлению (если имеется) в CertReq и посылает его ССА.


    60. ССА формирует сертификат, включает его в CertRes и посылает владельцу карты.


      61. Функционирование приложения продавца и платежного центра имеет свою специфику:

    61. Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.


    62. СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.


    63. Приложение SET отображает эту форму и требования. Пользователь должен заполнить регистрационную форму и согласиться с предлагаемыми требованиями.




    64. Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.


    65. СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру.


      66. Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13. Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.



      Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА

      Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений.

      Приложение SET формирует сообщение CardCInitReq следующим образом.

      Шаг Действие
      1 Генерируется RRPID
      2 Генерируется LID-EE
      3 Формируется новый случайный Chall-EE
      4 Копируется BrandID, который запомнен или получен в инициализирующем сообщении
      5 Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты
      6 Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА
      Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17.

      Таблица 4.6.2.17. Структура сообщения CardCInitReq



      CardCInitReq

      		 {RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]}


      RRPID

      		 Идентификатор пары запрос/отклик


      LID-EE

      		 Локальный ID, сформированный для системы владельца карты


      Chall-EE

      		 Вызов владельца карты по поводу пригодности подписи, адресованный ССА


      BrandID

      		 Идентификатор платежной системы для запрошенного сертификата


      Thumbs

      		 Список оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты
      <


      /p> ССА, получив CardCInitReq, выполнит следующие операции:

      Шаг Действие
      1 Получить CardCInitReq из сообщения Receive
      2 Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID
      3 Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes
      После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.

      Шаг Действие
      1 Сформировать структуру данных CardCInitResTBS, для этого:

    66. Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReq


    67. Сформировать опционно LID-CA


    68. Заполнить CAEThumb оттиском сертификата шифрования данных CCA


    69. Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifier


    70. Скопировать список оттисков из CardCInitReq


      		71.
      2 Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS.

      Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков.
      3 Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты
      Формат отклика CardCInitRes представлен в таблице ниже.



      CardCInitRes

      S(CA, CardCInitResTBS)


      CardCInitResTBS

      {RRPID, LID-EE, Chall



      -EE, [LID-CA], CAEThumb, [BrandCRLIdentifier], [Thumbs]}


      RRPID

      		 Идентификатор пары запрос/отклик


      LID-EE

      		 Копируется из CardCInitReq


      Chall-EE

      		 Копируется из CardCInitReq


      LID-CA

      		 Локальный ID. Генерируется системой CCA или для нее


      CAEThumb

      		 Оттиск сертификата ключевого обмена CCA, котоый владелец карты должен использовать для шифрования RegFormReq


      BrandCRLIdentifier

      		 Смотри секцию описания BrandCRLIdentifier


      Thumbs

      		 Копируется из CardCInitR
      <


      /p> Приложение владельца карты обрабатывает сообщение CardCInitRes в следующей последовательности:

      Шаг Действие
      1 Получить CardCInitRes из входного сообщения (Receive)
      2 Проверить, что RRPID соответствует тому, что был послан в CardCInitReq и тому, который получен в цифровом конверте сообщения CardCInitRes. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным unknownRRPID
      3 Проверить, что полученный список оттисков соответствует тому, что был послан в сообщении CardCInitReq. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным thumbsMismatch
      4 Проверить, что полученный Chall-EE равен посланному в CardCInitReq. Если равенство отсутствует, посылается сообщение об ошибке с кодом ErrorCode равным challengeMismatch.
      5 Запомнить LID-CA (если этот элемент был включен) для последующей записи в RegFormReq. Проверить, что полученный Chall-EE равен посланному в CardCInitReq.
      6 Проверить, что приложение владельца карты поддерживает один из алгоритмов, перечисленных в туннельном расширении сертификата шифрования CA. Если приложение владельца карты не поддерживает ни одного общего с СА алгоритма, следует уведомить об этом пользователя и прервать дальнейшую обработку сообщения СА.
      Если приложение владельца карты успешно обработало отклик CardCInitRes, оно может сформировать и послать сообщение RegFormReq. Это сообщение шифруется приложением владельца карты с использованием сертификата, полученного от ССА в CardCInitRes. Последовательность формирования и посылки RegFormReq представлена ниже в таблице.

      Шаг Действие
      1 Сформировать RegFormReqData согласно следующему формату:

    71. Сформировать новый RRPID


    72. Скопировать LID-EE, посланный в CardCInitReq


    73. Сформировать новый Chall-EE2


    74. Если такой элемент был включен в CardCInitRes, скопировать LID-CA


    75. Заполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца карты


    76. Заполнить поле языка (Language)


    77. Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется).


      		78.
      2 Сформировать структуру RegFormReqTBE:

    78. Ввести ReqFormReqData


    79. Заполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель.


    80. Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly


      		81.
      3 Оформить поле данных, подлежащих дополнительному шифрованию:

    81. Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байт


    82. Для маскирования PAN сгенерировать новый EXNonce


      		83.
      4 Зашифровать данные, используя оператор EXH со следующими параметрами:

    83. RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE и


    84. Результатом шага 3 в качестве данных, подлежащих шифрованию


      85. Для шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes
      5 Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА
      <


      /p> Структура сообщения RegFormReq представлена в таблице 4.6.2.18.



      Таблица 4.6.2.18

      . Структура RegFormReq



      RegFormReq

      		 EXH(CA, RegFormReqData, PANOnly)


      RegFormReqData

      		 {RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]}


      PANOnly

      		 Структуру смотри в табл. ниже


      RRPID

      		 ID пары запрос/отклик


      LID-EE

      		 Копируется из CardCInitRes


      Chall-EE2

      		 Вызов ЕЕ, имеющий целью обновление подписи СА


      LID-CA

      		 Копируется из CardCInitRes


      RequestType

      		 Смотри табл. 4.6.2.19


      Language

      		 Предпочтительный язык последующего текста


      Thumbs

      		 Списки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты
      Поля данных PANOnly



      Имя поля

      		 Описание


      PAN

      		 Номер платежной карты владельца


      EXNonce

      		 Случайное число, используемое для маскирования PAN


      Таблица 4.6.2.19

      . Значения кодов RequestType

      Тип запроса Только сертификат подписи Только сертификат шифрования Оба сертификата
      Начальный запрос владельца карты 1 2* 3*
      Запрос обновления владельца карты 10 11* 12*
      * указывает на значения, зарезервированные для будущего использования

      Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.

      Шаг Действие
      1 Извлечь RegFormReq из входного сообщения
      2 Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя.
      3 Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка.
      4 Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID
      После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.

      Шаг Действие
      1 Сформировать RegFormTBS в соответствии со следующей процедурой:

    85. Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqData


    86. Если в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса.


    87. Сгенерировать новый Chall-CA


    88. Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier.


    89. Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде:


    90. Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и Language


    91. Включить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено.


    92. Опционно добавляется URL для отображения логотипа платежной системы или карты.


    93. CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes.


    94. Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData:




          1. Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты.


          2. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.
          2 Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.
          3 Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes
          <


          /p> Структура сообщения RegFormRes представлена в таблице 4.6.2.20.



          Таблица 4.6.2.20

          . Структура RegFormRes



          RegFormRes

          		 S(CA, RegFormResTBS)


          RegFormResTBS

          		 {RRPID, LID-EE, Chall-EE2,[LID-CA], Chall-CA, [CAEThumb], RequestType, RegFormOrReferral, [BrandCRLIdentifier], [Thumbs]}


          RRPID

          		 ID пары запрос/отклик


          LID-EE

          		 Копируется из RegFormReq


          Chall-EE2

          		 Копируется из RegFormReq


          LID-CA

          		 Локальный ID. Формируется для системы СА.


          Chall-CA

          		 СА обращение по поводу пригодности сертификата запрашивающей стороны


          CAEThumb

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


          RequestType

          		 Смотри табл. 4.6.2.19


          RegFormOrReferral

          		 Смотри табл. 4.6.2.21


          BrandCRLIdentifier

          		 Смотри описание в разделе о BrandCRLIdentifier ниже.


          Thumbs

          		 Копируется из RegFormReq


          Таблица 4.6.2.21

          . Структура поля RegFormOrReferral



          RegFormOrReferral

          		 <RegFormData, ReferralData>


          RegFormData

          		 {[RegTemplate], PolicyText}


          ReferralData

          		 {RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}


          RegTemplate

          		 {RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}


          PolicyText

          		 Заявление, которое должно быть отображено в системе отправителя запроса вместе с RegTemplate


          Reason

          		 Заявление, связанное с запросом и отображаемое в системе отправителя запроса


          ReferralURLSeq

          {ReferralURL +}



          Опционные URL ссылок, перечисленные в порядке важности


          RegFormID

          		 Идентификатор, присвоенный СА


          BrandLogoURL

          		 URL базовой страницы расчетной системы


          CardLogoURL

          		 URL базовой страницы финансовой организации


          RegFieldSeq

          {RegField +}


          ReferralURL

          		 URL альтернативного СА для обработки запросов сертификатов для данного объекта


          RegField

          {[FieldId], FieldName, [FieldDesc], [FieldLen], FieldRequired, FieldInvisible}


          FieldID

          		 Идентификаторы объекта для полей регистрационной формы


          FieldName

          		 Одно или более имен полей, которые должны быть отображены в качестве меток для заполнения формы; текст записывается на языке, определенном в RegFormReq или Me-AqCInitReq


          FieldDesc

          		 Описание содержимого поля на языке, заданном в RegFormReq или Me-AqCInitReq; содержит дополнительную информацию для использования в случае, когда владелец карты запросит помощи при заполнении формы


          FieldLen

          		 Максимальная длина поля


          FieldRequired

          		 Булево значение, указывающее на необходимость ввода (должен ли поле заполнить владелец карты или оно будет заполнено приложением) (невидимое поле)


          FieldInvisible

          		 Булево значение, указывающее на то, что поле не должно отображаться пользователю; приложение должно заполнить FieldValue, основываясь на FieldID, или оставить его пустым
          <


          /p> Приложение владельца карты обрабатывает сообщение RegFormRes следующим образом:

          Шаг Действие
          1 Получить RegFormRes из входного сообщения
          2 Проверить подпись. Если подпись некорректна, отправить сообщение об ошибке с ErrorCode равным signatureFailure.
          3 Получить RRPID, RequestType, LID-EE, Chall-EE2, CAEThumb из RegFormTBS
          4 Проверить, что RRPID является тем же самым, что и идентификатор, записанный в цифровом конверте сообщения, и совпадет с кодом, присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным unknownRRPID.
          5 Проверить, что RequestType, LID-EE и Chall-EE2 идентичны присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным challengeMismatch.
          6 Если был включен CAEThumb, запомнить соответствующий сертификат шифрования, использованный для шифрования CertReq.
          7 Проверить, что полученные оттиски, соответствуют посланным в сообщении CardCInitReq. Если соответствия нет, отправить сообщение об ошибке с ErrorCode равным thumbsMismatch.
          8 Если в RegFormTBS включены данные RegFormData то:

        1. Запоминается LID-CA


        2. Прежде чем приложение SET сформирует CertReq, отображается текст общих требований и необходимый отклик пользователя


        3. Отображаются видимые поля регистрационной формы и приглашение для заполнения их пользователем.


        4. Если RegFormRes содержит URL, отображаются логотипы платежной системы или эмитента карты.


        5. Заполняются видимые поля регистрационной формы. Если поле является необходимым, а приложение не может его заполнить, оно остается пустым, а остальная часть формы заполняется и посылается обычным порядком.


        6. После того как пользователь завершил ввод, формируется сообщение CertReq.


          		7.
          9 Если в RegFormResTBS включено поле ReferralData то:

        7. Отображается причина (Reason)


        8. Если включено ReferralLoc, отображаются URL или электронный адрес из ReferralLoc


        9. CertReq не формируется. Протокол переходит к формированию CardCInitReq


          		10.
          Пары сообщений Me-AqCInitReq/Res используются продавцом или расчетным центром для получения регистрационной формы сертификата. Продавец или расчетный центр запускают сертификатный протокол путем посылки запроса Me-AqCInitReq. Это сообщение содержит банковскую информацию продавца или расчетного центра, тип запрашиваемого сертификата, а также сертификаты, CRL и BrandCRLIdentifier, которые хранятся в надежном сертификатном кэше. Если MCА или РСА имеют регистрационные формы на подходящем языке для указанного банка, она присылается в сообщении Me-AqCInitRes вместе с любыми сертификатами, CRL и BrandCRLIdentifier, которые могут потребоваться продавцу или расчетному центру для проверки цифровой подписи. Если MCА или РСА не имеют подходящей регистрационной формы и/или имеют дополнительную информацию относительно отклонения поступившего запроса, эти данные также заносятся в Me-AqCInitRes. Схема работы протокола сертификатов для данного случая показана на рис. 4.6.2.13.





          Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA

          При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:

          Шаг Действие
          1 Сформировать новый RRPID
          2 Сформировать новый LID-EE
          3 Сформировать новый случайный код Chall-EE
          4 Занести BrandID, который хранится в приложении или получен в стартовом сообщении
          5 Заполнить поле RequestType
          6 Заполнить поле Language (язык)
          7 Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются)
          8 Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID.
          9 Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА.
          Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22.



          Таблица 4.6.2.22

          . Формат Me-AqCInitReq



          Me-AqCInitReq

          		 {RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]}


          RRPID

          		 ID пары запрос/отклик


          LID-EE

          		 Локальный ID; формируется ЕЕ-системой или для нее


          Chall-EE

          		 Обращение EE к СА по поводу пригодности подписи


          RequestType

          		 Смотри табл. 4.6.2.24


          IDData

          		 См. табл. 4.6.2.23


          BrandID

          		 BrandID запрошенного сертификата


          Langauage

          		 Желательный язык последующих текстов


          Thumbs

          		 Список оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ
          Формат поля IDData описан в таблице 4.6.2.23.



          Таблица 4.6.2.23

          . Формат IDData



          IDData

          		 <MerchantAcquirerID, AcquirerID> (только для продавца и получателя)


          MerchantAcquirerID

          		 {MerchantBIN, MerchantBIN}


          AcquirerID

          		 {AcquirerBIN, [AcquirerBusinessID]}


          MerchantBIN

          		 Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer)


          MerchantID

          		 Идентификатор продавца, присвоенный ему его банком (Acquirer)


          AcquirerBIN

          		 Идентификационный номер банка для Acquirer (BIN получателя)


          AcquirerBusinessID

          		 Рабочий идентификационный номер банка продавца
          <


          /p>

          Таблица 4.6.2.24

          . Значения RequestType для продавца и платежного центра

          Тип запроса Только сертификат подписи Только сертификат шифрования Оба

          сертификата
          Начальный для продавца 4 5 6
          Начальный для расчетного центра 7 8 9
          Обновление для продавца 13 14 15
          Обновление для расчетного центра 16 17 18
          Получив Me-AqCInitReq, СА производит его обработку следующим образом:

          Шаг Действие
          1 Выделяеть Me-AqCInitReq из входного сообщения
          2 Проверяеть, что RRPID из цифрового конверта сообщения совпадает с полученным в Me-AqCInitReq. Если это не так, формируется сообщение об ошибке с errorCode unknownRRPID.
          3 Запоминается RRPID, LID-EE, Chall-EE, BrandID, Language, Thumbs и IDData
          Проверив корректность Me-AqCInitReq, CA формирует Me-AqCInitRes. Эта операция включает в себя следующие шаги:

          Шаг Действие
          1 Сформировать сообщение Me-AqCInitResTBS:

        10. Скопировать RRPID, LID-EE и Chall-EE из Me-AqCInitReq


        11. Опционно сгенерировать LID-CA для данного вида запроса обслуживания


        12. Сгенерировать новый Chall-CA


        13. Если регистрационная форма продавца или платежного центра доступна для BIN, языка и RequestType, то:


        14. Заполнить поле RegFormData, используя RegTemplate и PolicyText, соответствующие Requesttype, BIN и Language


        15. Опционно включить URL для отображения логотипа платежной системы и/или карты


        16. Включить RegFormID и RegFieldSeq. При обновлении RegFieldSeq может быть опущено.


        17. Если СА посредством AcctData аутентифицирует продавца или расчетный центр, заполнить поле AcctDataField, указывая наименование данных, подлежащих вводу, описание, их длину и будут ли данные вводиться ЕЕ (конечным пользователем).


        18. Если соответствующая форма для продавца или расчетного центра не доступна, заполняется поле ReferralData:




          1. Включить причину отказа обслуживания, которая будет отображена для продавца или расчетного центра


          2. Опционно включить в ReferralLoc электронный адрес и/или URL, где пользователь может получить дополнительную информацию, об отказе обслуживания.


          3. Включить оттиск сертификата шифрования CA, CAEThumb.


          4. Если BrandCRLIdentifier в полученном Me-AqCInitReq не специфицирован, ввести BrandCRLIdentifier.


          5. Скопировать список оттисков (Thumbs) из Me-AqCInitReq


          6. Скопировать RequestType, полученный в Me-AqCInitReq.


            		7.
            2 Подписать Me-AqCInitResTBS, установить тип содержимого SignedData равным id-set-content-Me-AqCInitResTBS.
            3 Сформировать цифровой конверт и послать сообщение Me-AqCInitRes продавцу или расчетному центру.
            <


            /p> MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см. табл. 4.6.2.25)



            Таблица 4.6.2.25

            . Шаблон регистрационной формы MCA и PCA



            Me-AqCInitRes

            		 S(CA, Me-AqCInitResTBS)


            Me-AqCInitResTBS

            		 {RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}


            RRPID

            		 ID пары запрос/отклик


            LID-EE

            		 Копируется из Me-AqCInitReq


            Chall-EE

            		 Копируется из Me-AqCInitReq


            LID-CA

            		 Локальный ID; генерируется СА системой или для нее


            Chall-CA

            		 СА обращение по поводу пригодности сертификата запрашивающей стороны


            RequestType

            		 Смотри табл. 4.6.2.24


            RegFormOrReferral

            		 Смотри табл. 4.6.2.21


            AcctDataField

            RegField

            ; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq


            CAEThumb

            		 Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq


            BrandCRLIdentifier

            		 Смотри раздел описания BrandCRLIdentifier ниже.


            Thumbs

            		 Копируется из Me-AqCInitReq
            Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes

            следующим образом:

            Шаг Действие
            1 Получить Me-AqCInitRes из входного сообщения.
            2 Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.
            3 Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType
            4 Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.
            5 Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.
            6 Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.
            7 Если в Me-AqCInitResTBS включено поле RegFormData то:

          7. Запомнить LID-CA и Chall-CA


          8. Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq


          9. Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей


          10. Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты


          11. Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля


          12. Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq.


            		13.
            8 После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.
            9 Если в Me-AqCInitResTBS включено поле ReferrelData, то:

          13. Отображается причина


          14. Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc


          15. CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq


            		16.
            <


            /p> Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq.

            Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме.

            Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме.

            Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме.

            Запрос сертификата (CertReq) содержит в себе:



            • Новые общедоступные ключи.


            • Обновляемые сертификаты (если таковые есть).


            • Заполненную регистрационную форму.


            • Информацию об аккоунте ЕЕ


            • Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,


            • Другие контрольные коды


              • Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа.

              Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq.

              ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo.



              Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.

              Шаг Действие
              1 Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата
              2 Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.
              3 Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код – CardSecret.
              4 Генерируется 160-битовый случайный код – EXNonce
              5 Формируется CertReqTBS:

            • Генерируется RRPID


            • Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType.


            • Заполняется поле RequestData


            • Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый.


            • Генерируется новый Chall-EE3


            • Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения.


            • Если ЕЕ является продавец карты или расчетный центр, то:


            • заполняется поле IDData и,


            • если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ


            • Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret.


            • Сформировать EXNonce


            • Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes


            • Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.


              		•
              6
            • Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь.


            • Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА.


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


            • Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.


              		•
              7 Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0.

              Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.
              8 Данные укладываются в конверт с использованием техники EncX:

              Включить:

              Обработка

              а. В качестве подписанных данных CertReqTBS

              То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.

              Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS.

              Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату.

              Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи.

              Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL.

              Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS.

              b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию

              Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes

              c. CertReqTBEX в качестве данных, подлежащих шифрованию

              Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
              9 Сформировать цифровой конверт и послать сообщение CertReq центру СА
              <


              /p> Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:

              Шаг Действие
              1 Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи
              2 Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования
              3 Сгенерируется 160-битное случайное число - EXNonce
              4 Данные CertReqData формируются следующим образом:

            • Генерируется RRPID


            • Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем.


            • Заполняется поле ReqestDate


            • Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое.


            • Генерируется новое Chall-EE3


            • Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется.


            • Заполнить поле IDData


            • Занести RegFormID, полученный из Me-AqCInitRes


            • Занести новую или скорректированную форму RegForm


            • Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА.


            • Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению.


            • Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты.


              		•
              5 Поместить данные в цифровой конверт, используя инкапсуляцию Enc:

              Включить:

              Обработка

            • CertReqData в качестве информации, подлежащей подписыванию.


              • То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.

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

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

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

              Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData.

              Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE.

            • Ключ DES в качестве данных, подлежащих дополнительному шифрованию


              • Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes.

            • CertReqTBE в качестве обычных данных, подлежащих шифрованию


              • Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.

               
              6 Подготовить цифровой конверт и послать CertReq центру СА
              <


              /p> Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26:



              Таблица 4.6.2.26.

               Формат CertReq



              CertReq

              		 <EncX(EE, CA, CertReqData, AcctInfo), Enc(EE, CA, CertReqData)>

              Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ:

            • секретный ключ нового сертификата подписи


            • существующий сертификат подписи для запроса сертификата шифрования или


            • существующий сертификат подписи для запроса обновления


              • Эти подписи без соответствующего сертификата являются лишь проформой; они доказывают лишь то, что ЕЕ владеет секретным ключом.


              CertReqData

              		 {RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]}


              AcctInfo

              		 <PANData0, AcctData>

              Если отправитель запроса – владелец карты, вводится PANData0.

              Если отправитель запроса – продавец или получатель, вводится AcctData


              RRPID

              		 ID пары запрос/отклик


              LID-EE

              		 Копируется из RegFormRes или Me-AqCInitRes


              Chall-EE3

              		 Обращение ЕЕ по поводу обновления подписи СА


              LID-CA

              		 Копируется из RegFormRes или из Me-AqCInitRes


              Chall-CA

              		 Копируется из RegFormRes или из Me-AqCInitRes


              RequestType

              		 Смотри таблицу 4.6.2.24


              RequestDate

              		 Дата запроса сертификата


              IDData

              		 См. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты.


              RegFormID

              		 Идентификатор, присвоенный СА


              RegForm

              		 { RegFormItems +}


              Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ


              CABackKeyData

              {CAAIgId, CAKey}


              publicKeySorE

              		 {[ PublicKeyS], [PublicKeyE]}

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


              EEThumb

              		 Оттиск сертификата ключа шифрования, который обновляется


              Thumbs

              		 Списки сертификатов, включая корневой, CRL и BrandCRLIdentifier, используемые в данный момент ЕЕ.


              PANData0

              		 См. табл. 4.6.2.27


              AcctData

              		 См. табл. 4.6.2.28


              RegFormItems

              		 {FieldName, FieldValue}


              CAAlgId

              		 Идентификатор симметричного алгоритма шифрования


              CAKey

              		 Секретный ключ, соответствующий идентификатору алгоритма


              PublicKeyS

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


              PublicKeyE

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


              FieldName

              		 Одно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq


              FieldValue

              		 Величина, введенная ЕЕ
              <


              /p>

              Таблица 4.6.2.27

              . Формат PANData0



              PANData0

              		 {PAN, CardExpiry, CardSecret, EXNonce}


              PAN

              		 Первичный номер счета ( Primary Account Number) для данной карты


              CardExpiry

              		 Дата пригодности карты


              CardSecret

              		 Предложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain.


              EXNonce

              		 Новый код (Nonce) для предотвращения атак на PANData0


              Таблица 4.6.2.28

              . Формат AcctData



              AcctData

              		 {AcctIdentification, EXNonce}


              AcctIdentification

              		 Для продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца)


              EXNonce

              		 Новый код Nonce для предотвращения атак на PANData0
              СА проверяет CertReq (EncX) следующим образом.

              Шаг Действие
              1 Получить CertReq из входного сообщения

            • Если RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail.


            • Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq.




              1. Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail.


              2. Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure.


              3. Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure.


                		4.
                2 Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования
                3 Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID.
                4 Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch.
                5 Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer.
                6 Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA.
                7 Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA.
                8 Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты.
                9 Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer.
                10 Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed.
                <


                /p> Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq.

                При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется.

                Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.

                Шаг Действие
                1 CertResData формируется как:

              4. Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReq


              5. Генерируется или копируется из CertReq (если имеется) LID-CA


              6. Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg)


              7. CertStatusCode устанавливается равным “Request Complete”


              8. Формируется Nonce-CCA


              9. Вычисляются и заносятся оттиски EE-сертификатов, CertThumbs.


              10. Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier.


                		11.
                2 Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке.

              11. Подписать данные посредством сертификата подписи СА


              12. Установить тип данных SignedData равным id-set-content-CertResData.


              13. Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData.


              14. Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq.


              15. Установить тип содержимого EncriptedData равным id-set-content-CertResTBE


                		16.
                3 Сформировать цифровой конверт и послать EE CertRes.
                <


                /p> Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage. Подписанное сообщение CertRes формируется следующим образом:

                Шаг Действие
                1 Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS.
                2 Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от “Request Complete”, создается CertResData:

              16. Копируется LID-EE и Chall-EE3 из CertReq


              17. Опционно заносится EEMessage


              18. Из табл. 4.6.2.30 заносится значение CertStatusCode


              19. Если CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме.


                		20.
                3 Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes
                Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29.



                Таблица 4.6.2.29.

                 Формат CertRes



                CertRes

                		 <S(CA, CertResData), EncK(CABackKeyData, CA, CertResData)>

                EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData


                CertResData

                		 {RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]}


                CABackKeyData

                		 Копируется из CertReq


                RRPID

                		 ID пары запрос/отклик


                LID-EE

                		 Копируется из CertReq


                Chall-EE3

                		 Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти.


                LID-CA

                		 Копируется из CertReq. Если в CertReq его нет, то присваивается новое значение.


                CertStatus

                		 {CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]}


                CertThumbs

                		 Если запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования


                BrandCRLIdentifier

                		 Смотри раздел об идентификаторах списков отмененных сертификатов платежной системы.


                Thumbs

                		 Копируется из CertReq.


                CertStatusCode

                		 Нумерованный код, указывающий на статус запроса сертификата


                Nonce-CCA

                		 Присутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА.


                EEMessage

                		 Сообщение на естественном языке, предназначенное для отображения в системе ЕЕ


                CAMsg

                		 {[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]}


                FailedItemSeq

                		 {FailedItem+}


                CardLogoURL

                		 URL – указатель на логотип эмитента карты


                BrandLogoURL

                		 URL - указатель на логотип платежной системы


                CardCurrancy

                		 Вид валюта, хранящейся на счете владельца карты


                CardholderMsg

                		 Сообщение на естественном языке владельца карты, которое должно быть отображенопрограммой


                FailedItem

                		 {ItemNumber, ItemReason}


                ItemNumber

                		 Указывает на позицию в списке полей регистрационной формы, интерпретация которой невозможна. Значение нуль указывает на поле AcctData


                ItemReason

                		 Причина неудачи. Текстовое поле на естественном языке.
                <


                /p>

                Таблица 4.6.2.30

                . Статусные коды для запросов сертификата

                Код Значение Источник
                requestComplete Запрос сертификата одобрен CA
                invalidLanguage В запросе указан неверный язык CA
                invalidBIN Запрос сертификата отклонен из-за некорректного BIN Эмитент или получатель
                sigValidationFail Запрос сертификата отклонен по причине некорректной подписи CA
                decryptionError Запрос сертификата отклонен из-за ошибки дешифрования CA
                requestInProgress Запрос сертификата обрабатывается СА, эмитент или получатель
                rejectedByIssuer Запрос сертификата отклонен эмитентом карты Эмитент
                requestPended Запрос сертификата ждет обработки СА, эмитент или получатель
                rejectedByAquirer Запрос сертификата отклонен банком продавца (получателем) Получатель
                regFormAnswerMalformed Запрос сертификата отклонен из-за неверной позиции в регистрационной форме. CA
                rejectedByCA Запрос сертификата отклонен центром сертификации CA
                unableToEncryptCertRes Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты CA
                Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:

                Шаг Действие
                1 Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier.
                2 Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.
                3 Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch.
                4 Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то:

              20. Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи.


              21. Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.


              22. В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency.


              23. Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate.


              24. В случае владельца карты выполняются следующие дополнительные действия:




                  1. Для того чтобы получить PANSecret, вычисляется (Nonce-CCAA

                    CardSecret)


                  2. Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата.
                  5 Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата.
                  6 Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq
                  7 Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage.
                  <


                  /p>

                  Информационные сертификатные запросы и обработка статуса



                  Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов).

                  Если CertStatusCode из CertRes равен “Certificate Request in Progress” или “Certificate Request Pending”. EE формирует CertInqReq для получения сертификата следующим образом:

                  Шаг Действие
                  1 Копируется LID-CA3 из CertRes в поле данных “CertInqReqTBS”
                  2 Генерируется новый RRPID
                  3 Генерируется новый LID-EE
                  4 Генерируется новый Chall-EE3
                  5 Копируется LID-CA из предыдущего CertRes
                  6 Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq.
                  7 Формируется цифровой конверт и посылается CertInqReq в центр СА.
                  Формат сообщения представлен в таблице ниже.



                  Таблица 4.6.2.31

                  . Формат CertInqReq

                  CertInqReq S(EE, CertInqReqTBS)
                  CertInqReqTBS {RRPID, LID-EE, Chall-EE3, LID-CA}
                  RRPID Идентификатор пары запрос/отклик
                  LID-EE Копируется из CertRes
                  Chall-EE3 Требование ЕЕ по поводу обновления подписи СА
                  LID-CA Копируется из CertRes
                  Центр СА обрабатывает CertInqReq следующим образом:

                  Шаг Действие
                  1 Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX)
                  2 Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID.
                  3 Используя LID-CA в качестве индекса, определяется статус CertReq.
                  4 Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode
                  <


                  /p> После обработки CertInqReq СА формирует CertInqRes. Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично.

                  Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32.



                  Таблица 4.6.2.32

                  . Поля формата сертификата Х.509

                  Имя Ограничения на формат и значения Описание
                  Version (Версия) Целое Указывает на версию сертификата
                  SerialNumber Целое Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат
                  Signature.AlgorithmIdentifier OID и тип Определяет алгоритм, используемый для генерации подписи сертификата
                  Issuer (эмитент) Имя Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат
                  Validity.notBefore Время UTC Специфицирует время, когда сертификат становится активным
                  Validity.notAfter Время UTC Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты.
                  Subject Имя Содержит уникальное имя объекта владельца ключа
                  SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier OID и тип Специфицирует алгоритм, который может использоваться с этим ключом.
                  SubjectPublicKeyInfo. subjectPublicKey Строка битов Содержит общедоступный ключ, представленный в запросе сертификата
                  IssuerUniqueID   В SET не используется
                  SubjectUniqueID   В SET не используется
                  Extensions.extnId Формат OID Содержит расширение OID, как это определено Х.509 или SET
                  Extensions.critical Булево: 0=ложно

                  1=истинно                  		 Каждое описание расширения определяет то, какое значение должно принимать это поле
                  Extensions.extnValue   Информация расширения
                  Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET:

                1. countryName [2 5 4 6]


                2. organizationName [2 5 4 10]


                3. organizationUnitName [2 5 4 11]


                4. commonName [2 5 4 3]




                  5. Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType).



                  OID имен (ASN.1)

                  id-at-

                  countryNameOBJECT IDENTIFIER ::= { id-at 6 }

                  id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }

                  id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }

                  id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 }



                  Владелец карты



                  countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>

                  organizationName=<BrandID> (идентификатор платежной системы)

                  organizationalUnitName=<Название финансового учреждения, выпустившее карту>

                  organizationalUnitName=<Опционно - название карты>

                  commonName=<Уникальный идентификатор владельца карты>

                  Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту.



                  Продавец



                  countryName=< Страна, где размещается банк продавца – Acquirer>

                  organizationName=<BrandID>

                  organizationalUnitName=<Название банка продавца>

                  commonName=<Имя продавца, как написано в заявлении владельца карты>

                  Расчетный центр


                  countryName=<Страна, где размещается банк продавца – Acquirer>

                  organizationName=<BrandID>

                  organizationalUnitName=<Название банка продавца>

                  commonName=<Уникальный идентификатор расчетного центра>

                  Центр сертификации владельца карты


                  countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>

                  organizationName=<BrandID>

                  organizationalUnitName=<Описательное имя>

                  commonName=<Опционный уникальный идентификатор>

                  Центр сертификации продавца


                  countryName=<Страна, где размещается банк продавца – Acquirer >

                  organizationName=<BrandID>

                  organizationalUnitName=<Описательное имя>

                  commonName=<Опционный уникальный идентификатор>

                  Центр сертификации расчетного центра




                  countryName=<Страна, где размещается банк продавца – Acquirer >

                  organizationName=<BrandID>

                  organizationalUnitName=<Описательное имя>

                  commonName=<Опционный уникальный идентификатор>

                  Геополитический центр сертификации


                  countryName=<Страна геополитической организации>

                  organizationName=<BrandID>

                  organizationalUnitName=<Описательное имя>

                  commonName=<Опционный уникальный идентификатор>

                  Центр сертификации платежной системы (Brand)


                  countryName=<Страна, где размещен центр сертификации платежной системы>

                  organizationName=<BrandID>

                  organizationalUnitName=<Описательное имя>

                  commonName=<Опционный уникальный идентификатор>

                  Корневой центр сертификации


                  countryName=<Страна, где размещен корневой центр сертификации – СА>

                  organizationName=<Корневой центр SET>

                  commonName=<Опционный – уникальный ID>

                  Поля имен в имени субъекта сертификата определены в таблице ниже:

                  Country 2 символа кода страны (ISO 3166)
                  BrandID <Brand Name>:<Product>, где название продукта является опционным.
                  Brand Name Платежная система карты, которая определяется разработчиками платежной системы.
                  Product Type Опционное поле, которое определяет тип продукта в рамках заданной платежной системы.
                  Описательное имя Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например:

                5. Название финансовой организации


                6. Название организации, выполняющей функцию СА


                7. Название платежной системы


                8. Имя объекта, ответственного за одобрение сертификатов


                  		9.
                  Официальное название карты Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д.
                  Название финансовой организации Имя финансовой организации, выпускающей расчетные карты
                  Уникальный идентификатор владельца карты Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета.
                  Уникальный идентификатор расчетного центра Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN.
                  <


                  /p> Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета. PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом:

                  Hash(KA

                  opad|hash((KAipad)|text)),

                  где A

                  - оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:

                  K Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA.
                  Text Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry.

                  Text ::= SEQUENCE {

                  pan PAN

                  cardExpiry CardExpiry

                  }

                  PAN ::= NumberString (SIZE(1..19))

                  CardExpiry ::= NumericString (SIZE(6)) --YYYMM

                  Время истечения действия карты
                  ipad 64 байта, содержащих код 0x36
                  opad 64 байта, содержащих код 0x5C


                  K

                   дополняется нулями до 64 байт.

                  Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName.



                  Профайлы сертификатов



                  В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET.



                  Таблица 4.6.2.33.

                   Типы сертификатов

                  Объект Цифровая подпись Шифрование_ключей/

                  шифрование_данных                  		 Подпись



                  keyCert

                  		 Подпись



                  CRL
                  Владелец карты

                  Х

                  		      
                  Продавец

                  Х

                  Х

                  		    
                  Расчетный центр

                  Х

                  Х

                  		    
                  Центр сертификации владельца карты

                  Х

                  Х

                  Х

                  		  
                  Центр сертификации продавца

                  Х

                  Х

                  Х

                  		  
                  Центр сертификации расчетного центра

                  Х

                  Х

                  Х

                  Х
                  Геополитический центр сертификации

                  Х

                  		  

                  Х

                  Х
                  Центр сертификации платежной системы    

                  Х

                  Х
                  Корневой центр сертификации    

                  Х

                  Х
                  <


                  /p> ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата.

                  Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать:

                9. привилегии keyCertSign и offLineCRLSign или


                10. keyEncipherment и dataEncipherment


                  11. В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ).



                  Таблица 4.6.2.34

                  . Обязательные расширения сертификата ЕЕ.

                   

                  Сертификат владельца карты

                  Сертификат продавца

                  Сертификат расчетного центра
                  Расширение Х.509

                  Подпись

                  Подпись

                  Шифрова-ние ключа

                  Подпись

                  Шифрова-ние ключа
                  AuthorityKeyIdentifier

                  Х

                  Х

                  Х

                  Х

                  Х
                  KeyUsage

                  Х

                  Х

                  Х

                  Х

                  Х
                  PrivateKeyUsagePeriod

                  Х

                  Х

                  		  

                  Х

                  		  
                  CertificatePolicies

                  Х

                  Х

                  Х

                  Х

                  Х
                  SubjectAltName

                  O

                  O

                  O

                  O

                  O
                  BasicConstraints

                  Х

                  Х

                  Х

                  Х

                  Х
                  IssuerAltName

                  O

                  O

                  O

                  O

                  O
                  Частное расширение
                  HashedRootKey          
                  CertificateType

                  Х

                  Х

                  Х

                  Х

                  Х
                  MerchantData  

                  Х

                  Х

                  		    
                  CardCertRequired        

                  Х
                  Tunneling        

                  Х
                  SETExtensions        

                  Х


                  Х – обязательный

                  O - опционный

                  Таблица 4.6.2.35

                  . Обязательные расширения сертификатов СА

                    СА Корневой центр сертификации
                  Расширение Х.509 Цифровая

                  подпись                  		 Подпись

                  серти-фиката                  		 Шифрова-ние ключа Подпись

                  CRL                  		 Подпись сертификата & CRL
                  AuthorityKeyIdentifier

                  Х

                  Х

                  Х

                  Х

                  Х
                  KeyUsage

                  Х

                  Х

                  Х

                  Х

                  Х
                  PrivateKeyUsagePeriod

                  Х

                  Х

                  		  

                  Х

                  		  
                  CertificatePolicies

                  Х

                  Х

                  Х

                  Х

                  Х
                  SubjectAltName

                  O

                  O

                  O

                  O

                  O
                  BasicConstraints

                  Х

                  Х

                  Х

                  Х

                  Х
                  IssuerAltName

                  O

                  O

                  O

                  O

                  O
                  Частное расширение
                  HashedRootKey        

                  Х
                  CertificateType

                  Х

                  Х

                  Х

                  Х

                  Х
                  MerchantData          
                  CardCertRequired          
                  Tunneling    

                  Х

                  		    
                  SETExtensions          
                  <


                  /p> Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:

                11. Номер CRL. Номера монотонно возрастают.


                12. Список серийных номеров устаревших сертификатов.


                13. Даты, когда конкретные сертификаты были признаны устаревшими.


                14. Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).


                15. Уникальное имя СА, который поддерживает данный CRL.


                16. Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL.


                  17. В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509).



                  Таблица 4.6.2.36

                  . Формат полей CRL и ограничения для их значений

                  Имя поля Формат и ограничения на значение Описание
                  CRL.version (версия) Целое; V2 Определяет версию CRL. В настоящее время =2.
                  CRL.signature

                  .algorithmIdentifier                  		 OID и тип Определяет алгоритм, использованный для подписи CRL
                  CRL.Issuer Имя Содержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА
                  CRL.thisUpdate Время UTC Определяет время, когда был сформирован CRL
                  CRL.nextUpdate Время UTC Определяет время, когда CRL устареет
                  CRL.revokedCertificate

                  .certSerialNumber                  		 Целое Номер по порядку устаревшего сертификата
                  CRL. RevokedCertificate

                  .revocationDate                  		 Время UTC Дата признания сертификата устаревшим
                  CRL. RevokedCertificate

                  .extensions                  		 Расширения Не используется в SET
                  CRL.extensions Расширения В этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier
                  <


                  /p> Следующие СA должны поддерживать CRL в рамках SET:

                17. корневой СА – для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.


                18. СА платежных систем – для поддержки незапланированной замены или прекращения действия сертификата, выданного центром сертификации платежной системы.


                19. геополитические СА – для поддержки незапланированной замены сертификатов CCA, MCA или PCA.


                20. CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра.


                  21. Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL.

                  При получении нового CRL должны проводиться следующие проверки:

                  1. Сначала проверяется подпись:



                    • Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.


                    • Расширение KeyUsage в сертификате подписи указывает на CRLsign(6)


                    2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.

                    3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом

                    Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:



                        1. IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRL


                        2. certSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL.


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



                        BrandCRLIdentifier



                        BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы. BrandCRLIdentifier содержит в себе следующую информацию:

                      1. Номер BCI (увеличивается для каждого нового BCI)


                      2. Название платежной системы


                      3. Время пригодности BCI


                      4. Список номеров CRL (из расширения номера CRL)


                      5. Эмитент и серийный номер сертификата СА платежной системы, который используется для подписи BCI (включается в расширение)




                        6. Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов.



                        Запросы и отклики сертификатов



                        Запрос сертификата посылается клиентом вышестоящему центру сертификации (СА). Последний формирует сертификат и отсылает его отправителю запроса в подписанном сообщении отклике. Различные объекты ответственны за подпись разных сертификатов, как это показано ниже.

                        Сертификат для: Формируется и подписывается:
                        СА платежной системы Корневой СА
                        Геополитический СА СА платежной системы
                        ССА, МСА или РСА Геополитический СА, если таковой имеется, в противном случае СА платежной системы
                        Сообщения запросы от СA форматируются согласно CertificationRequest, специфицированному в PKCS#4 версии 1.0. CertificationRequest содержит общедоступный ключ, DN субъекта и атрибуты, которые должен сертифицировать подписывающий СА.

                        Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest.



                        Таблица 4.6.2.37

                        . Атрибуты CertificationRequest

                          ССА, МСА или РСА Геополитический центр сертификации или СА платежной системы
                        Атрибут SET Сертификат подписи Подпись CRL Сертификат и подпись CRL
                        KeyUsage

                        X

                        X

                        X

                        X

                        X
                        PrivateKeyUsagePeriod

                        X

                        X

                        		  

                        X

                        X
                        AdditionalPolicy

                        O

                        O

                        O

                        O

                        O
                        SubjectAltName

                        O

                        O

                        O

                        O

                        O
                        CertificateType

                        X

                        X

                        X

                        X

                        X
                        Tunneling    

                        X

                        		    


                        Х –

                        обязательный

                        O - опционный

                        При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:

                        Шаг Действие
                        1 Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest
                        2 Используя общедоступный ключ, присланный в запросе, проверить подпись
                        3 Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name
                        4 Используя тип сертификата и атрибуты использования ключа, проверить, что имеются необходимые атрибуты (см. таблицу 4.6.2.37)
                        5 Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА.
                        6 Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован.
                        7 Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData.
                        8 SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET.
                        <


                        /p>

                        Рассылка CRL



                        CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.

                        Шаг Действие
                        1 Сформировать CRLNotificationTBS:

                        • Занести в поле данные текущую дату


                        • Занести в CRLThumbprint оттиск, несущий в себе CRL
                        2 Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS
                        3 Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения.
                        4 Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME.
                        CRL-Notification-сообщение содержит следующие поля:

                        Название поля Описание
                        CRL-Notification

                        S(CA, CRLNotificationTBS)
                        CRL-NotificationTBS

                        {Date, CRLThumbprint}
                        Дата Дата, когда сформировано сообщение
                        CRLThumbprint Оттиск CRL, заключенный в CRL-секцию SignedData
                        При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:

                        Шаг Действие
                        1 Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate.
                        2 Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch.
                        3 Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI.
                        CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:

                        Шаг Действие
                        1 Заполнить NotificationResTBS:

                        • Вставить дату из сообщения CRLNotification


                        • Вставить оттиск полученного CRL
                        2 Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype

                        равным id-set-content-CRLNotificationResTBS
                        3 Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА.
                        <


                        /p> Сообщение-отклик CRLNotification содержит следующие поля.

                        Название поля Описание
                        CRL-NotificationRes

                        S(CA, CRLNotificationTBS)
                        CRL-NotificationResTBS

                        {Date, CRLThumbprint}
                        Дата Копируется из сообщения CRLNotification
                        CRLThumbprint Оттиск CRL, копируется из сообщения CRLNotification
                        При получении отклика CRLNotification СА проверяет то, что дата и оттиск соответствуют значениям из запроса. Если соответствия нет, посылается сообщение об ошибке, а запрос CRLNotification посылается повторно.



                        Получение BCI



                        BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА.

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

                        Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution

                        не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.

                        Шаг Действие
                        1 Заполнить BCIDistributionTBS:

                        • Ввести текущую дату


                        • Включить последнюю версию BCI
                        2 Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL.
                        3 Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом.
                        <


                        /p> Сообщение BCI Distribution содержит в себе следующие поля:

                        Название поля Описание


                        BCIDistribution

                        S(CA, BCIDistributionTBS)


                        BCIDistributionResTBS

                        {Date, BCIDistribution}


                        Дата

                        		 Дата формирования сообщения


                        BrandCRLIdentifier

                        		 Список текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы.
                        Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:

                        Шаг Действие
                        1 Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы.
                        2 Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить.
                        3 Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается.
                        4 Запомнить все CRL и BrandCRLIdentifier для последующей рассылки


                        Структуры данных



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



                        TransID



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



                        TransID

                        {LID-C, [LID-M], XID, PReqData, [PaySysID], Language}


                        LID-C

                        		 Локальный ID. Метка, генерируемая системой владельца карты или для нее.


                        LID-M

                        		 Локальный ID. Метка, генерируемая системой продавца или для нее.


                        XID

                        		 Глобально уникальный идентификатор


                        PReqData

                        		 Дата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq.


                        PaySysID

                        		 Используется некоторыми платежными системами для пометки транзакций


                        Language

                        		 Естественный язык владельца карты
                        <


                        /p> TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты. XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET.



                        Таблица 4.6.2.38

                        . Условия формирования и использование поля TransID

                        Сообщение LID-C LID-M XID PaySysID
                        PInitReq R C1 N/P N/P
                        PInitRes ?

                        		 ?

                        (C2)                        		 R N/P
                        PReq ?

                        		 ?

                        		 ?

                        (R3)                        		 N/P
                        PRes ?

                        		 ?

                        (C2)                        		 ?

                        		 C4
                        InqReq ?

                        		 ?

                        		 ?

                        		 C5
                        InqRes ?

                        		 ?

                        		 ?

                        		 C4
                        AuthReq ?

                        		 ?

                        		 ?

                        		 N/P
                        AuthRes ?

                        		 ?

                        		 ?

                        		 C6
                        AuthRevReq ?

                        		 ?

                        		 ?

                        		 C
                        AuthRevRes ?

                        		 ?

                        		 ?

                        		 ?
                        CapReq I I I I
                        CapRes I I I I
                        CapRevReq I I I I
                        CapRevRes I I I I
                        CredReq I I I I
                        CredRes I I I I
                        CredRevReq I I I I
                        CredRevRes I I I I
                        PCertReq N/P C N/P N/P
                        PCertRes N/P ?

                        		 N/P N/P
                        BatchAdminReq I I I I
                        BatchAdminRes I I I I
                        CardCInitReq R N/P N/P N/P
                        CardCInitRes ?

                        		 N/P N/P N/P
                        Me-AdCInitReq N/P C N/P N/P
                        Me-AdCInitRes N/P ?

                        		 N/P N/P
                        RegFormReq ?

                        		 ?

                        		 N/P N/P
                        RegFormRes ?

                        		 ?

                        		 N/P N/P
                        CertReq ?

                        		 ?

                        		 N/P N/P
                        CertRes ?

                        		 ?

                        		 N/P N/P
                        CertInqReq ?

                        		 ?

                        		 N/P N/P
                        CertInqRes ?

                        		 ?

                        		 N/P N/P
                        R Поле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт.
                        C Наличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения.
                        N/P (Not Present) Отсутствует как в сообщении так и в цифровом конверте.
                        ?

                        		 Копируется из запроса или предыдущего сообщения, дублируется в цифровом конверте
                        I Может присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте.
                        <


                        /p> Примечания:



                              1. Копируется из процесса инициализации SET (если имеется)


                              2. Если для данной транзакции нет предшествующего LID-M, продавец может сформировать его для данного сообщения.


                              3. Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.


                              4. Если послано после получения AuthRes с PaySysID


                              5. Если послано после получения PRes с PaySysID


                              6. Может быть сформировано расчетным центром для данного сообщения.


                              Алгоритм формирования TransID представлен ниже:

                              Шаг Действие
                              1 Если сообщение для данной транзакции получено раньше, следует запомнить все его поля.
                              2 Если это новая транзакция, сформировать все необходимые поля (см таблицу выше)
                              3 Заполнить любые опционные поля, которые могут быть сформированы данным объектом.
                              Обработка TransID зависит от типа сообщения.



                              Платежная инструкция



                              Платежная инструкция (PI) является одной из важнейших информационных структур SET. Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца – Acquirer). Эта информация не может быть прочитана продавцом.

                              Имеется три разновидности PI. Первые два формируются владельцем карты, третье – расчетным центром.



                              PIUnsigned

                              		 Формируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned.

                              Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится.


                              PIDualSigned

                              		 Формируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных.


                              AuthToken

                              		 Формируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq.

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


                              /p> Платежная инструкция имеет структуру представленную в таблице 4.6.2.39.



                              Таблица 4.6.2.39

                              . Структура PI



                              PI

                              <PIUnsigned, PIDualSigned, AuthToken>

                              Владелец карты создает PIUnsigned или PIDualSigned инструкцию.

                              Расчетный центр формирует AuthToken для поддержки поставки по частям и последовательных платежей. Продавец запишет PI для последующего вложения в AuthReq.


                              PIUnsigned

                              EXH(P, PI-OILink, PANToken

                              )} (См. табл. 4.6.2.46)


                              PIDualSigned

                              {PISignature, EX(P, PI-OILink, PANData)}

                              (См. табл. 4.6.2.45)


                              AuthToken

                              		 См. табл. 4.6.2.42


                              PI-OILink

                              L(PIHead, OIData)

                               (см. табл. 4.6.2.40)


                              PISignature

                              SO(C, PI-TBS)


                              PI-TBS

                              {HPIData, HOIData}


                              HPIData

                              DD(PIData)


                              HOIData

                              DD(OIData)


                              PIData

                              {PIHead, PANData}

                              (см. табл. 4.6.2.40 и 4.6.2.45)


                              Таблица 4.6.2.40

                              . Структура PIHead



                              PIHead

                              {TransIDs, Inputs, MerchantID, [InstallRecurData], TransStain, SWIdent, [AcqBackKeyData], [PIExtensions]}


                              TransIDs

                              		 См. выше описание TransIDs


                              Inputs

                              {HOD, PurchAmt}


                              MerchantID

                              		 Копируется из сертификата подписи продавца


                              InstallRecurData

                              		 См. табл. 4.6.2.41


                              TransStain

                              HMAC(XID, CardSecret)


                              SWIdent

                              		 Строка, идентифицирующая программное обеспечение (разработчик и версия), инициирующее запрос. Оно специфицируется в PI, чтобы расчетный центр знал программное обеспечение владельца карты.


                              AcqBackKeyData

                              {AcqBackAlg, AcqBackKey}


                              PIExtensions

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



                              Таблица 4.6.2.41

                              . Структура InstallRecurData



                              InstallRecurData

                              {InstallRecurDInd, [IRExtensions]}


                              InstallRecurDInd

                              < InstallTotalTrans, Recurring >


                              IRExtensions

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


                              InstallTotalTrans

                              		 Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей


                              Recurring

                              		 {RecurringFrequency, RecurringExpiry}


                              RecurringFrequency

                              		 Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями)


                              RecurringExpiry

                              		 Окончательная дата, после которой никакие авторизации не разрешены
                              <


                              /p> Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту.

                              AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42.



                              Таблица 4.6.2.42

                              . Структура AuthToken



                              AuthTokenData

                              {TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque}


                              PANToken

                              		 Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40)


                              TransIDs


                              PurchAmt


                              MerchantID


                              AcqBackKeyData


                              InstallRecurData


                              RecurringCount

                              		 Число реализованных рекуррентных авторизаций


                              PrevAuthDateTime

                              		 Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций


                              TotalAuthAmount

                              		 Полное число авторизованных в результате всех авторизаций для данного XID


                              AuthTokenOpaque

                              		 Невидимые данные, генерируемые расчетным центром
                              AuthToken формируется следующим образом:

                              Шаг Действие
                              1 Генерируется AuthTokenTBE как:

                              Если это первая авторизация (выполнена согласно PI)

                              а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData

                              б. RecurringCount делается равным 1

                              в. В PrevAuthDateTime записывается текущая дата

                              г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthToken

                              Если это очередная аутентификация (сгенерирована из предыдущего AuthToken)

                              а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData

                              б. Инкрементируется на 1 RecurringCount

                              в. В PrevAuthDateTime записывается текущая дата

                              г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthToken

                              Если это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken)

                              а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData

                              б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1

                              в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken.
                              2 Сформировать PANToken (см. табл. 4.6.2.46)
                              3 С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p.
                              <


                              /p> Обработка AuthToken выполняется в следующем порядке:

                              Шаг Действие
                              1 Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра.
                              2 Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed
                              3 Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch.
                              4 Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией:



                                  1. Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired.


                                  2. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon.
                                  5 Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты.
                                  6 Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу.
                                  AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43.



                                  Таблица 4.6.2.43

                                  . Структура AcqCardMsg



                                  AcqCardMsg

                                  EncK(AcqBackKeyData, P,

                                   AcqCardCodeMsg)

                                  AcqBackKeyData                                   предоставляется владельцем карты в PI.


                                  Зашифрованное сообщение адресуется владельцу карты.


                                  AcqBackKeyData

                                  		 Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40)


                                  AcqCardCodeMsg

                                  {AcqCardCode, AcqCardMsgData}


                                  AcqCardCode

                                  		 Числовой код


                                  AcqCardMsgData

                                  {[AcqCardText], [AcqCardURL], [AcqCardPhone]}


                                  AcqCardText

                                  		 Текстовое сообщение, отображаемое владельцу карты


                                  AcqCardURL

                                  		 URL HTML-сообщения, отображаемого владельцу карты


                                  AcqCardPhone

                                  		 Телефонный номер, предоставляемый владельцу карты
                                  <


                                  /p> Для AcqCardCode определены следующие значения:

                                  messageOfDay Банк продавца хочет, чтобы это сообщение было передано всем
                                  accountInfo Информация о счете должна быть передана назад пользователю
                                  сallCustomerService Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов


                                  CapToken

                                   предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44.



                                  Таблица 4.6.2.44

                                  . Структура CapToken



                                  CapToken

                                  <Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}>

                                  P1

                                  и P2 обозначают платежные центры:

                                1. P1
                                  2.  – отправителя

                                2. P2
                                  3.  - получателя

                                  В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2)


                                  CapTokenData

                                  {AuthRRPID, AuthAmt, TokenOpaque}


                                  PANToken

                                  		 Смотри табл. 4.6.2.46


                                  AuthRRPID

                                  		 RRPID, который появляется в соответствующем AuthReq или AuthRevReq


                                  AuthAmt

                                  		 Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты


                                  TokenOpaque

                                  		 Невидимые данные, определенные расчетным центром
                                  Алгоритм формирования CapToken показан ниже:

                                  Шаг Действие
                                  1 Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes
                                  2 Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов
                                  3 Если продавец получает PANToken из своего банка, тогда:

                                3. Занести PANToken из PI


                                4. Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секции


                                  5. В противном случае:

                                5. Использовать Enc инкапсуляцию с CapTokenData


                                  		6.
                                  Обработка CapToken производится следующим образом:

                                  Шаг Действие
                                  1 Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc.
                                  2 Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest.
                                  3 Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound
                                  4 Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest.
                                  5 Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса.
                                  <


                                  /p> PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45.



                                  Таблица 4.6.2.45.

                                  Структура PANData



                                  PANData

                                  {PAN, CardExpiry, PANSecret, EXNonce}


                                  PAN

                                  		 Первичный номер счета, обычно номер счета карты


                                  CardExpiry

                                  		 Дата действительности карты


                                  PANSecrit

                                  		 Секретный код, используемый совместно владельцем карты, расчетным центром и сертификационным центром владельца карты. Предотвращает атаки на PAN в сертификате владельца карты.


                                  EXNonce

                                  		 Новый код (Nonce), который препятствует атаке на PANData
                                  Формирование PANData осуществляется согласно алгоритму, рассмотренному ниже.

                                  Шаг Действие
                                  1 Занести в PAN номер счета владельца карты
                                  2 Записать в CardExpiry дату действительности карты
                                  3 Занести PANSecret, который был получен от СА вместе с сертификатом владельца карты. Для владельца карты без сертификата все октеты этого поля устанавливаются равными нулю.
                                  4 Сформировать новое значение EXNonce
                                  PANToken подобно PANData содержит информацию, идентифицирующую определенную платежную карту. PANToken используется, когда для сокрытия данных PANSecret не нужен. Структура PANToken показана в таблице 4.6.2.46.



                                  Таблица 4.6.2.46.

                                   Структура PANToken



                                  PANToken

                                  {PAN, CardExpiry, EXNonce}


                                  PAN

                                  		 Первичный номер счета, обычно номер счета карты


                                  CardExpiry

                                  		 Дата действительности карты


                                  EXNonce

                                  		 Новый код (Nonce), который препятствует атаке на PANData
                                  Формирование PANToken осуществляется достаточно просто:

                                  Шаг Действие
                                  1 Занести в PAN номер счета владельца карты
                                  2 Записать в CardExpiry дату действительности карты
                                  3 Сформировать новое значение EXNonce.


                                  Структура SaleDetail



                                  SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47.



                                  Таблица 4.6.2.47. Структура SaleDetail



                                  SaleDetail

                                  		 {[BatchID],[BatchSequenceNum], [PayRecurInd], [MerOrderNum], [AuthCharInd], [MarketSpecSaleData], [CommercialCardData], [OrderSummery], [CustomerReferenceNumber], [CustomerServicePhone], OktoPrintPhoneInd, [SaleExtensions]}

                                  Это поле может появляться в AuthReq с флагом CaptureNow установленным равным TRUE или в сообщениях, связанных с платежным запросом.


                                  BatchID

                                  		 Идентификация последовательности операций в системе продавец и его банк


                                  BatchSequenceNum

                                  		 Порядковый номер позиции в данной последовательности расчетных операций.


                                  PayRecurInd

                                  		 Номер типа транзакции


                                  MerOrderNum

                                  		 Номер заказа продавца


                                  AuthCharInd

                                  		 Копируется из AuthResPayload


                                  MarketSpecSaleData

                                  {[MarketSpecDataID], [MarketSpecCapData]}


                                  CommercialCardData

                                  		 Описание позиции в платежном запросе (см. табл. 4.6.2.48)


                                  OrderSummary

                                  		 Краткое описание заказа


                                  CustomerReferenceNumber

                                  		 Номер ссылки, присвоенный заказу владельца карты


                                  CustomerServicePhone

                                  		 Номер телефона службы обслуживания клиентов данного продавца


                                  OKtoPrintPhoneInd

                                  		 Булево число, указывающее, может ли эмитент выдавать телефон службы сервиса в ответ на запрос владельца карты.


                                  SaleExtensions

                                  		 Данные этого расширения должны быть финансовыми и важными для обработки платежного запроса расчетного центра или эмитента


                                  MarketSpecDataID

                                  		 Копируется из AuthResPayload


                                  MarketSpecCapData

                                  <MarketAutoCap, MarketHotelCap, MarketTransportCap>


                                  MarketAutoCap

                                  		 Описание оплаты проката автомобиля (см. табл. 4.6.2.49)


                                  MarketHotelCap

                                  		 Описание оплаты гостиницы (см. табл. 4.6.2.50)


                                  MarketTransportCap

                                  		 Данные о пассажире (см. табл. 4.6.2.51)
                                  PayRecurInd может принимать следующие значения:

                                  unknown Тип транзакции неизвестен
                                  singleTransaction Транзакция состоит из одной авторизации и платежного запроса
                                  recurringTransaction Транзакция состоит из нескольких авторизаций и платежных запросов, которые повторяются регулярно
                                  installmentPayment Транзакция состоит из нескольких авторизаций и заказов-резервирований, которые выполняются фиксированное число раз
                                  otherMailOrder Прочие транзакции заказов по почте
                                  <


                                  /p> Структура коммерческих данных карты представлена в таблице 4.6.2.48.



                                  Таблица 4.6.2.48

                                  . Структура коммерческих данных карты



                                  CommercialCardData

                                  {[ChargeInfo], [MerchantLocation], [ShipFrom], [ShipTo], [ItemSeq]}


                                  ChargeInfo

                                  {[TotalFreightShippingAmount], [TotalDutyTariffAmount], [DutyTariffReference], [TotalNationalTaxAmount], [TotalLocalTaxAmount], [TotalOtherTaxAmount], [TotalTaxAmount], [MerchantTaxID], [MerchantDutyTariffRef], [CustomerDutyTariffRef], [SummaryCommodityCode], [MerchantType]}


                                  MerchantLocation

                                  		 Местоположение продавца


                                  ShipFrom

                                  		 Адрес отправки


                                  ShipTo

                                  		 Адрес получателя


                                  ItemSeq

                                  {Item +}

                                  Номера от 1 до 999


                                  TotalFreightShippingAmount

                                  		 Общее количество позиций, подлежащих обработке и доставке


                                  TotalDutyTariffAmount

                                  		 Полная сумма налога или тариф для заказа


                                  DutyTariffReference

                                  		 Код ссылки, приписанный налогу или тарифу для данного заказа


                                  TotalNationalTaxAmount

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


                                  TotalLocalTaxAmount

                                  		 Размер местного налога, распространяющегося на данный заказ


                                  TotalOtherTaxAmount

                                  		 Прочие налоги, действующие для данного заказа


                                  TotalTaxAmount

                                  		 Полный размер налога для данного заказа


                                  MerchantTaxID

                                  		 Индивидуальный идентификационный номер продавца


                                  MerchantDutyTariffRef

                                  		 Код налога или тарифа, приписанный продавцу


                                  CustomerDutyTariffRef

                                  		 Код налога или тарифа, приписанный владельцу карты


                                  SummaryCommodityCode

                                  		 Код товара, приложимый ко всему заказу


                                  MerchantType

                                  		 Тип продавца


                                  Item

                                  {Quantity, [UnitOfMeasureCode], Descriptor, [CommodityCode], [ProductCode], [UnitCost], [NetCost], DiscountInd, [DiscountInd], [NationalTaxAmount], [NationalTaxAmount], [NationalTaxRate], [NationalTaxType], [LocalTaxAmount], [LocalTaxAmount], ItemTotalCost}


                                  Quantity

                                  		 Количество предметов или услуг данного типа


                                  UnitOfMeasureCode

                                  		 Единицы измерения для данной позиции в заказе


                                  Descriptor

                                  		 Описание позиции в заказе


                                  CommodityCode

                                  		 Код вида товара для данной позиции заказа


                                  ProductCode

                                  		 Код продукта для данной позиции заказа


                                  UnitCost

                                  		 Цена единицы товара


                                  NetCost

                                  		 Чистая цена единицы товара


                                  DiscountInd

                                  		 Указывает, распространяется ли скидка на данную позицию в заказе


                                  DiscountAmount

                                  		 Величина скидки для данной позиции заказа


                                  NationalTaxAmount

                                  		 Величина национального налога, применимого к данной позиции заказа


                                  NationalTaxRate

                                  		 Национальный налог (с продаж или на добавленную стоимость), применимый к данной позиции заказа


                                  NationalTaxType

                                  		 Ставка национального налога, действующая для данной позиции заказа


                                  LocalTaxAmount

                                  		 Величина местного налога, действующая для данной позиции заказа


                                  OtherTaxAmount

                                  		 Величина прочих налогов


                                  ItemTotalCost

                                  		 Полная цена данной строки заказа
                                  <


                                  /p> Структура данных MarketAutoCap представлена в таблице 4.6.2.49.



                                  Таблица 4.6.2.49

                                  . Структура MarketAutoCap



                                  MarketAutoCap

                                  {[RenterName], [RentalLocation], RentalDateTime, [AutoNoShow], [RentalAgreementNumber], [ReferenceNumber], [InsuranceType], [InsuranceType], [ReturnLocation], ReturnDateTime, AutoCharges}


                                  RenterName

                                  		 Имя лица, сдающего авто в аренду


                                  RentalLocation

                                  		 Адрес фирмы сдающей авто в аренду


                                  RentalDateTime

                                  		 Дата (опционно время), когда авто было взято в аренду


                                  AutoNoShow

                                  		 Числовой код, указывающий, что клиент не предъявил во время арендованную машину


                                  RentalAgreementNumber

                                  		 Номер арендного соглашения


                                  ReferenceNumber

                                  		 Код аренды


                                  InsuranceType

                                  		 Тип страховки, выбранный арендатором


                                  AutoRateInfo

                                  		 {AutoApplicableRate, [LateReturnHourlyRate], [LateReturnHourlyRate], [FreeDistance], [VehicleClassCode], [CirporateID]}


                                  ReturnLocation

                                  		 Адрес фирмы, куда следует вернуть авто (см. табл. 4.6.2.51)


                                  ReturnDateTime

                                  		 Дата (опционно время) возвращения автомобиля


                                  AutoCharges

                                  		 {RegularDistanceCharges, [LateReturnCharges], [TotalDistance], [ExtraDistanceCharges], [InsuranceCharges], [FuelCharges], [AutoTowingCharges], [OneWayDropOffCharges], [TelephoneCharges], [ViolationsCharges], [DelivaryCharges], [ParkingCharges], [OtherCharges], [TotalTaxAmount], [AuditAdjustment]}


                                  AutoApplicableRate

                                  <DailyRentalRate, WeeklyRentalRate>


                                  LateReturnHourlyRate

                                  		 Почасовая плата за опоздание возврата


                                  DistanceRate

                                  		 Помильная оплата за превышение допустимого пробега


                                  FreeDistance

                                  		 Расстояние, которое может пройти машина в день, без увеличения арендной платы.


                                  VehicleClassCode

                                  		 Класс арендуемого автомобиля


                                  CorporateID

                                  		 Корпоративный идентификационный номер, который применяется для определения арендной платы


                                  RegularDistanceCharges

                                  		 Сумма расходов за аренду (исключая расходы, перечисленные ниже)


                                  LateReturnCharges

                                  		 Сумма выплаты за возвращения автомобиля после оговоренного срока.


                                  TotalDistance

                                  		 Полный пробег автомобиля.


                                  ExtraDistanceCharges

                                  		 Сумма оплаты избыточного пробега (сверх оговоренного в договоре)


                                  InsuranceCharges

                                  		 Сумма страховки


                                  FuelCharges

                                  		 Оплата горючего


                                  AutoTowingCharges

                                  		 Оплата буксировки


                                  OneWayDropOffCharges

                                  		 Оплата одностороннего разрыва арендного договора


                                  TelephoneCharges

                                  		 Расходы использования телефона в арендованной машине


                                  ViolationsCharges

                                  		 Сумма штрафов за нарушения за время аренды автомобиля


                                  DelivaryCharges

                                  		 Оплата доставки арендованного автомобиля


                                  ParkingCharges

                                  		 Оплата парковки арендованного автомобиля


                                  OtherCharges

                                  		 Оплата расходов, не определенных в других позициях


                                  TotalTaxAmount

                                  		 Сумма налогов, связанная с арендой автомобиля


                                  AuditAdjustment

                                  		 Сумма изменения объема транзакции в результате аудита в компании, предоставляющей автомобили в аренду.


                                  DailyRentalRate

                                  		 Дневная арендная плата


                                  WeeklyRentalRate

                                  		 Арендная плата за неделю
                                  <


                                  /p> Структура данных MarketHotelCap представлена в таблице 4.6.2.50.



                                  Таблица 4.6.2.50

                                  . Структура MarketHotelCap



                                  MarketHotelCap

                                  {[ArriveDate], [RentalLocation], DepartureDate, [DurationOfStay], [FolioNumber], [PropertyPhone], [CustomerServicePhone], [ProgramCode], [HotelRateInfo], HotelCharges}


                                  ArriveDate

                                  		 Дата регистрации владельца карты в отеле


                                  HotelNoShow

                                  		 Цифровой код, указывающий, что клиент не был зарегистрирован в этом отеле своевременно


                                  DepartureDate

                                  		 Дата отбытия владельца карты из отеля


                                  DurationOfStay

                                  		 Число дней пребывания владельца карты в отеле


                                  FolioNumber

                                  		 Номер книги


                                  PropertyPhone

                                  		 Номер телефона отеля


                                  CustomerServicePhone

                                  		 Номер телефона системы обслуживания клиентов отеля или сети отелей


                                  ProgramCode

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


                                  HotelRateInfo

                                  {DailyRoomRate, [DailyTaxRate]}


                                  HotelCharges

                                  		 {RoomCharges, [RoomTax], [PrepaidExpenses], [FoodBeverageCharges], [RoomServiceCharges], [MiniBarCharges], [LaundryCharges], [TelephoneCharges], [BusinessCenterCharges], [ParkingCharges], [MovieCharges], [HealthClubCharges], [GiftShopCharges], [FolioCashAdvances], [OtherCharges], [TotalTaxAmount ], [AuditAdjustment]}


                                  DailyRoomRate

                                  		 Стоимость проживания в день. В эту сумму входят налоги, если не специфицирована переменная DailyTaxRate.


                                  DailyTaxRate

                                  		 Размер налога за проживание одного дня в гостинице


                                  RoomCharges

                                  		 Полная стоимость проживания в номере с учетом дополнительных расходов, перечисленных ниже


                                  RoomTax

                                  		 Налог, взымаемый с суммы RoomCharges


                                  PrepaidExpenses

                                  		 Полный размер предоплаты


                                  FoodBeverageCharges

                                  		 Оплата еды и напитков


                                  RoomServiceCharges

                                  		 Оплата обслуживания номера


                                  MiniBarCharges

                                  		 Оплата пользования минибаром


                                  LaundryCharges

                                  		 Оплата услуг прачечной


                                  TelephoneCharges

                                  		 Плата за пользование телефоном


                                  BusinessCenterCharges

                                  		 Оплата за услуги бизнес-центра


                                  ParkingCharges

                                  		 Оплата парковки


                                  MovieCharges

                                  		 Оплата за просмотр фильмов в номере


                                  HealthClubCharges

                                  		 Оплата услуг оздоровительного клуба


                                  GiftShopCharges

                                  		 Оплата покупок в сувенирном магазине


                                  FolioCashAdvances

                                  		 Сумма, предварительно внесенная за номер


                                  OtherCharges

                                  		 Другие расходы


                                  TotalTaxAmount

                                  		 Сумма налогов, включенная в счет


                                  AuditAdjustment

                                  		 Изменение платежа в результате перепроверки расчетов в отеле
                                  <


                                  /p> Структура данных MarketTransportCap представлена в таблице 4.6.2.51.



                                  Таблица 4.6.2.51

                                  . Структура MarketTransportCap



                                  MarketTransportCap

                                  {PassangerName, DepartureDate, OrigCityAirport, [TripLegSeq], [TicketNumber], [TravelAgencyCode], [TravelAgencyName], [Restrictions]}



                                  PassangerName

                                  		 Имя пассажира, кому выдается билет


                                  DepartureDate

                                  		 Дата отбытия


                                  OrigCityAirport

                                  		 Город начала путешествия


                                  TripLegSeq

                                  {TripLeg +}

                                  от одной до 10 TripLeg-записей


                                  TicketNumber

                                  		 Номер билета


                                  TravelAgencyCode

                                  		 Код турагенства


                                  TravelAgencyName

                                  		 Название турагенства


                                  Restrictions

                                  		 Численный код, указывающий на ограничения выплат и расходов


                                  TripLeg

                                  {DateOfTravel, CarrierCode, ServiceClass, StopOverCode, DestCityAirport, [FareBasisCode], [DepartureTax]}


                                  DateOfTravel

                                  		 Дата путешествия


                                  CarrierCode

                                  		 Код перевозчика данного тура


                                  ServiceClass

                                  		 Класс услуг тура


                                  StopOverCode

                                  		 Числовой код, указывающий на допустимость остановок в пути при совершении тура


                                  DestCityAirport

                                  		 Аэропорт места назначения тура


                                  FareBasisCode

                                  		 Код базовой цены тура


                                  DepartureTax

                                  		 Налог при отбытии для данного тура
                                  Структура данных, указывающих место (Location), представлена в таблице ниже.



                                  Location

                                  {CountryCode, [City], [StateProvince], [PostalCode], [LocationID]}


                                  CountryCode

                                  		 Код страны ISO 3166


                                  City

                                  		 Название города


                                  StateProvince

                                  		 Название или аббревиатура штата или провинции


                                  PostalCode

                                  		 Почтовый код


                                  LocationID

                                  		 Идентификатор, который использует продавец, чтобы специфицировать один из своих адресов
                                  Структура данных RRTags представлена в таблице 4.6.2.52.



                                  Таблица 4.6.2.52

                                  . Структура RRTags



                                  RRTags

                                  { RRPID, MerTermIDs, Date}


                                  RRPID

                                  		 Новый идентификатор пары запрос/отклик


                                  MerTermIDs

                                  {MerTermIDs, [TerminalID], [AgentNum], [ChainNum], [StoreNum]}


                                  Date

                                  		 Текущая дата для устаревающих записей


                                  MerchantID

                                  		 Владелец карты заносит эти данные в PIHead. Этот код копируется из MerID в сертификат подписи продавца.


                                  TerminalID

                                  		 Продавец вводит эти данные в AuthReq.


                                  AgentNum

                                  		 Продавец вводит эти данные в AuthReq.


                                  ChainNum

                                  		 Продавец вводит эти данные в AuthReq.


                                  StoreNum

                                  		 Продавец вводит эти данные в AuthReq.
                                  <


                                  /p> Формирование RRTags производится следующим образом

                                  Шаг Действие
                                  1 Формируется новый RRPID и запоминается в базе данных транзакции.
                                  2 Заносятся MerTermIDs из записанных данных продавца, описывающих место продажи.
                                  3 Записывается текущая дата в поле Date.
                                  Целью BatchStatus является предоставление данных о состоянии платежной линии между расчетным центром и продавцом или для согласования объемов платежей продавца в расчетный центр. Структура данных BatchStatus представлена в таблице 4.6.2.53.



                                  Таблица 4.6.2.53

                                  . Структура BatchStatus



                                  BatchStatus

                                  {OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]}


                                  OpenDateTime

                                  		 Дата и время открытия платежной линии


                                  ClosedWhen

                                  		 {CloseStatus, CloseDateTime}


                                  BatchDetails

                                  		 {CloseDateTime, [BrandBatchDetailsSeq]}


                                  BatchExtensions

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


                                  CloseStatus

                                  		 Цифровой код, указывающий статус закрытия платежной линии


                                  CloseDateTime

                                  		 Дата и время закрытия платежной линии


                                  BatchTotals

                                  		 {TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]}


                                  BrandBatchDetailsSeq

                                  {BrandBatchDetails +}


                                  TransactionCountCredit

                                  		 Число транзакций, которые внесли вклад в кредит продавца.


                                  TransactionTotalAmtCredit

                                  		 Полная сумма, внесенная на счет продавца


                                  TransactionCountDebit

                                  		 Число транзакций, которые внесли вклад в дебет продавца


                                  TransactionTotalAmtDebit

                                  		 Полная сумма, снятая со счета продавца


                                  BatchTotalExtensions

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

                                  Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail.


                                  BrandBatchDetails

                                  {BrandID, BatchTotals}


                                  BrandID

                                  		 Тип платежной системы карты без типа продукта
                                  <


                                  /p> Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54.



                                  Таблица 4.6.2.54

                                  . Структура TransactionDetail



                                  TransactionDetail

                                  {TransIDs, AuthRRPID, BrandID, BatchSequenceNum, [ReimbursementID], TransactionAmt, TransactionAmtType, [TransactionStatus], [TransExtensions]}


                                  TransIDs

                                  		 Идентификаторы транзакций обработки авторизации/оплаты для заданной позиции


                                  AuthRRPID

                                  		 RRPID, который присутствует в соответствующих AuthReq или AuthRevReq


                                  BrandID

                                  		 Платежная система карты (без типа продукта)


                                  BatchSequenceNum

                                  		 Порядковый номер позиции в пакете платежей


                                  ReimbursmentID

                                  		 Цифровой код, указывающий на тип оплаты для заданной позиции


                                  TransactionAmt

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


                                  TransactionAmtType

                                  		 Цифровой код, указывающий тип суммы (кредит или дебет)


                                  TransactionStatus

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


                                  TransExtensions

                                  		 Данные в расширении для административного отклика последовательности платежей (batch) должны иметь финансовый характер и использоваться при обработке административного запроса для заданной последовательности платежей.

                                  Информация, имеющая отношение к обработке запроса должна размещаться в расширении BatchAdminResData.
                                  Суммы в платежных сообщениях SET характеризуются тремя полями: валюта, сумма и amtExp10. Эти поля содержат ASCII-строки, формат которых охарактеризован в таблице ниже.

                                  Поле Определение
                                  currency (валюта) Значение представляется в виде строки ASCII-символов, характеризующей три цифры кода валюты (ISO 4217) Например, платеж в долларах США будет обозначен кодом 840. Возможные значения лежат в диапазоне 1-999 включительно.
                                  amount (cумма) Значение представляется в виде строки ASCII-символов, характеризующей сумму платежа в указанной валюте. Значение должно соответствовать положительному числу.
                                  amtExp10 Значение представляется в виде строки ASCII-символов, характеризующей десятичный показатель степени:

                                  cумма * (10amtExp10). Значение может быть как положительным, так и отрицательным.
                                  <


                                  /p> Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и –2.



                                  Поля Date



                                  Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате:

                                  YYYYMMDDHHMM[SS[.f]f]f]]]Z

                                  где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму:

                                  20011003102853.33Z,

                                  что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня.



                                  Поток платежных сообщений



                                  Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система.

                                  Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes.

                                  На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.



                                  Рис. 4.6.2.14. Диаграмма обмена для протокола покупки

                                  На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.



                                  Рис. 4.6.2.15. Опции обмена сообщениями при покупке



                                  Рис. 4.6.2.15а. (продолжение)

                                  Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.





                                  Обработка запросов/откликов инициализации платежа



                                  Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика. В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз.

                                  Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.

                                  Шаг Действие
                                  1 Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом
                                  2 Занести в поле Language, значение которое выбрал владелец карты для данной транзакции
                                  3 Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды.
                                  4 Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение.
                                  5 Сформировать новый код Chall-C
                                  6 На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET).
                                  7 Заполнить поле BIN (первые 6 цифр номера счета владельца карты)
                                  8 Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат.
                                  9 Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются).
                                  10 Опционно. Заполнить любые расширения PInitReq.
                                  11 Занести все это в цифровой конверт и послать продавцу
                                  <


                                  /p> Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55.



                                  Таблица 4.6.2.55

                                  . Структура PInitReq



                                  PInitReq

                                  		 { RRPID, Language, LID-C, [LID-M], Chall-C, BrandID, BIN, [Thumbs], [PIRqExtensions]}


                                  RRPID

                                  		 Идентификатор пары запрос/отклик


                                  Language

                                  		 Естественный язык владельца карты


                                  LID-C

                                  		 Локальный ID. Метка, формируемая системой владельца карты или для нее.


                                  LID-M

                                  		 Копируется из сообщения инициации SET (если имеется)


                                  Chall-C

                                  		 Вызов владельца карты, служащий для гарантии новизны подписи продавца


                                  BrandID

                                  		 Выбранная владельцем карты платежная система


                                  BIN

                                  		 Номер идентификации банка из номера счета владельца карты (первые 6 цифр)


                                  Thumbs

                                  		 Оттиски списка сертификатов, CRL и BrandCRLIdentifier из кэша владельца карты


                                  PIRqExtensions

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

                                  Шаг Действие
                                  1 Извлечь запрос из входного сообщения
                                  2 Если LID-M присутствует, найти запись транзакции, базирующуюся на LID-M. Если запись не найдена:

                                6. Прислать сообщение Error c ErrorCode равным unknownLID


                                7. Прервать обработку PInitReq


                                  		8.
                                  3 Если LID-M отсутствует, найти запись транзакции, на основе критериев, выходящим за пределы регламентаций SET. Если продавец не сформировал LID-M для этой транзакции, опционно сгенерировать LID-M и занести его в запись транзакции.
                                  4 Сформировать новый XID
                                  5 Занести XID, RRPID, Language, LID-C, Chall-C, BrandID и BIN в запись транзакции
                                  6 Если оттиски присутствуют, произвести спасение записи транзакции
                                  7 Если имеется какое-либо расширение PInitReq, произвести его обработку. Если расширение не распознано и флаг критичности равен TRUE, сформировать сообщение Error, в противном случае игнорировать расширение. Если расширение распознано, его следует обработать.
                                  <


                                  /p> Формирование продавцом отклика PInitRes осуществляется следующим образом.

                                  Шаг Действие
                                  1 Сформировать структуру данных PInitRes следующим образом:

                                8. Сгенерировать TransID согласно следующей процедуре:


                                9. Скопировать LID-C, XID и Language из записи транзакции


                                10. Если запись транзакции содержит LID-M, скопировать его


                                11. Занести текущую дату в TransIDs.PReqDate


                                12. Скопировать RRPID из записи транзакции


                                13. Скопировать Chall-C из записи транзакции


                                14. Сформировать новый Chall-M


                                15. Если оттиск для текущего BrandCRLIdentifier не получен или устарел, занести новый BrandCRLIdentifier


                                16. На основе информации из PInitReq (BrandID, BIN и сертификат владельца карты) выбрать расчетный центр. Записать в PEThumb оттиск сертификата выбранного расчетного центра.


                                17. Скопировать оттиски из PInitReq, если он имеется. Это позволяет владельцу карты проверить, что продавцу корректно доставлены все посланные оттиски.


                                18. Опционно: добавить любые PIRqExtensions


                                  		19.
                                  2 Ввести Compose SignedData. Если оттиск для Cert-PE не получен в PInitReq, включить в подпись Cert-PE.
                                  3 Вставить все эти данные в цифровой конверт и послать владельцу карты
                                  Информационная структура PInitRes представлена ниже в таблице 4.6.2.56.



                                  Таблица 4.6.2.56

                                  . Структура PInitRes



                                  PInitRes

                                  S(M, PInitResData)


                                  PInitResData

                                  		 {TransIDs, RRPID, Chall-C, Chall-M, [BrandCRLIdentifier], PEThumb, [Thumbs], [PIRsExtensions]}


                                  TransIDs

                                  		 Смотри описание структуры TransID выше


                                  RRPID

                                  		 Идентификатор пары запрос/отклик


                                  Chall-C

                                  		 Копируется из сообщения PInitReq


                                  Chall-M

                                  		 Вызов продавца, служащий для проверки новизны подписи владельца карты


                                  BrandCRLIdentifier

                                  		 Список текущих CRL для всех СА в рамках заданной платежной системы.


                                  PEThumb

                                  		 Оттиск сертификата ключевого обмена расчетного центра.


                                  Thumbs

                                  		 Копируется из PInitReq


                                  PIRsExtensions

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

                                  Шаг Действие
                                  1 Извлечь PInitRes из входного сообщения
                                  2 Вызвать Receive SignedData
                                  3 Проверить TransID следующим образом:

                                19. Осуществить поиск транзакции с использованием LID-C. Если поиск безуспешен:


                                20. Послать сообщения Error с ErrorCode равным unknownLID


                                21. Остановить обработку PInitRes


                                22. Если LID-M был послан во время инициализационного процесса SET, сравнить LID-M с LID-M в записи транзакции. Если они неэквивалентны, то:


                                23. Послать сообщение Error с ErrorCode равным unknownLID


                                24. Остановить обработку PInitRes


                                  25. с) Если LID-M не был послан и имеется LID-M, то:

                                25. Послать сообщение Error с ErrorCode равным unknownLID


                                26. Остановить обработку PInitRes


                                  		27.
                                  4 Сравнить RRPID со значением из записи транзакции. Если они отличаются, то:

                                27. Послать сообщение Error с ErrorCode равным unknownRRPID


                                28. Остановить обработку PInitRes


                                  		29.
                                  5 Сравнить Сhall-C со значением из записи транзакции. Если они отличаются, то:

                                29. Послать сообщение Error с ErrorCode равным challengeMismatch.


                                30. Остановить обработку PInitRes


                                  		31.
                                  6 В опционном варианте управления со стороны владельца карты из сертификата продавца извлекается его имя и отображается для пользователя. Если владелец карты одобряет кандидатуру, процесс продолжается, в противном случае обработка PInitRes прерывается.
                                  7 Занести данные, включая TransID и Chall-M, в запись транзакции
                                  8 Обработать BrandCRLIdentifier, если он присутствует.
                                  9 Использовать PEThumb для идентификации сертификата шифрования (Cert-PE), чтобы использовать в PReq при шифровании данных для расчетного центра.
                                  10 Проверить, что сертификат платежной системы продавца и сертификат расчетного центра (Cert-PE) согласуются с платежной системой владельца карты, указанной в PInitReq. Если согласия нет, владелец карты оповещается об этом, а обработка PInitReq прерывается.
                                  11 Если поле Thumbs присутствует, сравнить его значение с тем, что прислано в PInitReq. Если значения совпадают, перейти к исполнению пункта 14, в противном случае:

                                31. Послать сообщение Error с ErrorCode равным thumbsMismatch


                                32. Остановить обработку PInitRes


                                  		33.
                                  12 Если поле Thumbs отсутствует, проверить, что Thumbs не было послано в PInitReq. Если Thumbs было послано в PInitReq, то:

                                33. Послать сообщение Error с ErrorCode равным thumbsMismatch


                                34. Остановить обработку PInitRes


                                  		35.
                                  13 Если PIRsExtensions существуют, их необходимо обработать. Если они не распознаны, а флаг критичности (criticality) равен TRUE, сформировать сообщение Error, в противном случае расширения следует игнорировать.
                                  14 Проверить Cert-PE (идентифицированный в PEThumb) для неподписанных транзакций. Если индикатор в Cert-PE не допускает неподписанных транзакций, а владелец карты не имеет сертификата, информировать его о том, что транзакция не может быть продолжена и прервать обработку.
                                  15 Владелец карты может теперь продолжить процедуру посылкой запроса покупки.
                                  <


                                  /p> Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует иметь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации.

                                  Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется.



                                  Обработка заказа-покупки



                                  Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа.

                                  Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).



                                  Рис. 4.6.2.16. Обработка запроса покупки

                                  Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца. Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP).



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

                                  Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе.

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

                                  Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись.



                                  PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:

                                35. C PI используется OAEP


                                36. В блок OAEP включается H(PIHead) (вместе с PANData)


                                37. С PIHead используется H(OIData)


                                38. Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead.


                                  39. Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).

                                  Шаг Действие
                                  1 Извлечь PurchAmt и OD
                                  2 Сформировать OIData следующим образом:
                                  a) Если имел место обмен PInitReq/ PInitRes: Скопировать TransIDs из PInitRes
                                  В противном случае: Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID
                                  b) Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца
                                  Если имел место обмен PInitReq/PInitRes: Скопировать Chall-c из PInitRes
                                  В противном случае: Сформировать новый Chall-C
                                  c) Сформировать новый ODSalt
                                  d) Сформировать HODInput посредством следующей процедуры:


                                  • Скопировать OD из данных процесса инициализации SET


                                  • Записать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET.


                                  • Скопировать ODSalt из пункта 2 с)


                                  • Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurData


                                  • Опционно: добавить любые ODExtensions
                                  e) Сформировать HOD с HODInput из пункта 2 d
                                  f) Если имел место обмен PInitReq/ PInitRes: Скопировать Chall-M из PInitRes и не заполнять BrandID
                                  В противном случае: Не заполнять Chall-M

                                  Записать BrandID, указав предпочтительный тип карты
                                  g) Произвести записьв поле BIN с HODInput из пункта 2d
                                  h) Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш
                                  i) Опционно: добавить любые расширения OIExtensions.
                                  3 Сформировать PIHead следующим образом:
                                  a) Скопировать TransIDs, вычисленные в пункте 2.а
                                  b) Сгенерировать Inputs согласно процедуре:

                                  • Скопировать HOD из пункта 2.е


                                  • Скопировать PurchAmt из шага 2.d.2
                                  c) Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога
                                  d) Скопировать InstallRecurData из пункта 2.d.4 (если имеется)
                                  e) Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями.
                                  f) Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения
                                  g) Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом:

                                39. Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f.


                                40. Сформировать новый AcqBackKey (приемлемый для AcqBackAlg)
                                  41. h) Опционно добавить любые PIExtensions
                                  4 Сформировать PANData
                                  5 Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2)
                                  6 Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет.
                                  <


                                  /p> Когда расчетный центр готов шифровать данные для конечного пользователя (ЕЕ), его сертификат содержит список симметричных алгоритмов шифрования, которые он поддерживает, в порядке их предпочтения. Конечный пользователь, который хочет иметь шифрованные данные, выбирает первый алгоритм из списка, который он способен использовать. Ключ для этого алгоритма передается расчетному центру в сообщении PReq.

                                  Реализация PReqDualSigned рассмотрена ниже.

                                  Шаг Действие
                                  1 Сформировать PISignature:



                                  1. Сформировать PI-TBS:




                                      1. Сгенерировать HPIData в виде дайджеста PIData


                                      2. Сгенерировать HOIData в виде дайджеста OIData




                                        1. Выполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t).
                                        2 Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p)
                                        3 Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2.
                                        4 Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.).
                                        5 Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2)
                                        6 Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5.
                                        Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned). Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57.





                                        Таблица 4.6.2.57.

                                         Структура PReqDualSigned

                                        PReqDualSigned {PIDualSigned, OIDualSigned}
                                        PIDualSigned Смотри описание PI (выше)
                                        OIDualSigned L(OIDualSigned, PIData)
                                        OIData Смотри табл. 4.6.2.59
                                        PIData {PIHead, PANData}
                                        Структура данных в случае PReqUnsigned показана в таблице 4.6.2.58.



                                        Таблица 4.6.2.58

                                        . Структура PReqUnsigned

                                        PReqUnsigned {PIUnsigned, OIUnsigned}
                                        PIUnsigned Смотри описание PI (выше)
                                        OIUnsigned L(OIData, PIDataUnsigned)
                                        OIData Смотри табл. 4.6.2.59
                                        PIDataUnsigned {PIHead, PANToken} (см. табл. 4.6.2.40 и 4.6.2.45)
                                        Структура данных сообщения PReq для PReqDualSigned и PreqUnsigned показана в таблице 4.6.2.59.



                                        Таблица 4.6.2.59

                                        . Структура PReq для PReqDualSigned и PreqUnsigned

                                        OIData {TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]}
                                        TransIDs Копируется из PInitRes, если имеется
                                        RRPID ID пары запрос/отклик
                                        Chall-C Копируется из соответствующего PInitReq (см. табл. 4.6.2.55)
                                        HOD DD(HODInput)

                                        Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью
                                        ODSalt Копируется из HODInput
                                        Chall-M Вызов продавца владельцу карты относительно свежести подписи
                                        BrandID Выбранная владельцем карты платежная система
                                        BIN Идентификационный номер банка из номера счета владельца карты (первые 6 цифр)
                                        ODExtOIDs Список объектных идентификаторов из ODExtensions
                                        OIExtensions Данные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации.
                                        HODInput {OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]}
                                        OD Описание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д.
                                        PurchAmt Число транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40).
                                        ODSalt Новое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD.
                                        InstallRecurData См. табл. 4.6.2.41
                                        ODExtensions Данные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу.
                                        <


                                        /p> При получении PReq продавец производит следующие действия.

                                        Шаг Действие
                                        1 Извлекает PReq из входного сообщения
                                        2 Если получено PReqDualSigned, производит проверку подписи;



                                        1. Извлекает OIData и HPData из OIDualsigned


                                        2. Формирует HOIData в виде дайджеста OIData


                                        3. Формирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В.


                                        4. Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t).


                                        5. Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq.


                                        6. Переходит к выполнению пункта 4.


                                          		7.
                                          3 Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то:



                                            1. Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись)


                                            2. Останавливает обработку PReq


                                              		3.
                                              4 Производит обработку TransIDs:

                                              Проводит поиск транзакций, базирующихся на XID.

                                              Если запись такой транзакции найдена

                                              Сравнивает LID-C и LID-M с записью. Если соответствия нет:

                                            3. Возвращает сообщение Error c ErrorCode = unknownLID


                                            4. Останавливает обработку PReq


                                              5. В противном случае сверяет Chall-M с записью. Если соответствия нет, то:

                                            5. Присылает сообщение Error c ErrorCode = challengeMismatch


                                            6. Останавливает обработку PReq


                                              7. В противном случае

                                            7. Формирует новую запись транзакции


                                            8. Спасает LID-C, PReqDate и Language


                                            9. Опционно формирует LID-M


                                              		10.
                                              5 Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то:

                                            10. Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен)


                                            11. Останавливает обработку PReq


                                              		12.
                                              6 Запоминает Chall-C, чтобы вернуть его в последующем PRes
                                              7 Запоминает оставшиеся переменные из сообщения в базе данных
                                              8 Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется)
                                              9 Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes
                                              <


                                              /p> После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:

                                              Шаг Действие
                                              1 Сформировать PResData:

                                            12. Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центра


                                            13. Скопировать RRPID из PReq (или из InqReq)


                                            14. Скопировать Chall-C из PReq (или из InqReq)


                                            15. Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifier


                                            16. Сформировать PresPayloadSeq:




                                                1. Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2.


                                                2. Если расчетный центр отклонил заказ, сформировать PresPayload:




                                                • Установить CompletionCode = orderReject


                                                • Скопировать AcqCardMsg из AuthRes, если имеется.


                                                • Перейти к пункту 2




                                                    1. Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2.


                                                    2. Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2.


                                                    3. Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже
                                                    2 Ввести Compose SignedData
                                                    3 Вставить сообщение в цифровой конверт и послать владельцу карты
                                                    Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:

                                                    Шаг Действие
                                                    1 Если выполнена только авторизация:

                                                  1. Установить CompletionCode = authorizationPerformed


                                                  2. Сформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq.


                                                    		3.
                                                    2 Если оплата (capture) выполнена:



                                                    1. Установить CompletionCode = capturePerformed


                                                    2. Сформировать Results, как это описано ниже, опуская CredStatusSeq


                                                      		3.
                                                      3 Если кредитование осуществлено;



                                                      1. Установить CompletionCode = creditPerformed


                                                      2. Сформировать Results, как это описано ниже


                                                        		3.
                                                        4 Опционно добавить любые PRsExtensions
                                                        <


                                                        /p> Формирование поля Results производится согласно следующему алгоритму:

                                                        Шаг Действие
                                                        1 Скопировать AcqCardMsg из AuthRes, если этот отклик имеется
                                                        2 Если позиция авторизована, сформировать AuthStatus:



                                                        1. Скопировать AuthDate из записи транзакции


                                                        2. Скопировать AuthCode из записи транзакции


                                                        3. Вычислить AuthRatio, как AuthReqAmt ? PurchAmt


                                                        4. Если в AuthRes присутствуют данные о конвертации валюты, скопировать их


                                                          		5.
                                                          3 Если позиция оплачена, сформировать CapStatus:

                                                        5. Скопировать CapDate из записи транзакции


                                                        6. Скопировать CapCode из записи транзакции


                                                        7. Вычислить CapRatio, как CapReqAmt ? PurchAmt


                                                          		8.
                                                          4 Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus:

                                                        8. Скопировать CreditDate из записи транзакции


                                                        9. Скопировать CreditCode из записи транзакции


                                                        10. Вычислить CreditRatio, как CapRevOrCredReqAmt ?

                                                          PurchAmt


                                                          		11.
                                                          Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60.



                                                          Таблица 4.6.2.60

                                                          . Структура PRes, формируемая продавцом



                                                          PRes

                                                          		 S(M, PresData)


                                                          PResData

                                                          		 {TransIDs, RRPID, Chall-C, [BrandCRLIdentifier], PresPayloadSeq}


                                                          TransIDs

                                                          		 Копируется из PReq


                                                          RRPID

                                                          		 Идентификатор пары запрос/отклик


                                                          Chall-C

                                                          		 Копируется из соответствующего PInitReq


                                                          BrandCRLIdentifier

                                                          		 Список текущих CRL для всех СА в зоне ответственности СА платежной системы


                                                          PResPayloadSeq

                                                          		 {PresPayload +}

                                                          Одна запись для каждой выполненной авторизации. Отмена авторизации удаляет запись из PResPayload. Если не было авторизаций, появляется одна позиция с соответствующей статусной записью


                                                          PResPayload

                                                          		 См. табл. 4.6.2.61
                                                          Структура данных PResPayload представлена в таблице 4.6.2.61



                                                          Таблица 4.6.2.61

                                                          . Структура PResPayload



                                                          PResPayload

                                                          		 {CompletionCode, [Results], [PrsExtensions]}


                                                          CompletionCode

                                                          		 Цифровой код, указывающий на состояние завершения транзакции


                                                          Results

                                                          		 {[AcqCardMsg], [AuthStatus], [AuthStatus], [CredStatusSeq]}


                                                          PRsExtensions

                                                          		 Отклик на запрос покупки не зашифрован и по этой причине не должен содержать конфиденциальную информацию


                                                          AcqCardMsg

                                                          		 Копируется из AuthRes (см. табл. 4.6.2.43)


                                                          AuthStatus

                                                          		 {AuthDate, AuthCode, AuthRatio, [CurrConv]}


                                                          CapStatus

                                                          		 {CapData, CapCode, CapRatio}

                                                          Данные присутствуют здесь, только если CapReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.


                                                          CredStatusSeq

                                                          		 {CredStatus +}

                                                          Данные присутствуют, только если CredReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.


                                                          AuthDate

                                                          		 Данные авторизации. Копируются из AuthRRTags.Date (см. табл. 4.6.2.64)


                                                          AuthCode

                                                          		 Цифровой код, указывающий на состояние авторизационного процесса. Копируется из AuthResPayload.


                                                          AuthRatio

                                                          		 AuthReqAmt ? PurchAmt


                                                          CurrConv

                                                          		 {CurrConvRate, CardCurr}

                                                          Информация о конвертировании валюты, копируется из AuthResPayload


                                                          CapData

                                                          		 Дата оплаты, копируется из CapPayload


                                                          CapCode

                                                          		 Цифровой код, указывающий на состояние оплаты, копируется из CapResPayload


                                                          CapRatio

                                                          		 CapReqAmt ? PurchAmt


                                                          CreditStatus

                                                          		 {CreditDate, CreditCode, CreditRatio}

                                                          Данные присутствуют, только если реализован запрос CreditReq. Эта информация удаляется CredRevReq


                                                          CreditDate

                                                          		 Дата кредита. Копируется из CapRevOrCredCode.


                                                          CreditCode

                                                          		 Цифровой код, указывающий на состояние кредита. Копируется из CapRevOrCredResPayload.CapRevOrCredCode. (см. табл. 4.6.2.74)


                                                          CreditRatio

                                                          		 CapRevOrCredReqAmt ? PurchAmt
                                                          <


                                                          /p> Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62).



                                                          Таблица 4.6.2.62

                                                          . Коды завершения операции



                                                          meanonglessRatio

                                                          		 PurchAmt=0; отношение не может быть вычислено


                                                          orderRejected

                                                          		 Продавец не может обработать заказ


                                                          orderReceived

                                                          		 Процессы авторизации отсутствуют


                                                          orderNotReceived

                                                          		 Информационный запрос получен до заказа


                                                          authorizationPerformed

                                                          		 См. AuthStatus


                                                          capturePerformed

                                                          		 См. CapStatus


                                                          creditPerformed

                                                          		 См. CreditStatus
                                                          Владелец карты обрабатывает полученный отклик PRes следующим образом.

                                                          Шаг Действие
                                                          1 Извлекается отклик из входного сообщения
                                                          2 Чтобы проверить подпись продавца, производится обращение к Received Signed Data,
                                                          3 На основе Trans.LID-C ищется запись транзакции. Если запись не найдена:

                                                        11. Посылается сообщение Error c ErrorCode равным unknownLID


                                                        12. Прерывается обработка PRes


                                                          		13.
                                                          4 Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет:

                                                        13. Посылается сообщение Error c ErrorCode равным unknownXID


                                                        14. Прерывается обработка PRes


                                                          		15.
                                                          5 Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет:

                                                        15. Посылается сообщение Error c ErrorCode равным unknownRRPID


                                                        16. Прерывается обработка PRes


                                                          		17.
                                                          6 Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет:

                                                        17. Посылается сообщение Error c ErrorCode равным challengeMismatch


                                                        18. Прерывается обработка PRes


                                                          		19.
                                                          7 Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной.
                                                          8 Для каждого PResPayload из PresPayloadSeq выполняются следующие действия:

                                                        19. Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio).


                                                        20. В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount

                                                          (PurchaseAmount*CapRatio).


                                                        21. В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount

                                                          (PurchaseAmount*AuthRatio).


                                                        22. В противном случае сообщить результат транзакции на основе CompletionCode.


                                                        23. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы.


                                                          		24.
                                                          <


                                                          /p>

                                                          Обработка информационных запросов



                                                          Пара сообщений InqReq/ InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.

                                                          Шаг Действие
                                                          1
                                                        24. Копируется InqReqData из предыдущего запроса


                                                        25. Формируется новый RRPID


                                                        26. Генерируется новый Chall-С


                                                        27. Опционно добавляются любые InqReqExtensions


                                                          		28.
                                                          2 Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData
                                                          3 Вставить сообщение в цифровой конверт и послать продавцу
                                                          Структура данных запроса InqReq представлена в таблице 4.6.2.63.



                                                          Таблица 4.6.2.63.

                                                           Структура InqReq



                                                          InqReq

                                                          		 <InqReqSigned, InqReqData>


                                                          InqReqSigned

                                                          		 S(C, InqReqData)


                                                          InqReqData

                                                          		 {TransIDs, RRPID, Chall-C2, [InqRqExtensions]}


                                                          TransIDs

                                                          		 Копируется из самого последнего: PReq, PRes, InqReq


                                                          RRPID

                                                          		 Идентификатор пары запрос/отклик


                                                          Chall-C2

                                                          		 Новый вызов владельца карты по поводу подписи продавца.


                                                          InqRqExtensions

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

                                                          Шаг Действие
                                                          1 Извлекается запрос из входного сообщения
                                                          2 Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда:

                                                        28. Прислать сообщение InqRes c CompletionCode = signatureRequired.


                                                        29. Прервать обработку InqReq


                                                          30. В противном случае перейти к пункту 4.
                                                          3 Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла:

                                                        30. Прислать сообщение Error с ErrorCode = signatureFailure


                                                        31. Прервать обработку InqReq


                                                          		32.
                                                          4 Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет:

                                                        32. Прислать сообщение Error c ErrorCode = wrapperMsgMismatch


                                                        33. Прервать обработку InqReq


                                                          		34.
                                                          5 Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен:

                                                        34. Прислать InqRes c CompletionCode = orderNotReceived.


                                                        35. Прервать обработку InqReq


                                                          		36.
                                                          6 Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то:

                                                        36. Прислать сообщение Error c ErrorCode = unknownXID.


                                                        37. Прервать обработку InqReq


                                                          		38.
                                                          7 Сформировать PResPayloadSeq
                                                          <


                                                          /p> Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.



                                                          Рис. 4.6.2.17. Авторизация платежей

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

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

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

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

                                                          При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса. Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель).



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

                                                          Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись.

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

                                                          Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты.

                                                          Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа. В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.

                                                          Шаг Действие
                                                          1 Сгенерировать AuthTags (см. табл. ниже)
                                                          2 Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI.
                                                          3 Сгенерировать AuthReqPayload (см. табл. ниже)
                                                          4 Опционно для одновременной авторизации и резервирования заказа:

                                                        38. Установить CaptureNow = TRUE


                                                        39. Сгенерировать SaleDetail (см. табл. 4.6.2.47)


                                                        40. Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа).


                                                          41. Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа.
                                                          5 Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken.
                                                          6 Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра.
                                                          7 Осуществить EncB-инкапсуляцию
                                                          8 Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы.
                                                          9 Поместить сообщение в цифровой конверт и отправить адресату
                                                          <


                                                          /p> Процедура формирования AuthTags показана в таблице ниже.

                                                          Шаг Действие
                                                          1 Заполнить поле AuthRRTags (см. табл. 4.6.2.52)
                                                          2 Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID.
                                                          3 Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes
                                                          Схема формирования поля данных AuthReq показана ниже.

                                                          Шаг Действие
                                                          1 Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE.
                                                          2 Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData
                                                          3 Установить AuthReqAmt равным числу авторизаций
                                                          4 Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты.
                                                          5 Если при некотором платеже необходимы данные MerchData, добавить их в сообщение.
                                                          6 Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки.
                                                          7 Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты.
                                                          8 Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение.
                                                          9 Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE.
                                                          Структура данных сообщения AuthReq представлена в таблице 4.6.2.64.



                                                          Таблица 4.6.2.64.

                                                           Структура AuthReq



                                                          AuthReq

                                                          		 EncB(M, P, AuthReqData, PI)


                                                          AuthReqData

                                                          		 {AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]}


                                                          PI

                                                          		 См. табл. 4.6.2.39.


                                                          AuthReqItem

                                                          		 {AuthTags, [CheckDigests], AuthReqPayload}


                                                          MThumbs

                                                          		 Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца.


                                                          CaptureNow

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


                                                          SaleDetail

                                                          		 См. табл. 4.6.2.47


                                                          AuthTags

                                                          		 {AuthRRTags, TransIDs, [AuthRetNum]}


                                                          CheckDigests

                                                          		 {HOIData, HOD2}

                                                          используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken


                                                          AuthReqPayload

                                                          		 См. табл. 4.6.2.65


                                                          AuthRRTags

                                                          		 RRTags

                                                          Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации.


                                                          TransIDs

                                                          		 Копируется из соответствующего поля OIData (см. табл. 4.6.2.59)


                                                          AuthRetNum

                                                          		 Идентификация запроса авторизации, используемого в пределах финансовой сети.


                                                          HOIData

                                                          DD(OIData)

                                                          (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.


                                                          HOD2

                                                          DD(HODInput)

                                                          (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.
                                                          <


                                                          /p> Структура данных AuthReqPayload представлена в таблице 4.6.2.65.



                                                          Таблица 4.6.2.65.

                                                           Структура AuthReqPayload



                                                          AuthReqPayload

                                                          {SubsequentAuthInd, AuthReqAmt, [AVSData],

                                                          [SpecialProcessing], [CardSuspect],

                                                          RequestCardTypeInd, [InstallRecurData],

                                                          [MarketSpecAuthData], MerchData, [ARqExtensions]}


                                                          SubsequentAuthInd

                                                          		 Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки


                                                          AuthReqAmt

                                                          		 Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие


                                                          AVSData

                                                          {[StreetAddress], Location}

                                                          Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.


                                                          SpecialProcessing

                                                          		 Числовое поле, указывающее тип запрошенной обработки


                                                          CardSuspect

                                                          		 Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения


                                                          RequestCardTypeInd

                                                          		 Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).


                                                          InstallRecurData

                                                          		 См. табл. 4.6.2.41.


                                                          MarketSpecAuthData

                                                          < MarketAutoAuth, MarketHotelAuth, MarketTransportAuth >

                                                          Специфические авторизационные данные рынка


                                                          MerchData

                                                          {[MerchCatCode], [MerchGroup]}


                                                          ARqExtensions

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


                                                          StreetAddress

                                                          		 Адрес улицы владельца карты


                                                          MarketAutoAuth

                                                          {Duration}


                                                          MarketHotelAuth

                                                          {Duration, [Prestige]}


                                                          MarketTransportAuth

                                                          {}

                                                          В настоящее время нет авторизационных данных для этого сегмента рынка


                                                          MerchCatCode

                                                          		 4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.


                                                          MerchGroup

                                                          		 Числовой код, идентифицирующий общую категорию продавца


                                                          Duration

                                                          		 Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).


                                                          Prestige

                                                          		 Числовой тип приоритета, определяется платежной системы карты.
                                                          <


                                                          /p> Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.

                                                          Шаг Действие
                                                          1 Извлечь запрос из транспортного сообщения
                                                          2 Дешифровать PI
                                                          3 Сравнить TransIDs из AuthTags и PIHead или AuthToken:

                                                        41. Проверить что коды XID идентичны


                                                        42. Проверить что коды LID-C идентичны


                                                        43. Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения


                                                          44. Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch
                                                          4 Если PI является AuthToken:

                                                        44. Обработать AuthToken


                                                          45. В противном случае, если PI подписаны:

                                                        45. Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch.


                                                        46. Проверить PANData


                                                        47. Запомнить данные из PANData


                                                          48. В противном случае, если PI не подписаны:

                                                        48. Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired


                                                        49. Верифицировать хэш в EXH


                                                        50. Запомнить данные из PANToken


                                                          		51.
                                                          5 Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed
                                                          6 Обработать PIHead:

                                                        51. Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами.


                                                        52. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией.


                                                        53. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch.


                                                        54. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch


                                                        55. Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension


                                                        56. Запомнить данные от PIHead


                                                          		57.
                                                          7 Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.
                                                          8 Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.
                                                          9 Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported
                                                          10 Выполнить авторизацию через финансовую сеть платежной карты
                                                          11 Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты
                                                          12 Продолжить формирование сообщения AuthRes
                                                          <


                                                          /p> Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.

                                                          Шаг Действие
                                                          1 Получить необходимые данные от авторизационного процесса
                                                          2 Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.
                                                          3 Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.
                                                          4 Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра:

                                                        57. Вставить Cert-PE в цифровой конверт PKCS#4


                                                        58. Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью


                                                          		59.
                                                          5 Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса
                                                          6 Заполнить поле PANToken, если это необходимо для сертификата продавца,
                                                          7 Заполнить AuthResBaggage (опционно):

                                                        59. Опционно заполнить CapToken


                                                        60. Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты.


                                                        61. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE).


                                                          62. Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.
                                                          8 Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.
                                                          9 Если PANToken имеется, реализовать EncBX-инкапсуляцию
                                                          10 Вставить сообщение в цифровой конверт и отправить владельцу карты
                                                          Расчетный центр формирует AuthResPayload следующим образом.

                                                          Шаг Действие
                                                          1 Сгенерировать CapResPayload
                                                          Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса

                                                        62. Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq.


                                                        63. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported


                                                          		64.
                                                          3 Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.
                                                          4 Заполнить ResponseData:

                                                        64. Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса.


                                                        65. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса.


                                                        66. Занести в AuthCharInd значение, присланное авторизационным процессом


                                                          		67.
                                                          <


                                                          /p> Структура полей AuthRes представлена в таблице 4.6.2.66.



                                                          Таблица 4.6.2.66.

                                                          Структура полей AuthRes



                                                          AuthRes

                                                          		 <EncB(P, M, AuthResData, AuthResBaggage), EncBX(P, M, AuthResData, AuthResBaggage, PANToken)>


                                                          AuthResData

                                                          		 {AuthTags, [BrandCRLIdentifier], [PEThumb], AuthResPayload}


                                                          AuthResBaggage

                                                          		 {[CapToken], [AcqCardMsg], [AuthToken]}


                                                          PANToken

                                                          		 См. табл. 4.6.2.46. Посылается, если сертификат продавца указывает на то, что информация предназначена продавцу.


                                                          AuthTags

                                                          		 Копируется из соответствующего AuthReq; TransIDs и AuthRetNum могут быть актуализованы с привлечением текущей информации


                                                          BrandCRLIdentifier

                                                          		 Список текущих CRL для всех СА в зоне ответственности СА платежной системы.


                                                          PEThumb

                                                          		 Оттиск сертификата расчетного центра предоставляется, если AuthReq.Mthumbs указывает то, что он нужен продавцу


                                                          AuthResPayload

                                                          		 См. табл. 4.6.2.67.


                                                          CapToken

                                                          		 См. табл. 4.6.2.44.


                                                          AcqCardMsg

                                                          		 Если владелец карты включил AcqBackKeyData в PIHead, расчетный центр может послать это поле продавцу в шифрованном сообщении для владельца карты. Продавец должен скопировать AcqCardMsg в любой последующий отклик PRes или InqRes, посылаемый владельцу карты.


                                                          AuthToken

                                                          		 Продавец использует это поле в качестве PI в последующих запросах AuthReq. См. табл. 4.6.2.42.
                                                          Структура AuthResPayload представлена ниже в таблице 4.6.2.67.



                                                          Таблица 4.6.2.67

                                                          . Структура AuthResPayload



                                                          AuthResPayload

                                                          {AuthHeader, [CapResPayload], [ARsExtensions]}


                                                          AuthHeader

                                                          {AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}


                                                          CapResPayload

                                                          		 Присылается, если CaptureNow

                                                          имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.


                                                          ARsExtensions

                                                          		 Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.


                                                          AuthAmt

                                                          		 Копируется из AuthReqPayload.AuthReqAmt


                                                          AuthCode

                                                          		 Числовой код, индицирующий результат процесса авторизации


                                                          ResponseData

                                                          {[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}


                                                          BatchStatus

                                                          		 См. табл. 4.6.2.53.


                                                          CurrConv

                                                          {CurrConvRate, CardCurr}


                                                          AuthValCodes

                                                          {[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}


                                                          RespReason

                                                          		 Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)


                                                          CardType

                                                          		 Числовой код, который указывает на тип карты, использованной для транзакции.


                                                          AVSResult

                                                          		 Числовой код отклика адресной верификационной службы


                                                          LogRefID

                                                          		 Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)


                                                          CurrConvRate

                                                          		 Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.


                                                          AuthReqAmt

                                                          		 Код валюты владельца карты в стандарте ISO 4217


                                                          ApprovalCode

                                                          		 Код одобрения, присваиваемый транзакции эмитентом


                                                          AuthCharInd

                                                          		 Числовое значение, которое указывает условия, при которых выполнена авторизация.


                                                          ValidationCode

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


                                                          MarketSpecDataID

                                                          		 Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью)
                                                          <


                                                          /p> Список возможных значений кода AuthCode приведен ниже

                                                          approved Запрос авторизации удовлетворен
                                                          unspecifiedFailure Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.
                                                          declined Запрос авторизации отклонен
                                                          noReply Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.
                                                          callIssuer Эмитент запрашивает телефонный вызов от продавца
                                                          amountError Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)
                                                          expiredCard Срок действия карты истек
                                                          invalidTransaction Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.
                                                          systemError Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.
                                                          piPreviouslyUsed Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).
                                                          recurringTooSoon Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).
                                                          recurringExpired Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)
                                                          piAuthMismatch Дата в PI от владельца карты не согласуется с данными в OD от продавца.
                                                          installRecurMismatch InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.
                                                          captureNotSupported Расчетный центр не поддерживает платеж (capture).
                                                          signatureRequired Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы.
                                                          cardMerchBrandMismatch Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.
                                                          <


                                                          /p> Обработка продавцом отклика AuthRes производится следующим образом.

                                                          Шаг Действие
                                                          1 Получить отклик из входного сообщения
                                                          2 Извлечь запись транзакции и сравнить с AuthTags:

                                                        67. Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID


                                                        68. Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.


                                                          		69.
                                                          3 Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
                                                          4 Обработать AuthResPayload
                                                          5 Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата
                                                          6 Если BatchStatus присутствует, обработать и запомнить данные.
                                                          7 Обработать AuthResBaggage:

                                                        69. Запомнить CapToken, если это поле присутствует


                                                        70. Если имеется AcqCardMsg, запомнить его для отправки владельцу карты


                                                        71. Запомнить AuthToken, если имеется, для последующей авторизации.


                                                          72. Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken
                                                          8 Если присутствует PANToken, записать его в безопасную локальную память
                                                          9 Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.
                                                          Алгоритм обработки AuthResPayload представлен ниже.

                                                          Шаг Действие
                                                          1 Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.
                                                          2 Обрабатать CapResPayload:

                                                        72. Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension


                                                        73. Обработать CapCode с целью определения результата


                                                        74. Обработать SaleDetail в соответствии с политикой платежной системы карты


                                                        75. Для успешной оплаты заказа, записать CapCode и CapAmt.


                                                          76. Если делался запрос оплаты (capture), будет возвращен CapResPayload
                                                          3 Если имеется CurrConv, запомнить его для переадресации владельцу карты
                                                          4 Обработать AuthCode, AuthAmt и ResponseData:

                                                        76. Для определения результата обрабатывается AuthCode.


                                                        77. Запомнить AuthCode и AuthAmt для получения успешного результата.


                                                        78. Запомнить ValidationCode для успешного исхода, если это поле имеется.


                                                        79. Запомнить AuthValCode, если имеется.


                                                        80. Запомнить AVSResult, если имеется.


                                                        81. Запомнить LogRefID, если имеется.


                                                          		82.
                                                          <


                                                          /p> Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode.

                                                          Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0).

                                                          При этом код отклика не переписывается.

                                                          Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode.

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

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

                                                          Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках.





                                                          Запрос/отклик платежа (CapReq/CapRes)



                                                          Пара сообщений CapReq/ CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).



                                                          Рис. 4.6.2.18. Обработка платежных запросов

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

                                                          Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов.

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

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

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



                                                          Пары запросов CapReq/ CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.

                                                          Шаг Действие
                                                          1 Заполнить поле CapRRTags
                                                          2 Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken
                                                          3 Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier
                                                          4 Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem:

                                                        82. Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции.


                                                        83. Заполнить CapPayload


                                                        84. Заполнить SaleDetail, как это требует политика платежной системы карты.


                                                        85. Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes


                                                          		86.
                                                          5 Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль.
                                                          6 В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken
                                                          7 Опционно заполняется CRqExtensions
                                                          8 Если включено PANToken, использовать EncBХ-инкапсуляцию
                                                          9 Если PANToken не включено, использовать EncB-инкапсуляцию
                                                          10 Вложить сообщение в цифровой конверт и послать владельцу карты
                                                          Генерация CapPayload осуществляется согласно алгоритму.

                                                          Шаг Действие
                                                          1 Занести в поле CapDate текущее значение даты
                                                          2 Занести в CapReqAmt сумму выплаты
                                                          3 Скопировать AuthResPayload из соответствующего AuthRes
                                                          4 Опционно заполнить CPayExtensions
                                                          Формат сообщения CapReq представлен в таблице 4.6.2.68





                                                          Таблица 4.6.2.68

                                                          . Формат CapReq



                                                          CapReq

                                                          <EncB(M, P, CapReqData, CapTokenSeq), EncBX(M, P, CapReqData, CapTokenSeq, PANToken)>

                                                          CapTokenSeq является внешним “багажом”.

                                                          Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq.


                                                          CapReqData

                                                          		 {CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]}


                                                          CapTokenSeq

                                                          {[

                                                          CapToken] +}

                                                          Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю.


                                                          PANToken

                                                          		 См. табл. 4.6.2.46.


                                                          CapRRTags

                                                          		 RRTags.

                                                          Новый RRPID и Date


                                                          MThumbs

                                                          		 Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца.


                                                          CapItemSeq

                                                          {

                                                          CapItem +}

                                                          Один или более CapItem в упорядоченном массиве


                                                          CRqExtensions

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

                                                          Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload


                                                          CapToken

                                                          		 Копируется из соответствующего AuthRes или AuthRevRes


                                                          CapItem

                                                          		 {TransIDs, AuthRRPID, CapPayload}


                                                          TransIDs

                                                          		 Копируется из соответствующего AuthRes или AuthRevRes


                                                          AuthRRPID

                                                          		 RRPID, который появляется в соответствующем AuthReq или AuthRev


                                                          CapPayload

                                                          		 См. табл. 4.6.2.69.
                                                          Структура данных CapPayload представлена в таблице 4.6.2.69.



                                                          Таблица 4.6.2.69

                                                          . Структура CapPayload



                                                          CapPayload

                                                          		 {CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]}


                                                          CapDate

                                                          		 Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты.


                                                          CapReqAmt

                                                          		 Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты.


                                                          AuthReqItem

                                                          		 См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса.


                                                          AuthResPayload

                                                          		 См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика.


                                                          SaleDetail

                                                          		 См. табл. 4.6.2.47.


                                                          CPayExtensions

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

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


                                                          /p> Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.

                                                          Шаг Действие
                                                          1 Извлечь запрос из входного сообщения
                                                          2 Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension
                                                          3 Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче:

                                                        86. Обработать CapPayload


                                                        87. Если CapToken присутствует:




                                                            1. Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken


                                                            2. Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken


                                                            3. Обработать TokenOpaque


                                                          1. В противном случае, если допустимы платежи без CapToken:




                                                              1. Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing


                                                              2. Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData.


                                                            1. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken


                                                            2. Проверить TransIDs




                                                                1. Извлечь запись транзакции


                                                                2. Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID


                                                                3. Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLID


                                                                f) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат.
                                                                Расчетный центр обрабатывает CapPayLoad следующим образом.

                                                                Шаг Действие
                                                                1 Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension
                                                                2 Запомнить SaleDetail
                                                                3 Проверить, что BatchID является открытой платежной линией для BrandAndBIN.

                                                              1. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown.


                                                              2. Если линия не открыта, отклонить платеж с CapCode = batchClosed


                                                                		3.
                                                                4 Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown.
                                                                <


                                                                /p> Расчетный центр формирует отклик CapRes согласно следующему алгоритму.

                                                                Шаг Действие
                                                                1 Получить данные о платеже от платежного процесса
                                                                2 Скопировать CapRRTags из CapReq
                                                                3 Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел.
                                                                4 Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE:

                                                              3. Вложить Cert-PE в цифровой конверт PKCS#7


                                                              4. Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью


                                                                		5.
                                                                5 Опционно занести в поле BatchSequenceNum состояние текущих платежных линий
                                                                6 Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload
                                                                7 Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом:

                                                              5. Скопировать TransIDs из соответствующего CapReqItem


                                                              6. Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется


                                                              7. Заполнить CapResPayload


                                                                		8.
                                                                8 Опционно заполнить CRsExtensions
                                                                9 Вставить сообщение в цифровой конверт и послать продавцу
                                                                Генерация CapResPayload осуществляется следующим образом.

                                                                Шаг Действие
                                                                1 Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem
                                                                2 Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem
                                                                3 Опционно заполнить CRsPayExtensions
                                                                Структура сообщения-отклика CapRes показана в таблице 4.6.2.70.



                                                                Таблица 4.6.2.70

                                                                . Структура CapRes



                                                                CapRes

                                                                		 Enc(P, M, CapResData)


                                                                CapResData

                                                                {

                                                                CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]}


                                                                CapRRTags

                                                                RRTag

                                                                >s; копируется из CapReq


                                                                BrandCRLIdentifier

                                                                		 Список текущих CRL для всех СА в области ответственности платежной системы СА.


                                                                PEThumb

                                                                		 Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается.


                                                                BatchStatusSeq

                                                                		 {BatchStatus +}


                                                                CapResItemSeq

                                                                		 {CapResItem +}

                                                                Заказ соответствует CapReq


                                                                CRsExtensions

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


                                                                BatchStatus

                                                                		 См. табл. 4.6.2.53.


                                                                CapResItem

                                                                		 {TransIDs, AuthRRPID, CapResPayload}


                                                                TransIDs

                                                                		 Копируется из соответствующего CapReq


                                                                AuthRRPID

                                                                		 RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq


                                                                CapResPayload

                                                                		 См. табл. 4.6.2.71.
                                                                <


                                                                /p> Структура данных CapResPayload представлена в таблице 4.6.2.71.



                                                                Таблица 4.6.2.71

                                                                . Структура CapResPayload



                                                                CapResPayload

                                                                		 {CapCode, CapAmt, [BatchID], [BatchSequenceNum],

                                                                [CRsPayExtensions]}


                                                                CapCode

                                                                		 Цифровой код, указывающий на состояние платежа


                                                                CapAmt

                                                                		 Копируется из соответствующего CapReq


                                                                BatchID

                                                                		 Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq


                                                                BatchSequenceNum

                                                                		 Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq


                                                                CRsPayExtensions

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

                                                                Шаг Действие
                                                                1 Извлекается отклик из входного сообщения
                                                                2 Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается
                                                                3 Извлекается запись транзакции и производится сравнение CapRRTags:

                                                              8. Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID


                                                              9. Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID


                                                                		10.
                                                                4 Если в сообщение включен BrandCRLIdentifier, запомнить все CRL.
                                                                5 Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата.
                                                                6 Для каждого CapResItem в CapResSeq:

                                                              10. Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается.


                                                              11. Обработать CapCode для получения результата операции


                                                              12. Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID.


                                                                		13.
                                                                7 Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus
                                                                <


                                                                /p> В таблице ниже представлены допустимые значения CapCode.

                                                                success Платежная позиция обработана расчетным центром успешно
                                                                unspecifiedFailure Причина неудачи неизвестна
                                                                duplicateRequest Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID)
                                                                authExpired Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты.
                                                                authDataMissing В платежном запросе отсутствует авторизационная информация
                                                                invalidAuthData Авторизационная информация для данной транзакции некорректна
                                                                capTokenMissing Для обработки данной позиции необходимо поле CapToken, а его нет
                                                                invalidCapToken Поле CapToken некорректно для данной транзакции
                                                                batchUnknown Расчетный центр не знает о существовании платежной линии для данной позиции
                                                                batchClosed Платежная линия для данной позиции закрыта
                                                                unknownXID Не распознан идентификатор XID
                                                                unknownLID Не распознан идентификатор LID
                                                                Сообщения отзыва платежа и кредита синтактически идентичны и выполняют сходную функцию. Алгоритм формирования информационной структуры CapRevOrCredReqData продавцом представлен ниже.

                                                                Шаг Действие
                                                                1 Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой.
                                                                2 Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром.
                                                                3 Заполнить одну или более позиций в CredRevOrCredReqItems:

                                                              13. Скопировать TransIDs из соответствующего CapRes.


                                                              14. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется.


                                                              15. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq).


                                                              16. Заполнить NewBatchID, если кредитная линия транзакции закрыта.


                                                              17. Заполнить CapRevOrCredReqData с текущей датой и временем


                                                              18. Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload.


                                                              19. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken.


                                                              20. Опционно заполнить CRvRqItemExtensions


                                                                		21.
                                                                4 Опционно заполнить CRvRqExtensions
                                                                <


                                                                /p> Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72.



                                                                Таблица 4.6.2.72

                                                                . Структура CapRevOrCredReqData



                                                                CapRevOrCredReqData

                                                                		 {CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]}


                                                                CapRevOrCredRRTags

                                                                		 RRTags.

                                                                Новый идентификатор RRPID и Date для данной пары.


                                                                MThumbs

                                                                		 Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца


                                                                CapRevOrCredReqItemSeq

                                                                		 {CapRevOrCredReqItem +}

                                                                Один или более CapRevOrCredReqItem в виде упорядоченного массива


                                                                CRvRqExtensions

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


                                                                CapRevOrCredReqItem

                                                                		 {TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]}


                                                                TransIDs

                                                                		 Копируется из соответствующего CapRes.

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


                                                                CapPayload

                                                                		 См. табл. 4.6.2.69


                                                                NewBatchID

                                                                		 Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию.


                                                                CapRevOrCredReqDate

                                                                		 Дата подачи запроса


                                                                CapRevOrCredReqAmt

                                                                		 В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload


                                                                NewAccountInd

                                                                		 Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца.


                                                                CRvRqItemExtensions

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


                                                                /p> Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.

                                                                Шаг Действие
                                                                1 Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается.
                                                                2 Обрабатывается каждое CapRevOrCredItem:

                                                              21. Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions


                                                              22. Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem




                                                                  1. Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID.


                                                                  2. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID


                                                                1. Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch.


                                                                2. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown.


                                                                3. Запоминается CapRevOrCredAmt


                                                                4. Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети.


                                                                  		5.
                                                                  3 На основе TransIDs в AuthRevTags извлекается запись транзакции.
                                                                  Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.

                                                                  Шаг Действие
                                                                  1 Заполнить поле CapRevOrCredTags
                                                                  2 Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел.
                                                                  3 Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то:

                                                                5. Ввести Cert-PE в цифровой конверт PKCS#7


                                                                6. Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью


                                                                  		7.
                                                                  4 Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено.
                                                                  5 Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом:

                                                                7. Скопировать TransIDs из соответствующего CapRevOrCredReqItem


                                                                8. Если доступно, скопировать RRPID из соответствующего CapRevOrCredItem


                                                                  9. Заполнить CapRevOrCredResPayload следующим образом:



                                                                    1. Занести в CapRevOrCredCode результат кредита или отзыва платежа


                                                                    2. Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва


                                                                    3. Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem


                                                                    4. Опционно заполнить CRvRsPayExtensions
                                                                    6 Опционно заполнить CRvRsExtensions
                                                                    <


                                                                    /p> Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73.



                                                                    Таблица 4.6.2.73

                                                                    . Структура CapRevOrCredResData

                                                                    CapRevOrCredResData {CapRevOrCredRRTags, [BrandCRLIdentifier],

                                                                    [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions]
                                                                    CapRevOrCredRRTags RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData
                                                                    BrandCRLIdentifier Список текущих CRL для всех СА в зоне ответственности СА платежной системы.
                                                                    PEThumb Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается
                                                                    BatchStatusSeq {BatchStatus +}
                                                                    CapRevOrCredResItemSeq {CapRevOrCredResItem +}

                                                                    Один или более CapRevOrCredResItem в упорядоченном массиве
                                                                    CRvRsExtensions Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром
                                                                    BatchStatus См. табл. 4.6.2.53.
                                                                    CapRevOrCredResItem

                                                                    {TransIDs, AuthRRPID, CapRevOrCredResPayload}
                                                                    TransIDs Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags
                                                                    AuthRRPID RRPID, который появляется в соответствующем AuthReq или >AuthRevReq
                                                                    CapRevOrCredResPayload См. табл. 4.6.2.74
                                                                    Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74.



                                                                    Таблица 4.6.2.74

                                                                    . Структура CapRevOrCredResPayload

                                                                    CapRevOrCredResPayload {CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]}
                                                                    CapRevOrCredCode Числовой код, характеризующий состояние отзыва платежа или кредита.


                                                                    CapRevOrCredActualAmt

                                                                    		 Копируется из соответствующего CapRevOrCredReqItem.


                                                                    BatchID

                                                                    		 Идентификатор платежной линии сделки для банка продавца


                                                                    BatchSequenceNum

                                                                    		 Порядковый номер позиции в последовательности платежей


                                                                    CRvRsPayExtensions

                                                                    		 Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит.
                                                                    <


                                                                    /p> Допустимые значения кода CapRevOrCredCode представлены ниже

                                                                    success Позиция была успешно обработана расчетным центром
                                                                    unspecifiedFailure Причина неудачи не специфицирована
                                                                    duplicateRequest Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID)
                                                                    originalProcessed Запрос платежа для данной позиции был уже обработан
                                                                    originalNotFound Специфицированная позиция расчетным центром не обнаружена
                                                                    capPurged Информация о платеже была удалена из памяти транзакций расчетного центра
                                                                    missingCapData Информация о платеже отсутствует в запросе отзыва платежа или кредита
                                                                    missingCapToken Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита
                                                                    invalidCapToken Маркер CapToken некорректен
                                                                    batchUnknown Платежная линия для данной позиции расчетному центру неизвестна
                                                                    batchClosed Платежная линия для данной позиции уже закрыта
                                                                    Обработка продавцом CapRevOrCredResData осуществляется следующим образом.

                                                                    Шаг Действие
                                                                    1 Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension.
                                                                    2 Обработать CapRevOrCredTags
                                                                    3 Извлечь запомненную запись транзакции и обработать TransIDs следующим образом:

                                                                  1. Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID


                                                                  2. Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.


                                                                    		3.
                                                                    4 Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
                                                                    5 Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата.
                                                                    6 Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат
                                                                    7 Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом

                                                                  3. Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension


                                                                  4. Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID


                                                                  5. Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.


                                                                  6. Обработать CapRevOrCredPayload следующим образом:




                                                                      1. Обработать CapRevOrCredCode для получения результата


                                                                      2. Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt


                                                                      3. Обработать BatchID и BatchSequenceNum, если таковые имеются
                                                                      <


                                                                      /p> Пара сообщений CapRevReq/ CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75.



                                                                      Таблица 4.6.2.75

                                                                      . Структура CapRevReq

                                                                      CapRevReq <EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)>

                                                                      CapTokenSeq является внешним “багажом”.

                                                                      Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq
                                                                      CapRevData

                                                                      CapRevOrCredReqDat

                                                                      a
                                                                      CapTokenSeq {[CapToken] +}

                                                                      Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в

                                                                      CapRevOrCredReqData.CapRevOrCredReqItemSeq.

                                                                      Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL)
                                                                      PANToken См. табл. 4.6.2.46
                                                                      CapToken Копируется из соответствующего AuthRes или AuthRevRes
                                                                      Структура отклика показана ниже CapRevRes.

                                                                      CapRevRes Enc(P,M, CapRevResData)
                                                                      CapRevResData CapRevOrCredResData
                                                                      Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.

                                                                      Шаг Действие
                                                                      1 Генерируется информация CredReqData
                                                                      2 Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом:

                                                                    1. Если доступно, записать CapToken для соответствующей транзакции.


                                                                    2. В противном случае (если недоступно), записать NULL.


                                                                      3. Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq
                                                                      3 Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции.

                                                                      Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq
                                                                      4 Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию.
                                                                      5 Вставить сообщение в цифровой конверт и послать владельцу карты
                                                                      <


                                                                      /p> Структура запроса CredReq показана в таблице 4.6.2.76.



                                                                      Таблица 4.6.2.76.

                                                                       Структура CredReq

                                                                      CredReq

                                                                      <

                                                                      EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)>

                                                                      CapTokenSeq является внешним “багажом”.

                                                                      Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS
                                                                      CredReqData

                                                                      CapRevOrCredReqData



                                                                      ; см. табл. 4.6.2.72.
                                                                      CapTokenSeq {[CapToken] +}

                                                                      Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq.

                                                                      Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL
                                                                      PANToken См. табл. 4.6.2.46
                                                                      CapToken Копируется из соответствующего AuthResили AuthRevRes
                                                                      Расчетный центр обрабатывает полученный CredReq следующим образом.

                                                                      Шаг Действие
                                                                      1 Извлекается запрос из входного сообщения
                                                                      2 Для каждой позиции, для которой продавец получил маркер CapToken:

                                                                    3. Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing


                                                                    4. Проверяется CapToken


                                                                      		5.
                                                                      3 Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem.
                                                                      Формирование CredRes осуществляется в следующей последовательности.

                                                                      Шаг Действие
                                                                      1 Получить отклик из финансовой сети платежной карты
                                                                      2 Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе
                                                                      3 Включить Enc-инкапсуляцию для полученных результатов
                                                                      4 Поместить сообщение в цифровой конверт и отправить владельцу карты
                                                                      Формат отклика CredRes представлен ниже.

                                                                      CredRes Enc(P, M, CredResData)
                                                                      CredResData

                                                                      CapRevOrCredResData

                                                                      ; см. табл. 4.6.2.74.
                                                                      Продавец обрабатывает CredRes за два шага:



                                                                          1. Получается отклик CredRes из входного сообщения




                                                                          2. Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму.


                                                                          Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита. Формирование запроса CredRevReq осуществляется следующим образом.

                                                                          Шаг Действие
                                                                          1 Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq
                                                                          2 Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом:

                                                                        1. Если доступен, занести CapToken для соответствующей транзакции


                                                                        2. В противном случае, если маркер не доступен, записать NULL


                                                                          		3.
                                                                          3 Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции.

                                                                          Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq.
                                                                          4 Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию.
                                                                          5 Вставить сообщение в цифровой конверт и направить владельцу карты
                                                                          Структура запроса CredRevReq показана в таблице 4.6.2.77.

                                                                          Таблица 4.6.2.77. Структура CredRevReq

                                                                          CredRevReq <EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)>

                                                                          CapTokenSeq является внешним “багажом”.

                                                                          Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq.
                                                                          CredRevReqData CapRevOrCredReqData; см. табл. 4.6.2.72
                                                                          CapTokenSeq {[CapToken] +}

                                                                          Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq.

                                                                          Заметим, что любой CapToken может быть опущен, т.е. может быть NULL
                                                                          PANToken См. табл. 4.6.2.46
                                                                          CapToken Копируется из соответствующего AuthRes или AuthRevRes
                                                                          Расчетный центр обрабатывает запрос CredRevReq следующим образом.

                                                                          Шаг Действие
                                                                          1 Выделить запрос из входного сообщения
                                                                          2 Для каждой позиции, для которой продавец получил CapToken:

                                                                        3. Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing


                                                                        4. Проверить CapToken


                                                                          		5.
                                                                          3 Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem
                                                                          <


                                                                          /p> Формирование отклика CredRevRes осуществляется в следующей последовательности.

                                                                          Шаг Действие
                                                                          1 Получить отклик из финансовой сети платежной карты
                                                                          2 Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе.
                                                                          3 Включить для полученного результата Enc-инкапсуляцию
                                                                          4 Вложить отклик в цифровой конверт и отправить владельцу карты
                                                                          Отклик CredRevRes имеет достаточно простой формат:



                                                                          CredRevRes

                                                                          		 Enc(P, M, CredRevResData)


                                                                          CredRevResData

                                                                          		 CredRevOrCredResData; См. табл. 4.6.2.74.
                                                                          Продавец обрабатывает полученный отклик следующим образом

                                                                          Шаг Действие
                                                                          1 Извлекается отклик из входного сообщения
                                                                          2 Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа.
                                                                          Обработка запроса сертификата расчетного центра включает в себя два сообщения, запрос от продавца к расчетному центру и отклик последнего, направляемый продавцу. В запросе продавец просит расчетный центр прислать ему сертификат, который необходим для последующего шифрования сообщений от продавца к расчетному центру. Сертификат присылается в сообщении-отклике. Генерация запроса PCertReq выполняется в следующей последовательности.

                                                                          Шаг Действие
                                                                          1 Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52.
                                                                          2 Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра.
                                                                          3 Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты:

                                                                        5. Заполнить поле BrandID


                                                                        6. Опционно заполнить поле BIN


                                                                          		7.
                                                                          4 Опционно заполнить поле PCRqExtensions
                                                                          5 Ввести S (см. описание оператора подпись выше)
                                                                          6 Вложить сообщение в цифровой конверт и отправить владельцу карты
                                                                          <


                                                                          /p> Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.

                                                                          PCertReq S(M, PCertReqData)
                                                                          PCertReqData {PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]}
                                                                          PCertTags RRTags.

                                                                          Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата
                                                                          MThumbs Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца.
                                                                          BrandAndBINSeq {BrandAndBIN +}

                                                                          Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs
                                                                          PCRqExtensions Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации
                                                                          BrandAndBIN {BrandID, [BIN]}
                                                                          BrandID Платежная система карты (без указания типа).
                                                                          BIN Идентификационный номер банка для обработки транзакции продавца в расчетном центре.


                                                                          Таблица 4.6.2.78

                                                                          . Структура сообщения PCertReq

                                                                          Расчетный центр обрабатывает PCertReq следующим образом

                                                                          Шаг Действие
                                                                          1 Расчетный центр получает PCertReq из входного сообщения
                                                                          2 Обрабатываются расширения PCRqExtensions. Если встречается нераспознанное расширение, помеченное как критическое, прислается отклик unrecognizedExtensions, а PCertReq отбрасывается.
                                                                          3 Обрабатывается BrandIDSeq и MThumbs
                                                                          4 Формируется и посылается PCertRes
                                                                          Формирование PCertRes осуществляется в следующей последовательности

                                                                          Шаг Действие
                                                                          1 Скопировать PCertTags из PCertReq в PCertRes
                                                                          2 Для каждого BrandAndBIN в BrandIDSeq из PCertReq:

                                                                        7. Если доступен корректный сертификат:




                                                                            1. Заполнить соответствующий сертификат шифрования расчетного центра Cert-PE


                                                                            2. Занести в PCertCode, соответствующий PCertResItem c “успешным” кодом PCertCode


                                                                            3. Занести в CertThumb оттиск присланного сертификата


                                                                          1. В противном случае, если сертификаты недоступны, так как не поддерживается данная платежная система, занести PCertCode, соответствующего PСertResItem c кодом PCertCode = brandUnsupported и опустить CertThumb


                                                                          2. В противном случае, если платежная система поддерживается, но BIN неизвестен, занести в поле PCertCode соответствующего PсertResItem код PCertCode = unknownBIN и опустить CertThumb


                                                                          3. В противном случае занести в поле PCertCode соответствующего PCertResItem код PCertCode = unspecifiedFailure

                                                                            и опустить CertThumb


                                                                            		4.
                                                                            3 Для каждой платежной системы, для которой необходим сертификат, прислать текущее значение BrandCRLIdentifier, если только Mthumbs не содержит оттиска для текущего BrandCRLIdentifier
                                                                            4 Опционно заполнить PCRqExtensions
                                                                            <


                                                                            /p> Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79.



                                                                            Таблица 4.6.2.79.

                                                                             Структура PCertRes

                                                                            PCertRes S(P, PCertResTBS)
                                                                            PCertResTBS {PCertTags, [BrandCRLIdentifierSeq], PCertResItems, [PCRsExtensions]}
                                                                            PCertTags

                                                                            RRTag

                                                                            s; копируется из PCertReq.
                                                                            BrandCRLIdentifierSeq {BrandCRLIdentifier +}
                                                                            PCertResItems {PCertResItem +}

                                                                            Один или более статусных кодов и оттисков сертификатов, которые возвращаются в соответствии один к одному с PCertReq.BrandAndBINSeq
                                                                            PCRsExtentions Сертификатный отклик расчетного центра не шифруется, по этой причине данное расширение не должно содержать конфиденциальных данных.
                                                                            BrandCRLIdentifier Список текущих CRL для всех CA в зоне ответственности CA платежной системы. См. раздел о BrandCRLIdentifier
                                                                            PCertResItem {PCertCode, [CertThumb]}
                                                                            PCertCode Цифровой код, указывающий результат PCertReq
                                                                            CertThumb Оттиск возвращенного сертификата
                                                                            Продавец обрабатывает PCertRes следующим образом.

                                                                            Шаг Действие
                                                                            1 Извлекается отклик из входного сообщения
                                                                            2 Обрабатываются PCRsExtensions. Если встречается нераспознанное расширение, помеченное как критическое, присылается отклик unrecognizedExtensions и отбрасывается PCertRes
                                                                            3 Извлекаются сертификаты из Cert-PE
                                                                            4 Проверяются сертификаты в Cert-PE путем сравнения их с CertThumbs в PCertResItems. Отбрасываются все сертификаты, которые не прошли сверку.
                                                                            5 Обработатывается каждый BrandCRLIdentifier из присланной последовательности таких идентификаторов.
                                                                            6 Продолжается обработка сообщений, которые ожидали сертификатов, присланных в PCertRes.
                                                                            Стандартизованы следующие значения PcertCode, собранные в таблице 4.6.2.80.



                                                                            Таблица 4.6.2.80

                                                                            . Значения PCertCode

                                                                            success Запрос обработан успешно
                                                                            unspecifiedFailure Запрос не прошел из-за неспецифицированной причины
                                                                            brandNotSupported Запрос не прошел из-за того, что платежная система, специфицированная в PCertReq, не поддерживается
                                                                            unknownBIN Запрос не прошел из-за того, что BIN, специфицированный в PCertReq, не поддерживается.
                                                                            <


                                                                            /p>

                                                                            Управление платежными линиями (Batch)



                                                                            Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные.

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

                                                                            Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия.

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



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

                                                                            Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.

                                                                            Шаг Действие
                                                                            1 Если это первое сообщение, направленное расчетному центру после получения нового секретного ключа, или если это первое сообщение в данный день, в цифровой конверт этого сообщения следует вложить сертификаты для секретных ключей и цепочку сертификатов платежной системы, выбранных продавцом для подписи и шифрования сообщений BatchAdmin.
                                                                            2 Сформировать RRTags
                                                                            3 Если новая платежная линия открыта:

                                                                          4. Установить BatchOperation = open


                                                                          5. Занести в поле BatchID идентификатор для неиспользуемой платежной линии.


                                                                          6. Опционно занести в поле BrandAndBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые могут появиться в данной группе платежей.


                                                                          7. Установить ReturnBatchSummeryIndicator = FALSE


                                                                          8. Опустить все остальные поля сообщения


                                                                            		9.
                                                                            4 Если платежная линия (группа платежей) пуста:

                                                                          9. Установить BatchOperation = purged


                                                                          10. Занести в BatchID идентификацию для неиспользуемой платежной линии


                                                                          11. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы платежей.


                                                                          12. Установить ReturnBatchSummeryIndicator = FALSE


                                                                          13. Опустить все остальные поля сообщения


                                                                            		14.
                                                                            5 Если платежная линия закрыта:

                                                                          14. Установить BatchOperation = closed


                                                                          15. Занести в BatchID идентификацию для открытой платежной линии


                                                                          16. Установить ReturnBatchSummeryIndicator = FALSE


                                                                          17. Опустить все остальные поля сообщения


                                                                            		18.
                                                                            6 Если нужно запросить состояние платежной линии у расчетного центра:

                                                                          18. Опустить BatchOperation


                                                                          19. Занести в BatchID идентификацию для платежной линии


                                                                          20. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить объем статусной информации, возвращаемой в BatchAdminRes.


                                                                          21. Установить ReturnBatchSummeryInd = TRUE


                                                                          22. Опустить все остальные поля сообщения


                                                                            		23.
                                                                            7 Если нужно запросить детальные данные о платежной линии у расчетного центра:

                                                                          23. Опустить BatchOperation


                                                                          24. Занести в BatchID идентификацию платежной линии


                                                                          25. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы (платежной линии).


                                                                          26. Если необходима итоговая информация платежной линии, установить ReturnBatchSummeryInd = TRUE, в противном случае = FALSE


                                                                          27. Если это первый (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить StartingPoint равным значению NextSequence, полученному в предшествующем отклике BatchAdminRes для данной последовательности.


                                                                          28. Занести MaximumItems наибольший номер позиции, которую нужно послать в BatchAdminRes


                                                                          29. Опустить все остальные поля сообщения


                                                                            		30.
                                                                            8 Если нужно послать состояние платежной линии расчетному центру:

                                                                          30. Опустить BatchOperation


                                                                          31. Занести в BatchID идентификацию для платежной линии


                                                                          32. Опустить BrandandBIN


                                                                          33. Установить ReturnBatchSummeryInd = FALSE


                                                                          34. Сформировать BatchStatus:




                                                                                    1. Занести в поле BatchTotals значения для всех транзакций данной группы (batch)


                                                                                    2. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.


                                                                                    f) Опустить все остальные поля сообщения
                                                                                    9 Если нужно передать расчетному центру детальные данные о платежной линии:

                                                                                  1. Опустить BatchOperation


                                                                                  2. Занести в BatchID идентификацию для платежной линии


                                                                                  3. Опустить BrandandBIN


                                                                                  4. Установить ReturnBatchSummeryInd = FALSE


                                                                                  5. Если это последний (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить NextStartingPoint равным значению, позволяющему расчетному центру проверить, что группа платежей принята в правильной последовательности.


                                                                                  6. Заполнить TransactionDetail для набора позиций платежной линии.


                                                                                  7. Если NextStartingPoint = 0, опционно сформировать BatchStatus:




                                                                                      1. Занести в BatchTotals значения для всех транзакций платежной линии.


                                                                                      2. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.


                                                                                      h) Если продавец хочет прервать передачу BranchBatchDetails, установить значение поля MaximumItem равным 0, в противном случае опустить это поле.
                                                                                      10 Реализовать операцию подписи для результата шагов 1-9, используя сертификат подписи продавца для любой платежной системы, известной расчетному центру.
                                                                                      11 Включить сертификат шифрования продавца для той же платежной системы, что была выбрана на предшествующем шагу. Общедоступный ключ этого сертификата будет использоваться расчетным центром при дешифровке сообщений BatchAdminRes.
                                                                                      12 Зашифровать BatchAdminReqTBE, используя сертификат расчетного центра и установить тип содержимого равным id-set-content-BatchAdminReqTBE.
                                                                                      13 Вложить сообщение в цифровой конверт и послать владельцу карты
                                                                                      <


                                                                                      /p> Структура запроса BatchAdminReq представлена в таблице 4.6.2.81.



                                                                                      Таблица 4.6.2.81

                                                                                      . Структура BatchAdminReq

                                                                                      BatchAdminReq Enc(M, P, BatchAdminReqData)
                                                                                      BatchAdminReqData {BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]}
                                                                                      BatchAdminRRTags RRTags.

                                                                                      Новый идентификатор RRPID и Date (дата)
                                                                                      BatchID Идентификатор платежной линии для счета банка продавца
                                                                                      BrandAndBINSeq {BrandAndBIN +}
                                                                                      BatchOperation Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии
                                                                                      ReturnBatchSummaryInd Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные.
                                                                                      ReturnTransactionDetail {StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]}

                                                                                      Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты.
                                                                                      BatchStatus См. табл. 4.6.2.53.
                                                                                      TransDetails {NextStartingPoint, TransactionDetailSeq}
                                                                                      BARqExtensions Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов.
                                                                                      BrandAndBIN {BrandID, [BIN]}
                                                                                      StartingPoint Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes
                                                                                      MaximumItems Максимальное число позиций, которые следует прислать в этой группе.
                                                                                      ErrorsOnlyInd Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки.
                                                                                      BrandID Тип платежной системы (без указания типа продукта).
                                                                                      NextStartingPoint Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций.
                                                                                      TransactionDetailSeq {TransactionDetail +}
                                                                                      BIN Идентификационный номер банка для обработки транзакций продавца.
                                                                                      TransactionDetail См. табл. 4.6.2.54
                                                                                      Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.

                                                                                      Шаг Действие
                                                                                      1 Выделить запрос из входного сообщения
                                                                                      2 Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure.
                                                                                      3 Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID.
                                                                                      4 Если BatchOperation = open:

                                                                                    1. Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen.


                                                                                    2. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.


                                                                                    3. Если имеется BrandIDSeq:




                                                                                        1. Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported.


                                                                                        2. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN.


                                                                                        3. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии.


                                                                                      1. Открыть платежную линию для использования продавцом и установить BAStatus = success.


                                                                                      2. Продолжить процесс посылкой BatchAdminRes


                                                                                        3. Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open.
                                                                                        5 Если BatchOperation = purge:

                                                                                      3. Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.


                                                                                      4. Если BrandIDSeq присутствует:




                                                                                          1. Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.


                                                                                          2. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.


                                                                                          3. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN.


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


                                                                                        2. Установить BAStatus = success


                                                                                        3. Продолжить работу посылкой сообщения BatchAdminRes


                                                                                          4. Любые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge.
                                                                                          6 Если BatchOperation = close:

                                                                                        4. Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.


                                                                                        5. Установить BAStatus = success


                                                                                        6. Продолжить работу посылкой сообщения BatchAdminRes


                                                                                          7. Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close.
                                                                                          7 Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE:

                                                                                        7. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.


                                                                                        8. Если BrandAndBIN включен:


                                                                                        9. Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.


                                                                                        10. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.


                                                                                        11. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN.


                                                                                        12. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями.


                                                                                        13. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes.


                                                                                        14. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу.


                                                                                          15. NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE.
                                                                                          8 Если включено поле StartingPoint:

                                                                                        15. Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.


                                                                                        16. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.


                                                                                        17. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes.


                                                                                        18. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint.


                                                                                        19. Если имеется BrandAndBIN:




                                                                                            1. Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.


                                                                                            2. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.


                                                                                            3. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd.


                                                                                            f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
                                                                                            9 Если код BatchOperation опущен, а BatchStatus имеется:

                                                                                          1. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.


                                                                                          2. Если имеется поле BrandBatchDetails:




                                                                                              1. Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.


                                                                                              2. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.


                                                                                              3. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN.


                                                                                            1. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует.


                                                                                            2. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus.


                                                                                            3. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту.


                                                                                            4. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes


                                                                                              		5.
                                                                                              10 Если код BatchOperation опущен и включено поле TransactionDetails:

                                                                                            5. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.


                                                                                            6. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint.


                                                                                            7. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes.


                                                                                            8. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes.


                                                                                            9. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes.


                                                                                            10. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.


                                                                                              11. Последовательность BrandAndBIN игнорируется.
                                                                                              <


                                                                                              /p> Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.

                                                                                              Шаг Действие
                                                                                              1 Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом.
                                                                                              2 Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData.
                                                                                              3 Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE.
                                                                                              4 Вложить сообщение в цифровой конверт и послать владельцу карты.
                                                                                              Структура отклика BatchAdminRes представлена в таблице 4.6.2.82.



                                                                                              Таблица 4.6.2.82

                                                                                              . Структура BatchAdminRes



                                                                                              BatchAdminRes

                                                                                              		 Enc(P, M, BatchAdminResData)


                                                                                              BatchAdminResData

                                                                                              		 {BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]}


                                                                                              BatchAdminTags

                                                                                              		 RRTags; копируется из предшествующего BatchAdminReq


                                                                                              BatchID

                                                                                              		 Идентификатор платежной линии между продавцом и его банком.


                                                                                              BAStatus

                                                                                              		 Числовой код, указывающий на состояние открытой платежной линии.


                                                                                              BatchStatus

                                                                                              		 См. табл. 4.6.2.53.


                                                                                              TransmissionStatus

                                                                                              		 Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня


                                                                                              SettlementInfo

                                                                                              		 {SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate}


                                                                                              TransDetails

                                                                                              		 {NextStartingPoint, TransactionDetailSeq}


                                                                                              BARsExtensions

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

                                                                                              Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail.


                                                                                              SettlementAmount

                                                                                              		 Занесенная через сеть на счет продавца сумма


                                                                                              SettlementType

                                                                                              		 Числовой код, указывающий тип суммы


                                                                                              SettlementAccount

                                                                                              		 Счет продавца


                                                                                              SettlementDepositDate

                                                                                              		 Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца


                                                                                              NextStartingPoint

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


                                                                                              TransactionDetailSeq

                                                                                              		 {TransactionDetail +}


                                                                                              TransactionDetail

                                                                                              		 См. табл. 4.6.2.54..
                                                                                              <


                                                                                              /p> В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID

                                                                                              unspecified Неизвестное значение
                                                                                              standard Стандартная скорость обмена
                                                                                              keyEntered Скорость обмена для транзакций key-entered (ввод с клавиатуры)
                                                                                              electronic Скорость обмена для электронных транзакций
                                                                                              additionalData Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные
                                                                                              enhancedData Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации).
                                                                                              marketSpecific Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт).
                                                                                              Продавец получает и обрабатывает BatchAdminRes следующим образом.

                                                                                              Шаг Действие
                                                                                              1 Извлекается отклик BatchAdminRes из входного сообщения.
                                                                                              2 Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed.
                                                                                              3 Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID.
                                                                                              4 Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны.
                                                                                              5 Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы.
                                                                                              6 Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin.
                                                                                              7 Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца.
                                                                                              <


                                                                                              /p> Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet (http://www.microsoft.com/commerce/wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$.

                                                                                              Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash (http://www.digicash.nl) или Millicent -

                                                                                              http://www.millicent.digital.com/                                                                                              ). Схема First Virtual (http://www.fv.com) предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон.

                                                                                              Система CyberCash (http://www.cybercash.com) базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши “оплатить”. Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций.


                                                                                              Содержание раздела