Что такое шифрование с нулевым разглашением? Простое руководство
Шифрование с нулевым разглашением означает, что провайдер не может получить доступ к вашим данным.
Шифрование с нулевым разглашением — это архитектура с разделением ключей поставщика, в которой служба не хранит ключ, нужный для расшифровки сохранённого содержимого пользователя. В отличие от обычного облачного шифрования, где ключ содержимого контролирует поставщик, шифрование на стороне клиента может оставить эту возможность только на устройствах пользователя. Юридический запрос, утечка или инсайдер всё равно могут раскрыть шифртекст, записи учётной записи, данные трафика и другие метаданные, которые сохраняет поставщик. Рекомендации NIST по управлению ключами ставят хранение ключей в центр контроля доступа, но клиентское приложение, операционная система и разблокированное устройство остаются частью границы доверия.
Как работает шифрование с нулевым разглашением
Простейшая аналогия: сейф в гостинице, где только вы устанавливаете комбинацию, а гостиница её никогда не узнаёт. Если вы забудете комбинацию, гостиница не сможет открыть сейф. Это не недостаток конструкции. Это и есть конструкция.
Технически шифрование с нулевым разглашением работает в три этапа:
Получение ключей на устройстве. Пользователь вводит учётные данные: пароль, парольную фразу или узор. Функция получения ключа из пароля объединяет их с солью и создаёт ключ на устройстве пользователя. В хорошо разделённой схеме этот ключ открывает случайный ключ шифрования содержимого, а не шифрует каждый файл напрямую учётными данными человека.
Шифрование перед передачей. Все данные шифруются на устройстве с помощью производного ключа до того, как покинут устройство для облачного хранения или резервного копирования. Зашифрованный результат (шифротекст) — это то, что загружается.
Поставщик не получает ключ содержимого в открытом виде. Ключи содержимого неизбежно находятся в памяти клиента во время работы и могут храниться локально или удалённо внутри аутентифицированных зашифрованных конвертов. Поставщик может хранить шифртекст и обёрнутые ключи, не храня секрет пользователя, нужный для их открытия. Метаданные учётной записи, трафика, размеров записей и времени при этом могут оставаться видимыми.
Ключевое ограничение: если пользователь теряет все действительные учётные данные и пути восстановления, зашифрованное содержимое становится недоступным. Восстановление всё же может существовать, но нужно объяснить, где хранится его ключ. Если сброс через электронную почту сам по себе возвращает читаемое содержимое без подтверждения со старого устройства, фразы восстановления, ключа восстановления или другого секрета, который хранит пользователь, у поставщика остаётся действующий путь к открытому тексту.
Шифрование с нулевым разглашением vs другие типы шифрования
Слово «шифрование» встречается в маркетинговых материалах почти каждого облачного сервиса. Различия между типами существенны.
| Тип | Кто хранит ключ | Провайдер может читать данные | Защищает при утечке у провайдера | Пример |
|---|---|---|---|---|
| Без шифрования | Н/П | Да | Нет | Dropbox (стандартный уровень) |
| Шифрование при передаче (TLS) | Провайдер | Да (при хранении на их серверах) | Нет | Google Фото |
| Серверное шифрование при хранении | Провайдер | Да (они хранят ключ дешифрования) | Частично (зависит от масштаба утечки) | iCloud (стандартный) |
| Сквозное шифрование платформы | Клиентские устройства и система восстановления аккаунтов | Не обычными средствами службы | Зависит от клиента, способа восстановления и доступа к метаданным. | iCloud с расширенной защитой данных |
| Шифрование на стороне клиента с разделением ключей поставщика | Клиент и путь восстановления под контролем пользователя | У поставщика нет ключа в открытом виде | Содержимое может оставаться зашифрованным; метаданные и шифртекст всё равно могут утечь | Зашифрованные сейфы и системы резервного копирования |
Наиболее часто путают «шифрование при хранении» и «шифрование с нулевым разглашением». При шифровании при хранении провайдер шифрует ваши данные на своих серверах с помощью ключей, которые он контролирует. Это защищает от физической кражи серверного оборудования. Но не защищает от провайдера, читающего ваши данные, от судебного ордера на данные и ключи или от внутренних угроз. Провайдер сохраняет возможность дешифрования.
При шифровании на стороне клиента с разделением ключей поставщика служба по задокументированному протоколу не получает ключ содержимого в открытом виде. Сохранённый шифртекст может оставаться непрозрачным для поставщика, но клиентскому ПО, пути восстановления, метаданным учётной записи и каналу доставки ПО всё равно нужно доверять и их нужно проверять.
Почему важно шифрование с нулевым разглашением
Утечки данных ежегодно затрагивают миллиарды записей
Identity Theft Resource Center сообщил о 3205 случаях компрометации данных в США в 2023 году, затронувших примерно 353 миллиона человек. Когда ключи содержимого у поставщика, одна утечка может раскрыть и сохранённые данные, и способ их расшифровать. Шифрование с разделением ключей поставщика разделяет эти активы: взлом сервера может раскрыть шифртекст и метаданные, но не ключ содержимого в открытом виде, которого у поставщика нет. Подбор учётных данных и компрометация клиента остаются отдельными рисками.
Правовое принуждение — реальная угроза
От поставщиков могут потребовать раскрыть данные, которые они хранят. Схема с разделением ключей поставщика может ограничить такой ответ шифртекстом и доступными метаданными учётной записи, трафика, оплаты или службы, поскольку ключа содержимого в открытом виде у поставщика нет. Может ли другая сторона получить учётные данные пользователя, взломать клиент или потребовать раскрытия — отдельный вопрос. Apple представила расширенную защиту данных в iOS 16.2 как необязательное расширение сквозного шифрования для данных iCloud.
«Доверьтесь нам» — это не архитектура безопасности
Шифрование на стороне сервера опирается на ключи и правила, которые контролирует поставщик. Шифрование с разделением ключей поставщика меняет схему хранения ключей, поэтому в задокументированном пути службы нет ключа содержимого в открытом виде. Это более строгая архитектурная граница, но её надёжность по-прежнему зависит от правильного клиентского кода, аутентифицированной доставки ПО, продуманного восстановления, защищённых устройств и соответствия реализации спецификации.
Стандарт NIST, лежащий в основе криптографии
AES-GCM стандартизирован Национальным институтом стандартов и технологий США в SP 800-38D (2007). Сам AES был выбран NIST по итогам открытого конкурса в 2001 году. Число «256» в AES-256 означает 256-битный ключ. Полный перебор равномерно случайного ключа вычислительно невыполним, но пароль или узор, выбранный человеком, может давать гораздо меньше энтропии, даже если функция получения ключа выдаёт 256 бит.
GCM (режим счётчика Галуа) добавляет аутентифицированное шифрование, то есть процесс расшифровки обнаруживает любое изменение шифротекста. Если изменён хотя бы один бит зашифрованных данных, расшифровка завершается ошибкой, а не выдаёт повреждённый результат. Это предотвращает манипуляции с зашифрованными данными без обнаружения.
PBKDF2 (Password-Based Key Derivation Function 2), описанная в RFC 8018, превращает учётные данные, введённые человеком, в ключевой материал фиксированной длины с помощью многократных вызовов псевдослучайной функции. Больше итераций — выше стоимость каждой попытки. Энтропии предсказуемому узору или паролю они не добавляют, поэтому выбор учётных данных и возможность офлайн-проверки по-прежнему важны.
Как Vaultaire реализует разделение ключей поставщика
Vaultaire — зашифрованный сейф на стороне клиента для iPhone. Продукты такого типа часто называют решениями с «нулевым разглашением», но задокументированное утверждение Vaultaire уже: Wraxle не получает содержимое сейфа в открытом виде и ключи, нужные для его расшифровки. Ниже описано, как устроена реализация и где проходят оставшиеся границы доверия на каждом уровне.
Получение ключей. Пользователь рисует узор на сетке 5x5 из 25 точек. PBKDF2-HMAC-SHA512 объединяет эту последовательность с общей для устройства солью из Keychain и за 600 000 итераций получает 256-битный ключ сейфа. Ключ сейфа аутентифицирует зашифрованный индекс и разворачивает отдельный случайный 256-битный главный ключ. Данные восстановления, включая узор, хранятся в базе данных Keychain, зашифрованной AES-GCM, а не в файлах открытого текста или учётной записи Vaultaire.
Шифрование файлов. Каждый импортированный файл шифруется AES-256-GCM под случайным главным ключом. CryptoKit создаёт аутентифицированные запечатанные контейнеры со свежими nonce, а потоковый формат получает отдельный nonce для каждого упорядоченного фрагмента.
Шифрование метаданных. Имена файлов, MIME-типы, даты, записи индекса и данные миниатюр тоже защищены AES-256-GCM. Vaultaire не использует ChaCha20 для метаданных сейфа.
Управление ключами. Vaultaire хранит соль устройства и зашифрованную базу данных восстановления как обычные элементы общего пароля в iOS Keychain с классом доступности WhenUnlockedThisDeviceOnly. Ключи сейфов, полученные из узоров, и случайные главные ключи обрабатываются в памяти приложения через CryptoKit. Блокировка удаляет активное состояние ключей, но Swift и iOS не гарантируют, что каждая временная копия будет перезаписана.
Обнаружение сейфов. Обычный интерфейс не показывает список сейфов. Формат хранения содержит одну папку хранения на каждый сейф. Поэтому тот, у кого есть доступ к контейнеру приложения, может подсчитать сейфы, хотя имена папок не раскрывают узоры, названия или содержимое в открытом виде. Подробнее: архитектура безопасности и объяснение шифрования узором.
Как проверить, использует ли приложение реальное шифрование с нулевым разглашением
Начните с трех быстрых тестов, затем проверьте опубликованную архитектуру:
Тест забытого пароля. Если читаемые данные возвращает один лишь сброс через электронную почту, спросите, какой механизм поставщика восстановил действующий ключ содержимого. Фраза восстановления у пользователя, подтверждение со старого устройства и сброс под контролем поставщика — это разные схемы.
Тест нового устройства. Если новое устройство получает читаемое содержимое, выясните, какой секрет или доверенное устройство это разрешили. Если достаточно одного входа в учётную запись, путь восстановления контролирует поставщик; фраза восстановления вместе с зашифрованными записями резервной копии может сохранить разделение ключей поставщика.
Тест учётной записи. Адрес электронной почты или номер телефона связывают личность с метаданными службы, но сами по себе не доказывают, что поставщик может расшифровать содержимое. Проверьте иерархию ключей, схему восстановления, клиентский код или аудит, политику метаданных, а также то, позволяет ли аутентифицированный шифртекст проверять учётные данные офлайн.
Эти тесты — фильтры, а не доказательство безопасности. Последовательная спецификация должна указывать ключ содержимого, ключ разблокировки, соли, параметры получения ключей, формат аутентифицированного шифрования, правила nonce, конверты восстановления, локальное хранилище секретов, облачные метаданные и места, где ключи существуют в открытом виде. Независимая проверка — более сильное доказательство, чем надпись на продукте.
Часто задаваемые вопросы
Шифрование с нулевым разглашением — то же самое, что сквозное шифрование?
Они пересекаются, но не идентичны. Сквозное шифрование (E2EE) означает, что данные шифруются на устройстве отправителя и расшифровываются только на устройстве получателя. Шифрование с нулевым разглашением означает, что провайдер не может получить доступ к данным. Сервис может использовать E2EE, не являясь при этом системой с нулевым разглашением, если провайдер создавал ключи или имел к ним доступ в какой-то момент. Шифрование с нулевым разглашением — более строгий стандарт.
Что произойдёт, если я потеряю пароль при шифровании с нулевым разглашением?
Ваши данные становятся навсегда недоступными, если потеряны все действительные учётные данные и конверт восстановления. Сброс или главный ключ под контролем поставщика ослабляют границу поставщика, поэтому восстановление нужно проектировать отдельно. Vaultaire создаёт фразу восстановления из 9 отдельных слов; полученный из неё ключ восстановления открывает зашифрованный конверт с ключом сейфа. Фраза не воссоздаёт и не кодирует ключ, а для восстановления на новом устройстве также нужны соответствующие зашифрованные записи CloudKit.
Может ли полиция получить доступ к данным, зашифрованным с нулевым разглашением?
Поставщика могут обязать раскрыть сохранённый шифртекст и метаданные учётной записи, трафика, оплаты или службы, которые он хранит. Если у поставщика нет ключа содержимого в открытом виде, он не может расшифровать содержимое обычными средствами службы. Взлом устройства, получение учётных данных, копии для восстановления и принудительное раскрытие — отдельные пути, законность и действенность которых зависят от юрисдикции и обстоятельств.
Шифрование с нулевым разглашением медленнее обычного?
Производительность AES-256-GCM не зависит от того, у кого ключ. Получение ключа из пароля добавляет работу при разблокировке, и её длительность зависит от алгоритма, числа итераций, устройства и реализации. Приложениям стоит измерять эти затраты на поддерживаемом оборудовании и соизмерять скорость отклика со стоимостью каждой офлайн-попытки.
Означает ли нулевое разглашение, что приложение вообще не собирает данные?
Не обязательно. Этот термин описывает границу ключа содержимого у поставщика, а не каждый поток данных. Приложение всё равно может обрабатывать данные учётной записи, аналитику, отчёты о сбоях, IP-адреса, размеры записей, время и другие метаданные службы. Vaultaire не требует учётной записи для идентификации. Аналитика приложения и диагностика сбоев включены по умолчанию, но их можно отключить переключателем «Анонимно делиться ошибками» в настройках. Задокументированная политика событий исключает содержимое сейфов, узоры, фразы и ключи расшифровки; политика конфиденциальности описывает текущие правила сбора и хранения.
Как шифрование с нулевым разглашением соотносится с расширенной защитой данных Apple?
Расширенная защита данных Apple (ADP), представленная в iOS 16.2, распространяет сквозное шифрование на дополнительные категории iCloud и использует модель восстановления учётной записи Apple. Vaultaire шифрует содержимое сейфов на устройстве и не требует учётной записи Vaultaire; резервное копирование в iCloud (включено по умолчанию, можно отключить), синхронизация и общий доступ используют записи CloudKit, зашифрованные на стороне клиента, в учётной записи Apple пользователя. Vaultaire также предлагает доступ к сейфам, разделённым по узорам, и режим принуждения; ограничения по хранению и восстановлению описаны в документации о правдоподобном отрицании.
Итог
Шифрование с нулевым разглашением лучше понимать как утверждение о разделении ключей поставщика: служба не хранит ключ в открытом виде, нужный для расшифровки сохранённого содержимого. Это надёжнее, чем шифрование на стороне сервера с ключами под контролем поставщика, но это не утверждение, что ключи существуют только в памяти, что метаданные исчезают или что компрометация любого клиента и устройства невозможна. Оценивайте продукт по иерархии ключей, схеме восстановления, реализации и независимой проверке.