Было рекомендовано использовать тот же IV в реализации AES

Question

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

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

То, что я хотел знать, насколько это угроза безопасности? Мне нужно иметь возможность эффективно сообщить об этом руководству, чтобы они точно знали, на что они согласны.

* ОБНОВЛЕНИЕ: * Мы также используем один и тот же КЛЮЧ повсюду.

Спасибо

Answer 1

Использование статического IV всегда плохая идея, но точные последствия зависят от используемого режима работы .Во всех них один и тот же открытый текст создаст один и тот же зашифрованный текст, но могут быть и дополнительные уязвимости: например, в режиме CFB с учетом статического ключа злоумышленник может извлечь зашифрованный поток из известного открытого текста и использовать его для расшифровки всехпоследующие строки!

Answer 2

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

К сожалению, я видел это раньше. У вашего поставщика есть требование, чтобы они внедрили шифрование, и они пытаются внедрить шифрование таким образом, чтобы это было максимально прозрачно - или как «флажок», насколько это возможно. То есть они на самом деле не используют шифрование для обеспечения безопасности, они используют его для удовлетворения требований флажка.

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

Answer 3

То, что я хотел знать, это насколько серьезна угроза безопасности?Мне нужно иметь возможность эффективно сообщить об этом руководству, чтобы они точно знали, на что они согласны.

Хороший пример повторного использования одного и того же одноразового номера - Sony vs. Geohot (на другомалгоритм хотя).Вы можете увидеть результаты для Sony :) В точку.Использование одного и того же IV может привести к незначительным или катастрофическим проблемам в зависимости от режима шифрования AES, который вы используете.Если вы используете режим CTR, то все, что вы зашифровали, так же хорошо, как обычный текст.В режиме CBC ваш первый блок открытого текста будет таким же для тех же зашифрованных данных.

Answer 4

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

Это отлично подходит для анализа паттернов злоумышленниками и выглядит как эквивалент пароля, который даст злоумышленникам ключи от королевства:

• Анализ паттернов: злоумышленник можетобратите внимание, что зашифрованная комбинация пользователя и пароля «gobbbledygook» используется каждую ночь перед тем, как генеральный директор уходит с работы.Затем злоумышленник может использовать эту информацию в будущем, чтобы удаленно определить, когда уходит генеральный директор.

• Эквивалент пароля: вы передаете это имя пользователя + пароль в URL.Почему кто-то другой не может передать точно такое же значение и получить те же результаты, что и вы?Если они могут, зашифрованные данные представляют собой открытый текстовый эквивалент для целей получения доступа, опровергая цель шифрования данных.