Vultisig actualizó en agosto sus aplicaciones para Android e iOS para que dejaran de reintentar automáticamente firmas multipartitas cuando la biblioteca de firma señalara a un participante como malicioso. La modificación, divulgada por ChainSecurity el 21 de octubre, aborda un fallo que podía permitir a un atacante con control sobre uno de los firmantes recuperar gradualmente la parte de clave de otro participante, mediante el envío de mensajes maliciosos y la observación de las respuestas de error.
El problema afectaba a la firma ECDSA y pone de relieve un riesgo de las carteras que reparten la firma entre varios dispositivos: la seguridad no depende solo de dividir el material de la clave, sino también de que la aplicación interrumpa el protocolo cuando la biblioteca de firma lo indica. Aunque un intento fallido no genere una transacción válida, las respuestas de error pueden revelar información.
Los errores podían revelar una semilla del protocolo
Las carteras basadas en computación multipartita distribuyen la capacidad de firmar entre varias partes de una clave. En una sesión normal, los participantes colaboran para generar una firma estándar de cadena de bloques sin reconstruir la clave privada completa. En una configuración que requiere dos dispositivos, un atacante que controle solo uno normalmente necesitaría la participación del otro para firmar.
El ataque descrito por ChainSecurity parte de que uno de los participantes ya ha sido comprometido. El atacante podría enviar varios mensajes de firma maliciosos al otro participante y observar si este responde con un error. Según los investigadores, esas respuestas podrían revelar poco a poco información sobre una semilla interna reutilizable del protocolo. Si el ataque continuara, el atacante podría llegar a recuperar la parte de clave del otro participante y, en última instancia, reconstruir la clave privada completa.
La semilla es un secreto que el protocolo utiliza internamente. La biblioteca de firma daba por sentado que, tras un error grave, la aplicación que la invocaba detendría nuevas firmas hasta que se rotara la semilla. Las versiones anteriores no aplicaban esa condición: mostraban un mensaje de error genérico y podían seguir reintentando. Por tanto, el riesgo no residía en que una firma fallida pudiera difundirse, sino en que la aplicación continuara comunicándose con un participante al que la biblioteca había marcado.
Las actualizaciones de agosto detienen los reintentos
Los responsables del proyecto incorporaron los cambios pertinentes para Android e iOS el 21 de agosto, cerca de dos meses antes de que el problema se hiciera público. El código anterior comparaba los fallos de firma con los resultados satisfactorios de la biblioteca, pero no trataba por separado los errores que bloquean a un participante malicioso. El proceso podía reintentarse hasta tres veces, mientras que el usuario solo veía un mensaje genérico. Ese límite no indica cuántos mensajes serían necesarios para recuperar una clave ni permite determinar cuántas sesiones requeriría un ataque.
Las aplicaciones actualizadas reconocen los códigos de error de participante malicioso 100 a 109 de la biblioteca de firma DKLS, en etapas que incluyen la configuración de la sesión, el procesamiento de mensajes y la finalización de la firma. Ambas vinculan al participante señalado con un identificador de dispositivo, impiden que los reintentos automáticos oculten el error y muestran una advertencia localizada que indica al usuario que no siga utilizando ese dispositivo. La aplicación para Android también omite el proceso de recuperación mediante relay.
El cambio distingue un fallo de firma ordinario de la determinación de la biblioteca criptográfica de que un participante es malicioso. Reintentar puede ayudar ante un problema temporal, pero seguir interactuando después de que la biblioteca haya indicado que se detenga podría aumentar la exposición de información.
Los cambios están documentados en las solicitudes de modificación PR #5658 para Android y PR #5235 para iOS. Las notas de versión sitúan el lanzamiento de iOS v1.45.71 el 21 de agosto y el de Android v1.0.118 el 25 de agosto; ambas versiones incluyen la corrección.
No está claro qué configuraciones de bóveda se vieron afectadas
Vultisig describe dos modalidades de firma. En una Fast Vault, el dispositivo del usuario guarda una parte de la clave y VultiServer conserva otra; ambos participan en la firma. En una Secure Vault, la firma se distribuye entre dos o más dispositivos controlados por el usuario, sin depender de VultiServer. Las dos modalidades utilizan firma distribuida, pero sus dependencias operativas son distintas. Que una sesión concreta tenga dos participantes no significa necesariamente que la bóveda completa solo cuente con dos partes.
La investigación publicada y la documentación de las aplicaciones no ofrecen una correspondencia completa entre las versiones afectadas y las configuraciones de bóveda. Con la información disponible, los usuarios no pueden saber con precisión qué configuraciones estuvieron expuestas ni cómo cubren las actualizaciones las distintas versiones anteriores.
La documentación de seguridad de Vultisig señala que Trail of Bits auditó en 2024 la biblioteca DKLS23 de Silence Laboratories y que los informes de auditoría de las aplicaciones móviles y de escritorio se proporcionarían tras su publicación. Al divulgar el problema, ChainSecurity indicó que no había revisado la corrección de Vultisig ni auditado otras partes del protocolo. Por tanto, los cambios realizados en las aplicaciones quedaron fuera de su evaluación.
Queda por aclarar qué versiones publicadas y configuraciones de bóveda estuvieron afectadas, y si la condición de parada se aplica tanto a los reintentos automáticos como a los casos en que el usuario inicia manualmente otra sesión de firma. El punto central es si la aplicación hace cumplir de forma consistente la instrucción de la biblioteca de interrumpir las interacciones durante todo el proceso de firma.