Почему одних доказательств с нулевым разглашением недостаточно для защиты приватности

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

Это обещание реально. Но оно уже, чем часто кажется.

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

Эта статья адаптирует презентацию, представленную NGI TrustChain в сентябре 2024 года. Главный тезис прост: доказательства с нулевым разглашением являются важным строительным блоком приватного гражданского участия, но приватность пользователя — это свойство всей технической системы.

Почему идентичность появляется в гражданских платформах

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

Гражданские платформы решают другую задачу. Если цель — собрать содержательный общественный вклад, противостоять спаму, снизить вычислительную пропаганду или поддержать процессы "один человек — один голос", системе нужна форма защиты от Sybil-атак. На практике ей может понадобиться знать, что участник является реальным человеком, относится к соответствующему сообществу или удовлетворяет правилу гражданской допустимости.

Подходов несколько, и у каждого есть компромиссы:

Биометрические системы могут давать уникальность, но создают серьезные риски приватности и безопасности.
Системы на основе социального графа полезны в некоторых контекстах, но плохо масштабируются и часто имеют слабые гарантии приватности.
Гибридные web of trust подходы могут работать для отдельных сообществ, но обычно дают более слабую уникальность.
Государственные или институциональные credentials могут давать сильные гарантии, но не должны превращаться в слой наблюдения.

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

Что доказательства с нулевым разглашением делают хорошо

В упрощенном потоке credential участвуют три стороны:

Эмитент подтверждает факт о человеке и выдает credential.
Держатель хранит credential и решает, когда его использовать.
Верификатор проверяет доказательство, полученное из credential.

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

Этот паттерн поддерживают разные технические подходы. BBS+ credentials позволяют выборочное раскрытие и несвязываемые доказательства. Другие подходы "меркелизируют" более связываемые форматы credential и используют ZK-SNARKs, чтобы сделать их более приватными. Универсальные zkVM в будущем могут упростить доказательства фактов о существующих security-focused credentials.

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

Это решает важную проблему. Но не решает все проблемы приватности.

Модель угроз: держатель на первом месте

Для гражданского участия модель приватности должна начинаться с точки зрения держателя. Человек, использующий credential, должен контролировать, что он раскрывает и кому.

Это требует более строгой модели угроз, чем у большинства современных социальных платформ:

Верификатор, то есть платформа, запрашивающая доказательство, не должен слепо считаться доверенным. Он может пытаться деанонимизировать пользователя, если система не делает это трудным и проверяемым.
Эмитент доверен для идентификации держателя и выдачи valid credential, но не должен знать, где, когда и зачем credential используется позже.
Эмитент и верификатор не должны иметь возможность сговориться и идентифицировать пользователей через предъявления доказательств.
Проприетарный клиентский код, код кошелька и frontend верификатора должны считаться поверхностями риска, если они не open source, не инспектируемы и желательно не прошли независимый аудит.

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

Остальная часть айсберга приватности

Самая простая ошибка — считать доказательство с нулевым разглашением всей системой приватности. На самом деле доказательство — только один слой.

Избыточное раскрытие

Даже если доказательство генерируется в zero knowledge, верификатор может запросить слишком точные, слишком многочисленные или слишком редкие атрибуты. Пользователь может не раскрывать весь документ, но комбинация атрибутов все равно может его идентифицировать.

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

Сетевые метаданные

Верификатор может пытаться связать доказательство с пользователем через IP-адреса, отпечатки браузера, метаданные устройства или время запросов. Если доказательство отправлено из той же браузерной сессии, что и идентифицирующий логин или email verification, математическая приватность доказательства может перестать иметь значение.

Zero knowledge по умолчанию не скрывает сетевой слой. Важны приватность транспорта, прокси, политика логирования и аккуратное разделение сессий.

Cookies и data brokers

Сторонние cookies, аналитические скрипты, рекламные идентификаторы и купленные данные могут подорвать приватность доказательства. Если верификатор встроит tracking вокруг proof flow, он может сопоставить анонимное доказательство с известной web identity.

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

Email, телефон и восстановление аккаунта

Email и телефон удобны, но являются сильными идентификаторами. Если верификатор связывает их с доказательством с нулевым разглашением, доказательство может стать частью более широкого identity profile.

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

Постоянные идентификаторы

Доказательство с нулевым разглашением все еще может быть связано, если вокруг него появляется тот же постоянный идентификатор. Адреса кошельков, DIDs, subject IDs, device IDs или устойчивые account IDs могут стать ручками корреляции.

Системы, которым нужна псевдонимность, должны использовать контекстные или pairwise идентификаторы вместо универсальных. Пользователь не должен по умолчанию нести один и тот же след между несвязанными гражданскими пространствами.

Корреляция по времени

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

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

Кошельки, устройства и supply-chain риски

Доказательство может быть криптографически корректным, но кошелек или клиент все еще может утекать чувствительные данные. Проприетарный кошелек может отправлять телеметрию. Скомпрометированный SDK может раскрывать атрибуты. Вредоносный frontend может запросить больше, чем пользователь понимает.

Open source не устраняет эти риски магически, но закрытый код делает их гораздо сложнее проверять. Для доверенных гражданских систем open-source клиенты, воспроизводимые сборки, независимые аудиты и минимальная телеметрия должны быть базовой инфраструктурой.

Поведенческий вывод

Машинное обучение может выводить идентичность из паттернов, которые по отдельности кажутся безобидными. Стиль письма, время активности, поведение устройства, паттерны местоположения и история взаимодействий могут сужать anonymity set.

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

Лучшая архитектура для правдоподобно анонимных доказательств

Приватный credential flow нужно проектировать с предположением, что верификатор хочет узнать больше, чем должен.

Как минимум гражданская платформа с доказательствами с нулевым разглашением должна учитывать такие принципы:

Запрашивать наименее точное доказательство, достаточное для гражданского требования.
Не смешивать предъявление доказательства с идентифицирующими account flows.
Не привязывать телефоны, email, адреса кошельков или постоянные DIDs к proof events, если use case не требует этого явно.
Убрать сторонние cookies, аналитику и trackers из proof flow.
Минимизировать логи, особенно IP-адреса, временные метки и метаданные запросов.
Использовать контекстные псевдонимы, когда требуется постоянное участие.
Делать frontend верификатора, proof-request logic, wallet integrations и SDK open source и audit-friendly.
Делать proof requests понятными пользователям, чтобы они видели, что доказывается и что не раскрывается.
Предотвращать callbacks к эмитенту и другие механизмы, которые позволили бы ему узнать, где используются credentials.

Цель — не только анонимные доказательства. Цель — правдоподобная анонимность: система, в которой пользователи, аудиторы и гражданское общество могут проверить, совпадают ли обещания приватности с реальным поведением платформы.

Открытые вызовы

Впереди остается сложная работа.

Во-первых, пользовательский опыт пока недостаточно хорош. Большинство людей не может рассуждать о credential schemas, selective disclosure, proof requests, issuer unlinkability или correlation attacks. Безопасный продукт должен объяснять свойства приватности, не требуя от пользователей стать криптографами.

Во-вторых, экосистема credentials фрагментирована. BBS+, SD-JWT, мобильные водительские удостоверения, паспортные чипы, merkelized credentials и zkVM-based proofs имеют разные компромиссы. Гражданским платформам нужна интероперабельность, но не ценой перехода к самому слабому общему знаменателю приватности.

В-третьих, Sybil resistance и приватность остаются в напряжении. Более сильная уникальность часто требует более сильного identity evidence. Задача — проверять только необходимое и не позволять этой проверке стать универсальным identity graph.

В-четвертых, предотвращение злоупотреблений не должно заново создавать наблюдение. Анонимным или псевдонимным пространствам все еще нужны модерация, rate limits и механизмы ответственности. Но они должны быть спроектированы так, чтобы не реидентифицировать всех незаметно.

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

Заключение

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

Но доказательства — не вся система приватности. Верификатор все еще может атаковать соседние слои: атрибуты, метаданные, cookies, email, телефон, постоянные идентификаторы, время, кошельки, устройства и поведенческие паттерны.

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

Практический урок ясен: используйте zero knowledge, но не останавливайтесь на этом.