Кратко

  • В MLS все участники группы могут вычислять AEAD-ключи цепочек отправки данной эпохи. Успешное открытие шифротекста подтверждает групповую возможность, но не выбирает конкретного клиента.
  • Индивидуальная подпись даёт более сильное свидетельство источника. Привязка личности, право на действие, доставка и реальный эффект требуют отдельных подтверждений.
  • Новая эпоха важна для криптографического состояния, но не является автоматическим актом закрытия инцидента. Нужно назвать скомпрометированный секрет и проверить удаление, отзыв, сходимость и восстановление приложения.

Два клиента получают разные последовательности Commit, но оба способны открыть часть сообщений. Для одного оператора зелёная проверка означает, что история верна. Для другого — что известен отправитель. Руководитель читает её как подтверждение доставки. Разветвление Delivery Service уже изменило состояние системы, однако один и тот же индикатор скрывает все различия.

RFC 9750 описывает архитектуру Messaging Layer Security и проводит первую границу. Участники имеют групповые секреты и способны вычислять AEAD-ключи для всех цепочек отправки в эпохе. Поэтому аутентификация общего фрейминга слаба в строго определённом смысле: успешная расшифровка гарантирует лишь, что сообщение создал кто-то из группы либо атакующий, получивший соответствующий AEAD-материал. Она не указывает единственного клиента.

Алгоритм здесь выполняет обещание. Общая возможность порождает свидетельство о классе возможных создателей. Имя появляется только тогда, когда система добавляет отдельный источник данных или необоснованный вывод.

Подпись создаёт другое свидетельство

Согласно RFC 9420, каждое сообщение несёт цифровую подпись. Для участника проверяется ключ из LeafNode по указанному индексу листа. Подпись охватывает содержание, сетевое представление и GroupContext текущей эпохи. Тем самым она связывает сообщение с конкретной возможностью подписи в конкретном состоянии группы.

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

Журнал должен отдельно хранить открытие AEAD, принятую эпоху и генерацию, решение о повторе, индекс листа и проверку подписи. Одно поле «аутентифицировано» стирает разницу между общей и индивидуальной компрометацией именно тогда, когда она необходима для расследования.

RFC 9750 рекомендует отдавать приоритет защите закрытых ключей подписи и обсуждает аппаратные модули или защищённые среды. Часто меняющиеся групповые секреты не всегда можно охранять тем же способом. Разумная политика учитывает не общее слово «ключ», а жизненный цикл, способ вызова и последствия злоупотребления.

Клиент ещё не человек и не должность

MLS оперирует клиентами. У одного пользователя может быть несколько устройств и ключей подписи. Authentication Service выпускает удостоверения, проверяет связь эталонного идентификатора с ключом и решает, относятся ли два удостоверения к одному клиенту. Это отдельное решение доверенной стороны, а не побочный эффект подписи.

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

Авторизацию задаёт приложение. RFC 9750 прямо говорит, что MLS не обеспечивает контроль доступа к групповым операциям самостоятельно. Политика должна определять, кто добавляет и удаляет участников, утверждает содержание и меняет административное состояние. Proposal описывает изменение, Commit меняет состояние. Ни один объект не является сам по себе протоколом законного человеческого согласования.

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

Доставка имеет собственную историю

Delivery Service маршрутизирует сообщения и распределяет начальный ключевой материал. Он может давать строгий порядок или итоговую согласованность. Он способен задерживать и подавлять данные, показывать разным клиентам разные допустимые истории, вызывать расхождение по текущей эпохе или выбранному Commit. MLS стремится не позволить скомпрометированному сервису читать содержание или подделывать приемлемые клиентские сообщения, но доступность и сходимость не следуют из этого автоматически.

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

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

Восстановлению требуется название секрета

Фраза «ключи сменили» не указывает объект ремонта. Компрометация ratchet-секрета может раскрыть текущие и будущие AEAD-ключи цепочки в эпохе, сохраняя защиту корректно удалённых прошлых ключей. Более широкая компрометация группы может открыть шифрование и расшифровку в затронутых эпохах. Компрометация подписи меняет риск атрибуции и требует отдельной работы с удостоверениями.

После пассивной компрометации честный Commit, сделанный после устранения причины, может перевести группу к новым секретам при выполнении условий post-compromise security. Если злоумышленник остаётся активным участником, задача сложнее: удаление скомпрометированной стороны восстанавливает секретность будущих эпох, когда остальные участники честны.

Даже тогда новая эпоха — криптографическое свидетельство, а не акт закрытия. Нужно подтвердить удаление или обновление клиента, отзыв нужных удостоверений, правильный ввод замены, восстановление политики и сходимость получателей. Формулировка «после удаления клиента C группа перешла в эпоху E+1» уже и проверяемее, чем «безопасность восстановлена».

Восемь ступеней доказательства

Практическая цепочка задаёт отдельные вопросы. Был ли разобран шифротекст и открыт AEAD? Приняты ли эпоха, генерация и защита от повтора? Проверена ли подпись указанного участника или разрешённого внешнего отправителя? Соответствует ли удостоверение ожидаемому эталонному идентификатору? Являлся ли клиент текущим участником? Разрешала ли политика именно эту операцию? Дали ли сервис и получатели нужные квитанции доставки и обработки? Наблюдался ли человеческий или деловой результат независимо?

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

RFC 9750 имеет статус Informational, а RFC 9420 — Standards Track. Документы не доказывают реализацию в названном продукте, фактическую атаку или измеренный результат. Их ценность — в языке границ: вывод сохраняет масштаб механизма, который его породил. Такой язык улучшает требования, расследования и решения руководства.

Источники