НОУ ИНТУИТ | Защита информации в электронных платежных системах. Лекция 13: Системы проведения микроплатежей

Учитесь и получайте официальные документы БЕСПЛАТНО. Вы можете поддержать наш проект.

Регистрация Вход

Твой путь к знаниям!

Опубликован: 24.10.2016 | Доступ: свободный | Студентов: 1352 / 467 | Длительность: 21:30:00

Темы: Безопасность, Менеджмент

Специальности: Администратор информационных систем, Специалист по безопасности

|

Вам нравится? Нравится 27 студентам

| Поделиться |

Поддержать курс

| Скачать электронную книгу

13.2. Системы проведения удаленных микроплатежей

В отличие от систем проведения микроплатежей в face-to-face-коммерции удаленные микроплатежи не требуют для оплаты товаров или услуг специальных терминалов - их заменяют специализированное программное обеспечение или браузер. Электронные кошельки покупателя и продавца в этом случае хранятся не на смарт-карте или платежном терминале, а в виде файла на компьютере или на сервере платежной системы. Такой способ хранения позволяет помимо стандартных возможностей по оплате товаров или услуг и пополнения счета осуществлять передачу электронной наличности с кошелька на кошелек, что было невозможно в ряде систем face-to-face-коммерции. Кроме того, подобный подход избавляет от необходимости использования сложных многоитерационных алгоритмов взаимной аутентификации кошелька и его владельца, что, в свою очередь, значительно ускоряет время проведения платежной транзакции и позволяет сохранить анонимность владельца электронного кошелька. Исключение аппаратных средств (платежных терминалов) из цепочки взаимодействия участников платежной транзакции при осуществлении фазы покупки позволяет объединять несколько платежных систем путем введения некоего посредника, ответственного за конвертацию электронной наличности при переводе денег из одной платежной системы в другую.

Ниже приведено описание наиболее популярных систем проведения удаленных микроплатежей.

13.2.1. NetBill

Процесс осуществления платежных транзакций в системе NetBill схематично представлен на рис. 13.6.

Рис. 13.6. Структура системы NetBill

Система предполагает наличие трех участников - покупателя C, продавца M и сервера N, который выполняет функции как платежного шлюза, так и центра сертификации. Для работы в данной системе продавец и покупатель должны зарегистрироваться. При регистрации в системе пользователь получает уникальный идентификатор ID, а также пару открытый/закрытый ключ.

Как и в большинстве систем на основе пластиковых карт, покупатель общается с сервером N через продавца. При этом сервер NetBill выступает в качестве сервера Kerberos для продавца, который в свою очередь выступает в качестве сервера Kerberos для покупателя. В традиционной схеме Kerberos (см. "Методы защиты информации в компьютерных системах и сетях" ) доступ к серверу выдачи билетов (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, включающий в себя следующие поля:

идентификатор покупателя ;
идентификатор товара $ID_{Product}$ ;
договорная цена Price;
идентификатор продавца ;
подписанный хеш-образ оплаченного товара $SHA\{K_{Goods}\{Goods\}\}$ ;
подписанный хеш-образ информации о товаре SHA{PRD} для предотвращения возможных разногласий по условиям заказа;
подписанный хеш-образ номера и результата верификации электронного кошелька покупателя $SHA\{С_{Acct} || VN_{Acct}\}$ ;
идентификатор электронного платежного ордера $ID_{EPO}$ ;
сеансовый билет для взаимодействия с сервером NetBill $T_{CN}$ ;
зашифрованные на симметричном секретном ключе $K_{CN}$ билет авторизации Authorization, номер электронного кошелька покупателя $С_{Acct}$ , результат верификации данного кошелька $VN_{Acct}$ и дополнительную информацию о покупателе $C_{Memo}$ :

Затем покупатель при помощи своего секретного ключа подписывает электронный платежный ордер:

после чего посылает продавцу следующее сообщение:

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

где	$M_{Acct}$	-	номер электронного кошелька продавца;
	$M_{Memo}$	-	дополнительная информация о продавце.

После этого продавец отправляет платежному шлюзу следующее сообщение:

где

$T_{MN}$ и $K_{MN}$

-

сеансовый билет и сеансовый ключ для взаимодействия с платежным шлюзом.

Получив указанное сообщение, платежный шлюз проверяет подписи покупателя, продавца и корректность электронного платежного ордера. Платежный шлюз также анализирует поля $C_{Memo}$ и $M_{Memo}$ реализации специальных форм оплаты (скидки, кредиты, накопительные бонусы). Затем производится проверка средств на кошельке покупателя и при положительном результате - перевод электронной наличности с кошелька покупателя на кошелек продавца. После этого платежный шлюз формирует сообщение о результате данной операции:

Затем платежный шлюз формирует подпись:

и отправляет продавцу следующее сообщение:

где	Bal	-	остаток денежных средств на кошельке покупателя после завершения данной транзакции;
	Flags	-	характеристики проведенной платежной транзакции.

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

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

13.2.2. MilliCent

Взаимодействие покупателя и продавца в системе MilliCent схематично представлено на рис. 13.7.

Рис. 13.7. Структура системы MilliCent

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

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

Формат облигации. Описание полей облигации приведено в табл. 13.2.

Таблица 13.2. Описание полей облигации
№	Имя поля	Описание
1	Vendor	Идентификатор создателя облигации
2	Value	Текущий баланс средств, размещенных на облигации
3	ID#	Уникальный серийный номер облигации
4	Cust_ID#	Идентификатор владельца облигации (покупателя)
5	Expires	Срок действия облигации
6	Props	Дополнительная информация о владельце облигации
7	Certificate	Сертификат, подтверждающий подлинность облигации

Для работы с облигациями применяются три секретных ключа:

customer_secret - подтверждает право собственности на облигацию;
master_customer_secret - используется для создания customer_secret;
master_scrip_secret — используется для проверки аутентичности облигации.

Процесс создания облигации начинается с заполнения продавцом или брокером полей 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 брокера хранится на сервере, что при наличии защищенного канала связи позволяет любому продавцу получить секретный ключ для работы с облигацией брокера.

13.2.3. MPTP

MPTP (Micro Payment Transfer Protocol) является развитием идей, предложенных в MilliCent. Также как и MilliCent, MPTP предполагает наличие трех участников платежной транзакции - покупателя, продавца и брокера, который контролирует счета двух первых участников. Вместо облигаций scrip используются условные единицы payword.

При регистрации в системе, использующей протокол MPTP, пользователь получает специализированное программное обеспечение, устанавливает защищенное соединение с брокером (например, при помощи протокола SSL) и передает последнему свои банковские реквизиты. Брокер открывает счет в системе и высылает пользователю сертификат

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

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

Рис. 13.8. Формирование цепочки условных единиц

Пользователь определяет число N, которое является числом условных единиц, которое он хочет получить. Затем пользователь генерирует случайное число W_N и вычисляет цепочку платежных единиц при помощи хеш-функции, известной всем участникам системы. Стоимость всех платежных единиц цепочки W_i , идентична, W_0 представляет собой корень цепочки, а не платежную единицу.

Обязательство представляет собой следующее выражение:

где		-	секретный ключ пользователя;
		-	идентификатор продавца;
	D	-	срок действия обязательства;
		-	дополнительная информация о продавце.

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

Продавец i раз хеширует сообщение W_i , получает W_0 и сравнивает его с W_0 из платежного обязательства.

Для обеспечения корректной работы системы платежи должны быть индексированы в соответствии с порядком i сформированных платежных слов. Допускается пропуск в передаче платежных единиц. Например, для оплаты продукта стоимостью j единиц можно после слова W_i сразу передать слово $W_{i + j}$ . Для обеспечения взаиморасчета продавец предоставляет брокеру в конце рабочего дня информацию о последнем проведенном платеже W_k || k , добавляя к нему соответствующее обязательство. Получив указанное сообщение, брокер осуществляет перевод денежного эквивалента k платежных единиц со счета покупателя на счет продавца.

13.2.4. MicroMint

Данная система также развивает идеи использования электронной наличности, предложенные в системе MilliCent. Электронные облигации scrip заменяются монетами, которые выпускать и распространять может только брокер. Жизненный цикл электронных монет представлен на рис. 13.9.

Рис. 13.9. Взаимодействие участников системы MicroMint

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

Алгоритм MicroMint устроен таким образом, что стоимость формирования одной электронной монеты уменьшается с увеличением объема выпускаемых монет. В связи с этим брокер формирует большую партию монет один раз в указанный период (неделя или месяц). При этом действие монет из предыдущей партии истекает, и они больше не могут использоваться.

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

В основе создания электронных монет MicroMint лежит факт наличия k-кратных коллизий в некоей хеш-функции h (x). Под k-кратной коллизией понимается ситуация, когда существует k оригиналов xi-тых, имеющих одинаковый хеш-образ, т.е.

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

Для вычисления k-кратной коллизии хеш-функции с размером хеш-образа, равным n, потребуется примерно вычислений хеш-функции. Соответственно, вычисление даже одной электронной монеты требует значительных вычислительных ресурсов (табл. 13.3).

Таблица 13.3. Примерное число вычислений хеш-функций, необходимое для получения k-кратной коллизии
№	Хеш-функция	Размер хеш-образа	Число вычислений
№	Хеш-функция	Размер хеш-образа	k = 4	k = 8	k = 16
1	MD5	128	$2^{96}$	$2^{112}$	$2^{120}$
2	SHA	160	$2^{120}$	$2^{140}$	$2^{150}$

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

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

Предотвращение кражи монет может быть достигнуто следующими способами:

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

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

13.2.5. CyberCash

В отличие от традиционных систем проведения микроплатежей, имеющих двухуровневую структуру (перевод электронной наличности с кошелька на кошелек - перевод средств со счета на счет), 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 электронных монет .
проверяет, соответствуют ли указанные копии хранящимся электронным монетам и при положительном ответе переводит n электронных монет .

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

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

Дальше >>

Авторизоваться

Защита информации в электронных платежных системах

Системы проведения микроплатежей