Безопасное получение IV (Nonce) с помощью атаки MITM

Question

Я понимаю, что хороший одноразовый номер очень важен для большинства шифров. Я использую AES-GCM и использую 96-битный одноразовый номер с 256-битным ключом AES. Я задал здесь несколько вопросов о том, как вести переговоры по одноразовому номеру по небезопасному каналу.

Я использую ECDH для получения общего секрета и планирую использовать стандартный метод X9.63 для получения ключевого материала из них. Я знаю, что было бы возможно просто добавить случайно сгенерированные 96 битов к концу для соли при согласовании ключа. Тогда я мог бы как-то объединить два (это одноранговая система), например XOR, и получить случайный, хороший одноразовый номер.

Конечно, это не останавливает атаки MITM, скажем, с помощью ARP-спуфинга. Сами открытые ключи сертифицируются центральным сервером, открытый ключ которого распространяется вместе с приложением. Таким образом, сертификация не может быть подделана из-за использования GCM. Тем не менее, одноразовые номера не сертифицированы, конечно, поэтому можно потенциально MITM одноранговых узлов, сохраняя их ключи идентичными, но заменив IV на что-то предсказуемое или статическое (или все нули или что-то еще), что приведет к уязвимости для выбранного (известно?) атака открытым текстом.

Вот сценарий того, о чем я говорю, на случай, если это сбивает с толку. Алиса (A) и Боб (B) генерируют хороший случайный 96-битный одноразовый материал (Am и Bm) и добавляют их к своим сертификатам x.509. Для иллюстрации я буду использовать маленькие числа Am=1234 и Bm=4321. Если не MITMed, каждый вычислит Am calculateBm = 5171. Это будет использоваться в качестве одноразового номера. Ева решает MITM их победить IV. Она удостоверяется, что они в конечном итоге с постоянным IV "6666." Когда A посылает Am "1234" B, Eve ARP подменяет Bm и заменяет его "2795". Когда B посылает Bm "4321" A, Ева заменяет это "7896". 1234⊕7896 == 4312⊕2795 == 6666.

Вот мои идеи / мысли:

Подписать одноразовый материал с помощью ключа подписи (ECDSA): На данный момент у меня нет возможности для аутентификации чего-либо вне самой GCM (т.е. я не использую ключи ECDSA или управляю ими). Я хотел бы строго придерживаться алгоритмов Suite B. Я знаю, что могу аутентифицировать открытый текст с помощью GCM ("AD" часть AEAD - Authenticated Encryption with Associated Data), но, конечно, у меня еще нет установленного IV... поэтому я не могу аутентифицировать материал IV с этим, могу Я? Мне кажется, что я должен быть в состоянии аутентифицировать это, используя только симметричный ключ с GCM (который я установил уже через ECDH), потому что он не должен быть зашифрован в любом случае, так что нет никакого секрета - только открытый текст и GCM MAC - но я не могу понять, как инициализировать AEADBlockCipher без IV в BC. Было бы глупо "обмануть" шифр, сначала инициализировав его с нулевым IV, правильным ключом, затем обработав Nonce как "связанные данные" (не зашифрованные), завершив работу буфера (для добавления MAC), отправив это равноправному узлу, затем повторно инициализировать шифр с реальным IV и тем же ключом? В качестве альтернативы я вполне уверен, что мог бы подписать одноразовый номер (возможно, вместе с открытым ключом ECDH, если бы захотел), используя ECDSA, но для этого потребовалось бы распространение открытых ключей ECDSA, которые также сертифицированы сервером, что добавляет сложности, которую я скорее избегайте (таким образом моя первая идея подписания)

Запишите и запретите повторное использование одной и той же комбинации IV/Key: Важно, что с IV используется только один раз с данным ключом. Таким образом, если кто-то совершит атаку MITM, описанную выше, чтобы заменить IV искусственным, то эта идея просто заметит и закроет соединение. Если они заменят его на рабочую замещающую пару, которая выводит неиспользованный IV, атакующий не получит преимущества (верно?). Закрытый ключ пары ECDH в моем проекте фактически никогда не попадает на диск, поэтому между вызовами программы у меня будут все новые симметричные ключи, поэтому этот набор пар ключ +IV можно легко сохранить в памяти, поэтому мне очень нравится такой подход:)

Используйте секретный материал из ECDH в качестве "маски" для создания секрета. IV: Возьмите установленный секретный материал ECDH (еще не переданный генератору ключей X9.63 (ECDHKEKGenerator в BC)). Каким-то образом получить 96 бит из него (км), например, первые 96 самого материала или первые 96 из SHA-1 дайджеста материала. Алиса и Боб генерируют случайный 96-битный одноразовый материал (Am и Bm). A и B рассчитывают Am⊕Km и Bm⊕Km соответственно, затем отправляют свои значения другому человеку. Как только A имеет Bm⊕Km, а B имеет Am⊕Km, A выполняет Km⊕(Bm⊕Km), чтобы получить Bm, а B выполняет Km⊕(Am⊕Km), чтобы получить Am. Затем и A, и B выполняют AmmBm, и мы наконец получаем наш IV. Если подделать, у A и B будут разные IV, потому что Ева не знает Km, поэтому она не может точно манипулировать ею, верно? Это приведет к тому, что GCM обнаружит несанкционированный доступ при обмене первым сообщением, поэтому никакого вреда не будет. Что не так с этим подходом?

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

Answer 1

Чтобы ответить на этот вопрос, вы должны сначала взглянуть на основной GHASH, который используется для проверки целостности. GHASH - это универсальная хеш-функция. зависит от некоторых секретных параметров. Безопасность GHASH зависит от того, можете ли вы сохранить эти секретные параметры в секрете. Поскольку GHASH является линейной функцией, очень важно, чтобы злоумышленник никогда не узнал результат GHASH. Т.е. знание только нескольких выходных данных GHASH позволяет атакующему получить секретные параметры GHASH.

GCM защищает вывод GHASH, шифруя его, то есть XOR с помощью AES(Counter0). Очень важно, чтобы Счетчик никогда не повторялся. Предположим, например, что вы шифруете два сообщения, используя одно и то же значение для Counter0. Затем злоумышленник узнает

AES(Counter0) Xor GHASH(C1,..)

а также

AES(Counter0) Xor GHASH(C2,..)

откуда злоумышленник может получить

GHASH(C1,..) Xor GHASH(C2,..)

который дает одно линейное уравнение атакующему. Знание двух уравнений позволяет решать по секретным параметрам. Но даже знание одного уравнения должно позволить упростить атаки на GCM.

Это показывает, что режим счетчика Галуа должен использоваться очень и очень осторожно. То есть, если вы повторяете IV в режиме CTR, то вы потенциально можете пропустить открытый текст. Если вы повторяете IV в GCM, вы теряете ключи, что, конечно, хуже.

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