пiдручник

Добавил:

Vasa Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Тернопольский национальный технический университет им. И. Пулюя

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Плательщик

Получатель

(преобразует монету)

Получатель

(преобразует монету)

.pdf

Скачиваний:

Добавлен:

18.10.2019

Размер:

14.08 Mб

Скачать

☆

<<< < Предыдущая 8 9 10 11 12 13 14 15 16 17 18 1920 / 3320 21 22 23 24 25 26 27 28 29 30 31 32 > Следующая >>>

З. Системы электронных платежей

189

7.Банк перемещает pkp в список прошлых владельцев v и сохра няет платежное поручение как доказательство на случай возможных спорных ситуаций.

8.Банк вводит pkR как открытый ключ нынешнего (текущего)

владельца стандартной величины.

9. Банк подписывает подтверждение перевода денег и посылает

его плательщику: Sig:ik (<<New owner of»,v,«is»,pkR) .

1О. Плательщик пересылает сообщение банка получателю.

11.Если на предыдущем шаге сообщение не поступило к полу чателю платежа, последний может сам обратиться непосредственно

вбанк и получить информацию о совершенном платеже.

12.При необходимости получатель R может направить платель

щику Р квитанцию или сразу поставить ему товар или услугу, за ко

торую тот заплатил ему деньги.

Если R отказывается от факта совершения платежа, Р может ис пользовать банковское подтверждение из шага (9) вместе с сообще нием получателя из шага (3), чтобы доказать, что он перевел деньги

на псевдоним именно этого получателя.

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

альные деньги.

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

3.4.3. СЭП на базе затемненной подписи

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

190 Запечников С. В. Криптографическиепротоколы tI их примененив

которой предложена в работах Шаума (Chaum). Рассмотрим кон цепцию такой платежной системы (рис. 3.6).

Снятие СО счета.

эпгеыненвая ПОДПИСЬ

несвязываемосгь

Рис. 3.6. Концептуальная схема СЭПна базе затемненной подписи

Для простоты на схеме показано, что плательщика и получателя обслуживает один и тот же банк. Банк каким-либо образом выдает плательщику «электронную монету», которая представляет собою сообщение, подписанное затемненной подписью. Плательщик мо жет некоторым образом преобразовать эту монету перед тем, как передать ее получателю в платеже. Получатель затем кладет ее на депозит. Вследствие преобразования монеты плательщиком перед платежом банк не может установить связь, какая из монет, положен ных на депозит, какой именно монете, снятой со счета, соответству ет. Таким образом, становится невозможно отследить, кто из участников СЭП кому заплатил.

Базовая версия СЭП Шау.ма (рис. 3.7) является системой с предоплатой, с неотложным депозитом. Она обеспечивает аноним ность плательщика с неотслеживаемостью, не обеспечивает аноним

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

Основные этапы ее функционирования таковы.

Установка начальных параметров. Первоначально банк должен

распространить среди участников системы некоторые параметры,

необходимые для функционирования СЭП.

3. Системы электронных платежей

191

Банк ~

4 - 3:mr.m. ПОД[ПIСЬ 9 - ПровеРК:I

ПJштельщш< coln

12 Получатель

г---~ l1-Подпш:ь

квптаншш

Рис. 3.7. Абстрактное представление базовой версии СЭПШаума на основе схе.МЫ затемненной подписи

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

1. Плательщик генерирует монету coin при помощи операции gencoin - вероятностного алгоритма, которому в качестве аргумен тов передаются начальные параметры, распространенные банком. В результате получается «форма» для монеты, используемой впо следствии в платеже (на рис. 3.7 заштрихована).

2. Плательщик преобразует монету операцией bIind. В результа те получается «затемненная» монета bIindcoin (на рис. 3.7 показана пустым кругом, без штриховки).

3. ПЛательщик посылает «затемненную» монету в банк вместе с расходным ордером - требованием о снятии денег со счета, в кото ром обозначен номинал монеты и номер счета.

4. Банк вычитает требуемую сумму со счета плательщика и под писывает затемненную монету bIindcoin подписью bIindsig, которая

генерируется при помощи специального секретного ключа, соответ

ствующего требуемому номиналу монеты.

192Запечников С. В, Криптографическиепротоколы и 'IX применение

5.Банк посылает подпись bIindsig обратно плательщику, кото рый проверяет ее.

Платеж с депозитом

6.Плательщик применяет к подписи операцию снятия затемне

ния unbIind. Результат ее - цифровая подпись sig, которая является подписью для исходной формы монеты (обозначенной как заштри хованная). Для этой операции он использует параметры, сохранен ные при выполнении операции bIind.

7.Плательщик пересылает (coin, sig) получателю.

8.Получатель просто пересылает это сообщение в банк, чтобы

выполнить в режиме реального времени проверку на предмет по

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

9. Банк проверяет подпись и проверяет по базе данных, что эта монета не была положена на депозит ранее. Если эти проверки за канчиваются успешно, он вводит монету в базу данных и добавляет

сумму платежа на счет получателя.

10. Банк сообщает получателю результаты проверок и депозита.

11. Если предыдущие шаги завершились успешно, получатель обычно подписывает квитанцию. Если нет, получатель не принимает

платеж.

12. Получатель отправляет квитанцию плательщику, поставляет

ему товары ИЛИ оказывает услуги.

Отметим, на каких этапах здесь имеют место входные и выход ные потоки данных, которые в подразд. 3.1.2 мы рассматривали для обобщенной системы:

•withdraw запускаетшаг (1);

•allow необходимо на шаге (4);

•subtract такжеимеетместо на шаге (4);

рау запускает шаг (6);

•если получатель должен вводить receive, это необходимо сделать на шаге (8);

•add имеетместона шаге (9);

•ok для получателя - на шаге (1О);

•ok для плательщика в конце платежа - не обеспечивается в базо вой системе.

3. Системы электронных платежей

193

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

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

и тех же монет просто по их последовательности во времени.

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

только среди всех лиц, которые имеют снятые со счета в том же

банке монеты такого же номинала.

Монеты обычно имеют ограниченный срок действия: несколько месяцев или лет. Это делается с целью ограничения проблем, свя занных с возможной подделкой подписи, а также для ограничения размеров базы данных монет, которую поддерживает банк. Эта база данных, 'очевидно, будет БОЛЬШОЙ1 но все-таки не должна быть не обозримой. В других СЭП в базы данных заносится одна запись на

платеж, а здесь - одна запись на каждую монету, используемую в

плаТ,еже. По статистике в этом случае записей будет в среднем в пять раз больше.

Криптографическая реализация СЭП Шаума: схема затем ненной подписи на ОСН0ве задачи RSA. Чтобы реализоватьсистему, концепциякоторой была рассмотренавыше, нужно предложитьме тоды выполнения всех перечисленных операций. Оригинальная и хорошо известная реализация этой СЭП основывается на схеме цифровой подписи RSA. Заметим, что эта реализация может рас сматриваться как позитивное использование известного способа ак тивной атаки на схему подписи RSA.

Банк выбирает ключевую пару схемы подписи RSA дЛЯ подпи сания монет: sk B = (n,dB) , pkB = (n,ев), На практике необходима одна

такая ключевая пара для каждого номинала монет, выпускаемых в

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

при генерации монет.

Для генерации монеты (операция gencoin) плательщик выбирает случайную величину с, которая короче п на столько битов, какова

194 Запечкиков С. В. Криптографическивпротоколы и их примененив

длина хеш-кода, генерируемого выбранной хеш-функцией: с ЕR 2т '

Iml ::::; /nl-Ihasll (с)/. Монета сот = (с1I'1asll (С») представляет собою

конкатенацию величины с и ее хеш-кода.

Чтобы выполнить затемнение (операция bIind) плательщик выбирает случайную, равномерно распределенную величину r Ен Zn '

называемую затемняющим фактором, или затемняющим множи телем, и полагает: Ытасот « coin. r~B (mod п) .

Генерация подписи полностью аналогична обычной схеме RSA: blindsig ;; blindcoin dn (mod 1l) . Таким образом, получается, что

blindsig ;;coindB 'r,'nds =.coindn ·r(mod11).

Чтобы снять затемнение с подписи (операция unbIind), платель щик берет У, сохраняемое им от операции затемнения, и вычисляет

sig	blindsig	. Подпись будет иметь вид	.	. d	в	(	)
			Slg ::: сот				mod 1l •

Проверкаподписидля построеннойтакимобразоммонетыбудет заключатьсяв обычной проверке подписипо схеме RSA и проверке

хеш-кода величины с.

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

Другими словами, схема Шаума обеспечивает свойство теоре тико-информационной анонимности плательщиков сэп.

Разрешение конфликтных ситуаций. Попытаемся усложнить СЭП Шаума таким образом, чтобы она обеспечивала возможность разрешения конфликтных ситуаций между плательщиками и полу чателями, с одной стороны, и банком, с другой стороны.

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

SigSk.~'lr (<<Coin withdrawal», N, seq_no, amount, blindcoin),

3. Системы электронных платежей

195

где skarco///Jt - неанонимный ключ, принадпежащий номеру счета N; seq_no - порядковый номер расходного ордера; атоипл - номинал

монеты, которую плательщик хочет получить.

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

Вторая конфликтная ситуация - спор о повторной трате моне ты. Что можно сделать, если банк отказывается класть на депозит монету, говоря, что эта монета уже содержится в базе данных, но плательщик не согласен и говорит, что никогда не тратил ее прежде? Банк, возможно, сумеет доказать, что монета была зачислена на не который счет. Но плательщик может заявить, что это счет не того получателя, для которого была предназначена его монета. Проблема

заключается в том, что для плательщика отсутствует возможность

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

Решение - ввести так называемые ключи люнет, Т. е. специфиче

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

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

gensig (1) -1 (skCOi/l' pkcoi/I ) , сот = pk coill 11/1asI1(pk(:Qin ) .

При выполнении платежа на шаге (7) плательщик пересылает получателю не только (coin, sig), но и платежноепоручение, напри мер следующегоформата:

SigSk~oi" (ерау», NR, «Гог», ref),

где NR - номер счета получателя; пе]- некоторая ссылочная строка, используемая для связи этого платежа с каким-либо другим (на слу

чай споров между плательщиком и получателем).

196 Запечников С. В. Криптографическиепротоколы и их применение

Дополнительные меры для обеспечения «свежести» сообщений

здесь не нужны, так как каждая монета тратится только однажды.

Получатель на шаге (8) и банк на шаге (9) могут проверить 'эту

подпись по отношению к сот = pk . Illшsll(pk . ).

сот сот

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

пасна и для получателя, так как она выдает квитанции или услуги

только после шага (11), и в это время он уже имеет подтверждение

депозита, которое он может использовать в решении конфликта, ес ли выяснится, что деньги не поступили на его счет. Если получатель

отказывает в квитанции, плательщик может получить подтвержде

ние банка, что его монета была положена на депозит. Если нет, он может в этот момент заплатить ее себе же.

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

Эта схема уже не является СЭП с предоплатой, так как платель щик не знает, кому он будет платить. Чтобы избежать связи по вре

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

затемненную монету, плательщик не может потратить ее дважды.

3. Системы электронных платежей

197

6 - Зятемн, ПОдrDlСЬ

Плательщик "' - Расходныjf

Оlщq)~

8 - РетранL'J1ЯIJ,1Ш

l3lindsig

Рис. 3.8. Абстрактное представление базовой версии СЭПШаума на основе схе..мы затемненной подписи для обеспечения анонимности

получателя платежа

втерминах ранее введенных определений мы получили систему

срезервированием (которая не имеет большого практического зна чения без анонимности). Чтобы обеспечить безопасность в спорах о

состоянии депозитных счетов, получателю следует, как и в преды

дущей схеме, генерировать монеты с ключом монет.

Достижение максимальной анонимности. Различные виды анонимности из предыдущих схем можно скомбинировать вместе

иполучить СЭП, в которой анонимными являются и плательщик

иполучатель. В такой СЭП полученная монета не кладется на счет в банке, а немедленно обменивается на новую монету, которую полу

чатель может использовать в следующем платеже, но уже в роли

плательщика.

198 Запечкиков С. В. Криптографическиепротоколы и ихпримененив

Технически эта СЭП основывается на системе с анонимным по лучателем. Предположим, что некоторый участник такой системы, выступавший в предыдущем платеже в роли получателя монеты, имеет недепонированную монету с ключом монеты. Обозначим эту

монету сот; = pkcoill ,I III1ClSlz(pkm i /I•I ) с секретным ключом монеты

SkC(Jill.l и подписью sigJ• В новом платеже этот же участник - владе лец монеты - собирается выступить в роли плательщика, который

должен передать свою монету новому получателю.

Для этого новый получатель вырабатывает новую монету, т. е.

генерирует пару ключей:	gensi.t: (1) ~(SkCQill.2' pk(:Oill,l) ' полагает
сот, =рkСQ;II.2111шslz(pkClJill.2 ),	проводитоперациюзатемнения,в ре

зультате чего получается bIindcoin2, и посылает ее плательщику, т. е. обладателю монеты сош.. Плательщик вместо депозитного по ручения для его «старой» монеты подписывает обменный ордер, на пример в таком формате:

Sigsk • I (<<exchange», Ышёсош-).

c v jll

При получении (сопт., si9 1) и обменного ордера банк делает обычные проверки. Он проверяет обе подписи (т. е. убеждается, что монета действительна и что обменный ордер был сгенерирован вла дельцем монеты) и проверяет по своей базе данных, что монета не была депонирована или обменена ранее. Если все нормально, он да ет подпись bIindsi92 для монеты bIindcoin2 и посылает ее обратно

плательщику.

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

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

<<< < Предыдущая 8 9 10 11 12 13 14 15 16 17 18 1920 / 3320 21 22 23 24 25 26 27 28 29 30 31 32 > Следующая >>>