Atualizações de agosto bloqueiam vazamento crítico de chave privada na carteira de criptomoedas Vultisig

Vultisig, uma carteira de criptomoedas que utiliza assinatura compartilhada, lidou incorretamente com um sinal de parada crítico em sua implementação de assinatura ECDSA, conforme descobriram pesquisadores de segurança da ChainSecurity.

A divulgação dos pesquisadores em 21 de outubro descreve como continuar após o erro poderia permitir que um signatário já comprometido recuperasse a chave privada completa.

Tanto os mantenedores do Android quanto os do iOS descreveram um código que tentava novamente após a biblioteca identificar um participante malicioso, e depois adicionaram um tratamento para parar essas tentativas e avisar o usuário. As mudanças aparecem nas notas de lançamento do repositório subsequente.

Requerer vários dispositivos oferece proteção apenas se o software preservar essa exigência quando um participante começa a se comportar mal.

Uma carteira de computação multipartidária (carteira MPC) distribui a autoridade de assinatura entre partes de chave. Partes suficientes cooperam para produzir uma assinatura padrão de blockchain sem montar a chave privada completa durante a operação normal.

Em um arranjo de dois dispositivos que requer ambos os participantes, comprometer um deve deixar o atacante dependente da aprovação do outro dispositivo.

O defeito divulgado envolveu a assinatura ECDSA e exigiu aquele compromisso inicial. Um atacante poderia então enviar muitas mensagens de assinatura maliciosas e observar se o outro signatário retornava um erro.

Essas respostas revelaram partes de uma semente de protocolo interno reutilizável, eventualmente permitindo a recuperação da outra parte e da chave completa, de acordo com a ChainSecurity.

Essa semente é um segredo de configuração interna, e a biblioteca assumiu que novas assinaturas parariam após o erro crítico até que a semente fosse rotacionada. O aplicativo exibiu um erro genérico e não impôs essa resposta.

O fluxo ECDSA histórico da Vultisig poderia vazar material de chave através de respostas de erro repetidas; as atualizações de agosto agora param as tentativas e identificam o dispositivo comprometido.

A consequência de segurança é que uma tentativa de assinatura falhada pode importar mesmo quando não produz uma assinatura de transação utilizável.

Se continuar a troca revela mais informações secretas, rejeitar a transação sozinha não preserva a separação prometida entre os signatários. O aplicativo deve responder à falha do protocolo em si.

O que as mudanças de agosto demonstram

A mudança do Android (#5658) e a mudança do iOS (#5235) foram ambas mescladas em 21 de agosto, dois meses antes da divulgação pública.

Suas descrições dizem que o código antigo comparava falhas de assinatura com o resultado de sucesso da biblioteca sem tratar separadamente os erros de banimento de partes maliciosas. As rotinas de assinatura poderiam tentar novamente até três vezes, enquanto o usuário recebia uma mensagem de falha genérica.

Essa contagem de tentativas não estabelece quantas mensagens recuperariam uma chave, ou quantas sessões um atacante precisaria.

As mudanças de código do Android e as mudanças do iOS reconhecem os códigos de erro de parte maliciosa da biblioteca de assinatura DKLS durante a configuração da sessão, processamento de mensagens e conclusão de assinatura.

Ambas mapeiam o participante sinalizado para um identificador de dispositivo, carregam um erro dedicado além das tentativas automáticas e exibem um aviso localizado contra o uso desse dispositivo novamente. No Android, a exceção também contorna a recuperação de retransmissão.

Juntas, essas mudanças mostram que os aplicativos distinguem um veredicto criptográfico sobre um participante de uma falha de assinatura comum.

O comportamento de tentativa apropriado para uma falha temporária pode se tornar perigoso quando a biblioteca está dizendo ao chamador para parar de interagir com um signatário malicioso.

As notas do GitHub para o iOS v1.45.71, datadas de 21 de agosto, listam #5235. O lançamento do Android v1.0.118, datado de 25 de agosto, lista #5658.

Contagens de carteira e escopo de auditoria precisam de contexto

As descrições do cofre da Vultisig distinguem quem controla os signatários. O Fast Vault usa um dispositivo do usuário com o VultiServer segurando a segunda parte e co-assinando. O Secure Vault usa dois ou mais dispositivos mantidos pelo usuário sem o VultiServer.

Uma carteira assistida por provedor e uma carteira espalhada pelos próprios dispositivos de um usuário podem ambas usar assinatura distribuída, mas suas dependências operacionais diferem. Dois participantes em uma troca de assinatura também não precisam significar que o cofre tem apenas duas partes no total.

A divulgação revisada e os materiais do aplicativo não fornecem uma matriz completa de versões afetadas e configurações de cofre.

A documentação de segurança da Vultisig diz que a Trail of Bits auditou a biblioteca DKLS23 dos Silence Laboratories em 2024. Diz que os relatórios de auditoria de aplicativos móveis e de desktop serão vinculados quando publicados.

Na divulgação, a ChainSecurity disse que não havia revisado as correções da Vultisig ou auditado outras partes do protocolo, então as correções permaneceram fora dessa avaliação.

Detalhes úteis de remediação conectariam configurações afetadas a versões enviadas e explicariam a aplicação após reinicializações automáticas e iniciadas pelo usuário. Uma revisão cobrindo esses comportamentos abordaria a falha em nível de aplicativo descrita aqui.

Os detentores de proteção são prometidos que a aplicação depende da aplicação para impor a condição de parada da biblioteca durante toda a assinatura, incluindo quando os usuários começam novamente após uma falha.