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

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

В частности, рассмотрим этот сценарий:

Алиса владеет открытым ключом, принадлежащим Бобу (ключ обмена и алгоритм выходит за рамки этого вопроса). У Алисы есть идентифицирующий ключ К, также разделяемый с Бобом, который она может использовать, чтобы идентифицировать себя. Только Алиса и Боб знают ключ К.
Алиса шифрует (nonce || K) с помощью открытого ключа Bob.
Боб расшифровывает пакет и теперь имеет 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, которые можно найти в большинстве криптовых пакетов. Это решение также может быть медленнее, но это тоже выходит за рамки вопроса.

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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