Рейтинг:2

Можно ли использовать тег аутентификации AES-GCM в качестве функции получения ключа?

флаг na

Я хочу построить детерминированное дерево вывода ключей, в котором корень безопасно хранится в централизованной службе, а листья встроены во множество устройств. Когда устройство хочет взаимодействовать с серверной частью, устройство предоставляет свой идентификатор и соль, а централизованные службы получают ключ для конкретного устройства из корневого ключа, идентификатора устройства и соли.

Обычно для этой цели я предпочитаю HKDF или другую хорошо известную функцию получения ключей. Но поскольку мы намерены запускать весь сервис у облачного провайдера, наш выбор безопасного хранилища ключей более ограничен.

Azure Key Vault имеет экспериментальную поддержку AES-GCM на своих управляемых модулях HSM. Моя идея состоит в том, чтобы использовать соль устройства в качестве входного одноразового номера (IV) AES-GCM и идентификатора устройства в качестве связанного ввода данных, а не открытого текста в качестве ввода. В качестве вывода AES-GCM я бы использовал сгенерированный тег в качестве детерминированного псевдослучайного ключа:

$\text{KDF}(ключ, соль, идентификатор) := \text{AES-GCM-шифрование}(ключ, \эпсилон, соль, идентификатор)$

куда $ключ$ глобальный корневой секрет, хранящийся в хранилище ключей, $\эпсилон$ пустая строка, используемая в качестве ввода открытого текста GCM, $соль$ это 96-битное значение, используемое как $одноразовый номер$ в ГКМ и $id$ представляет собой строку идентификации устройства переменной длины, которую ни одно устройство не использует совместно с другим устройством, и которая используется в качестве связанного ввода данных в GCM.

Надежна ли эта конструкция?

  • предполагая соль / одноразовый номер глобально уникален среди всего времени жизни ключа и по всем идентификаторам устройств?
  • предполагая соль / "одноразовый номер" уникален только для определенного идентификатора а может быть несколько устройств, случайно (из-за коллизии случайных значений) совместно использующих одну и ту же соль?

Интуитивно я почти уверен, что с глобально уникальной солью эта конструкция должна быть безопасной функцией получения ключа. Но этого трудно достичь для варианта использования, который мы имеем в виду.

Maarten Bodewes avatar
флаг in
Вы используете одноразовый номер в качестве ключа? Разве тогда он не должен быть размером 128 бит? И почему вы называете это одноразовым номером, если это ключ? Как он создается/управляется?
Perseids avatar
флаг na
Ах, мой плохой, я был так занят остальным, что забыл важный вход в формулу.Nonce — это соль в номенклатуре HKDF, и на самом деле существует ключ, который создается и резервируется за пределами Key Vault и хранится в неэкспортируемом виде в Key Vault.
Perseids avatar
флаг na
Да, и еще один неприятный побочный эффект этой установки заключается в том, что второй уровень дерева (то есть результат первого деривации) уже покидает защищенную среду. В идеале сервер приложений должен предоставлять только информацию о пути (идентификаторы и соль для каждой производной), но я не вижу, как это сделать без специальной поддержки получения ключей в защищенной среде. (Большинство выделенных HSM могут это сделать, но не управляемый интерфейс, предоставляемый облачными провайдерами.)
Рейтинг:3
флаг us

Во-первых, определить конструкцию. AES-GCM при использовании предложенным способом эквивалентен $$\operatorname{KDF}(K,S,I)=\operatorname{AES}_K(S\|0^{32})\oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{ 128})}(Я)$$

куда $\operatorname{GHASH}_H(M)\приблизительно \sum_i H^iM_i$ для блоков сообщений $M_i$ размером 128 бит, а умножения и сложения выполняются в 128-битном конечном поле с полиномиальным представлением. Это приближение GHASH, которое будет работать для нашего обсуждения ниже.

Надежна ли эта конструкция?

Я назову эту конструкцию KDF безопасной, если она ведет себя как PRF на обоих входах, с учетом именованных ограничений, т. е. уникальные входы дают независимые псевдослучайные выходы.

[Предположим, что соль/одноразовый номер глобально уникален среди всего жизненного цикла ключа и всех идентификаторов устройств?

Как видно из приведенного выше выражения, при условии, что ваши соли уникальны, операция AES будет маскировать любой результат GHASH, и результат будет выглядеть случайным и непредсказуемым. Однако, учитывая ответ на следующую часть, сомнительно, приносят ли связанные данные какую-либо полезную пользу, кроме того, что они могут немного скрыть событие столкновения с солью.

[Предполагая, что соль / «одноразовый номер» уникальна только для определенного идентификатора, и может быть несколько устройств, которые случайно используют одну и ту же соль (из-за столкновения случайных значений)?

К сожалению нет. Если два производных используют одно и то же $(К,С)$ пара с двумя разными $я,я'$ запросы, и злоумышленник узнает соответствующие выходные ключи $к,к'$, то противник может узнать $k\oplus k' = \operatorname{GHASH}_{\operatorname{AES}_K(0^{128})}(I) \oplus\operatorname{GHASH}_{\operatorname{AES}_K(0^{ 128})}(I')\приблизительно \sum_i H^i(I'_i\oplus I_i)$ это выражение, из которого противник может восстановить $H=\имя_оператора{AES}_K(0^{128})$ позволяя им восстановиться $k\oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{128})}(I) = \operatorname{AES}_K(S\|0^{32})$ и оттуда предсказать производный ключ для любого $I$ за это исправлено $(К,С)$ пара.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.