¿Qué quiere decir con "anónimo"?

El nivel de anonimato se puede describir "como la dificultad para alguien de encontrar información sobre usted que no quiere que sea encontrada" - quien es usted, su localización, con quien se comunica, o incluso cuándo se comunica. El anonimato "perfecto" no es aquí un concepto útil - las aplicaciones no le harán indistinguible de las personas que no utilizan ordenadores o no usan Internet. Aún así intentamos proveer suficiente anonimato pera cumplir las verdaderas necesidades de quien podemos - de aquellos simplemente navegando por webs, o para aquellos que intercambian información, hasta aquellos con miedo de ser descubiertos por organizaciones poderosas o estados.

La cuestión de si I2P provee suficiente anonimato para usted es una pregunta difícil, pero esperemos que esta página le responda a esa pregunta explorando como I2P opera ante varios atauqes y así puede decidir si se amolda a sus necesidades.

Damos la bienvenida a más investigaciones y análisis sobre la resistencia de I2P a las amenazas más abajo descritas. Se necesitan revisiones sobre los textos ya existentes (la mayoría sobre Tor) y trabajos originales sobre I2P.

Sumario de la topología de la red

I2P se crea sobre las ideas de muchos otros sistemas, pero a la hora de revisar la información hay que tener en cuenta varios puntos:

• I2P es una mixnet de rutas libres - el creador del mensaje define explícitamente el camino que seguirán los mensajes enviados (el túnel de salida), y el receptor del mensaje define explícitamente el camino por el cual serán recibidos los mensajes (el túnel de entrada).
• I2P no tiene puntos de entrada y salida oficiales - todos los pares participan completamente en la mezcla, y no hay proxies de entrada o salida en la capa de red (aún así existen varios proxies de salida en la capa de aplicación)
• I2P es totalmente distribuido - no existen centros de control o autoridades. Cualquiera pude modificar algunos ruters para operar cascadas de mezcla (construyendo túneles y dando las claves necesarias para controlar el envío al final del túnel) o controlar los perfiles de los directorios, todo esto sin romper la compatibilidad con el resto de la red, pero por supuesto no es necesario hacer nada de esto (y además podría poner en peligro su anonimato).

Tenemos planes documentados para implementar retardos no triviales y estrategias de procesados por lote cuya estrategia es sólo conocida por un salto en particular o por las puerta de salida del túnel que recibe el mensaje, permitiendo una red de baja latencia para proveer tráfico de cobertura para las comunicaciones de mayor latencia (por ejemplo correos). Aún así somos conscientes de que son necesarios retardos importantes para proveer una protección útil, y la implementación de esos retardos será un gran desafío. No está claro aún si implementaremos estas características de retardo.

En teoría, los ruters a lo largo del camino pueden inyectar un número arbitrario de saltos antes de enviar el mensaje al siguiente par, pero la implementación actual no lo hace.

El modelo de amenazas

El diseño de I2P comenzó en 2003, no mucho tiempo después del llegada del [Onion Routing] (enrutamiento cebolla), [Freenet] (red libre), y [Tor]. Nuestro diseño se beneficia sustancialmente de las investigaciones publicadas en torno a esa época. I2P usa varias técnicas de enrutamiento cebolla, así que continuamos beneficiándonos del significativo interés académico en Tor.

Teniendo en cuenta los ataques y análisis en la literatura sobre el anonimato (en gran parte Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems), a continuación describimos brevemente un gran variedad de ataques así como las defensas en i2P. Actualizaremos esta lista según sean identificados nuevos ataques.

Se incluyen algunos ataques que pueden ser solamente para I2P. No tenemos soluciones perfectas para esos ataques, pero continuamos estudiando como defendernos de ellos.

Además, muchos de esos ataques son significativamente más fáciles de lo que deberían ser debido al pequeño tamaño actual de la red. Aunque somos conscientes de algunas limitaciones que deben ser reparadas, I2P está diseñado para soportar cientos de miles, o millones de pares. Según vayamos difundiendo la palabra y la red crezca, esos ataques serán mucho mas difíciles de llevar acabo.

Vale la pena re leer las páginas comparación entre redes y "terminología garlic sobre el tema.

Ataques de fuerza bruta

Un ataque por fuerza bruta puede ser montado por adversarios pasivos o activos, observando todos los mensajes que pasan entre todos los nodos e intentarlo averiguar que mensaje sigue qué camino. Montar este ataque sobre I2P no debería ser trivial, ya que todos los pares en la red envían mensajes frecuentemente (de fin a fin y mensajes de mantenimiento de la red), además un mensaje de fin a fin cambia su tamaño y datos a lo largo de su camino. Además, un adversario externo tampoco tiene acceso al mensaje, ya que la comunicación interna entre ruters está cifrada y después enviada (haciendo que un mensaje de 1024 bytes sea indistinguible de un mensaje de 2048 bytes)

Aún así, un atacante poderoso podría usar la fuerza bruta para detectar tendencias - si puede enviar 5GB a una destinación I2P y monitorizar las conexiones de red de todos, podría eliminar a todos los pares que no recibieron los 5Gb de datos. Existen técnicas para evitar este ataque, pero pueden ser prohibitivamente caras (vea Tarzan). A la mayoría de los usuarios no les debería preocupar este ataque, ya que el coste de montarlo es enorme (y normalmente ilegal). Aún así, el ataque es plausible, por ejemplo, para un observador en un ISP o en un punto de cambio de Internet. Los que deseen protegerse de este ataque deben tomar las medidas necesarias, como poner límites bajos al ancho de banda, y usar leasesets cifrados o no publicados para las eepsites. Otras medidas, como retardos no triviales y rutas restringidas no se han implementado.

Como una defensa parcial contra un ruter o varios tratando de enrutar todo el tráfico de la red, los ruters contienen límites como el número de túneles que puede pasar por un único ruter. Según crezca la red, estos límites serán ajustados. Otros mecanismos como la clasificación, selección y anulación de los ruters son discutidos en la página de selección de ruters.

Ataques de sincronización

Los mensajes de I2P son unidireccionales, y no implican necesariamente que se enviará una respuesta. Aún así, las aplicaciones sobre I2P tienen patrones reconocibles dentro de las frecuencias de sus mensajes - por ejemplo, una petición HTTP tendrá un pequeño mensaje con una secuencia larga de mensajes de respuesta conteniendo las respuestas HTTP. Utilizando esta información y teniendo una vista general de la topología de la red, un atacante podría inhabilitar algunos enlaces como mensajes demasiado lentos como para ser pasados.

Este tipo de taques es poderoso, pero su aplicación a I2P no es obvia. Debido a la variación de los retardos de los mensajes en las colas, procesamiento de los mensajes y estrechamientos, a menudo excederán el tiempo para pasar un mensaje a través de un enlace - incluso cuando un atacante sabe que una respuesta será enviada tan pronto como el mensaje llegue. Aunque hay varios escenarios en los cuales se exponen respuestas casi automáticas - la librería de streaming lo hace (con el SYN+ACK) al igual que que el modo de mensaje de la garantía del envío (con el DataMessage+DeliveryStatusMessage).

Sin la depuración del protocolo y unas mayores latencias, adversarios globales pueden obtener bastante información. Por eso, la gente preocupada por estos ataques puede aumentar la latencia (usando retardos no triviales o estrategias de procesado por lotes), incluyendo la depuración del protocolo, o las técnicas de enrutado avanzado de túneles, pero estas no están implementadas en I2P.

Referencias: Low-Resource Routing Attacks Against Anonymous Systems

Ataques por intersección

Los ataques de intersección contra los sistemas de baja latencia son realmente poderosos - contactando con el objetivo periódicamente y llevando el registro de los pares que hay en la red. Con el tiempo, y con el movimiento, el atacante obtendrá bastante información sobre el objetivo simplemente observando los pares que hay online cuando un mensaje pasa a través. El costo de este ataque aumenta según aumenta el tamaño de la red, pero puede ser válido en varios escenarios.

En resumen, si un atacante está al inicio y al final de tu túnel al mismo tiempo podría tener éxito. I2P no tiene defensa contra este ataque en una comunicación de baja latencia. Esto es una debilidad inherente del enrutado onion de baja latencia. Tor proporciona una aclaración similar.

Defensa parcialmente implementada en I2P:

• orden estricto de pares
• selección y perfiles de los pares de un pequeño grupo que cambia lentamente
• Límite en el número de túneles rutados a través de un solo par
• Prevención de pares del mismo rango /16 de IPs por ser miembros del mismo único túnel.
• For I2P Sites or other hosted services, we support simultaneous hosting on multiple routers, or multihoming

Incluso usando todas ellas, estas defensas no son una solución completa. Además, hemos hecho algunas elecciones de diseño que podrían incrementar las vulnerabilidades:

• No utilizamos "nodos guardianes" de bajo ancho de banda
• Usamos grupos de túneles compuestos de varios túneles, y el tráfico puede pasar de túnel a túnel.
• Los túneles no son de larga duración; los túneles se recrean cada 10 minutos.
• El tamaño de los túneles es configurable. Aunque se recomienda 3 saltos por túnel para protección total, algunas aplicaciones y servicios usan túneles de 2 saltos por defecto.

En el futuro, esto podría ocurrir para los cares que puedan permitirse retardos significativos (por retardos no triviales y estrategias de procesado por lotes). Además, esto sólo es relevante para las destinaciones que pueden ser conocidas por otra gente - un grupo privado cuya destinación es sólo conocida por pares de confianza no tiene de que preocuparse, ya que un adversario no puede contactarles,"ping" them, para montar el ataque.

Referencia: One Cell Enough

Ataques de denegación de servicio

Hay un montón de ataques de denegación de servicio disponibles contra I2P, cada cual con sus costes y consecuencias:

Ataque del usuario codicioso: Esto es simplemente gente intentando consumir muchas más recursos de los que están dispuestos a compartir. La defensa contra este ataque es:

• Establezca las configuraciones por defecto de forma que la mayoría de los usuarios proporcionen recursos a la red. En I2P, los usuarios enrutan tráfico por defecto. En clara distinción con otras redes, más del 95% de los usuarios de I2P repiten tráfico para otros.
• Proporcionar opciones de configuración fáciles para que los usuarios puedan incrementar su contribución (porcentaje de lo que se comparte) a la red. Mostrar medidas fáciles de entender como "el ratio de lo que se comparte" para que los usuarios puedan ver lo que contribbuyen.
• Manteniendo una comunidad fuerte con blogs, foros, IRC y otras formas de comunicación.

Ataque por 'hambruna': Un usuario hostil puede intentar dañar la red creando un gran número de pares en la red ocultando que están bajo el control de la misma persona (como con Sybil). Esos nodos deciden entonces no dar recursos a la red , haciendo que los pares existentes tengan que buscar una base de datos de red más grande o crear más túneles de los necesarios. Además, los nodos pueden ofrecer servicio intermitente eliminando periódicamente el tráfico elegido, o negando las conexiones a ciertos pares,. Este funcionamiento puede no diferenciarse del de un nodo saturado y con fallos. I2P soluciona este problema manteniendo perfiles de los pares, intentando identificar los que funciona mal e ignorándolos , o usándolos raramente. Hemos hechos grandes avances en el reconocimiento de los pares problemáticos; aún así todavía se requieren grandes esfuerzos en este área.

Ataque por inundación, flooding: Un usuario hostil puede intentar inundar o saturar, la red, un par, una destinación o un túnel. La saturación de la red y de los pares es factible, e I2P no hace nada por prevenir la saturación de la capa de IP. Es posible saturar una destinación enviando un gran número de mensajes a las puertas de salida de los túneles de entrada, pero el destinatario tendrá conocimiento del ataque por los contenidos de los mensajes y porque las pruebas de los túneles fallarán. Lo mismo ocurre con la saturación de un solo túnel. I2P no tiene defensas para el ataque a la red por inundación. Para el ataque por inundación de una destinación o un túnel, el objetivo identifica cuales túneles no responden y crea unos nuevos. Se podría añadir nuevo código para aumentar el número de túneles por si el cliente desease manejar la sobrecarga. Si, por otra parte, la carga es mayor de lo que el cliente puede soportar, puede instruir a los túneles para acelerar el número de mensajes o bytes que deben ser pasados (una vez que se implemente el funcionamiento avanzad de los túneles).

Ataque de carga de CPU: Hay algunos métodos que pueden hacer que algún usuario remoto solicite que un par haga operaciones de cifrados muy costosas, y un usuario hostil puede usar esto para saturar el par con un gran número de solicitudes e intentar saturar la CPU. Usando buenas prácticas de ingeniería y exigiendo certificados no triviales (por ejemplo HashCash) puede mitigarse el problema, aunque hay posibilidad también de que un atacante explote algún error en la implementación.

Ataque floodfill de denegación de servicio: Un usuario hostil puede intentar dañar la red convirtiéndose en un ruter floodfill. Las defensas actuales contra los ruters floodfill no fiables, intermitentes o maliciosos son pobres. Un ruter floodfill puede dar respuestas falsas o no darlas a las búsquedas, y puede también interferir en las comunicaciones entre floodfills. Se han implementado algunas defensas y el control de perfiles, aún así hay mucho por hacer todavía. Para más información vea la web de la base de datos de la red.

Ataques de etiquetado

Los ataques de etiquetado - modificando un mensaje de tal forma que más tarde pueda ser identificado en el camino - son imposibles en I2P, ya que los mensajes enviados a través de los túneles están firmados. Aún así, si un atacante es la puerta de salida del túnel de entrada y es también un participante en otro lugar del mismo túnel, puede identificar el hecho de que están en el mismo túnel (y antes de añadir el id único del salto y otros cambios, los pares coincidentes dentro del mismo túnel pueden reconocer este hecho sin ningún esfuerzo). Pero un atacante en el túnel de salida y en cualquier otra parte de un túnel de entrada no puede hacer nada, ya que el cifrado del túnel codifica la información de diferente forma en los túneles de entrada y en los de salida. Los atacantes externos tampoco pueden hacer nada, ya que los enlaces están cifrados y los mensajes firmados.

Ataques de particionamiento

Los ataques de particionamiento - buscar formas (técnica o analíticamente) de separar los pares en la red - son a tener en cuenta cuando nos enfrentamos a adversarios poderosos, ya que el tamaño de la red juega un papel importante a la hora de determinar el anonimato. I2P ha resuelto el problema técnico del ataque de particionamiento que corta los enlaces entre los pares dentro de su base de datos de la red, la cual mantiene estadísticas sobre los pares a fin de permitir que las conexiones fragmentadas sean reparadas usando otras partes de la red. Aunque si un atacante desconecta todos los enlaces de un par, aislando el objetivo completamente, la base de datos poco podrá hacer para reparar el daño. En este punto lo único que el router I2P puede intentar hacer es avisar de que un gran número de pares anteriormente fiables han pasado a estar no disponibles, y alertar al cliente de que está temporalmente desconectado (este tipo de detección no está aún implementada).

Partir la red analíticamente buscando por diferencias en como se comportan los ruters y las destinaciones y agrupándolos de acuerdo a los resultados, es también un ataque poderoso. Por ejemplo, un atacante cosechando la base de datos de la red sabrá cuando una destinación en particular tiene 5 túneles de entrada y su LeaseSet mientras que otros sólo tienen 2 o 3, permitiendo al adversario clasificar los clientes por el número de túneles seleccionados. Otro ataque por partición es posible cuando tratamos con los retardos no triviales y las estrategias de procesamiento por lotes, ya que las puertas de entrada de los túneles y los saltos con no-ceros retardos resaltarán entre los demás. Aún así, esta información sólo será expuesta a esos saltos específicos, con lo que para que el ataque por partición sea efectivo, el atacante necesita tener el control de una gran parte de la red (y aún así sólo sería un ataque probabilístico, ya que no sabría que otros túneles o mensajes tienen esos retardos).

También se discute en la página de la base de datos de la red (ataque de bootstrap).

Ataques del predecesor

El ataque del predecesor es obtener estadísticas pasivamente intentando ver qué pares están 'cerca' de la destinación, participando en sus túneles y haciendo el seguimiento de los saltos anteriores o siguientes ( para túneles de salida o entrada, respectivamente). Con el tiempo, un atacante usando un ejemplo aleatorio perfecto de pares y ordenación, podría ver cuales pares parecen estar más 'cerca' estadísticamente que el resto, y ese par podría llegar a estar donde el el objetivo se encuentra.

I2P evita esto de 4 formas: primera, los pares seleccionados para participar en un túnel no están seleccionados aleatoriamente de la red - derivan del algoritmo de selección de pares que los parte en niveles. Segunda, con el orden estricto de los pares en un túnel, el hecho de que un par se muestre más a menudo no quiere decir que que sea la fuente. Tercera, con la permutación del tamaño del túnel (no activado por defecto) incluso los túneles de 0 saltos pueden proveer negación plausible, ya que la variación ocasional de la puerta de salida parecerá un túnel normal. Cuarta, con las rutas restringidas (no implementadas), sólo el par con una conexión restringida con el objetivo será capaz de contactar con el objetivo, mientras que los atacantes simplemente pasarán por la puerta de salida.

El método de creación de túneles actual fue diseñado específicamente para combatir el ataque del predecesor. Ver también el ataque de interesección.

Referencias: http://forensics.umass.edu/pubs/wright.tissec.2008.pdf el cual es una actualización del documento sobre el ataque del predecesor http://forensics.umass.edu/pubs/wright-tissec.pdf.

Ataques de cosechado

"Harversting", cosechado, es la compilación de una lista de usuarios que ejecutan I2P. Puede ser usado para atacar legalmente o para ayudar a otros ataques simplemente ejecutando un par, viendo quien se conecta al par, y cosechando todas las referencias que pueda encontrar sobre otros pares.

En sí mismo I2P no está diseñado para defenderse efectivamente contra este ataque, ya que la base de datos de la red distribuida contiene toda esta información. Aunque los siguientes factores hacen este ataque sea un poco más difícil en la práctica:

• El crecimiento de la red hará más difícil el controlar una parte determinada de la red.
• Los ruters floodfill implementan límites en las peticiones para prevenir ataques de denegación de servicio, DOS.
• "Modo oculto", evita que el ruter publique su información en la netDb, (pero también hace que no reenvíe datos), no se usa mucho por ahora.

En implementaciones futuras, ruters restringidos básicos y exhaustivos, este ataque perderá gran parte de su poder, ya que los pares "ocultos" no publicarán su lista de contactos en la base de datos de la red - sólo los túneles por los que puede ser cntactado (al igual que sus claves publicas y demás).

En el futuro los ruters podrán usar GeoIP para identificar si están en un país donde la identificación de su nodo como un nodo de I2P podría ser peligroso. En ese caso, el ruter podrá activar el modo oculto automáticamente, o utilizar otros métodos de enrutado restringidos.

Identificación a través de análisis del tráfico

Inspeccionando el tráfico entrante y saliente del ruter, un ISP malicioso o un firewall de un estado podrían identificar que una máquina utiliza I2P. Como se discutió más arriba, I2P no está diseñado específicamente para ocultar que una computadora usa I2P. Aún así, ciertas decisiones en diseño de los protocolos y la capa de transporte hacen bastante difícil identificar el tráfico de I2P:

• Selección de puertos aleatoria
• Cifrado de todo el tráfico de punto a punto
• Intercambio de clave DH sin bytes del protocolo u otros campos constantes no cifrados
• El uso simultáneo de UDP y TCP. UDP puede ser mucha más difícil de inspeccionar y seguir con equipamiento DPI, (inspección profunda de paquetes).

En breves tenemos planeado solucionar los problemas de análisis de trafico ofuscando los protocolos de transporte de I2P, probablemente incluyendo:

• Rellenando la capa de transporte para que tenga determinados tamaños, especialmente durante el handshake de conexión
• Estudiando las firmas de la distribución de los tamaños de los paquetes, y rellenando si es necesario.
• Creación de otros métodos de transporte camuflados como SSL u otros protocolos comunes.
• Revisión de las estrategias de relleno en las capas superiores para ver como afectan al tamaño de los paquetes en la capa de transporte.
• Revisar varios métodos implementados por varios cortafuegos de algunos estados para bloquear Tor
• Trabajar directamente con expertos en DPI, inspección profunda de paquetes, y expertos en ofuscación.

Referencia: Breaking and Improving Protocol Obfuscation

Ataques Sybil

Sybil describe una categoría de ataques donde el adversario crea números arbitrariamente grandes de nodos compinchados y usan el incremento numérico para ayudar a montar otros ataques. Por ejemplo, si un atacante esta en una red donde los pares se seleccionan aleatoriamente y quieren un 80% de posibilidades de ser uno de esos pares, simplemente crean cinco veces el número de nodos que están en la red y tiran el dado. Cuando la identidad es gratuita, Sybil puede ser una técnica muy potente para un adversario enérgico. La técnica primaria para enfrentar esto es simplemente hacer la identidad 'no gratuita' - Tarzan (entre otros) usa el hecho de que la dirección IP es limitada, mientras IIP (proyecto de IRC invisible) usaba HashCash para realizar un 'cargo' por crear una nueva identidad (prueba de trabajo). Actualmente no hemos implementado técnica particular alguna para enfrentar Sybil, pero incluimos certificados de posición en las estructuras de datos del router y el destino que pueden contener un certificado HashCash de un valor adecuado cuando sea necesario (o algún otro certificado que pruebe la escasez).

Requerir certificados HashCash en varios sitios tiene algunos problemas:

• Mantener compatibilidad con versiones anteriores
• El problema clásico del HashCash - seleccionar valores HashCash que sean pruebas significativas de gasto de trabajo en máquinas potentes, mientras que también sean factibles en máquinas no tan potentes como los dispositivos móviles.

Varios límites en el número de ruters que puede haber en un rango determinado de IPs restringe las posibilidades de los atacantes, ya que no pueden poner más computadoras en ese bloque de IPs. Aún así esto no es defensa contra un adversario con muchos recursos.

Vea la web de la base de datos de la red para obtener más información sobre Sybil.

Ataques por agotamiento de amigos

(Reference: In Search of an Anonymous and Secure Lookup Section 5.2)

Al rechazar aceptar o remitir las solicitudes de construcción de túneles, excepto hacia un par (`peer`) compinchado, un router puede asegurar que un túnel está formado en su totalidad con su grupo de routers compinchados. Las posibilidades de éxito se incrementan si hay un gran número de routers compinchados, es decir, un ataque Sybil. Esto es mitigado de alguna manera por nuestros métodos de perfilado de pares usados para monitorizar el rendimiento de los pares. Sin embargo, esto es un ataque potente cuando el número de routers se aproxima a f = 0.2, o 20% nodos maliciosos, como se detalla en la especificación. Los routers maliciosos también pueden mantener conexiones con el router objetivo y proporcionar un excelente ancho de banda de reenvío para el tráfico sobre aquellas conexiones, en un intento de manipular los perfiles gestinados por el objetivo y parecer atractivos. Podría ser necesaria ulterior investigación y defensa.

Ataques de cifrados

Usamos cifrados seguros con claves grandes, y usamos los algoritmos de cifrado por defecto de la industria de la seguridad, como se documenta en on the low-level cryptography page. Las medidas de seguridad también incluye la detección inmediata de mensajes alterados en los caminos intermedios, la imposibilidad de descifrar los mensajes que no le son enviados explícitamente a un par dado y defensas contra ataques main in the middle. Los tamaños de las claves elegidas en el 2003 todavía son más grandes que las usadas en otras redes de anonimato como . No creemos que el tamaño de las claves sean la mayor vulnerabilidad, sobre todo contra adversarios que no sean estados; los errores de programación y el pequeño tamaño actual de la red son mucho más preocupantes.. Por supuesto, todos los algoritmos de cifrado se convierten en obsoletos tarde o temprano con la llegada de microprocesadores más potentes, estudios sobre cifrados y avances en métodos como las raionbow tables, grupos de consolas, etc. Desafortunadamente, I2P no fue diseñado con un mecanismo fácil para el cambio del tamaño de las claves o los secretos compartidos, manteniendo la compatibilidad con versiones anteriores.

La actualización de varias estructuras y protocolos para el soporte de claves más largas es un tema que deberá ser tratado tarde o temprano, y esto será un dificil problema de resolver, al igual que le ocurrirá a otros. Esperemos que con un buen planteamiento podamos minimizar los trastornos e implementar mecanismos que hagan más fáciles futuros cambios.

En el futuro varios protocolos y estructuras de datos de I2P soportarán el rellenado seguro de mensajes con tamaños arbitrarios, con lo que los mensajes serán de un tamaño constante o los mensajes garlic podrán ser modificados aleatoriamente con lo cual algunas partes parecerán contener más subpartes de lo que realmente tienen. Hasta el momento los túneles garlic y los mensajes de fin a fin utilizan un simple relleno aleatorio.

Ataques de anonimato FloodFill

Además de los ataques DOS FloodFill ya descritos arriba, los ruters floodfill tienen una posición ventajosa a la hora de aprender sobre los participantes en la red, debido a su rol en la netDb y de la alta frecuencia de las comunicaciones con otros participantes. Esto es mitigado en parte ya que los ruters FloodFill sólo administran una parte de todo el espacio de claves, y el espacio de claves rota diariamente, como se explica en la web de la base de datos de la red. Los mecanismos específicos con los que los ruters se comunican con los FloodFills han sido diseñados cuidadosamente. Aún así, estos peligros deben estudiarse más profundamente. Los ataques específicos potenciales y sus defensas deberán ser discutidos en estudios futuros.

Otros ataques a la base de datos de la red

Un usuario hostil podría intentar dañar la red creando uno o más ruters FloodFill y haciendo que den respuestas malas, lentas o incluso que no respondan. Varios escenarios como este han sido discutidos en la web de la base de datos de la red.

Ataque de Recurso Central

Hay varios recursos centralizados o limitados (algunos dentro de I2P, algunos no) que pueden ser atacados o usados como vectores para ataques. La desaparición de jrandom en Noviembre del 2007, seguida de la pérdida del servicio de alojamiento de i2p.net en enero del 2008, mostraron que muchos servicios estaban centralizados en el desarrollo y funcionamiento de la red I2P, aunque actualmente la mayoría están descentralizados. Los ataques a los servicios externos afectan mayormente a cómo los nuevos usuarios pueden encontrarnos, no en la operación de la red en sí misma.

• La web tiene copias en varios lugares y usa round-robin DNS para el acceso público externo.
• Los roters I2P ahora soportan múltiples ubicaciones de resembrado externas, aún así se necesitarían más routers I2P de resembrado, y la gestión de los equipos de resembrado no fiables o maliciosos puede precisar mejora.
• Los ruters soportan ahora la actualización desde múltiples localizaciones. Un ruter malicioso de actualizaciones podría enviar un archivo enorme, se necesita limitar el tamaño.
• Los ruters ahora soportan múltiples actualizaciones de confianza firmadas.
• Los routers I2P ahora gestionan mejor múltiples pares de inundación (floodfills) no fiables. Los routers I2P de inundación maliciosos precisan mayor estudio.
• El cóodigo está ahora almacenado en un sistema distribuido de control de código fuente.
• Los routers I2P confían en un solo servidor de novedades de consola, pero hay una URL de respaldo incluida en el código, apuntando a un servidor distinto. Un servidor de novedades de consola malicioso podría enviar un fichero enorme, es necesario limitar el tamaño.
• Los servicios del sistema de nombres (de servidores), incluyendo los proveedores de suscripción a libreta de direcciones, los servicios de agregación de servidores, y los servicios de salto (jump, direccionamiento distribuido), podrían ser maliciosos. Se implementaron protecciones sustanciales para las suscripciones en la versión 0.6.1.31, con mejoras adicionales en las versiones subsiguientes. No obstante, todos los servicios de nombres requieren una cierta dosis de confianza, vea la página de nombres para más detalles.
• Continuamos confiando en el servicio DNS para i2p2.de, perder esto causaría bastante trastorno en nuestra capacidad de atraer nuevos usuarios, y encogería la red (de corto a medio plazo), al igual que lo hizo la pérdida de i2p.net.

Ataques de desarrollo

Estos ataques no son a la red, en cambio van detrás del equipo de desarrolladores ya sea poniendo obstáculos legales a cualquiera contribuyendo al desarrollo, o usando cualquier método disponible para hacer que los desarrolladores boicoteen el software. Las medidas técnicas tradicionales no pueden derrotare estos ataques, y si alguien amenaza la vida o el sustento de un desarrollador (simplemente poniendo una denuncia con secreto de sumario para que no pueda contarlo, con amenaza de cárcel), podríamos tener un gran problema.

Sin embargo, estas técnicas ayudan a defenderse contra estos ataques:

• Todos los componentes de la red deben ser de código libre para permitir su inspección, verificación, modificación y mejora. Si algún desarrollador ha sido comprometido, una vez notificado, la comunidad debe exigir una explicación y su cese para aceptar el trabajo de ese desarrollador. Todos los cambios en nuestro sistema de control de código distribuido están criptográficamente firmados, y los empaquetadores de versiones usan una sistema de listas de confianza para restringir las modificaciones a sólo aquellos que han sido aprovados.
• El desarrollo de la red permitiendo a los desarrolladores permanecer anónimos pero aun así seguros. Todo el desarrollo de I2P puede hacerso dentro de I2P - usando un sistema de control distribuido de código, IRC chat, servidores web públicos , foros de discusión (forum.i2p), y webs de distribución de las aplicaciones, todo disponible dentro de I2P.

También mantenemos relaciones con organizaciones que ofrecen consejo legal, en caso de que fuese necesario algún tipo de defensa legal.

Ataques de implementación (errores de programación)

Por mucho que nos esforcemos, incluso las aplicaciones más simples tienen errores de diseño, e I2P no es una excepción. Pueden existir bugs inesperados que pudieran ser explotados para atacar el anonimato o la seguridad de las comunicaciones ejecutándose sobre I2P. Para evitar estos ataques contra el diseño de los protocolos usados, publicamos todos los diseños y documentación y solicitamos revisión y crítica con la esperanza de que usando muchos ojos se mejorará el sistema. No creemos en la seguridad por oscuridad.

Además, el código es tratado de la misma forma, sin muchos problemas para volver a hacer el trabajo o tirar trabajo ya hecho que no cumpla las necesidades del sistema (incluida su fácil modificación). La documentación del diseño y de la implementación de la red y de los componentes de software es una parte esencial de la seguridad, ya que sin ella sería raro que los programadores gastasen tanto tiempo en aprenderse el software como para identificar deficiencias y errores.

En partucular, es probable que nuestras aplicaciones contengan errores relacionados con la denegación de servicio a través de errores de llenado de memoria (OOMS), cross-site-scripting (XSS) en la consola del ruter, y otras vulnerabilidades no tan normales a causa de varios protocolos.

I2P aún es una red pequeña con una comunidad de programadores pequeña y casi sin interés por parte de académicos y grupos de investigación. A causa de eso nos faltan los análisis que pueden tener otras redes de anonimato. Continuamos reclutando gente para que se involucre y ayude.

Otras defensas

Listas de bloqueos

Hasta cierto punto I2P puede ser afinada para evitar a los pares que operan con direcciones IP incluidas en una lista de bloqueo (blocklist). Comúnmente están disponibles varias listas de bloqueo en formatos estándar, e incluyen organizaciones contrarias a I2P, adversarios de un nivel potencialmente estatal, y otros.

En la medida en que aparecen pares activos en la lista de bloqueo actual, bloquear sólo una parte de los pares tendería a segmentar la red, exacerbando los problemas de alcanzabilidad, y reduciendo la fiabilidad del conjunto. Por tanto querríamos ponernos de acuerdo en una lista de bloqueo determinada, y habilitarla por defecto.

Las listas de bloqueo (blocklist) sólo son una parte (quizáa una pequeña parte) de una batería de defensas contra la maliciosidad. En gran parte, el sistema de elaboración de perfiles hace un buen trabajo de medición del comportamiento de los routers I2P, y hace que no necesitemos confiar en ningún contenido de la netDb. Aún así hay más cosas que se pueden hacer. En cualquiera de las áreas de la lista anterior hay mejoras que se pueden realizar para detectar la maliciosidad.

Si una lista de bloqueo (blocklist) está hospedada en una ubicación central con actualizaciones automáticas, la red es vulnerable a un ataque al recurso centralizado. La suscripción automática a una lista ofrece al proveedor de esta la capacidad de apagar toda la red i2p. Por completo.

Actualmente, con nuestro software se distribuye una lista de bloqueo (blocklist) predeterminada, que incluye sólo las IPs que han sido origen de ataques de denegación de servicio (DOS). No hay mecanismo de actualización automático. En caso de que un rango de IPs determinado implementase ataques graves a la red I2P, tendríamos que pedirle a la gente que actualizase manualmente su lista de bloqueo a través de mecanismos externos a la red como foros, blogs, etc.