Банк или кошелек?

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

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

Системы «банк-клиент» проецируют в Internet идеологии а) классического банкинга и б) сетевых технологий «(тонкий) клиент-сервер».

Такая система представляет собой совокупность счетов (accounts), хранящихся централизованно и допускающих удаленное управление (обычно через Internet). При классическом подходе каждый из них представляет собой запись, отражающую финансовую ответственность банка перед клиентом. Системы «банк-клиент» построены на счетах банков  [1], с которыми иногда можно оперировать только в онлайне, а иногда и традиционными способами.

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

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

• получить от покупателя описание операции;

• проверить допустимость операции;

• возможно, получить от продавца согласие на проведение операции;

• сгенерировать транзакции по взиманию комиссии;

• изменить пару записей;

• разослать сторонам отчеты-квитанции;

• сохранить отчет у себя.

Уже из этого короткого описания ясно, что универсального подхода к алгоритму платежей быть не может  [2].

В результате некоторые системы «банк-клиент» становятся узкоспециализированными, а стремящиеся к универсальности - предоставляют мощное ядро, которое можно обвешивать произвольными функциями.

Любая система «банк-клиент» должна определять права клиента на пользование счетом. Офлайновый аналог производимой при этом идентификации - предъявление паспорта. Роль паспорта в Internet может играть некая секретная информация:

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

Главный недостаток этого метода очевиден: ключ многократно передается по Internet, и в случае его перехвата злоумышленник получает все права на операции со счетом. Простейшей модификацией является ситуация, когда банк не спрашивает ключ, а передает некий случайный текст. Покупатель шифрует этот текст своим ключом и отправляет банку. Банк расшифровывает текст этим же ключом и в случае совпадения с исходным убеждается, что покупатель знает ключ. Естественно, эти операции покупатель делает не лично, а при помощи некой программы-клиента («электронного бумажника»  [3]).

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

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

Принципиальной проблемой одноразовых и многоразовых симметричных ключей является недоказуемость операций.  [4] Возможное решение - использовать алгоритмы с разделяемыми секретами (ключами).

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

Тонких различий между отдельными системами много, но мы сосредоточимся на рассмотрении общих проблем.  [6]

1. Основной качественной проблемой систем «банк-клиент» является трассировка платежей. Подробная информация обо всех платежах хранится в банке и может быть востребована для любой цели, причем не только в интересах клиента, но и в интересах третьих лиц  [7]. Анонимные или псевдонимные (номерные) счета лишь отчасти решают задачу: все платежи со счета являются связанными, и если удастся персонифицировать один платеж, тем самым «засвечиваются» и другие.

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

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

4. Основной же проблемой является:

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

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

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

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

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

При каждом платеже продавец должен запрашивать «банк», нет ли предъявленной ему монеты в списке «использованных», а число «использованных» обязательств в таком листе стремительно растет со временем и неизбежно переполняет базу данных  [9].

Обычно такая ситуация вызывает вопрос: если каждый платеж проходит через банк, то в чем, собственно, разница?

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

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

Если, как мы уже говорили, «банк-клиент» является проекцией на Internet идеологии «клиент-сервер», причем с тонким клиентом (рис. 1), то цифроналичная платежная система - это пиринговая (peer-to-peer) сеть с (относительно тонким) справочным (lookup) сервером (рис. 2).

Преимущество последней на «хороших» задачах состоит в медленном (линейном) росте критической нагрузки с ростом объема вычислений  [10], в то время как для клиент-серверной архитектуры нагрузка на сервер может расти от квадрата до экспоненты объема вычислений.

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

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

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

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

Автор признателен Ильдару Хамитову за обсуждение статьи и замечания.

[i36938]