Кратко

  • CMS AuthEnvelopedData может правильно указывать AES-GCM, содержать допустимые параметры и пройти проверку тега, не доказывая, что такая пара ключ/nonce никогда не встречалась в другом объекте.
  • Поэтому RFC 5084 требует автоматизированного управления ключами и называет безопасной конструкцией свежий CEK для каждого содержимого; поддержка алгоритма не подтверждает этот жизненный цикл.

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

RFC 5084 задаёт применение AES-CCM и AES-GCM в CMS AuthEnvelopedData. Она назначает OID для трёх размеров ключа AES, требует параметры, определяет длины ICV и использует аутентифицированные атрибуты CMS как дополнительные аутентифицируемые данные.

Уникальность определяется в области одного ключа. Множество nonce, использованных с данным ключом аутентифицированного шифрования содержимого, не должно иметь повторов. Повтор пары для разных сообщений разрушает свойства безопасности. Текущий объект показывает свой nonce, но ничего не знает о другом процессе, регионе или старом снимке.

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

RFC 5084 требует автоматизированную систему управления ключами. Она перечисляет транспорт и согласование ключа, симметричные ключи шифрования ключей и ключи, выведенные из пароля. Каждый способ удовлетворяет требованию, если для каждого содержимого создаётся новый ключ аутентифицированного шифрования содержимого — CEK.

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

Параметры объекта обладают собственной проверяемой силой. GCMParameters содержит nonce и длину ICV от двенадцати до шестнадцати октетов; двенадцать — значение по умолчанию и рекомендация. Длина должна совпадать с mac. В CCM nonce занимает от семи до тринадцати октетов, а ICV — чётное число от четырёх до шестнадцати, с рекомендацией двенадцать. Длина nonce CCM связана с доступным размером поля длины содержимого.

Парсер обязан отклонить отсутствующие параметры, невозможные значения и несоответствие длины. Успех подтверждает кодирование одного объекта, но не качество генерации CEK, локальную политику риска и состояние второго отправителя.

RFC 5083 определяет контейнер. В RFC 5084 аутентифицированные атрибуты становятся AAD: они защищены от изменения, но не скрыты. Тег охватывает их и зашифрованное содержимое. Неаутентифицированный атрибут не получает полномочий только потому, что находится рядом.

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

Интерфейс AEAD из RFC 5116 принимает ключ, nonce, открытый текст и связанные данные. Алгоритм не просматривает внешнюю историю. NIST SP 800-38D также считает уникальность IV критическим эксплуатационным условием GCM.

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

После восстановления счётчик может отстать при сохранённом CEK. Новый объект отдельно проверяется, хотя его пара уже была использована. Возможна и обратная ошибка: разные свежие CEK имеют одинаковые nonce, а монитор без идентичности ключа сообщает ложный конфликт. Область сравнения должна совпадать с настоящей эпохой ключа.

Восстанавливаемая цепочка отдельно хранит байты CMS; OID и параметры; эпоху CEK или запись свежей генерации; выдачу nonce; точные атрибуты и AAD; шифротекст и тег; получателя и способ управления ключом; результаты разбора, открытия ключа и проверки; исторический поиск; разрешение на выдачу текста; прикладную авторизацию и результат.

Это эксплуатационная рекомендация, а не новая синтаксическая норма RFC 5084. В дисциплине слоёв реальности Heng Lu имя алгоритма, объект, тег, историческая уникальность и деловое решение — соседние, но разные записи.

Источники