Шифрование ключей: нужна ли аутентификация?

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

Она шифрует файлы ключами $k_i$ соответственно и получается $c_i := Enc_{k_i}(m_i) $. Она также шифрует ключи как $k'_i := Enc_k(k_i)$ и отправляет кортежи $(k'_i,c_i)$ Бобу хранить.

Кажется вполне естественным, что режим шифрования, используемый для $c_i$ быть аутентифицированным шифрованием. Но для $k'_i$, из-за высокой энтропии полезной нагрузки и того факта, что они используются только для расшифровки аутентифицированного шифрования, кажется, что шифрование $Enc_k(k_i)$ не нуждается в аутентификации.

Это правда? Если да, то каков более формальный и последовательный аргумент в его пользу? Если нет, то какую атаку позволяет это расслабление?

Если бы шифр AEAD мог быть проверен, когда неправильный ключ был использован случайный ключ, тогда я думаю, что шифр будет считаться небезопасным. Таким образом, я думаю, что исключение ключа в расчете будет иметь большое значение.

С другой стороны, крайне маловероятно, что входной AD будет обрабатываться как ключ в блочном шифре. Таким образом, включение его в AD также не должно сделать большинство алгоритмов небезопасными. Однако я все еще немного беспокоюсь о внутреннем алгоритме MAC; может быть, существует какое-то странное математическое соотношение, которое можно использовать; Я не думаю, что есть какие-то особые требования, чтобы избежать этого.

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

Итак, какие еще есть варианты:

1. Включите зашифрованный текст упакованного ключа в качестве данных AEAD. Таким образом, ключ имеет двойную защиту. Однако, если вы используете неправильный режим (например, режим счетчика), злоумышленник может внести побитовые изменения в ключ. и дополнительные данные, которые могут меня немного смутить. Поэтому я бы использовал режим переноса ключей, разработанный для этой цели. в этом случае или вернуться к CBC с нулевым IV (yuk). Это не должно давать злоумышленнику большого контроля над значением ключа.

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

Вывод: меня больше беспокоит то, как вы упаковываете или получаете ключи, используемые с данными. Включение самих производных ключей в AD — плохая идея, но вы мог включать Другие данные, такие как зашифрованный текст или производные данные в AD, и затрудняют для злоумышленника создание завернутой комбинации ключа/зашифрованного текста.

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