Кратко

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

Самый тихий сбой выглядит последовательно

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

draft-ietf-keytrans-architecture-09 прямо описывает эту границу. В Datatracker IETF документ числится активным Internet-Draft. Редакция 09 опубликована 29 июня 2026 года, процесс обновлен 9 июля. Состояние рабочей группы — Submitted to IESG for Publication, состояние IESG — Publication Requested, предполагаемый статус — Informational, дата telechat не назначена. Это не одобренный RFC и не окончательный текст.

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

Key Transparency помещает такие связи в криптографически защищенный журнал только для добавления. Search возвращает значение метки и доказательство, Update добавляет версию, Monitor периодически подтверждает сохранность прежних значений и отсутствие скрытых изменений метки владельца. Общий механизм координирует проверяемую историю, а не всю политику приложения.

Недобросовестный журнал способен показывать Анне одну историю, Борису — другую. Каждый клиент требует, чтобы следующий ответ согласовывался с сохраненной вершиной. Он остается на линейной ветви и отвергает будущие противоречия. Развилку нельзя незаметно слить обратно, поэтому доказательство сохраняется. Но без сравнения обе группы могут видеть только успешные проверки.

Сравнение — отдельная функция безопасности

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

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

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

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

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

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

Потеря состояния стирает точку сопоставления

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

Архитектура рассматривает потерю состояния как самостоятельный риск. В Contact Monitoring особенно чувствительны новые значения внутри окна наблюдения и недостаточно распространенные участки. При внешнем аудите уязвимый интервал связан с допустимым отставанием аудитора. Эфемерная веб-сессия, замена телефона, неполная резервная копия или навязанная перезагрузка меняют гарантию без изменения алгоритма проверки.

Восстановление учетной записи должно определять, что переносится: последняя принятая вершина, незавершенные задачи Monitor, подписи свидетелей, время сравнений и идентификатор конфигурации журнала. Если непрерывность не доказана, разрыв надо записать и передать локальной политике восстановления, а не объявлять устройство новым и лишенным прошлого.

Срок выявления складывается из нескольких ограничений: максимально допустимой давности ответа, Reasonable Monitoring Window, реальной частоты фоновой проверки, интервала анонимных запросов или обмена, задержки аудитора и эффективности контроля управляющего. Пользователь иногда должен оставаться в сети достаточно долго. Фраза об обнаружении за ограниченное время проверяема только тогда, когда каждая граница измеряется и имеет владельца.

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

Прозрачность не отменяет права доступа

Key Transparency оставляет транспорт и большую часть авторизации приложению. Сервис может требовать вход, разрешать поиск только контактов, ограничивать частоту и запрещать изменение чужих меток. Журнал доказывает выполнение разрешенной операции, но не выдает разрешение.

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

Режимы раскрывают разную информацию. Аудитор узнает число, порядок и примерное время изменений, но не открытый текст меток и значений. Управляющий обычно видит метки, значения, историю и запросы, известные оператору. Анонимный путь нуждается в защите метаданных. Обмен между участниками может показать связи и встречи. Свидетеля без информационного следа не существует.

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

Миграция не должна выключать старое доказательство

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

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

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

Обнаруженная развилка дает улику, а не универсальную команду

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

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

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

Источники