Обновления августа блокируют утечку критического закрытого ключа в криптокошельке Vultisig

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

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

Как разработчики для Android, так и для iOS описали код, который повторно пытался выполнить операцию после того, как библиотека выявила злонамеренного участника, а затем добавили обработку для остановки этих повторных попыток и предупреждения пользователя. Изменения отражены в последующих примечаниях к выпускам репозитория.

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

Кошелек для многопартийных вычислений (MPC-кошелек) распределяет полномочия подписи между долями ключа. Достаточное количество долей сотрудничает для создания стандартной подписи блокчейна без сборки полного закрытого ключа в процессе нормальной работы.

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

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

Эти ответы раскрыли части повторно используемого внутреннего семени протокола, в конечном итоге позволяя восстановить другую долю и полный ключ, согласно ChainSecurity.

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

Исторический поток ECDSA Vultisig мог утекать ключевые материалы через повторные ответы с ошибками; обновления августа теперь останавливают повторные попытки и идентифицируют скомпрометированное устройство.

Безопасные последствия заключаются в том, что неудачная попытка подписи может иметь значение, даже если она не производит ни одной используемой подписи транзакции.

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

Что демонстрируют изменения августа

Изменения для Android (#5658) и iOS (#5235) были объединены 21 августа, за два месяца до публичного раскрытия.

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

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

Изменения кода для Android и изменения для iOS распознают коды ошибок злонамеренной стороны библиотеки подписи DKLS в диапазоне 100--109 во время настройки сессии, обработки сообщений и завершения подписи.

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

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

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

Примечания GitHub для iOS v1.45.71, датированные 21 августа, перечисляют #5235. Выпуск Android v1.0.118, датированный 25 августа, перечисляет #5658.

Количество кошельков и объем аудита требуют контекста

Описание хранилищ Vultisig различает, кто контролирует подписантов. Fast Vault использует одно устройство пользователя с VultiServer, удерживающим вторую долю и совместно подписывающим. Secure Vault использует два или более устройств, находящихся у пользователя, без VultiServer.

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

Рассмотренные раскрытия и материалы приложения не предоставляют полной матрицы затронутых версий и конфигураций хранилищ.

Документация по безопасности Vultisig говорит, что Trail of Bits провела аудит библиотеки Silence Laboratories DKLS23 в 2024 году. Она говорит, что отчеты об аудите мобильных и настольных приложений будут связаны, когда будут опубликованы.

На момент раскрытия ChainSecurity заявила, что она не проверяла исправления Vultisig или не проводила аудит других частей протокола, поэтому исправления остались вне этой оценки.

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

Держатели защиты обещают, что выполнение зависит от приложения, обеспечивающего условие остановки библиотеки на протяжении всей подписи, включая случаи, когда пользователи начинают снова после неудачи.