Я понимаю, что хороший одноразовый номер очень важен для большинства шифров. Я использую 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.
Вот мои идеи / мысли:
Подпишите материал nonce с помощью ключа подписи (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 выполняют Am⊕Bm, и мы наконец получаем наш IV. Если подделать, у A и B будут разные IV, потому что Ева не знает Km, поэтому она не может точно манипулировать ею, верно? Это приведет к тому, что GCM обнаружит несанкционированный доступ при обмене первым сообщением, так что никакого вреда не будет Что не так с этим подходом?
Извините за длинный вопрос, и, пожалуйста, не говорите мне, чтобы я не реализовывал свой собственный протокол, потому что я делаю это, чтобы узнать о деталях реализации как студент CS, а не о том, как их игнорировать.