CMAC почему K1 и K2

Question

http://en.wikipedia.org/wiki/CMAC

http://www.rfc-archive.org/getrfc.php?rfc=4493

Есть две клавиши К1 и К2. Существуют ли другие причины, кроме того, что сообщения 1 отличаются от 10^127 (1 и 127 нулей)

Если сообщение имеет длину (а длина также является сообщением с разрешением CMAC), существуют ли какие-либо недостатки безопасности, использующие только один случайно сгенерированный K?

Answer 1

Я не верю, что это имеет отношение к атакам с использованием открытого текста, и я не согласен с симметричными шифрами, которые восприимчивы к ним. Одно из условий защищенности шифра заключается в том, что он защищен при KPA, CPA (атаки с использованием выбранного открытого текста) и CCA (атаки с использованием выбранного шифрованного текста).

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

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

Вы можете прочитать статью XCBC, чтобы увидеть, как работает атака:

"В качестве простого примера обратите внимание, что, учитывая CBC MAC для одноблочного сообщения X, скажем, T = CBCEK(X), злоумышленник немедленно знает CBC MAC для двухблочного сообщения X || (X ^ T), так как это еще раз Т. "

[1] http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf

Answer 2

Прежде всего, в AES-CMAC действительно есть только один ключ K - это единственный, который вы должны сгенерировать, чтобы ответить на ваш последний вопрос, и это явно указано в спецификации:

Алгоритм генерации подключа, Generate_Subkey(), принимает секретный ключ K, который является просто ключом для AES-128.

Другой ваш вопрос - зачем нам генерировать K1 и K2 из K - ответить немного сложнее, но на самом деле есть очень простое объяснение: устранить любую двусмысленность в аутентификации сообщений.

Для иллюстрации предположим, что мы берем двоичные ключи из статьи в вики: K1 = 0101 и K2 = 0111. Теперь давайте поиграем с сообщением M = 0101 011. Поскольку M не состоит из полных блоков (три бита, а не четыре), мы должны дополнить это. Теперь у нас есть M ' = 0101 0111.

Чтобы сгенерировать MAC для этого сообщения, мы просто должны XOR наши ключи в:

M'  = 0101 0111
K1  = 0101
K2  =      0111
MAC = 0000 0000

Если бы мы использовали K1 в обоих случаях, то у нас была бы следующая процедура:

M'  = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

Это все хорошо, но посмотрите, что произойдет, когда мы попытаемся сгенерировать MAC для M'' = 0101 0111 (то есть незаполненное сообщение M'', идентичное дополненному сообщению M ').

M'' = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

Мы создали один и тот же MAC из двух разных сообщений! Использование второго ключа (который обладает некоторыми теоретико-числовыми свойствами, которые мешают его проблемному "сходству" с K1) предотвращает такую ​​неоднозначность.

Answer 3

Я полагаю, что симметричные шифры подвержены атакам с использованием открытого текста, по крайней мере, так было в прошлом. А так как вы делаете часть открытого текста (шаблон заполнения), вы не хотите пропускать информацию о вашем ключе. Если вы можете извлечь некоторые биты ключа таким образом, вы сможете атаковать методом грубой силы последний блок, но все остальные блоки остаются защищенными (по крайней мере, под этой атакой KP), поскольку они были зашифрованы с помощью K1.

Чтобы преодолеть ту же самую проблему, блочные шифры обычно работают в различных режимах, см.: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation. Не знаю, почему это очевидное решение не было учтено при разработке CMAC.