Project Wycheproof обнаруживает ошибки в популярных криптографических библиотеках

Google выпустила Project Wycheproof, набор тестов безопасности, которые проверяют библиотеки криптографического программного обеспечения на наличие известных слабых мест. После разработки более 80 тестовых примеров было обнаружено более 40 ошибок безопасности.

Для хорошей криптографии необходимо наличие двух компонентов. Во-первых, сила самого примитива шифра. Это свойство, которое классифицирует его как подходящее или непригодное для создания приложения. Например, в протоколе TLS, описанном в разделе «Рекомендации по развертыванию SSL и TLS — используйте комплекты защищенных шифров», не все шифры рекомендуются для использования. В этом списке, например, мы находим несколько устаревших криптографических примитивов, которые небезопасны, и их следует избегать:

Анонимные пакеты Диффи-Хеллмана (ADH) не обеспечивают аутентификацию

Комплекты NULL шифров не обеспечивают шифрования

Наборы со слабыми шифрами (обычно 40 и 56 бит) используют шифрование, которое легко взломать.

RC4 небезопасен

3DES медленный и слабый

Второй фактор — это библиотека, реализующая шифр. Вы уверены, что в нем нет ошибок? Одним из таких контрпримеров является функция mcrypt из библиотеки libmcrypt, популярная в приложениях PHP, несмотря на множество недостатков, описанных в статье Если вы вводите слово MCRYPT в свой PHP-код, вы делаете это неправильно.

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

Таким образом, Project Wycheproof представляет собой набор модульных тестов, которые проверяют библиотеки криптографического программного обеспечения на наличие известных слабых мест в RSA, шифровании с эллиптической кривой и аутентифицированном шифровании. За то короткое время, что проект жив, более 40 ошибок было обнаружено с помощью 80 полных модульных тестов. Тесты, доступные на GitHub, охватывают некоторые из наиболее широко используемых алгоритмов, таких как:

ЮАР

DSA

ECDH

Диффи-Хеллман

против их реализаций в поставщиках архитектуры криптографии Java, таких как Bouncy Castle, Spongy Castle и поставщиках по умолчанию в OpenJDK.

Чтобы запустить эти тесты, скажем, для Bouncy Castle или OpenJDK, вам необходимо установить Bazel, а затем запустить тест следующим образом:

bazel test BouncyCastleAllTests

или же

bazel test OpenJDKAllTests

Одной из наиболее тревожных из обнаруженных ошибок является утечка закрытых ключей реализацией ECDHC Bouncy Castle, поскольку ECDCH полностью заменит RSA для транспортировки ключей в предстоящей версии TLS 1.3, поскольку такая библиотека, в которой размещена слабая реализация, представляет собой первоочередной вопрос. важность.

При реализации алгоритмов многое может пойти не так, и на самом деле в проекте TLS 1.3 есть целый раздел, посвященный подводным камням реализации, с которыми потенциально можно столкнуться при разработке библиотеки или приложения:

Какие контрмеры вы используете для предотвращения атак по времени?

При проверке подписей RSA принимаете ли вы как NULL, так и отсутствующие параметры? Вы проверяете, что заполнение RSA не содержит дополнительных данных после хеш-значения?

При использовании обмена ключами Диффи-Хеллмана правильно ли вы сохраняете начальные нулевые байты в согласованном ключе?

Проверяет ли ваш клиент TLS, что параметры Диффи-Хеллмана, отправленные сервером, являются приемлемыми?

Используете ли вы надежный и, что наиболее важно, правильно настроенный генератор случайных чисел при генерации частных значений Диффи-Хеллмана, параметра «k» ECDSA и других критически важных для безопасности значений? РЕКОМЕНДУЕТСЯ, чтобы реализации реализовывали «детерминированный ECDSA», как указано в [RFC6979].

Подгоняете ли вы значения открытого ключа Диффи-Хеллмана к размеру группы?

Проверяете ли вы подписи после их создания для защиты от утечки ключей RSA-CRT?

Таким образом, Project Wycheproof становится ценным дополнением к стремлению к правильному применению криптографии, так как получить его правильно слишком сложно, поэтому требуется тщательное тестирование или использование проверенных безопасных продуктов, таких как CMS с открытым исходным кодом Paragonie. в отличие от известных уязвимых, таких как Drupal, Joomla или WordPress.