Ataques en la entrega de bloques y transacciones en Bitcoin

En la entrega anterior, comentábamos acerca de los ataques comunes en las redes P2P en el protocolo Bitcoin, específicamente, el ataque de Eclipse.

En esta oportunidad, comentaremos acerca de los ataques que atentan contra los tiempos de entrega de bloques y las transacciones en Bitcoin.

A medida que la adopción de Bitcoin se incrementa, sucede lo mismo con el número de transacciones que circulan en la red, así como también el tamaño de los bloques. Por lo tanto, es importante centrar la atención en la escalabilidad y en la adopción de mecanismos que permitan la optimización de la red.

Consideremos primero lo siguiente:

• Nodo atacante o malicioso (A)
• Nodo victima (V)
• Bloque (B)
• Transacción (T)
• Objetos (O), los cuales pueden ser bloques o transacciones

Ahora sí, comencemos:

Un nodo atacante (A) buscará la manera de restringir el flujo de información entre sus pares, empleando un ataque de denegación de servicio (Denial of Service), esto le permitirá restringir la comunicación del nodo victima (V) con sus nodos vecinos para la propagación de la información, aquella referida a las transacciones y a nuevos bloques encontrados para agregarse a la cadena de bloques, que con esfuerzo en tiempo y poder de cómputo hayan logrado los mineros de la red.

Desde la perspectiva más general, consideremos los siguientes aspectos:

• La seguridad en una transacción se fundamenta en el mecanismo de prueba de trabajo PoW (Proof of Work) para validar cada bloque en la red, el consumo de 10 minutos para su resolución y la recomendación de implementar hasta 6 bloques consecutivos para la confirmación de cualquier transacción.
• En este sentido, las transacciones en promedio tardan aproximadamente una hora para ser confirmadas en la red, estimando que se provee de una mayoría (>51%) de la capacidad de computo mantenida por los nodos honestos.

Para lograr minimizar la propagación de información referida a las transacciones, el protocolo Bitcoin implementa un sistema de gestión para que los nodos en la red puedan anunciarse advertisement-based request managment system-, de esta manera, si un nodo recibe información acerca de una nueva transacción (T) proveniente de otro nodo, entonces el nodo advertirá de esa transacción a sus otros pares enviándoles mensajes inv (inventory).

Lo interesante es que el tamaño de ese mensaje es más pequeño que el tamaño de la transacción, puesto que solo contiene el hash y el tipo de objeto que ha sido anunciado, esto se hace con la intención de minimizar el consumo de ancho de banda en la red P2P.

Si el objeto (O) que está siendo anunciado en la red corresponde a un bloque, el nodo receptor primero consultará la cabecera antes de recibir toda la data asociada al bloque y si por alguna razón, el nodo vecino no ha recibido la reciente transacción anunciada por el mensaje inv, entonces éste hará una petición getdata, y a su vez, los clientes Bitcoin mantendrán un registro del orden de las transacciones anunciadas en la red y una política en donde si una petición de información por una transacción dada no es respondida en un lapso de 2 minutos, el próximo nodo en la red será consultado.

Ahora bien, ¿Cómo se gestionan las conexiones lentas y la indisponibilidad en los tiempos de entrega de los bloques y transacciones?

Para ello el protocolo Bitcoin se centra en dos factores: la confiabilidad y la latencia.  Para evitar el bloqueo, se usa el mismo principio de gestión de procesos que usa el kernel en un sistema operativo, se implementa una base de tiempo finita para evitar que se bloquee la espera por la respuesta de un nodo. Por ejemplo, el protocolo Bitcoin implementa un tiempo de descarga de bloque (B) por un espacio de 20 minutos y para transacciones (T), un tiempo de 2 minutos. Estos tiempos de espera están relacionados al ancho de banda, el tamaño del objeto, la latencia, la capacidad de procesamiento, y la versión Bitcoin del nodo.

La cuestión está en que, por un lado, si los tiempos de entrega son muy cortos, se impide la comunicación entre nodos lentos o que sea lo suficientemente efectiva entre los nodos de la red, y si es muy largo, incide en el deterioro de la calidad de servicio de la red y pudieran surgir ataques de doble gasto dirigido por un nodo malicioso.

En todo caso, la implementación de expiración de tiempos de espera, que actualmente se usan en el protocolo Bitcoin, son necesarios para garantizar la correcta entrega de bloques enviados y recibidos en la red.  

A continuación, mostramos como es la interacción entre nodos en una red cuando se intercambia información referente a una transacción y a un bloque.

Dentro de este marco, la red P2P aplica estrategias de mitigación de errores en la propagación de información de las transacciones, para ello, el protocolo Bitcoin combate la dispersión de bloques malformados y transacciones inválidas manteniendo una reputación interna gestionada por el sistema de anuncio de transacciones entre los nodos.

El nodo receptor chequeará el objeto recibido (aplica para un bloque, así como también para una transacción). Por lo que hay factores de descarte: por ejemplo, si el tamaño del bloque es más grande que el permitido; para las transacciones, se verificará la firma y que las transacciones de entrada y salida tengan el balance correcto, así como también la validez de la prueba de trabajo PoW que está alojada en la cabecera del bloque comparada con la dificultad en la red.

¿Qué sucede cuando un nodo malicioso pretenda propagar en la red bloques malformados y transacciones inválidas?

Recibirá penalizaciones, si acumula un total de 100 puntos, será desconectado de la red por 24 horas, con riesgo de ser expulsado de la red. Si envía alertas invalidas, será penalizado con 10 puntos.

El Nodo Atacante: El ataque mediante el retraso en la entrega de información relacionada a las transacciones y a los bloques de la red.

Un nodo malicioso o atacante (A) explota la escalabilidad de la red Bitcoin, para ello, debe asegurarse en ser el primero en enviar el mensaje de anuncio de un objeto (O) al nodo víctima (V). De esta forma, se asegura que (V) no volverá a hacer consulta a otro nodo vecino por la política de ahorro de ancho de banda en la red. Por lo tanto, (A) debe ser el vecino inmediato de (V), esto requiere que haya una conexión directa TCP entre ambos.

Para que se cumpla esta condición, el nodo malicioso implementa un proxy que se encargue de reenviar mensajes inv sin la validación previa del objeto (O).

Por tanto, sin hacer la validación respectiva, (A) gana más tiempo comparado con el resto de los nodos honestos de la red, quienes gastan tiempo y costo computacional en la validación de la transacción. A su vez, (A) además de ser el primero en anunciar la transacción a (V), enviando mensajes inv, mantendrá este comportamiento de manera consecutiva, anunciando la misma transacción una u otra vez, para incrementar el tiempo de envío hasta 2 veces (congestiona a la red).

Luego de (V) haber recibido el mensaje inv, este procederá a solicitar a través del mensaje getdata, información de la transacción, allí el nodo (A) no responderá, se consumirán los 2 minutos de espera, por lo que el nodo (V) interrogará al siguiente nodo de la lista, la cual también pertenece al atacante y entra en un bucle obligado de espera.

¿Cómo el nodo malicioso o atacante logra extender el tiempo de entrega de un bloque?

Para que un nodo (A) niegue la entrega de un bloque por más de 20 minutos, debe cumplirse que:

1. El nodo victima (V) acepte al menos una conexión proveniente del nodo atacante (A).
2. El nodo (A) sea capaz de mantener ocupadas los slots restantes de conexión del nodo (V).

En la red Bitcoin, para que los bloques puedan ser transmitidos, se establece primero una sincronización de sus cabeceras, dada la cabecera de un bloque, cualquier nodo puede conseguir la cadena más larga y verificar el PoW. Una vez sincronizados, el nodo en la red puede de manera selectiva solicitar los bloques correspondientes a sus pares.

Las cabeceras son sincronizadas de dos formas:

1.- Si el nodo (V) recibe un nuevo anuncio de un bloque desconocido a través de un mensaje inv desde el nodo (A), el nodo (V) requerirá la cabecera al nodo (A) con un mensaje getheader.

2.- Una vez que el nodo (A) se conecta con (V), ambos intercambiarán información de la versión de nodos. Cada mensaje de versión contiene un contador con el tamaño más reciente de bloque conocido.

Si el nodo (A) impide la entrega de un bloque (B) al nodo (V) y éste recibe la cabecera de (B) desde otro nodo o par, entonces (A) puede demorar la entrega de (B) por otros 20 minutos más.  Esto porque luego de 20 minutos, (V) se desconectará de (A) y solicitará la petición de (B) a otro nodo en la red. Si el nodo consultado no está bajo el dominio del nodo (A), entonces el nodo (V) se sincronizará con la cadena de bloques de nodos honestos.

Si (V) no recibe la cabecera de (B), entonces no solicitará más peticiones por otros 20 minutos, incluso si ha recibido mensajes inv provenientes de otros nodos.

Por lo tanto, para que se cumpla la condición de denegación de entrega del bloque (B) al nodo victima (V), el nodo atacante (A) debe asegurar:

• Ser el primero en anunciar mensajes inv de todos los bloques a (V). Cuando (A) comienza a impedir la entrega de (B) a (V), y quiere extender la entrega de (B) inclusive en periodos consecutivos, (A) necesitará ser el primero nodo en retransmitir todos los mensajes inv del bloque.

 

• Reducir la cantidad de conexiones al nodo (V), de esta manera, el nodo (V) no debe recibir mensajes de una nueva versión provenientes de otros nodos. Esto se logra si (A) puede mantener todas las conexiones disponibles de (V) ocupadas.

En la siguiente figura se muestra un proceso de denegación de entrega de múltiples bloques por parte de un nodo atacante en la red, y de cómo el nodo victima sufre una pérdida de tiempo de hasta dos bloques de espera.

Explicación del ataque:

En la figura se muestra la denegación en la entrega de dos bloques consecutivos, se asume que el nodo victima (V) recibe la cabecera del bloque B y agrega al bloque en su cadena local. Una vez que B+1 es minado (encontrado), el nodo atacante (A) no hace su entrega a (V). Aquí, comienza un tiempo de 20 minutos de (A) para anunciar el bloque B+1. Una vez que se consigue el bloque B+2, (A) tampoco hace la entrega a (V). Nuevamente, un tiempo de 20 minutos inicia para (A) para anunciar al bloque B+2. Cuando el tiempo para anunciar B+1 expira, (V) no hace petición de bloque porque no sabe de la existencia de nuevas cabeceras de bloques.

De esta manera, (V) solo recibiría las cabeceras si llegase a establecer una nueva conexión con otro par para que le informara de la actualización de la cadena de bloques; o que reciba un mensaje inventory proveniente de otro nodo después de caducar el tiempo de espera, dado este escenario, entonces (A) nuevamente puede denegar el anuncio del bloque B+1 y ganar otros 20 minutos de espera para el bloque B+1.

Supongamos ahora que cuando se consigue al bloque B+3 y (A) no sea el primero nodo en enviar el mensaje inv de B+3, entonces (V) consecutivamente estará solicitando a través de mensajes getheaders y getdata a otros pares de la red. Por otro lado, los bloques B+1 y B+2 por estar demorados en su entrega por (A), (V) solo recibirá información del bloque B+3. Y para validar el bloque B+3 en la cadena de bloques principal, (V) requiere información de los bloques intermedios B+1 y B+2.

Cuando el tiempo de B+2 expira, (V) se desconecta de (A) y solicita información de B+2 a otro par, sin embargo, aún (V) no está habilitado para concatenar B+2 y B+3 a la cadena de bloques, porque le falta información de B+1. Finalmente, cuando expira el tiempo de B+1, (V) solicitará información de B+1 a otro par y de esta manera estará dispuesto a sincronizarse con la cadena de bloques.

Con ello podemos ver el retraso y el daño que consigue el nodo atacante con la denegación y consecuente retraso de la información de los bloques a los nodos de la red, lo que le da ventaja para ejecutar operaciones ilegales tales como el doble gasto e incrementar sus ventajas de minado comparado con el resto de los nodos honestos (selfish mining).

 

Contramedidas:

Tal como lo publica en su investigación el prof Arthur Gervais y su equipo de trabajo [1], se establecen algunas técnicas para mitigar este tipo de ataque en la red, a saber:

Tiempo de espera dinámicos:

En vista de que existen nodos que son más lentos que otros para descargar los bloques, debido a limitaciones de ancho de banda, entonces es necesario implementar tiempos de espera que sean adaptables a la heterogeneidad de la red. Para ello se sugiere la inclusión del tamaño del mensaje al momento de anunciarse en la red, lo cual permitiría a cada nodo estimar dinámicamente el tiempo de expiración de acuerdo a sus recursos y el tamaño del objeto. Es decir, cuando se esté enviando un mensaje de anuncio de bloque, el minero incluye el tamaño del bloque dentro de la cabecera del mismo, con esta política, los nodos receptores pueden conocer el tamaño del bloque y de manera apropiada poder estimar dinámicamente el tiempo de espera. Con esta contramedida, un nodo malicioso se le haría más difícil poder abusar con el retraso de entrega de bloques.

Actualizar el anuncio de bloques:

El estudio sugiere dejar a un lado el uso de mensajes inv para el anuncio de bloques, y únicamente usar las cabeceras antes de la transmisión de los bloques. Con esto, cada nodo receptor inmediatamente verificaría la validez del PoW y aprende acerca de cualquier bloque nuevo que ha sido descubierto en la red. Al mismo tiempo, como el tamaño de la cabecera de un bloque es de 80 bytes, comparado con un mensaje inv que ocupa 36 bytes, tampoco sería un problema una saturación en la red por esta modificación.

Mantener registro del anuncio de bloques:

Tal como ocurre en el anuncio de las transacciones, también debe mantenerse un registro en los nodos de la red respecto al anuncio en las cabeceras de los bloques. Esto permite a un nodo solicitar bloques de aquellos pares que anuncian la cadena más larga. Adicionalmente, permite a un nodo solicitar el anuncio de un bloque desde un par elegido aleatoriamente, en caso de que haya retardo en la entrega del bloque por parte de un nodo.

Gestión en el anuncio de transacciones

La transacción entre los nodos de la cadena de bloques es solicitada por aquellos nodos que primero han anunciado la operación en la red. Si por alguna razón, el nodo no responde y expira el tiempo de anuncio, entonces es consultado el siguiente nodo en la cola FIFO – First In First Out. Esto da una ventaja considerable al nodo atacante en dilatar el tiempo de espera por un nodo para informarse de las transacciones en la red.

Para remediar esta situación, se platea lo siguiente.

• Filtrado por direcciones IP: De manera que solamente se acepte un solo mensaje inv de la misma transacción por dirección IP. Sin embargo, aún quedaría la posibilidad del nodo malicioso en usar varias direcciones IP para anunciar la misma transacción.
• Elección aleatoria del transmisor: Otro mecanismo de mitigación consiste en incrementar aleatoriamente el número de pares a los cuales se les solicita información de la transacción en particular, si el primer nodo solicitado no responde con el getdata.

Por ejemplo, si una transacción en particular es consultada a un nodo, y este no transmite la transacción dentro de la ventana de tiempo establecida, entonces el nodo solicitante consultará a dos nuevos nodos elegidos aleatoriamente de la lista de posibles nodos, luego lo hará a tres nodos, hasta que la transacción sea finalmente recibida. Esta contramedida evita que el nodo malicioso en la cual trata de anunciar la misma transacción varias veces.

• Penalizar a nodos que no respondan: De este modo, cuando un nodo no responda a una solicitud luego de recibir un mensaje getdata, debería ser penalizado y si continúa dilatando la ventana de espera, podría ser desconectado de la red. Esta medida deberá ser bien definida para no afectar a aquellos nodos que sean lentos en los tiempos de respuesta por problemas de conexión o ancho de banda.

 

En la próxima entrega, hablaremos acerca de la privacidad en Bitcoin y los ataques en la capa de red.

Referencias:

[1] Tampering with the Delivery of Blocks and Transactions in Bitcoin. Arthur Gervaisy, Hubert Ritzdorfy, Ghassan O. Karamez and Srdjan Capkun. ETH Zurich, Switzerland, NEC Laboratories Europe, Germany

Regístrate en Binance y obten un 15% de descuento en tus comisiones de por vida con nuestro enlace

Compra ahora tu cuenta Tradingview con este enlace y disfruta de beneficios exclusivos

Abre hoy una cuenta GRATIS en BINGX y disfruta del mejor CopyTrading y descuentos en comisiones