Кратко

  • Revision 01 позволяет Initiator аутентифицировать Responder только после проверки message_4_KEM; Responder аутентифицирует Initiator после message_5_KEM.
  • Третье сообщение может быть конфиденциальным и целостным, но не аутентифицировать Initiator. Финальный ключ приложения должен ждать взаимной аутентификации, целостности transcript, подлинности credentials и доказательства владения ключом.

В середине обмен уже похож на завершённый

После третьего сообщения панель управления получает множество признаков успеха. Эфемерный KEM дал общий секрет. Initiator проверил credential Responder, создал encapsulation для его статического открытого ключа и передал собственный credential в защищённом ciphertext. Responder смог выполнить decapsulation и расшифровать данные.

Такое подтверждение преждевременно.

Revision 01 документа KEM-based Authentication for EDHOC, поданная 28 сентября 2026 года, прямо говорит: ключ защиты сообщения 3 не аутентифицирует Initiator. Responder ещё не отправил MAC, который подтвердит его самого; MAC Initiator тоже отсутствует. Владельцу статического KEM-ключа сначала нужна encapsulation, созданная peer для соответствующего public key, и только затем он способен подтвердить владение private key. Отсюда две дополнительные передачи.

Datatracker показывает активный Internet-Draft рабочей группы LAKE со статусом IESG лишь I-D Exists. Текст нацелен на Standards Track, но не является RFC, утверждённым стандартом или свидетельством реализации. Без замены или продвижения версия истечёт 1 апреля 2027 года.

У двух направлений разные границы

Сообщение 1 несёт эфемерный KEM public key. Responder создаёт для него encapsulation и возвращает в сообщении 2 ciphertext и идентификатор своего credential. Перед раскрытием собственных данных Initiator должен получить credential Responder, проверить его и принять по локальной политике. Криптографически верный документ всё ещё может принадлежать недоверенной или непредусмотренной стороне.

В сообщении 3 Initiator выполняет encapsulation к статическому ключу Responder и защищает свои credential-данные. Успешная decapsulation не закрывает привязку личности. Явный MAC Responder приходит в message_4_KEM. После его проверки Initiator может аутентифицировать peer и сохранить PRK_out либо application keys.

Обратное направление остаётся открытым. Responder аутентифицирует Initiator после проверки MAC в message_5_KEM. Проект признаёт, что misbinding может не обнаружиться до этих двух финальных проверок. До завершения EAD следует считать незащищёнными, а keying material не сохранять постоянно.

Один флаг authenticated=true стирает интервал, когда один узел уже проверил peer, а другой ещё нет. Успешная decapsulation также не отвечает, к какой личности, trust policy, transcript и прикладному разрешению относится секрет.

Постквантовый алгоритм тоже требует свежести

Key schedule объединяет свежий эфемерный вклад с двумя секретами от статических KEM-ключей. Для каждой сессии нужны новые encapsulations. ss_I, ss_R и соответствующие ciphertext нельзя использовать повторно. Кроме IND-CCA2, KEM обязан криптографически связывать derived secret с public key получателя: одного IND-CCA2 недостаточно против re-encapsulation и unknown key-share.

RFC 9935 и FIPS 203 определяют ML-KEM, но не полномочия организации. SP 800-227 описывает безопасное применение KEM; RFC 9528 остаётся базой EDHOC. Новый проект предлагает transcript, credentials и точки проверки LAKE, а не результаты внедрения, совместимости или производительности.

Он также исключает non-repudiation: метод даёт лишь неявное доказательство участия. Аутентифицированный LAKE peer не получает автоматически права менять маршрут, устанавливать ПО, переводить деньги или управлять устройством. Операционный ledger должен отдельно хранить method и suite, локальную проверку credential, состояния сообщений 2–5, результаты MAC_2 и MAC_3, несекретный идентификатор freshness, переход к сохранению ключей, авторизацию, защищённые запрос и ответ и конечный эффект.

Предыдущий материал BTW о RFC 9668 рассматривал иной рубеж: объединение EDHOC message 3 с первым OSCORE request не доказывает выполнение приложением. Здесь граница раньше. В KEM-варианте третье сообщение ещё не завершает саму аутентификацию.

Running-Code Primacy требует реально оборвать сообщения 4 и 5, повторить encapsulation, заменить credentials и проверить оставшееся состояние. Minimum Initial Specification поддерживает узкий общий инвариант — явные состояния завершения и freshness на сессию — при локальной trust policy. Reality Layers не позволяет владению ключом, доверенной личности, авторизации и результату подменять доказательства друг друга.

Источники