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

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

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

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

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

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

Банк вычитает требуемую сумму со счета плательщика и под-писывает затемненную монету blindcoin подписью biindsig, которая генерируется при помощи специального секретного ключа, соответ-ствующего требуемому номиналу монеты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Банк выбирает ключевую пару схемы подписи RSA для подпи-сания монет: skB = (n,dB), pkB = (п,ев). На практике необходима одна такая ключевая пара для каждого номинала монет, выпускаемых в обращение в СЭП. Открытые ключи банк распространяет среди уча-стников системы на этапе установки начальных параметров. Выби-рается также алгоритм хеш-функции, которая будет использоваться при генерации монет.

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

длина хеш-кода, генерируемого выбранной хеш-функцией: сеЛ Zm ,

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

Чтобы выполнить затемнение (операция blind) плательщик вы-бирает случайную, равномерно распределенную величину r&R Zn, называемую затемняющим фактором, или затемняющим мнооїси- телем, и полагает: blindcoin = coin • re" (mod /і).

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

blindsig = coin*** ¦ гСпНв = coindh -r(modn).

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

sig - bhndsig д0ДПИСЬ будет иметь вид sig = coin4" (mod л).

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

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

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

Разрешение конфликтных ситуаций.

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

Sigcl. («Coin withdrawal», N, seq_no, amount, blindcoin),

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

где skaccomit - неанонимный ключ, принадлежащий номеру счета N\ seq_no - порядковый номер расходного ордера; amount - номинал монеты, которую плательщик хочет получить.

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

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

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

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

Sensig (1) (*Коіп > PKoin ) > С01П = PKoin IIhash(pkcoin ) .

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

SIGSKOM («pay», NR, «for», ref),

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

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

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

Получатель на шаге (8) и банк на шаге (9) могут проверить эту подпись по отношению к coin = pkcojn \hash(pkcojn).

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