Правдоподобное отрицание в приложениях: что это и почему важно
Правдоподобное отрицание означает, что существование скрытых данных нельзя доказать.
Правдоподобное отрицание при шифровании — это свойство хранилища, которое позволяет пользователю раскрывать один набор данных, не оставляя структурного артефакта, доказывающего существование другого набора данных. В заявлении должна быть указана модель угрозы: статическое изображение правильно дополненного зашифрованного хранилища отличается от действующего, скомпрометированного устройства, метаданных облачного сервиса или копий, хранящихся в другом месте. Это больше, чем функция сокрытия. Это зависит от совместной работы шифрования, макета, заполнения и операционной конструкции.
Это руководство объясняет, как правдоподобное отрицание работает в приложениях, разницу между настоящей криптографической отрицаемостью и косметическими режимами-приманками, реальные сценарии, где это важно, и как оценивать заявления об отрицаемости.
Что означает правдоподобное отрицание в шифровании
На повседневном языке правдоподобное отрицание означает, что вы можете достоверно отрицать что-то. В криптографии хранилища полезная цель уже: проверяющий зашифрованное хранилище не должен иметь возможности отличить скрытое содержимое от неиспользуемого дополнительного пространства в рамках заявленной модели угроз. Ни одно приложение не может распространить это обещание на уже открытое хранилище, записанные данные, внешние копии или любую форму компрометации устройства.
Концепция зародилась в дисковом шифровании. TrueCrypt (и его преемник VeraCrypt) ввёл скрытый том: зашифрованный том внутри другого. Один пароль раскрывает внешний том с безобидными файлами. Другой пароль раскрывает внутренний скрытый том с конфиденциальными файлами. Криминалист не может определить, существует ли скрытый том, потому что неиспользованное пространство внешнего тома заполнено случайными данными, неотличимыми от зашифрованных.
Для приложений правдоподобное отрицание означает, что разные учётные данные (пароли, PIN, узоры) открывают разные наборы данных, и нет метаданных, реестра, флага конфигурации или структурного артефакта, раскрывающего существование дополнительных наборов данных.
Настоящая отрицаемость vs косметические режимы-приманки
Это критическое различие, которое большинство приложений допускает неправильно.
Косметический режим-приманка (не настоящая отрицаемость)
Многие хранилища предлагают функцию «приманки» или «фальшивого PIN». Устанавливается вторичный PIN, открывающий отдельное пространство с другими фотографиями. Проблема: такие приложения обычно хранят булево значение, запись в базе данных или файл конфигурации, указывающий, что режим-приманка существует и настроен.
Криминалист, знающий приложение, может найти этот флаг. Обнаружение настроенного режима-приманки доказывает существование скрытых данных. Отрицаемость косметическая — она работает против случайного подглядывания, но не при криминалистической экспертизе.
Признаки косметической отрицаемости:
- В настройках есть переключатель «режим-приманка»
- Файл конфигурации хранит, включён ли режим-приманка
- Таблица базы данных перечисляет ID хранилищ с индикаторами типа (основное/приманка)
- Структура хранилища приложения меняется при включении режима-приманки
- Удаление и повторная установка приложения выявляет разное поведение при настроенном режиме-приманке
Настоящая криптографическая отрицаемость
Настоящая отрицаемость — это архитектурное свойство, а не функциональный переключатель. Зашифрованное хранилище должно быть спроектировано так, чтобы:
Альтернативные учетные данные раскрывают только свой собственный набор данных. Система не хранит отдельный флаг-ловушку, который идентифицирует одно удостоверение как камуфляж. Неверные учетные данные могут привести к сбою, но этот сбой не должен указывать на существование нераскрытого набора данных.
Нет реестра хранилищ. Приложение не может перечислить, сколько хранилищ существует. Нет счётчика, индекса, списка ID хранилищ. Криминалист, исследующий хранилище приложения, находит недифференцированный пул зашифрованных данных.
Нет флагов конфигурации, раскрывающих скрытые хранилища. Нет булевого значения, записи в базе данных, файла настроек, указывающего, существуют ли дополнительные хранилища.
Хранилище дополнено случайными данными. Общий занятый объём не меняется в зависимости от количества хранилищ или файлов. Без дополнения исследователь мог бы оценить количество хранилищ по разнице между общим объёмом зашифрованных данных и видимым содержимым.
Зашифрованные данные неотличимы от случайного шума. Нет границ файлов, заголовков, структурных маркеров, раскрывающих, где заканчиваются данные одного хранилища и начинаются другого.
| Свойство | Косметическая приманка | Настоящая отрицаемость |
|---|---|---|
| Отдельные данные для каждых учётных данных | Да | Да |
| Нет реестра хранилищ | Нет (база данных отслеживает хранилища) | Да |
| Нет флагов конфигурации | Нет (переключатель приманки хранится) | Да |
| Дополнение хранилища | Редко | Да |
| Скрывает альтернативное хранилище в статическом изображении. | Нет | Да, в рамках заявленной модели угроз хранения |
| Архитектурное vs функция | Функциональный переключатель | Архитектурное свойство |
Реальные сценарии, где это важно
Правдоподобное отрицание — не теоретическая проблема. Оно адресует задокументированные, повторяющиеся реальные ситуации.
Пограничные переходы
При пересечении границы эксперт может осмотреть устройство и запросить учетные данные. Если дизайн действительно обеспечивает отрицание на уровне хранилища, один учетный документ может раскрыть безобидный набор данных, в то время как статическое изображение не имеет структурного маркера, который отличает скрытое содержимое от заполнения. Текущая схема Vaultaire с одним индексным файлом на каждое хранилище не дает такой гарантии эксперту, имеющему доступ к контейнеру приложения.
Домашнее насилие и принудительные отношения
Человек в отношениях с насилием может нуждаться в хранении доказательств (фото травм, угрожающих сообщений, юридических документов) на устройстве, которое контролирует насильник. Если насильник требует показать хранилище, пользователь может открыть хранилище с неконфиденциальным контентом. Без настоящей отрицаемости флаг «режима-приманки» в конфигурации приложения раскрыл бы существование скрытого контента.
Кража устройства
Вор, обладающий техническими навыками, может попытаться извлечь данные из украденного телефона. Правильно дополненное отрицаемое хранилище призвано скрыть, сколько наборов данных занимает пул, хотя общее распределение, состояние устройства, резервные копии и операционные следы по-прежнему входят в модель угроз. В настоящее время Vaultaire шифрует содержимое, но предоставляет один счетный локальный индекс для каждого настроенного хранилища.
Юридическая и журналистская защита
Журналисты, защищающие источники, адвокаты, защищающие дела клиентов, и активисты в авторитарных режимах сталкиваются со сценариями, где содержимое устройства может быть изъято принудительно. Настоящая отрицаемость обеспечивает правдоподобную защиту от изъятия данных.
Что Vaultaire реализует сегодня
Хранилище реализует доступ по шаблону и обычный интерфейс без видимого списка хранилищ. Эти свойства помогают при обычном использовании приложения, но они не отвечают всем требованиям приведенного выше контрольного списка подлинного отрицания.
Настроенные шаблоны открывают отдельные зашифрованные хранилища. PBKDF2 извлекает ключ хранилища из шаблона и соли для всего устройства. Настроенный ключ проверяет подлинность своего зашифрованного индекса и разворачивает случайный главный ключ. Ненастроенный шаблон отображает пустое состояние, а не сообщение «неправильный шаблон».
Локальный формат является перечислимым. Хранилище Вултер хранит один vault_index_<fingerprint>.bin файла на хранилище. Отпечаток пальца не раскрывает шаблон или имя хранилища, но кто-то, у кого есть доступ к контейнеру приложения, может подсчитать индексные файлы. AES-GCM аутентификация и детерминированное имя файла также обеспечивают автономную проверку потенциальных ключей хранилища.
Локальное хранилище не имеет постоянного размера. Содержимое файлов и метаданные зашифрованы, а фрагменты облачных резервных копий используют дополнения к размеру и ложные записи. Локальный контейнер приложения не резервирует фиксированный пул реальных и фиктивных слотов хранилища, поэтому общее количество хранилища и индексов может раскрыть структуру.
Существует состояние восстановления и принуждения. Vaultaire хранит информацию о восстановлении в AES-GCM зашифрованный Keychain база данных. Режим принуждения удаляет локальные индексы и сопоставления восстановления для хранилищ без принуждения и изолирует это устройство от синхронизации. Он не удаляет облачные резервные копии, копии на одноранговых устройствах или каждый общий зашифрованный объект, а время завершения зависит от выполненной локальной работы.
Таким образом, Vaultaire обеспечивает разделение интерфейсов и зашифрованное хранилище, а не теоретико-информационное доказательство отсутствия дополнительного хранилища. Будущий каталог фиксированной емкости с неотличимыми реальными и фиктивными слотами потребуется, чтобы скрыть количество локальных хранилищ из моментального снимка автономного контейнера приложений.
Как оценивать заявления об отрицаемости
Когда приложение заявляет о правдоподобном отрицании, спросите:
- Есть ли переключатель «режим-приманка»? Если да — это косметика. Криминалист может найти переключатель.
- Есть ли у приложения список или база данных хранилищ? Если да — существование хранилищ доказуемо.
- Можно ли проверить догадки в автономном режиме? Аутентифицированный зашифрованный текст может подтвердить потенциальный ключ без отдельного хэша пароля. Спросите, что ограничивает стоимость угадывания и предлагает ли схема хранения более дешевые отпечатки ключей.
- Меняется ли потребление хранилища с количеством хранилищ? Если да — анализ диска может оценить количество хранилищ.
- Может ли приложение перечислить хранилища? Если приложение показывает список хранилищ, этот список существует на устройстве и обнаружим.
Часто задаваемые вопросы
Является ли правдоподобное отрицание законным?
Использование шифрования с правдоподобным отрицанием законно в большинстве демократий. Закон не запрещает иметь зашифрованные данные на устройстве, существование которых нельзя доказать. В некоторых юрисдикциях (Великобритания по RIPA, Австралия по Assistance and Access Act) власти могут принудить к раскрытию ключей. Правовой вопрос о том, исполнимо ли принуждение к раскрытию ключа к данным, существование которых нельзя доказать, остаётся развивающейся областью права.
Могут ли криминалистические инструменты обнаружить правдоподобное отрицание?
Эксперт, получивший контейнер приложения Vaultaire, может обнаружить зашифрованное хранилище и подсчитать vault_index_*.bin файлы. В файлах не раскрываются имена хранилищ или содержимое открытого текста, но их подсчет показывает количество локальных зашифрованных индексов. Таким образом, нынешняя конструкция скрывает хранилища от обычной навигации, а не от каждой криминалистической проверки хранилища.
Работает ли правдоподобное отрицание против опытного государственного субъекта?
AES-256-GCM обеспечивает надежную границу шифрования контента, когда ключи, одноразовые номера и реализация верны. Это не делает текущую структуру хранилища Vaultaire недоступной для эксперта национального уровня: количество локальных индексов остается видимым, а живой взлом может быть нацелен на шаблоны, ключи, предварительный просмотр или экспорт, пока хранилище открыто. Текущая функция разделяет то, какие шаблоны открываются в интерфейсе; это не гарантирует, что решительный эксперт не сможет доказать существование дополнительных локальных индексов.
В чём разница между правдоподобным отрицанием и скрытыми хранилищами?
Скрытые хранилища — это хранилища, которые не видны в обычном интерфейсе приложения. Строгое криптографическое отрицание — это отдельное свойство, при котором скрытые данные невозможно отличить от неиспользуемого дополнительного хранилища. В настоящее время Vaultaire предоставляет первую недвижимость. Его формат «один индексный файл на одно хранилище» не обеспечивает второго для эксперта, имеющего доступ к контейнеру приложения.
Можно ли использовать правдоподобное отрицание с облачными резервными копиями?
Vaultaire записывает зашифрованные манифесты резервных копий и дополняет зашифрованные фрагменты файлов в личный кабинет пользователя. CloudKit база данных. Случайные имена записей, унифицированные типы записей, заполнение частями размером 10 МБ и ложные записи уменьшают прямое раскрытие содержимого. Количество записей, общий объем, время и шаблоны обновлений остаются видимыми метаданными службы, поэтому облачное резервное копирование не создает хранилище постоянного размера, теоретически отрицаемое для информации.
Итог
Строгое отрицание хранилища направлено на то, чтобы проверяющий не смог отличить скрытые данные от дополненного свободного места в статически зашифрованном хранилище. Большинство приложений, заявляющих об этой функции, предлагают косметические режимы-приманки с обнаруживаемыми флагами конфигурации. Для соответствия более строгому определению требуется точная модель угроз, отсутствие исчисляемого реестра хранилищ, отсутствие раскрытия флагов конфигурации, стабильное заполнение и зашифрованные записи, которые не раскрывают, какие слоты являются реальными.
Хранилище использует настроенные шаблоны для разделения зашифрованных хранилищ и не допускает попадания имен и содержимого хранилищ в заблокированный интерфейс. Текущая структура хранилища по-прежнему предоставляет счетчик зашифрованных индексов для проверки контейнера приложения. Считайте это сокрытием на уровне интерфейса, подкрепленным аутентифицированным шифрованием, а не доказательством отсутствия дополнительного хранилища.