Журнал "Information Security/ Информационная безопасность" #6, 2025

(34.10–2018) для электронной подписи на эллиптических кривых, ГОСТ Р 28147- 89 (ГОСТ Р 34.13-2015) для режимов шифрования и ГОСТ Р 34.11–2012 (34.11–2018) для хэш-функций. Поддержка этих стандартов с исполь- зованием сертифицированных крипто- провайдеров в виде СКЗИ, в сочетании с ГОСТ-TLS, позволяет пройти серти- фикацию и оценку влияния по высокому классу – КС2. Без этого мост остается лишь технологическим экспериментом, но не элементом защищенной инфра- структуры. Отдельный аспект – модель доверия. Если мост не находится на стороне регу- лятора и выступает независимым субъ- ектом, функция содержательного дис- петчера доступа, предполагающая рас- крытие передаваемых данных, стано- вится неприемлемой для участников. Значит, шифрование должно быть встроено в базовую архитектуру моста. При этом важно избежать наличия еди- ной точки выработки ключей шифрова- ния. Оптимальный вариант – децентра- лизованное шифрование, при котором доступ к данным возможен только у леги- тимных участников обмена. Поскольку юридически значимая под- пись в таких системах возможна только на эллиптических кривых согласно ГОСТ, выработка сессионных ключей также должна осуществляться через ECDH (протокол Диффи-Хеллмана на эллиптических кривых). Для отечествен- ных алгоритмов этот механизм описан в RFC 7836 (выработан под руководством специалистов компании "КриптоПро"). В криптопровайдерах он обычно встре- чается как CALG_DH_GR3410_EL. ГОСТ-Web3-мост: от идеи к реализации С учетом распространенности Ethereum-подобных платформ в защи- щенных Web3-АС и возможности исполь- зовать тестовые лицензии СКЗИ было принято решение спроектировать мост между двумя автоматизированными системами: либо Ethereum-Ethereum, либо Ethereum-Hyperledger Fabric (HLF). Допол- нительные консультации с действующими ОИС показали важный нюанс: алгоритм разрешительной подписи на совершение операции может отличаться от алгоритма подписи транзакции внутри блокчейна. Это потребовало внедрения вспомога- тельного слоя Account Abstraction (ERC- 4337) для Ethereum и аналогичного Chain- code для HLF, обеспечивающего проверку юридически значимой подписи, выпол- ненной по ГОСТ. Ключевая архитектурная идея моста – разделение конфиденциального доку- мента и доказательства права доступа к нему. Вместо передачи самого документа между сетями используется NFT, выпол- няющий роль криптографически вери- фицируемого индикатора доступа. Сам документ хранится в зашифрованном виде во внешнем файловом хранилище, предпочтительно децентрализованном (в эксперименте – IPFS). Такой подход позволяет фиксировать факты и права в неизменяемом реестре, не раскрывая содержимого данных, что соответствует как принципам Web3, так и требованиям к защите информации. Архитектура остается адаптивной: мост может связывать любые системы со смарт-контрактами или их аналогами. Тестовый стенд был развернут на базе Мастерчейн 2.0. В его состав вошли две АС (АС-1 и АС-2), смарт-контракты NFT (wNFT), оркестратор моста и хра- нилище IPFS. В оркестраторе использо- вался криптопровайдер КриптоПро CSP 5.0. Взаимодействие компонентов опи- сывается детерминированным протоко- лом из четырех этапов. 1. На первом этапе отправитель фор- мирует разрешение на передачу доку- мента конкретному получателю и выра- батывает сессионный ключ по ECDH (RFC 7836). Документ шифруется, загружается в IPFS и получает CID, после чего подпи- сывается транзакция на выпуск NFT. Далее смарт-контракт формирует NFT, в метаданных которого фиксируются CID, адрес получателя и идентификатор целе- вой сети. В тестовой реализации контракт принимает транзакции, подписанные secp256k1, а внутри проверяет подпись пользователя по ГОСТ 34.10–2012. 2. После выпуска NFT оркестратор моста, используя СКЗИ, проверяет под- пись отправителя, придавая операции юридическую значимость. 3. Затем он инициирует выпуск зер- кального токена в АС-2 – Wrapped NFT, владельцем которого становится полу- чатель. Оркестратор при этом не имеет доступа ни к содержимому документов, ни к закрытым ключам пользователей, выступая исключительно как синхрони- затор событий между реестрами. 4. На финальном этапе получатель, владея wNFT, извлекает CID, получает зашифрованный документ из IPFS и вос- станавливает сессионный ключ по ECDH для расшифровки. Все операции выпол- няются в периметре принимающей плат- формы. Безопасность решения обеспечивает- ся комплексно. Конфиденциальность достигается за счет сквозного шифро- вания по ГОСТ до размещения данных в хранилище. Целостность и аутентич- ность гарантируются как аутентифици- рованным шифрованием, так и прове- ряемыми цифровыми подписями всех критических транзакций. Использование сертифицированных алгоритмов и штат- ное применение СКЗИ в контуре орке- стратора позволяют говорить о соответ- ствии требованиям КС2. К выявленным ограничениям относит- ся недетерминированное время выпол- нения – как при проверке подписи смарт- контрактами, так и при подтверждении транзакций нодами блокчейна. Это тех- нологический вопрос, требующий даль- нейшей оптимизации. Ведутся работы по внедрению ГОСТ-TLS на всех этапах взаимодействия. Предложенный протокол легко рас- ширяется дискреционными и мандатны- ми политиками доступа: оркестратор может учитывать уровни допуска сторон и гриф документа. Фактически решение выходит за рамки интероперабельности и формирует модель защищенного децентрализованного документооборота, позволяющего связать разрозненные системы без создания единой уязвимой точки. Кодовая база проекта и материа- лы по его развитию доступны на сайте веб3-мост.рф . l • 59 КРИПТОГРАФИЯ www.itsec.ru Рис. 2. Принципиальная схема разрабатываемого моста Ваше мнение и вопросы присылайте по адресу is@groteck.ru