Интегрированные сети ISDN
Модель электронных переводов
Модель электронных переводов
Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет.
Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.
Не менее важную роль имеет конфиденциальность любых финансовых операций.
Это не следует рассматривать как исчерпывающий список требований к безопасности и конфиденциальности.
4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)
Разработчики технологии WWW, HTML и XML (группа W3C;
http://www.w3.org/TR/WD-mptp-951122) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint – Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно.
Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.
Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.
При разработке протокола принимались во внимание следующие риски.
Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной.
Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина.
Схема PayWord является кредитной и практически реализует схему электронных монет.
Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид:
СП = [B, ID, AП, PKП, E, IП]SKB
где B – идентификатор (имя) брокера; ID – идентификатор покупателя; AП – адрес доставки; PKП – общедоступный ключ покупателя; Е – время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП – дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB – секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером.
Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии).
Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению:
wi = H(wi+1) для i= n-1, n-2,…,0.
Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H – представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера.
i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца.
Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж.
В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.
4.6.2.2. MicroMint
MicroMint (при вольной интерпретации это выражение можно перевести как микромонетный двор) представляет собой еще одну платежную систему, базирующуюся на модели электронных монет. Здесь не используется общедоступный ключ шифрования. Электронные монеты в этой схеме формируются брокером, который продает их пользователям. Пользователи передают эти монеты продавцам в качестве оплаты товаров или услуг.
Продавцы возвращают эти монеты брокеру, который осуществляет перевод реальных денег на счет продавца.
Электронная монета представляет собой последовательность бит, которая может быть легко проверена, но которую достаточно трудно сформировать. Алгоритм MicroMint устроен так, что формирование большого числа монет стоит дешевле (из расчета на одну монету), чем формирование одной или нескольких. Брокер формирует партию монет, например раз в месяц. При этом действие прежней партии монет истекает, и они не могут более использоваться. Продавцы возвращают полученные монеты в конце каждого дня.
Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.
k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.
H(x1)=H(x2)=…=H(xk)=y
Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет. Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации.
Предположим, что брокер хочет иметь чистый доход размером в 1 млн.
долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов.
Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA – программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу.
При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя.
Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется.
Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996).
Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет.
Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.
Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной.
Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно.
Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h – хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты.
При малых же группах брокер будет вынужден производить слишком большую вычислительную работу.
Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 – yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным.
Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев.
Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.
4.6.2.3. Безопасный протокол электронных платежей SET
Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. “SET - Secure Electronic Transaction Specification”). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет.
Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:
На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:
Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники.
Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца.
Практика электронной торговли позволяет выделить семь этапов сделки.
| Этап | Действие |
| 1 | Владелец карты просматривает позиции каталога продавца: |
| 2 | Владелец карты выбирает понравившийся товар или услугу. |
| 3 | Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов). |
| 4 | Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт. |
| 5 | Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов. |
| 6 | Продавец запрашивает платежную авторизацию от эмитента карты. |
| 7 | Продавец посылает подтверждение заказа. |
| 8 | Продавец доставляет заказанный товар или услугу |
| 9 | Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты. |
Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии.
Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие.
Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры – код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму.
Каждая цифра номера умножается на его “вес”. Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы).
Схема взаимодействия субъектов в протоколе SET показана на Рисунок 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.
