Регистрация Войти
Рейтинг:2
avatar Crypto

Что может сделать злоумышленник с таким незащищенным использованием AES-CFB8?

флаг in
katoriw701

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

В основном AES-CFB8 (явно без заполнения) используется для шифрования потока данных, а IV/ключ повторно используются между потоками сервера и клиента, а IV совпадает с ключом. Насколько это небезопасно и может ли атака восстановить iv/key из этого. Ключ, используемый для AES, представляет собой общий секрет, который может скомпрометировать не только исходный поток пакетов, поскольку поток, который имеет такое возможное небезопасное использование, не так чувствителен, но если используемый ключ будет скомпрометирован, это будет более серьезной проблемой.

общедоступный статический секретный ключ generateSharedSecret () {
   окончательный Генератор ключей = KeyGenerator.getInstance("AES");
   Ген.инит(128); // АЭС-128
   вернуть gen.generateKey();
}

// Определяется клиентом и отправляется безопасным способом на сервер через RSA и проверяется через надежный источник.
final SecretKey sharedSecret = generateSharedSecret();

 // Это делается как на сервере, так и на клиенте после того, как сервер получит общий секрет. 
 окончательный шифр aesCFBEncrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBEncrypt.init(Cipher.ENCRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 окончательный шифр aesCFBDecrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBDecrypt.init(Cipher.DECRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 this.enableStreamEncryption(aesCFBEncrypt, aesCFBDecrypt);

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

80
0 + 0
SAI Peregrinus avatar
флаг si
SAI Peregrinus
Почему ЦФБ? Это не общедоступный режим, и он не защищен AE, поэтому ответ «нет», даже если не учитывать другие проблемы с этим.
0
Ответить
флаг in
katoriw701
@sai-peregrinus Я понятия не имею, почему использовался CFB, этот код был написан более десяти лет назад, но кем-то, кроме меня. Я знаю, что самим потоком можно манипулировать, но в базовом протоколе есть механизмы, делающие это трудным или невозможным в режиме реального времени.Предположим, что базовый протокол использует MAC-затем-шифрование для аутентификации. Это анализ кода устаревшей программы, а не самопроизвольное использование плохого шифрования для нового протокола, если вы это предполагаете. Здесь было сделано много ошибок и плохих практик, и они могут работать только благодаря удаче, но меня интересуют любые практические атаки.
0
Ответить
флаг in
katoriw701
@SAIPeregrinus Меня больше интересует, используется ли общий секрет с шифром и можно ли его восстановить, а не попытки манипулировать открытым текстом, если это имеет смысл, поскольку это не проблема, если только кто-то не имеет полного контроля и не может читать и писать открытые тексты в обоих направлениях потока. Единственная причина, по которой шифрование вообще используется, — это предыдущие попытки MITM с помощью социальной инженерии, которые никогда не причиняли реального вреда.
0
Ответить
Рейтинг:2
Maarten Bodewes avatar Crypto
флаг in
Maarten Bodewes

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

Конечно, этот зашифрованный текст также передается в регистр сдвига, который в настоящее время содержит IV. Один байт IV сдвигается влево (MSB), а байт зашифрованного текста помещается вправо (LSB). Так что теперь следующее шифрование снова приведет к идентичному промежуточному значению. Это означает, что следующий идентичный байт открытого текста также приведет к прямой утечке данных и так далее и тому подобное. Конечно, если у вас много сообщений, то вы можете сделать много пар, поэтому утечка данных более вероятна.

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

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

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

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

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

0 + 0
Maarten Bodewes avatar
флаг in
Maarten Bodewes
Другими словами: ?ПОВТОРИТЬ С НАЧАЛА...
0
Ответить
Рейтинг:-1
SAI Peregrinus avatar Crypto
флаг si
SAI Peregrinus

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

Также кажется, что вы можете повторно использовать один и тот же IV для нескольких сообщений. Это аннулирует требования безопасности CFB, даже если это держалось в секрете. Вам может понадобиться защищенный от неправильного использования режим, такой как AES-GCM-SIV, если вы не можете гарантировать новый IV для каждого сообщения.

0 + 0
флаг in
katoriw701
IV никогда не отправляется, IV совпадает с ключом, если только это не деталь реализации AES-CFB, которая включает IV в зашифрованный текст, но я сомневаюсь в этом. «Также кажется, что вы можете повторно использовать один и тот же IV для нескольких сообщений.Это аннулирует требования безопасности CFB, даже если это держалось в секрете». Это объяснение, о котором я хочу узнать больше, и как оно ломается? Меня больше интересует, почему это плохо, а не плохо, потому что я знаю о повторном использовании IV и IV в качестве ключа (IV никогда не генерируется случайным образом для каждого сообщения или отправляется).
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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