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