UDC: обзор безопасности


🇬🇧 / 🇷🇺

UDC – это «коробочное» решение для развёртывания централизованно управляемой платёжной системы на базе блокчейна (в т.ч. CBDC, Central Bank Digital Currency), отражающей в виде цифровой валюты/токена (пригодных для использования в смарт-контрактах) активы и валюты реального мира. Внутри себя оно базируется на технологиях Universa Blockchain; в связи с этим ниже рассматриваются как аспекты безопасности, обеспечиваемые на уровне Universa Blockchain, так и аспекты безопасности, специфичные именно для решения UDC.

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

В целом же применение блокчейна (и применение блокчейна конкретно этого типа) дает следующие преимущества в области стойкости ко взлому:

Типичные блокчейн-атаки, от которых защищает UDC

В UDC невозможно «расщепить» сеть

Шаблонная архитектура блокчейнов подразумевает, что несогласованность на разных узлах в какой-то момент времени самых последних данных, зарегистрированных в сети — это рядовая ситуация. Часть узлов считают какой-то блок данных/транзакцию верными, но если положиться на них, что эти данные верны (например, какой-то перевод успешно прошёл), то можно сделать фатальную ошибку, в случае, если на других узлах есть противоречащий этому блок данных/транзакция, который в итоге и будет принят консенсусом. В связи с этим приходится эмпирически (или статистически) полагаться, что при достаточном количестве блоков («подтверждений») после проверяемого блока вероятность «отмены» этого блока уже достаточно низкая — хотя строгих цифр, после какого количества блоков можно гарантировать неизменность блокчейна, обычно нет. Такая согласованность обычно называется «согласованность в конечном счёте» (eventual consistency).

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

В отличие от классических блокчейнов, блокчейн Universa обеспечивает «моментальную согласованность» (immediate consistency) – поэтому все связанные с «отменой транзакций» или «недостаточным количеством подтверждений» атаки просто исчезают: в блокчейне Universa нет понятия «количество подтверждающих блоков», и самопроизвольная отмена регистрации, когда-то консенсусно посчитавшейся «корректной», невозможна. Если транзакция зарегистрирована, то она зарегистрирована.

В UDC невозможно подделать историю операций

Как и с любым блокчейном, для успеха подобной атаки необходимо подделать историю операций на большинстве узлов сети. Типичным для «классических блокчейнов» является правило «50% + 1 узла» (столько узлов должны быть захвачены для успешного захвата консенсуса и подделки данных); в сети Universa Blockchain для атаки требуется «90% узлов», что существенно усложняет атаку. Нарастив сеть до любого желаемого размера, можно получить масштабируемую стойкость к такого рода атакам.

Для снижения рисков массового взлома нескольких узлов сразу с помощью 0-day уязвимостей, можно устанавливать узлы проприетарной сети на разных площадках и использовать разные версии ОС/ПО для них. В таком случае, даже если для какой-то из операционных систем находится 0-day уязвимость (напр. в случае нахождения очередной массовой уязвимости Windows), ноды на других ядрах и ОС не позволят получить доступ к ним и подделать блокчейн.

В UDC невозможно подделать сделать фальшивую эмиссию

... поскольку для этого пришлось бы подделать всю историю токена.

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

Для большей безопасности выполнения операций владельцами ключей системы (supervisory board) можно использовать мультиключ большого ранга. Например, для новой эмиссии может требовать «70 подписей из 100», или даже «две тысячи из трёх тысяч». В Universa нет искусственных ограничений на количество использующихся ключей (таких, например, как в системах, использующих кодовую базу Bitcoin и позволяющих только 3 ключа при P2MS-схеме или до 15 ключей при P2SH-схеме мультиключа). Использование таких мультиключей хорошо защищает от их хищения, а сделать эмиссию без соответствуюшей подписи невозможно: её не примет блокчейн. Подробности защиты эмиссии: Issuing DC.

Интересной особенностью системы является возможность изменять ключи, необходимые для эмиссии, уже после эмиссии, что обеспечивает возможность сохранять защиту эмиссии, обновляя эти ключи со временем. При этом уже выпущенные токены останутся столь же защищенными, как и новые, так как структура смарт-контрактов системы позволяет кворуму supervisory board менять также и свои ключи, отменяя старые и вводя новые (без изменений в выпущенных токенах). Это обеспечивает поддержку и повышение уровня защиты в будущем без нужды обмена выпущенных ранее «электронных купюр» — даже обновление сетевого ПО и добавление новых ещё более надёжных алгоритмов для ключей эмиссии не потребует никаких действий со старыми использующимися «электронными купюрами» (смарт-контрактами) до тех пор, пока они не будут выведены из обращения естественным путём.

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

В UDC невозможно провести незаконную операцию

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

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

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

Использование криптографических алгоритмов и ключей повышенной стойкости

Для асимметричного шифрования и цифровых подписей система использует ключи повышенной стойкости (проверенный временем алгоритм RSA, в котором за 43 года после публикации не было найдено криптографических уязвимостей; ключи длиной от 4096 бит, с возможным, в случае надобности, повышением до 8192 бит), что обеспечивает отличную стойкость на протяжении многих лет. В случае надобности и для совместимости с другими программно-аппаратными системами, возможно прозрачное расширение для поддержки других алгоритмов (в т.ч. алгоритмов, основанных на эллиптических кривых).

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

В блокчейн-системах чрезвычайно важным является выбор основного алгоритма криптографической хэш-функции, используемой для снятия «отпечатка» с данных и блоков с информацией (а в случае с Universa – для уникальной идентификации смарт-контрактов и их ревизий). Для снижения рисков того, что в такие алгоритмы могли быть заложены уязвимости на этапе разработки хэш-функции, в Universa/UDC используется уникальная схема использования хэш-функций – комбинация из трёх публично доступных, проверенных и стандартных хэш-функций SHA2-512/256, SHA3-256 и «Стрибог»:

  • SHA-512/256 – это вариант алгоритма семейства SHA-2, обладающий наибольшей практической безопасностью для 256-битных вариантов этого семейства. Изначально создан Национальным Агентством Безопасности США (NSA), стандартизирован как:
    • FIPS PUB 180-2, FIPS PUB 180-3, FIPS PUB 180-4 – государственный стандарт США с августа 2002;
    • CRYPTREC – государственный стандарт Японии;
    • NESSIE – стандарт Евросоюза.
  • SHA3-256 – 256-битный вариант алгоритма SHA-3. Изначально создан командой европейских специалистов по криптографии для конкурса NIST hash function competition (2007). Стандартизирован как:
    • FIPS PU B202 – самый новый государственный стандарт США с августа 2015.
  • «Стрибог» – 256-битная хэш-функция, разработанная ФСБ России с участием ОАО «ИнфоТеКС». Стандартизирована как:
    • ГОСТ Р 34.11-2012 – актуальный стандарт РФ с августа 2012.

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

Защита от бекдоров

Поскольку система построена на базе смарт-контрактов в блокчейне, любой бекдор должен быть описан в самих контрактах. Например, если в контракте не предусмотрена возможность выпустить дополнительный токен без мультиключа supervisory board, то никакого способа обойти такое – нет. Даже если злоумышленник получит доступ ко всем данным блокчейна, без этих ключей он будет бессилен что-то изменить.

Смарт-контракты имеют открытую декларативную структуру (это не программный код на каком-то языке программирования) и могут быть аудированы независимо. Поскольку сами смарт-контракты имеют небольшой объем, в них очень сложно, практически невозможно спрятать бекдор. Любой же бекдор в серверном и клиентском программном обеспечении не сможет никак обойти ограничения, установленные в смарт-контракте. Отсутствие бекдоров в ПО узлов блокчейн-сети (равно как и невозможность выполнения операций со смарт-контрактом за пределами разрешённых в определении смарт-контракта) может быть проверено с помощью аудита их кода — исходный код узлов Universa Blockchain публично доступен на Github.

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

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

Разработчики не имеют доступа к ключам управления системой

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

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

Таким образом, безопасность системы сводится к безопасности хранения её ключей (или паролей к ним), в частности, к охране доступа к ключам CFO и supervisory board, что выходит за границы ответственности собственно программного комплекса UDC и уже относится к задаче его безопасной установки, обслуживания и соблюдения регламента эксплуатации (например, не следует писать пароль на кредитной карте или стикере в углу экрана).

Пример парирования взлома

Представим себе самый потенциально деструктивный сценарий: злоумышленником является CFO, либо он позволил скомпрометировать свой ключ несоблюдением процедур безопасности. Например, у него над столом висит китайская камера безопасности, а зашифрованный ключ у него лежит на компьютере под Windows (хотя на практике уже последнего достаточно для взлома даже без камеры, так как Windows бóльшую часть времени позволяет злоумышленникам иметь полный доступ к системе через сеть).

Как только аномалия обнаружена, и CFO попал под подозрение, supervisory board может отменить его ключ, подписав соответствующий контракт, по сути, об увольнении (о снятии с его ключа прав на проведение операций роли CFO). С этого момента его ключ больше не может быть использован ни для одной такой операции. Через какое-то время назначается новый CFO, который, используя историю хранимых в блокчейне операций, может полностью откатить назад незаконные транзакции.

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