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

Question

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

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

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

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

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

Answer 1

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

И вы также беспокоитесь о читах.

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

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

Answer 2

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

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

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

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

---

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

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

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

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

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