El último análisis de vulnerabilidad de Lightning Network: solo es necesario atacar 85 nodos para robar los fondos del canal de nodos Lightning

Aviv Zohar, profesor asociado de la Escuela de Ingeniería y Ciencias de la Computación de la Universidad Hebrea, la institución más importante de Israel, y Jona Harris, estudiante de posgrado de la Universidad Hebrea, publicaron recientemente un artículo de investigación "Inundaciones y saqueos: un ataque sistemático en la Red Lightning". Se propone un ataque sistemático a Lightning Network. El atacante puede robar los fondos bloqueados en el canal de pago a través de un ataque sistemático a Lightning Network. En este ataque, el atacante obliga a una gran cantidad de víctimas a exigir fondos de la cadena de bloques, y luego puede usar la congestión para robar fondos que no fueron reclamados antes de la fecha límite. El documento demuestra que solo se necesitan 85 canales atacados simultáneamente para garantizar que un atacante pueda robar algunos fondos. Además, el artículo propone varias técnicas de mitigación frente a este ataque. Se sabe que la red de canales de pago de Lightning Network es vulnerable a la congestión de la cadena de bloques, y si la red es atacada, es posible que los participantes no puedan retirar fondos de manera oportuna. En nuestro último artículo, evaluamos uno de esos ataques: un ataque sistemático a Lightning Network que puede robar fondos bloqueados en los canales de pago. En este ataque, el atacante obligó inmediatamente a muchas víctimas a acudir en masa a la cadena de bloques, exigiendo sus fondos. Los atacantes pueden usar la congestión que han creado para robar todos los fondos que no hayan sido reclamados antes de la fecha límite. Las consecuencias de un ataque dependen de la implementación de Lightning Network que elija atacar el atacante. Demostramos que un atacante solo necesita atacar 85 canales simultáneamente para robar fondos dentro de los canales (esto supone que ninguna otra transacción de blockchain compite por espacio de bloque, lo cual es una suposición muy optimista). Además de entender este ataque y sus consecuencias en general, en este artículo proponemos varias técnicas para mitigar este ataque. Nota: El ataque puede permitir que se roben los fondos de usuarios inocentes. No intentes este ataque en casa. Desafortunadamente, actualmente no hay ningún cambio de protocolo que lo elimine por completo. Los hallazgos de este documento se compartieron con los desarrolladores de las tres principales implementaciones de clientes de Lightning Network antes de su publicación. El número de nodos de Bitcoin Lightning Network es 36 186: Jinse Finance informó que los datos del sitio web de 1ML muestran que el número de nodos de Bitcoin Lightning Network (Lightning Network) es 36 186, un aumento interanual del 2,26 %; el número de canales es 86 168 , una disminución interanual del 1,2%; la capacidad es de 3.726,38 BTC, un aumento interanual del 6%. [2022/4/10 14:15:16] El ataque aprovecha un mecanismo para reenviar pagos a través de múltiples canales Lightning: contratos de bloqueo de tiempo hash (HTLC). En resumen, los HTLC permiten a los participantes enrutar los pagos a través de nodos intermediarios sin confianza, lo que garantiza que ninguno de ellos pueda robar fondos. Si dicho nodo intenta robar fondos, sus pares pueden reclamar los fondos publicando una transacción en la cadena de bloques, pero solo por un tiempo limitado. Como hemos demostrado en nuestro trabajo, es relativamente fácil inundar una cadena de bloques con nodos Lightning inocentes y explotar este límite de tiempo para robar fondos. La idea clave detrás de HTLC es que, después de que se establece un HTLC, el nodo de destino "arranca" un pago del nodo anterior en la ruta al proporcionar un secreto (una preimagen hash). El atacante enrutará el pago entre dos de sus propios nodos y retirará el pago al final de la ruta. Cuando finalmente se retire el pago del nodo de origen, se negará a cooperar, lo que obligará a la víctima a reclamarlo a través de una transacción de cadena de bloques. Este ejemplo de topología muestra el nodo del atacante y el canal que compartió con la víctima, según los datos de hace unos días aumentó un 7,41% mes a mes, el número de canales fue de 42219, lo que supuso un aumento del 6,5%. en comparación con los datos de hace 30 días, la capacidad de carga de Lightning Network es actualmente de 1205,24 BTC, lo que equivale a unos 66,4944 millones de dólares estadounidenses. [2021/4/19 20:33:58] El ataque se divide en cuatro etapas principales: El atacante controla dos nodos Lightning, que representan el nodo de origen y el nodo de destino respectivamente. El nodo de origen abre canales a muchas víctimas potenciales, posiblemente múltiples canales para cada víctima. Estos canales son iniciados y financiados por el nodo de origen del atacante (el nodo de destino puede estar lejos de la víctima, pero en el siguiente diagrama simplificamos el proceso y mostramos solo una ruta corta y simple). Fase 1: Establecimiento del canal Después de configurar todos los canales, el nodo de origen comenzará a realizar muchos pagos HTLC al nodo de destino, enrutados a través del canal de cada nodo de origen. El nodo de origen envía la cantidad máxima permitida para ser retransmitida y la distribuye entre tantos pagos como permita la víctima. Como parte del mecanismo HTLC, el nodo de destino debe aceptar el pago devolviendo un conjunto de secretos HTLC. Este ataque evitará hacerlo hasta que el nodo de origen haya terminado de reenviar todos los pagos. El número de nodos de Lightning Network ha llegado a 17.033: según Jinse Finance, según los datos de 1ML.com, el número de nodos que soportan la red ha llegado a 17.033, lo que supone un aumento del 6,64 % en comparación con los datos de hace 30 días; el número de canales es 38,065, en comparación con 30 Según los datos de hace unos días, el aumento mensual fue del 3.7%; la capacidad de carga de Lightning Network es actualmente 1086.3 BTC, que es alrededor de 56.5261 millones de dólares estadounidenses. [2021/2/22 17:41:00] Fase 2: usar el pago HTLC para cargar el canal Después de completar con éxito el envío de todos los pagos y agregar HTLC al canal del nodo de destino, el nodo de destino resolverá todos los pagos realizados, y reclama esos fondos para ti. En este punto, el nodo de destino puede cerrar su canal normalmente y quedarse con los fondos enviados por el nodo de origen. Una vez que cada víctima ha adquirido estos secretos, los envía de regreso al nodo de origen, solicitando analizar el HTLC y mover su cantidad al lado de la víctima del canal. El nodo de origen se niega a analizar el pago e ignora cualquier otro mensaje de su víctima. Fase 3: Analizar el pago en el último salto En este punto, cada canal atacado está lleno de HTLC aún por analizar, cuyos secretos conoce la víctima. Dado que el nodo de origen del atacante no coopera, la única forma en que la víctima puede acceder a estos pagos es cerrar su canal y reclamar el HTLC en la cadena de bloques. La víctima tiene un tiempo limitado (en bloques) para reclamar el pago (o un límite de tiempo si el nodo no conoce estos secretos, en cuyo caso los fondos deben ser reclamados por el nodo de origen). Una vez que caducan, el atacante puede gastar la salida del HTLC. Aunque la víctima aún puede reclamar el HTLC después de la expiración, los detalles específicos del protocolo le dan al atacante una gran ventaja: Golden Relativity | En "Lightning Network: Hello, TPS", Tong Yang, socio de Jinse Finance, tuvo una conversación con Pan Zhibiao, el fundador de Biyin. Con respecto a la ruta de evolución futura y las perspectivas de aplicación de Lightning Network, Pan Zhibiao dijo: Una red de conexiones. Toda la red no puede funcionar solo con nodos grandes. Los nodos están distribuidos en la red, algunos son personales y otros son empresariales. Algunos nodos son muy grandes, con decenas de miles de canales, algunos nodos son pequeños, con varios canales. Los nodos de red Lightning tienen un umbral relativamente bajo. Cualquier ingeniero de software puede construir rápidamente un nodo, y la gente común también puede construir rápidamente un nodo con la ayuda de herramientas técnicas. Mientras el mercado esté abierto y la competencia sea libre, la red básicamente permanecerá descentralizada. En cuanto a la anticensura, debido a que el flujo pasa a través de N nodos, la privacidad es mucho mejor que la de la transacción de bitcoin enviada directamente. La mayoría de los intercambios necesitan hacer KYC, y casi no hay privacidad para las transacciones en cadena, pero la privacidad de Lightning Network es muy buena. En cuanto a la ruta de evolución y las perspectivas de aplicación, es principalmente en el campo de pago.En la actualidad, los nodos independientes aún dominan. La mayoría de las billeteras Lightning Network actuales todavía no son billeteras Lightning Network reales. La dirección de popularizar Lightning Network sigue siendo onchain + nodos independientes. [2019/3/7] La ​​víctima no puede establecer la tarifa de transacción al publicar la transacción. La tarifa se determina cuando se abre el canal. El atacante puede establecer la tarifa para su propia transacción como lo desee, y reemplazar cualquier transacción de la víctima que no haya sido confirmada después del vencimiento (usando la estrategia "Reemplazar por tarifa") por atacando múltiples canales y obligando a todos los canales a cerrarse al mismo tiempo (establecer el mismo tiempo de caducidad para todos los HTLC), las transacciones de propiedad de reclamación de HTLC de algunas víctimas no se confirmarán a tiempo y el atacante las robará. Voz | He Yi: Lightning Network ha mejorado en gran medida la velocidad de transferencia, pero Binance presta más atención a la seguridad en sí misma: se le preguntó a He Yi, el cofundador de Binance, en una entrevista: "¿Binance Exchange admitirá Bitcoin Lightning Network? este año?" Al discutir el plan", dijo He Yi, "La Lightning Network de hecho ha mejorado en gran medida la velocidad de transferencia, pero Binance presta más atención a la seguridad en sí misma, por lo que esto requiere una evaluación exhaustiva por parte del equipo. Además, depende sobre cómo definir el plan Bitcoin Lightning Network. Por ejemplo, algunas monedas han tomado prestada o utilizado Lightning Network, y también hemos lanzado este tipo de token. Así que creo que tenemos que esperar hasta que toda la industria madure antes de tomar la decisión correspondiente. .” [2019/2/17] Por lo tanto, el ataque El atacante retiene algunos fondos que deberían haber ido a la víctima (los fondos del siguiente salto de la víctima se enviaron al nodo de destino del atacante). Fase 4: Recopilación de salidas no gastadas después del vencimiento Para mostrar la viabilidad del ataque, realizamos una simulación en Lightning Network local en el registro de red de prueba de Bitcoin. Implementamos un prototipo de un nodo atacante capaz de bloquear la transmisión de secretos de HTLC, ignorar solicitudes para analizar HTLC y emitir transacciones de propiedad de reclamo de HTLC con tarifas más altas. Dado que LND es la implementación Lightning más popular en la actualidad (se informa que más del 90 % de los nodos Lightning en la red ejecutan LND), lo usamos para simular nodos víctimas. Como se muestra en la figura a continuación, atacar 85 canales asegura un ataque exitoso incluso si todo el espacio disponible en el bloque (tamaño máximo del bloque) se asigna a la transacción de la víctima. Cada vez que se agrega un canal, también se robarán todos sus fondos. El número de HTLC robados con éxito para diferentes números de canales atacados y tamaños de bloque. El tamaño de bloque máximo actual de Bitcoin es 4M (correspondiente a la línea verde). De hecho, las Transacciones Lightning tienen menos de todo el espacio disponible. Como se muestra, cuando el espacio disponible en cada bloque disminuye, se necesitan menos víctimas para robar la misma cantidad de HTLC. Demostramos que este puede ser el caso cuando el atacante utiliza la estrategia de "minimización conjunta" (descrita a continuación). El número de HTLC robados con éxito para diferentes números de canales atacados y tamaños de bloque. El peso de bloque máximo actual de Bitcoin es 4M (correspondiente a la línea verde). De hecho, las transacciones Lightning tienen menos espacio libre que todos los gráficos y, a medida que disminuye el espacio libre en cada bloque, se necesitan menos víctimas para robar la misma cantidad de HTLC. Demostramos que este puede ser el caso cuando el atacante utiliza la estrategia de "minimización de feerate" (descrita a continuación). La tarifa pagada por cada transacción de la víctima proviene del parámetro Feerate del canal. Esta tarifa la determina y paga el iniciador del canal (en nuestro caso, el nodo de origen del atacante). Antes de abrir un canal, otro nodo debe aceptar el avance establecido por el canal. Si el nodo cumple con su estimación de la tarifa de blockchain, el nodo acepta establecer una tarifa, determinada por el método de estimación de bitcoind. Como se puede ver en la figura siguiente, el valor estimado de la velocidad de avance puede fluctuar mucho en un período de tiempo relativamente corto. Cuando el canal se cierra unilateralmente, es posible que una tarifa de canal determinada en un momento dado no se aplique en un momento posterior. Tasa de tarifa estimada por Bitcoind para confirmación inmediata (Satoshi/byte) Además de establecer la tasa de tarifa inicial del canal, el iniciador del canal también puede proponer una nueva tarifa de tarifa en cualquier momento después de que se abra el canal para ajustarla al estado actual de la tarifa de cadena del bloque . El protocolo Lightning establece que, en nuestro caso, la otra parte (es decir, la víctima) no puede realizar ninguna solicitud de actualización de la tasa de avance. En la estrategia de "minimización de tasa de tarifa", el atacante utiliza el mecanismo de actualización de tarifas para reducir la tarifa de tarifa del canal cuando sea posible (es decir, cuando la tarifa de blockchain es baja (para que la otra parte acepte el cambio)), pero desde las actualizaciones se realizan cuando las tarifas de blockchain son altas. Una vez que la diferencia entre la tasa de tarifa del canal y la tasa de tarifa real de la cadena de bloques se vuelve grande, un atacante puede comenzar a iniciar todos los pagos de HTLC y lanzar un ataque. En el siguiente gráfico, vemos el espacio de bloque promedio disponible para la víctima cuando el atacante usó la estrategia de minimización de la velocidad de transmisión durante 3 y 7 días. Por ejemplo, cuando el atacante trató de minimizar las tarifas 7 días antes de comenzar el ataque, la víctima tuvo acceso a un promedio de la mitad del espacio del bloque solo el 58% del tiempo o más (durante un período de recopilación de datos de 2 meses) cuando Espacio de bloque promedio disponible para las transacciones de las víctimas cuando se utiliza la estrategia de "minimización de la tarifa". En este trabajo, también mostramos que encontrar víctimas potenciales no es una gran cantidad de trabajo para el atacante. Para que un nodo sea víctima de un ataque, el nodo solo necesita aceptar una solicitud para abrir un canal con el atacante. Como se describe en el protocolo Lightning, un nodo puede indicar su voluntad de abrir un canal respondiendo al mensaje "accept_channel" y no necesita abrir el canal en este momento. Realizamos un experimento en el que se probó la disposición de muchos nodos de la red para abrir un canal con un nodo desconocido. Descubrimos que la gran mayoría de los nodos activos (~95%) están dispuestos a abrir canales en esta solicitud y, por lo tanto, son víctimas fáciles de este ataque. Respuesta del nodo a la solicitud "open_channel" Para este tipo de ataque, varias técnicas pueden hacer que sea más difícil para el atacante y reducir el daño potencial del ataque. A continuación se presentan algunas de las técnicas de mitigación que proponemos. 1) Reducir la cantidad máxima de HTLC sin resolver: la cantidad máxima de pagos que un atacante puede enrutar a través del canal atacado está determinada por el parámetro del canal "max_accepted_htlcs". Si el valor de este parámetro se mantiene bajo, el atacante tendrá que atacar más canales para robar fondos con éxito. 2) Cierre anticipado del canal: el momento (bloque) en el que la víctima reclama sus fondos está determinado por un parámetro específico de la implementación. La mayoría de las implementaciones de Lightning usan valores mucho más pequeños de los que posiblemente podrían usar (para evitar cerrar canales prematuramente)

Tags：

ICP