Кратко

  • RFC 9709 передаёт в HKDF полную DER-кодировку внутреннего AlgorithmIdentifier, включая параметры, вместе с исходным ключом шифрования содержимого.
  • Замена аутентифицированного режима на CBC или изменение параметра даёт иной ключ, а не полезный оракул открытого текста.
  • Мера защищает конфиденциальность от такого преобразования, но не подтверждает отправителя, безопасность содержимого или право на последующее действие.

Целью становится интерпретация

В атаке, исследованной LAMPS, ключ не извлекают. Посредник перехватывает CMS-данные под AES-GCM или AES-CCM и представляет выбранные блоки как AES-CBC. Если система с ключом обрабатывает подмену и выдаёт результат, ошибку либо наблюдаемое поведение, атакующий получает возможность проверять догадки о структурированном блоке с низкой энтропией.

Это не универсальная расшифровка. В материалах IETF 118 отмечалось, что S/MIME часто выдаст очевидный мусор, заголовок может быть отвергнут заранее, а реально уязвимые системы были неизвестны. Но это свойства приложений, не криптографическая гарантия. Просмотрщик, конвертер, квитанция или автоматический процесс могут дать сигнал, которого нет в почтовом клиенте.

RFC 9709 превращает описание алгоритма во вход безопасности. Поддерживающий получатель объявляет id-alg-cek-hkdf-sha256 в S/MIME Capabilities без параметров. При выборе защиты отправитель помещает этот OID во внешний contentEncryptionAlgorithm. Его обязательный параметр несёт настоящий внутренний AlgorithmIdentifier: шифр содержимого и его параметры.

Затем обе стороны выводят рабочий CEK-prime через HKDF-SHA-256. Исходный CEK служит секретным входным материалом, фиксированная ASCII-строка “The Cryptographic Message Syntax” — солью, а полный DER внутреннего идентификатора — полем info. В него входят тег и длина SEQUENCE, OID и закодированные параметры. Выход имеет длину исходного ключа с пределом 8 160 байт.

Защиту обеспечивает побайтовая точность. Замена GCM на CBC, смена вектора инициализации или параметра меняет info, а значит, и ключ. Шифротекст для исходного ключа перестаёт быть полезным опытом при выбранной атакующим интерпретации. Если внешний OID удалить целиком, получатель применит исходный CEK вместо CEK-prime. Доступ к сообщению пропадёт, но открытый текст не появится: отказ в доступе вместо нарушения конфиденциальности.

Не сводить цепочку к одному «успеху»

Эксплуатационный журнал должен раздельно хранить: объявленную возможность; внешний OID; внутренний алгоритм и параметры; DER-байты, поступившие в HKDF; результат аутентифицированного расшифрования и проверки связанных данных; любой текст, результат разбора или сигнал за границей доверия; правило, разрешившее хранение, отображение или действие.

Одна отметка «расшифровано» не отличает несовместимость от вмешательства. Успешный разбор также не доказывает авторство. RFC 9709 разделяет ключи, но не заменяет подпись, репутацию отправителя, проверку содержимого или деловое разрешение.

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

Узкое общее правило

Конструкция фиксирует SHA-256 и не вводит согласование KDF; будущему хешу потребуется новый OID. Общий механизм остаётся детерминированным: распознать внешнюю оболочку, сохранить точную внутреннюю кодировку, вывести ключ, затем выполнить внутренний алгоритм.

Обычные требования не исчезают. CEK должен создаваться качественным генератором и защищаться. RFC 5652, RFC 5083, RFC 5084, RFC 5869, RFC 8551 и RFC 4086 остаются самостоятельными основаниями. RFC 9709 не исправит слабый ключ, скомпрометированный узел или ложную личность.

На момент проверки поиск RFC Editor не показывал зарегистрированных исправлений к RFC 9709, а реестр SMI IANA содержал выделенные идентификаторы. Это подтверждает формальный статус, но не внедрение.

Источники