4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8
Семенов Ю.А. (ГНЦ ИТЭФ)
Протокол CyberCash (RFC-1898, D. Eastlake, CyberCash Credit Card Protocol Version 0.8. February 1996) предназначен для осуществления платежей через Интернет посредством кредитных карточек.
CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом.
CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.
1.1. Обзор системы
Система CyberCash предназначена для обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash.
Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть.
Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.
Рис. .1. Схема взаимодействия субъектов сделки
1.2. Соображения безопасности
В системе CyberCash особое внимание уделяется вопросам безопасности. Система использует самые современные технологии шифрования и способна адаптировать любые новые схемы шифрования, которые появятся в будущем.
1.2.1. Аутентификация и идентификация личности
Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для “персон” покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой.
В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ.
Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту.
Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.
1.2.2. Конфиденциальность
Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа.
Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции.
1.3. Работа с кредитной картой
При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.)
При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.
2. Формат заголовка общего сообщения
Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет.
В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена.
2.1. Формат сообщения
Сообщения CyberCash состоят из следующих компонентов:
Заголовок – определяет начало сообщения CyberCash и включает информацию о версии.
Прозрачная часть – содержит данные, которые не являются конфиденциальными.
Невидимые части – содержат финансовую информацию сообщения и защищены от разглашения или искажения. Невидимая часть может отсутствовать в некоторых сообщениях. Если она присутствует, она обеспечивает защиту от искажения прозрачной части.
Завершающая секция – определяет конец сообщения CyberCash и содержит контрольный код, который позволяет судить о том, что сообщение дошло без искажений. Заметим, что этот код призван детектировать случайные искажения сообщения.
В CyberCash сообщении запрещены нулевые символы (значение нуль) или символы, характеризуемые восемью битами. "Двоичные" значения, которые могут содержать такие коды, представляются с помощью base64, описанного в документе RFC-1521.
2.2. Детали формата
Заголовок содержит одну строку, которая выглядит следующим образом
$$-CyberCash-0.8-$$
или
$$-CyberCash-1.2.3-Extra-$$
Он содержит в себе несколько полей, разделенных символом минус "-"
1.
"$$" - литерная строка со значением $ в колонке 1.
2.
"CyberCash" - литерная строка (регистр не существенен)
3.
x.y или x.y.z – номер версии формата сообщения. x – первичный номер версии. y – номер субверсии. z, если присутствует, номер субсубверсии.
Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы.
Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall.
2.3. Части тела
Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности.
Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label).
Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа.
Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк.
Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.
2.4. Открытая часть
Открытая часть сообщения включает любые текстовые данные, связанные с финансовой транзакцией, а также информацию, необходимую CyberCash и другим, для того чтобы дешифровать скрытую часть. Она всегда включает поле транзакции, которое представляет собой номер транзакции, сформированный источником запроса, это поле копируется в отклик. Открытая часть всегда включает поле даты, которое представляет собой местную дату и время, переносимые без изменений в соответствующие поля отклика. Во всех случаях кроме начальной регистрации открытая часть содержит ID персоны источника запроса.
В сообщениях, подготовленных для сервера, существует киберключ (cyberkey:) поле, которое идентифицирует, какой из общедоступных ключей сервера был использован для шифрования ключа сессии.
2.5. Скрытая часть
Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются.
Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные.
Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением.
Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто.
2.6. Завершающая часть
Завершающая секция служит для выделения конца сообщения. Она содержит несколько полей разделенных "-".
1.
"$$" - строка литералов.
2.
"CyberCash" - строка литералов (не чувствительна к регистру).
3.
"End" - строка литералов (не чувствительна к регистру).
4.
Контрольная сумма передачи.
5.
"$$" – строка литералов.
Контрольная сумма передачи вычисляется согласно алгоритму MD5. Номер версии в начальной строке содержит исключительно печатные символы и размещается после второго $$ этой строки и до первого $$ завершающей строки. Заметим, что все пробелы (SP, TAB, LF и CR) не включаются в этот хэш. Терминаторы меток (: или ;) включаются туда, также как любые строки #-комментариев. Заметим также, что опционная символьная строка "Extra" в начальной $-строке в хэш не включается. Основной идеей является обеспечение корректности передачи, избегая зависимости от шлюзов (gateways) или любой обработки, которая может изменить завершающую строку или преобразовать символы табуляции, пробелы или символы разрыва строки.
Входные сообщения- запросы CyberCash обычно имеют подпись всех полей. Эта подпись передается в пределах скрытой части сообщения. Она позволяет серверу аутентифицировать источник сообщения.
Сообщения от продавца клиенту, инициализирующие процедуру покупки, имеют поля подписанные продавцом. Эти поля и эта подпись включаются клиентом в скрытую часть сообщения продавцу, так что когда все передается серверу, он может проверить, что клиент получил именно ту информацию, которую ему передал продавец.
3.1. Цифровые подписи
Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA.
Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке.
В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения.
Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.
3.2. Хэш-коды
Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение.
Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности.
До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются.
Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями).
4. Форматы специальных сообщений
Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла.
4.1. Регистрация персоны и нахождение приложения
Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2.
Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя.
4.1.1. R1 – регистрация
Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash.
content-language ( язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.
4.1.2 R2 – отклик регистрации
Это сообщение предоставляет отклик об успехе или неудаче R1.
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
message;
Произвольный текст уведомления об успехе или неудаче.
Этот текст должен быть отображен для владельца приложения CyberCash...
В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация).
Объяснение:
responseid
применяется для предоставления уникального ID, если в результате ошибки потерян ID, использованный ранее. Если причина неудачи не связана с дублированным ID, это поле может быть опущено.
responseid
предоставляет действительный ID с присоединенными контрольными символами в случае успеха.
swseverity
может предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок.
Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить.
4.1.4. GA2 – отклик получения приложения (get-application-response)
Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи.
Система CyberCash сконструирована так, чтобы предоставить организации, выпустившей кредитную карту, возможность определить, может ли она использоваться через CyberCash. Покупатель, после регистрации персоны в CyberCash, как это описано выше, может связать каждую кредитную карту по своему желанию с персоной в системе CyberCash. Это делается с помощью сообщения BC1, посылаемого покупателем своему серверу CyberCash, и отклика BC4, приходящего от сервера.
4.2.1. BC1 – подключение кредитной карты (Bind-Credit-card)
Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash.
salt необходимо из-за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.
4.2.2. BC4 – отклик подключения кредитной карты (bind-credit-card-response)
Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
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 должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.
4.3. Сообщения покупателя о покупке, содержащие данные о кредитной карте
Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash “payment”, продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash.
Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.
4.3.1. PR1 – запрос платежа (payment-request)
Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить.
Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию.
accepts:
Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например,
MasterCard
AmericanExpress
Распознаны как
Master card
American express
Не распознаны. MasterCard и masterCard распознаются оба как master card.
За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием.
url-pay-to
указывает, куда следует послать CH1.
url-fail
и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи.
4.3.2. CH1 – платеж через кредитную карту (credit-card-payment)
Это сообщение осуществляет представление кредитной карты для выполнения платежа. ####################################################################
swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
message;
Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash.
Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения.
Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу. Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.
4.4. Сообщения продавца о покупке, связанные с кредитной картой
Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения.
Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7
Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым.
Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом.
4.4.1. CM1 - auth-only (аутентификация)
Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя.
Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey. Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.
4.4.2. CM2 - auth-capture
Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа.
Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена.
4.4.4. Сообщение об удалении CM4
Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись).
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.
4.4.5. CM5 - возврат
Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип.
4.4.6. CM6 – отклик на операцию оплаты (charge-action-response)
Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию.
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
дублируется в целях безопасности в закрытой секции покупателя.
[]
комментарии, появляющиеся после некоторых полей.
4.4.7. Последовательности сообщений MM*
Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.
4.4.8. CD1 – запрос данных о кредитной карте
Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений.
Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции. Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу.
Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.
4.4.9. CD2 – отклик на данные кредитной карты
Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте.
merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
merchant-message;
Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.
4.5. Прикладные сообщения и уведомления об ошибках
Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке.
Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту.
Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером.
Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2.
4.5.1. P1 - ping
Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов.
swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.
Это попытка клиента аннулировать предыдущую транзакцию или транзакции.>
begin-transaction и end-transaction могут совпадать.
Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.
Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты. Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.).
Термины
"исходная транзакция"
относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера.
"request"
относится к запрашивающим сообщениям TQ.2 или TQ.1.
id:
идентификатор сообщения-запроса
date:
дата сообщения-запроса
transaction:
транзакция сообщения-запроса
server-date:
текущая дата/время
type:
Отклик транзакции
response-code:
код отклика для сообщения-запроса, может быть одним из:
"success"
означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса.
"failure-hard"
означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине.
"failure-swversion"
означает, что запрос не был обработан из-за проблем ревизии программного обеспечения.
message:
сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика:
"success"
сообщение проигнорировано.
"failure-hard"
используется стандартное сообщение уведомление о неудаче.
"failure-swversion"
в случае фатальной ошибки используется стандартное сообщение типа swversion
swseverity:
относится к сообщению-запросу
swmessage:
относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N)
transaction-N:
номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из:
"success"
исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится.
"failure"
исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится.
"pending"
исходная транзакция все еще обрабатывается и окончательный результат пока не известен.
"canceled"
исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled".
server-date-1:
поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
date-1:
поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
type-1:
поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
<
/p>
4.5.6. UNK1 – неизвестная ошибка
Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту.
Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д.
Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу. Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1.
4.5.7. DL1 – диагностическая запись
Клиентская диагностическая запись о плохом сообщении от продавца или сервера.
Приложение клиента не ожидает отклика на это сообщение. Если дешифрация прошла успешно, дешифрованное исходное сообщение будет заключено в закрытую секцию. Если дешифровка не прошла, не дешифрованная закрытая секция берется из исходного сообщения.
4.5.8. DL2 – диагностические журнальные записи продавца (merchant-diagnostic-log)
Диагностическая запись продавца о плохом сообщении от сервера.
Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение.
4.6. Таблица описанных сообщений
C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash
FLOW
Раздел
Имя
C->S
4.2.1
BC.1 bind-credit-card
S->C
4.2.2
BC.4 bind-credit-card-response
C->M
4.3.2
CH.1 credit-card-payment
M->C
4.3.3
CH.2 credit-card-response
M->S
4.4.8
CD.1 запрос данных о кредитной карте
S->M
4.4.9
CD.2 отклик на запрос о кредитной карте
M->S
4.4.1
CM.1 только аутентификация
M->S
4.4.2
CM.2 auth-capture
M->S
4.4.3
CM.3 post-auth-capture
M->S
4.4.4
CM.4 void
M->S
4.4.5
CM.5 возврат
S->M
4.4.6
CM.6 отклик на платеж
C->S
4.5.7
DL.1 диагностическая запись
M->S
4.5.7
DL.2 диагностическая запись продавца
C->S
4.1.3
GA.1 получение приложения
S->C
4.1.4
GA.2 получение отклика приложения
M->S
4.4.7
MM.1 только аутентификация продавца
M->S
4.4.7
MM.2 merchant-auth-capture
M->S
4.4.7
MM.3 merchant-post-auth-capture
M->S
4.4.7
MM.4 merchant-void
M->S
4.4.7
MM.5 merchant-return
S->M
4.4.7
MM.6 отклик продавца на процедуру оплаты
C->S
4.5.1
P.1 ping
S->C
4.5.2
P.2 отклик на ping
M->C
4.3.1
PR.1 запрос платежа
C->S
4.1.1
R.1 регистрация
S->C
4.1.2
R.2 отклик на регистрацию
C->S
4.5.3
TQ.1 запрос о состоянии транзакции
C->S
4.5.4
TQ.2 аннулирование транзакции
S->C
4.5.5
TQ.3 отклик на транзакцию
S->C, S->M, M->C
4.5.6
UNK.1 неизвестная ошибка
<
/p>
5. Дальнейшие разработки
Список возможностей, которые доступны в системе CyberCash, расширяется. В настоящее время реализована универсальная система расчетов, включающая эффективную пересылку небольших сумм денег, планируются различные дальнейшие улучшения.
5.1. Процесс авторизации кредитной карты и расчета
Существует шесть шагов обработки кредитной карты, как это описано ниже. Первые четыре присутствуют всегда, если транзакция завершена. Пятый и шестой являются опционными.
(1)
авторизация
: продавец контактирует со своим покупателем, который в свою очередь получает от банкира, выпустившего кредитную карту, подтверждение или отрицание своей кредитоспособности. Эти данные он пересылает продавцу.
(2)
приобретение (capture)
: платежная информация для покупки вводится продавцом в расчетный документ.
(3)
оплата
(clearance): обработка перечня товаров. Это вызывает появление товаров из перечня в записи о покупке для данной кредитной карты. Эта запись посылается банку, предоставившему кредитную карту покупателю.
(4)
урегулирование
(settlement): межбанковская операция по пересылке денежных средств.
(5)
удаление
(void): продавец отменяет шаг 2 (или 6), сумма оплаты удаляется из расчетного документа. Операция должна быть выполнена до осуществления оплаты.
(6)
кредит
(credit): продавец вводит отрицательную сумму оплаты в расчетный документ. Эта сумма появится в записи о покупке владельца кредитной карты.
Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются “терминальными покупками” ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера.
6. Соображения безопасности
Система CyberCash для работы с кредитными картами версии 0. 8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.
Ссылки
[ISO 4217]
Codes for the representation of currencies and funds
Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982.
[RFC-1521]
Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993.
[RFC-1766]
Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.