116 / 736SYBIL

Sybil Attack

Un atacante detrás de muchos participantes aparentemente independientes

Cien cuentas no siempre representan a cien personas. Un Sybil Attack aprovecha esa diferencia: un atacante se presenta como muchos participantes. Por eso Bitcoin no elige su historial contando ordenadores conectados.

En un Sybil Attack, un adversario controla muchas identidades y las presenta como participantes independientes. En Bitcoin, añadir conexiones de red no le da por sí solo más potencia de minería ni permiso para cambiar las reglas. Sí puede ayudarle a influir en las fuentes de información de un nodo concreto.

Ana elige un servicio por las recomendaciones de un foro. Decenas de cuentas lo elogian, pero todas pertenecen al operador del servicio. Ese acuerdo no surgió de opiniones independientes. John R. Douceur describió el problema equivalente en redes informáticas en The Sybil Attack, de 2002: un adversario puede fingir ser varios participantes. Inventar un nombre es fácil; conseguir las direcciones, servidores (ordenadores que prestan servicios a otros) y conexiones necesarios puede costar dinero y tiempo. [1]

En la red Bitcoin, un peer es simplemente la contraparte con la que el programa intercambia datos. Pedro puede ejecutar varios nodos, y una empresa muchos más. Bitcoin no exige un registro de personas que asigne un nodo a cada una. Una dirección IP identifica un punto de la red al que se conecta el programa. Una IP diferente no demuestra, por tanto, que el propietario sea otro. Operar varios nodos tampoco constituye por sí mismo un ataque; el problema es aprovechar su aparente independencia. [1] [3]

El Full Node de Pedro es un programa que comprueba por sí mismo las reglas de Bitcoin. Firmar significa aquí usar una clave privada, un valor numérico secreto, para crear una prueba verificable de autorización del pago. Los demás pueden comprobar la firma sin conocer ese secreto. Aunque todos los peers conectados al nodo de Pedro le envíen una transacción con una firma inválida, la rechazará. Las respuestas coincidentes no cuentan como votos. Un bloque agrupa transacciones en un lote que se añade al historial compartido. El nodo también verifica los bloques completos: por ejemplo, que no gasten fondos ya gastados ni creen una recompensa no permitida. La red proporciona los datos; su validez depende de las reglas del nodo, no de la popularidad del remitente. [2] [6] [9]

A veces existen dos ramas válidas que compiten por representar el historial. Proof of Work permite comparar su trabajo acumulado: un peso derivado de la dificultad de los bloques encontrados. La minería requiere intentos de cálculo reales; cambiar el nombre de un ordenador no añade trabajo. Si un atacante reparte el mismo equipo de minería entre muchas identidades, esa división no aumenta su potencia total. Aquí no funciona la regla de una cuenta, un voto. [2] [6]

Mil conexiones no sustituyen la clave privada necesaria para gastar los bitcoin de otra persona. Multiplicar identidades tampoco permite por sí solo romper las reglas de emisión ni obligar a un nodo que verifica correctamente a aceptar un bloque inválido. Esto no garantiza protección ante cualquier ataque. El adversario podría obtener además potencia de minería o explotar un fallo del programa. Esas capacidades deben evaluarse por separado, no atribuirse al número de cuentas. [2] [9]

Volvamos al nodo de Pedro. Un atacante puede intentar llenar su lista de direcciones conocidas y ocupar sus conexiones. Si controla todas las vías relevantes hacia el resto de la red, puede retener bloques y mostrarle una visión incompleta o retrasada. Ese aislamiento se llama Eclipse Attack. Un Sybil Attack puede facilitarlo, pero muchas identidades del atacante no demuestran que haya logrado aislar el nodo. Verificar datos recibidos no equivale a conocer los que alguien oculta. [3] [5] [8]

Bitcoin Core combina varias barreras. Al elegir automáticamente conexiones salientes busca diversidad de red, y agrupa las direcciones conocidas para dificultar que una sola fuente domine toda la selección. Las conexiones breves de prueba llamadas feeler comprueban si otros peers son accesibles. Estas medidas encarecen el ataque; no identifican al verdadero dueño de cada servidor ni garantizan evitar el aislamiento. La implementación evoluciona: las fuentes muestran aquí Bitcoin Core 29.0. [4] [7] [8]

Una dirección IP o de un servicio Tor indica al programa dónde conectarse. No certifica que al otro lado haya una persona nueva e independiente. Un operador puede tener muchas direcciones, y varios usuarios pueden compartir una IP pública o parte de la ruta de red. Tor resulta útil para la privacidad de la conexión, pero su dirección no prueba por sí sola la independencia de un peer. Encaminar mensajes y ponderar el historial de Bitcoin son cuestiones distintas. [3] [4]

Proof of Work aborda una parte importante del problema de las mayorías ficticias, no todos los riesgos de comunicación. La red P2P — el intercambio directo de datos entre participantes — puede sufrir saturación, vigilancia y retención de mensajes. La defensa incluye también gestionar conexiones y limitar el consumo de recursos. La seguridad depende de lo que controle realmente el atacante: solo nombres, rutas de red, potencia de cálculo o una combinación de esas capacidades. [1] [5] [6]

Un contador de nodos públicamente accesibles no cuenta personas ni votos sobre las reglas. También importan sus fuentes de información y lo que verifican por sí mismos. Un Full Node propio permite comprobar los bloques recibidos, pero necesita conexión con el resto de la red. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Si usa un servidor ajeno, la existencia de muchos nodos en otros lugares no elimina esa dependencia. Tener más contactos no significa automáticamente ser más independiente. [1] [3] [9]

Para obtener la imagen más completa, lee esta entrada junto con Nakamoto Consensus, Eclipse Attack, Selfish Mining, Block Propagation, Bitcoin, Proof of Work. También enlazan con esta entrada Byzantine Generals Problem, Nakamoto Consensus, Eclipse Attack, Selfish Mining.

DOC · 001John R. Douceur — The Sybil AttackFuente primaria DOC · 002Satoshi Nakamoto — Bitcoin whitepaperFuente primaria DOC · 003Bitcoin Developer Guide — P2P NetworkDocumentación DOC · 004Bitcoin Core v29.0 — Peer connectionsDocumentación DOC · 005Heilman et al. — Eclipse Attacks on BitcoinFuente primaria DOC · 006The Bitcoin Backbone ProtocolFuente primaria DOC · 007Bitcoin Core v29.0 — Address managerDocumentación DOC · 008Bitcoin Optech — Eclipse attacksDocumentación DOC · 009Bitcoin Core v29.0 — Block validationDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero