Кратко

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

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

RFC 5275 — стандарт IETF 2008 года о распределении симметричных ключей с помощью CMS. Его параметры нельзя автоматически принимать за современную рекомендацию по развёртыванию, но логика полномочий остаётся точной. При удалении человека из закрытого или управляемого группового списка группу необходимо перевести на новые ключи. Без этого бывший участник всё ещё обладает общим ключом и способен расшифровать полученный им защищённый материал.

Решение владельца и действие агента

Владелец группового списка, GLO, создаёт список, выбирает режим управления и определяет членство и политику смены ключей. Агент списка, GLA, реализует функции управления группой и ключами и подписывает сообщения glKey, доставляющие общие KEK.

Такое разделение ролей не устраняет необходимость проверки. Сам RFC отмечает, что скомпрометированный GLA способен причинить ущерб. Полномочие роли объясняет, почему ей разрешено выполнить переход. Оно не доказывает, что все зависимые системы действительно перешли.

Подписанный glDeleteMember — это распоряжение об удалении. В зависимости от модели его направляет владелец или сам участник. Для управляемого и закрытого списка необходимо также убедиться, что тот же субъект не зарегистрирован дважды. Иначе одна запись исчезнет, а вторая продолжит получать следующие ключи.

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

У смены ключа несколько моментов завершения

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

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

Отправка не равна получению, а получение — использованию. Даже подписанный ответ агента об успехе описывает состояние обработки у агента, а не память каждого конечного устройства. Он также не доказывает уничтожение копий на неподконтрольном устройстве. Универсального удалённого доказательства стирания RFC 5275 не предлагает.

Произведение поколения и срока

generationCounter задаёт число выдаваемых или ожидающих ключей, duration — срок каждого из них. Изначально распространяется не менее двух KEK, чтобы истечение первого не остановило группу.

В разделе безопасности приведён намеренно крайний пример: четырнадцать ключей сроком на год дают злоумышленнику как минимум тринадцать лет для атаки на последний ключ. Это не рекомендуемая настройка, а демонстрация длинного хвоста заранее выданного полномочия.

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

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

Подписи нужна сохранённая история

Участник, хранящий KEK, должен связать его с именем GLA, который этот ключ распространил. Тогда последующую смену можно проверить как исходящую от той же сущности. Корректная подпись без такой связи может относиться не к той группе или не к той последовательности поколений.

Nonce и signingTime также работают против повтора только при наличии сохранённого состояния для сравнения. Часы расходятся, допустимое окно определяет локальная политика, а сообщения со временем в будущем требуют явной обработки. Метка времени без памяти не доказывает свежесть.

Новый рубеж не стирает старые копии

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

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

Каким должен быть документ о выходе

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

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

Список сообщает, кому полагается способность. Работающие системы показывают, у кого она осталась. Исключение становится реальностью только после доказанной границы, на которой эти два слоя снова совпадают.