Кратко

  • RFC 9678 определяет необязательное аутентифицированное расширение ECDHE для EAP-AKA', включая X25519 и P-256 и влияние общего секрета на K_re, MSK и EMSK.
  • Позднее получение долговременного ключа не должно раскрывать завершённые защищённые сеансы лишь при условии, что весь относящийся к ним ключевой материал был удалён.
  • Практическое доказательство связывает политику и transcript с потребителем ключа, событием завершения, перечнем копий, квитанциями уничтожения и независимой попыткой восстановления.

Испытание начинается после компрометации

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

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

Именно ретроспективная проверка показывает границу между протоколом и эксплуатацией. RFC способен определить, как создать независимый секрет. Он не может заставить все системы забыть его производные.

Что стандартизировано

RFC 9678 опубликован в марте 2025 года как Proposed Standard. Он обновляет RFC 9048 и предшествующий RFC 5448. Основа EAP-AKA' — долговременный симметричный секрет на стороне абонента и домашней сети. Без дополнительного временного вклада злоумышленник может сохранять обмены, а после будущей компрометации этого секрета пытаться восстановить старые сеансовые ключи.

Расширение вводит Elliptic Curve Diffie-Hellman. Сервер отправляет один или несколько вариантов AT_KDF_FS и публичное значение в AT_PUB_ECDHE. Клиент выбирает поддерживаемый вариант по правилам RFC и возвращает собственное значение. IANA закрепила за атрибутами типы 152 и 153; исходно определены X25519 и P-256.

Новые атрибуты защищены AT_MAC, основанным на существующей аутентификации AKA'. Сторонний наблюдатель не может незаметно подменить публичное значение или выбор KDF и сохранить корректный transcript. Общий секрет участвует в получении MK_ECDHE, а далее — K_re, MSK и EMSK.

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

Один результат доступа скрывает разные истории

Расширение необязательно. Устройство, которое его не поддерживает или не выбирает, может продолжить обычный EAP-AKA', если политика разрешает. Если прямая секретность обязательна, отсутствие общего варианта должно привести к отказу.

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

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

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

Условие удаления сформулировано прямо

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

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

Понятие завершения также распределено. EAP может закончиться раньше канального соединения. Туннель может ещё использовать производный материал. Мобильность может оставить перекрывающиеся контексты. База абонентов и шлюз могут применять разные таймеры.

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

Повторная аутентификация опирается на прошлое

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

Новый Diffie-Hellman при этом не выполняется. Недавнее событие доступа может зависеть от старого полного обмена и долго хранимого K_re. Возраст контекста, число повторов и условие обязательной полной аутентификации должны быть частью журнала.

Называть каждую повторную аутентификацию «свежим ECDHE» значит приписывать протоколу несуществующий шаг. Правильная связь ведёт к исходному полному сеансу и его жизненному циклу.

Куда ушли MSK и EMSK

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

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

Как построить проверяемую цепочку

Сначала фиксируются политики обеих сторон: расширение обязательно, предпочтительно или опционально; fallback разрешён или нет. Затем — версии реализации, поддерживаемые варианты, порядок предложения, выбор, публичные значения и проверка AT_MAC.

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

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

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

Минимальная спецификация и работающая система

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

В логике Heng Lu код IANA относится к координации, аутентифицированный transcript — к протоколу, байты в памяти — к работающему коду, ассоциация доступа — к эксплуатации, тест восстановления — к доказательству. Фраза «прямая секретность включена» стоит над ними и не должна стирать различия.

RFC 9678 делает важную часть системы сильнее. Честная эксплуатация не требует от него невозможного дистанционного доказательства памяти. Она добавляет собственные квитанции там, где заканчивается протокол.

Источники