Кратко

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

Ротация, которая только добавила поколение

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

RFC 5295 оставляет EMSK внутри EAP-узла и сервера и использует его для получения корней с определённым назначением. USRK вычисляется из EMSK, метки, нулевого разделителя, необязательных данных и длины выхода. Разделитель устраняет неоднозначность префиксов, а одинаковые входы детерминированно дают одинаковый результат.

Формула гарантирует разделение значений. Она не инвентаризирует места, где старое значение всё ещё наделяет правом.

Метка задаёт координаты объекта

Каждому назначению нужна отдельная согласованная метка — печатаемая и чувствительная к регистру. Необязательные данные связывают дополнительный контекст. Имя USRK может использовать EAP Session-ID вместе с той же меткой и контекстом, позволяя ссылаться на корень без раскрытия материала.

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

В квитанции нужны Usage ID, точные байты метки, разделитель, хеш необязательных данных, длина, версия KDF, EAP Session-ID, имя EMSK и полученное имя ключа. Записи «успешно» недостаточно для воспроизведения выбора.

Домен ограничивает возможность дальнейшего вывода

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

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

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

Срок родителя должен проходить через всю ветвь

Корневой ключ не может жить дольше EMSK. После истечения EMSK его корни выводятся из использования; после нового обмена EAP новые корни следует применять как можно скорее. Необходимость одновременной замены детей определяется конкретным назначением.

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

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

Интерфейс корней обязан проверять вызывающую сторону

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

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

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

Защищённая доставка должна нести ограничения

Для передачи корней RFC требует конфиденциальности и целостности, аутентифицированных и авторизованных сторон, а также контекста, который идентифицирует ключ и ограничивает его использование, включая срок. Конкретный транспортный протокол не задан.

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

Дочерний ключ не сильнее родителя

Стойкость вывода не превышает стойкости EMSK или внутреннего master key метода EAP. Дополнительные метки не создают энтропию. Когда один корень питает множество детей, протоколу может потребоваться свежая случайность от участников.

Разветвлённая архитектура помогает реализовать минимальные привилегии, но не исправляет слабого родителя, неоднозначное имя или слишком широкого получателя.

Полная квитанция жизненного цикла

Для каждого использования сохраните связь с EAP-сессией, именем EMSK, Usage ID, меткой и хешем контекста, KDF и длиной, доменом, именами корня и ребёнка, родословной, созданием и истечением, индексом кэша, заменой и выводом, вызывающей стороной, участниками доставки, каналом, установленным поколением, подтверждением дочернего протокола и последующим результатом доступа.

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

Sources