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, Pero digámoslo es, tor no lo es todo en el mundo de las
redes anónimas.
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, partieré de algunos conceptos clave y dando los detalles técnicos
necesarios (dada la complejidad del proyecto) para empezar a entender el
funcionamiento de I2P, más adelante es posible que haga realice algún tutorial de
como configurar de una manera óptima esta red.
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
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:
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:
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:
- 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).
- 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.
- 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:
- 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.
- 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.
Bueno,
resulto salir bastante extenso el artículo, pero creo que era útil tocar en
primera instancia varios temas, para ver el funcionamiento de I2P, así que eso
es todo por ahora.
Saludos!
