Сервис шифрования данных: критерии выбора для Web3-проектов

В Web3 шифрование редко ломается на уровне самого алгоритма. Обычно проблема находится выше: закрытый ключ генерируется в одном сервисе, хранится в одной базе, используется одновременно для подписи и расшифровки, а контроль доступа реализован набором серверных флагов. В такой архитектуре AES, эллиптическая криптография и zk-SNARKs могут быть математически корректными. Это не спасает систему от единой точки отказа.

Для dApp сервис шифрования данных — не просто API, которое принимает plaintext и возвращает ciphertext. Это архитектура генерации ключей, распределения полномочий, проверки условий доступа и восстановления после компрометации. Если сервис не объясняет, где создаётся ключ, кто может собрать его части, как отзывается разрешение и что произойдёт при падении нескольких узлов, перед нами не криптографическая инфраструктура, а обёртка над доверенным сервером.

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

Почему EIP-1024 не стал рабочим стандартом Ethereum

Идея встроенного асимметричного шифрования для Ethereum выглядит логично: кошелёк публикует открытый ключ, отправитель шифрует сообщение, получатель расшифровывает его своим секретом. На практике такая схема упирается в архитектуру существующих кошельков и в наследие secp256k1.

EIP-1024 предполагал методы eth_getEncryptionPublicKey и eth_decrypt. Концепция не была утверждена в Ethereum из-за проблем со стандартизацией и риска использовать один секрет одновременно для подписи транзакций и шифрования. Это не косметический дефект API. Подпись и шифрование решают разные задачи, а повторное использование одного ключевого материала увеличивает область последствий при компрометации.

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

Есть и более низкоуровневые проблемы:

• ключи Ethereum-аккаунтов исторически ассоциированы с secp256k1 и схемой ECDSA, тогда как шифрование требует отдельного, согласованного механизма преобразования ключей;
• кошелёк должен одинаково реализовывать генерацию, публикацию и использование encryption key;
• dApp необходимо понимать, действительно ли открытый ключ относится к тому же субъекту, который подписал сообщение;
• ротация ключа шифрования не должна ломать идентичность кошелька и историю подписей;
• восстановление аккаунта не должно автоматически означать восстановление всех прежних секретов.

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

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

Поэтому EIP-1024 нельзя рассматривать как общепринятый стандарт сквозного шифрования для Ethereum. В экосистеме нет единого встроенного механизма E2EE, который одинаково поддерживали бы все Web3-кошельки, хранилища и dApp. Проекту приходится выбирать внешний протокол или собственную связку примитивов. Второй вариант почти всегда означает рост аудиторского долга.

Пороговое шифрование убирает главный SPOF

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

Пороговое шифрование меняет модель доверия. Вместо полного закрытого ключа система распределяет ключевой материал между несколькими независимыми узлами. Для операции требуется порог t из общего числа n участников. Например, в схеме 3-of-5 три узла должны участвовать в расшифровке, тогда как один или два скомпрометированных узла не получают возможности восстановить секрет самостоятельно.

Ключевой этап здесь — Distributed Key Generation, DKG. Узлы совместно генерируют ключ, не создавая его полную версию в одном месте. Каждый участник получает долю. Публичный ключ может использоваться для шифрования данных, но расшифровка требует взаимодействия узлов и проверки политики доступа.

В корректной реализации это даёт несколько свойств:

1. Отсутствие единой точки отказа. Компрометация одного узла не раскрывает полный закрытый ключ.

2. Распределение доверия. Администратор одного сервера не получает абсолютный контроль над данными.

3. Контроль порога. Политика 2-of-3, 3-of-5 или другая конфигурация задаёт баланс между устойчивостью к отказам и требованием к доступности.

4. Разделение ролей. Узлы могут находиться у разных операторов, в разных зонах отказа и под разными административными доменами.

5. Возможность аудита. Логи запросов расшифровки и состав участников можно анализировать отдельно от приложения.

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

Что сравнивать при выборе архитектуры

Таблица показывает неприятный, но полезный факт: пороговое шифрование увеличивает архитектурный overhead. Появляются сетевые раунды, координация, обработка частичных ответов, таймауты и сценарии восстановления. Но этот overhead платит за снижение доверия к одному серверу. В системах с чувствительными документами, приватными транзакциями и автоматизированным token gating это обычно оправданный обмен.

Главная ошибка — выбирать порог t-of-n как маркетинговую характеристику. Схема 3-of-5 не становится безопасной автоматически. Нужно знать:

• как проходит DKG и может ли оператор подменить параметры;
• что происходит при недоступности двух узлов;
• есть ли защита от сговора участников;
• как меняется состав узлов и выполняется resharing;
• как отзываются скомпрометированные доли;
• каким образом связывается запрос расшифровки с конкретным пользователем или wallet address;
• фиксируется ли событие расшифровки в аудируемом журнале;
• какие данные видят узлы во время выполнения операции.

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

Где здесь Lit Protocol и token gating

Lit Protocol использует пороговую криптографию и позволяет строить управление доступом на основе блокчейн-условий. Данные можно хранить в публичных децентрализованных системах вроде IPFS или Arweave, а право на расшифровку связывать с состоянием сети: владением токеном, NFT, ролью, подписью, membership-признаком или другим условием.

Это практичнее, чем пытаться сделать IPFS приватным хранилищем. IPFS отвечает за адресуемость и распространение контента, но не за разграничение доступа. Если plaintext попал в публичный контент-адрес, криптография уже не поможет. Правильная последовательность выглядит иначе: данные шифруются до публикации, в сеть отправляется ciphertext, а расшифровка выдаётся только после проверки политики.

Условие token gating в такой модели — не сам механизм шифрования. Это политика авторизации. Пороговая сеть должна убедиться, что запрос соответствует условию, и только затем участвовать в выдаче результата. Следовательно, аудит нужно проводить по двум независимым направлениям:

• криптографический слой: генерация ключей, threshold protocol, аутентификация участников, защита от replay и корректность расшифровки;
• слой политик: проверка владения активом, актуальность блокчейн-состояния, обработка смены владельца, отзыв доступа и защита от подмены RPC-данных.

Token gating часто проектируют так, будто владение NFT является постоянным правом. В реальности право может измениться между моментом проверки и использованием ресурса. Возникает вопрос времени действия разрешения: сервис выдаёт одноразовый ключ, короткоживущий capability или доступ на определённый срок. Долгоживущий доступ удобнее, но увеличивает окно после продажи токена или компрометации сессии.

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

Критические сценарии для dApp

Сервис шифрования данных для Web3-проекта должен заранее описывать поведение в нескольких ситуациях:

1. Пользователь потерял кошелёк. Может ли он восстановить доступ к данным без обхода политики? Если да, кто контролирует recovery?

2. NFT продан. Сохраняется ли ранее выданный доступ или он проверяется при каждом запросе?

3. RPC-узел вернул устаревшее состояние. Как система защищается от stale read при проверке владения?

4. Один из threshold-узлов недоступен. Продолжает ли работать схема при отказе узлов ниже порога?

5. Скомпрометирован frontend. Может ли вредоносный клиент запросить расшифровку от имени пользователя?

6. Публичный ciphertext скопирован. Остаётся ли он бесполезным без threshold-подтверждения?

7. Политика изменилась. Есть ли механизм re-encryption или требуется расшифровка и повторное шифрование данных?

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

Комплаенс начинается с ключей, а не с логотипа сертификата

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

FIPS 140-2 относится к требованиям к криптографическим модулям и аппаратной защите. Наличие такой сертификации у используемого оборудования может быть существенным для корпоративного контура, но само по себе не делает весь сервис соответствующим стандарту. Если приложение неправильно передаёт ключи, пишет plaintext в логи или использует слабую авторизацию, сертифицированный модуль не компенсирует уязвимость верхнего слоя.

Аналогично ISO 27001 оценивает систему управления информационной безопасностью, а SOC 2 — контрольные процедуры и организационные процессы. Это не сертификаты «безопасности конкретного ciphertext». Они показывают, что у оператора есть формализованные процессы, контроль доступа, управление инцидентами и аудит. Техническая проверка всё равно нужна.

Для Web3-инфраструктуры обычно рассматривают следующие контуры:

• генерация ключей: выполняется ли DKG, используется ли HSM, кто имеет административный доступ;
• хранение: не сохраняется ли полный private key, шифруются ли резервные копии, защищены ли секреты в состоянии покоя;
• транспорт: используется ли взаимная аутентификация узлов и защищённые каналы;
• доступ: как связаны wallet signature, identity и политика расшифровки;
• журналирование: фиксируются ли запросы, отказанные операции, смена политик и административные действия;
• удаление и ротация: можно ли отозвать доступ и заменить ключевой материал без массового раскрытия данных;
• регуляторика: где обрабатываются данные, кто является оператором, как выполняются требования GDPR и применимые положения MiCA.

Формулировка «двойное шифрование в состоянии покоя» также требует расшифровки. Два слоя шифрования не означают автоматически удвоенную безопасность. Если оба ключа находятся у одной роли в одном KMS, добавляется главным образом operational overhead. Полезная схема — та, где уровни принадлежат разным контурам доверия: например, аппаратный модуль защищает ключ сервиса, а приложение работает только с временными производными или envelope key.

GDPR добавляет ещё один конфликт с публичной природой блокчейна. Неизменяемый идентификатор, адрес кошелька и связанная с ним информация могут рассматриваться как персонализируемые данные в зависимости от контекста. Шифрование уменьшает риск раскрытия, но не превращает публикацию в автоматически совместимую с требованиями приватности. Удаление plaintext из приложения не удаляет ciphertext из публичного хранилища. Поэтому проект должен заранее понимать, какие данные вообще допустимо якорить в блокчейн или постоянное децентрализованное хранилище.

Как выбирать сервис для Web3-проекта

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

Практический порядок оценки выглядит так.

1. Определить, что именно шифруется

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

Если сервис предлагает один универсальный endpoint для всех этих задач, это повод запросить архитектурную документацию. Универсальность в криптографии часто означает скрытые допущения.

2. Проверить границу доверия

Нужно получить чёткий ответ, кто может расшифровать данные:

• владелец сервиса;
• оператор threshold-узла;
• разработчик dApp;
• администратор KMS;
• frontend;
• сам пользователь через wallet signature;
• заданное количество независимых участников.

Фраза «ключи защищены» ничего не сообщает о распределении полномочий. Аудит начинается с вопроса, может ли один сотрудник или один скомпрометированный компонент получить plaintext без участия остальных.

3. Разобрать DKG и ротацию

Если заявлено threshold encryption, требуется понять, как генерируются доли, как участники аутентифицируют друг друга и как меняется состав узлов. Ротация должна учитывать как компрометацию отдельной доли, так и смену операторов. Простое создание новой пары ключей не решает проблему старых ciphertext: проекту нужен план re-encryption либо контролируемого сохранения прежнего доступа.

4. Замерить не только throughput

Бенчмарк должен включать:

• задержку encrypt и decrypt;
• число сетевых раундов;
• время при недоступности одного или нескольких узлов;
• нагрузку на узлы при массовой выдаче доступа;
• размер ciphertext и служебных метаданных;
• стоимость RPC-вызовов и проверок состояния сети;
• поведение при повторных запросах;
• время восстановления после ротации ключей.

Пороговая криптография обычно дороже локального AES в одном процессе. Сравнивать их напрямую бессмысленно: они решают разные архитектурные задачи. Корректный вопрос звучит иначе — насколько оправдан overhead распределённого доверия для конкретного класса данных.

5. Проверить клиентский контур

Сильный backend не компенсирует скомпрометированный frontend. Если браузер получает plaintext, вредоносный скрипт может украсть его после расшифровки. Нужно проверять CSP, supply chain зависимостей, механизм подписания запросов, привязку сессии к wallet и возможность использования hardware wallet.

Для особо чувствительных данных стоит рассматривать локальную расшифровку, когда сервер выдаёт только зашифрованный объект и необходимые ключевые материалы, а plaintext появляется в контролируемом клиентском окружении. Но это усложняет UX, восстановление и поддержку нескольких устройств. Простого решения здесь нет.

6. Провести негативные тесты

Нормальная проверка сервиса — это не только успешный decrypt. Нужны тесты отказов:

• один узел threshold-сети отвечает злоумышленными данными;
• запрос повторяется с устаревшим nonce;
• пользователь больше не владеет токеном;
• RPC возвращает старый block state;
• frontend изменяет условие доступа;
• администратор пытается вызвать расшифровку напрямую;
• резервная копия содержит полный ключ;
• журналы случайно записывают plaintext;
• доступ выдаётся после смены политики.

Именно такие сценарии находят уязвимость. Happy path почти всегда проходит даже у плохой архитектуры.

Итоговый технический вердикт

Сервис шифрования данных для Web3-проектов нужно выбирать как распределённую систему управления секретами, а не как готовый криптографический виджет. EIP-1024 не стал универсальной основой для шифрования в Ethereum, и пытаться закрыть этот пробел повторным использованием ключа подписи — архитектурная ошибка.

Базовый зрелый вариант выглядит так: данные шифруются до публикации в публичное хранилище, ключевой материал не собирается в одном сервисе, DKG и threshold encryption распределяют доверие между независимыми узлами, а доступ привязан к проверяемой политике. Lit Protocol показывает один из практических способов связать такую модель с token gating и блокчейн-условиями, но наличие threshold-слоя не отменяет аудит frontend, RPC, политик и журналирования.

Для корпоративного контура нужны не только FIPS 140-2, ISO 27001 или SOC 2 в презентации провайдера, но и проверяемые ответы по ротации, recovery, отказам и компрометации узлов. GDPR и MiCA добавляют требования к процессам, но не исправляют плохую криптографическую архитектуру.

Жёсткий критерий простой: если один администратор, один KMS или один backend может получить полный закрытый ключ и расшифровать весь массив данных без независимого согласия, перед нами централизованный сервис с Web3-интерфейсом. Он может быть удобным. Надёжным — только после доказательства обратного бенчмарками, threat model и аудитом исходного кода.