AES256 CBC + HMAC SHA256, обеспечивающий конфиденциальность * и * аутентификацию?

Question

Я подумываю об использовании AES256 CBC + HMAC SHA-256 в качестве стандартного блока для сообщений, обеспечивающего как конфиденциальность, так и аутентификацию.

В частности, рассмотрим следующий сценарий:

• Алиса владеет открытым ключом, принадлежащим Бобу (обмен ключами и алгоритм выходят за рамки этого вопроса). У Алисы есть идентификационный ключ K, также сообщаемый Бобу, с помощью которого она может идентифицировать себя. Только Алиса и Боб знают ключ K.
• Алиса шифрует (nonce || K), используя открытый ключ Боба.
• Боб расшифровывает пакет и теперь имеет K и nonce.
• Боб использует SHA-256 с SHA256 (K | nonce), чтобы получить K (e) 256 бит.
• Боб использует SHA-256 с SHA256 (K || nonce + 1), чтобы получить K (s) из 256 битов.

Теперь для каждого пакета, который Боб хочет отправить Алисе, он выполняет следующее:

• Создать новый случайный 128 бит IV
• Шифрует сообщение, используя IV и K (e) в качестве ключа.
• Создает SHA-256 HMAC с K (s) в качестве ключа и (IV || зашифрованное сообщение) в качестве данных.
• Наконец отправляет (IV || HMAC || Ciphertext) Алисе

Алиса также рассчитала K (e) и K (s) и выполняет следующую процедуру при получении данных от Боба:

• Разделить сообщение на IV, шифротекст и HMAC.
• Рассчитать HMAC, используя K (s), IV и шифротекст.
• Сравнить HMAC с отправленным HMAC. Если это совпадает, Алиса считает это сообщение аутентифицированным как сообщение, отправленное Бобом, в противном случае оно отбрасывается.
• Алиса расшифровывает сообщение, используя K (e)

Гарантирует ли этот протокол, что Алиса только расшифровывает сообщения от Боба, при условии, что никто, кроме Боба, не может прочитать зашифрованное сообщение, которое Алиса отправляет ему в зашифрованном виде с помощью его открытого ключа?

т.е. сообщения, созданные таким образом, обеспечивают конфиденциальность и аутентификацию?

Примечание. Если протокол требует, чтобы Боб отправлял несколько сообщений, эта схема нуждается в небольшом изменении, чтобы избежать атак воспроизведения.

P.S. Мне известно об AES-GCM / CCM, но эта схема будет работать с основными алгоритмами AES, SHA и HMAC, которые встречаются в большинстве криптопакетов. Это решение также может быть медленнее, но оно также выходит за рамки вопроса.

Answer 1

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

При этом используется AES с CBC для шифрования и HMAC для целостностиэто звук.Существуют комбинированные режимы шифрования + целостности (о которых вы знаете), и CBC + HMAC является своего рода «старой школой», но это не может повредить.Вы делаете все «одобренным наукой» способом: зашифруйте, затем MAC зашифруйте зашифрованную строку (и вы не забудете IV: забывание IV - это классическая ошибка).

Ваш ключ может быть несколько слабым.Идеально, если SHA-256 ведет себя как идеальный случайный оракул, но известно, что SHA-256 не ведет себя как случайный оракул (из-за так называемой атаки с удлинением длины).Это похоже на причину, по которой HMAC является HMAC, с двумя вложенными вызовами хеш-функций вместо простого хеширования (один раз) конкатенации ключа MAC и данных.TLS использует специальную функцию вывода ключа (которая в спецификации TLS называется «PRF»), которая должна избегать каких-либо проблем.Эта функция построена на основе SHA-256 (на самом деле, на основе HMAC / SHA-256) и может быть реализована на основе любой типичной реализации SHA-256.

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

В TLS существует два одноразовых номера, называемых «случайным клиентом» и «случайным сервером».В вашем предложении у вас есть только «случайный клиент».Что вы теряете здесь, с точки зрения безопасности, неясно.Осторожной стратегией было бы включение случайного сервера (то есть другого одноразового номера, выбранного Бобом).Мы должны избегать того, когда Алиса и Боб запускают протокол в обоих направлениях, а злоумышленник передает сообщения от Алисы самой Алисе.Полный анализ того, что может сделать злоумышленник, сложен (это целая ветвь криптографии);Вообще говоря, одноразовые номера в обоих направлениях имеют тенденцию избегать некоторых проблем.

Если вы отправляете несколько пакетов, у вас могут возникнуть проблемы с потерянными пакетами, дублированными пакетами («атаками воспроизведения») и пакетами, поступающими не в порядке,В контексте TLS это не должно "нормально" происходить, поскольку TLS используется на носителе, который уже обеспечивает (при нормальных условиях, не считая активных атак) передачу данных в строгом порядке.Таким образом, TLS включает порядковый номер в данные, которые поступают в MAC.Это позволит обнаружить любое изменение от злоумышленника, включая воспроизведение, потерянные записи и переупорядочение записей.Если возможно, вы также должны использовать порядковый номер.

Answer 2

Ответ на поставленный вопрос - нет, нет гарантии, что Алиса расшифровывает только сообщения от Боба, но это только потому, что вы не оговорили, что только Боб знает K . Если Алиса и Боб - единственные люди, которые знают K , то суть вопроса в том, является ли ваш протокол генерации ключей надежным. (Я думаю, что мы можем игнорировать все остальное, потому что вы просто используете HMAC-SHA256 и AES256, так как они предназначены для использования.)

Протокол генерации неплох, но его можно улучшить. Общепринятым способом создания ключей из общих секретов является использование « функции получения ключа ». Эти функции используют хэш аналогично тому, что вы сделали здесь, но они также намеренно медленны, чтобы предотвратить атаки методом грубой силы. PBKDF2 кажется тем, что вы хотите, так как он а) может получать 512 бит ключевых данных (или более), и б) может состоять из имеющихся примитивов; а именно SHA256 и HMAC-SHA256.

Answer 3

Если вы не хотите использовать PKI, взгляните на TLS-PSK. Казалось бы, решить именно ту проблему, которую вы решаете сами. См. RFC 4279 (и 5487 для дополнительных наборов шифров).