Аннулирование операции
Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).
Аннулирование транзакции
Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP. Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:
если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,
если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,
определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру.
Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать.
Аннулирование транзакций
Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен.
Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли.
Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене.
Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца.
Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка.
После аннулирования транзакции IOTP, Покупатель должен обратиться в сетевую позицию, специфицированную атрибутом CancelNetLocn, содержащимся в элементе торговой роли для организации, которой был послан блок Cancel. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:
| о | после получения блока запроса; |
| o | до посылки блока отклика. |
Если торговая роль, отличная от Покупателя, аннулирует транзакцию в любое другое время, это должно восприниматься получателем, как ошибка.
Аннулированные транзакции
Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент.
Аутентификация и идентификация личности
Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для "персон" покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой.
В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ.
Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту.
Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.
Аутентификационный обмен
Целью аутентификационного обмена является допущение одной организации, например, финансовому учреждению, иметь возможность проверить, что другая организация, например Покупатель, является тем, за кого себя выдает.
В аутентификационный обмен вовлечены:
Аутентификатор - организация, запрашивающая аутентификацию и
Аутентифицируемый - организация, которая должна быть аутентифицирована.>
Это проиллюстрировано на диаграмме ниже.
| 1. | Первая организация, например покупатель, осуществляет действие (например, нажимает на клавишу на HTML-странице), которое требует, чтобы организация была аутентифицирована. |
| 1 а 2 | Запрос аутентификации (за пределами действия IOTP) |
| 2. | Вторая организация генерирует данные вызова и список алгоритмов, которые могут быть использованы для аутентификации и/или запрос данных об организации, после чего посылает все это первой организации. |
| 1 Я 2 | Запрос аутентификации. Компоненты: запрос аутентификации, запрос информации о торговых ролях. |
| 3. | Первая организация опционно проверяет любую подпись, связанную с запросом аутентификации, после чего использует специфицированный алгоритм аутентификации, чтобы сформировать отклик аутентификации, который посылается второй организации вместе с запрошенной информацией об организации. |
| 1 а 2 | Отклик аутентификации. Компонент: отклик аутентификации, организации |
| 4. | Отклик аутентификации проверяется согласно данным вызова для того чтобы выяснить является ли первая организация той, за которую себя выдает, результат записанный в компонент статус посылается первой организации. |
| 1 Я 2 | Статус аутентификации. Компонент: Статус |
| 5. | Первая организация опционно проверяет результаты, записанные в cтатус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру. |
Рис. .5. Обмен аутентификации
Обмен аутентификации использует следующие торговые компоненты, которыми обмениваются между собой две организации:
Компонент запрос аутентификации, который требует аутентификации, указывает, какой алгоритм аутентификации следует употребить.
Компонент запроса данных о торговых ролях, который требует информации об организации, например адрес.
Компонент отклик аутентификации, который содержит отклик на вызов, сформированный получателем компонента запроса аутентификации.
Компонент организации, который содержит результат запроса данных о торговых ролях.
Компонент статуса, который содержит результаты верификации отклика аутентификации второго партнера.
Базовая транзакция аутентификации
Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:
перед другой транзакцией IOTP;
одновременно с другой транзакцией;
независимо от каких-либо других транзакций.
Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на рис. .24.
Рис. .24. Базовая транзакция аутентификации
Пример, использующий базовую транзакцию аутентификации, включает в себя следующие процедуры:
когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:
| - сформировать безопасный канал связи с покупателем (напр., используя [SSL/TLS]); | |
| - аутентифицировать покупателя, используя базовую транзакцию аутентификации и затем; | |
- предоставить покупателю доступ к информации и другим услугам с конфиденциальностью, с которой они общаются с добросовестными клиентами. |
как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;
предоставление возможности аутентифицировать кассира до начала процедуры платежа.
Базовая транзакция депозита
Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации.
Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1);
документальный обмен предложения (смотри раздел 9.1.2) и
документальный обмен платежа (смотри раздел 9.1.3).
Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. .25.
Рис. .25. Базовая транзакция депозита
Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям.
Заметим, что:
Продавец (финансовая организация) может принять депозит в виде различных видов электронных платежей. Но покупатель, который собирается разместить депозит, обячно знает, каким видом электронного платежа он намерен воспользоваться, по этой причине все многообразие электронных платежей в каждом конкретном случае сводится к одной разновидности. Однако могут быть несколько протоколов, которые могут использоваться с одним и тем же видом электронного платежа. В этом случае предложение, зависимое от вида платежа, може подойти для согласования используемого протокола.
Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:
| - покупатель может специфицировать номер счета перед началом базовой транзакции депозита или | |
| - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией. |
Базовая IOTP-транзакция депозита без аутентификации может быть использована:
- если предыдущая транзакция, например, отзыва сделки или аутентификации уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента; | |
| - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен; | |
- если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом. |
Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями использует документальный обмен платежа, чтобы поддержать обмен ценностями в одной валюте с помощью одного метода оплаты и с привлечением той же или (обычно) другой валюты с помощью того же или иного платежного метода (встречный платеж). Примеры реализации такой процедуры включают в себя:
Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах.
Платежный обмен с заграничным субъектом посредством идентичных платежных методов. Например, один платеж может заключаться в снятии средств со счета в английских фунтах методом Mondex, а второй - предполагает внесение на счет денег в евро с помощью того же метода Mondex.
Платежный обмен с заграничным субъектом посредством различных платежных методов. Например, один платеж может осуществляться по протоколу SET в канадских долларах, а второй - методом GeldKarte в немецких марках.
Базовый обмен ценностями использует следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1);
документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и
два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа.
Способы, которыми эти документальные обмены комбинируются друг с другом изображены на рис. .29.
Рис. .29. Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями осуществляется в двух вариантах:
Обмен ценностями, зависящий от вида платежа. Где содержимое предложения, например курс по которому одна форма ценности обменивается на вторую, зависит от вида платежа и протокола, выбранного клиентом и
Обмен ценностями, независящий от вида платежа. Где содержимое предложения, не зависит от вида платежа и протокола, выбранного клиентом.
В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.
Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями.
Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме рис. .30.
Рис. .30. Подписи при обмене ценностями
Базовая транзакция отзыва платежа
Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации.
Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца - за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1)
документальный обмен предложения (смотри раздел 9.1.2) и
документальный обмен платежа (смотри раздел 9.1.3).
Способы, какими эти документальные обмены могут комбинироваться показаны на рис. .28.
Рис. .28. Базовая транзакция отзыва сделки
Заметим, что:
Продавец (финансовая организация) может предложить реализацию возврата средств различными видами электронных платежей. Однако может быть несколько различных протоколов для каждого из видов электронных платежей.
Продавец (финансовая организация) может использовать результаты аутентификации для того, чтобы идентифицировать не только покупателя, но счета, куда надлежит перевести возвращаемые средства. Если не удается идентифицировать один счет, используются другие средства. Например:
| - покупатель может специфицировать номер счета перед началом базовой транзакции отзыва или | |
| - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией. |
базовая транзакция отзыва может использоваться без аутентификации:
| - если предыдущая транзакция, например, депозит или аутентификация уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента; | |
| - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен; | |
| - если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом. |
Базовая транзакция Ping
Целью базовой транзакции IOTP Ping является проверка коннективности между торговыми ролями, принимающими участие в транзакции. Это позволяет приложению IOTP сделать следующее:
определить, работает ли приложение IOTP другой торговой роли;
проконтролировать, могут ли торговые роли работать с цифровыми подписями.
Например, эта транзакция может быть использована продавцом, чтобы определить, функционирует ли кассир или агент доставки, прежде чем запускать транзакцию, требующую участия этих торговых ролей.
Торговыми блоками, используемыми транзакцией Ping, являются:
блок запроса Ping (смотри раздел 8.14),
блок отклика Ping (смотри раздел 8.15) и
блок Signature (смотри раздел 8.16).
Сообщения PING
На рис. .33 отображен обмен сообщениями прибазовой транзакции Ping.
| 1. | Приложение IOTP первой торговой роли решает проверить, находится ли в рабочем состоянии соответствующее приложение партнера. Оно генерирует блок запроса Ping, опционный блок подписи и шлет их другой торговой роли. |
| 1 а 2 | Запрос PING. IotpMsg: блоки Trans Ref; подписи (опционный); запроса Ping |
| 2. | Вторая торговая роль, которая получает блок запроса Ping, генерирует блок отклика Ping и посылает его отправителю исходного запроса Ping, с блоком подписи, если это требуется. |
| 1 Я 2 | Отклик PING. IotpMsg: блоки Trans Ref; подписи (опционный); отклика Ping |
| 3. | Первая торговая роль проверяет блок отклика Ping и выполняет необходимые действия, если это требуется |
Рис. .33. Базовые сообщения транзакции Ping
Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса Ping путем включения:
компонентов Organisation, которые идентифицируют себя и предполагаемого получателя блока запроса Ping;
блок подписи, который гарантирует корректность и целостность запроса Ping.
Получатель запроса Ping таким образом:
знает, кто послал запрос Ping и может следовательно верифицировать подпись запроса;
знает, кто должен генерировать подпись отклика Ping.
Заметим, что запрос Ping:
не влияет на выполнение транзакций;
в отличии от других сообщений IOTP, таких как TPO или статусный запрос, не запускает новых транзакций IOTP.
Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении.
Базовый запрос IOTP Ping может также содержать опционный блок подписи.
Приложение IOTP может, например, использовать блок подписи для проверки того, способен ли получатель этого запроса формировать и верифицировать цифровые подписи. Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии. Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций. Блок ссылок транзакции IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других. Блок запроса PING Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7). Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для: отправителя блока запроса Ping;верификатора компонента подписи.
Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping. Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты: один компонент Signature (смотри раздел 7.19)один или более компонентов Certificate, если они требуются.
Блок отклика PING Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты: компонент Organisation отправителя сообщения-отклика Ping
Если транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит: копии компонентов Organisation, содержащиеся в блоке запроса Ping.
Блок SIGNATURE (отклик PING) Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты: один компонент Signature (смотри раздел 7.19);один или более компонентов Certificate, если они нужны.
Базовая транзакция покупки
Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1)
документальный обмен предложения (смотри раздел 9.1.2)
или:
| - документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует | |
| - документальный обмен доставки (смотри раздел 9.1.4) |
только документальный обмен платежа или
комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5).
Способы, какими эти документальные обмена могут комбинироваться показаны на рис. .26.
Рис. .26. Базовая транзакция покупки
Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12.
Базовая транзакция возврата денег
Процесс возврата денег обычно состоит из:
запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:
| - исходная сделка имела место, например, путем предоставления расписки для исходной транзакции; | |
| - используется некоторый вид аутентификации, чтобы показать, что субъект, запросивший возврат, действительно является покупателем, или представителем покупателя, который осуществлял исходную сделку; | |
- причину, почему продавец должен вернуть деньги. |
Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,
выполняется возврат денег продавцом покупателю.
Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:
отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)
возвратный платеж продавца покупателю с помощью следующих двух торговых обменов:
| - опционный документальный обмен аутентификации (смотри раздел 9.1.1) | |
| - документальный обмен предложения (смотри раздел 9.1.2) и | |
| - документальный обмен платежа (смотри раздел 9.1.3). |
Способы того, как эти документальные обмены взаимодействуют, показаны на рис. .27.
Рис. .27. Базовая транзакция возврата денег
Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:
когда аутентификация покупателя осуществлена как-то иначе, например, покупатель, чтобы идентифицировать себя ввел представленный ему ранее код. Код может может быть записан на WEB-странице или прислан по электронной почте.
когда предыдущая транзакция, например базовая аутентификация, идентифицировала покупателя, при этом используется безопасный канал гарантирует корректность предыдущей аутентификации.
когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.
Базовая транзакция запроса состояния транзакции IOTP
Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
торговый блок информационного запроса (смотри раздел 8.12),
торговый блок информационного отклика (смотри раздел 8.13)
опционный блок подписи (смотри раздел 8.16).
Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:
чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.
Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.
Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:
не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или
совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.
Базовыми требованиями являются:
Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:
| - Продавцу, после отправки блока выбора TPO, | |
| - Кассиру, после отправки блока платежного запроса, | |
| - Агенту доставки, после отправки блока запроса доставки, |
другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.
Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.
Технические ошибки в сообщении, содержащем сам блок информационного запроса.
Рабочие ошибки в исходных сообщениях
Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.
Технические ошибки в исходных сообщениях
Возврат блока информационного отклика, содержащего компонент Status.
Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка. Технические ошибки в блоке информационного запроса Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса. Сообщения информационого запроса транзакции На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.
| 1. | Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли. |
| 1 а2 | Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса |
| 2. | Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается |
| 1 Я 2 | Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный) |
| 3. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты: один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений. Блок подписи (информационный запрос) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос. Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты: один компонент Signature (смотри раздел 7.19)один или более компонентов сертификата, если таковые нужны. Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что: Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;другие торговые роли могут согласовать применение цифровых подписей, если это требуется. Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом. С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты: один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты. Блок SIGNATURE (отклик информационного запроса) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика. Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты: один компонент Signature (смотри раздел 7.19)один или более компонентов Certificate, если они нужны. Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов.В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что: Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;другие торговые роли могут договориться о том, что подпись необходима. Например, продавец может потребовать присылки подписанного информационного отклика от кассира.
BC- отклик подключения кредитной карты (bind-credit-card-response)
Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
#####################################################################
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: mycybercashid
transaction: 12312314
date: 19950121100505.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Ключ сессии от BC1 и ID
#####################################################################
Содержимое скрытой секции:
type: bind-credit-card-response
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; message about obsoleteness of customer software to be shown to the customer. [only resent if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Простой текст для пользователя может содержать много строк.
Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.
BC- подключение кредитной карты (Bind-Credit-card)
Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Формируется из ключа шифрования CyberCash идентифицированного в CyberKey
#####################################################################
Содержимое скрытой секции:
type: bind-credit-card
swversion: 0.8win
card-number: 1234567887654321
card-type: mastercard
card-salt: 46735210
card-expiration-date: 05/99
card-name: John Q. Public
card-street:
card-city:
card-state:
card-postal-code:
card-country:
signature:
tX3odBF2xPHqvhN4KVQZZBIXDveNi0eWA7717DNfcyqh2TpXqgCxlDjcKqdJXgsNLkY7
GkyuDyTF/m3SZif64giCLjJRKg0I6mqI1k/Dcm58D9hKCUttz4rFWRqhlFaj
#####################################################################
Подпись покрывает следующие поля: id, date, transaction, cyberkey, type, swversion, card-number, card-salt, card-expiration-date, card-name, card-street, card-city, card-state, card-postal-code, card-country
#####################################################################
Объяснение:
salt необходимо из-за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.
Безопасность платежного протокола
IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу.
IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например IOTP связывает вместе: предложение, платеж и доставку.
Безопасные и небезопасные позиции в сети
IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:
"Безопасные" сетевые позиции, где конфиденциальность данных гарантируется с помощью, например, некоторых методов шифрования, таких как [SSL/TLS].
"Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется.
Заметим, что должны присутствовать безопасна33я или не3безопасная сетевая позиция (Net Location) или обе обязательно.
Если присутствует одна из двух сетевых позиций, только она и может использоваться. Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.
Безопасный обмен сообщениями
Целью безопасного обмена сообщениями является обеспечение конфиденциальности, целостность данных и аутентификация отправителя. Принято два формата сообщений.
Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code).
Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4.
Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.
Рис. 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями
Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт.
В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт.
Вычисление s байтов МАС (4?s?8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC.
Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено.
При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется).
В случае формата 2 сообщение формируется согласно спецификации используемой платежной схемы.
Но оно всегда содержит заголовок команды APDU. Если МАС специфицирован, как имеющий длину менее 8 байтов, он получается из старших (левых) байтов 8-байтного результата его вычисления. Формат зашифрованных командных данных показан на рисунке 4.6.4.14.
| Тэг | Длина | Значение |
| T | L | Криптограмма (зашифрованные данные) |
| Значение 1 | Значение 2 |
| Криптограмма (зашифрованные данные) | МАС (если имеется) |
Оглавление:
Вперёд:
Безопасный протокол электронных платежей 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 помогает реализовать следующие процедуры.
Программа SET WEB- сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка.Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц). Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом. Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец.
Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование. В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.
Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы. Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче).
Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже. Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы. Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.
Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА. Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу. После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу. Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца. SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный.
В рамках протокола используются следующие значения символов-префиксов участников сделки:
| Символы-префиксы | Участник сделки |
| C | Владелец карты (Cardholder) |
| M | Продавец (Merchant) |
| P | Расчетный центр (Payment Gateway) |
| CA | Сертификационный центр (Certificate Authority) |
С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes). Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты. Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:
| XID | 20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения). |
| RRPID | 20-байтовое число, которое однозначно идентифицирует запрос. |
| locallD-M | 1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца |
| paySysID | 1-64 байтовый идентификатор транзакции |
| MerOrderNum | 1-25 байтовый номер заказа продавца |
| Держатель карты (Cardholder) | Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги. |
| Продавец (Merchant) | Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей. |
| Эмитент (Issuer) | Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции. |
| Получатель (Acquirer) | Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент. |
| Расчетный центр (Payment Gateway) | Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем. |
| Платежная система (Brand) | Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.) |
| Сертификационный центр (Certificate Authority -CA) | Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА - гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем. |
Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq). В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции. Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются. Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты). Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard). Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты. Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов.
Банк продавца получает свои сертификаты из платежной системы (brand). Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы. Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583). Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов. Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты. Каждая платежная система обеспечивает поддержку 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, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности. |
Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений. При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа. При описании протокола используется нотация представленная в таблице 4.6.2.2. Таблица 4.6.2.2. Нотация протокола SET
| Понятие | Нотация | Описание | |
| Группа (tuple) | {A,B,C} | Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы | |
| Компонент | T={A,B,C} | Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т. | |
| Упорядоченное объединение | A|B|C | Служит для обозначения упорядоченного объединения элементов A,B и C | |
| Опционное значение | [A] | Значение A является опционным | Допускается любое вложение этих скобок |
| Выбор | <A,B,C> | Обозначает, что должно присутствовать одно из значений A,B или C | |
| Опционный выбор | [<A,B,C>] | То же, что и предыдущее, но сам выбор опционен | |
| Кратное использование | {A+} | Группа содержит один или более элементов A | |
| {A*} | Группа содержит нуль или более элементов A | ||
| {[A]+} | Означает, что группа содержит:один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать) | ||
| Исключающее ИЛИ | Е | Обозначает операцию исключающее ИЛИ | |
| Нотация | Оператор | Описание | ||
| H(t) | хэш | 160-битовый хэш группы t | ||
| HMAC(t,k) | Ключевой хэш-механизм | 160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1 HMAC(t,k) = H(k Е opad) | H((k Е ipad)|t)),где ipad - байт 0х36, повторенный 64 раза;opad - байт 0х5С, повторенный 64 раза; аЕ - знак операции исключающее ИЛИ. | ||
| L(t1,t2) | Связь | Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)} | ||
| Нотация операторов цифровой подписи | ||||
| S(s,t) | Подписанное сообщение | Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7. | ||
| Нотация операторов двойной цифровой подписи | ||||
| SO(s,t) | Только подпись | Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. | ||
| Нотация операторов шифрования | ||||
| E(r,t) | Асимметричное шифрование (цифровой конверт) | Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData. | ||
| EH(r,t) | Шифрование целостности | Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте. | ||
| EX(r,t,p) | Дополнительное шифрование | Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t - группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p - параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r. | ||
| EXH(r,t,p) | Дополнительное шифрование с обеспечением целостности | Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH | ||
| EK(k,t) | Симметричное шифрование посредством ключа k | Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData | ||
| Нотация операторов инкапсуляции | ||||
| Enc(s,r,t) | Простая инкапсуляция с подписью | Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData | ||
| EncK(k,s,t) | Простая инкапсуляция с подписью и предоставленным ключом | Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData. | ||
| EncX(s,r,t,p) | Дополнительная инкапсуляция с подписью | Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP | ||
| EncB(s,r,t,b) | Простая инкапсуляция с подписью с загрузкой | Подписанное зашифрованное сообщение с загрузкой (baggage) | ||
| EncBX(s,r,t,p,b) | Дополнительная инкапсуляция с подписью и загрузкой | Подписанное, Е-шифрованное составное сообщение с загрузкой | ||
OAEP - Bellare-Rogaway Optimal Asymmetric Encryption Padding
HMAC - ключевой хэш-механизм, базирующийся на алгоритме SHA-1. В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 -(BLmod 8) октетов. Каждый из байтов заполнителя содержит код 8 -(BLmod 8). Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах - 030303. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES. SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP. Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.
| Шаг | Действие |
| 1 | Алиса запускает программу вычисления дайджеста сообщения, которое она намерена послать Бобу. Этот дайджест будет использован для проверки отсутствия модификации сообщения в процессе его транспортировки от Алисы к Бобу. |
| 2 | Алиса шифрует дайджест сообщения с использованием своего секретного ключа, формируя цифровую подпись. |
| 3 | Формируется псевдослучайный код (симметричный ключ) и с помощью его шифруется сообщение, цифровая подпись и сертификат Алисы, который содержит в себе ее общедоступный ключ. Чтобы дешифровать данное сообщение Бобу будет нужен указанный выше симметричный ключ. |
| 4 | Сертификат Боба, который Алиса должна была получить заранее, содержит копию общедоступного ключа Боба. Чтобы гарантировать безопасность пересылки симметричного ключа, Алиса должна зашифровать его с использованием общедоступного ключа Боба. Зашифрованный таким способом симметричный ключ заносится в одно из полей цифрового конверта (иногда единственное поле), куда в свою очередь будет вложено зашифрованное сообщение. |
| 5 | Алиса посылает сообщение Бобу. При этом в его состав входит: Сообщение, зашифрованное с применением симметричного ключа, цифровая подпись, сертификат и асимметрично зашифрованный симметричный ключ (цифровой конверт). |
| 6 | Боб получает сообщение от Алисы, дешифрует ключ-конверт с привлечением своего секретного ключа и получает в свое распоряжение симметричный ключ. |
| 7 | Боб использует симметричный ключ для дешифрования текста сообщения, подписи Алисы и ее сертификата. |
| 8 | Осуществляется дшифрация подписи Алисы с привлечением ее общедоступного ключа, который берется из ее сертификата. В результате получается дайджест посланного сообщения. |
| 9 | Боб независимо вычисляет дайджест полученного сообщения с привлечением того же алгоритма, что был использован Алисой. |
| 10 | Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису. |
В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи. Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту). Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения.
Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения. В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца). Важным принципом при анализе работы программ SET является идемпотентность - реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы. XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения.
Его длина составляет 20 байт. BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product. Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ. Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq. Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers. Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7. SignedData для вложения подписанной информацииEnvelopedData для инкапсуляции зашифрованных данныхEncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритмаDigestedData для инкапсуляции хэшированных или связанных данных Тип SignedData из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.
SignedData Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest. Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.
| Шаг | Действие |
| 1 | Генерация сообщения SET |
| 2 | Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0) |
| 3 | Вложить код даты, включая время. |
| 4 | Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается. |
| 5 | Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса. |
| 6 | Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта |
| 7 | Вкладывается Message |
| 8 | Производится DER-кодирование вложенного сообщения |
| 9 | Сообщение передается на транспортный уровень |
| Шаг | Действие |
| 1 | Извлекается цифровой конверт сообщения |
| 2 | Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode. |
| 3 | Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений |
| 4 | Произвести DER-декодирование сообщения |
| 5 | Если сообщение содержит SignedData, произвести следующее:Актуализовать системный кэш с учетом полученных CRL.Для каждого полученного сертификата, произвести верификацию цепочки сертификатовПроверить подпись сообщения |
| 6 | Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData |
| 7 | Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается. |
| 8 | Обработать сообщение |
| 9 | Актуализовать системный журнал с учетом состояния транзакции |
Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты: Контроль сертификатов X.509Контроль сертификатов SETОбработку CRL (Certificate Revocation List)Обработку BrandCRLIdentifier (BCI) На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения 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 | Проверить каждый сертификат |
Блок Cancel
Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется. Пример использования включает в себя:
Роль Покупателя, информирующую других о том, что он не собирается продолжать транзакцию. Это позволяет серверу завершить транзакцию, не дожидаясь таймаута.
Роль, отличная от покупателя, информирует Покупателя о том, что транзакция останавливается. В этом случае Покупатель вряд ли повторно пошлет предыдущее сообщение в предположении, что оно не было получено.
Его определение имеет вид.
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Cancel транзакции. |
Cодержимое:
| Status | Содержит статусную информацию, указывающую, что транзакция была аннулирована. |
Блок опций торгового протокола
Торговый блок TPO содержит опции, которые применяются в транзакции IOTP. Определение торгового блока TPO представлено ниже.
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок опций торгового протокола транзакции IOTP (смотри раздел 3.4). |
Cодержимое:
| ProtocolOptions | Компонент протокольных опций (смотри раздел 7.1) определяет опции, которые распространяются на всю транзакцию IOTP (смотри раздел 9). |
| BrandList | Этот компонент списка видов платежа содержит один или более видов протоколов и типов платежа, которые можно выбрать (смотри раздел 7.7). |
| Org | Компоненты Organisation (смотри раздел 7.6) идентифицируют организации и их роли в транзакции IOTP. Роли и организации, которые должны присутствовать, зависят от конкретного типа транзакции. Определения каждой транзакции смотри в разделе 9. |
Блок TPO должен содержать:
компонент протокольных опций;
компонент Organisation с торговой ролью Продавца;
компонент Organisation с торговой ролью Покупателя;
опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку;
компоненты списка видов платежа для каждого платежа транзакции;
компоненты Organisation для Кассира, включенного в транзакцию;
опционно, компоненты Organisation для Агента доставки (если имеется) транзакции;
дополнительные компоненты Organisation, которые Продавец захочет включить. Например.
| - Агент обслуживания Покупателя; | |
- источник сертификатов, который предлагает "коды доверия (Credentials)" Продавца или какую-то другую гарантию на товары или услуги. |
Блок ошибки
Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку.
Ниже представлены две фразы, которые используются в описании торгового блока Error:
ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода;
сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении.
Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error.
Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность.
Структура торгового блока Error представлена ниже.
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Error транзакции. |
Cодержимое:
| ErrorComp | Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке. |
| PaySchemeData | Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы. |
Блок отклика аутентификации
Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже.
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика аутентификации транзакции. |
Cодержимое:
| AuthResp | Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации - смотри раздел 7.3. |
| Org | Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли. |
Компоненты, присутствующие в блоке отклика аутентификации должны согласовываться с требованиями соответствующего блока аутентификационного запроса, в противном случае имеет место ошибка.
Блок отклика доставки
Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным.
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика доставки транзакции. |
Cодержимое:
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным. |
| DeliveryNote | Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15). |
Блок отклика Offer
Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика Offer транзакции. |
Cодержимое:
| Status | Содержит статусную информацию об успехе или неудаче подготовки предложения (смотри раздел 4.2). Заметим, что в блоке отклика Offer, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовой операции, которая имеет место, смотри раздел 7.5. |
Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.
| Payment | Компоненты Payment содержат информацию о платежах, которые надлежит произвести, смотри раздел 7.9. |
| Delivery | Компонент Delivery содержит детали предстоящей доставки (смотри раздел 7.13). |
| TradingRoleData | Компонент информации о торговой роли содержит данными должны обменяться торговые роли, вовлеченные в транзакцию (смотри раздел 7.17). |
Блок отклика Offer должен содержать:
компонент Order транзакции;
компоненты Payment для каждой проплаты транзакции;
компонент Delivery транзакции (если предусмотрено).
Блок отклика Ping
Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.
Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок запроса Ping транзакции. |
| PingStatusCode | Содержит код, который показывает состояние программы отправителя, которая обрабатывает IOTP-сообщения. Допустимыми значениями являются: o Ok. Сервис работает нормально, включая проверку подписей. |
| SigVerifyStatusCode | Заключает в себе код, который показывает состояние проверки подписи. Он присутствует только когда сообщение, содержащее блок запроса Ping имеет также блок Signature. Допустимы следующие значения: o Ok. Веоификация подписи прощла успешно. |
| Xml:lang | Определяет язык, использованный в PingStatusDesc. Присутствует тогда, когда имеется PingStatusDesc. |
| PingStatusDesc | Содержит короткое описание состояния сервера, который поылает этот блок отклика Ping. Сервер, если его разработчики хотят, может использовать этот атрибут для посылки более детальной информации, чем содержится в PingStatusCode, он может использоваться, например, для отладрчных целей. |
Cодержимое:
| Org | Компоненты Organisation (смотри раздел 7.6). |
Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping.
Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.
Блок платежного обмена
Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.
<!ELEMENT PayExchBlk (PaySchemeData+)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного обмена транзакции. |
Cодержимое:
| PaySchemeData | Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10. |
Блок платежного отклика
Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*)>
<!ATTLIST PayRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного отклика транзакции. |
Cодержимое:
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| PayReceipt | Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным. |
| PaySchemeData | Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10. |
| PaymentNote | Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12. |
| TradingRoleData | Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17). |
Блок платежного запроса
Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного запроса транзакции. |
Cодержимое:
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., отклика Offer и/или Payment), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Платеж может состояться лишь тогда, когда все предыдущие шаги были успешными. |
| BrandList | Компонент списка видов платежа содержит список из одного или более видов платежа и протоколов, которые могут быть выбраны (смотри раздел 7.7). |
| BrandSelection | Идентифицирует выбор вида платежа, платежного протокола и Кассира, которые должны быть использованы при оплате в данной транзакции. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждой проплаты, которую следует выполнить в процессе транзакции. |
| Payment | Компоненты Payment содержит информацию о платеже, который выполняется, смотри раздел 7.9. |
| PaySchemeData | Компонент Payment Scheme содержит специфические данные о платежной схеме, смотри раздел 7.10. |
| Org | Компонент Organisation содержит подробности об организациях, вовлеченных в платеж (смотри раздел 7.6). Присутствие организаций зависит от транзакции и данных, которые должны быть подписаны. Смотри раздел 6. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна для пересылки между торговыми ролями, вовлеченными в транзакцию (смотри раздел 7.17). |
Блок платежного запроса должен содержать:
Компонент Organisation с торговой ролью продавца;
Компонент Organisation с торговой ролью Покупателя;
Компонент Payment для платежа;
Компонент Brand List;
Компонент выбора вида платежа из списка;
Компонент Organisation для Кассира, осуществляющего платеж;
Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир;
Компонент Organisation для организации, которая выполняет следующий шаг. Это может быть, например, Агент доставки или Кассир;
Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer;
Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP;
Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1).
Блок подписи
Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.
Определение блока Signature представлено ниже:
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures ID ID #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок подписи транзакции. |
Cодержимое:
| Signature | Компонент Signature. Смотри раздел 7.19. |
| Certificate | Компонент Certificate. Смотри раздел 7.20. |
Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature.
Блок подписи в отклике доставки
Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.
Блок подписи в отклике предложении
Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).
Блок подписи в платежном отклике
Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).
Блок подписи в платежном запросе
Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и
Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге).
Блок подписи в запросе доставки
Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и
Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге.
Блок состояния аутентификации
Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок состояния аутентификации транзакции. |
Cодержимое:
| Status | Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2). |
Блок ссылок операции (Transaction Reference Block)
Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:
Компонент ID-операции, который однозначно идентифицирует операцию IOTP. Компоненты ID-операции идентичны для всех сообщений IOTP, относящихся к одной IOTP-операции.
Компонент ID-сообщения, который предоставляет управляющую информацию о сообщении IOTP, а также однозначно идентифицирует сообщение IOTP в рамках операции IOTP.
Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий.
Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4). |
Cодержимое:
| TransId | Смотри 3.3.1 Id-компонент операции. |
| MsgId | Смотри 3.3.2 Id-компонент сообщения. |
| RelatedTo | Смотри 3.3.3 Компонент Related To. |
Блок выбора TPO
Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже.
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP. |
Cодержимое:
| BrandSelection | Идентифицирует выбор вида платежаи платежного протокола, которы следует использовать при оплате в транзакции IOTP. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждого предстоящего платежа транзакции IOTP. |
Блок выбора TPO должен содержать по одному компоненту выбора вида платежа для каждого списка видов платежа блока TPO.
Блок запроса аутентификации
Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:
информацию о том, как аутентифицировать себя и/или
запрос о дополнительной информации об организации, которую надлежит аутентифицировать.
Его определение предагается ниже.
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса аутентификации транзакции. |
Cодержимое:
| AuthReq | Каждый компонент запроса аутентификации (смотри раздел 7.2) описывет альтернативный путь, с помощью которого получатель запроса аутентификации может себя аутентифицировать, генерируя компонент отклика аутентификации (смотри раздел 7.3). |
Если присутствует один компонент запроса аутентификации, тогда именно он и должен использоваться. Если присутствует несколько компонентов запроса аутентификации, тогда получатель должен выбрать один компонент, основываясь на своих предпочтениях и возможностях программного обеспечения.
Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.
| TradingRoleInfoReq | Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются. |
В аутентификационном блоке должен быть по крайней мере один компонент (аутентификационного запроса или информационного запроса торговой роли), в противном случае имеет место ошибка.
Блок запроса доставки
Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже.
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*)>
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса доставки транзакции. |
Cодержимое:
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., платежный отклик), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Доставку следует осуществлять только если все прдыдущие шаги завершились успешно. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовых операциях, которые имеют место, смотри раздел 7.5. Комоненты Organisation (смотри раздел 7.6) идентифицируют организации их роли. |
| Org | Транзакция IOTP. Роли и организации, которые должны присутствовать зависят от конкретного типа транзакции. Описания транзакций смотри в разделе 9. |
| Delivery | Компонент Delivery содержит подробности доставки, которую следует осуществить (смотри раздел 7.13). |
| ConsumerDeliveryData | Опционный. Содержит идентификатор, специфицированный Покупателем, который в случае возвращения Агентом доставки позволяет покупателю определить, о какой доставке идет речь. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна при обмене между двумя торговыми ролями в процессе транзакции (смотри раздел 7.17). |
Блок запроса доставки содержит:
Компонент Organisation с торговой ролью Продавца;
Компонент Organisation для торговых ролей Покупателя и DeliverTo;
Компонент Delivery;
Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery;
Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира;
Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer;
Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1).
Блок запроса Ping
Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой.
Определение блока запроса Ping предложено ниже.
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет запрос Ping торгового блока транзакции. |
Cодержимое:
Опционные компоненты Organisation (смотри раздел 7.6).
Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер.
Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи.
В этом случае отправитель включает:
Компонент Organisation, который идентифицирует сам себя, специфицируя торговую роль (или роли), которую он исполняет в транзакции (Продавец, Кассир, и т.д.)
Компонент Organisation, который идентифицирует получателя сообщения.
Эти компоненты используются для формирования подписи блока отклика Ping.
CD- отклик на данные кредитной карты
Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте.
#####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-opaque:
t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP
2Z0BClVHLmhIBY7+QXx5iCEGHy8JKC9IWyNNi2O/OOIDgLeJAkMSZYbNQrSKViY34imS
0s7Q6uDk9wV0fixjvRBuNO2B7urWWsqfkLOYDnHy0RvhyUzYxLrMaTX+/6IkyU5Z0lH3
BXYBUNV8DgitEjgLXmyWuXRDlEBN02yeZgsFRm9GmuBHfCTySm2XqnifizpmKMUa9UiH
onNx9W86fuBdcJF7CJgH5Gct2M/dx/f2VpoRkmeSmWxFrYi8wgtvddSXF9my40NZ8WZz
CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5
L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo
5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl
xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ: ключ сессии из CD1.
#####################################################################
Содержимое скрытой секции:
type: card-data-response
server-date: 19950121100706.nnn
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
card-number: 4811123456781234
card-type: visa
card-name: John Q. Public
expiration-date: 01/99
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
merchant-message;
Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.
CD- запрос данных о кредитной карте
Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: card-data-request
password: xyzzy
server-date: 19950121100505.nnn [optional]
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
#####################################################################
Скрытый ключ продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицированного в merchant-cyberkey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [от успешного BC4 (включает в себя время действия карты, номер карты и card-salt)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, password, server-date, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
[смотри также объяснения для CM1] Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции. Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу. Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.
CH- отклик оплаты с помощью карты (charge-card-response)
Отклик покупателю на CH1-попытку оплатить покупку с помощью кредитной карты. Индицирует успех или неудачу.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: charge-card-response
merchant-ccid: ACME-012
id: myCyberCashID
transaction: 78784567
date: 1995121100500.nnn
merchant-date: 19950121100505.nnn
merchant-response-code: failure/success/etc.
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
merchant-message; Это сообщение от продавца следует отобразить пользователю. Может иметь много строчек и не имеет защиты.
opaque: [может отсутствовать, смотри объяснение]
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
>rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ. Ключ сессии покупателя, взятый из CH1 и переданный через CM1 для ID и транзакции.
#####################################################################
Закрытая секция содержит (из CM.6):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [из успешного BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
message;
Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash.
Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения.
Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу. Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.
CH- платеж через кредитную карту (credit-card-payment)
Это сообщение осуществляет представление кредитной карты для выполнения платежа.
####################################################################
Отправитель: CyberApp
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: card-payment
id: myCyberCashID
order-id: 1231-3424-234242
merchant-ccid: ACME-012
transaction: 78784567
date: 19950121100505.nnn
pr-hash: c77VU/1umPKH2kpMR2QVKg==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ. Создан с использованием общедоступного ключа шифрования CyberCash, на который указывает CyberKey.
#####################################################################
Содержимое скрытой секции:
swversion: 0.8win
>amount: usd 10.00
card*: [из успешно прошедшего BC4 (включает в себя время действительности кредитной карты, ее номер, тип и card-salt)]
Подпись:
meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh
mm9BVmHRwCq6+8ylZXixGHI1I9A/ufAMrpqMIi6DS3PRlc8WC3CCWoAHyAqr
#####################################################################
type, id, order-id, merchant-ccid, transaction, date, pr-hash, pr-signed-hash, cyberkey, swversion, amount, card*
#####################################################################
Поле pr-signed-hash тождественно полю подписанного продавцом хэша (merchant-signed-hash) в сообщении PR1.
Части тела
Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности.
Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label).
Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа.
Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк.
Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.
Цифровые подписи
Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA.
Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке.
В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения.
Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.
Цифровые подписи и IOTP
IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач.
CM- auth-capture
Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[exactly the same as CM1 except
type: auth-capture
]
CM- auth-only (аутентификация)
Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: auth-only
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY
GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
#####################################################################
Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey.
Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой части и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date, card-number, and card-salt)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля:
merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
Пояснение: Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.
CM- отклик на операцию оплаты (charge-action-response)
Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию.
#####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ продавца. Ключ сессии, который совпадает с CM1/2/3/4/5 для той же транзакции и CCID продавца.
Скрытый ключ. Тот же ключ сессии покупателя, что и в сообщении CH1 переданном через CM* для данного ID и транзакции
#####################################################################
Содержимое скрытой секции продавца:
type: charge-action-response
server-date: 19950121100706.nnn
action-code: XXX [per ISO 8583]
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
retrieval-reference-number: 432112344321
authorization-code: a12323
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
{
card-prefix: nnxxxx [ Returned if merchant is not full-PAN]
}
или
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [всегда присутствует]
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца об устаревшем номере протокола в стартовой $$-строке сообщения продавца.
merchant-message;
Свободный текст, поясняющий причины неудачи или успеха.
Этот текст направляется сервером продавцу...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn Содержимое скрытой секции (покупателя):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя. [присутствует только, когда имеется SWSeverity]
message;
Свободный текст, поясняющий причины неудачи или успеха. Этот текст следует отобразить покупателю с помощью приложения CyberCash.
| retrieval-reference-number | необходимо для аннулирования. |
| authorization-code | необходим для post-auth-capture. Оба эти поля присутствуют только в сообщении CM6, если оно было присланы банком. Все зависит от выполняемой операции. |
| card-prefix | (префикс карты) представляет собой первые две и последние четыре цифры номера кредитной карты. По усмотрению банка продавца присылается номер кредитной или ее префикс. |
| card-hash | является в действительности хэшем всего номера кредитной карты и salt, представленной покупателем. card-hash необходим для того, чтобы продавец мог, если хочет, сортировать транзакции покупателя по его кредитным картам, не зная их номеров. |
| card* | представляет собой поля card*, полученные вместе с сообщениями CM*, присланными в качестве отклика. Они появляются в алфавитном порядке. |
| server-date | дублируется в целях безопасности в закрытой секции покупателя. |
| [] | комментарии, появляющиеся после некоторых полей. |
CM- возврат
Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[в точности как и CM1, только поле type: return]
Дальнейшие разработки
Список возможностей, которые доступны в системе CyberCash, расширяется. В настоящее время реализована универсальная система расчетов, включающая эффективную пересылку небольших сумм денег, планируются различные дальнейшие улучшения.
Детали формата
Заголовок содержит одну строку, которая выглядит следующим образом
$$-CyberCash-0.8-$$
или
$$-CyberCash-1.2.3-Extra-$$
Он содержит в себе несколько полей, разделенных символом минус "-"
| 1. | "$$" - литерная строка со значением $ в колонке 1. |
| 2. | "CyberCash" - литерная строка (регистр не существенен) |
| 3. | x.y или x.y.z - номер версии формата сообщения. x - первичный номер версии. y - номер субверсии. z, если присутствует, номер субсубверсии. |
| 4. | "Extra" - опционная дополнительная алфавитно-цифровая строка. |
| 5. | "$$" - литерная строка. |
Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы.
Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall.
Динамическая аутентификация данных
Динамическая аутентификация данных выполняется терминалом, с использованием цифровой подписи, базирующейся на технике общедоступного ключа, и имеет целью аутентифицировать ICC и подтвердить легитимность динамической информации, записанной на ICC. Динамическая аутентификация требует наличия центра аутентификации, который подписывает общедоступные ключи эмитента. Каждый терминал должен иметь общедоступные ключи сертификационного центра для каждого приложения, распознаваемого терминалом. Схема аутентификации динамических данных показана на рис. 4.6.4.12.
Рис. 4.6.4.12. Схема динамической аутентификации данных
ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.
Индекс общедоступного ключа сертификационного центра. Этот элемент состоит из одного байта, который указывает, какой из общедоступных ключей сертификационного центра и алгоритм, доступный терминалу, следует использовать с данной картой ICC.
Сертификат общедоступного ключа эмитента. Этот элемент переменной длины записывается в ICC эмитентом карты. Когда терминал проверяет этот элемент, он аутентифицирует общедоступный ключ и сопутствующие данные ICC.
Остаток общедоступного ключа эмитента.
Показатель общедоступного ключа эмитента.
Остаток общедоступного ключа ICC.
Показатель общедоступного ключа ICC.С
екретный ключ ICC. Элемент переменной длины, используемый для формирования подписанных динамических прикладных данных.
ICC, которые поддерживают аутентификацию динамических прикладных данных, должны сформировать следующий информационный элемент.
Подписанные динамические прикладные данные. Этот информационный элемент переменной длины формируется ICC с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате общедоступного ключа ICC.
Чтобы поддерживать аутентификацию динамических данных, каждый терминал должен запоминать большое число общедоступных ключей сертификационного центра, и ставить им в соответствие информацию, которая должна использоваться с этими ключами.
Терминал способен найти любой такой ключ, заданный RID и индексом общедоступного ключа сертификационного центра, полученных от ICC. ICC, поддерживающая аутентификацию динамических данных должна иметь пару ключей, один из которых является секретным, служащим для цифровой подписи, другой - общедоступный для верификации. Общедоступный ключ ICC запоминается ИС картой в сертификате общедоступного ключа, сформированном эмитентом карты. Общедоступный ключ эмитента сертифицирован центром сертификации. Как следствие для верификации подписи ICC терминал должен сначала верифицировать два сертификата, для того чтобы получить и аутентифицировать общедоступный ключ ICC, который далее служит для проверки корректности динамической подписи ICC. Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ? 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC - 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ - (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1. Модуль общедоступного ключа ICC содержит NIC байт, где NIC ? 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна - состоит из NЭ - 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC - (NЭ - 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1. Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC.
За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу. Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.
| Имя поля | Длина (байт) | Описание |
| Формат сертификата | 1 | Шестнадцатеричное число 0х02 |
| Идентификационный номер эмитента | 4 | Левые 3-8 цифр от PAN (дополняемые справа кодами 0хF) |
| Дата истечения времени действия сертификата | 2 | Дата ММГГ, после которой сертификат становится недействительным |
| Серийный номер сертификата | 3 | Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации |
| Индикатор хэш-алгоритма | 1 | Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи |
| Индикатор алгоритма общедоступного ключа эмитента | 1 | Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента |
| Длина общедоступного ключа эмитента | 1 | Идентифицирует длину модуля общедоступного ключа эмитента в байтах |
| Длина показателя общедоступного ключа эмитента | 1 | Идентифицирует длину показателя общедоступного ключа эмитента в байтах |
| Общедоступный ключ эмитента или левые цифры этого ключа | NCC - 36 | Если NЭ ? NCC - 36, это поле состоит из полного общедоступного ключа эмитента дополненного справа NCC -36 - NЭ байт с кодом 0хBB. Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байтов общедоступного ключа эмитента |
| Остаток общедоступного ключа эмитента | 0 или NЭ -NCC + 36 | Это поле присутствует только если NЭ > NCC - 36 и состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента |
| Показатель общедоступного ключа эмитента | 1 или 3 | Показатель общедоступного ключа эмитента равен 2, 3 или 216+1 |
| Имя поля | Длина (байт) | Описание |
| Формат сертификата | 1 | Шестнадцатеричное число 0х04 |
| PAN (Primary Application Number) приложения | 10 | PAN дополненный справа кодами 0хF |
| Дата истечения времени действия сертификата | 2 | Дата ММГГ, после которой сертификат становится недействительным |
| Серийный номер сертификата | 3 | Двоичное число, уникальное для данного сертификата, присваиваемое эмитентом |
| Индикатор хэш-алгоритма | 1 | Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи |
| Индикатор алгоритма общедоступного ключа ICC | 1 | Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC |
| Длина общедоступного ключа ICC | 1 | Идентифицирует длину модуля общедоступного ключа ICC в байтах |
| Длина показателя общедоступного ключа ICC | 1 | Идентифицирует длину показателя общедоступного ключа ICC в байтах |
| Общедоступный ключ ICC или левые цифры этого ключа | NЭ - 42 | Если NIC ? NЭ - 42, это поле состоит из полного общедоступного ключа ICC дополненного справа NЭ - 42 - NIC байт с кодом 0хBB.Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC |
| Остаток общедоступного ключа ICC | 0 илиNIC - NЭ + 42 | Это поле присутствует, только если NIC > NЭ - 42 и состоит из NЭ - NCС + 42 младших байт общедоступного ключа ICC |
| Показатель общедоступного ключа ICC | 1 или 3 | Показатель общедоступного ключа ICC равен 2, 3 или 216+1 |
| Данные, подлежащие аутентификации | Переменная | Статические данные, подлежащие аутентификации согласно спецификации ICC для платежных систем |
| Метка (Tag) | Длина (байт) | Описание |
| - | 5 | Зарегистрированный идентификатор провайдера приложения (RID) |
| 0х8F | 1 | Индекс общедоступного ключа центра сертификации |
| 0х90 | NCC | Сертификат общедоступного ключа эмитента |
| 0х92 | NЭ - NCC + 36 | Остаток общедоступного ключа эмитента (если имеется) |
| 0х9F32 | 1 или 3 | Показатель общедоступного ключа эмитента |
| 0х9F46 | NЭ | Сертификат общедоступного ключа ICC |
| 0х9F48 | NIC - NЭ + 42 | Остаток общедоступного ключа ICC (если он имеется) |
| 0х9F47 | 1 или 3 | Показатель общедоступного ключа ICC |
| - | Переменная | Данные, подлежащие аутентификации |
Терминал считывает индекс общедоступного ключа центра сертификации. Используя этот индекс и RID, терминал может идентифицировать и извлечь из памяти модуль и показатель общедоступного ключа сертификационного центра и сопряженную с ним информацию. Если терминал не сможет найти нужные данные, сертификация не состоится. Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит. Для того чтобы получить восстановленные данные, представленные в таблице 4.6.4.26, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных не равен 0хBC, аутентификация динамических данных не проходит. Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается. Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается. Объединяются слева направо информационные элементы со второго по десятый (см. табл. 4.6.4.26), добавляется остаток общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Для полученной строки применяется соответствующий алгоритм хэширования. Сравнивается вычисленный хэш и восстановленное значение поля результата хэширования. При несовпадении аутентификация не проходит. Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.
| Имя поля | Длина (байт) | Описание |
| Заголовок восстановленных данных | 1 | Шестнадцатеричное число 0х6А |
| Формат сертификата | 1 | Шестнадцатеричное число 0х02 |
| Идентификационное число эмитента | 4 | Левые 3-8 цифр из PAN, дополненные справа кодами 0хF |
| Дата истечения времени действия сертификата | 2 | Дата ММГГ, после которой сертификат становится недействительным |
| Серийный номер сертификата | 3 | Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации |
| Индикатор хэш-алгоритма | 1 | Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи |
| Индикатор алгоритма общедоступного ключа эмитента | 1 | Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента |
| Длина общедоступного ключа эмитента | 1 | Идентифицирует длину модуля общедоступного ключа эмитента в байтах |
| Длина показателя общедоступного ключа эмитента | 1 | Идентифицирует длину показателя общедоступного ключа эмитента в байтах |
| Общедоступный ключ эмитента или левые цифры этого ключа | NCC - 36 | Если NЭ ? NСС - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NСС - 36 - NЭ байтами с кодом 0хBB. Если NЭ > NСС - 36, это поле состоит из NСС - 36 старших байтов общедоступного ключа эмитента |
| Результат хэширования | 20 | Хэш общедоступного ключа эмитента и сопряженных данных |
| Хвостовик восстановленных данных | 1 | Шестнадцатеричное число 0хВС |
Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается. Проверяется срок действия сертификата и, если он истек, аутентификация отвергается. Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации и серийного номера сертификата корректно. Если индикатор алгоритма общедоступного ключа эмитента не распознан, аутентификация не проходит. Если все вышеперечисленные проверки прошли успешно, осуществляется объединение левых цифр общедоступного ключа эмитента и остатка этого ключа (если он имеется). Это делается для получения модуля общедоступного ключа эмитента. После данной процедуры система переходит к извлечению общедоступного ключа ICC. Если сертификат общедоступного ключа ICC имеет длину, отличную от длины модуля общедоступного ключа эмитента, авторизация не проходит. Для того чтобы получить данные, специфицированные в таблице 4.6.4.27, используется сертификат общедоступного ключа ICC и общедоступный ключ эмитента. Если хвостовик восстановленных данных не равен 0хВС, аутентификация не проходит. Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит. Если код формата сертификата не равен 0х04, аутентификация также не проходит. Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.
| Имя поля | Длина(байт) | Описание |
| Заголовок восстановленных данных | 1 | Шестнадцатеричное число 0х6А |
| Формат сертификата | 1 | Шестнадцатеричное число 0х04 |
| PAN приложения | 10 | PAN, дополненный справа кодами 0хF |
| Дата истечения времени действия сертификата | 2 | Дата ММГГ, после которой сертификат становится недействительным |
| Серийный номер сертификата | 3 | Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации |
| Индикатор хэш-алгоритма | 1 | Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи |
| Индикатор алгоритма общедоступного ключа ICC | 1 | Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC |
| Длина общедоступного ключа ICC | 1 | Идентифицирует длину модуля общедоступного ключа ICC в байтах |
| Длина показателя общедоступного ключа ICC | 1 | Идентифицирует длину показателя общедоступного ключа ICC в байтах |
| Общедоступный ключ ICC или левые цифры общедоступного ключа ICC | NЭ - 42 | Если NIC ? NЭ - 42, это поле состоит из полного общедоступного ключа ICC, дополненного справа NЭ - 42 - NIC байтами с кодом 0хBB. Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC |
| Результат хэширования | 20 | Хэш общедоступного ключа ICC и сопряженных с ним данных |
| Хвостовик восстановленных данных | 1 | Шестнадцатеричное число 0хВС |
Объединяются слева направо поля из таблицы 4.6.4.27, начиная со второго до десятого, добавляется остаток общедоступного ключа ICC (если имеется), показатель общедоступного ключа ICC и данные, подлежащие аутентификации. Это объединение хэшируется согласно указанному алгоритму. Результат сравнивается со значением поля результат хэширования. При несовпадении аутентификация не проходит. Восстановленный PAN должен быть равен PAN приложения (ICC). После этого проверяется срок пригодности сертификата. Если все выше перечисленные проверки оказались успешными, система переходит к последующим тестам. После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта). ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения. Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны
| Имя поля | Длина (байт) | Описание |
| Формат подписанных данных | 1 | Шестнадцатеричное число 0х05 |
| Индикатор хэш-алгоритма | 1 | Индицируется алгоритм хэширования, используемый для получения результата |
| Длина динамических данных ICC | 1 | Идентифицирует длину LDD динамических данных ICC в байтах |
| Динамические данные ICC | LDD | Динамические данные, сформированные и/или записанные в ICC |
| Символы заполнителя | NIC - LDD - 25 | (NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB |
| Динамические данные терминала | Переменная | Объединение информационных элементов, специфицированных DDOL |
Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит. Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения
| Имя поля | Длина (байт) | Описание |
| Заголовок восстановленных данных | 1 | Шестнадцатеричное число 0х6А |
| Формат подписанных данных | 1 | Шестнадцатеричное число 0х05 |
| Индикатор алгоритма хэширования | 1 | Индицируется алгоритм хэширования, используемый для получения результата при вычислении цифровой подписи |
| Длина динамических данных ICC | 1 | Идентифицирует длину динамических данных ICC в байтах |
| Динамические данные ICC | LDD | Динамические данные, сформированные и/или записанные в ICC |
| Символы заполнителя | NIC - LDD - 25 | (NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB |
| Результат хэширования | 20 | Хэш динамических данных приложения и сопряженной информации |
| Хвостовик восстановленных данных | 1 | Шестнадцатеричное число 0хВС |
