В августе Vultisig обновил приложения для Android и iOS, чтобы они прекращали автоматические повторные попытки многосторонней подписи, если библиотека сигнализирует о вредоносном участнике. Об уязвимости ChainSecurity сообщила 21 октября: при компрометации одного подписанта атакующий мог отправлять другому вредоносные сообщения и по ответам с ошибками постепенно собирать сведения, позволяющие восстановить долю его ключа. Для пользователей кошельков с распределённой подписью это важно потому, что безопасность зависит не только от разделения ключа, но и от того, прекращает ли приложение обмен данными после критической ошибки.
Ответы с ошибками могли раскрывать данные протокола
Кошельки на основе многосторонних вычислений распределяют право подписи между несколькими долями ключа. В штатном режиме участники совместно формируют стандартную блокчейн-подпись, не восстанавливая полный приватный ключ. Если для операции нужны два устройства и атакующий контролирует только одно, ему, как правило, всё ещё требуется участие второго.
Описанный ChainSecurity сценарий предполагает, что один из участников уже скомпрометирован. Атакующий мог многократно отправлять другому участнику специально сформированные сообщения и отслеживать, возвращает ли приложение ошибку. По оценке исследователей, такие ответы могли постепенно раскрывать сведения о повторно используемом внутреннем seed протокола. При дальнейшем развитии атаки это могло позволить восстановить долю ключа второго участника и в итоге получить полный приватный ключ.
Seed — секретное значение, используемое протоколом внутри процесса подписи. Библиотека исходила из того, что после серьёзной ошибки вызывающее её приложение остановит дальнейшие попытки до смены seed. Старые версии Vultisig не обеспечивали это условие: они показывали общее сообщение о сбое и могли запускать подпись заново. Риск заключался не в том, что неудачная подпись могла быть отправлена в блокчейн, а в продолжении обмена с участником, которого библиотека пометила как вредоносного.
Августовские версии отключают повторные попытки
Изменения в коде для Android и iOS были объединены 21 августа — примерно за два месяца до публичного раскрытия уязвимости. Прежняя логика обрабатывала ошибки подписи, но отдельно не учитывала сигналы библиотеки о блокировке вредоносного участника. Процесс мог повторяться до трёх раз, а пользователю при этом показывалось общее сообщение об ошибке. Этот лимит не указывает, сколько сообщений потребовалось бы для восстановления ключа, и не позволяет определить число сессий, нужное для атаки.
Обновлённые приложения распознают коды ошибок DKLS от 100 до 109 на разных этапах: при настройке сессии, обработке сообщений и завершении подписи. Приложения связывают отмеченного участника с идентификатором устройства, не позволяют автоматическому повтору скрыть ошибку и показывают локализованное предупреждение с просьбой не продолжать использование устройства. Версия для Android также пропускает процедуру восстановления через relay.
Теперь приложение различает обычный сбой подписи и вывод криптографической библиотеки о том, что участник вредоносен. Повторная попытка может помочь при временной технической проблеме, однако дальнейший обмен после команды остановиться способен увеличить объём раскрываемой информации.
Изменения описаны в Android PR #5658 и iOS PR #5235. В примечаниях к выпускам указаны iOS v1.45.71 от 21 августа и Android v1.0.118 от 25 августа; обе версии содержат исправление.
Неясно, какие конфигурации хранилищ были затронуты
Vultisig описывает два варианта подписи. В Fast Vault одна доля хранится на устройстве пользователя, другая — у VultiServer; для подписи участвуют обе стороны. В Secure Vault подпись распределена между двумя или более устройствами пользователя без участия VultiServer. В обоих случаях используется распределённая подпись, но операционные схемы различаются. Наличие двух участников в отдельной сессии не означает, что всё хранилище состоит только из двух долей.
Опубликованные материалы исследования и приложений не содержат полного сопоставления затронутых версий с конфигурациями хранилищ. Поэтому по имеющейся информации пользователи не могут точно установить, какие варианты были уязвимы и какие исторические версии охватывает исправление.
В документации по безопасности Vultisig указано, что Trail of Bits провела в 2024 году аудит библиотеки DKLS23 компании Silence Laboratories. Отчёты об аудите мобильных и настольных приложений, как говорится в документации, должны быть опубликованы позднее. При раскрытии уязвимости ChainSecurity сообщила, что не проверяла исправление Vultisig и не проводила аудит остальных частей протокола. Следовательно, изменения на уровне приложений не входили в её оценку.
Для полной оценки остаётся уточнить, какие выпуски и конфигурации хранилищ были затронуты, а также действует ли остановка не только при автоматических повторах, но и когда пользователь вручную запускает новую сессию подписи. Ключевой вопрос — всегда ли приложение выполняет указание библиотеки прекратить взаимодействие на всех этапах подписания.