Протоколы обеспечения безопасности платежных систем

From CryptoWiki
Jump to: navigation, search

Contents

Постановка задачи защиты информации

Следующие условия должны быть соблюдены в любой из современных платежных систем:

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

2) Сохранение целостности информации. Информация о покупки и данные транзакции должны быть защищены от несанкционированного изменения.

3) Аутентификация сторон. Обе стороны должны быть уверены, что имеют дело именно с тем лицом, за которое оно себя выдает.

4) Широкий выбор средств оплаты. Покупатель может оплачивать сделки любыми доступными ему денежными средствами.

5) Авторизация. Проверка аутентифицированного пользователя на возможность осуществления сделки(например платежеспособность).

6) Гарантия рисков. Продавец должен иметь гарантии от множества рисков связанных с использованием платежной системы. Например, отказ от товара. Риски определяются и документируются в соглашениях между провайдером платежной системы и других участвующих в процессе организаций.

7) Минимизация оплаты транзакции. Оплата обработки заказа, очевидно, будет входить в стоимость операции и она должна быть, по возможности, минимизирована. Оплата, также оплачивается даже, в том случае, когда покупатель отказывается от приобретаемого товара.

3-D Secure

3-D Secure является XML-протоколом, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт, двухфакторной аутентификации пользователя. Он был разработан Visa с целью улучшения безопасности интернет-платежей и предложил клиентам услугу Verified by Visa (VbV). Услуги, основанные на данном протоколе, также были приняты MasterCard под названием MasterCard SecureCode (MCC) и JCB International как J/Secure.

3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей.

3-D Secure не следует путать с кодом CVV2, который напечатан на карте с обратной стороны.


Описание

Для владельца карты банка, поддерживающего 3-D Secure, в процессе оплаты онлайн к ранее необходимой информации добавляется дополнительный запрос на подтверждение владения картой, чаще всего одноразовый код подтверждения предоставляется банком в sms-сообщении, отправленном на привязанный к карте номер сотового оператора связи. Возможны и другие варианты получения кода подтверждения платежа, такие как карты с микропроцессорами. Ряд банков используют обычную систему постоянных паролей, т. е. пользователь задаёт пароль один раз (при регистрации) и при совершении каждого интернет-платежа вводит именно его. Данный способ является менее надёжным, нежели одноразовый код подтверждения.

Основные аспекты протокола

Основная концепция протокола — добавить к процессу финансовой авторизации онлайн-проверку подлинности. Эта проверка подлинности основана на принципе трёх доменов (отсюда 3-D в названии):

  • домен эквайера (домен продавца и банка, в который перечисляются деньги);
  • домен эмитента (домен банка, выдавшего карту);
  • домен совместимости (Interoperability Domain) (домен, предоставляемый кредитной организацией (MasterCard, Visa и т. д.) для поддержки 3-D Secure протокола).

Перенос ответственности

В обычных (не защищённых 3-D Secure) транзакциях ответственность за операции по украденным картам несёт «мерчант» — торгово-сервисное предприятие, на сайте которого была произведена покупка товара/услуги по ворованной карте при условии что он не поддерживает эту технологию. В случае 3-D Secure происходит так называемый «Перенос ответственности» (англ. Liability Shift), когда ответственность переносится на банк-эмитент, выпустивший карту.

Архитектура 3-D Secure

Visa разработала протокол 3-D Secure™ (так называемый протокол трех доменов), чтобы увеличить эффективность онлайновых транзакций и ускорить рост электронной коммерции.

Развитие и внедрение этого протокола должно принести выгоду всем участникам онлайновой транзакции, предоставив банкам-эмитентам возможность аутентифицировать держателей карт во время онлайновой покупки. Это повысит надежность и безопасность транзакций и уменьшит возможность мошеннического использования кредитных карт в Интернете – если покупки будут совершаться с использованием технологии 3D-secure.

Преимущества данного протокола состоят в следующем:

  • использование 3-D Secure уменьшает возможные потери денег всеми участниками транзакции, поскольку существенно уменьшает количество чарджбэков, инициированных держателями карт по причине того, что карта была использована мошенниками.
  • Чтобы использовать протокол, клиентам не обязательно приобретать новое аппаратное или программное обеспечение
  • Протокол может быть расширен и дополнен банком-эмитентом, чтобы наилучшим образом соответствовать требованиям клиентов без необходимости банкам-эквайрам и мерчантам вводить дополнения в протокол со своей стороны.
  • Протокол может использоваться на таких перспективных для развития электронной коммерции платформах, как мобильные телефоны, карманные компьютеры, цифровые телевизоры.
  • Он основан на широко применяющихся технических стандартах, поддерживаемых международными организациями.
  • Предоставляет возможность ведения (и доступа к) централизованному архиву аутентификаций, который будет полезен для принятия решения по спорным транзакциям.

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

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

Acquirer Domain (Домен эквайра) – его назначение в том, чтобы определить правила и процедуры обмена информацией между доменами эмитента и эквайра, гарантирующие этим доменам взаимную аутентификацию друг друга.

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

Обеспечение безопасности в моделе 3-х доменов

Рассмотрим подробно структуру доменов и что в них входит.

Домен эмитента

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

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

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

Эмитент

Член финансового сообщества Visa

  • Входит в договорные отношения с владельцем карты (выдает одну или больше кредитных карт Visa клиенту)
  • Определяет допустимость участия владельца карты в сервисе 3-D Secure
  • Определяет ограничения на номера карт, допустимые для участия в сервисе 3-D Secure-Предоставляет данные об этих ограничениях на номер карты серверу Visa Directory
  • Производит (enroll) владельца карты при каждом доступе к карте для платежа(через Сервер контроля доступа, отдельные сервер учета или вручную)


Сервер контроля доступа (Access control server - ACS)

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

  1. Проверка возможности 3-D Secure аутентификации для номера карты
  2. Аутентификация владельца карты для конкретной транзакции или обеспечение подтверждения попытки аутентификации в случае, если аутентификация недоступна (невозможна).

Хотя эти функции и описаны, как осуществляемые одиночным логическим ACS, физических серверов, обеспечивающих реализацию функций ACS, может быть много. Например каждый из этих серверов «обслуживает» определенный диапазон номеров карт.

Домен эквайра

Мерчант (Интернет-магазин, торговая точка) Программное обеспечение мерчанта получает номер карты, и затем вызывает Плагин Сервера Мерчанта, чтобы провести аутентификацию платежа. После аутентификации платежа, программное обеспечение на стороне мерчанта может отправить запрос на авторизацию эквайеру в зависимости от результата аутентификации.

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

Эквайер

Это финансовое учреждение, входящее в финансовое сообщество Виза, которое:

  • Заключает контракт с мерчантом для обеспечения приема к оплате кредитных карт Visa
  • Определяет право и возможность мерчанта участвовать в сервисе 3-D Secure
  • Получает запросы на авторизацию от мерчанта
  • Пересылает их к авторизующей системе (такой как VisaNet)
  • Передает мерчанту ответы об авторизации
  • Пересылает завершенную транзакцию в VisaNet

Организация коммерческой сертификации

Генерирует сертификаты для участников 3-D Secure , включая клиентские и серверные сертификаты SSL.

Центр сертификации Visa

Генерирует необходимые сертификаты для использования участниками 3D-secure, включая сертификаты для подписей и (visa root) сертификаты.

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

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

Копия данных, сохраняемых сервером истории аутентификаций, может быть передана эквайрам и эмитентам для решения спорных вопросов.

VisaNet

Относительно аутентификации платежей VisaNet выполняет свою традиционную роль:

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

Аутентификация платежа

Владелец карты совершает покупку

Когда владелец кредитной карты намеревается совершить покупку, он либо должен предоставить информацию о своем счете (карте), либо использует специальное программное обеспечение (например, цифровой кошелек), чтобы это сделать. Когда владелец карты подтверждает свое желание сделать покупку, запускается плагин сервера мерчанта (ПСМ) Merchant Server Plug-in (MPI). Программа ПСМ может находиться на сайте интернет-магазина, у эквайера или у процессингового центра третьей стороны.


Запрос к Visa Directory

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

Аутентификация владельца карты

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

Процессинг платежа

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

Поток сообщений при онлайн-транзакции:

  1. Покупатель выбирает товары на сайте продавца (мерчанта) и подтверждает желание совершить покупку.
  2. ПСМ посылает запрос на аутентификацию серверу Виза Директори.
  3. Сервер Виза Директори запрашивает соответствующий Сервер контроля доступа, чтобы определить, возможна ли аутентификация для данной карты. Если соответствующий сервер контроля доступа недоступен, Виза Директори формирует соответствующий ответ и переходит к шагу 5.
  4. Сервер контроля доступа отвечает серверу Виза Директори, сообщая, возможно ли провести аутентификацию данного номера кредитной карты.
  5. Виза Директори пересылает ответ сервера конторля доступа (или свой ответ) к ПСМ. Если аутентификация возможна, эквайер или процессинговый центр отпраавляет стандартный запрос на авторизацию.
  6. ПСМ посылает запрос плательщика на аутентификацию (Payer Authentication Request (PAReq)) к ACS через компьютер или иное устройство, которое использует покупатель для совершения онлайн-покупки.
  7. ACS получает вышеуказанный запрос.
  8. ACS аутентифицирует покупателя, используя процесс соответствующий номеру кредитной карты (пароль, PIN и т п). Затем формируется сообщение PARes – Payer Authentification Response (аутентификационный ответ покупателю с соответствующими значениями, и заверяет его цифровой подписью)
  9. ACS пересылает PARes к ПСМ через компьютер покупателя. Также ACS отправляет необходимые данные на сервер историии аутентификаций (Authentication History Server (AHS))
  10. ПСМ получает PARes.
  11. ПСМ проверяет цифровую подпись полученного PAREs (осуществляет проверку сам или отправляет соответствующий запрос к отдельному серверу валидации)
  12. Если аутентификация прошла успешно, мерчант начинает процесс авторизации, соответственно взаимодействуя со своим эквайером.

После шага 12, эквайер обрабатывает запрос на авторизацию и пересылает ответ к мерчанту.




EMV

EMV (Europay, MasterCard и VISA) — международный стандарт для операций по банковским картам с чипом. Этот стандарт разработан совместными усилиями компаниями Europay, MasterCard и Visa, чтобы повысить уровень безопасности финансовых операций.

Основное отличие для пользователя карты стандарта EMV — это преимущественное требование ввода ПИН-кода при проведении любого платежа через терминал (например, в магазинах, ресторанах). Тем не менее, данное требование не является обязательным. При желании банк-эмитент может настроить CVM-лист чип-карты так, что в первую очередь она будет запрашивать подпись.

Стандарт EMV определяет физическое, электронное и информационное взаимодействие между банковской картой и платёжным терминалом для финансовых операций. Существуют стандарты, основанные на ISO/IEC 7816 для контактных карт, и стандарты ISO/IEC 14443 для бесконтактных карт.

Первый стандарт для платёжных карт был создан во Франции в 1989 году и назывался Carte Bancaire B0' стандарт. Также стандарт Geldkarte в Германии предшествовал EMV. EMV полностью совместим с этими двумя стандартами. Франция перевела все выпускаемые на территории страны карты на стандарт EMV.

Наиболее распространённые вариации стандарта EMV:

  • VSDC — VISA;
  • MChip — MasterCard;
  • AEIPS — American Express;
  • J Smart — JCB.

В мае 2010 года было заявлено, что United Nations Federal Credit Union в Нью-Йорке выпустит первую карту стандарта EMV в США.

Особенности и преимущества EMV

Основные преимущества — повышенный уровень безопасности транзакций и возможность более точного контроля транзакций в «оффлайн». Одна из целей EMV — повысить функциональность карт (например, платёжная карта с электронным проездным).

Повышенный уровень безопасности обеспечивается за счёт ухода от визуального контроля (проверка продавцом голограммы, подписи, сверка имени с удостоверением личности) к использованию ПИН-кода и криптографических алгоритмов, таких как Data Encryption Standard, Triple DES, RSA и SHA-1 для аутентификации карты.

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

Уязвимости EMV

Перехватив ПИН-код и клонировав магнитную полосу карты, злоумышленник может произвести оплату копией карты в POS-терминалах, не поддерживающих работу с чипом. При этом снятие наличных в банкоматах и оплата в POS-терминале с поддержкой оплаты по чипу невозможно, так как данные магнитной полосы карты содержат информацию о необходимости использовать чип. Терминал прочтёт эту информацию и потребует использовать чип EMV, который невозможно скопировать таким образом. EMV также не защищает и от мошеннического использования карты в Интернете (если злоумышленнику стал известен 16-значный номер карты, срок её действия и секретный CVC2/CVV2 код) при операциях, не защищённых дополнительно протоколом 3-D Secure. Строго говоря, данные уязвимости присущи не только EMV-картам.

Защищенность

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


Схема Шаума

Здесь мы приводим описание двух схем из работы Шаума. Однако, эти схемы достаточно просты и хорошо иллюстрируют основные идеи и методы, лежащие в основе банковских криптографических протоколов.[АнВаСиЯщ97]

В обеих схемах банк вырабатывает два больших простых числа p и q и публикует их произведение N = pq, сохраняя множители в секрете (инициализация схемы электронной подписи RSA). Кроме того, выбирается и публикуется некоторая односторонняя функция f: Zn → Zn. Устанавливается соглашение, согласно которому экспоненте, равной i-му нечетному простому числу, соответствует номинал в 2^(i-1), скажем, центов. Т. е., предъявитель пары (n,f(n)^(1/3) mod N) является владельцем электронной банкноты достоинством в 1 цент. Если в этой паре вместо корня кубического присутствует корень 7-ой степени, то банкнота имеет достоинство 4 цента, а если 21-ой степени -- то 5 центов. Иными словами, для банкноты достоинством S центов необходим корень степени, равной произведению всех простых, соответствующих единицам в двоичном представлении числа S.

Первая схема

В первой схеме все банкноты, выдаваемые банком, имеют одинаковое достоинство. Для простоты изложения будем предполагать, что оно равно 15 центам. Тогда подпись банка на банкноте, это -- корень h-ой степени, где h=3*5*7*11. Для этой схемы нужен также еще дополнительный модуль RSA N1, который используется в работе с так называемой копилкой (см. ниже). Этот модуль выбирается и публикуется таким же образом, как и модуль N.

В транзакции снятия со счета покупатель выбирает случайное значение n1 ϵ Zn и вычисляет f(n1). Ему нужно получить подпись банка на этой банкноте, т. е. вычислить f(n1)^(1/h). Но просто послать значение f(n1)банку покупатель не может, поскольку для снятия денег со счета он должен идентифицировать себя. Поэтому, если банк получает f(n1), он в дальнейшем всегда узнает данную банкноту и неотслеживаемость будет потеряна. Решение проблемы состоит в использовании затемненной подписи: покупатель выбирает случайное значение r1 ϵ Zn, r1 ≠ 0, вычисляет f(n1)r1^h mod N и посылает это значение банку. Множитель r1^h часто называют затемняющим множителем. Банк вычисляет значение f(n1)^(1/h)r1 mod N и возвращает его покупателю. Покупатель легко "снимает" затемняющий множитель и получает подписанную банкноту f(n1)^(1/h) mod N.

Предположим, теперь, что покупатель желает заплатить продавцу 5 центов. Для этого он вычисляет f(n1)^(1/3*7) mod N, просто возводя полученную банкноту в 55-ую степень, и создает копилку, выбирая случайное значение j и вычисляя f(j)s1^(5*11) mod N1. Здесь опять s1^(5* 11)-- затемняющий множитель. Транзакция платежа начинается с пересылки значений n1, f(n1)^(1/3* 7) mod N, f(j)s1^(5* 11) mod N1, а также суммы платежа (5 центов) продавцу. Продавец, в свою очередь, передает всю эту информацию банку. Банк легко проверяет, что пара (n1,f(n1)^(1/3*7)) представляет собой подлинную банкноту достоинством 5 центов. Он проверяет по специальному регистру, не была ли банкнота с номером n1 потрачена ранее. Если нет, записывает в регистр вновь полученную банкноту и посылает продавцу уведомление о завершении транзакции платежа, а также "сдачу" 10 центов для покупателя, возвращаемую через копилку: f(j)^(1/5*11)s1 mod N1.

Безопасность схемы

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

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

Предположим, что покупатель получил в банке вторую банкноту с номером n2и желает заплатить тому же или другому продавцу сумму в 3 цента. Тогда в транзакции платежа он может использовать копилку со "сдачей", оставшейся после первого платежа, и послать продавцу n2, f(n2)^(1/3*5) mod N, f(j)^(1/5* 11)s2^(7*11) mod N1. Платеж выполняется таким же образом, как было описано выше, и в результате покупатель получит копилку f(j)^(1/5*11*7*11) mod N1.

В транзакции депозита покупатель кладет накопленную в копилке сумму на свой счет в банке. Для этого он посылает банку значения j, f(j)^(1/5* 7* 11* 11) mod N1 и указывает сумму. Банк проверяет копилку так же, как банкноту, т. е. устанавливает наличие всех корней с объявленными покупателем кратностями, а также проверяет, что копилка с номером j не использовалась ранее ни в одной транзакции депозита. Если все условия выполнены, банк вычисляет сумму, находящуюся в копилке, и зачисляет ее на счет покупателя.

Чем больше платежей выполняется с одной и той же копилкой и чем больше клиентов в системе, тем ниже шансы банка отследить действия каждого из них.

Вторая схема

Вторая схема, основывается на тех же идеях, поэтому здесь описываются только ее отличия от предыдущей. Во-первых, используется только один модуль (в описаниях мы его опускаем). Во-вторых, банк может выдавать банкноты различного достоинства. А именно, пусть h, как и выше, соответствует максимальному достоинству банкноты и g | h. Тогда банк может выдать банкноту, достоинство которой соответствует числу g. Кроме того, пусть dсоответствует сумме платежа, где d | g, и c = g/d-- "сдаче".

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

 Img826.gif

Банк возвращает покупателю (через продавца) значение

Img827.gif

Число m может быть выбрано как f(n1) для некоторого нового значения n1, что позволяет в дальнейшем использовать "сдачу" в новом платеже без необходимости промежуточного депозита и снятия со счета. Т. е., "сдача" становится такой же электронной банкнотой, как и сумма, снятая со счета.

Множитель f(f(n)^(1/c))в значении, возвращаемом банком, необходим для того, чтобы покупатель мог вычислить m^(1/c) только тогда, когда он знает f(n)^(1/c).

Транзакция депозита в данной схеме ничем не отличается (с криптографической точки зрения) от транзакции платежа.

"Сдача", возвращенная в транзакции платежа, может быть разделена на несколько банкнот. Предположим, например, что в последнем платеже было d=5* 11, c=3* 7, а значение m было сформировано как m=f(n1)^3f(n2)^7. Тогда, после снятия затемняющих множителей со значения, возвращенного банком, будет получена величина a=m^(1/21). После этого покупатель вычисляет

uImg837.gif
vImg838.gif
Img839.gifImg840.gif
Img841.gifImg842.gif	   

В результате получены две банкноты достоинством в 1 и 4 цента соответственно.

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

Схема Брандса

Схема Брандса выделяется из всех автономных систем электронных платежей благодаря, во-первых, своей высокой эффективности, а во-вторых, попыткой обосновать ее стойкость.[АнВаСиЯщ97]

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

Всюду ниже мы будем обозначать покупателя через U, а продавца -- через S.

Инициализация системы

Банк выбирает тройку порождающих Img903.gif группы Gq простого порядка и число Img905.gif. Кроме того, он выбирает две хэш-функции (в работе они названы хэш-функциями с трудно обнаружимыми коллизиями) H и H0. H отображает пятерки элементов группы Gq в Img177.gif, а H0 -- пары элементов Gq -- в Zq. Кроме того, H0 зависит, например, от некоторого значения ID, идентифицирующего S, а также -- от времени и даты t выполнения транзакции. Банк публикует описание группы Gq (простые числа p и q, если Img907.gif), тройку Img903.gifи функции H, H0, в качестве своего открытого ключа. Секретным ключом банка является число x. В описаниях протоколов появляется также еще некоторое значение h, которое в работе нигде не определяется, но из анализа протоколов можно понять, что h=g^x и это значение должно публиковаться как часть открытого ключа. Подпись sign(A,B) банка для пары (A,B), группы Gq есть четверка (z,a,b,r), где z,a,b ϵ Gq, r ϵ Zq, такая, что

Img915.gif

Открытие счета

U выбирает число Img916.gif и вычисляет Img917.gif. Если Img918.gif, то U передает значение I банку, а u1 хранит в секрете. Для безопасности банка существенно, чтобы значения I были различными для разных клиентов. Банк вычисляет Img920.gif и передает это значение U.

Снятие со счета

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

1. Банк выбирает число Img921.gif и посылает Img922.gifи Img923.gif клиенту U.

2. U выбирает три числа Img924.gif, Img925.gif и вычисляет Img926.gif, Img927.gif и Img928.gif. Кроме того, U выбирает числа Img929.gif и вычисляет Img930.gif и Img931.gif. Затем он вычисляет Img932.gif и посылает запрос Img933.gif банку.

3. Банк посылает ответ Img934.gif и снимает со счета U соответствующую сумму. U принимает ответ тогда и только тогда, когда Img935.gif и Img936.gif. Если эти условия выполнены, U вычисляет Img937.gif. Пара (A,B) и подпись банка (z',a',b',r') для нее образуют электронную монету.

Платеж

В транзакции платежа U и S выполняют следующий протокол.

1. U посылает S электронную монету: A, B, sign(A,B).

2. Если A ≠ 1, то S вычисляет запрос Img940.gif, где ID -- идентификатор S, а t -- дата и время транзакции. S посылает U значение d.

3. U вычисляет ответы Img941.gif и Img942.gif и посылает их S. S принимает монету тогда и только тогда, когда sign(A,B). является подписью (A, B)для и Img943.gif.

Депозит

S посылает банку A, B, sign(A,B),(r1,r2), а также дату и время транзакции платежа t. Если A = 1, то банк не принимает монету. В противном случае он вычисляет d, используя полученные данные и идентификатор ID продавца S. Затем банк проверяет, что Img943.gif и что sign(A,B) является подписью для (A,B). Если все корректно, то банк проверяет, не была ли монета потрачена ранее. Если нет, то банк запоминает (A,t,r1,r2) и кладет монету на счет S.

Если данная электронная монета уже была потрачена ранее, то банк имеет в своем распоряжении две несовпадающие тройки (d, r1, r2) и (d', r'1, r'2) и может вычислить идентификатор нарушителя Img949.gif.

Из утверждений, сформулированных в работе, вытекает, в предположении трудности задачи дискретного логарифмирования и стойкости протокола аутентификации Шнорра, безопасность вышеприведенных протоколов для всех участников. Это означает, что: клиенты не могут создавать электронные монеты без участия банка; если продавец действует в транзакции платежа согласно протоколу, то покупатель не может обмануть его, заплатив фальшивой монетой; если покупатель действует согласно протоколам, то банк не может ложно обвинить его, предоставив в арбитраж сфабрикованное доказательство повторной траты одной и той же электронной монеты; сообщения, посылаемые в ходе выполнения протоколов, не требуют шифрования, т. е. противник, подслушивающий транзакции снятия со счета, не может сам создать электронную монету, а подслушивание транзакции платежа не помогает выполнить депозит перехваченной монеты на другой счет. Кроме того, при некотором предположении, которое представляется более сильным, чем предположение о трудности задачи Диффи-Хеллмана, доказывается, что нарушитель, дважды потративший одну электронную монету, всегда будет идентифицирован.

SET

Secure Electronic Transaction (SET, Безопасные электронные транзакции) — это стандартизированный протокол для проведения операций по кредитной/банковской карте через небезопасные сети (например Интернет). SET это не сама платежная система, а набор правил и протоколов безопасности (цифровых сертификатов, криптографических технологий) для аутентификации осуществляемых транзакций. Это позволяет пользователям безопасно использовать кредитные/банковские карты в открытой сети. Однако, SET не обрела популярности. VISA теперь продвигает XML-протокол 3-D Secure.

Преимущества и недостатки протокола SET

Протокол SET (Secure Electronic Transaction) был разработан консорциумом во главе с Visa и Master Card. Официальной датой рождения стандарта SET является 1 февраля 1996 г. В этот день Visa International и MasterCard International совместно с рядом технологических компаний (включая IBM, GlobeSet) объявили о разработке единого открытого стандарта защищенных Интернет-расчетов. SET представляет собой набор протоколов, предназначенных для использования другими приложениями (такими, как Web-браузер). Он был рекомендован как стандарт обработки транзакций, связанный с расчетами за покупки по кредитным картам в Интернет.

В декабре 1997 г. была создана некоммерческая организация SETCo LLC, призванная координировать работы по развитию стандарта и осуществлять тестирование и сертификацию предлагаемого на рынке программного обеспечения с целью контроля над соответствием этого программного обеспечения спецификациям SET.

В основе системы безопасности, используемой SET, лежат стандартные криптографические алгоритмы DES (Data Encryption Standard — стандарт шифрования данных) и RSA (Rivest-Shamir-Adleman — алгоритм цифровой подписи Райвеста-Шамира-Адлемана). Инфраструктура SET построена в соответствии с инфраструктурой открытого ключа (Public Key Infrastructure, PKI) на базе сертификатов, соответствующих ISO-стандарту X.509. Протокол SET не привязан ни к HTTP, ни к Web-коммерции. Его можно использовать с самыми различными протоколами. SET шифрует сами сообщения, а не канал связи, как, например. SSL. Оригинальный протокол SET подразумевает следующую схему взаимодействия между участниками процесса платежа в Интернете.

Владелец карточки и магазин устанавливают у себя программное обеспечение - Cardholder Wallet и Merchant Server соответственно. Эквайер должен установить себе Payment Gateway.

Всем участникам необходимо получить Certificate Authority так называемые сертификаты, которые используются для формирования цифровых подписей и шифрования данных. Для этого участники запрашивают и получают сертификаты от сертифицирующих организаций (SETCo). SET-сертификат Интернет-Магазина содержит идентификационные параметры торговой точки. SET-сертификат Покупателя – это электронный документ, который содержит зашифрованные параметры платежной карты (её номер, имя владельца и т. д.).

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

Преимущества использования SET

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

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

клиенты не пострадают от перехвата номера кредитки и от покупки у несуществующих продавцов.


Недостатки использования SET

Дороговизна решения и высокие эксплуатационные расходы

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

Очень существенный минус в том, что владельцу карточки требуется установить на свой компьютер довольно сложный в настройке Cardholder Wallet. Оригинальный SET предполагает, что все участники платежа в Интернете (владелец карточки, магазин, банк-эквайер) получили в Certificate Authority так называемые сертификаты, что существенно усложняет процедуру покупки и приводит к удорожанию транзакций. Стандарт MIA SET - это несколько упрощенный вариант протокола SET (Secure Electronic Transaction).

Полноценное использование SET-технологий, предполагает наличие SET-сертификатов у всех участников сделки. Но существует также упрощённый вариант – технология MIA SET, которая также признана международными платёжными систeмами.

MIA SET предполагает, что владельцу карточки и магазину не нужно устанавливать у себя сложного программного обеспечения. Фактически, Cardholder Wallet перекочевывает на сервер эмитента, а Merchant Server - на сервер эквайера. Эмитент и эквайер обмениваются между собой по SET от имени владельца карточки и магазина. Эмитент при этом может на свое усмотрение использовать любые средства идентификации владельца карточки (пароль, смарт-карта и т.д.). Это же правило распространяется и на эквайера при идентификации магазина. Благодаря этому MIA SET более прост во внедрении и эксплуатации чем традиционный SET. Важно отметить, что Visa объявила о том, что некогда популярный протокол SET уже не отвечает современным требованиям безопасности и должен быть замещен более совершенными системами, такими как — Verified by Visa, работающий на основе протокола 3D Secure и Secure Payment Application (SPA) от MasterCard.

Процедуры протокола SET

  1. Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.
  2. Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе - номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).
  3. Продавец выделяет часть, адресованную банкиру, и направляет ее по месту назначения. Программа SET WEB-сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка.
  4. Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.
  5. Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.
  6. Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.
  7. WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.
  8. Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.
  9. Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).

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


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

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

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

Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной. Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина. Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид: СП = [B, ID, AП, PKП, E, IП]SKB где B - идентификатор (имя) брокера; ID - идентификатор покупателя; AП - адрес доставки; PKП - общедоступный ключ покупателя; Е - время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП - дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB - секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером. Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии). Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению: wi = H(wi+1) для i= n-1, n-2,…,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H - представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера. i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца. Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж. В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.

Протокол для работы с кредитными картами CyberCash

Протокол CyberCash (RFC-1898, D. Eastlake, CyberCash Credit Card Protocol Version 0.8. February 1996) предназначен для осуществления платежей через Интернет посредством кредитных карточек. CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом. CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.

Обзор системы

Система CyberCash предназначенадля обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash. Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть. Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.

Соображения безопасности

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

Аутентификация и идентификация личности

Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для "персон" покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой. В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ. Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту. Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.

Конфиденциальность

Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа. Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции.

Работа с кредитной картой

При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.) При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.

Формат заголовка общего сообщения

Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет. В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена.

Формат сообщения

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

Детали формата

Заголовок содержит одну строку, которая выглядит следующим образом $$-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.

Части тела сообщения

Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности. Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label). Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа. Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк. Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.

Открытая часть

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

Скрытая часть

Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются. Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные. Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением. Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто.

Завершающая часть

Завершающая секция служит для выделения конца сообщения. Она содержит несколько полей разделенных "-".

  1. "$$" - строка литералов.
  2. "CyberCash" - строка литералов (не чувствительна к регистру).
  3. "End" - строка литералов (не чувствительна к регистру).
  4. Контрольная сумма передачи.
  5. "$$" - строка литералов.

Контрольная сумма передачи вычисляется согласно алгоритму MD5. Номер версии в начальной строке содержит исключительно печатные символы и размещается после второго $$ этой строки и до первого $$ завершающей строки. Заметим, что все пробелы (SP, TAB, LF и CR) не включаются в этот хэш. Терминаторы меток (: или ;) включаются туда, также как любые строки #-комментариев. Заметим также, что опционная символьная строка "Extra" в начальной $-строке в хэш не включается. Основной идеей является обеспечение корректности передачи, избегая зависимости от шлюзов (gateways) или любой обработки, которая может изменить завершающую строку или преобразовать символы табуляции, пробелы или символы разрыва строки.

Примеры сообщений

Простое сообщение от клиента: $$-CyberCash-0.8-$$ id: DONALD-69 transaction: 918273645 date: 199512250102 cyberkey:CC1001 opaque: GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4 elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9 EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8= $$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$ Сообщение от продавца: $$-CyberCash-a.b.c-extra-$$ merchant-ccid: acme-69 merchant-date: 19951231115959 merchant-transaction: 987654321 label: value labelx: multiple line value...

  1. Комментарий
  2. еще одна строка комментария

label; text with a real multi-line format ! merchant-cyberkey: CC1001 merchant-opaque: C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y /iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J 66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ 6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC sDrWehG/UbFTPD26trlYRnnY $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

Подписи и хэши

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

Цифровые подписи

Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA. Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке. В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения. Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.

Хэш-коды

Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение. Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности. До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются. Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями).


Безопасность электронных платежей

Электронные платежи в банке

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

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

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

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

К достоинствам ОЭД следует отнести:

  • Уменьшение стоимости операций за счет перехода на безбумажную технологию. Эксперты оценивают стоимость обработки и ведения бумажной документации в 3-8% от общей стоимости коммерческих операций и доставки товаров;
  • Повышение скорости расчета и оборота денег;
  • Повышение удобства расчетов.

Банки в США и Западной Европе уже осознали свою ключевую роль в распространении ОЭД и поняли те значительные преимущества, которые дает более тесное взаимодействие с деловыми и личными партнерами. ОЭД помогает банкам в предоставлении услуг клиентам, особенно мелким, тем, которые ранее не могли позволить себе ими воспользоваться из-за их высокой стоимости.

Частным случаем ОЭД являются электронные платежи - обмен финансовыми документами между клиентами и банками, между банками и другими финансовыми и коммерческими организациями.

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

Электронные платежи применяются при межбанковских, торговых и персональных расчетах.

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

Большинство крупных хищений в банковских системах прямо или косвенно связано именно с системами электронных платежей.

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

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

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

Вопросы безопасности электронных платежей

Для определения общих проблем защиты систем ОЭД рассмотрим в прохождение документа при ОЭД. Можно выделить три основных этапа:

  • подготовка документа к отправке;
  • передача документа по каналу связи;
  • прием документа и его обратное преобразование.

С точки зрения защиты в системах ОЭД существуют следующие уязвимые места:

1. Пересылка платежных и других сообщений между банками или между банком и клиентом;

2. Обработка информации внутри организаций отправителя и получателя;

3. Доступ клиента к средствам, аккумулированным на счете.

Одно из наиболее уязвимых мест в системе ОЭД – пересылка платежных и других сообщений между банками, или между банком и банкоматом, или между банком и клиентом. При пересылке платежных и других сообщений возникают следующие проблемы:

  • внутренние системы организаций Получателя и Отправителя должны быть приспособлены к получению/отправке электронных документов и обеспечивать необходимую защиту при их обработке внутри организации (защита оконечных систем);
  • взаимодействие Получателя и Отправителя документа осуществляется опосредованно – через канал связи. Это порождает три типа проблем:

1. взаимного опознавания абонентов (проблема установления аутентификации при установлении соединения);

2. защиты документов, передаваемых по каналам связи (обеспечение целостности и конфиденциальности документов);

3. защиты самого процесса обмена документами (проблема доказательства отправления/доставки документа);

  • в общем случае Отправитель и Получатель документа принадлежат к различным организациям и друг от друга независимы. Этот факт порождает проблему недоверия – будут ли предприняты необходимые меры по данному документу (обеспечение исполнения документа).

В системах ОЭД должны быть реализованы следующие механизмы, обеспечивающие реализацию функций защиты на отдельных узлах системы ОЭД и на уровне протоколов высокого уровня:

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

Полнота решения рассмотренных выше проблем сильно зависит от правильного выбора системы шифрования. Система шифрования (или криптосистема) представляет собой совокупность алгоритмов шифрования и методов распространения ключей. Правильный выбор системы шифрования помогает:

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

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


Глоссарий

Библиографический указатель

Перейти к списку литературы.

Вернуться к оглавлению

Аблеков В., Мороз М., 2013