РЕПИН М.М., преподаватель, Московский политехнический университет, направление «Информационная безопасность», bmstu.iu8@gmail.com

 ПШЕХОТСКАЯ Е.А., к.ф.н., доцент факультета информатики и систем управления, руководитель образовательной программы «Безопасность перспективных информационных систем», Московский политехнический университет, e-mail: pshehotskaya@gmail.com

 ПРОСТОВ И.А., студент, Московский политехнический университет, направление «Информационная безопасность автоматизированных систем», igorprostoff@gmail.com

 АМФИТЕАТРОВА С.С., студентка, Московский политехнический университет, направление «Информационная безопасность автоматизированных систем», piacanlie@gmail.com

Использование платформы
на основе распределенных реестров Ripple в банковских платежных системах

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

Введение

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

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

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

Платформа построена вокруг основанного на доверии механизма консенсуса [1], который позволяет совершать через нее переводы любых финансовых активов. Однако платформа не может гарантировать исполнения транзакции; она может только исполнять смарт-контракты, подвергая перевод рискам контрагента. Чтобы решить эту дилемму, компанией Ripple был создан собственный токен XRP, который предоставляет полную гарантию расчета в течение нескольких секунд.

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

1. Описание Ripple с точки зрения банковских платежных систем

Компания Ripple разработала систему межбанковских и международных платежей – RippleNet. С точки зрения самой Ripple эта система является универсальной системой распределенных реестров для использования в качестве системы межбанковских денежных переводов. В ее составе функционируют несколько «ветвей» [2]. Рассмотрим их подробнее.

xCurrent

xCurrent – это наиболее известный продукт компании Ripple, состоящий из решения для проведения расчетов для банков и других финансовых учреждений. Например, если Банк А хочет заплатить Банку B в долларах США, а Банк B хочет получить оплату в евро, сеть автоматически найдет наиболее ликвидный маршрут для каждой стороны для выплаты средств в соответствующих валютах. Расчеты в xCurrent осуществляются через полностью независимый протокол Interledger (ILP), который использует смарт-контракты для облегчения проведения ненадежных платежей в системе [3].

ILP изначально является ненадежным и работает по принципу условного депозита, аналогично с протоколом Lightning Network, применяемым в платежной системе Bitcoin. После установления маршрута стороны депонируют актив, представляющий интерес, их корреспонденту, помещая его на условный депозитный счет. Это приводит к цепной реакции, когда корреспондент депонирует на депозитный счет последующего корреспондента. Эта цепочка продолжается до тех пор, пока средства не дойдут до конечного получателя (см. рис. 1).

Рисунок 1. Депонирование активов между корреспондентами

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

Рисунок 2. Возврат депонированных активов после подписания квитанции

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

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

xRapid

xRapid – новый технологический уровень, внедренный в сеть xCurrent. Он позволяет отправляющей и принимающей сторонам использовать токен XRP (созданный Ripple в качестве «платежного моста») для совершения платежей. Вместо того, чтобы искать каналы ликвидности через многочисленных поставщиков корреспондентских платежей, вызывая многочисленные транзакционные издержки, участники могут обойтись без посредника и передать средства друг другу напрямую. Транзакции xRapid проводятся по новому алгоритму консенсуса протокола Ripple.

Банки либо хранят резервы XRP на своих балансах, либо выделяют линии ликвидности через слой xRapid. Банки отправителя конвертируют фиатную валюту в XRP, передают его по среде Ripple в банк получателя, который конвертирует токен XRP обратно в фиатную валюту через своего поставщика ликвидности [5]. Этот процесс занимает несколько секунд, что позволяет сократить количество комиссионных сборов и конверсий, связанных с xCurrent.

xVia

xVia – стандартный интерфейс для платежей, проводимых на платформах X-series. Данный интерфейс предоставляет удобный интуитивный интерфейс для инициирования транзакций, проводимых через сети xCurrent или xRapid, в реальном времени. xVia по-прежнему находится в стадии разработки, и подробности об основах технической архитектуры не распространяются.

Все вышеописанные механизмы работают согласно собственному алгоритму Ripple – RCPA (Ripple Consensus Protocol Algorithm). Приведем краткое описание данного алгоритма.

Алгоритм, используемый в системе RippleNet, состоит из нескольких компонент:

1. Непосредственно участники обмена, которые производят между собой обмен активами.
2. Валидаторы – особые доверенные узлы, которым доверяет большинство участников сети.
3. Механизм консенсуса. Алгоритм, который проводит взаиморасчеты и вносит изменения в общую базу транзакций. Механизм консенсуса и взаиморасчетов запускается с некоторым промежутком, он позволяет осуществлять проводки, выборку вариантов и обмен, обрабатывая за один запуск все открытые на текущий момент транзакции.
4. Криптовалюта сети XRP. Эта валюта служит своеобразным посредником, который позволяет провести унифицированный обмен, даже если не найден способ прямого обмена между двумя участниками или валютами.
5. Шлюзы (Gates). Внешние шлюзы, которые используются для обмена внутренних активов в любые другие виды валют. Часто гейтами выступают банки, которые производят перевод внутреннего обмена в бумажные деньги.

В настоящее время RippleNet требует двух обязательных особых участников для обеспечения возможности транзакций:

• во-первых, финансовое учреждение, которое «держит деньги и выдает остатки по поручению клиентов»;
• во-вторых, «маркет-мейкер» (например, хедж-фонд или валютная торговая площадка), предоставляющий ликвидность для соответствующего актива.

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

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

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

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

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

2. Обзор типовых уязвимостей RippleNet

Атака Сивиллы

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

Модели взаимодействия, построенные на основе криптологической задачи византийских соглашений, такие как RippleNet, обычно исправно работают в условиях, когда число «предателей» меньше N, например, (N–1)/3, где N – число узлов.

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

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

Атака предвычислением

Рассмотрим одно из описаний данной атаки [4].

Пусть A майнер некоторого блока B(h) высоты h. То есть A удовлетворяет условию:

hash(hash(B_prev),A,t)≤bal(A)M/D (1)

с параметрами, соответствующими B(h), где B_prev – блок, над которым работает майнер.

Если A обладает существенной вычислительной мощностью, он может повлиять на хеш блока B(h), чтобы иметь возможность решить следующий блок B(h+1), например, добавляя новую транзакцию в B(h).

Чтобы зарезервировать B(h+1) для себя, A просматривает все профили пользователей и проверяет, выполняется ли условие (1) для каждого из разрешенных значений времени t.

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

Эффективность атаки предвычислением зависит от доли злоумышленника, а также от общего числа пользователей или UTXO (Unspent Transaction Output – неизрасходованные транзакции выходов) в системе.

В системе, применяющей алгоритм консенсуса PoW, эта атака является фактически невозможной, так как сгенерировать блок с «хорошим» хешем намного сложнее, чем просто корректный блок. Аналогично в системе с делегированным PoS¹ последовательность лиц, подписывающих блоки, не зависит от свойств самого последнего блока [3]. Таким образом, алгоритм консенсуса DPoS (Delegated proof-of-stake) является устойчивым к предвычислительным атакам.

Риски, связанные с поиском узлов

У обычного человека мало рациональных стимулов для запуска проверяющего узла XRP. Работа с полным узлом – единственный способ гарантировать полную безопасность и конфиденциальность в сети. Наличие полной последовательности истории транзакций – это единственный способ обеспечить подлинную компиляцию владения UTXO, используя SPV²-клиента, просто перенося эту задачу на кого-то другого. Использование узла в Ripple по своей сути не гарантирует тот же уровень независимости, поскольку меньшинство внутри списка доверенных узлов (unique node list – UNL) может быть отвергнуто большинством «плохих» узлов.

Кроме того, если отдельный узел не имеет достаточного уровня доверия с другими узлами, весьма сомнительно, что одноранговые серверы включили бы этот узел в свой UNL. Таким образом, добавление большего количества узлов не обязательно способствует повышению устойчивости сети Ripple. Системе нужны корпоративные/институциональные партнеры для управления серверами, чтобы люди чувствовали себя уверенно, доверяя этим узлам.

Тем не менее можно утверждать, что крупные финансовые учреждения будут заинтересованы в том, чтобы не запускать узел проверки XRP в рамках полностью распределенной модели протокола консенсуса алгоритма Ripple (Ripple Consensus Protocol Algorithm – RCPA) из-за возможных юридических проблем.

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

Работа с проверяющим сервером XRP означает работу в системе, которая не имеет прав и заполнена неизвестными участниками. Учитывая жесткие требования банков и финансовых учреждений, таких как know your customer³ (KYC) и Anti-Money laundering (AML), маловероятно, что многие захотят участвовать в этом процессе, учитывая риск незнания личности других участников экосистемы.

Это создает проблему для сети XRP. Таким образом, модель консенсуса по своей сути опирается на доверие между участниками UNL. Трудно накопить доверие при работе с анонимными серверами. Большинство людей по умолчанию выберут Ripple Corp UNL – набор проверяющих узлов, контролируемых Ripple, из-за этих вышеописанных рисков.

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

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

3. Потенциальные решения обнаруженных угроз

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

• введение аутентификации пользователя, который желает сделать свой узел частью сети RippleNet, путем обращения самого пользователя в Ripple с соответствующей просьбой;
• исключение использования какой-либо единицы измерения доверия. Узлы должны взаимодействовать в среде, где все другие узлы по умолчанию считаются ненадежными;
• в процессе выбора транзакции для подтверждения параметр Proof of Work должен рассчитываться для каждой транзакции в отдельности;
• транзакции должны иметь суммирующуюся сложность цели. Так же как и запись в целом, транзакции добавляются в базу транзакций, когда их цель достигнута, и база транзакций закрывается для записи, когда достигается общая цель;
• правилом выбора цепочки является выбор цепочки с наибольшим количеством вычислений (или наибольшей сложностью);
• сложность настраивается исходя из активности в сети;
• при возможности необходимо установить вознаграждение за голосование за «лидера», чтобы стимулировать участие в голосовании.

Заключение

В статье рассмотрены основные возможности системы RippleNet, а также актуальные риски при использовании данной системы в банковских платежных системах.

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

1. David Schwartz, Noah Youngs, Arthur Britto. The Ripple Protocol Consensus Algorithm, Ripple Labs Inc, 2014.
2. Joe Kendzicky, Ripple (XRP) Analysis. [Электронный ресурс] – Режим доступа: URL: https://medium.com/@jkendzicky16/ripple-xrp-analysis-cc4f440d0604.
3. Баринова А.А., Запечников С.В. Методы и средства обеспечения конфиденциальности смарт-контрактов. // Безопасность информационных технологий. – 2017. – Т. 24. – № 2. – С. 16-23.
4. Колесников П., Бекетова Ю., Крылов Г. Технология блокчейн. Анализ атак, стратегии защиты, Lambert Academic Publishing RU, 2017.
5. Минко В. Одноранговые сети. Обратная сторона пиринговых сетей – сложность обеспечения безопасности. [Электронный ресурс] – Режим доступа: URL: https://www.osp.ru/lan/2015/04/13045700/.
6. Pedro Moreno-Sanchez, Navin Modi, Raghuvir Songhela, Aniket Kate, Sonia Fahmy. Mind Your Credit: Assessing the Health of the Ripple Credit Network. Purdue University, 2018.
7. Rizzo, P. Fidor Becomes First Bank to Use Ripple Payment Protocol. [Электронный ресурс] – Режим доступа: URL: http://www.coindesk.com/fidor-becomes-first-bank-to-use-ripple-paymentprotocol/.

Ключевые слова: платформа на основе распределенных реестров, безопасность банковских платежных систем, Ripple.

1 Proof-of-stake – метод защиты криптовалюты с помощью запрашивания у пользователей показать собственность определенной суммы валюты.

2 Simplified Payment Verification – упрощенная проверка платежей.

3 Know your customer – термин банковского и биржевого регулирования для финансовых институтов и букмекерских контор, означающий, что они должны идентифицировать и установить личность контрагента, прежде чем проводить финансовую операцию.

Using of Ripple distributed registry system in bank payment systems

Repin M.M., Department of Information Security, Moscow Polytechnic University, Moscow, Russia, bmstu.iu8@gmail.com

Pshehotskaya E.A., Department of Information Security, Moscow Polytechnic University, Moscow, Russia, pshehotskaya@gmail.com

Prostov I.A., student, Moscow Polytechnic University, direction “Information security of automated systems», igorprostoff@gmail.com

Amfiteatrova S.S., студент, student, Moscow Polytechnic University, direction «Information security of automated systems», piacanlie@gmail.com

Abstract: This article describes a system of distributed registries Ripple and its use in banking payment systems. The structure of the system, its working algorithms are considered, the main components of Ripple are described. The typical threats to distributed registry systems most applicable to Ripple are analyzed and potential solutions are presented. Based on the research conducted, it was concluded that Ripple could be used in the banking sector.

Keywords: distributed registry systems, security of banking payment systems, Ripple.

Комментарии могут оставлять только зарегистрированные пользователи