Микроплатежи - это платежные транзакции на сумму до 25 дол. США с минимальной или отсутствующей комиссией. Осуществление транзакций подобных объемов при помощи стандартных систем на основе пластиковых карт или с использованием банковских счетов чревато возникновением ситуации, когда цена транзакции может превысить размер поступлений от обслуживания процесса покупки-продажи товара или услуги, а в ряде случаев и цену самого товара. Данный факт привел к созданию систем, ориентированных на проведение микроплатежей.
Можно выделить три основных направления использования систем микроплатежей.
Об актуальности систем проведения микроплатежей говорят исследования, проведенные TowerGroup (). Как видно из графика, представленного на рис www.towergroup.com">13.1">рис www.towergroup.com). Как видно из графика, представленного на (рис 13.1) Динамика роста объемов микроплатежей
Система Mondex явилась пионером среди систем проведения микроплатежей в face-to-face-коммерции. Основной целью создания Mondex послужила замена наличных денег специальными смарт-картами. Данные карты содержат в себе микрочип, который служит электронным кошельком. При этом следует отметить, что структура электронного кошелька Mondex является закрытой и отличается от структуры, определенной CEPS (Common Electronic Purse Specification), устанавливающей единые технологические правила на карточки с электронным кошельком.
Структура Mondex показана на рис 13.2.
(рис 13.2) Структура системы Mondex
За выпуск электронной наличности и обеспечение платежей отвечает платежный шлюз Mondex Originator. Как видно из рис 13.2, Mondex не использует межбанковские сети, что и позволяет существенно снизить стоимость транзакции. Для оплаты товаров или услуг пользователю необходимо купить специальную смарт-карту, распространяемую через сеть финансовых агентов. Каждая смарт-карта обладает уникальным 16-разрядным номером, по которому она идентифицируется в системе. При этом пользователю не нужно вводить никакой аутентифицирующей информации о себе, что обеспечивает полную анонимность платежей. Ограничение доступа к информации об электронной наличности, хранимой кошельком смарт-карты, осуществляется при помощи четырехзначного PIN-кода. Существует ограничение на число попыток ввода данного кода - после трех неправильных значений кошелек на карте блокируется.
Пополнение счета осуществляется при помощи специальных POS-терминалов (Point of Sale). Mondex позволяет хранить электронную наличность в пяти различных валютах в разных кошельках на смарт-карте. Для оплаты покупки или услуги пользователю достаточно вставить карточку в терминал Mondex Wallet, после чего требуемая сумма автоматически будет списана с кошелька. Кроме этого терминалы Mondex Wallet позволяют осуществлять перенос электронной наличности с одной смарт-карты на другую. Оплата за проведенные транзакции не взимается. Информация о последних десяти проведенных транзакциях хранится в памяти смарт-карты.
Безопасность использования смарт-карты обеспечивается при помощи протокола взаимной аутентификации карты и платежного шлюза. В системе используется два закрытых алгоритма шифрования и электронной подписи.
Развитием системы явились возможности управления электронным кошельком при помощи мобильного телефона и Интернета. Данные нововведения требуют создания электронного кошелька в рамках системы, что приводит к необходимости использования протокола SSL и сертификатов для аутентификации владельца такого кошелька, что в свою очередь отменяет анонимность платежей.
В отличие от Mondex, в которой электронную наличность выпускал только платежный шлюз, в системе Proton эмитентом электронной наличности может являться любое финансовое учреждение, входящее в систему (рис 13.3).
(рис 13.3) Структура системы Proton
Для участия в системе пользователь должен открыть счет в банке-участнике системы и приобрести смарт-карту со встроенным электронным кошельком. Кошелек поддерживает суммы от 5 до 125 евро. Следует отметить, что перевод электронной наличности с кошелька на кошелек в системе Proton невозможен. Пополнение электронного кошелька осуществляется следующим образом. При помощи специальных POS-терминалов пользователь вносит определенную сумму денег, которая переводится на его счет в банке. Затем указанная сумма переводится эмитентом в единый резервный фонд, который, с одной стороны, обеспечивает дальнейшее возмещение средств организациям, принимающим к оплате электронную наличность, а с другой стороны, гарантирует невозможность эмиссии ничем не обеспеченных электронных денег. Итогом операции пополнения является перевод электронной наличности на кошелек смарт-карты. Учитывая, что пополнение электронного кошелька осуществляется путем дебетования счета владельца карты банком-участником системы, полная анонимность в системе Proton отсутствует, поскольку имеется возможность отследить движение денежной массы при пополнении электронного кошелька.
Оплата товара или услуги осуществляется при помощи специализированных платежных терминалов. Транзакция оплаты не требует ввода аутентифицирующей информации. При помещении смарт-карты в терминал производится списание требуемой суммы электронной наличности с кошелька. Информация об указанной транзакции передается вместе с электронной наличностью в процессинговый центр, который осуществляет обратное дебетование средств единого резервного фонда на счет продавца. Как правило, дебетование электронной наличности терминалом продавца осуществляется при накоплении на данном терминале определенной суммы цифровой наличности с целью снижения накладных расходов, вызванных пользованием защищенной межбанковской сетью.
Как и в системе Mondex, транзакция для пользователя смарт-карты является бесплатной. Абонентская плата за пользования смарт-картой варьируется от 0 до 5 евро в зависимости от банка-эмитента. Продавцы выплачивают определенный процент за каждый перевод средств со счета единого резервного фонда. Обеспечение безопасности передаваемых данных осуществляется за счет использование алгоритма RSA при взаимной аутентификации терминала и смарт-карты, а также при помощи алгоритмов 3DES и RSA при передаче информации в рамках защищенной межбанковской сети.
Структура GeldKarte представлена на рис 13.4.
(рис 13.4) Структура GeldKarte
В отличие от системы Proton GeldKarte не использует единый резервный фонд - его заменяет база данных транзакций. Информация о любой операции, будь то пополнение электронного кошелька или оплата товаров или услуг, помещается в данную базу и хранится там до тех пор, пока не перестанет быть актуальной. В связи с этим нет необходимости в жестком делении на конкретные банки-эмитенты - любой банк, входящий в состав системы, может осуществлять платежные операции по картам других банков системы.
Для работы в системе любой участник, будь то покупатель или продавец, должен приобрести смарт-карту в любом банке, входящем в систему GeldKarte. Каждая карта обладает уникальным идентификатором, который регистрируется в авторизационном центре. После этого все операции над электронным кошельком карты будут связаны с идентификатором этой карты.
Любая операция, проводимая покупателем C, выполняется при помощи специализированного терминала и начинается с обязательной процедуры аутентификации карты покупателя. Последовательность действий при аутентификации карты следующая.
Покупатель помещает свою карту в слот терминала.
получая тем самым $$h (ID_C || Rand_C)$$, которое сравнивается со значением хеш-функции, примененной к $$ID_C || Rand_C$$, извлеченным из полученного сообщения. Положительный результат сравнения свидетельствует о подлинности карты.
Осуществив аутентификацию карты, покупатель может приступить к пополнению счета. В том случае, если пополнение осуществляется при помощи наличных денег, терминал осуществляет перевод электронной наличности в кошелек покупателя на смарт-карте и информирует об этом процессинговый центр, который в свою очередь добавляет соответствующую запись в базу данных транзакций. Для перевода денег со счета покупателя на электронный кошелек терминал осуществляет процедуру взаимной аутентификации карты и владельца путем ввода последним PIN-кода. В случае успешного завершения данной процедуры терминал посылает запрос на перевод средств процессинговому центру. Последний по идентификатору карты определяет номер счета покупателя и в случае наличия достаточных средств осуществляет дебетование счета и добавление соответствующей записи в базу данных транзакций. В случае успешности указанных действий электронный кошелек покупателя пополняется на требуемую сумму.
Проведение платежа за товар или услугу равносильно переносу электронной наличности с кошелька покупателя на кошелек продавца, встроенный в терминал. Последовательность действий при осуществлении платежа следующая.
Вывод денег из системы путем перевода средств с кошелька продавца на его счет в банке осуществляется при помощи указания идентификатора карты продавца. Процессинговый центр анализирует состояние электронного кошелька продавца при помощи платежного терминала, а также путем чтения соответствующих записей в базе данных транзакций, подтверждающих не только наличие требуемых суммы, но и реальность платежных транзакций, в результате которых она была получена, что предотвращает эмиссию ничем не обеспеченных электронных денег. Банк продавца не обязательно должен быть банком-эмитентом электронной наличности. Последнее свойство достигается за счет использования базы данных транзакций.
На рис 13.5 представлена система Chipknip, которая является результатом слияния родственных платежных систем Нидерландов - Chipknip и Chipper. Данное слияние было обусловлено тем, что широкое разнообразие систем электронной наличности стало вводить в заблуждение держателей электронных кошельков, что привело к сужению сегмента рынка систем микроплатежей. Результатом этого процесса стало решение владельцев технологии Chipper - банков PostBank и ING Bank об отказе от бренда и миграцию на технологию Chipknip.
(рис 13.5) Структура Chipknip
Chipknip является продолжателем идей, заложенных в системе Proton. Новацией системы стало использование сервера Chipknip не в качестве отдельной сущности, как его прообраза в системе Proton - единого резерного фонда (см. рис 13.3), а как некой прослойки между банком-эмитентом и банком продавца, фактически заменяющей безопасную межбанковскую сеть. Результатом такого подхода явились, во-первых, сокращение расходов за транзакции по переводу денег на счет продавца, а во-вторых, возможность переноса средств из кошелька в кошелек, которая отсутствовала в системе Proton. Кроме того, использование двухуровневого платежного шлюза (сервер Chipknip - процессинговый центр) делает возможным обеспечить анонимность платежей, так как сервер Chipknip работает со счетами, а процессинговый центр - с идентификаторами смарт-карт. Несмотря на такой очевидный уклон в сторону операций с банковскими счетами, система Chipknip разрабатывалась и применяется исключительно для осуществления микроплатежей при реализации face-to-face-коммерции.
Одной из отличительных особенностей Minipay является то, что смарт-карты данной системы не поддерживают стандарт EMV. В остальном процесс проведения транзакций схож с другими системами проведения микроплатежей. Банки системы выпускают смарт-карты с встроенным микрочипом, играющим роль кошелька электронной наличности. Пополнение счета осуществляется при помощи специальных терминалов либо с мобильного телефона. При оплате товара или услуги электронная наличность с кошелька покупателя пересылается на кошелек продавца. В отличие от других систем микроплатежей снятие средств с кошелька и пополнение счета продавца происходит не по желанию последнего, а в конце рабочего дня. Еще одной особенностью системы является отсутствие проверки величины остатка на счете покупателя, при этом каждый покупатель имеет дневной лимит покупок, что, с одной стороны, гарантирует продавцу оплату товара или услуги, а с другой - увеличивает скорость проведения платежей и снижает стоимость платежной транзакции.
Безопасность платежей обеспечивается использованием сервера Kerberos, который, с одной стороны, ускоряет процессы взаимной аутентификации терминала и карты, а с другой, за счет наличия сеансовых ключей для взаимодействия участников системы позволяет осуществлять перевод средств с кошелька на кошелек.
Некоторые характеристики рассмотренных выше систем приведены в табл. 13.1.
| Характеристика | Система микроплатежей | ||||
|---|---|---|---|---|---|
| Mondex | Proton | GeldKarte | Chipknip | MiniPay | |
| Страна | Великобритания | Бельгия | Германия | Нидерланды | Италия |
| Максимальная сумма на карте, дол. | 250 | 145 | 200 | 450 | 262 |
| Число поддерживаемых валют | 5 | 1 | 1 | 1 | 1 |
| Допустимость перевода средств на кошелек другого пользователя | + | – | – | + | + |
| Адаптация к сетевым платежам | + | + | + | – | + |
| Многофункциональные платежные функции | – | функции дебетовой карты и доступ к банкоматам | + | Функции дебетовой карты | – |
| Количество эмитентов | 12 | 25 | 3 500 | Все розничные банки | 20 |
| Количество выпущенных карт | 1 000 000 | 25 000 000 | 62 000 000 | 17 200 000 | 11 362 |
| Количество торговых терминалов | 20 000 | 113 000 | 133 000 | 165 000 | 2340 |
| Безопасность | Неизвестно | 3DES RSA | DES RSA | 3DES RSA | Kerberos |
| Анонимность платежей | + | – | + | + | – |
В отличие от систем проведения микроплатежей в face-to-face-коммерции удаленные микроплатежи не требуют для оплаты товаров или услуг специальных терминалов - их заменяют специализированное программное обеспечение или браузер. Электронные кошельки покупателя и продавца в этом случае хранятся не на смарт-карте или платежном терминале, а в виде файла на компьютере или на сервере платежной системы. Такой способ хранения позволяет помимо стандартных возможностей по оплате товаров или услуг и пополнения счета осуществлять передачу электронной наличности с кошелька на кошелек, что было невозможно в ряде систем face-to-face-коммерции. Кроме того, подобный подход избавляет от необходимости использования сложных многоитерационных алгоритмов взаимной аутентификации кошелька и его владельца, что, в свою очередь, значительно ускоряет время проведения платежной транзакции и позволяет сохранить анонимность владельца электронного кошелька. Исключение аппаратных средств (платежных терминалов) из цепочки взаимодействия участников платежной транзакции при осуществлении фазы покупки позволяет объединять несколько платежных систем путем введения некоего посредника, ответственного за конвертацию электронной наличности при переводе денег из одной платежной системы в другую.
Ниже приведено описание наиболее популярных систем проведения удаленных микроплатежей.
Процесс осуществления платежных транзакций в системе NetBill схематично представлен на рис 13.6.
(рис 13.6) Структура системы NetBill
Система предполагает наличие трех участников - покупателя C, продавца M и сервера N, который выполняет функции как платежного шлюза, так и центра сертификации. Для работы в данной системе продавец и покупатель должны зарегистрироваться. При регистрации в системе пользователь получает уникальный идентификатор ID, а также пару открытый/закрытый ключ.
Как и в большинстве систем на основе пластиковых карт, покупатель общается с сервером N через продавца. При этом сервер NetBill выступает в качестве сервера Kerberos для продавца, который в свою очередь выступает в качестве сервера Kerberos для покупателя. В традиционной схеме Kerberos (см. параграф 3.9.4) доступ к серверу выдачи билетов (TGS - Ticket Grant Service) осуществляется при помощи секретного ключа, полученного от центра авторизации. Авторы NetBill несколько изменили работу TGS, превратив его в PKBTGS (Public-Key-Based TGS - сервер выдачи билетов, основанный на криптосистеме с открытым ключом). В этом случае взаимодействие с пользованием симметричного секретного ключа заменяется использованием секретного ключа пользователя для подписи и открытого ключа сервера для шифрования сообщения при движении запроса в сторону сервера и закрытого ключа сервера для подписи и открытого ключа получателя для шифрования сообщения при движении билета к получателю.
Платежная транзакция в системе NetBill состоит из следующих шагов:
Следует отметить, что система NetBill ориентирована на продажу информации в цифровой форме. Оплата производится после получения покупателем цифровой информации. После подтверждения факта оплаты продавец высылает покупателю ключ для расшифрования полученной информации.
Взаимная аутентификация покупателя и продавца. Взаимодействие покупателя с и продавца М начинается с процедуры взаимной идентификации и аутентификации. Вначале покупатель формирует сообщение:
представляющее собой зашифрованные на открытом ключе продавца идентификатор покупателя $$ID_C$$, идентификатор продавца $$ID_M$$, временную отметку Time и ключ Key. Данное сообщение продавец подписывает при помощи своего секретного ключа $$SK_C$$ и хеш-функции h (m), известной всем участникам системы:
После этого покупатель отправляет сообщение с подписью продавцу. Продавец вычисляет хеш-образ сообщения и сравнивает его с хеш-образом, полученным путем применения к подписи открытого ключа продавца $$SK_M$$. В случае совпадения продавец удостоверяется в личности покупателя. Далее продавец, выступая в качестве сервера Kerberos для покупателя, создает сеансовый ключ симметричного шифрования $$K_{CM}$$ и сеансовый билет:
| где | $$Time_{START}$$ и $$Time_{STOP}$$ | - | время начала и окончания действия сертификата соответственно. |
Затем шифрует ключ $$K_{CM}$$ и сеансовый билет $$T_{CM}$$ на ключе Key и отправляет покупателю сообщение:
Учитывая, что ключ Key известен только продавцу и покупателю, последний может быть уверен, что полученное сообщение создано продавцом. Используя открытый ключ продавца, покупатель проверяет идентичность сеансового ключа $$K_{CM}$$ полученному в составе сообщения ключу $$K_{CM}$$, указанному в сеансовом билете $$T_{CM}$$.
Согласование цены. Для согласования цены за предлагаемый товар покупатель формирует запрос, включающий в себя развернутые сведения о покупателе Credentials, информацию о запрашиваемом продукте PRD, флаги запроса ReguestFlags, начальную цену Bid и идентификатор транзакции $$ID_T$$. Затем на сеансовом ключе $$K_{CM}$$ запрос шифруется
и с прилагаемым сеансовым билетом $$T_{CM}$$ отправляется продавцу. Развернутые сведения о покупателе используются для реализации специальных форм оплаты (скидки, кредиты, накопительные бонусы). Продавец, используя сеансовый билет $$T_{CM}$$, идентифицирует покупателя, выбирает требуемый сеансовый ключ $$K_{CM}$$ и расшифровывает полученное сообщение. После этого продавец формирует сообщение, содержащее идентификатор товара $$ID_{Product}$$, его цену Price, а также флаги запроса ReguestFlags и идентификатор транзакции $$ID_T$$, извлеченные из сообщения покупателя. Указанное сообщение шифруется на сеансовом ключе $$K_{CM}$$
и с прикрепленным сеансовым билетом $$T_{CM}$$ отправляется обратно покупателю. Если покупатель согласен с условиями сделки, то он переходит к этапу заказа товара, в противном случае процесс согласования цены начинается с самого начала путем формирования нового запроса с новым номером транзакции и продолжается до тех пор, пока стороны не придут к консенсусу.
Заказ. Если покупатель согласен с условиями сделки, то он сообщает об этом продавцу следующим сообщением:
Доставка товара. Продавец формирует заказанную информацию Goods, вырабатывает секретный ключ симметричного шифрования $$K_{Goods}$$ и применяет его к заказанной информации:
Покупатель не может прочесть заказанную информацию без знания ключа, который он получит только после фазы оплаты. Для того чтобы покупатель мог убедиться в целостности полученной информации, продавец формирует подписанный хеш-образ:
и отправляет покупателю следующее сообщение:
| где | IDEPO | - | идентификатор электронного платежного ордера (Electronic Payment Order - EPO), состоящий из имени продавца, срока доставки товара и уникального серийного номера. |
Оплата товара. Покупатель формирует электронный платежный ордер EPO, включающий в себя следующие поля:
Затем покупатель при помощи своего секретного ключа подписывает электронный платежный ордер:
после чего посылает продавцу следующее сообщение:
Продавец расшифровывает данное сообщение, проверяет подпись покупателя и в случае согласия с указанным ордером формирует свою подпись:
| где | $$M_{Acct}$$ | - | номер электронного кошелька продавца; |
| $$M_{Memo}$$ | - | дополнительная информация о продавце. |
После этого продавец отправляет платежному шлюзу следующее сообщение:
| где | $$T_{MN}$$ и $$K_{MN}$$ | - | сеансовый билет и сеансовый ключ для взаимодействия с платежным шлюзом. |
Получив указанное сообщение, платежный шлюз проверяет подписи покупателя, продавца и корректность электронного платежного ордера. Платежный шлюз также анализирует поля $$C_{Memo}$$ и $$M_{Memo}$$ реализации специальных форм оплаты (скидки, кредиты, накопительные бонусы). Затем производится проверка средств на кошельке покупателя и при положительном результате - перевод электронной наличности с кошелька покупателя на кошелек продавца. После этого платежный шлюз формирует сообщение о результате данной операции:
Затем платежный шлюз формирует подпись:
и отправляет продавцу следующее сообщение:
| где | Bal | - | остаток денежных средств на кошельке покупателя после завершения данной транзакции; |
| Flags | - | характеристики проведенной платежной транзакции. |
Продавец извлекает сообщение о результате проведения платежной транзакции и, воспользовавшись симметричным секретным ключом, отправляет покупателю следующее сообщение:
Получив данное сообщение, покупатель извлекает из него секретный ключ KGoods и расшифровывает купленную информацию.
Взаимодействие покупателя и продавца в системе MilliCent схематично представлено на рис 13.7.
(рис 13.7) Структура системы MilliCent
Работа системы MilliCent основана на использовании условных единиц электронной наличности, именуемых scrip или облигациями. Осуществлять выпуск облигаций могут два участника системы - продавец и брокер. Последний также является посредником между участниками системы и банковской платежной системой. Этот факт, а также использование предоплаты за облигации позволяет снизить стоимость платежной транзакции и делает возможным использование системы MilliCent для осуществления удаленных микроплатежей.
Оплата товара осуществляется только с использованием облигаций. Покупатель может приобрести облигации как у брокера, так и непосредственно у продавца с использованием стандартных средств пополнения электронной наличности. Различие между данными облигациями состоит в том, что облигацией продавца можно оплатить товар только данного продавца, облигация же брокера позволяет покупать товар у любого продавца системы.
Формат облигации. Описание полей облигации приведено в табл. 13.2.
| № | Имя поля | Описание |
|---|---|---|
| 1 | Vendor | Идентификатор создателя облигации |
| 2 | Value | Текущий баланс средств, размещенных на облигации |
| 3 | ID# | Уникальный серийный номер облигации |
| 4 | Cust_ID# | Идентификатор владельца облигации (покупателя) |
| 5 | Expires | Срок действия облигации |
| 6 | Props | Дополнительная информация о владельце облигации |
| 7 | Certificate | Сертификат, подтверждающий подлинность облигации |
Для работы с облигациями применяются три секретных ключа:
Процесс создания облигации начинается с заполнения продавцом или брокером полей 1—6. После этого создатель облигации генерирует уникальное число master_scrip_secret и с его помощью подписывает облигацию:
| где | h( ) | - | хеш-функция, известная всем участникам системы. |
Затем создатель облигации генерирует уникальное число master_customer_secret и с его помощью вырабатывает
Регистрация в системе. Процесс регистрации в системе состоит в получении специализированного программного обеспечения MilliCent Wallet. Кроме этого пользователь должен выбрать брокера и согласовать с ним протоколы защищенного взаимодействия (система MilliCent не детерминирует используемые для защиты данных алгоритмы).
Получение облигации. Для покупателя существуют три способа получения облигации:
При первом получении облигации покупатель получает также и customer_secret.
Оплата покупки. Для оплаты покупки пользователь использует сеансовый ключ Key, совпадающий с customer_secret, и посылает продавцу следующее сообщение:
| где | request | - | запрос на приобретение товара. |
Продавец, используя идентификаторы Vendor и Cust_ID#, извлекает из своей базы данных master_customer_secret, соответствующий данной паре, вычисляет значение Key и осуществляет выполнение запроса. Следует отметить, что база данных master_customer_secret продавца доступна только данному продавцу, соответственно, осуществить покупку при помощи облигаций другого продавца покупателю не удастся. База же данных master_customer_secret брокера хранится на сервере, что при наличии защищенного канала связи позволяет любому продавцу получить секретный ключ для работы с облигацией брокера.
MPTP (Micro Payment Transfer Protocol) является развитием идей, предложенных в MilliCent. Также как и MilliCent, MPTP предполагает наличие трех участников платежной транзакции - покупателя, продавца и брокера, который контролирует счета двух первых участников. Вместо облигаций scrip используются условные единицы payword.
При регистрации в системе, использующей протокол MPTP, пользователь получает специализированное программное обеспечение, устанавливает защищенное соединение с брокером (например, при помощи протокола SSL) и передает последнему свои банковские реквизиты. Брокер открывает счет в системе и высылает пользователю сертификат
| где | $$SK_B$$ | - | секретный ключ брокера, использующийся им для подписи сообщения; |
| $$ID_B$$ | - | идентификатор брокера; | |
| $$ID_U$$ | - | идентификатор пользователя системы; | |
| $$A_U$$ | - | адрес пользователя; | |
| $$PK_U$$ | - | открытый ключ пользователя; | |
| Е | - | срок действия сертификата; | |
| $$I_U$$ | - | дополнительная информация о пользователе. |
Данный сертификат гарантирует пользователю, что его условные единицы .
(рис 13.8) Формирование цепочки условных единиц
Пользователь определяет число идентична, $$W_0$$ представляет собой корень цепочки, а не платежную единицу.
Обязательство представляет собой следующее выражение:
| где | $$SK_U$$ | - | секретный ключ пользователя; |
| $$ID_M$$ | - | идентификатор продавца; | |
| D | - | срок действия обязательства; | |
| $$I_M$$ | - | дополнительная информация о продавце. |
Для осуществления оплаты пользователю достаточно предоставить продавцу обязательство и платеж. Используя открытые ключи пользователя и брокера, продавец может убедиться, что такой пользователь присутствует в системе и обладает платежным обязательством. При оплате продукта на i единиц платеж имеет следующий вид:
Продавец i раз хеширует сообщение $$W_i$$, получает $$W_0$$ и сравнивает его с $$W_0$$ из платежного обязательства.
Для обеспечения корректной работы системы платежи должны быть индексированы в соответствии с порядком i сформированных платежных слов. Допускается пропуск в передаче платежных единиц. Например, для оплаты продукта стоимостью j единиц можно после слова $$W_i$$ сразу передать слово $$W_{i + j}$$. Для обеспечения взаиморасчета продавец предоставляет брокеру в конце рабочего дня информацию о последнем проведенном платеже $$W_k || k$$, добавляя к нему соответствующее обязательство. Получив указанное сообщение, брокер осуществляет перевод денежного эквивалента k платежных единиц со счета покупателя на счет продавца.
Данная система также развивает идеи использования электронной наличности, предложенные в системе MilliCent. Электронные облигации scrip заменяются монетами, которые выпускать и распространять может только брокер. Жизненный цикл электронных монет представлен на рис 13.9.
(рис 13.9) Взаимодействие участников системы MicroMint
Алгоритм MicroMint устроен таким образом, что стоимость формирования одной электронной монеты уменьшается с увеличением объема выпускаемых монет. В связи с этим брокер формирует большую партию монет один раз в указанный период (неделя или месяц). При этом действие монет из предыдущей партии истекает, и они больше не могут использоваться.
В основе системы обеспечения безопасности MicroMint лежит предположение о нецелесообразности подделки большой партии электронных монет. В связи с этим механизмы обеспечения безопасности ориентированы на обнаружение фактов множественных фальсификаций, таких как множественная подмена, кража или регулярное повторное использование электронных монет.
В основе создания электронных монет MicroMint лежит факт наличия k-кратных коллизий в некоей хеш-функции h (x). Под k-кратной коллизией понимается ситуация, когда существует k оригиналов xi-тых, имеющих одинаковый хеш-образ, т.е.
Электронная монета MicroMint как раз и представляет собой k-кратную коллизию. Пользователь монеты при получении последней проверяет совпадение хеш-образов для всех оригиналов для того, чтобы убедиться в подлинности монеты.
Для вычисления вычислений хеш-функции. Соответственно, вычисление даже одной электронной монеты требует значительных вычислительных ресурсов (табл. 13.3).
| № | Хеш-функция | Размер хеш-образа | Число вычислений | ||
|---|---|---|---|---|---|
| k = 4 | k = 8 | k = 16 | |||
| 1 | MD5 | 128 | $$2^{96}$$ | $$2^{112}$$ | $$2^{120}$$ |
| 2 | SHA | 160 | $$2^{120}$$ | $$2^{140}$$ | $$2^{150}$$ |
Таким образом, подделка одной монеты является неэффективной для злоумышленника. Подделка же крупной партии монет затруднительна по следующим причинам.
Предотвращение кражи монет может быть достигнуто следующими способами:
Защита от повторного использования монеты обеспечивается ведением брокером специальной базы данных. В случае постоянного поступления уже использованных монет от продавца брокер сообщает об этом последнему и совместными усилиями они выявляют пользователя-злоумышленника. В случае незначительных сумм доказать вину пользователя будет практически невозможно, однако брокер может прекратить выдачу указанному пользователю электронных монет; аналогично - продавец может перестать принимать монеты от указанного пользователя.
В отличие от традиционных систем проведения микроплатежей, имеющих двухуровневую структуру (перевод электронной наличности с кошелька на кошелек - перевод средств со счета на счет), CyberCash является трехуровневой системой, которая представлена на рис 13.10 в виде схемы.
(рис 13.10) Структура CyberCash
При регистрации в системе пользователь создает электронный кошелек (CyberCash Account) на сервере CyberCash. Данный кошелек будет связан со счетом пользователя в банке. Соответственно для пополнения электронного кошелька необходимо перевести требуемую сумму на счет. Затем пользователь системы получает специализированное программное обеспечение со встроенными электронными кошельками - CyberCash Customer Wallet для покупателя и СyberCash Merchant Cash Register для продавца. Программное обеспечение продавца обладает также специальными средствами для создания витрины интернет-магазина.
В ходе платежных транзакций кошельки покупателя и продавца, находящиеся на компьютерах последних, оперируют с копиями электронных денег, хранящихся на серверных кошельках. Поясним сказанное на примере, представленном на рис 13.11.
(рис 13.11) Пример перевода электронных монет с кошелька на кошелек
Допустим, 
— кошелек покупателя, хранящийся на сервере, 
— кошелек покупателя, хранящийся на компьютере последнего, аналогично - 
и 
— кошельки продавца, хранящиеся на сервере и компьютере продавца соответственно. Предположим, покупатель хочет оплатить покупку на сумму n электронных монет.
Последовательность действий в данном случае следующая.
запрашивает n электронных монет у . переводит копии n электронных монет . на . переводит копии n электронных монет на . отправляет копии n электронных монет . проверяет, соответствуют ли указанные копии хранящимся электронным монетам и при положительном ответе переводит n электронных монет .Использование в расчетах копий электронных монет позволяет исключить возможность появления фальшивых монет, так как факт мошенничества будет вскрыт на этапе проверки соответствия копий хранящимся монетам. Также данная технология исключает возможность непоставки оплаченного товара: кошельку покупателя, хранящемуся на сервере, при подготовке перевода электронных монет достаточно запросить программное обеспечение покупателя для подтверждения получения товара. Не требуется в системе и шифрование передаваемых данных - хранимые на сервере монеты недоступны извне, а фальсифицировать копии невозможно.
Информация о всех операциях фиксируется в базе данных платежных транзакций. В соответствии с этой информацией в конце рабочего дня сервер CyberCash осуществляет перевод средств со счета покупателя на счет продавца.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.