coitl ,
3. Системы электронныхплатежей |
209 |
На шаге (2) плательщик доказывает банку, |
что он знает id с |
hj = g/'/ . Для этого используется протокол аутентификации Шнор
ра, где плательшик выступает в роли доказывающего, банк - в роли
проверяющего.
На шаге (3) этого протокола плательщик подписывает (применяя skp ) сообщение т, которое впоследствии будет использовано для снятия им своих средств со счета. Если банк позднее сможет пока- зать величину id с g:d g2 =т, это будет служить доказательством то
го, что монета этого плательщика потрачена дважды.
Протокол регистрации получателя платежа (табл. 3.5). Как отмечалось ранее, каждый получатель платежа в СЭП Брандса дол жен обязательно использовать запрос, отличный от другого получа теля. Для этого желательно построить протокол так, чтобы каждый получатель регистрировался под уникальным идентификатором lllRr_ ripiellt. Получатель в СЭП Брандса не нуждается в каких-либо крипто графических ключах.
Таблица З.5. Протокол регистрации получателя платежа
Баи1\ В |
|
|
Получатель R |
|
|
IdRt:c'iPit:nr - |
ДОЛЖНО быть уникально |
~[ IdRl'ciJJiem ] ДЛЯ каждого получателя платежа
Протокол снятия со счета (табл. 3.6). Для каждого плательщика банк всегда подписывает (при помощи затемненной подписи) одно и то же сообщение т, которое было согласовано выше, в протоколе открытия счета. Так как при этом z получается одним и тем же для
каждого выполнения протокола, плательщик может хранить эту ве
личину у себя и шаг (0.0) становится ненужен. Но, конечно, новые величины w и (s,t,u,v) должны выбираться заново при каждом вы полнении протокола снятия со счета. На шаге (0.1) плательщик ге- нерирует два дополнительных случайных числа - YI' У2 (modq).
Вместе с (Xt,x2) существует уже четыре секретных переменных, для которых каждый платеж разглашает два линейных уравнения. В то же самое время набор величин (XI,x2,Yl,Y2) можно рассматривать как секретный ключ монеты sk которым плательщик (как анонимный владелец этой монеты) может впоследствии подписывать свои пла-
тежи. Он полагает pkcoin = g(1 . gI2 . Вместе с тем т' = =g;1 . g;2 (mod р). Таким образом, величины (т, pkcoil1) можно рас-
210 Запечников С. В. Криптографическиепротоколы и их примененив
сматривать как открытый ключ монеты, соответствующий SkcoiJl' Чтобы зафиксировать принадлежность pkm ill определенной монете, эта величина включается в запрос плательщика банку путем вычис- ления хеш-кода: / =}zasll (11/, pk m ill , z',a',b'). Для разрешения кон
фликтныхситуацийпредусмотрено,что плательщик,используясвой skp , подписывает расходный ордер, куда включает нужный ему но-
, |
v |
минап монеты и величину с |
, для которой ОН хочет получить ответ. |
Этот расходный ордер должен быть послан в банк на шаге (2) рас сматриваемого протокола. Результатом выполнения протокола явля ется получается плательщиком готовой «электронной монеты»
coin':::: (112', pkCOi/l' а'), где т' называется идентификатором монеты,
|
,=(' |
, |
") - |
подписыо монеты. |
|
|
|
|
|
|
|
|
о |
|
z, |
а, ь',С, r |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица З.6. Протокол снятия со счета |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Общедост, |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Банк В |
|
величины: |
|
|
|
|
|
Плательщик Р |
|
|
|
|
|
|
|
|
p,Q,f!,/z,f!J,f!2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
0.0 |
z=mx |
|
|
[ z17 |
|
|
|
|
|
|
|
|
|
|
|
|
|
0.1 |
|
|
|
|
|
s,u,v'YI'Y2EII Zq' |
(t::O), |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Х1 |
= id . s (mod q), Х2 |
=S ; |
|
|
|
|
|
|
|
|
|
|
|
т':::: т' (l1юd р)[;:: gt! .g;z (ШОd р)]; |
|
|
|
|
|
|
|
|
z'=zS(modp); |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sk,oill = (л;,~ ,УI , У2 ) - секр. ключ монеты; |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[111, pkro i l l = (g{! . gi2 ) J- опер. ключ монеты |
1 |
|
wE R Zq |
|
|
|
а' =а"g~' ; ь' =Ь |
Ш |
.(m'У |
|
|
|
|
|
|
а =!(IV, Ь :::: т" |
|
(а, Ь]7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
с' |
|
т(,, |
|
,а'Ь') |
, |
|
|
|
|
|
|
|
|
|
|
|
|
= 11asll |
|
pkcoill |
, z , |
• |
|
|
|
|
|
|
|
|
|
|
|
|
, |
-1 |
, |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
с=с·и |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
~[c, W.O.] |
W.o.;:; [Sigskl' (<<withdraw», номинал, с'] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 |
|
r = w+cx |
|
|
[ r]7 |
|
|
? |
|
|
? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
я' =ahC |
; т'=bzc , |
|
|
|
|
|
|
|
|
|
|
|
|
r |
, |
= ur |
+ v, |
|
• I |
('k |
сот» СУ |
') |
, |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
сот |
= т, Р |
|
где о' =('z .а',ь',С,,Г')
З. Системы электронных платежей |
211 |
Протокол платежа (табл. 3.7). Здесь плательщик, во-первых, посылает получателю имеющуюся у него монету coin' (компоненты см. выше), а получатель проверяет, что она корректно подписана подписью Шаума - Педерсена. Оставшаяся часть протокола платежа следует рассмотренным ранее идеям. В частности, каждый ответ R разглашает два линейных уравнения в четырех переменных (Хl,х2,У\,У2). Как проверить, что ответы корректны? Как и ранее, это делается проверкой соответствующих уравнений «по экспонентам».
Таблица 3.7. Протокол платежа
|
|
|
|
|
|
|
|
Общедаст. |
|
|
|
ПлательщикР |
вел1II1111lы: |
Попучатель R |
|
|
|
|
|
|
|
|
|
|
p,q,g, Jz, {[ья1 |
|
1 |
. , |
:;: |
( |
I |
k |
го;,,, о |
') |
.тце |
|
|
сот |
|
т, р |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
о |
, |
::::: |
Z .а |
, |
Ь' |
,С," |
') |
|
|
|
|
|
|
|
|
|
|
|
|
('I |
|
|
I |
|
[coill' ]-7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
С:=}юs/1'{m',pk">i".IdRc,~,;"",/1)' |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
~[n ] |
где 11 - |
какое-либо неповто- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ряющееся число (случайное |
|
С:= hns/r'(m'.pk,,~"./dR" "..... /1) |
|
|
|
число, порядк. номер и т. п.) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 |
R:;: (sigpsigJ, |
|
|
|
[R J-7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ |
|
|
' |
|
.g j |
|
. ? ( |
т |
')С |
. pk ' |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
где |
sig\ :;: |
Сх\ |
У\ |
|
gsr |
|
• gSlК1 :;: |
|
|
|
|
|
|
|
|
|
|
|
\ |
|
|
2 |
|
|
ШIII |
|
'sig 2 |
|
:;: СХ2 + У2 |
|
|
|
|
|
|
|
|
|
|
|
Следует обратить внимание, что протокол имеет такую же структуру, как и протокол аутентификации Шнорра (и вообще лю бой протокол аутентификации, основанный на доказательствах с ну левым разглашением знания), за исключением того, что «случайный вариант» (Х/,Х2) уже дан в виде (yj,Y2), Соответствующие открытые величины - т' = g;l . g~2 И pkcoin = g{1 . g;2 . Величина п в протоко ле - это элемент числовой последовательности, который гарантиру
ет получателю, что тот не сможет принять одну и ту же монету два жды с одним и тем же запросом. Линейная комбинация в ответе дос- тигается скалярным умножением и сложением пар: R:;;: С(х, 'Х2) + +(Уl'У2)· Если все вычисления проведены корректно, мы должны
212 Запечников С. В. Криптографическиепротоколы 11 их примененив
Протокол депонирования монеты (табл. 3.8). В депозите полу чатель пересылает всю свою информацию из платежа, включая klRecipiellt И п. Получив этот пакетданных, банк прежде всего проверя ет действительность монеты точно так же, как это делал получатель монеты в шагах (1) и (3) протокола платежа. При дальнейшем вы полнении проверок он может обнаружить факт повторной траты мо
неты или повторного депонирования монеты, вводя монету в свою
базу данных для сравнения с предыдущими депозитами других по лучателей. Это может быть сделано банком в автономном режиме, причем монеты остаются в базе данных до истечения установленно
го для них срока годности.
|
|
Таблица 3.8. Депозит 11 идентификация |
|
|
|
|
|
|
|
|
|
|
повторной траты монеты |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Получатель R |
|
|
|
|
|
|
|
|
|
|
|
Банк В |
|
1 |
[IdReCil'iml' п,сот',RJ |
7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
|
Проверка действительности монеты: |
|
|
|
с'~"'/Iash (т', pk"o!ll , г',а',Ь') , |
|
|
|
|
|
|
|
,?, |
|
|
, |
( |
т |
'у'? |
, (')("' |
,? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
g' =::;а |
./{, |
|
|
=::;Ь· z |
,т *1, |
|
|
|
|
|
|
|
|
|
? |
|
|
|
|
k |
|
|
|
|
|
|
sig, |
|
sig2 |
..:.. (')С |
стн » |
|
|
|
|
81 |
|
. 82 |
|
- |
171 |
|
• Р |
|
|
|
|
|
где С =::; |
/ШS/I'(т', pklOi/l' Id ReCi{1il'lJ',11 ) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 |
|
|
'd |
|
sig |
1 |
- |
sig; |
|
|
8 |
|
|
|
|
|
|
|
'7 |
|
|
|
|
|
1 |
;;::. |
|
|
|
|
• • |
|
|
|
|
|
|
|
|
Slg2 - |
Slg2 |
|
|
|
|
ею т =81,аg~
Если монета уже есть в базе данных, банк проверяет, имеет ли место совпадение получателя и номера запроса п. Если да, это озна чает, что получатель совершил повторный депозит. Если нет, то (по ка не найдена коллизия функции hash') два запроса С и с: всегда будут различны. Если при ЭТИХ условиях монета уже есть в базе
данных, банк достаетиз нее соответствующиезапросамответы R и
|
З. Системы электронных платежей |
213 |
... |
, |
• |
. |
. ... |
|
Slg, - |
Slg, |
R , |
вычисляет идентификатор |
ld |
=. |
. |
ф и устанавливает, ка- |
|
|
|
Slg2 - |
Slg2 |
кому плательщику принадлежит т = g, ;(1g2. Этот плательщик, следо-
вательно, совершил повторную трату монеты.
Корректность вычисления id может быть выведена непосредст венно из проверочных уравнений. В самом деле, мы, имеем:
g :;Кl • g ~i.'12 |
= (m')С .ре |
и |
|
g j\O;g; •g ~ig; = (тnJ)C' .ре, следовательно, |
з'i,<\-~i{ll' |
з"i~~-sil'~ |
(J)C-C' |
. |
Э |
то |
означает, |
что плательщик знает |
gl' ." • g2'- |
0 _ |
= т |
|
|
|
представление |
|
111' |
В |
виде |
g:"1 . g;" |
с |
и |
_ sig2 |
- sig; |
|
|
|
|
|
|
|
|
v |
Х2 - |
.. |
|
Из рассмотренного ранее своиства удержания |
с-с |
|
|
|
|
|
|
|
|
|
|
идентичности следует, что ..:5..- = id .
Х2
Контрольные вопросы 11 задачи к гл. 3
1. В чем заключаются технические трудности обеспечения ано нимности участников СЭП и автономности их работы?
2.Какие методы борьбы с повторной тратой монеты в СЭП вам известны?
3.Какие виды схем цифровой подписи с дополнительной функ циональностью используются в сэп и для каких целей?
4.Приведите примеры ситуаций, когда анонимность и неотсле живаемость в СЭП могут быть утрачены по причинам, не связанным непосредственно с особенностями применения криптографических
алгоритмов и протоколов.
5. Можно ли в СЭП Шаума использовать затемненную цифро вую подпись, основанную не на задаче RSA, а на других вычисли тельно-сложных задачах?
6.С какой целью в СЭП Шаума могут вводиться ~ючи монет?
7.Подсчитайте примерный объем памяти устройств пользовате лей СЭП Шаума, который может потребоваться для хранения от крытых ключей банка для всех номиналов монет, которые сущест-
214 Запечников С. В. Криптографическиепротоколы и их применение
вуют В российской денежной системе (схема затемненной подписи строится на базе RSA).
8.Каким образом в СЭП Брандса в «электронных монетах» ко дируются идентификаторы плательщиков?
9.Расскажите о существе метода обнаружения повторной траты монеты, применяемого в СЭП Брандса.
10.Существует ли вероятность необнаружения повторной траты монеты в СЭП Брандса?
11.Можно ли предложить какие-либо подходы к определению кратности повторной траты монеты в СЭП Брандса?
Глава 4 КРИПТОГРАФИЧЕСКИЕ ПРОТОКОЛЫ
ВЭЛЕКТРОННОЙ КОММЕРЦИИ
ИВ ЭЛЕКТРОННОМ ДОКУМЕНТООБОРОТЕ
Под термином электронная коммерция чаще всего подразуме
вают прикладное научно-техническое направление, связанное с соз данием информационных систем и отдельных прикладных программ
для поддержки экономических и связанных с ними государственно правовых отношений, осуществляемых с использованием техниче ских средств распределенной вычислительной среды. Важнейшим условием реализации идеи дистанционного взаимодействия участ ников экономических отношений является обеспечение надежной и защищенной перссылки данных, электронных документов и «элек тронных денег», а также взаимного обмена обязательствами. При рассмотрении криптографических протоколов и схем электронной коммерции мы будем использовать введенные ранее криптографи
ческие протоколы.
Электронная коммерция становится одной из важнейших облас тей применения науки о криптографических протоколах. Представ ляется, что со временем значение криптографии в этой сфере будет только возрастать. В связи с этим ДЛЯ специалиста по обеспечению компьютерной безопасности знание этой предметной области пред ставляется чрезвычайно важным.
4.1.Основные задачи защиты информации
вэлектронной коммерции
Все задачи, возникающие при дистанционном осуществлении экономических отношений с использованием распределенных сис тем обработки данных, можно разделить на два класса: «горизон тальные» и «вертикальные», Такое деление стало сейчас общепри
знанным.
«Горизонтальные - это взаимоотношения между юридически ми лицами, участвующими в различных сферах деловой деятельно сти: предприятиями - участниками рынка товаров и услуг, государ
ственными органами и структурами, биржами, банками, фондами,
216 Запечников С. В. Криптографическиепротоколы IIIIX примененив
страховымикомпаниямии другими кредитно-финансовымиучреж дениями. В англоязычнойлитературетакие отношенияимеют обо значениеВ2В - «Ьевшеев-ю-Ьцвгпевв».
«Вертикальные» - это взаимоотношения между государствен ными органами и частными предприятиями, а также физическими лицами, между поставщиками и потребителями, между продавцами
и покупателями, т. е. всякие отношения, характеризующиеся нерав
ноправностью, когда одна из сторон в целом определяет характер и правила взаимоотношений, диктует условия, параметры, исходную информацию для совершения коммерческой сделки или юридиче ского действия. В англоязычной литературе такие отношения имеют обозначение В2С - «Ьцыпевв-ю-сопвшпег».
4.1.1. Классификация задач электронной коммерции
Выделяют два уровня рассмотрения задач электронной коммер ции с точки зрения обеспечения безопасности информации. Пер вый - это единичные информационные взаимодействия субъектов коммерческих отношений. Второй - это процессы деловой деятель ности (бизнес-процессы) между субъектами коммерческих отноше ний, рассматриваемые в целом.
Начнем с первого уровня. В электронной коммерции рассматри вают две базовые формы единичных информационных взаимодейст вий: одностороннюю передачу данных (transfer) и электронный об мен данными (exchange). Обе формы, рассматриваемые в совокуп ности, в англоязычной литературе нередко обозначают термином
«electronic data interchange».
Под односторонней передачей данных понимают передачу одно го или более фрагментов информации (данных, документов, плате жей) от одной стороны к одному или нескольким другим получате лям. В реальности одна логическая процедура односторонней пере дачи данных может потребовать нескольких физических пересылок сообщений. Например, вся информация еще неизвестна отправите лю в момент отсылки первого фрагмента данных, или разные фраг менты необходимо разослать по разным адресам, или требуется ши роковещательная рассылка одного фрагмента. Когда речь идет об односторонней передаче данных, очень важно иметь в виду, что ка
ждый передаваемый фрагмент данных или каждая отдельная пере-
4. КРlmmографllческuе протокоды в :JлекmРОIlНОU KO.1f,...,epIfUII u 6 доку.~fеllmообороmе 217 дача одного и того же фрагмента может быть индивидуально ассо циирована с различными атрибутами защиты (конфиденциальность, целостность, невозможность отказа, подлинность И т. д.).
В электронной коммерции приходится иметь дело с тремя прин ципиально различными видами информации, пересылаемой между
участниками протоколов:
обычными электронными данными (не имеющие юридической значимости);
подписанными электронными документами, имеющими юриди ческий статус (платежные поручения, ордера, квитанции, рас писки, контракты, сертификаты, лицензии и др.);
•«электронными деньгами»,
Таким образом, проблема защиты односторонней передачи ин формации в электронной коммерции оказывается далеко не такой простой, как может показаться на первый взгляд. Попытки ее реше
ния порождают множество других задач, как то:
образование защищенных (секретных и(или) аутентичных) логи
ческих каналов связи;
широковещательное шифрование информации; защита авторских прав на электронные данные (защиты от не
санкционированного копирования), в том числе отслеживание
«пиратского» копирования данных;
учет использования ресурсов участниками протоколов и др.
Когда говорят об электронном обмене данными, имеется в виду
группировка нескольких односторонних передач данных для пред
ставления семантики иеделимой операции, выполняемой двумя или более сторонами (участниками протокола). Основная и важнейшая задача электронного обмена данными - обеспечить гарантии чест ности обмена, Т. е. невозможности только одностороннего выполне ния обязательств и обмана одним участником протокола другого.
Рассматривая те же три вида информации (обычные данные,
электронные документы, электронные деньги), получаем шесть ти пов обмена информацией (табл. 4.1):
1)обмен обычными данными;
2)обмен информации на деньги, т. е. покупка информации;
3)обмен подписанных документов на информацию, т. е. доступ
кинформации по условию, при подписании какого-либо обязатель
ства (conditional access);
218Запечников С. В. Криптографическиепротоколы 11 их примененив
4)обмен подписанными документами, который может осущест вляться в режиме реального времени либо в отложенном режиме (В общем случае обеспечение честности этой процедуры подразумева ет решение задачи одновременного подписания контракта);
5)обмен, при котором одна сторона передает другой электрон
ные деньги, а в ответ передаются электронные документы, пред ставляет собою платеж с квитированием (подтверждением об оп лате);
б) обмен волюты (пусть и представленной в электронном виде).
Таблица 4.1. Классификация задач электронного обмена данными
Шесть типов |
3. Элекзнрон- |
2. Электронные |
1. Электрон- |
обмена: |
ные деньги |
документы |
ные данные |
1. Электронные |
Покупка ИН- |
Доступ к информа- |
Обмен ин- |
данные |
формации |
ции по условию |
формацией |
|
|
Сертифицированная |
|
|
|
|
|
2. Электронные |
ПЛатеж с кви- |
электронная почта |
- |
|
|
|
документы |
тированием |
Одновременное под- |
|
|
писание контракта |
|
|
|
|
|
3. Электронные |
Обмен |
- |
- |
деньги |
валюты |
|
|
|
|
|
|
Заметим, что среди перечисленных задач наибольший интерес с точки зрения обеспечения безопасности обмена данными представ ляют третий и четвертый случаи. Они порождают еще одну задачу,
занимающую промежуточное положение между ними - это так на
зываемая задача о сертифицированной электронной почте. Она за ключается в построении таких протоколов доставки электронной почты и - на их основе - такой системы электронной почты, которая обеспечивала бы невозможность отказа получателя от факта озна комления с сообщением, отправителя сообщения - от факта его от правки, а самой системы - от факта принятия сообщения к доставке. Этим задачам в настоящее время уделяется очень большое внимание среди общего поля проблем электронной коммерции и электронного документооборота.
Второй уровень рассмотрения задач электронной коммерции с точки зрения обеспечения безопасности информации - это процессы деловой деятельности. Для решения задач обеспечения безопасности
