Введение

В июле 2021 года Nym прошел проверку безопасности у Жан-Филиппа Омассонa, известного эксперта в области безопасности. Целью было выявление потенциальных уязвимостей и дефектов в кодовой базе Nym, с акцентом на криптографию, безопасность кода и безопасность протоколов. Обзор был направлен на обеспечение целостности и надежности системы, охватывая ключевые аспекты ее архитектуры и реализации. Вы можете увидеть полный отчет об аудите здесь.

Резюме аудита

Аудит был проведён летом 2021 года. Его охват включал несколько репозиториев проекта Nym, в том числе:

• Основной репозиторий Nym: nymtech/nym, содержащий реализацию сервисов миксноды, шлюза и валидатора.
• Формат пакета микснета Sphinx: nymtech/sphinx, используемый микснодами.
• Протокол подписи Coconut Threshold Blind: nymtech/coconut, используемый для выпуска сертификатов.

В рамках аудита была проведена проверка актуальной версии кода в ветке develop, которая регулярно обновлялась в связи с интенсивным развитием проекта. Команда Nym предоставила JP Aumasson полный доступ к исходному коду, подробным техническим спецификациям, научным публикациям и сопроводительной документации.

Основные направления аудита

Аудит был сосредоточен на трёх ключевых направлениях: безопасности кода, криптографии и дизайне протоколов. В рамках проверки безопасности кода аудиторы тщательно исследовали базу исходного кода Nym на наличие уязвимостей, уделяя особое внимание распространённым проблемам, таким как небезопасные шаблоны программирования и некорректная обработка ошибок. Особый акцент был сделан на безопасности работы с памятью, включая защиту от переполнения целых чисел и других типичных ошибок в низкоуровневом коде.

Криптографический обзор охватывал широкий спектр основных примитивов, используемых Nym, таких как AES-128-CTR, BLAKE2b, ChaCha, Ed25519 и других. Целью было убедиться в правильности их реализации и устойчивости к сторонним атакам, включая атаки по сторонним каналам, неправильное использование параметров и слабости в генерации случайных чисел.

Помимо отдельных компонентов, аудит также включал проверку протоколов, определяющих основную функциональность системы Nym. Это включало изучение формата пакета Sphinx и протокола слепой подписи с порогом Coconut, чтобы выявить любые уязвимости, которые могли бы поставить под угрозу конфиденциальность или безопасность. Аудит был сосредоточен на потенциальных утечках информации, угрожающих анонимности пользователей, а также уязвимостях, таких как обходы проверки MAC, атаки через малые подгруппы и ошибки в криптографических операциях, включая арифметику BLS12-381 и доказательства с нулевым разглашением.

Обзор результатов

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

S-SPHX-01: Отсутствие проверки ключей (Низкий уровень)

Проблема, выявленная в nymtech/sphinx, связанная с недостаточной проверкой частных и общественных ключей, была решена путём миграции на библиотеку x25519, которая по своей сути обеспечивает действительность ключей благодаря своему дизайну. Реализация x25519 гарантирует, что приватные ключи корректно зажимаются (clamped), то есть автоматически ограничиваются допустимым подмножеством скаляров, исключая риск использования недопустимых приватных ключей. Кроме того, хотя x25519 явно не проверяет публичные ключи, реализация лестницы Монтгомери (Montgomery ladder) по своей природе предотвращает использование некоторых некорректных точек на кривой. Это снижает риск возникновения точек на бесконечности или других некорректных публичных ключей. Кроме того, в процессе обмена ключами предусмотрена возможность обнаружения и отклонения нулевого общего секрета. Использование x25519 значительно повысило уровень валидации ключей, снижая риск использования недопустимых или неправильно отформатированных ключей в системе. Это эффективно устраняет озабоченность, выраженную в ходе аудита в отношении проверки ключей.

S-COCO-01: Смещённое распределение при преобразовании хэша в скаляр (Низкий)

Процесс хэширования для получения скалярного значения в поле BLS12-381 ранее предполагал непосредственное отображение вывода хэш-функции в элемент поля. Однако такой подход вносил смещение из-за операции модульного сокращения (mod p), поскольку вывод хэш-функции не всегда равномерно распределяется относительно простого модуля поля, что приводило к неравномерному распределению. Чтобы решить эту проблему, мы заменили существующую функцию хеширования в скаляр hash_to_field из bls12_381 crate. Эта функция соответствует стандартизированной спецификации хеширования для полей, обеспечивая единообразное и беспристрастное отображение хеш-результатов на элементы поля. Кроме того, протокол zk-Nym, пришедший на смену Coconut, также использует эту функцию для своих хэш-операций, что гарантирует согласованность и корректность криптографических вычислений.

S-COCO-02: Права доступа к файлам ключей keygen-cli (Низкий)

Аудиторы отметили, что файлы ключей, создаваемые с помощью keygen-cli, имеют права доступа по умолчанию, тогда как с точки зрения безопасности им следовало бы установить более строгие ограничения. Однако эта проблема не потребовала внесения изменений, поскольку keygen-cli использовался только на ранних этапах реализации протокола Coconut. В настоящее время он больше не является частью основного репозитория Nym и не используется. Поскольку инструмент устарел, никаких дополнительных действий по ограничению прав доступа к его файлам не потребовалось.

S-CRYP-01: Потенциальный повтор использования IV в потоковом шифре (Высокий)

Проблема касалась функции шифрования данных с использованием вектора инициализации (IV). Если IV не был предоставлен, функция по умолчанию использовала нулевой IV, что могло привести к повторному использованию IV. Эта проблема была решена путем внедрения протокола AES-GCM-SIV на этапе регистрации. Чтобы предотвратить атаки по понижению уровня, мы убрали возможность использования устаревшего ключа AES-128-CTR для связи между клиентом и шлюзом. При условии, что и клиент, и шлюз обновлены, они всегда будут генерировать случайный, ненулевой IV.

S-PROT-01: Возможное двойное использование учетных данных (Высокий)

Аудиторы отметили, что в проверяемой версии Coconut отсутствовал механизм обнаружения двойного расходования, что могло позволить нескольким шлюзам одновременно неправильно считать учетные данные неиспользованными. Однако контракт пропускной способности Coconut был позже обновлен для отслеживания использования учетных данных с помощью хранения состояния в блокчейне, что решило эту проблему. Кроме того, Coconut с тех пор был заменен протоколом zk-nyms, который включает встроенную функциональность обнаружения двойных расходов.

S-NYM-01: Зависимости с известными уязвимостями (Средний)

Аудиторы выявили, что несколько компонентов проекта Nym использовали устаревшие версии зависимостей с известными проблемами безопасности. Например, репозиторий Sphinx применял небезопасную версию библиотеки generic-array, основной репозиторий Nym — устаревшую версию tokio, а клиент Nym содержал несколько пакетов с известными уязвимостями, некоторые из которых могли быть эксплуатируемы в контексте Nym. По рекомендации аудиторов мы регулярно обновляем зависимости. В настоящее время мы активно управляем зависимостями с помощью Dependabot, который непрерывно отслеживает и автоматически выявляет устаревшие или уязвимые пакеты в наших репозиториях. Смотрите исправления Dependabot, которые постоянно применяются в нашем репозитории.

S-NYM-02: Ошибка обработки неудачи дешифрования (Низкий)

В коде была обнаружена проблема в функции recover_identifier, расположенной в файле nym/common/nymsphinx/acknowledgments/identifier.rs, где неудачи дешифрования, например из-за неверных параметров, не обрабатываются должным образом. Это может привести к панике или другим небезопасным состояниям. Аналогичная проблема имелась в функции recover_plaintext в файле nym/common/nymsphinx/src/receiver.rs. Отсутствие обработки ошибок дешифрования потенциально могло вызвать нестабильное или небезопасное состояние системы. После тщательного анализа функций мы пришли к выводу, что первый пример, в recover_identifier, не представляет проблемы. Невозможно предоставить некорректные параметры, так как все параметризовано с помощью AckEncryptionAlgorithm (ссылка), что означает, что любые недопустимые значения будут пойманы во время компиляции. Второй случай, recover_plaintext, больше не существует. Вместо него используется функция recover_plaintext_from_regular_packet, которая теоретически могла завершиться с ошибкой, если бы параметры были изменены на необычные значения. Мы решили эту проблему, добавив соответствующую обработку ошибок, чтобы гарантировать стабильность системы даже в крайних случаях.

S-NYM-03: Паника при генерации идентификаторов фрагментов (Низкий)

Код, используемый для генерации новых идентификаторов фрагментов, случайным образом выбирает значение типа i32 и берёт его абсолютное значение. Однако такой подход может привести к панике в случаях, когда случайно выбранное значение равно i32::MIN, поскольку его абсолютное значение не может быть представлено в пределах типа i32. Это вызывает ошибку «попытка отрицания с переполнением» из-за ограничений представления в формате дополнительного кода (2-комплемента). Мы согласны с тем, что оценка серьёзности проблемы как низкой является оправданной, так как вероятность встретить такой случай составляет примерно 1 из 4 миллиардов. Однако мы устранили проблему, реализовав рекомендованное аудитором исправление, чтобы предотвратить потенциальные паники и неожиданные сбои, особенно когда миллионы пользователей генерируют тысячи идентификаторов фрагментов.

S-NYM-04: Мнемоническая фраза не обнуляется (Низкий)

Выявленная проблема заключалась в том, что BIP39 мнемоническая фраза, используемая для подключения сервиса nymd, не обнулялась после использования, в результате чего в памяти оставалось несколько копий этой фразы. Это увеличивало риск утечки, так как мнемонические фразы легче обнаружить в памяти по сравнению с необработанными криптографическими ключами. Для решения этой проблемы мы реализовали несколько мер. В компонентах Rust мы интегрировали пакет zeroize, чтобы гарантировать, что любая память, содержащая мнемонику, будет надежно стерта, как только выйдет из области видимости. Поскольку JavaScript — это язык с автоматическим управлением памятью и без прямого контроля над её очисткой, мы применили иной подход для снижения риска утечки в среде JavaScript. В частности, мы изменили систему так, чтобы JavaScript-рантайм завершался сразу после передачи мнемонической фразы в Rust-слой. Это обеспечивает очистку всех экземпляров мнемоники в памяти JavaScript при завершении работы программы. Мнемоника переносится в Rust как можно скорее, уменьшая её воздействие в JavaScript. В Rust zeroize обеспечивает безопасное удаление всех копий мнемонической фразы, когда она становится больше не нужна. Благодаря этим изменениям мы значительно сократили присутствие мнемонической фразы в памяти, снизили риск её утечки и обеспечили безопасное управление и удаление чувствительных данных.

Заключение

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