Кратко

  • В версии 00 раздел 6.3 допускал четыре сообщения, но ID_CRED_I передавался открыто уже в первом. Авторы прямо указывали на потерю защиты личности инициатора. В сентябрьской версии 01 этот раздел отсутствует.
  • Текущий проект требует пять сообщений. Для отвечающей стороны подтверждение инициатора и вывод прикладных ключей наступают после проверки сообщения 5, а не после получения сообщения 4 другой стороной.
  • Значение метода «5» пока лишь предложено. Сам по себе KEM-метод не означает защиту от квантового противника: требуется подходящий постквантовый KEM и соответствующий набор алгоритмов.

У новой редакции примечателен не добавленный термин, а удалённый компромисс. Июльский Internet-Draft описывал, как инициатор мог отправить ID_CRED_I в незашифрованном message_1. Тогда отвечающая сторона получала сведения о его статическом ключе раньше и протокол мог закончиться на четвёртом сообщении. В тексте прямо оговаривалась цена: идентификатор инициатора переставал быть скрытым. Это была предложенная конструкция на бумаге, а не опубликованные данные об утечке или внедрении в устройствах.

Редакция 01 датирована 28 сентября и не содержит прежнего раздела о четырёх сообщениях. Она перечисляет message_1, message_2, message_3, message_4_KEM и message_5_KEM как обязательные. Пятисообщный механизм был и в версии 00, поэтому неверно объявлять его сентябрьским изобретением. Зафиксированное изменение уже: из нынешнего документа убрали короткую ветку с указанной потерей приватности. Причина удаления неизвестна; из него нельзя выводить общий запрет или техническую невозможность иных четырёхсообщных протоколов.

Дополнительный шаг объясняется зависимостью доказательства владения ключом. В KEM владелец статического закрытого ключа должен получить шифртекст, инкапсулированный для соответствующего открытого ключа, прежде чем доказать владение секретом. Проект допускает из-за этого до одного дополнительного обмена туда и обратно. Сообщение 4 подтверждает ключ отвечающей стороны перед инициатором; сообщение 5 подтверждает инициатора перед отвечающей стороной. Инициатор может вывести прикладные ключи после обработки четвёртого и создания пятого сообщения. Отвечающая сторона ждёт проверки пятого.

Одинаковая метка «обмен завершён» в журналах обоих устройств скрыла бы разные условия завершения.

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

Изменился и объём обращения к IANA. Ранняя версия предлагала номера для алгоритмов ML-KEM в COSE, наборов шифров EDHOC и типа аутентификации. Раздел 7 версии 01 оставляет лишь предполагаемое значение типа метода «5» и ссылается на отдельные проекты по представлению KEM и квантово-устойчивым наборам LAKE. Это не свидетельствует ни о состоявшемся назначении номера, ни об утверждении тех проектов. Сам метод не привязан к одной KEM-конструкции; заявлять квантовую стойкость можно только с учётом конкретной постквантовой реализации.

При испытании ограниченных устройств стоит проверять, когда раскрываются данные удостоверения, что реально выбрано при согласовании алгоритмов, что знает каждая сторона после четвёртого и пятого сообщения и как обрабатывается обрыв. Это вопросы для оценки, предложенные Daniel Kade, а не новая обязательная форма отчёта IETF. Рабочий Internet-Draft не даёт сведений о внедрении, измеренной задержке или произошедших атаках.

Источники