¿Cuándo restaurará Liquid Network los peg outs de Bitcoin?

La red Liquid declaró en su actualización del ecosistema del 28 de septiembre que ya está en marcha una auditoría de seguridad externa de Elements v23.3.4, como parte de su labor para restaurar de forma segura los peg outs tras el incidente de seguridad de septiembre.

Al mismo tiempo, la Federación Liquid está actualizando su lista de Claves de Autorización de Peg out, o PAK. Se están sustituyendo las entradas existentes y la federación trabaja para garantizar que todas las claves de recepción de Bitcoin asociadas a los peg outs estén debidamente protegidas en almacenamiento en frío.

Liquid no facilitó una fecha para la reanudación de los retiros. La red afirmó que la auditoría y los cambios en las PAK son pasos hacia la reanudación de operaciones seguras de peg out, y que se espera otra actualización sobre el proceso de restauración en breve.

La auditoría de Liquid Network se centra en Elements v23.3.4

Elements v23.3.4 se publicó a principios de este mes para corregir el fallo de software explotado durante el incidente del 6 de septiembre, cuando un atacante creó aproximadamente 4.000 LBTC sin respaldo y utilizó el proceso normal de peg out de Liquid para retirar Bitcoin de la reserva de la federación.

La última auditoría externa añade otra revisión de esa versión antes de que se vuelvan a activar los peg outs.

Elements es la plataforma blockchain de código abierto que sustenta Liquid. La red utiliza transacciones confidenciales, que ocultan los importes de las transacciones mientras que las pruebas criptográficas permiten a los nodos verificar que dichos importes son válidos.

La evaluación posterior al incidente de Liquid indicó que la vulnerabilidad afectaba a la forma en que Elements almacenaba en caché los resultados de la verificación de pruebas de rango. Un cambio anterior había eliminado parte del contexto de la transacción de la clave de caché, creando un fallo de consenso que podía permitir reutilizar un resultado de verificación en caché en circunstancias diferentes.

Una corrección posterior abordó el problema identificado inicialmente, pero persistía un segundo problema relacionado con la forma en que se combinaban los campos en la clave de caché. El atacante del 6 de septiembre explotó esa segunda debilidad para crear una salida cuyo valor no estaba respaldado por sus entradas.

Elements v23.3.4 cambió la forma en que se construyen las claves de caché de las pruebas de rango y de sobreyección, serializando cada campo con un prefijo de longitud. Liquid afirmó que el cambio impide que distintos conjuntos de entradas produzcan la misma clave de caché mediante el método de colisión utilizado en el ataque.

La corrección reforzada se fusionó en la rama de lanzamiento de Elements 23.3.x el 8 de septiembre y Elements v23.3.4 se publicó al día siguiente.

Liquid reanudó la producción de bloques después de que los nodos funcionarios recibieran las actualizaciones de software necesarias, mientras que las operaciones de peg permanecieron desactivadas.

Las transacciones volvieron posteriormente a la red a medida que Liquid avanzaba en su proceso de recuperación por fases. Los peg outs han permanecido suspendidos mientras la federación completa el trabajo en la parte del sistema que libera BTC de la reserva.

La Federación Liquid está sustituyendo las entradas PAK

La segunda parte de la actualización del 28 de septiembre se centra en el sistema PAK utilizado para autorizar los peg outs de Liquid a Bitcoin.

Según la arquitectura de Liquid, las entradas PAK contienen dos claves con funciones separadas. Un componente fuera de línea se deriva de la cartera de recepción de Bitcoin de un miembro, mientras que una clave en línea firma las solicitudes de peg out.

Los nodos funcionarios utilizan el componente fuera de línea para verificar que el destino de Bitcoin pertenece a una entrada PAK registrada. Las claves privadas que controlan el Bitcoin receptor están pensadas para permanecer fuera de línea.

El componente en línea desempeña una función diferente. Su clave privada opera en un nodo Elements porque es necesaria para firmar las solicitudes de liberación de Bitcoin a través del proceso de peg out.

La evaluación del incidente de Liquid indicó que la configuración de la cartera fuera de línea pretende proporcionar otra capa de protección si falla un sistema anterior. El Bitcoin liberado a través de un peg out permanecería en una cartera fría y requeriría una acción separada antes de poder moverse.

El incidente del 6 de septiembre expuso una debilidad en esa protección junto con la vulnerabilidad de consenso de Elements.

Tras crear el LBTC sin respaldo, el atacante utilizó SideSwap, un miembro de la Federación Liquid con una PAK, para procesar el peg out. SideSwap recibió aproximadamente 4.000 LBTC a través de su servicio antes de que los firmantes de la federación liberaran aproximadamente 3.996 BTC en Bitcoin.

La evaluación de Liquid indicó que dos problemas separados permitieron la sustracción del Bitcoin: las vulnerabilidades de consenso de Elements y una brecha en la configuración del proceso de firma de la PAK de un miembro de la federación.

SideSwap ha declarado que la federación sabía que su clave de autorización de peg out operaba en línea y que esta configuración había sido visible en sus peg outs durante años. La empresa afirmó que no se le había indicado que cambiara el funcionamiento de la clave ni que suspendiera los peg outs antes del incidente.

SideSwap declaró que estaba revisando cómo se custodia su clave de autorización, así como los límites y controles aplicados antes de los pagos, y que no restablecería sus servicios de peg hasta que tanto la empresa como la federación estuvieran satisfechas con la nueva configuración de seguridad.

La última actualización de Liquid confirma ahora que la federación está sustituyendo las entradas PAK existentes y trabajando para garantizar que las claves de peg out pertinentes se mantengan en almacenamiento en frío antes de que se reanuden los retiros.

Los peg outs siguen siendo la última operación restringida

La actividad normal de transacciones regresó a principios de septiembre, pero el peg de Bitcoin ha permanecido sujeto a restricciones durante la recuperación.

Liquid detuvo inicialmente los nodos puente el 6 de septiembre después de que el atacante explotara el fallo de Elements. La producción de bloques se reanudó el 9 de septiembre utilizando la cadena corregida, seguida del regreso de la actividad de transacciones de los usuarios mientras la federación supervisaba la red.

Los peg outs permanecieron desactivados durante todas esas etapas.

El incidente original provocó la salida de aproximadamente 4.000 BTC de la reserva de la federación después de que el atacante creara LBTC sin respaldo. Los actores se identificaron como sombreros blancos mediante un mensaje en cadena y posteriormente devolvieron 3.400 BTC a la cartera de la federación después de que Blockstream confirmara que los nodos afectados habían sido parcheados.

Aproximadamente 602 BTC siguen sujetos a esfuerzos de recuperación, según la última evaluación detallada del incidente de Liquid.

Blockstream rechazó posteriormente una demanda de recompensa vinculada a los fondos restantes, afirmando que trabajaría con las fuerzas del orden, exchanges, especialistas forenses y otros proveedores de servicios para perseguir su recuperación.

El plan de recuperación por fases de Liquid prevé que las operaciones de peg se reanuden una vez restablecido el estado de la red y completado el trabajo de seguridad requerido. La auditoría externa de Elements v23.3.4 y la sustitución de las entradas PAK son los últimos pasos revelados en el marco de ese proceso.