Интероперабельность Web3‑систем: как обеспечить безопасный обмен данными по ГОСТ
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
Email: petukhov@legascom.ru
В госуправлении и финансовой инфраструктуре блокчейн‑системы уже активно применяются - от МЧД до ЦФА. Однако на практике Web3‑автоматизированные системы (Web3‑АС) остаются изолированными: единого стандарта для безопасного обмена данными между ними пока нет. При этом регуляторы (ФСТЭК, ФСБ, Банк России) предъявляют строгие требования к защите информации и средствам криптографической защиты (СКЗИ). Поэтому задача интероперабельности решается не только технологически, но и с учётом нормативных ограничений - в первую очередь через применение ГОСТ‑криптографии.
Почему интеграция Web3‑систем - это не просто «мост» между блокчейнами
Российские Web3‑АС строятся на разных платформах (Ethereum, Hyperledger Fabric, Waves) и используют разные модели консенсуса (CFT, BFT, PoA). Это создаёт несовместимость на уровне доверенной среды, даже если бизнес‑логика систем схожа.
Технологически мосты между блокчейнами возможны - в том числе между PoW‑ и PoS‑сетями. Но в регулируемой среде главным барьером становятся требования к СКЗИ и защите от несанкционированного доступа. Именно они чаще всего тормозят проекты: архитектура распределённых реестров плохо сочетается с классическими моделями контроля доступа. В результате ключевой вопрос - не выбор консенсуса, а корректная реализация криптографической защиты без разрушения логики распределённого доверия.
Архитектуры мостов и ограничения для регулируемых сред
На практике применяют несколько подходов к построению мостов:
Атомарные мосты на Hash‑Time‑Lock‑контрактах - полностью децентрализованы, безопасность строится на криптографии, доверие к участникам не требуется.
Lock‑and‑Mint - актив блокируется в одной сети, в другой выпускается его «обёртка»; обычно управляется единым оркестратором.
Мосты на guardian‑ах и оракулах (например, LayerZero, Wormhole) - используют доверенных валидаторов, лёгкие клиенты и ретрансляторы; степень децентрализации варьируется.
Для российских регулируемых сред Trustless‑модели (без доверенного субъекта) практически неприменимы: регулятор требует наличия ответственного субъекта, реализующего политику безопасности. Поэтому компромиссным вариантом становится мост с оркестратором, который выполняет роль диспетчера доступа - как индикаторного, так и содержательного.
ГОСТ‑криптография как основа доверия
Чтобы мост мог считаться элементом защищённой инфраструктуры и пройти сертификацию (вплоть до класса КС2), он должен опираться на отечественные криптостандарты:
ГОСТ Р 34.10–2012/2018 - для электронной подписи на эллиптических кривых.
ГОСТ Р 28147‑89 / ГОСТ Р 34.13‑2015 - для режимов шифрования.
ГОСТ Р 34.11–2012/2018 - для хэш‑функций.
Их использование совместно с ГОСТ‑TLS и сертифицированными СКЗИ позволяет подтвердить соответствие требованиям регуляторов.
Важный аспект - модель доверия и управление ключами. Если мост - независимый субъект, раскрытие передаваемых данных недопустимо. Поэтому шифрование должно быть встроено в архитектуру, а выработка ключей - децентрализована: доступ к данным должен быть только у легитимных участников. Для выработки сессионных ключей применяется ECDH (протокол Диффи‑Хеллмана на эллиптических кривых) в соответствии с RFC 7836.
Как устроена реализация ГОСТ‑Web3‑моста
С учётом распространённости Ethereum‑подобных платформ в защищённых Web3‑АС была выбрана архитектура моста между Ethereum‑Ethereum или Ethereum‑Hyperledger Fabric. Ключевая идея - разделить сам конфиденциальный документ и доказательство права доступа к нему.
Вместо передачи документа между сетями используется NFT как криптографически верифицируемый индикатор доступа. Сам документ хранится в зашифрованном виде во внешнем (желательно децентрализованном) хранилище - в эксперименте применялся IPFS. Такой подход фиксирует факты и права в неизменяемом реестре, не раскрывая содержимое данных.
Архитектура адаптивна и может связывать любые системы со смарт‑контрактами или их аналогами.
Тестовый стенд и протокол обмена
Тестовый стенд был развёрнут на базе Мастерчейн 2.0 и включал:
две автоматизированные системы (АС‑1 и АС‑2);
смарт‑контракты NFT (wNFT);
оркестратор моста;
хранилище IPFS;
криптопровайдер (в эксперименте - КриптоПро CSP 5.0).
Протокол взаимодействия состоит из четырёх этапов:
Формирование передачи. Отправитель создаёт разрешение на передачу документа получателю, вырабатывает сессионный ключ по ECDH, шифрует документ, загружает его в IPFS и получает CID. Затем подписывается транзакция на выпуск NFT, в метаданных которого фиксируются CID, адрес получателя и идентификатор целевой сети. Смарт‑контракт принимает транзакции, подписанные secp256k1, и внутри проверяет подпись пользователя по ГОСТ 34.10–2012.
Проверка подписи. Оркестратор моста с помощью СКЗИ проверяет подпись отправителя, придавая операции юридическую значимость.
Выпуск зеркального токена. Оркестратор инициирует выпуск Wrapped NFT в АС‑2, владельцем которого становится получатель. При этом оркестратор не имеет доступа к содержимому документов и закрытым ключам пользователей - он лишь синхронизирует события между реестрами.
Получение и расшифровка. Получатель, владея wNFT, извлекает CID, скачивает зашифрованный документ из IPFS и восстанавливает сессионный ключ по ECDH для расшифровки. Все операции выполняются в периметре принимающей платформы.
Безопасность решения обеспечивается комплексно:
Конфиденциальность - сквозное шифрование по ГОСТ до размещения данных в хранилище.
Целостность и аутентичность - аутентифицированное шифрование и проверяемые цифровые подписи всех критических транзакций.
Соответствие требованиям регуляторов - использование сертифицированных алгоритмов и СКЗИ в контуре оркестратора позволяет соответствовать классу КС2.
Ограничения и перспективы
Выявленное ограничение - недетерминированное время выполнения операций: проверка подписей смарт‑контрактами и подтверждение транзакций нодами блокчейна могут занимать разное время. Это технологический вопрос, требующий дальнейшей оптимизации. Ведётся работа по внедрению ГОСТ‑TLS на всех этапах взаимодействия.
Предложенный протокол можно расширять дискреционными и мандатными политиками доступа: оркестратор способен учитывать уровни допуска сторон и гриф документа. Фактически решение выходит за рамки простой интероперабельности и формирует модель защищённого децентрализованного документооборота, позволяющего связать разрозненные системы без создания единой уязвимой точки.
Таким образом, интероперабельность Web3‑систем в регулируемой среде - это не только техническая задача, но и задача соответствия нормативным требованиям. Применение ГОСТ‑криптографии, разделение данных и прав доступа, а также использование оркестратора как контролируемого субъекта позволяют построить безопасный и юридически значимый обмен между Web3‑АС, сохраняя при этом принципы децентрализации и доверия.
