d9e5a92d

Глава 5. Другие модели построения систем электронной коммерции


Другие аспекты повышения безопасности систем электронной коммерции

Как уже отмечалось ранее, сегодня большинство систем ЭК используют протокол SSL Уровень защиты, обеспечиваемый SSL, таков, что аутентификация владельца карты не производится вообще, а аутентификация электронного торгового предприятия может быть признана с серьезными оговорками. Эффективность ранее обсуждавшихся методов повышения безопасности проведения электронных покупок с использованием протокола SSL (применение различных негатив-файлов, проверка CVV2/CVC2, VISA AVS) является весьма ограниченной.

Что же делать обслуживающему банку, желающему заниматься электронной коммерцией уже сегодня в условиях отсутствия широко распространенных надежных протоколов ЭК? Пожалуй, для нынешнего этапа развития электронного бизнеса существует единственный ответ на поставленный вопрос — руководствоваться набором базовых принципов, выработанных на основе обобщения накопленного опыта работы других банков. Эти принципы носят в основном организационноадминистративный характер и представлены во многих документах. В частности, в концентрированном виде они изложены в материале компании VISA International «Acquirer Best Practices. Electronic Commerce Fraud Management».

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

В общем случае различаются три этапа работы обслуживающего банка с ТП:

1. Подписание договора с ТП.

2. Контроль функционирования ТП.




3. Разрыв отношений с ТП.

На первом этапе банк получает от ТП заполненную анкету ТП, осуществляет необходимые проверки данных анкеты и принимает решение о подписании договора с торговым предприятием. Заканчивается этап либо подписанием договора на обслуживание ТП банком, либо отказом от сотрудничества с данным ТП. Роль первого этапа является крайне важной. Фактически, только грамотно реализовав этот этап работы с ТП, можно защититься от мошеннических торговых предприятий, создаваемых для «отмывания» украденных реквизитов карт.

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

Наконец, на третьем этапе реализуется процедура расторжения договора с ТП.

Рассмотрим подробнее каждый этап работы обслуживающего банка с ТП.

Этап 1. Рассмотрение заявки на регистрацию электронного торгового предприятия и заключение договора

На данном этапе банк получает от ТП комплект документов, включающий в себя:

• нотариально заверенные копии учредительных документов и Устава, свидетельств о регистрации в МРП и постановке на учет в налоговых органах, а также лицензий/разрешений ТП на заявленные виды деятельности;

• ксерокопии паспортов руководства ТП (директор, главный бухгалтер) и основных учредителей (в случае наличия в составе учредителей физических лиц), а также ксерокопии трудовых книжек вышеуказанных лиц;

• бухгалтерский баланс с отметкой инспекции МНС;

• анкету ТП, заверенную руководством ТП.

Рекомендуется, чтобы анкета ТП содержала следующие сведения:

• торговую марку ТП;

• название юридического лица, выполняющего функции ТП;

• паспортные данные руководителей ТП (директор, главный бухгалтер);

• при наличии «физического» магазина, являющегося основой для электронного бизнеса, фактический адрес ТП;

• URLTn;

• E-mail и контактные телефонные номера для обслуживания клиентов ТП. Контактные телефоны и E-mail ответственных менеджеров, в том числе по вопросам технического функционирования ТП и безопасности;

• IP-адрес сервера, на котором расположен сайт ТП;

• данные о компании-владельце хостинга и его учредителях;

• краткую историю бизнеса ТП (в частности, необходимо указать, работало ли ранее торговое предприятие через другие банки и если да, то почему оно меняет обслуживающий банк);

• подробный перечень предоставляемых товаров и услуг с указанием для каждой услуги или товара разброса в ценах;

• если данное предприятие является биллинговой компанией (через нее обслуживаются несколько ТП, в иностранной литературе также используется термин merchant aggregator), то требуется указать данные по предыдущему пункту для каждого обслуживаемого биллинговой компанией ТП. В идеале банк должен заключать прямой договор на обслуживание с каждой торговой точкой;

• если ТП уже ранее функционировало, указывается средний размер транзакции, количество транзакций, количество chargeback, процент объемов chargeback к общему объему покупок, время функционирования ТП;

• если ТП ранее не функционировало, указываются ожидаемые значения оборотов и количества транзакций;

• наличие (отсутствие) в ТП собственной системы безопасности, системы защиты БД карт клиентов (если таковая ведется), а также системы анализа транзакций на потенциальное мошенничество (предоставляется краткое описание архитектуры системы, используемых алгоритмов и критериев);

• наличие в ТП собственной службы безопасности с указанием ее контактных адресов;

• предложения по предоставлению дополнительных поручительств физических лиц либо иных структур за ТП.

Банк, получив вышеуказанный комплект документов, проводит проверку фирмы по следующим направлениям:

1. Подтверждение факта регистрации фирмы в РФ.

2. Проверка действительности паспортных данных руководителей ТП.

3. Проверка руководства ТП на предмет наличия ликвидного имущества в личной собственности, регистрации на их имя других юридических лиц.

4. Проверка наличия претензий со стороны правоохранительных и налоговых органов к ТП либо к близким к ТП структурам.

5. Проверка наличия лицензий и разрешений на осуществляемую ТП деятельность.

6. Проверка адресов электронной почты и контактных телефонов для обслуживания клиентов.

Банк, получив анкету ТП, выполняет следующие действия:

1. Проверяет соответствие URL и IP-адреса хоста.

2. Устанавливает юридическое лицо, на которое зарегистрировано доменное имя и IP-адрес сервера для сайта магазина (по БД РосНИИРоса).

3. Если ТП торгует физическими товарами, проверяет наличие физического офиса ТП.

4. Если ТП использует услугу хостинга для организации своего Web-сайта, производится проверка информации о компании-владельце хостинга.

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

6. Сравнивает списки продаваемых услуг или товаров из анкеты ТП и по электронной витрине ТП.

7. Классифицирует ТП на предмет его степени риска. К высоко рискованным предприятиям априори относятся Adult Entertainment (развлечения для взрослых), игры в реальном масштабе времени/ лотереи (gambling/lottery), магазины, торгующие информацией и ПО, магазины, работающие по схеме ребиллинга (то есть магазины, безакцептно дебетующие на регулярной основе счета своих клиентов, например некоторые биллинговые компании, ISP-провайдеры), предприятия, торгующие дорогостоящей аудио- и видеоаппаратурой и другими товарами, легко реализуемыми мошенниками в реальном мире за наличные, предприятия, оказывающие услуги со значительной задержкой от момента совершения оплаты (например, подписка на различные услуги). По данным исследования компании Gartner Group вероятность возникновения chargeback в таких ТП в среднем составляет 15 %, достигая в отдельных электронных магазинах 30 %. Наоборот, к низкорискованным ТП относятся продажа билетов, книг, CD/DVD-дисков и т. п.

8. Проверяет информацию о ТП по БД международных платежных систем MATCH и NMAS (данные БД содержат информацию о мошеннических и подозрительных ТП).

9. Проверяет наличие на сайте ТП ссылок на «подозрительные» сайты (например, на сайты Adult Entertainment).

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

11. Проверяет, ясны ли покупателю процедуры заказа товаров и их оплаты по карточкам. Проверяет наличие на Web-сайте ТП ясной информации о сроках доставки товара.

12. Проверяет наличие на сайте описания процедур возврата покупателю товаров/денежных средств, контактных данных ТП (адрес электронной почты, телефона) для покупателя, описания способов доставки товаров, экспортных ограничений и страны регистрации ТП.

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

14. Проводит пробную транзакцию для оценки времени доставки товара и проверки содержимого электронного чека, предоставляемого владельцу карты в качестве подтверждения выполнения транзакции. В электронном чеке должны присутствовать номер заказа, ясный для покупателя идентификатор ТП (это очень важно, поскольку практика показывает, что частой причиной отказа клиента от транзакции является неузнаваемость имени магазина на электронном чеке и в стейтменте о транзакциях), совпадающий с именем сайта ТП, имя покупателя, дата транзакции, размер транзакции и код валюты, код авторизации (Approval Code), контактные телефоны и адреса электронной почты для обращения клиента в случае возникновения вопросов, перечень покупаемых товаров и услуг, тип транзакции (покупка). Требования к электронному чеку хорошо изложены в VISA International Operating Regulations, Volume 1 — General Rules, Exhibit 71 «Electronic Transaction Receipt».

На основе полученных результатов банк принимает одно из следующих решений:

• отказать на запрос торгового предприятия по его обслуживанию в банке;

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

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

Ниже в порядке убывания степени защиты от мошенничества приведены возможные схемы проведения транзакции ЭК:

• Транзакция с реализацией надежной процедуры аутентификации владельца карты, принятой в банке-эмитенте карты. Схема, очевидно, может использоваться только для карт, эмитированных банками, реализующими надежные протоколы ЭК.

• Транзакция, совершаемая в отложенном режиме (то есть в режиме off-line), с проверкой следующих данных: номера карты, срока действия карты, имени владельца карты, CVV2, номера паспорта. Транзакция считается успешной, если эмитент по отдельности подтверждает правильность представленных в запросе обслуживающего банка данных. В противном случае, даже если эмитент присылает общее подтверждение, транзакция отвергается. В запросе должна специально оговариваться необходимость предоставить результат проверки по каждому элементу реквизитов транзакции. Запрос в банк-эмитент может передаваться разными способами, например с помощью принятой в международных платежных системах так называемой телексной авторизации.

• Транзакция с обязательной проверкой CVV2/CVC2.

• Транзакция с переходом на отложенную авторизацию и обязательным подтверждением номера карты, срока ее действия и имени клиента (проверка CVV2/CVC2 запрашивается, если карта содержит этот параметр, но наличие результата проверки необязательно; в то же время, если в ответе эмитента утверждается, что значение CVV2 неверно, транзакция отклоняется).

• Транзакции с обязательной проверкой только номера карты и срока ее действия.

Для каждого ТП на основании «профиля» торгового предприятия определяются значения Х1 Xj, Х4, суть которых состоит в следующем:

• если размер транзакции превышает значение Х4, то обязательным является проверка по схеме 1;

• если размер транзакции лежит в диапазоне (X,,X4, то минимально возможный уровень защиты — схема 2;

• если размер транзакции лежит в диапазоне (Х2,Х3], то минимально возможный уровень защиты — схема 3;

• если размер транзакции лежит в диапазоне (Х1Х2], то минимально возможный уровень защиты — схема 4;

• если размер транзакции меньше X1, то возможно использовать любой способ (схему) проведения транзакции.

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

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

2. Обязательство ТП предупреждать обслуживающий банк об изменении «профиля» магазина (появление принципиально отличающихся по цене и видам товаров). Всякое такое изменение должно оформляться в виде дополнительного приложения к договору.

3. Должна иметься статья, указывающая на то, что ТП обязано проводить любую транзакцию ЭК в режиме реального времени (Floor Limit=0).

4. Должны быть оговорены персональные гарантии учредителей ТП с одновременным заключением отдельного договора поручительства для покрытия расходов, связанных с мошенничествами по ЭК.

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

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

7. В договоре или приложении к нему должен быть указан МСС ТП.

8. В отдельном пункте договора должна оговариваться полная ответственность ТП за хранение реквизитов карт.

9. Должно быть отмечено, что для хранения данных о реквизитах карт могут использоваться симметричные алгоритмы шифрования с длиной ключа не менее 128 битов и/или асимметричные алгоритмы с длиной ключа не менее 1024 битов. Сервер, хранящий данные о картах, может быть подключен к Интернету только через специальные средства защиты сетевого доступа Firewall.

10. Должна быть оговорена процедура защиты данных карты при их передаче между ТП и хостом банка. Необходимо потребовать, чтобы сервер ТП при вводе данных о реквизитах карты поддерживал с покупателем защищенную сессию, организуемую с применением симметричного шифрования с длиной ключа не менее 128 битов; в случае использования для защиты реквизитов карты SSL-сессии ТП должно контролировать размер ключа, поддерживаемого браузером покупателя, и, если последняя меньше 128 битов, отказывать покупателю в проведении транзакции, указывая ему адрес сервера, с помощью которого он может модернизировать свой браузер, обеспечив поддержку симметричного шифрования на ключе длиной не менее 128 битов. При использовании асимметричных алгоритмов шифрования длина ключа должны быть не менее 1024 битов.

11. Должно быть предъявлено требование, чтобы на сайте ТП имелись четкие разъяснения для покупателя по процедурам безопасного хранения частной информации о покупателе, а также процедурам, гарантирующим покупателю невозможность компрометации данных его карты при проведении транзакции. По правилам системы VISA этот пункт должен быть включен во все договоры обслуживающего банка с его Интернет-магазинами до 1 января 2002 г.

12. Должен оговариваться режим регулярных инспекций ТП со стороны обслуживающего банка и всяческая помощь банку в осуществлении таких проверок со стороны ТП.

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

14. Должна предусматриваться возможность инициализации торговым предприятием расследования по подозрительным с точки зрения ТП транзакциям.

15. Должна быть предусмотрена оплата услуг по мониторингу транзакций ТП. Технология мониторинга должна сообщаться ТП.

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

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

и контактные телефоны (адреса электронной почты) ответственных

менеджеров, в том числе по вопросам технического функционирования ТП и безопасности.

Этап 2. Контроль функционирования ТП

I. В целях осуществления контроля за деятельностью ТП необходимо проводить регулярные инспекции ТП специалистами банка. Содержание инспекции:

1. Проверка ассортимента предоставляемых ТП услуг и товаров с использованием ранее сохраненных электронных копий (HTML Source) страниц сайта данного ТП, связанных с описанием продаваемых товаров-услуг.

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

3. Создание электронных копий (HTML Source) для новых страниц сайта ТП, содержащих описание продаваемых товаров, услуг.

4. Проверка наличия средств защиты БД карточек ТП и обеспечения защищенности соединений между ТП и владельцем карты.

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

II. Мониторинг транзакций ЭК на предмет выявления подозрительных транзакций и ТП. По подозрительным случаям банк инициирует и проводит специальные расследования.

III. Подготовка еженедельных статистических данных, необходимых для анализа функционирования ТП (как минимум, количество и объемы операций с разбивкой по платежным системам, уровень chargeback). Ведение негатив-файла (файла исключений) по картам и некоторым другим данным владельцев карт (телефон, e-mail, адрес), для которых имели место сообщения chargeback с Reason Code 83, 79 (VISA) и 37 (Europay).

IV. Ведение БД ТП, с которыми была приостановлена работа, с указанием причины расторжения договора и реквизитов, которые могут быть полезны для распознавания ТП при попытке повторного заключения договора (IP-адрес, URL сайта, Ф.И.О. директоров и учредителей и т. п.). Проведение расследования по подозрительным транзакциям.

V. Расследование инициируется либо по результатам анализа клиринговых файлов международных платежных систем (chargeback), статистических данных по ТП, данных мониторинга транзакций ЭК, либо по запросу ТП.

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

1. Карта эмитирована иностранным банком, и ее владелец делает покупку в российском ТП, используя российский IP-адрес.

2. Большое количество транзакций по одной карте в день.

3. Большой размер транзакции по отношению к ценовому ассортименту ТП.

4. Маленький размер транзакции по отношению к ценовому ассортименту ТП.

5. Большое количество транзакций по данному префиксу.

6. Слишком высокая активность ТП в терминах количества транзакций.

7. Слишком высокая активность ТП в терминах объема операций.

8. Слишком высокий процент отвергнутых эмитентами транзакций от общего количества транзакций, совершенных в ТП.

9. Высокий уровень chargeback по ТП.

По причинам 1-5:

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

• банк «замораживает» средства на страховом депозите ТП, если пре-зентмент по транзакции уже был отправлен в сеть; в противном случае — временно задерживает отправку презентмента до окончания расследования;

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

По причинам 6-9 банк предпринимает следующие действия:

• выясняет причины роста трафика (банк обращается за разъяснениями в ТП — возможно, ТП запустило новую услугу, пользующуюся спросом, и таким образом рост транзакционного трафика объясним);

• принимает решение по ужесточению схемы проведения транзакции (уменьшение параметров, для которых минимально обязательными становятся более защищенные методы авторизации);

• изменяет страховой депозит ТП и замораживает средства ТП для формирования нового значения страхового депозита.

Расследование может дать следующие результаты:

• банк-эмитент подтверждает факт проведения транзакции его клиентом. В этом случае банк оповещает ТП о возможности выполнения заказа, если он еще не был выполнен, и размораживает сумму транзакции на страховом депозите ТП, если эта сумма ранее была заморожена;

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

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

Если размер транзакции меньше величины Z, но больше Y, решение по результату выполнения операции перекладывается на ТП, но при обязательном «замораживании» суммы транзакции на страховом депозите ТП на срок 120 дней (срок, в течение которого эмитент может отправить банку chargeback).

Если размер транзакции меньше величины Y, то решение перекладывается на ТП без замораживания суммы транзакции. Значения Z и Y определяются банком на стадии подключения ТП к системе ЭК.

VI. Вычисление на регулярной основе новых значений страховых депозитов по каждому ТП на основе последних статистических данных о функционировании ТП.

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

Этап 3. Прекращение договора с ТП

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

• внести ТП в базу данных торговых предприятий, с которыми были разорваны договорные отношения;

• изменить значения параметров в программе мониторинга ТП;

• в случае необходимости сообщить о разрыве договорных отношений с ТП в международную платежную систему.

Виртуальные карты

Идея виртуальной карты основана на том, что во время проведения CNP-транзакции пластиковая карта как физический объект не применяется. Используются лишь реквизиты карты, и совсем необязательно, чтобы они были нанесены на пластик. Поэтому можно выделить отдельные предназначенные специально для ЭК номера карт с сопутствующими им реквизитами и «привязать» к таким виртуальным картам счета с небольшим остатком. В этом случае клиент будет застрахован от крупных потерь, связанных с риском мошенничества в ЭК.

Таким образом, смысл виртуальной карты заключается в том, чтобы психологически «раскрепостить» клиента при совершении электронных покупок. Действительно, карта, которой пользуется покупатель, связана с небольшим по размеру счетом, и потому весь риск покупателя ограничен потерей средств на этом счете.

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

Требования к виртуальным картам состоят в следующем:

• виртуальная карта должна иметь номер (система MasterCard требует, чтобы номер карты состоял из 16 цифр) и срок действия;

• система MasterCard требует, чтобы с виртуальной картой была связана величина CVC2 (VISA оставляет вопрос использования величины CVV2 для виртуальной карты на решение эмитента карты);

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

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

• эмитенты должны утвердить выпуск виртуальных карт в соответствующих департаментах сертификации карт международных платежных систем;

• эмитент должен ясно объяснить владельцу виртуальной карты, что она не может использоваться в режиме Dual Mode, когда авторизация производится по виртуальной карте, а презентмент сформирован по обычной карте, привязанной к тому же счету, что и виртуальная карта.

Для того чтобы передать клиенту реквизиты виртуальной карты, эмитент может использовать некоторый физический носитель информации о реквизитах карты (Reference Device — RD). RD по своим физическим характеристикам должен явным образом отличаться от обычной карты. В частности, RD не должен иметь тех же размеров и пропорций, что и обычная карта, содержать голограмм платежных систем, а также магнитной полосы и чипа.

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

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

• владельцу «физической» карты;

• клиенту, не имеющему «физической» карты платежной системы, но имеющему возможность получить ее по его первому требованию.

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

Гута Банк стал первым российским банком, который приступил к эмиссии виртуальных карт платежной системы VISA, получивших название VISA E-c@rd и специально предназначенных для осуществления платежей в Интернете. Проект был запущен летом 2000 г. после того, как компания VISA International завершила сертификацию VISA E-c@rd и официально санкционировала их эмиссию Гута Банком.

13-2103

Карты VISA E-c@id предназначены для оплаты через Интернет любых видов товаров и услуг в любых электронных магазинах во всем мире, в том числе для оплаты услуг операторов сотовой связи, Интернет-провайдеров, туристических компаний, предприятий гостиничного бизнеса и т. д. Для проведения других операций (расчетов в обычной торговой сети, получения наличных денежных средств) карта VISA E-c@rd не предназначена.

Платежи при помощи VISA E-c@rd осуществляются следующим образом. Выбрав товар в электронном магазине, держатель карты, находясь в защищенной сессии с сервером ТП, вводит в компьютер номер пластиковой карты и срок окончания ее действия. Далее транзакция обрабатывается по тем же законам, что и любая другая (не ЭК) транзакция.

Пополнять счет, связанный с картой VISA E-c@rd, клиенты могут путем внесения наличных денежных средств через кассы в филиалах Гута Банка, через систему Интернет-бэнкинга Телебанк, посредством перевода средств с других счетов (в том числе и карточных) в Гута Банке, а также через перевод средств со счетов в других банках.

Карта VISA E-c@rd Гута Банка выдается сроком на 6 месяцев. Стоимость обслуживания карты составляет $2 за полгода.

Еще одним участником проекта является один из ведущих российских Интернет-провайдеров компания «МТУ-Информ». «МТУ-Информ» будет обеспечивать распространение карт VISA E-c@rd среди своих клиентов. При помощи карты VISA E-c@rd клиенты «МТУ-Информ» могут в режиме реального времени оплачивать услуги доступа в сеть Интернет, аренды программного обеспечения, Интернет-телефонии и т. д.

Виртуальную карту Eurocard/MasterCard Virtual в системе MasterCard эмитирует и другой российский банк — Альфа-Банк. Открытие карты в этом банке обходится ее владельцу в $2, стоимость годового обслуживания карты равна $3. Минимальный первоначальный взнос при открытии карты составляет $20.

Технология Eurocard-MasterCard Virtual Card реализуется в 40 банках, расположенных в 8 странах. Среди банков, использующих эту технологию, два крупнейших испанских банка — La Caixa и BSCH, турецкие банки Citibank и Garanti Bank, португальский банк Unicre и другие.

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

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

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

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

Виртуальные номера карт

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

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

13

После этого транзакция выполняется обычным образом. Клиент направляет Интернет-магазину заполненную форму, в которой в качестве номера карты фигурирует виртуальный номер. В результате выполнения стандартных процедур обработки транзакции в системе обслуживающего банка и платежной системы из последней в систему эмитента поступает авторизационный запрос, содержащий виртуальный номер карты. Эмитент, получив авторизационный запрос, устанавливает соответствие между данными, сгенерированными при инициализации транзакции, и данными авторизационного запроса. Соответствие ищется по целому ряду параметров. Например, система MasterCard к обязательным параметрам относит номер карты, срок ее действия, имя магазина (Merchant Name), идентификатор магазина (Merchant ID), сумму транзакции и валюту транзакции. Эмитент определяет реальный номер карты, выполняя обратное преобразование, проводит с его использованием авторизацию транзакции и результат возвращает в платежную сеть, предварительно вновь подставив в авторизационный ответ виртуальный номер карты.

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

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

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

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

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

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

В-третьих, помимо виртуального номера карты система эмитента в некоторых случаях должна в режиме реального времени генерировать значения CVC2/CVV2. Напомним, что в системе MasterCard использование CVC2 в транзакциях ЭК коммерции является обязательным.

Конечно, эмитент, применяющий технологию виртуальных номеров карт, может и не проверять значения CVC2. В этом случае в платежную сеть может направляться любое случайное значение CVC2. Однако при таком подходе эмитент лишается возможности использовать резервную авторизацию (авторизацию Stand-in), предоставляемую в его распоряжение многими платежными системами на случай отказа в работе системы эмитента. В режиме резервной авторизации платежная сеть от лица эмитента в соответствии с параметрами, установленными эмитентом, производит авторизацию транзакции. В системе резервной авторизации существует общий параметр для всех префиксов карт, определяющий действие эмитента на случай неверного значения CVC2/CVV2 — отклонить транзакцию сразу или продолжить другие проверки. Если такой параметр установить равным значению, означающему «не отклонять», то и по всем другим операциям и префиксам будет приниматься то же решение, что наверняка противоречит интересам эмитента.

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

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

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

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

Сегодня технология виртуальных номеров карт получила распространение среди ряда крупных банков. Например, четвертый по размеру американский эмитент пластиковых карт Discover предлагает 50 миллионам своих клиентов услугу Discover DeskShop. В основе Discover DeskShop лежит технология виртуальных карт в реализации ирландской компании Orbiscom (). Решение этой компании O-power используется не только в Discover, но и в банках MBNA (система MBNA Shopsafe, создается для пользования 45 млн владельцев карт), HFC (английский филиал компании Household International) и Allied Irish Banks.

Система O-power для случая 16-цифрового номера карты и 6-цифро-вого BIN карты генерирует до 1 млрд различных значений виртуальных номеров карт (в терминах Orbiscom — Controlled Payment Number). Период повторного использования виртуального номера карты в системе — 9-12 месяцев.

Для банка Discover система O-power реализована на базе высокопроизводительных серверов Е450 компании Sun Microsystems, технологии Oracle и известного программного обеспечения для «свитча» платежной системы Oasis. Клиенту DeskShop достаточно ввести свой пароль для того, чтобы система эмитента заполнила для клиента платежную форму магазина (для этого необходимо, чтобы магазин участвовал в проекте Discover).

Компания Orbiscom не поставляет решений для электронного кошелька клиента. Внедрение технологии виртуальных номеров карт на стороне клиента остается задачей банка-эмитента. При этом может применяться уже используемый электронный кошелек.

Другое известное на рынке решение Nexus-1 предлагается американской компанией Appletix (филиал компании по разработке программных продуктов располагается в Израиле). Клиентами этой компании являются крупнейший канадский банк CIBC (4 млн владельцев карт на начало 2001 г.) и процессинговая компания VISA Israel Credit Cards. Решение Nexus-1 предлагает двухфакторную аутентификацию клиента — аутентификацию клиента по его паролю и аутентификацию компьютера клиента по некоторому специальному алгоритму.

Решение на основе виртуальных номеров карт предлагает также компания Cyota ().

В конце первого квартала 2001 г. платежная система Maestro (оператор дебетовых карт Maestro) объявила о том, что банки, эмитирующие эти дебетовые карты, могут использовать для реализации систем ЭК технологию виртуальных номеров карт (е-Wallet Maestro solution). Карты Maestro начнут приниматься некоторыми наиболее известными Интернет-магазинами начиная с третьего квартала 2001 г.

Требования к технологии виртуальных номеров карт при использовании карт Maestro состоят в следующем. Эмитент должен генерировать 16-цифровые номера карт (при этом виртуальный номер карты может совпадать с реальным номером карты), а также проверять соответствие между данными, сгенерированными при инициализации транзакции, и данными авторизационного запроса. Как указывалось ранее, соответствие ищется как минимум по номеру карты, сроку ее действия, имени магазина (Merchant Name), идентификатору магазина (Merchant ID), сумме транзакции и валюте транзакции.

Отличительная особенность решения для карт Maestro заключается в том, что владелец карты не должен устанавливать на своем компьютере никакого специального ПО (электронного бумажника). Транзакция выполняется следующим образом. После того как владелец карты сообщил ТП о готовности платить с использованием карты Maestro, Интернет-магазин отправляет на сервер эмитента (e-Wallet в терминах Maestro), хранящий информацию о реквизитах своих карт, специальное сообщение. Это сообщение содержит информацию о ТП (Merchant Name, Merchant ID), о сумме и валюте покупки, идентификатор транзакции в системе ТП и т. п. Одновременно сервер магазина переключает владельца карты на сервер эмитента.

Сервер эмитента устанавливает с владельцем карты защищенное соединение и направляет клиенту форму для проведения его аутентификации. Например, эмитент может запросить у владельца карты ранее предоставленные ему идентификатор и пароль.

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

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

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

Распределение ответственности при возникновении диспута по транзакции ЭК ничем не отличается от того, каким образом оно производится при использовании модели трех доменов.

Другие решения по расчетам на базе пластиковых карт

О некоторых других схемах проведения транзакций ЭК, повышающих безопасность платежей, говорилось ранее. Безусловный интерес представляет идея применения ПИН2, реализованная для банков-участников платежной системы STB CARD. Идея проста в реализации и эффективна с точки зрения защиты электронных платежей от мошенников.

Об идее системы банка First Virtual также уже коротко говорилось в предыдущем параграфе. Суть идеи состоит в том, чтобы вместо реального номера карты ее владелец при инициализации транзакции ЭК представлял некоторый код, называемый VirtualPIN, которой, в свою очередь, на платежном сервере First Virtual заменяется на реальный номер карты. В результате ТП не видит реального номера карты и не хранит его в своих БД, что понижает шансы мошенников на успех. Кроме того, даже если мошенникам удастся украсть БД VirtualPIN, это не будет иметь для эмитентов карт столь серьезного значения, поскольку эту БД можно просто обновить — перевыпускать карты клиентам не понадобится. Более того, обновление БД VirtualPIN целесообразно для повышения безопасности электронных платежей.

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

Идея VirtualPIN реализует защиту транзакции ЭК со стороны обслуживающего банка. Это снижает область ее применения только Интернет-магазинами, обслуживаемыми только этим обслуживающим банком. С другой стороны, от клиента, как правило, использование такой защиты не требует больших усилий. Другими примерами повышения безопасности транзакций ЭК со стороны обслуживающего банка являются системы CyberCash и VeriFone. Поскольку системы во многом напоминают друг друга, расскажем подробнее об одной из них, а именно о системе CyberCash.

2 0 2 Глава 5. Другие модели построения систем электронной коммерции Общая схема функционирования системы показана на рис. 5.1.

Глава 5. Другие модели построения систем электронной коммерции
Рис. 5.1. Система CyberCash
Основная идея системы CyberCash заключается в организации виртуального POS-сервера для подключения к нему Интернет-магазинов. В этом случае ТП на своем сервере должно имплементировать небольшое приложение, называемое Merchant Connection Kit (MCK), с помощью которого устанавливается надежное соединение с POS-cep-вером CyberCash, называемым также CashRegister. Весь трафик между МСК и POS-сервером шифруется с помощью алгоритма Triple DES, что обеспечивает защищенную передачу реквизитов карты и данных транзакции через Интернет. С другой стороны, POS-сервер подключен к платежным системам в соответствии со стандартными протоколами межхостовых соединений.

Системы расчетов, не использующие технологию пластиковых карт

Системы электронной наличности

Идея электронных наличных появилась более 10 лет назад. В 1980-х годах голландец Давид Шаум (David Chaum, после переезда в США чаще именуемый на англо-американский манер Дэвидом Чомом) получил патенты на разработанные им криптографические алгоритмы «слепой подписи», которые закладывали фундамент для альтернативы всем существовавшим системам платежей. Протоколы Чома позволяли создавать виртуальные электронные монеты, которые могли циркулировать подобно деньгам в онлайновой среде, абсолютно никак не раскрывая личности своих хозяев.

Сначала в Нидерландах, а потом и в США Чом основал компанию DigiCash, предназначенную для распространения технологии электронной наличности. В 1995 г. были запущены первые реальные проекты, когда систему электронных наличных лицензировал американский

банк Mark Twain, а также несколько крупных банков и компаний в Европе, Австралии и Японии.

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

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

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

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

В случае с DigiCash покупателям по сути дела не предоставлялось никаких финансовых стимулов к переходу на новую систему. Наоборот, электронные монеты в отличие от банковских счетов не приносили их владельцам никаких процентов. Более того, существовала постоянная угроза компрометации «бумажника» клиента на его персональном компьютере. Повышенный риск ощущали и продавцы, поскольку су-шествовала угроза двойной траты электронных монет, хотя клиринговая система банков обещала свести потери от этого к минимуму. Сегодня преемником дела DigiCash стала компания eCash Technologies, выкупившая все активы обанкротившейся фирмы и в марте 2000 г. объявившая о намерении продолжить внедрение электронных наличных. Коротко остановимся на технологических аспектах применения электронной наличности. Еще раз повторим, что электронная наличность — это цифровые данные (последовательность бит) специального вида, эмитируемые банком. Цифровые данные включают в себя идентификатор электронной монеты (купона), денежный номинал монеты и циф -ровую подпись банка, эмитировавшего монету.

Процедура эмиссии цифровой монеты в общих чертах выглядит следующим образом. Клиент, имеющий счет в банке, направляет в банк запрос об эмиссии ему монеты определенного номинала взамен соответствующей суммы денег, находящихся на его счете. Для этого клиент генерирует некоторую случайную цифровую последовательность, представляющую собой идентификатор монеты, и добавляет к ней номинал монеты. Получившуюся в результате последовательность (обозначим ее а) клиент с помощью некоторой хэш-функции h(x) преобразует в значение 1і(а). Далее на своем компьютере клиент вычисляет значение R=h(a)xbc(mod N), ткрытого ключа его банка (банк

для подписи использует алгоритм RSA с модулем N, экспонентой закрытого ключа d, экспонентой открытого ключа е), b — случайное число. Число b называют «слепым множителем» (blinding factor). Полученное в результате значение R клиент направляет в банк вместе с запросом на эмиссию монеты определенного номинала.

Банк, получив запрос клиента, списывает с его счета значение номинала монеты (и, возможно, комиссионные), зашифровывает R своим закрытым ключом, то есть вычисляет значение R"1 (mod N ), и полученное значение возвращает клиенту.

Нетрудно видеть, что имеет место равенство Rd (mod N)= h(a)dxb (mod N) Поэтому, получив от банка значение Rd (mod N), клиент легко освобождается от известного ему «слепого множителя» b (это делается с помощью алгоритма Евклида нахождения наибольшего общего делителя чисел b и N) и получает значение подписи последовательности а, равное h(a)H (mod N). Последова 1Ць)‘Діо<ж1 Kb) и является цифровым выражением электронной монеты.

Таким образом, клиент получает электронную монету ¦ а. !ца)'1 (mod N;¦), которая может быть предъявлена клиентом банку. При этом банк не сможет идентифицировать, кому была выдана эта монета. Благодаря «слепому множителю» Ь, банк непосредственно сам никогда не подписывал а. Все, что известно банку, — это значение h(a)dxb (mod N), которое благодаря «слепому множителю» b представляет собой просто случайное число. В то же время банк, проверив цифровую подпись в электронной монете, сможет легко установить, что данная монета была эмитирована именно им.

Таким образом, реализуется одно из важнейших свойств обычных денег — анонимность. Безопасность банка в схемах электронной наличности основывается на стойкости алгоритма RSA Применение хэш-функции h(x) в описанной здесь конструкции необходимо ввиду известного свойства мультипликативности RSA: если s, и s2 — подписи для іщ и т2 соответственно, то s|xsj=(mld)x(m2<l) (mod N) — подпись для m,xm2 Поэтому, если в качестве электронной монеты использовать последовательность (а, а' (и ні N)>, то, имея две электронные монеты, легко изготовить третью.

Очевидно, что электронная наличность помимо анонимности обладает и другими важнейшими свойствами денег:

• возможностью обмена на товары и услуги;

• единовременностью и окончательностью расчетов с их использованием (здесь требуется оговорка, связанная с необходимостью использования в некоторых случаях клиринговых систем или авторизации в реальном масштабе времени принятой наличности в банке, эмитировавшем эту наличность);

• делимостью суммы.

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

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

Существует несколько способов решения этой проблемы. Один из них состоит в следующем. Клиент направляет эмитенту М (М — достаточно большое число) последовательностей K“h( a)xb‘ (mod N) с разными значениями а и Ь, но с одним и тем же номиналом монеты. Банк случайным образом выбирает (М-1) последовательностей и запрашивает у клиента соответствующие значения а и Ь. Таким образом, банк проверяет, насколько «искренен» был клиент в выбранных им для проверки случаях. Легко видеть, что описанное решение обеспечивает защиту банка от обмана клиента с вероятностью 1—1/М.

Другая фундаментальная проблема состоит в возможности повторного использования монеты (double-spending). Классическим решением проблемы является применение единого авторизационного центра. Использованная однажды монета заносится в «черный список» и при попытке повторного применения опознается как использованная.

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

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

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

Рассмотрим одну из них, изложенную в основополагающей работе Чома. Система основана на использовании алгоритма RSA Будем обозначать а<|/|> (mod N) вместо ad(modN),raedxts 1 (mod (p-l)x(q-l)),N-pxq. и называть эту величину корнем t-й степени из а.

Рассматривается бесконечный ряд простых чисел с(1 )=3, с(2)=5, с(3)=7, с(4)=11,... Устанавливается следующее соглашение: номиналу 21 кибердолларов (КД) соответствует корень степени c(i+l), где i>0, из хэш-функции h(a). Таким образом, одному КД соответствует монета

(а, h(a)',/3,(modN)), 4 КД (а, h(a)(l,,)(mod N)) и т. д. В общем

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

Все банкноты, выдаваемые банком, имеют одинаковое достоинство. Для простоты изложения будем считать, что оно равно 15 КД. Тогда подпись банкноты должна представлять собой корень степени ? 3x5x7 > 11 хэш-функции 1т(а). Таким образом, клиент получает от банка монету (а, h(a)" "’(mod N)>. Очевидно, что для того, чтобы корень степени w существовал, необходимо и достаточно, чтобы w и ; р- 1 р -1 . были взаимно простыми. Для этого достаточно, чтобы простые сомножители, на которые раскладываются числа (р-1) и (q-1), были достаточно большими (больше максимального сомножителя в разложении w). Если w и (p-l)x(q-l) — взаимно простые числа, существует такое 1, что \?*1 = 1 (mod (р 1 )x(q- 1)). Более того, число 1 вычисляется с помощью известного алгоритма Евклида для нахождения наибольшего общего делителя двух целых чисел. На реализацию этого алгоритма тре-о?чсч не бо к? э іемен іарных операции.

Очень важно также отметить, что корень степени w может вычислить только банк, поскольку для нахождения 1 требуется знать секретные значения простых чисел р и q. Поэтому эмитировать монету никто, кроме банка, не сможет.

Процедура получения клиентом монеты {а, 1ц а V! "1 (в і ип N)} аналогична схеме, описанной ранее. Разница состоит только в том, что клиент направляет в банк вместо h(a)xi>' (mod N) число li(a)xl>* (mod X). В этом случае процедура освобождения от «слепого множителя» не меняется — достаточно полученную подпись банка «разделить» на число b. Рассмотрим теперь, как в схеме Чома осуществляются покупка и возврат электронной наличности. Начнем с покупки. Предположим, клиент, имея монету номиналом 15 КД, хочет потратить 5 КД. Для этого он вычисляет (а. h (а)‘ ) (mod N)), возведя подпись имеющейся моне

ты в 55-ю степень. Кроме того, клиент создает электронную копилку. Для этого он генерирует случайное число а„ вычисляет Ь (a )xb, (m od N,), где N, — другой модуль схемы RSA, используемый эмитентом электронной наличности для копилки. Платеж состоит в передаче продавцу значений (a. h(a)(1 <3’7)) (mod N)), h(a,)xb|55 (mod N,), а также значения платежа 5 КД. Продавец, в свою очередь, передает всю эту информацию банку клиента.

Банк к-и.о іірогерчск чю і юс к- юта к- п.і юс и. (а, h(a)'l/<3o,>} (mod Щ)

представляет собой монету достоинством 5 КД. Кроме того, он проверяет по специальному списку, что монета с идентификатором а ранее не использовалась. Если проверки закончились успешно, банк увеличивает счет продавца на 5 КД и возвращает клиенту сдачу в размере 10 КД через копилку: h(a,)<1/55)xb1 (mod N,)

В транзакции возврата электронной наличности покупатель отправляет в банк копилку (a,, h(a,)‘1 ' (mod N,)). Банк проверяет ее так же, как

и электронную монету, и если копилка подлинная и ранее не использовалась, кредитует счет клиента на 10 КД.

Если бы все платежи, производимые клиентом, делались на сумму 15 КД, рассмотренная выше схема обеспечивала бы безусловную анонимность клиента. Транзакции возврата электронной наличности в банк (клиент обналичивает имеющуюся в его распоряжении копилку) могут нарушить анонимность клиента. Действительно, банк запоминает все платежи, а значит, и все сдачи покупателям. Поэтому если клиент совершил покупку на уникальную или достаточно редкую сумму, то и сдача также будет иметь уникальное значение. Следовательно, при возврате сдачи в банк, когда личность клиента устанавливается по его счету, банк может «вычислить», кто делал покупку на уникальную сумму, то есть анонимность покупок клиента нарушается.

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

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

Напомним, что в схеме Шнорра операции производятся в поле GF(p), где р — большое простое число. Рассматривается также подгруппа мультипликативной группы поля простого порядка q с образующим элементом g. Каждый клиент банка обладает секретным ключом х, содержащим идентификатор клиента, и открытым ключом y=gx (mod p).

В транзакции снятия со счета с целью эмиссии электронной монеты клиент выбирает случайное число к и вычисляет r=gk (mod p). Электронная монета состоит из некоторой строки, содержащей у и г, а также подписи банка для этой строки.

i~(g>(y')

Для совершения транзакции платежа клиент предоставляет продавцу электронную монету. Продавец проверяет подлинность подписи банка и, если она корректна, генерирует случайное число е, которое направляется клиенту. Клиент вычисляет ;Нг. - .? ; :и: *.1 ¦.] _> и возвращает s продавцу. Продавец, получив s и зная е, г, у, проверяет соотношение (mod p). Как известно, если рассматриваемое соотношение верно, клиент действительно обладает закрытым ключом х, соответствующим открытому ключу у.

В транзакции возврата электронной наличности на счет клиента продавец отправляет в банк электронную монету, а также числа е и s. Если продавец обнаруживает, что монета с параметрами у, г уже ранее использовалась, то есть у банка имеются две пары (<¦ л.; и », удовлетворяющих проверочному соотношению схемы Шнорра, то банк легко вычисляет секретный ключ х, решая систему двух линейных уравнений

s,“k-x*e, (mod q) s2=k-x*e2 (mod q)

относительно х. Зная х, банк может идентифицировать клиента, нарушившего правило системы.

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

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

14-2103

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

За рубежом получили популярность системы электронных чеков, разработанные компаниями CyberCash и FSTC (Financial Services Technology Corporation).

Преимущества схем электронной наличности перед системами пластиковых карт состоят в следующем:

• Наличие надежных средств аутентификации участников транзакции ЭК. Безусловно, протокол SET предоставляет не менее надежные средства обеспечения безопасности, но из-за того, что эти средства должны быть адаптированы для предоставления транзакции ЭК в конечном счете в платежную сеть, стоимость решения SET выше стоимости решений для схем электронной наличности.

• Себестоимость транзакции ЭК с использованием схем электронной наличности в несколько раз ниже аналогичного параметра в транзакции с использованием пластиковых карт. Главная причина здесь та же — при использовании пластиковых карт помимо среды Интернет применяются выделенные телекоммуникационные системы, увеличивающие стоимость транзакции. Себестоимость транзакции ЭК с использованием схемы электронной наличности составляет несколько центов.

• Комиссионные, выплачиваемые обслуживающим банком банку-эми-тенту карты, в платежной системе на базе пластиковых карт имеют структуру «X %, но не менее $Y». В результате небольшие платежи (размер платежа сравним с Y) становятся невыгодными. То же самое верно и для крупных платежей, но по другой причине. Если размер транзакции достаточно большой, что характерно для схем В2В, то комиссионные X % могут попросту «съесть» маржу продавца, сделав расчет за покупку через платежную систему невыгодным. В случае применения схем электронной наличности в силу низкой себестоимости транзакции можно рассчитывать на то, что оба параметра X и Y будут значительно ниже значений, характерных для систем на основе пластиковых карт.

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

Схемы электронной наличности получили распространение и в России. Сегодня известны две системы — PayCash и WebMoney Transfer.

Проект PayCash является совместной разработкой банка «Таврический» (С.-Петербург) и группы компаний «Алкор-Холдинг». Система PayCash реализует цифровой эквивалент чека. Электронные деньги появляются у пользователя в момент перевода денег с его счета на его платежную книжку (эквивалент чековой книжки) в электронном кошельке (программа, работающая на компьютере пользователя). Использование цифровой подписи позволяет пользователям платежной системы получать электронные денежные обязательства, которые позже не могут быть не признаны банком пользователя.

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

Кошелек продавца посылает кошельку покупателя требование об оплате, содержащее подписанный электронной цифровой подписью (ЭЦП) текст договора.

Если покупатель собирается платить, то его кошелек отправляет кошельку продавца электронные деньги и подписанный покупателем текст договора. Продавец отправляет электронные деньги в банк для авторизации.

Банк, получив электронные деньги, проводит авторизацию (проверяет подлинность электронного чека и остаток средств в рамках этого чека). Результаты авторизации передаются продавцу вместе с электронной квитанцией для покупателя. В случае успешной авторизации деньги переводятся на счет продавца.

Продавец передает покупателю электронную квитанцию банка и приступает к выполнению своих обязательств по оказанию соответствующих договору услуг покупателю.

В системе PayCash предполагается участие неограниченного числа банков, каждый из которых может выпустить собственные электронные деньги. Комиссионные платежной системы за процессинг транзакции составляет 1-2 % от ее размера.

В систему PayCash деньги можно ввести одним из следующих способов:

• наличными через один из 6 банков-партнеров системы;

• наличными, вызвав курьера на дом;

• банковским переводом;

• почтовым или телеграфным переводом;

• с помощью предоплаченной карты.

Вывести деньги из системы можно:

• почтовым или телеграфным переводом;

• переводом на счет в российском банке;

• наличными в офисе фирмы в Санкт-Петербурге.

Электронной наличности в системе PayCash придается статус предоплаченных финансовых продуктов в рамках указаний ЦБ РФ №№ 276,277 (подробнее об этом сказано чуть позже). В связи с этим система PayCash работает только с рублями.

На январь 2001 г. в системе были зарегистрированы 30 магазинов и 11 тысяч пользователей. Ежедневно к системе подключалось около 60 пользователей.

Теперь несколько слов о системе WebMoney Transfer. Система предоставляет возможность пользователю Интернета осуществлять безналичные расчеты в масштабе реального времени с использованием электронной наличности WEBMONEY (WM).

Клиентами системы являются продавцы и покупатели товаров и услуг. С одной стороны, это Web-магазины, с другой — любой пользователь Интернета, не имеющий возможности или не желающий использовать традиционные методы расчетов (кредитные карточки и т. п.). Стать клиентом системы пользователю позволяет клиентское программное обеспечение — WEBMONEY KEEPER. С помощью этой программы пользователь получает возможность фиксировать определенные суммы для расчетов, контролировать движение собственных или перечисленных ему средств.

С помощью программы WEBMONEY KEEPER возможно:

1. В любое время принять или отказаться от WM, переведенных пользователю любым другим клиентом системы по сети Интернет.

2. Перевести по сети Интернет любое количество WM любому другому клиенту системы. Такими клиентами могут быть как частные лица, так и компании, принимающие WM в качестве средства платежа за товары и услуги, предлагаемые в сети Интернет.

3. Перевести свои WM на любой банковский счет банка системы с последующим (автоматическим или по запросу) переводом их в доллары США, российские рубли (или любую другую валюту).

4. Перевести доллары США, российские рубли (другую валюту) в WM с последующим использованием их в расчетах в рамках системы WebMoney Transfer.

WEBMONEY KEEPER является свободно распространяемым программным продуктом, в котором реализованы универсальные решения как для покупателей, так и для продавцов услуг или товаров в Сети.

WEBMONEY KEEPER в виде самораспаковывающегося инсталляционного архива можно бесплатно получить на Web-сервере системы. Если у клиента есть необходимость оплатить товар или услугу, предоставляемую Интернет-магазином (или получить оплату за свои товары или услуги), он может это сделать через систему WebMoney Transfer. Чтобы стать участником системы, достаточно:

• для всех пользователей: скачать и инсталлировать программу WEBMONEY KEEPER;

• для покупателей: перевести денежные средства (например, доллары США, российские рубли) с любого банковского счета банка системы WebMoney Transfer в WM с зачислением последних на спецсчета-кошельки. Реквизиты перевода можно получить с помощью программы WEBMONEY KEEPER (функция Пополнить кошелек).

• для продавцов: открыть (бесплатно) спецсчета-кошельки, в адрес которых будут поступать WM в счет оплаты их товаров и услуг, а также настроить свои Web-магазины на ведение расчетов в WM.

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

Так как WM имеют эквивалентную денежную ценность, то по совершению оплаты магазины, использующие систему WebMoney Transfer, немедленно обеспечивают клиенту доставку товаров или услуг. Система WebMoney Transfer предлагает также решение для превращения Web-сервера в виртуальный магазин. Для этого необходимо установить WEBMONEY KEEPER и настроить его под предлагаемые товары.

Далее рассмотрены некоторые методы обеспечения безопасности, примененные в WebMoney Transfer.

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

Идентификатор генерируется автоматически, уникален для каждой установленной программы WEBMONEY KEEPER. Это анонимное имя клиента в системе. Идентификатор необходим для входа в программу WEBMONEY KEEPER и осуществления сделок в системе WebMoney Transfer.

Пароль определяется лично клиентом и необходим для входа в программу WEBMONEY KEEPER и осуществления сделок в системе WebMoney Transfer.

Внутри каждой установленной программы WEBMONEY KEEPER денежные средства WM хранятся в кошельках.

Кошельки могут поддерживать только один тип валюты. Например:

• Z-кошельки можно пополнить только долларами США. С Z-KO-шелька можно отправить безналичный банковский перевод только в долларах США. На Z-кошельке 1WM=1USD.

• R-кошельки можно пополнить только российскими рублями. С R-кошелька можно отправить безналичный банковский перевод только в российских рублях. На R-кошельке 1WM=1RUR.

Перевод и получение денежных средств осуществляется только между однотипными кошельками клиентов системы.

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

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

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

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

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

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

Всем участникам системы гарантируется анонимность расчетов. При желании пользователь может не указывать никаких сведений о себе (имя, фамилия, адрес, почтовый адрес, номера банковских счетов и т. п.) при получении программы WEBMONEY KEEPER с сервера системы, при ее инсталляции, при осуществлении операций в системе WebMoney Transfer.

Все услуги и поставки товаров осуществляются в «адрес» оплатившего их кошелька. Можно создавать кошельки для разового использования и непосредственно после совершения сделки удалять их. По постоянному идентификационному номеру пользователя невозможно определить номера используемых им кошельков. Аналогично, номер кошелька не несет информации об идентификаторе пользователя. Кроме того, можно инсталлировать на своем компьютере любое число версий WEBMONEY KEEPER под разными идентификаторами и входить в систему для осуществления сделок с любого из них.

В системе реализовано два типа платежей:

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

2. Двухфазный платеж (платеж с протекцией торговой сделки). Магазин определяет товары, по которым возможен двухфазный платеж и сроки их доставки. После чего указанный товар можно оплатить только двухфазным платежом.

Клиент производит оплату товара и определяет (самостоятельно) пароль транзакции. При этом на кошельке покупателя резервируется сумма в размере стоимости товара. Продавец получает уведомление о том, что денежная сумма, эквивалентная стоимости товара, зарезервирована, а также инструкции по доставке. На этом первая фаза платежа завершается.

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

1. Если продавец осуществляет доставку в указанный им срок и качество товара соответствует заявленному в магазине, то покупатель получает товар и сообщает продавцу код транзакции. Продавец производит сверку кода транзакции через программу WEBMONEY KEEPER, после чего денежная сумма с кошелька покупателя переводится в кошелек продавца.

2. Если продавец не осуществляет доставку в указанный им срок, то по истечении срока доставки товара зарезервированная денежная сумма разблокируется и становится доступной для других операций.

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

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

В системе WebMoney Transfer приняты следующие тарифы.

Система не устанавливает никакой платы за использование клиентского программного обеспечения WEBMONEY KEEPER, которое предоставляется бесплатно с WEB-сервера системы.

За совершение каждой транзакции (за исключением операций с кошельками одного идентификатора) с кошелька пользователя взимается тариф в размере 0,8 % от суммы платежа, но не менее 0,01 единицы WM.

За все операции, связанные с движением WM из системы, взимается плата в размере 0,8 % от суммы платежа, но не менее 0,01 единицы WM. Ввод денег в систему производится бесплатно.

Система WebMoney Transfer официально действует (имеет представительства) кроме России в США, в Чехии, на Украине и в Казахстане. Сегодня в системе официально предусмотрен обмен на WM и обратно долларов США, чешских крон, российских рублей, казахских тенге и украинских гривен через обменные пункты на территориях этих стран. Все остальные валюты могут конвертироваться в WM и обратно через шлюз в банке 1MB (Черногория).

Деньги на свой кошелек в системе WebMoney Transfer можно поместить одним из следующих способов:

• обычным банковским переводом;

• почтовым или телеграфным переводом;

• переводом через систему Western Union;

• путем обмена наличных на WM в обменном пункте (в четырех странах);

• через покупку предоплаченной карты;

• через шлюз в черногорийском банке 1MB в любой валюте.

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

• перевести WM со своего кошелька на счет в любом российском или зарубежном банке;

• обменять WM на наличные в одном из обменных пунктов системы;

• переслать на свой домашний адрес почтовым или телеграфным переводом;

• перевести их кому угодно через систему Western Union.

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

Развитие электронных платежных систем в Интернете находится под пристальным вниманием как государственных органов различных стран, так и международных консультационных организаций в области финансов и права. Среди последних — Базельский комитет по банковскому надзору (Basle Committee on Banking Supervision). В разработке документов Базельского комитета принимают участие ведущие 15-2103 специалисты центральных банков стран ЕС. Эти документы имеют статус рекомендаций национальным банкам европейских стран при рассмотрении различных вопросов финансовой деятельности. Существует несколько документов, выпущенных комитетом и содержащих рекомендации по эмиссии, обращению и контролю электронной наличности. К таким документам относятся:

• Risk Management for Electronic Banking and Electronic Money Activities;

• Implications for Central Banks of the Development of Electronic Money;

• Security of Electronic Money.

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

ЦБ РФ также выпустил документы, регулирующие эмиссию и обращение электронной наличности, или как сказано в них, «предоплаченных ЦБ финансовых продуктов, выпущенных в электронной форме». Это указания ЦБ России от 3 июля 1998 г. № 276-У «О порядке выдачи разрешений кредитным организациям-резидентам на распространение платежных карт или предоплаченных финансовых продуктов других эмитентов» и № 211-У «О порядке выдачи регистрационных свидетельств кредитным организациям-резидентам на осуществление эмиссии предоплаченных финансовых продуктов».

В соответствии с этими документами кредитные организации на территории России могут выпускать денежные обязательства (в том числе и в электронной форме) на основании разрешения, выдаваемого ЦБ РФ. Под предоплаченными финансовыми продуктами понимаются «денежные обязательства кредитной организации, заменяющие в процессе их обращения требования юридических и/или физических лиц по оплате товаров и услуг, и в том числе денежные обязательства, составленные в электронной форме».

Некоторые специалисты в области права предлагают рассматривать электронную наличность в России в качестве условной денежной единицы, в которой выражено денежное обязательство эмитента, погашаемое в рублях по первому требованию держателя электронной наличности. Внедрение электронной наличности в этом случае возможно в порядке, предусмотренном договорами между участниками расчетов на основании положения ГК РФ (п. 2 ч. 1 ст. 317). «В денежном обязательстве может быть предусмотрено, что оно подлежит оплате в рублях в сумме, эквивалентной определенной сумме ... в условных денежных единицах ... В этом случае подлежащая уплате в рублях сумма определяется по официальному курсу ... условных денежных единиц на день платежа, если иной курс или иная дата его определения не установлены законом или соглашением сторон». При этом электронная наличность представляет собой денежные обязательства физического или юридического лица, подписанные его электронной цифровой подписью.

Важно отметить, что оба изложенных здесь обоснования использования электронной наличности действуют только в том случае, когда продавец, получив от покупателя электронную наличность, не распоряжается ею далее в качестве платежного средства, а сразу получает в обмен на полученную наличность ее денежное покрытие. Использование электронной наличности в качестве платежного средства продавцом не соответствует действующему в настоящее время российскому законодательству, в соответствии с которым единственным законным платежным средством на территории России является рубль (п. 1 ст. 140 ГК, а также ст. 29 Федерального закона «О Центральном Банке Российской Федерации (Банке России)»).

Понятие предоплаченного финансового продукта используется для обоснования статуса электронной наличности в системе PayCash.

Система WebMoney Transfer для обоснования WM придает последним статус некого объекта права, обладающего определенной ценностью. Выразить эту ценность можно в любой допускаемой законом форме. В одном случае это может быть долговое обязательство на предъявителя, в другом — паевой взнос, в третьем — ценная бумага, наделяющая ее владельца определенными правами.

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

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

15' 2 20 Глава 5. Другие модели построения систем электронной коммерции

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

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

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

После завершения транзакции система Earthport в отложенном режиме пытается произвести расчеты между клиентом и ТП. Если расчет произведен, транзакция считается успешной.

Достоинства технологии очевидны. Фактически сервер Earthport является посредником в расчетах ТП и покупателя. Он удобен в использовании (клиент только однажды предоставляет данные о себе и далее пользуется ими при совершении покупок). Во время покупки производится аутентификация клиента системой, причем данные аутентификации клиенту ТП не известны, а личные данные клиента хранятся в защищенном месте. Это повышает безопасность операций покупки через систему Earthport.

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

Недостаток технологии заключается в замкнутости системы Earthport (ограниченное количество ТП).

Пример другой технологии расчетов без пластиковых карт — российская система EACCESS (). Эта система ориентирована на микроплатежи (до $10) в Интернете, связанные с покупкой нематериальных товаров и услуг.

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

Для реализации описанной схемы EACCESS подписал договор с Ростелекомом. Планируется заключить аналогичные договоры с операторами сотовой связи.

Недостатки указанной системы с точки зрения бизнеса очевидны. Система EACCESS расплачивается с ТП в короткое время после совершения покупки, в то время как сама получает возмещение от покупателя по истечении гораздо большего времени. Кроме того, нет гарантий оплаты счета. Таким образом, EACCESS берет на себя риски, связанные с невозмещением покупателем средств за совершенную им транзакцию.

Содержание раздела