3.3. Неанонимные автономные СЭП
Основной недостаток такого подхода состоит в том, что заяв-ляемый производителем аппаратуры уровень защищенности уст-ройств, как правило, очень сомнителен для потребителей. Другая проблема заключается в том, что две различные стороны - пользова-тель и банк - должны доверять одному и тому же устройству. Но банк заинтересован в том, чтобы конструкция устройств была мак-симально засекречена, а пользователь - в том, чтобы она была опуб-ликована и публично проверяема.
3.3. 1 Системы на основе цифровой подписи
Простейший путь реализовать неанонимные автономные СЭП - использовать схемы цифровой подписи. Для каждого защищенного устройства D плательщика генерируется пара ключей (skD, pkD ).
Банк выдает атрибутный сертификат Certd для каждого pkD с атрибу-том, подтверждающим, что данное защищенное устройство выдано банком: «this is one of ту secure devices». Для операций в автоном-ном режиме каждое устройство содержит свой собственный серти-фикат. Баланс устройства balD изначально устанавливается в 0. Кроме того, на устройство записывается идентификатор обслуживающего его банка и сертификат открытого ключа банка.
Сертификаты открытых ключей устройств и банка подписываются специально создаваемым в СЭП удостоверяющим центром либо самим банком.Таким образом, при инициализации на каждое устройство пла-тельщика записываются следующие данные:
D (D, skD, pkD, certD, balD: = О, В, Certb).
Пополнение счета выполняется таким образом: устройство клиента системы получает подписанное сообщение m(I) от банка о том, что он готов увеличить его баланс. Важно обеспечить «свежесть» сообщения, например, присваивая ему порядковый номер: т^ = Sig^ (" increase", D, NB, х),
где skB - секретный ключ банка; «increase» - идентификатор, пока-зывающий, что это команда на пополнение счета; D - идентификатор устройства плательщика; NB - порядковый номер, позволяющий избежать повтора сообщений; х - сумма, на которую требуется уве-личить баланс устройства.
Для выполнения платежа с устройства плательщика Р на уст-ройство получателя R пересылается сообщение т(2) специального формата, содержащее в том числе сумму платежа х и атрибутный сертификат устройства плательщика, выданный ему банком. Но для обеспечения «свежести» сообщения получатель должен предварительно сгенерировать и переслать плательщику уникальный номер платежной транзакции вместе со своим идентификатором. Перед от-правкой т(2) устройство плательщика Р уменьшает свой баланс на величину х. После получения т(2) устройство получателя R увеличи-вает свой баланс на ту же величину. Это должно происходить имен-но в таком порядке. В противном случае плательщик и получатель могли бы преднамеренно «потерять» сообщение т(2\ чтобы увели-чить свой суммарный баланс на величину х. Таким образом, прото- кол, выполняемый Р и R в транзакции платежа, выглядит следую-щим образом:
R->P:R,Nr,
Р: balp: — balP - х,
P^R: т{2) = [Sigsk.: ("pay",Р,RtNR,x),Cert,],
R : balR: = balR - jc.
Мы не затрагиваем здесь вопросы предоставления квитанций и разрешения конфликтных ситуаций между участниками СЭП.
Рассмотренная система относится к классу СЭП с предоплатой, с отложенным депозитом. Она обладает свойством переводимости де-нежных средств, т. е. одни и те же устройства, выдаваемые клиентам системы, могут быть использованы и для оплаты, и для получения платежей и получаемые деньги могут добавляться на тот же самый счет, с которого выполняется оплата.