Архитектура нулевого знания: почему сервер не видит ваши файлы

Архитектура нулевого знания означает, что у провайдера нет технической возможности читать ваши файлы — ключи шифрования никогда не достигают их серверов, нет мастер-ключа, нет лазейки, не требуется «доверяйте нам». Ваш браузер шифрует файлы с помощью AES-256-GCM перед загрузкой, используя ключ, сгенерированный локально, — и этот ключ попадает к получателю только через фрагмент URL после #, который браузеры никогда не передают серверам. Даже по действительной судебной повестке провайдер может предоставить только шифротекст. Эта модель используется Tresorit, Proton, SwissTransfer и HexaTransfer, и она математически отличается от «зашифровано при хранении».

Доказательство — в том, что сервер может предоставить

Самый чистый тест нулевого знания: что компания может передать под принуждением? В традиционном облачном хранилище (Google Drive, Dropbox, OneDrive) ответ: ваши файлы в открытом виде. Отчёт о прозрачности Google за 2023 год показывает, что компания удовлетворила 83% запросов правительства США, предоставив пользовательский контент там, где это требовалось по закону. Это не провал системы безопасности Google — так работает архитектура.

При нулевом знании компания может предоставить:

Зашифрованные блобы файлов (бесполезные без ключа)
Метаданные аккаунта (email, IP при регистрации)
IP-адреса загрузок и скачиваний, временны́е метки
Платёжные данные, если применимо

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

Трюк с фрагментом URL, объяснённый точно

Основной технический приём — использование фрагмента URL как скрытого канала для передачи ключа. Когда браузер запрашивает https://hexatransfer.com/d/xyz789#k=BASE64KEY, на сервер отправляется только GET /d/xyz789. Фрагмент остаётся в адресной строке браузера. JavaScript затем вызывает window.location.hash для чтения ключа и передаёт его в crypto.subtle.decrypt().

Этот подход был впервые применён Mega.nz около 2013 года и доработан Firefox Send до его закрытия Mozilla в 2020 году. Сейчас это стандартная схема. Серверные логи, включая логи доступа nginx или Caddy, никогда не фиксируют фрагмент, поскольку HTTP RFC 3986 определяет его как клиентскую часть.

Теоретически провайдер мог бы логировать фрагмент через клиентский JavaScript — именно поэтому сервисы нулевого знания публикуют клиентский код для проверки и нередко поставляют его как подписанные статические ресурсы с отдельного источника.

Чем это отличается от «зашифровано при хранении»

Все облачные провайдеры шифруют файлы при хранении — это базовый уровень, обычно требуемый сертификациями SOC 2 Type II и ISO 27001. Но «зашифровано при хранении» с ключами на стороне провайдера означает: шифрование скрыто от злоумышленников с украденными дисками и незаметно для вас в том смысле, что провайдер автоматически расшифровывает по запросу.

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

Недобросовестные сотрудники. Сотрудник провайдера с доступом к базе данных видит только шифротекст.
Запросы властей. Статья 48 GDPR и запросы по US CLOUD Act могут обязать к раскрытию, но нельзя передать то, чего нет.
Взломы серверов. Утечка LastPass в 2021 году раскрыла зашифрованные хранилища; слабые мастер-пароли всё же взламывались, но архитектура нулевого знания предотвратила массовое раскрытие в открытом виде.

Что шифруется, а что остаётся метаданными

Наивная реализация шифрует содержимое файла, но оставляет имена файлов, размеры и структуру папок видимыми. Настоящее нулевое знание шифрует и имя файла — обычно добавляя JSON-заголовок вроде {"name": "Q4-financials.pdf", "type": "application/pdf"} к байтам файла до AES-GCM-шифрования.

Метаданные, которые сложно скрыть:

Размер файла — длина шифротекста приближается к длине открытого текста. Дополнение до фиксированных корзин (1 МБ, 10 МБ, 100 МБ, 1 ГБ) скрывает это, но тратит полосу пропускания.
Время загрузки — сопоставление временны́х меток с другими данными всё равно может раскрыть информацию.
IP-адреса — провайдер видит, кто загружал и скачивал. Используйте Tor или доверенный VPN, если это важно.

Proton и Tresorit публикуют подробные матрицы раскрытия метаданных. SwissTransfer и HexaTransfer придерживаются более простого подхода: минимум метаданных, короткий срок хранения (24 часа — 7 дней) и отсутствие привязки к аккаунту для бесплатных передач.

Задача аутентификации

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

Аутентификация по ссылке. Владение URL (и фрагментом) является авторизацией. Используется SwissTransfer, HexaTransfer, Tresorit Send. Просто, работает без аккаунтов.
Ссылки с паролем. Фрагмент URL содержит соль; фактический ключ получается через PBKDF2 из пароля. Сервер хранит верификатор (хеш ключа) для быстрого отклонения неверных попыток.
Нулевое знание с привязкой к аккаунту. Proton и Tresorit получают мастер-ключ из пароля входа через Argon2id, затем используют его для разблокировки ключей отдельных файлов, зашифрованных на сервере.

У каждой схемы есть компромиссы. Аутентификация по ссылке — проще всего, но передаёт ключ любому, получившему URL. Защита паролем добавляет второй фактор. Привязка к аккаунту требует доверять клиентскому коду — что он не передаёт мастер-ключ.

Подводные камни реализации, разрушающие нулевое знание

Несколько реальных провалов, о которых стоит знать:

Предварительный просмотр файлов на сервере. Если провайдер создаёт миниатюры или извлекает текст для поиска — ему нужен открытый текст. Сервисы нулевого знания не могут предлагать эти функции для зашифрованного содержимого.
Разрешение конфликтов синхронизации. Сравнение содержимого файлов на разных устройствах обычно требует открытого текста. Syncthing и Cryptomator решают это с помощью клиентских диффов.
Аналитические SDK. Сторонние скрипты Google Analytics или Segment могут читать window.location.hash в клиентском коде. Сервисы нулевого знания либо используют собственную аналитику, либо блокируют доступ к фрагменту.
Сброс пароля. Если провайдер может сбросить пароль и при этом дать доступ к старым файлам — он должен хранить ключ восстановления, что нарушает нулевое знание. Proton прямо предупреждает: сброс пароля означает потерю зашифрованных данных.

Кто действительно реализует нулевое знание

Краткий список сервисов с достоверными претензиями на нулевое знание, подтверждёнными независимыми аудитами (Cure53, NCC Group, Trail of Bits):

Tresorit — Швейцария, SOC 2 Type II, нулевое знание для синхронизации файлов и Send.
Proton Drive — Швейцария, основан на модели шифрования Proton Mail.
SwissTransfer — бесплатный уровень с опциональным E2EE, управляется Infomaniak.
Mega.nz — Новая Зеландия, опубликован технический документ по криптографии.
HexaTransfer — браузерный, без аккаунта, до 10 ГБ на передачу.

Сервисы, зашифрованные, но не нулевого знания: Google Drive, Dropbox, OneDrive, Box, iCloud (кроме уровня Advanced Data Protection) и стандартный уровень WeTransfer.

Применение на практике

Перед тем как доверить сервису конфиденциальные файлы, пройдите этот чеклист:

Заявляет ли политика конфиденциальности, что провайдер не может читать ваши файлы?
Есть ли опубликованный технический документ по безопасности с указанием AES-256-GCM и KDF?
Содержит ли URL для скачивания фрагмент (текст после #)?
Есть ли отчёты о независимых аудитах за последние 24 месяца?
Открыт ли клиентский код или хотя бы доступен для проверки?

Четыре «да» — вы нашли сервис с нулевым знанием. Три или меньше — провайдер может видеть ваши файлы.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.