Шифрование AES и необходимость целостности

Question

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

Я хочу использовать шифрование AES128 (CFB-Mode) для сетевого взаимодействия в моем приложении между двумя отдельными клиентами. Обмениваемые данные состоят только из текстовых строк определенной структуры, например, первые байты всегда сообщают получателю тип сообщения, которое они получают, чтобы они могли их обработать. С AES я хочу обеспечить конфиденциальность сообщения, но теперь возникает вопрос «целостности».

Обычно вы рассматриваете возможность использования MAC. Но разве не гарантируется, что никто не изменил сообщение, если получатель сможет правильно его расшифровать, то есть, что сообщение может быть правильно использовано в его приложении из-за формата строки? Не приведет ли изменение (даже 1-битное) зашифрованного сообщения от стороннего производителя к дешифровке во время расшифровки?

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

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

Answer 1

Как вы сказали, вы можете обнаружить изменения в формате простого текстового сообщения после шифрования. Но на каком уровне это пойдет не так? У вас есть что-то достаточно большое и избыточное для тестирования? Что вы собираетесь делать, если измененный простой текст приводит к неясному исключению где-то внизу? С помощью CFB (как и большинство режимов) злоумышленник может убедиться, что, например, изменена только последняя часть сообщения, и оставить первые блоки без изменений.

И вас тоже волнуют читы.

По моему мнению, вам гораздо лучше использовать алгоритм MAC или HMAC, либо режим шифрования, который обеспечивает целостность / аутентификацию поверх конфиденциальности (например, EAX или GCM). Если вы уверены, что никто другой не имеет симметричного ключа, проверка подлинности (например, MAC) докажет, что данные были подписаны правильным ключом. Поэтому нет, пользователь не может утверждать, что данные были изменены при транспортировке, если проверка подлинности прошла успешно.

Следующий вопрос звучит так: можете ли вы верить, что симметричный ключ принадлежит только другому игроку? Для этого вы можете использовать какую-то схему PKI (используя ассиметричные ключи) вместе с механизмом обмена ключами, таким как DH. Но это на потом, если вы решите пойти по этому пути.

Answer 2

Это немного из моей глубины, но ...

Да, изменение зашифрованных байтов зашифрованного сообщения AES должно привести к сбою дешифрования (это был мой опыт работы среализация c #).Клиент, который расшифровывает, узнает, что сообщение недействительно. РЕДАКТИРОВАТЬ: очевидно, это не так.Похоже, вам понадобится CRC или хеш, чтобы убедиться, что сообщение было успешно расшифровано.Более серьезная проблема - утечка секретного ключа AES (и в одноранговой среде ключ должен быть отправлен, чтобы получатель вообще мог расшифровать сообщение).Затем третья сторона может отправлять сообщения, как если бы они были законным клиентом, и они будут приняты как ОК.

Честность намного сложнее.Я не совсем уверен, насколько вы хотите, чтобы вещи были, но я подозреваю, что вы хотите использовать шифрование с открытым ключом .Это позволяет вам включить хэш сообщения (например, подпись или MAC) на основе закрытого ключа, чтобы подтвердить достоверность сообщения.Получатель использует открытый ключ для проверки хэша, и, таким образом, исходное сообщение в порядке.Основное преимущество шифрования с открытым ключом по сравнению с симметричным шифрованием, таким как AES, заключается в том, что вам не нужно отправлять закрытый ключ, только открытый ключ.Это делает намного труднее выдавать себя за клиента. SSL / TLS использует шифрование с открытым ключом.

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

---

Дополнительная информация о целостности:

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

Предположение, что секретный ключ остается секретным, вполне разумно.Особенно если после некоторого количества сообщений вы генерируете новые.SSH и WPA Wi-Fi периодически генерируют новые ключи.

Если вы не можете предположить, что секретный ключ является секретным, то вам нужно пойти в PKI, чтобы подписать сообщение.С ключом AES злонамеренной третьей стороны они будут просто генерировать любые сообщения с ключом, которые они хотят.

Может быть некоторое расстояние, включая порядковый номер в ваше сообщение, основанное на ГСЧ.Если вы используете один и тот же RNG и одинаковое начальное число для обеих сторон, они должны быть в состоянии предсказать, какой порядковый номер будет следующим.Сторонней организации потребуется перехватить исходное начальное число и узнать, сколько сообщений было отправлено для отправки действительных, но поддельных сообщений.(Это предполагает, что никакие сообщения никогда не могут быть потеряны или отброшены.)