I2P: Una red anónima que deberías conocer

Quizás nos suene las siglas I2P, posiblemente nos venga a la mente una red anónima no muy conocida, pero lo más seguro es que automáticamente pensemos en Tor cuando necesitemos soluciones que nos aporten privacidad y anonimato.

Tal y como hemos visto en artículos anteriores sobre anonimato y especialmente sobre Tor (en cuanto a sus servicios ocultos y vulnerabilidades), ha quedado de manifiesto su gran popularidad, visibilidad, y respaldo tanto académico como de la comunidad.

Sin embargo en este artículo vamos a mirar más allá de Tor para conocer una red anónima alternativa muy interesante llamada I2P (Invisible Internet Project). Pero como primer artículo, lo haremos partiendo de unos conceptos clave y dando los detalles técnicos necesarios (dada la complejidad del proyecto) para empezar a entender el funcionamiento de I2P.

Introducción

I2P nace en 2003 como una red anónima completamente descentralizada y autogestionada basada en mensajes con el objetivo de proporcionar un alto nivel de anonimato en las comunicaciones al dificultar de forma continua los ataques que se puedan producir.

Aunque otras redes como Tor o Freenet hayan surgido casi al mismo tiempo y cada una de ellas tenga un caso de uso distinto, al final todas persiguen el mismo fin: proteger el anonimato y la privacidad de los usuarios finales. Pero con el paso de los años Tor se ha convertido en la red anónima por excelencia, dejando en un segundo plano a otras redes que cuentan con un gran potencial como I2P (sobre todo por su modelo de comunicación).

A diferencia de otras redes anónimas, I2P no trata de preservar el anonimato ocultando el origen y el destino de una comunicación, ya que el hecho de encontrarse en esta red no es ningún secreto. I2P está diseñado para que toda la actividad que se lleve a cabo en la red permanezca oculta y los pares puedan comunicarse entre sí de forma anónima, no solo entre ellos sino también para aquellos terceros que puedan estar escuchando.

Básicamente, el propósito de I2P es permitir a los usuarios comunicarse de forma anónima en entornos hostiles donde todos los mensajes generados, tanto por aquellos usuarios que necesitan un alto nivel de anonimato como los que no, acaban mezclándose en la misma red generando el suficiente tráfico que impida distinguir unos mensajes de otros.

Conceptos clave en I2P

Una red I2P está formada por un conjunto de nodos o routers que a través de una serie túneles (temporales y unidireccionales) permiten que estén conectados. En el momento que un usuario decide conectarse a I2P, automáticamente pasa a formar parte de la red como un router más aportando una parte de su ancho de banda. Es decir, no se ruega a nadie que ponga a disposición de la red un router para contribuir con su ancho de banda.

Routers, servicios y destinos

Por una parte, I2P hace una clara distinción entre los propios routers y los servicios que los usuarios puedan tener publicados de forma anónima en cada uno de ellos.

Gracias a estos servicios, los usuarios podrán ofrecer en la red una serie de endpoints o destinos locales (local destinations) asociados a las aplicaciones que tengan en ejecución, para que dentro de I2P puedan ser utilizados por otros usuarios.

En pocas palabras, se podría decir que un destino permite el intercambio de mensajes, tanto el envío como la recepción, en un router determinado para una dirección IP y puerto concretos. Por ejemplo, en I2P se pueden encontrar destinos que pueden servir para distintos fines: servidores web anónimos (también conocidos como eepsites), servidores de correo, IRC, SSH, etc.

Túneles

Por otra parte, el concepto de túnel en I2P es clave para entender el funcionamiento de esta red anónima.

El objetivo principal de los túneles es el enrutamiento de mensajes a través de un conjunto de routers, previamente seleccionados y de un número configurable, hacia un destino concreto. Estos túneles son creados de forma temporal y solo permiten que la comunicación viaje en un único sentido (nunca de forma bidireccional), ya sea para enviar mensajes utilizando un túnel de salida (outbound tunnels) o bien para recibir mensajes utilizando un túnel de entrada (inbound tunnels).

El hecho de que estos túneles sean completamente independientes dificulta realmente no solo los ataques de análisis de tráfico sino también los ataques de correlación. Ya que los túneles de entrada y de salida no guardan ningún tipo de relación, y solo el usuario que los crea conoce exactamente los routers por los que pasan los mensajes.

Para poder explicar mejor ambos tipos de túneles, se parte de un ejemplo muy sencillo en el que Alice quiere enviar un mensaje a Bob:

Alice utiliza un túnel de salida para enviar un mensaje a través de un túnel de entrada de Bob (fuente)

En este ejemplo se representa en verde un túnel de salida (outbound tunnel, A-B-C) utilizado por Alice para el envío de un mensaje a un túnel de entrada (inbound tunnel, D-E-F) de Bob representado en rosa. Mencionar de nuevo que los túneles son unidireccionales, y en caso de que Bob quisiera contestar al mensaje de Alice, se necesitarían dos túneles más en sentido contrario: uno de salida por parte de Bob, y otro de entrada por parte de Alice.

Ya sea un túnel de salida o un túnel de entrada, cada uno de ellos contará con una serie de routers que podrán tomar alguno de los siguientes roles:

• Tunnel gateway. Se trata del primer router del túnel, pudiendo ser el router que reciba los mensajes enviados por Alice (A) en un túnel de salida, o bien el router que reciba los mensajes dirigidos hacia Bob (D) en un túnel de entrada.
• Tunnel endpoint. En este caso se trata del último router del túnel encargado de la entrega de mensajes, pudiendo ser el router que entregue los mensajes enviados por Alice (C) al gateway de un túnel de entrada de Bob, o bien el router que entregue finalmente los mensajes a Bob (F).
• Tunnel participant. Son todos aquellos routers intermedios encargados de enrutar los mensajes provenientes del gateway hacia el endpoint, ya sea en un túnel de salida (B) o de entrada (E).

De todos los roles vistos, el único que no es obligatorio a la hora de construir un túnel es el de participant. Esto dependerá de la longitud del túnel que podrá configurarse en función del número de saltos deseado: (hasta un máximo de 7)

• 0-hop tunnel. Túneles formados por un único router, el cual adopta el rol de gateway y endpoint.
• 1-hop tunnel. Túneles sin participants, formados por un gateway y un endpoint que se comunican directamente, sin intermediarios.
• 2-hop tunnel. Túneles que cuentan con un gateway, un participant, y un endpoint como se ha visto en el ejemplo anterior.
• n-hop tunnel. Túneles formados por un gateway, n-1 participants, y un endpoint.

El número de saltos elegido para la construcción de los túneles podrá afectar de forma significativa a ciertos parámetros que proporciona la propia red I2P: latencia, rendimiento, fiabilidad, anonimato.

Por ejemplo, cuanto mayor sea el número de routers que formen un túnel, mayor será el tiempo que necesiten los mensajes en llegar a sus destinos, y mayor será la probabilidad de que algún router falle inesperadamente cortándose la comunicación. Sin embargo, desde el punto de vista de un atacante, mayor será el esfuerzo que tendrá que invertir para realizar un ataque de análisis de tráfico y comprometer el anonimato. De hecho en I2P, de forma predeterminada se usan 2 o 3 saltos para los túneles, donde recomiendan utilizar al menos 3 para contar con el nivel más alto de protección.

NetDb (Network Database)

Una vez visto de forma resumida cómo se forman los túneles y cuál es su misión en I2P, hay que hacer referencia a otro elemento clave en el funcionamiento de esta red anónima: una base de datos distribuida llamada netDb (network database).

I2P utiliza de forma interna su propia base de datos (a partir de una modificación de Kademlia) para distribuir de forma segura la información necesaria para contactar con los routers (RouterInfo) y los destinos (LeaseSet).

Esta información se almacena firmada en netDb, de tal forma que pueda ser verificada por cualquiera que haga uso de ella. Además se encuentra constantemente actualizada, ya sea porque existan entradas que ya no sean válidas, entradas que reemplacen a otras más antiguas, o bien porque se apliquen medidas de protección contra ciertos tipos de ataques. Todo este trabajo de almacenamiento y mantenimiento de netDb es llevado a cabo por un conjunto de routers que cuentan con la capacidad floodfill (floodfill routers) por tener bastante ancho de banda disponible.

Estructura RouterInfo

Cuando un router quiere ponerse en contacto con otro, el primero necesita cierta información del segundo para poder llegar a él. Para ello, el primer router acude a netDb para obtener la información de contacto del segundo a partir de su RouterInfo. Esta estructura de información contendrá los siguientes campos: la identidad del router (claves públicas para cifrar y firmar, certificado), las direcciones de contacto (IP, puerto), cuándo fue publicada, etc.

Esto en cuanto a las consultas que se realicen sobre netDb. Sin embargo, también cabe la posibilidad de que un router quiera publicar su RouterInfo en netDb para que la información de contacto esté disponible para todos los demás. En ese caso la información es enviada a netDb de forma directa (sin routers entremedio) y sin ningún tipo de cifrado, ya que al no tratarse de información sensible no hay necesidad de ocultarla (al contrario que ocurre con los LeaseSet).

Estructura LeaseSet

De igual forma, cuando un router quiere ponerse en contacto con un destino, este necesita acudir a netDb para solicitar la información necesaria que le permita llegar a él. Esta información se distribuye a través de una estructura llamada LeaseSet que estará formada por una serie de leases o puntos de entrada (tunnel entry points) que facilitarán el contacto con el destino en cuestión.

Cada uno de los leases contendrá: el gateway de un túnel de entrada que lleve al destino (su identidad), el identificador del túnel de entrada, y su fecha de expiración. Mientras que el propio LeaseSet incluirá los siguientes campos: la identidad del destino (claves públicas para cifrar y firmar, certificado), una clave pública adicional para cifrar (*), otra adicional para firmar, etc.

Al contrario que ocurre con RouterInfo, en este caso la información almacenada en un LeaseSet sí que es sensible. Por lo tanto, en vez de enviarse a netDb de forma directa, el router hará uso de un túnel de salida para enviar el LeaseSet de forma anónima, evitando cualquier tipo de correlación y que pueda ser asociado al router en cuestión.

Intercambio de mensajes en I2P

Una vez repasados algunos conceptos clave en el funcionamiento de I2P, en este apartado se pondrán en práctica dichos conceptos a partir de un ejemplo en el que se explicará paso por paso cómo se comunicarían Alice y Bob:

Ejemplo de una topología de red I2P (fuente)

En la figura anterior Alice, Charlie, Bob y Dave cuentan con un único destino en cada uno de sus routers para el intercambio de mensajes. Todos los túneles representados en el ejemplo son de 2 saltos (gateway, participant y endpoint), donde cada usuario tiene un par de túneles de entrada (en verde) que aparecen enumerados, y un subconjunto de túneles de salida (en rosa). Por simplicidad, algunos túneles no se muestran en la figura.

Antes de comenzar con el intercambio de mensajes, todos los usuarios implicados necesitan construir tanto sus túneles de entrada como los de salida. Para ello, el usuario acude a netDb para solicitar un listado de routers (a través de los RouterInfo) con los que formar un túnel, envía al primero de ellos un mensaje específico (tunnel build message) para iniciar la construcción del mismo, y pide que se reenvíe al resto de routers hasta que el túnel quede completamente construido.

A partir de este momento Alice ya puede comunicarse con Bob siguiendo estos pasos:

1. Alice acude de nuevo a netDb para solicitar el leaseSet del destino, en este caso Bob, y obtener el gateway de uno de sus túneles de entrada (túneles 3 o 4 en la figura).
2. Alice escoge uno de sus túneles de salida para enviar el mensaje, indicándole al endpoint del túnel que lo reenvíe al gateway del túnel de entrada de Bob elegido en el punto anterior. Consideraciones a tener en cuenta:
   • Antes del envío del mensaje, el gateway del túnel de salida lleva a cabo un cifrado por capas donde el mensaje se cifra tantas veces como routers queden en el túnel de salida. Una vez enviado, cada router descifrará una capa y reenviará el mensaje al siguiente router hasta llegar al final del túnel (el endpoint). De tal forma que los routers, en cada proceso de descifrado, solo tendrán acceso a la información de reenvío y no al propio mensaje que viajará cifrado (explicado más adelante). Este proceso se conoce en I2P como garlic routing.
   • En el momento que el mensaje llega al final del túnel de salida y se han descifrado todas las capas, el endpoint dispondrá de las instrucciones necesarias para reenviar el mensaje al gateway del túnel de entrada de Bob.
   • La comunicación entre ambos túneles podría verse comprometida si no fuera porque los mensajes se envían cifrados directamente desde el origen (punto a punto). Este cifrado adicional llamado garlic encryption permite que los usuarios puedan comunicarse de forma segura mediante el uso de mensajes garlic (garlic messages) que podrán contener múltiples mensajes (con sus respectivas instrucciones de entrega), y estarán cifrados con una clave pública determinada. En este caso en concreto, Alice envolverá el mensaje a enviar en un mensaje garlic y lo cifrará con la clave pública (*) del destino (Bob) obtenida del leaseSet solicitado en el primer punto.
3. Una vez el mensaje ha llegado al gateway del túnel de entrada de Bob, este sigue su curso a lo largo del túnel hasta que finalmente llega a Bob. Consideraciones a tener en cuenta:
   • En el punto anterior pudo verse cómo se llevaba a cabo un cifrado iterativo por capas en el gateway que se iba deshaciendo en cada router hasta llegar al endpoint. En este punto, al tratarse de un túnel de entrada, el proceso es similar pero a la inversa. Es decir, el mensaje se va cifrando por capas de forma incremental a medida que pasa por cada uno de los routers del túnel hasta que llega al final del mismo. De tal forma que en el último router (el endpoint) es donde se descifran de forma iterativa todas las capas que tuviera el mensaje.
   • Debido al cifrado punto a punto entre Alice y Bob explicado antes, para que Bob pueda obtener el mensaje en claro solo tendrá que descifrar el mensaje garlic recibido con su clave privada.

Llegados al final de la comunicación Bob ya ha recibido el mensaje enviado por Alice, ¿pero cómo podría responder a este mensaje?

Sencillamente el proceso sería idéntico al anterior salvo que Alice y Bob intercambiarían sus roles. En este caso Bob elegiría un túnel de salida para el envío del mensaje que sería reenviado a un túnel de entrada de Alice.

Sin embargo en el primer punto podrían darse dos posibles situaciones a la hora de obtener la información del destino:

1. Por una parte, una primera posibilidad podría ser justo la que se comenta en el primer punto. En este caso Bob acudiría a netDb para solicitar el leaseSet de Alice y obtener el gateway de uno de sus túneles de entrada.
2. Y por otra parte, con el fin de agilizar la comunicación y reducir el tiempo de respuesta, Alice podría aprovechar el mensaje enviado inicialmente para incluir su leaseSet y evitar que Bob, en su respuesta, tenga que obtener esta información (previamente solicitada por Alice) de netDb. Para ello, simplemente se recurre a los mensajes garlic explicados anteriormente para que Alice pueda incorporar un mensaje adicional que contenga su leaseSet.

Espero que este primer artículo sobre I2P haya resultado útil como primera toma contacto y haya servido para dar a conocer los fundamentos básicos que se esconden detrás de esta red anónima. Si quieres completar el artículo con alguna aportación, ves algún tema que no haya quedado muy claro o bien localizas alguna metedura de pata, ¡no dudes en pasarte por los comentarios!

Imagen del artículo: Wikipedia

• Acerca de
• Últimas entradas

Pedro Castillo

Ingeniero Informático apasionado por la seguridad y la tecnología. Incansable perseguidor de retos. En constante reciclaje.

Ver descripción | Ver perfil en LinkedIn

Últimas entradas de Pedro Castillo (ver todo)

• Despliegue de honeypots de forma ágil y económica con SmartHive - 3 febrero, 2016
• Crónica del Hackathon en CyberCamp 2015 - 23 diciembre, 2015
• I2P: Una red anónima que deberías conocer - 18 noviembre, 2015