8.7.3. Примеры протоколов

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

E-cash

Существует несколько электронных платежных систем, которые базируются на концепции цифровых денег. Одной из наиболее известных является система e-cash, описание которой можно найти в [94, 95]. Основной целью при разработке этой системы было введение анонимности в платежи. Чтобы понять, как работает сис­тема e-cash, рассмотрим сначала не анонимную систему на основе наличных де­нег.

Допустим, Алиса хочет купить некоторые товары у Боба через сеть на общую сумму 12 долларов, используя цифровые деньги. Сначала она связывается со своим банком и просит снять 12 долларов с ее счета. Банк создает цифровые деньги в форме подписанных виртуальных банкнот на определенную сумму, причем каждая банкнота имеет уникальную ассоциированную с ней подпись. Так, например, виртуальная банкнота в 10 долларов может быть подписана спе­циальным, принадлежащим банку закрытым ключом К~\о, а однодолларовая банк­нота — другим специальным закрытым ключом К\. Для предотвращения копи­рования виртуальных банкнот каждая из них имеет уникальный серийный но­мер, с помощью которого банк может проверить факт повторного использования банкноты.

В нашем примере Алиса получает в своем банке десятидолларовую банкноту и две однодолларовых, которые позднее передает Бобу. По подписи банка Боб может проверить, что банкноты хотя и виртуальные, но не поддельные. Однако для проверки на попытку повторного использования банкнот ему необходимо связаться с банком, который по серийным номерам проверит, не применялись ли эти банкноты для оплаты раньше. Если это не попытка повторного использова­ния виртуальных банкнот, Боб отправляет сообщение ОК как знак того, что го­тов принять эти деньги. Отметим, что Бобу все равно нужно связаться с банком, поскольку банк должен также проверить целостность банкнот.

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

Эту систему необходимо дополнить, чтобы не нужно было отслеживать, ка­кие цифровые банкноты кому были переданы, сохраняя при этом защищенность банкнот от попыток подделки или повторного использования. Как показано в [93], такая защита может быть осуществлена при помощи так называемой сле­пой подписи (blind signature). Принцип, лежащий в основе слепой подписи, про­ще всего объяснить на примере конверта, покрытого изнутри копировальной бу­магой. [94]. Если положить внутрь конверта обычную бумагу, все, написанное на конверте, отпечатается и на бумаге внутри него.

Для Алисы, получающей свою десятидолларовую банкноту, подписанную ее банком, это выглядит так, будто она помещает банкноту в конверт с копироваль­ной бумагой и просит свой банк поставить подпись на конверте. Банк снимает 10 долларов со счета Алисы и ставит свою подпись на конверте. После этого банк никогда не увидит саму банкноту, но в любой момент может прочитать свою де­сятидолларовую подпись, стоящую на конверте. После этого Алиса может исполь­зовать банкноту как обычные деньги. Эта схема отлично работает, если учесть, что банк ежедневно подписывает множество десятидолларовых виртуальных банкнот. В этом случае, когда Боб передаст в банк десятидолларовую банкноту и потребует перечислить 10 долларов на свой счет, отследить Алису по этой банк­ноте будет невозможно.

Чтобы понять, как работают эти подписи в алгоритмах RSA, используем ту же нотацию, что и ранее при описании принципов RSА: п = р х q_f где р и q — два боль­ших простых (и секретных) числа. Число d вычисляется на основе этих простых чисел как d = (р - I) * (q - I), а. е получается следующим образом: е х d = 1 modz.

Предположим, Алиса хочет получить со своего банковского счета десятидол­ларовую банкноту. Фактически она сама создает себе эту банкноту, но нуждает­ся в банковской подписи для ее подтверждения, причем так, чтобы банк впо­следствии был не в состоянии проследить ее движение. Она создает случайное число k между 1 и п и делает т нечитаемым, скрывая его в сообщении

t = mk^e mod п.

Банк подписывает сообщение t своим защищенным ключом К\§ (в нашем примере — d), превращая его в сообщение t^d. Отметим, что мы используем клю­чи, специально предназначенные для десятидолларовых банкнот. Для изготовле­ния банкнот другого достоинства требуются другие ключи. Когда Алиса получит сообщение t^d, она раскроет его, делая следующие вычисления:

s = t^d/k mod п = (mk^e)^d/k mod п = m^dk^ed~¹ mod n = m^d mod n.

С этого момента она имеет в своем распоряжении десятидолларовую банкно­ту, которая подписана банком так, что банк никогда ее не видел. Теперь Алиса может использовать m^d в качестве десятидолларовой банкноты для того, чтобы заплатить Бобу, как это показано на рис. 8.44.

Хотя этот протокол в общем хорош, в нем все же имеются некоторые пробле­мы. Основная состоит в том, чтобы защититься от повторного использования де­нег. Хотя банк может легко проверить, не применялась ли банкнота т в качестве средства платежа ранее, нет сомнения, что было бы полезно наказывать людей, пытающихся делать это снова. Другими словами, хорошо было бы разработать такую схему, при которой попытка повторного использования предоставляла бы информацию, позволяющую идентифицировать человека, пытающегося это сде­лать. Детали подобной схемы можно найти в [94, 404].

Защищенные электронные транзакции

Рассмотрим теперь электронную платежную систему для транзакций с кредит­ными картами. Протокол защищенных электронных транзакций (Secure Electronic Transactions, SET) — это совместная попытка Visa и Mastercard в кооперации с не­сколькими другими организациями, такими как Netscape и Microsoft, разработать стандартный способ покупки товаров через Сеть с использованием кредитных карт. SET — открытый стандарт. Это означает, что вся информация о протоколе опубликована (информацию по SET можно найти по адресу http://www.setco.org).

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

В SET использована важная новая концепция двойной подписи. Прежде чем мы перейдем к обсуждению различных этапов протокола, нам следует в ней ра­зобраться. Рассмотрим следующую проблему: Алиса хочет купить у Боба не­которые товары, пользуясь кредитной картой. Все, что она должна сделать при этом, — отправить Бобу информацию о заказанных товарах вместе с данными о своей кредитной карте. Боб должен быть в состоянии передать эти данные в банк для завершения процесса оплаты за товары. Нам необходимо связать за­каз и платежную информацию.

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

Решение будет следующим. Пусть гп\ и т₂ обозначают соответственно заказ и платежную информацию. Двойная подпись (dual signature) состоит в построении дайджеста сообщения md_{ = Н(гп\) для гп\ и md₂ =H(m₂) для m₂ с последующим построением третьего дайджеста путем слияния md\ и md₂: md_ci_uai⁼ H(concat(md_[} md₂)). Этот дайджест md₍j_uui затем подписывается Алисой с использованием ее закрытого ключа. Теперь Алиса посылает Бобу сообщение mdduah nidi* K~\(?nd₍j_uai)], которое позволяет ему идентифицировать Алису и убедиться, что именно она поставила подпись под всем сообщением. Однако Боб не в состоя­нии прочесть тяг. Для обозначения двойной подписи сообщений тп\ и т₂, из кото­рых открыто только Шь мы используем запись [m_l |т₂] _A:

[m_l |т₂] _A =[ m_l ? Н(т₂), H(concat(m_l} т₂))_} K_A(H(concat(m_h т₂)))].

Давайте обсудим теперь основы протокола SET. Этапы протокола иллюстри­рует рис. 8.45.

Мы предполагаем, что Алиса хочет заплатить Бобу. Первое, что ей необходи­мо сделать, — послать Бобу заказ и платежргую информацию. На рисунке это действие показано в виде сообщения 1. Информация о заказе обозначена как order, информация о платеже — как pay_injо. Алиса создает дважды подписанное сооб­щение [order \ pay_info]_A. Платежная информация, которая должна быть прочи­тана только в банке, шифруется сеансовым ключом К_А,ь_апЬ который банк создал для Алисы. Этот ключ также посылается Бобу, но зашифрованный открытым ключом банка Kl_ank-

После того как Боб проверит сообщение Алисы, он пересылает платежную информацию в банк и запрашивает авторизацию оплаты. При этом он создает се­ансовый ключ Кв\,ьапЬ который использует для шифрования своего запроса auth. Этот запрос пересылается в банк вместе с информацией Алисы об оплате, а ключ Кв 1,bank шифруется открытым ключом банка. Все это показано на рисунке как со­общение 2.

Допустим, что банк признал действительность оплаты. В этом случае он воз­вращает Бобу подписанное сообщение о прохождении авторизации auth_OK, зашифрованное новообразованным сеансовым ключом К&2МпЬ который, в свою очередь, зашифрован открытым ключом Боба. Этот ответ, обозначенный как со­общение 3, содержит также и так называемое сообщение о получении (capture message), которое потребуется позже, когда Боб действительно будет получать деньги из банка. Сообщение о получении однозначно ассоциируется с конкрет­ной транзакцией посредством идентификатора транзакции. Этот идентификатор также используется и в сообщениях order и payjnfo. Сообщение о получении подписывается банком и шифруется при помощи третьего сеансового ключа,

КвЗ,Ьапк-

Когда Боб получает от банка «добро», он посылает Алисе подписанное под­тверждение, показанное на рисунке как сообщение 4.

Теперь Боб хочет получить свои деньги. Он посылает банку сообщение payjne вместе с ранее полученным сообщением о получении. И вновь для шифрования сообщения payjne создается и используется новый сеансовый ключ. Это сооб­щение 5.

И, наконец, после того как банк проверит сообщение о получении, он возвра­щает Бобу подтверждение сар_ОК, зашифрованное сеансовым ключом Квъмпк-

Хотя на рис. 8.45 это и не указано, в протоколе SET на каждом из шагов вы­полняется аутентификация путем посылки сертификатов всякий раз, когда воз­никает необходимость в использовании открытого ключа. С этой целью в прото­коле задействуется иерархия сертифицирующих организаций, сходная с ранее обсуждавшейся иерархией моделей доверия в почте РЕМ. Детали этой модели, равно как и протокола, можно найти в [407].