Аудит безопасности (Жан-Филипп Омассон)

Мы рады сообщить, что Ergo успешно прошел аудит безопасности определенных (самых критичных) частей кода. На этот раз аудит проводил Жан-Филипп Омассон (также известный как veorq, https://aumasson.jp/ ).

Подробный отчет приведен ниже. Ничего критичного не найдено. Комментарии по обнаруженным проблемам:

1. По паролю кошелька мы предоставим рекомендацию в следующих версиях клиентского протокола. Не уверены, что жесткое требование к паролю будет реализовано, но мы проведем дополнительные консультации по этому вопросу.
2. Изменение параметров "n" и "k" имеет смысл только при запуске новой сети. Изменение этих параметров в майнинговом узле сделает производимые блоки недействительными для других узлов. Изменение этих параметров в клиенте протокола означает переход на другой форк (блоки, поступающие от честных участников протокола, будут отклонены). Так что, возможно, нет необходимости в дополнительных проверках, так как люди, запускающие новые сети, правильно установят "n" и "k".
3. В настоящее время узел Ergo (как и другие клиентские протоколы блокчейна и кошельки, о которых нам известно, а также криптографические библиотеки, которые мы используем) не обеспечивает защиту от атак через побочные каналы, выполняемых локально (например, атак по времени или инспекции памяти вредоносным ПО или вирусами). Поэтому, пожалуйста, защищайте машины, на которых вы запускаете кошельки!

==========================================================================================================

% Оценка безопасности Ergo % Жан-Филипп Омассон % 07/Дек/19

Резюме

Мы были приглашены Ergo для проведения оценки безопасности нескольких компонентов их платформы Ergo:

• Создание и проверка доказательств протокола Sigma
• Безопасное хранение секретов в кошельке
• Проверка работы по принципу Proof-of-Work

​Этот краткий отчет подводит итоги нашей оценки и описывает наши выводы и рекомендации по смягчению.

Доказательства протокола Sigma

​Протокол Ergo основывается на ErgoScript, языке сценариев, поддерживающем сигма-утверждения, которые могут быть доказаны и проверены с помощью неинтерактивных доказательств знания.

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

Доказательство сигма-утверждения затем становится неинтерактивным благодаря преобразованию Фиата-Шамира.

Эта логика указана в документе ErgoScript, а конкретные
процедуры доказательства и проверки описаны в его Приложении A.

​Задачи реализации заключаются в:

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

Мы рассмотрели эти два аспекта, основываясь на коде в репозитории sigmastate-interpreter и на документе ErgoScript, тщательно сравнивая предполагаемое поведение (в Приложении A) с фактическим поведением, как оно реализовано.

​Мы особенно рассмотрели код из SigSerializer, Interpreter и ProverInterpreter трейтов и объектов.

​Мы в основном искали ошибки из следующих классов:

• ​Небезопасная обработка неправильно сформированного ввода
• Небезопасная обработка необычно длинного или короткого ввода
• Поведение при большой глубине дерева или уровне рекурсии
• Небезопасное использование типов и структур Scala
• Неподходящие типы переменных
• Переполнение целых чисел
• Условия гонки
• Логические ошибки

​Несмотря на обширный обзор, мы не выявили никаких проблем с безопасностью.

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

Что касается безопасности программного обеспечения, Scala устраняет определенные классы ошибок, но код Scala все еще может страдать от ошибок из-за специфического поведения Scala или из-за необработанных ошибок.

Кошелек

Функциональность кошелька Ergo позволяет его пользователям хранить секрет на диске и восстанавливать его, инициализируя кошелек с новым семенем при первом использовании.

​Эта логика в основном определена в ErgoWalletActor, а ключевым компонентом, касающимся хранения секретов, является JsonSecretStorage.

​В первый раз, когда создается кошелек, команда InitWallet выполняет следующее:

• Генерирует settings.walletSettings.seedStrengthBits случайных бит, в качестве начальной энтропии. По умолчанию генерируется 160 бит.
• Генерирует BIP39 из сгенерированных случайных бит, который можно рассматривать как кодирование бит энтропии. Используется стандартная логика BIP39 с необязательным паролем.
• Выводит семя из мнемоники, используя основанную на PBKDF2 логику вывода BIP39.
• Шифрует это семя на диске с помощью AES-GCM, используя случайный nonce и ключ, полученный из пароля с использованием PBKDF2-HMAC-SHA256 с 128000 итерациями, используя случайную соль.

Чтобы разблокировать уже созданный кошелек, пользователь предоставляет пароль, и кошелек пытается расшифровать сохраненные данные.

​Чтобы восстановить существующий аккаунт из фразы BIP39, выполняется аналогичный процесс инициализации, за исключением того, что кошелек будет выводить семя из мнемоники вместо выбора случайной мнемоники.

​Два риска, которые мы здесь выявили:

• Отсутствие проверок длины пароля: поскольку пароль является достаточным для доступа к семени, учитывая секрет, хранящийся на диске кошелька, пароль должен теоретически иметь как минимум столько же энтропии, сколько мнемоника, и на практике должен быть практически трудным для взлома. Мы, таким образом, рекомендуем установить минимальную длину пароля, например, 16 символов.
• Копии секретных значений (пароль, семя и производные закрытые ключи) вероятно останутся в памяти после выполнения программного обеспечения кошелька, что является внутренним ограничением языков с автоматической сборкой мусора, таких как Scala.

Другой процесс или пользователь, разделяющий то же адресное пространство памяти, потенциально может восстановить секреты, и они также могут появиться в дампах памяти. Насколько нам известно, в чистом Scala нет эффективных мер по смягчению.

​

Проверка PoW

​После предыдущего обзора безопасности Autolykos PoW мы провели еще один раунд проверки, сосредоточив внимание на его последней логике проверки, и особенно на изменениях в коммите eb0f85a.

​Основной соответствующий файл - AutolykosPowScheme, а другие важные операции, например, реализованы в HeadersProcessor и ModifierValidator.

​Мы проверили, что реализованная логика проверки согласуется с указанной в спецификациях Autolykos и что она правильно интегрирована в логику проверки заголовка блока.

​Мы считаем, что следующие моменты должны быть учтены:

• Более строгая проверка k и n: хотя класс требует k<=32 (количество элементов в решении) и n<31 (log2 от общего количества элементов), все еще могут быть созданы слабые из разрешенных параметров. Функция validate() может, следовательно, иметь дополнительную проверку, что n и k равны предполагаемым
  значениям.
• Убедитесь, что k и n являются положительными значениями, так как в настоящее время отрицательные (как Ints) могут пройти assert утверждения.