Actualizaciones de agosto bloquean filtración crítica de claves privadas en la billetera de criptomonedas Vultisig

Vultisig, una billetera de criptomonedas que utiliza firmas compartidas, manejó incorrectamente una señal de parada crítica en su implementación de firma ECDSA, como encontraron los investigadores de seguridad en ChainSecurity.

La divulgación del 21 de octubre de los investigadores describe cómo continuar después del error podría permitir que un firmante ya comprometido recupere la clave privada completa.

Tanto los mantenedores de Android como de iOS describieron un código que reintentó después de que la biblioteca identificara a un participante malicioso, y luego añadieron un manejo para detener esos reintentos y advertir al usuario. Los cambios aparecen en las notas de lanzamiento del repositorio subsiguiente.

Requerir varios dispositivos ofrece protección solo si el software mantiene ese requisito cuando un participante comienza a comportarse mal.

Una billetera de computación multipartita (billetera MPC) distribuye la autoridad de firma entre partes de claves. Suficientes partes cooperan para producir una firma estándar de blockchain sin ensamblar la clave privada completa durante la operación normal.

En un arreglo de dos dispositivos que requiere ambos participantes, comprometer uno debería dejar al atacante dependiente de la aprobación del otro dispositivo.

El defecto divulgado involucró la firma ECDSA y requirió ese compromiso inicial. Un atacante podría entonces enviar muchos mensajes de firma maliciosos y observar si el otro firmante devolvía un error.

Esas respuestas revelaron partes de una semilla de protocolo interno reutilizable, lo que eventualmente permitió la recuperación de la otra parte y la clave completa, según ChainSecurity.

Esa semilla es un secreto de configuración interno, y la biblioteca asumió que más firmas se detendrían después del error crítico hasta que la semilla fuera rotada. La aplicación mostró un error genérico y no hizo cumplir esa respuesta.

El flujo ECDSA histórico de Vultisig podría filtrar material de clave a través de respuestas de error repetidas; las actualizaciones de agosto ahora detienen los reintentos e identifican el dispositivo comprometido.

La consecuencia de seguridad es que un intento de firma fallido puede importar incluso cuando no produce una firma de transacción utilizable.

Si continuar el intercambio revela más información secreta, rechazar la transacción por sí solo no preserva la separación prometida entre los firmantes. La aplicación debe responder a la falla del protocolo en sí misma.

Lo que demuestran los cambios de agosto

El cambio de Android (#5658) y el cambio de iOS (#5235) se fusionaron el 21 de agosto, dos meses antes de la divulgación pública.

Sus descripciones dicen que el código antiguo comparaba fallos de firma con el resultado de éxito de la biblioteca sin manejar por separado los errores de prohibición de partes maliciosas. Las rutinas de firma podían reintentarse hasta tres veces, mientras que el usuario recibía un mensaje de fallo genérico.

Ese conteo de reintentos no establece cuántos mensajes recuperarían una clave, o cuántas sesiones necesitaría un atacante.

Los cambios en el código de Android y los cambios en iOS reconocen los códigos de error de parte maliciosa de la biblioteca de firma DKLS durante la configuración de sesión, el procesamiento de mensajes y la finalización de la firma.

Ambos mapean el participante señalado a un identificador de dispositivo, llevan un error dedicado más allá de los reintentos automáticos y muestran una advertencia localizada contra el uso de ese dispositivo nuevamente. En Android, la excepción también elude la recuperación de retransmisión.

Juntos, esos cambios muestran que las aplicaciones distinguen un veredicto criptográfico sobre un participante de un fallo de firma ordinario.

El comportamiento de reintento apropiado para un fallo temporal puede volverse peligroso cuando la biblioteca le dice al llamador que deje de interactuar con un firmante malicioso.

Las notas de GitHub para iOS v1.45.71, fechadas el 21 de agosto, enumeran #5235. La versión de Android v1.0.118, fechada el 25 de agosto, enumera #5658.

Los conteos de billetera y el alcance de auditoría necesitan contexto

Las descripciones de la bóveda de Vultisig distinguen quién controla a los firmantes. Fast Vault utiliza un dispositivo de usuario con VultiServer sosteniendo la segunda parte y co-firmando. Secure Vault utiliza dos o más dispositivos sostenidos por el usuario sin VultiServer.

Una billetera asistida por un proveedor y una billetera distribuida entre los propios dispositivos de un usuario pueden utilizar firmas distribuidas, pero sus dependencias operativas difieren. Dos participantes en un intercambio de firma tampoco necesitan significar que la bóveda tenga solo dos partes en total.

La divulgación revisada y los materiales de aplicación no proporcionan una matriz completa de versiones afectadas y configuraciones de bóveda.

La documentación de seguridad de Vultisig dice que Trail of Bits auditó la biblioteca DKLS23 de Silence Laboratories en 2024. Dice que los informes de auditoría de aplicaciones móviles y de escritorio se vincularán cuando se publiquen.

En la divulgación, ChainSecurity dijo que no había revisado las correcciones de Vultisig ni auditado otras partes del protocolo, por lo que las correcciones permanecieron fuera de esa evaluación.

Los detalles de remediación útiles conectarían configuraciones afectadas con versiones enviadas y explicarían la aplicación después de reinicios automáticos e iniciados por el usuario. Una revisión que cubriera esos comportamientos abordaría el fallo a nivel de aplicación descrito aquí.

Se promete a los titulares de protección que la aplicación depende de hacer cumplir la condición de parada de la biblioteca durante toda la firma, incluso cuando los usuarios comienzan de nuevo después de un fallo.