SlideShare una empresa de Scribd logo
1 de 35
Descargar para leer sin conexión
Universidad Wesleyana El Colegio de Honores 
Analizando la Efectividad de Ataques de Correlación 
Pasivos en la Red de Anonimato Tor 
por 
Sam DeFabbia-Kane 
Clase del 2011 
Traducción hecha por: Juan Eljach y Gustavo Rendón, Exploiter.co 
Una tesis entregada a la facultad de la Universidad Wesleyana como 
cumplimiento parcial de los requerimientos para el Diploma de Bachiller 
de Artes con Honores Departamentales en Ciencias de la Computación 
Middletown, Connecticut Abril 2011 
Agradecimientos 
Primero quiero agradecer a Norman Danner y a Danny Krizane, quienes me han 
permitido trabajar con ellos en proyectos relacionados con Tor desde mi segundo 
año, y quienes han sido mis asesores para esta tesis. Estoy sumamente agradecido
por su tiempo, consejo y paciencia. He sido capaz de haber pasado mucho tiempo 
en Wesleyan trabajando en un tema que encuentro extremadamente interesante, y 
me considero muy afortunado de haber tenido dicha oportunidad. 
También quisiera agradecer a mis amigos, quienes me apoyaron durante este 
proceso y durante todo mi tiempo en Wesleyan. He aprendido tanto de ellos como 
lo he hecho de las clases que he tomado aquí. Me gustaría agradecer especialmente 
a mis compañeros de piso. Andrew, Dan, Dave, Ryan, Jess y Lindsey han sido 
pacientes conmigo estas últimas semanas a pesar de que estuviese cansado, 
estresado, e irritable, y han sido maravillosos amigos todo el tiempo desde que los 
conozco en Wesleyan. 
Finalmente, quisiera agradecer a mis padres. Siempre han apoyado y 
animado mi curiosidad e intereses, y es ese apoyo el que me ha convertido en la 
persona que soy hoy día. 
ii 
Resumen 
Tor es un sistema de anonimato de baja-latencia ampliamente usado. Permite a 
los usuarios de navegadores web, clientes de un chat y otras aplicaciones de baja-latencia 
comunicarse anónimamente en línea al enrutar sus conexiones a través 
de un circuito de tres routers Tor. No obstante, Tor es comúnmente considerado 
vulnerable a una gran variedad de ataques, que le podrían permitir a operadores
Tor u observadores ajenos comprometer el anonimato de los usuarios de Tor. 
Uno de estos ataques es el ataque de correlación extremo-a-extremo, por lo cual 
un atacante controlando el primer y último router en un circuito puede usar la 
sincronización y otros datos para correlacionar flujos observados en esos routers y 
por lo tanto violar el anonimato de Tor. 
Debido a que la mayoría de pruebas previas de algoritmos de correlación 
han sido usados bien sea en simulación o con sólo ciertos tipos de tráfico, nuestra 
meta fue verificar que tan bien funcionan estos algoritmos en la red Tor 
desplegada. En esta tesis probamos tres algoritmos de correlación. Dos de estos 
algoritmos son de trabajos previos, y el tercero fue diseñado por nosotros. Su 
diseño estuvo basado en observaciones y análisis de datos que recolectamos 
durante el proceso de prueba. Encontramos que mientras los dos algoritmos 
previamente existentes que testeamos tienen problemas que previenen que sean 
usados en ciertos casos, nuestro algoritmo funciona plenamente en todo tipo de de 
datos. 
iii 
Contenidos 
Capítulo 1. Introducción 
1.1. Circuitos y Cifrado Onion 
1.2. Células de Tor 
1.3. Servidores de Directorios 
1.4. Contribuciones de esta Tesis 
Capítulo 2. Ataques en Tor 
2.1. Correlación de Flujo 
2.2. Atasco 
2.3. Round-Trip Travel Time
Capítulo 3. Métricas para el Tráfico de Tor 
3.1. Tráfico En Tor 
3.2. Tráfico de Router de Entrada 
Capítulo 4. Prueba de Algoritmos de Correlación 
4.1. Modelo de ataque 
4.2. Definiciones de Algoritmo de Correlación 
4.3. Organización del Test 
4.4. Resultados 
Capítulo 5. Conclusión 
Bibliografía 
iv 
Capítulo 1 
Introducción 
Cada uno de los mensajes que se envían por Internet tienen información de 
enrutamiento que puede ser usada para identificar el remitente y el destinatario del 
mensaje. Para muchos usuarios de Internet, esto supone un problema. Activistas, 
denunciantes anónimos y defensores de derechos humanos podrían querer ser 
anónimos para evadir la posible represión de gobiernos o corporaciones. Militares 
y fuerzas del orden podrían querer ser anónimos para poder recolectar información 
o realizar operaciones de seguimiento y captura sin ser identificados. Personas 
que viven en países o trabajan en compañías con internet censurado usarían el 
anonimato como una forma de burlar las medidas de censura. Hasta este punto, 
muchos sistemas de anonimato han sido desarrollados con el objetivo de facilitar la 
comunicación anónima online.
Estos sistemas de anonimato están típicamente divididos en dos categorías: 
Los de baja latencia y los de alta latencia. Los de alta latencia - como Babel, 
Mixmaster y Mixminion- implementan medidas de defensa como mixing, 
padding, batching, y reordering en un intento de protegerse contra un adversario 
pasivo global que pueda observar todo el tráfico de la red [4]. Sin embargo, 
dichos sistemas sólo pueden ser usados con métodos de comunicación de alta 
latencia como el email, lo cual limita su utilidad al igual que a sus usuarios. Los 
sistemas de baja latencia por lo general no intentan proteger contra un adversario 
pasivo global, pero pueden ser usados con una variedad mucho más amplia de 
aplicaciones, incluyendo navegadores, clientes de chat y streaming de vídeo. 
Una red muy popular de anonimato de baja latencia es Tor [4]. Tor funciona 
enrutando la conexión de un usuario a través de 3 routers onion (onion routers; 
ORs), los cuales forman un circuito y actúan como una cadena de proxies. Los 
mensajes enviados a través de la conexión se ponen en capas con cifrado (usando 
una técnica llamada onion encryption) por tanto cada OR conoce solo su origen 
y destino inmediato. Los routers onion son puestos por voluntarios alrededor del 
mundo. Los routers son coordinados y catalogados por un pequeño 
conjunto de servidores de directorios que proveen información acerca de la red 
Tor y de routers disponibles para los clientes (quienes son llamados por lo general 
onion proxies o OPs). 
A pesar de que no intenta proteger contra un adversario pasivo global, 
Tor intenta proteger contra un adversario más limitado que puede observar parte 
del tráfico que viaja en la red, o que controla routers onion. Esto es importante 
porque cualquier persona puede correr un router onion, y los usuarios de Tor no 
tienen garantía de que los operadores de estos routers no son maliciosos. Sin 
embargo, a pesar de los objetivos en su diseño inicial, se asume comúnmente que 
Tor es vulnerable a muchas clases de ataques por adversarios no globales. En esta 
investigación, examinaremos uno de estos tipos de ataques: un ataque de 
correlación extremo-a-extremo pasivo por el cual un atacante controlando el 
primer y último router en un circuito puede comprometer el anonimato de la 
conexión que viaja a través de dicho circuito. Como se asume que Tor es 
vulnerable a este tipo de ataques, muchos de los trabajos anteriores en este tema 
han sido realizados en simulación o solo en teoría. Aquí buscamos probar la 
efectividad de estos ataques en una red Tor desplegada, y determinar si podemos
crear un mejor ataque examinando las métricas del tráfico Tor. Este capítulo 
describe cómo funciona Tor y cuales son los objetivos de esta investigación. 
1.1. Circuitos y Cifrado Onion 
Los usuarios que desean usar Tor enrutan su tráfico a través de un proxy 
onion (OP), el cual maneja transparentemente la creación y cifrado del circuito. 
El objetivo de Tor es el anonimato. Tor no provee cifrado extremo-a-extremo 
porque no puede cifrar el paso entre el router de salida y el servidor al que el 
cliente se está conectando. Para hacer eso requeriría la cooperación de el servidor, 
lo que significa que Tor no sería un proxy transparente. Tor, por lo tanto, no es un 
reemplazo para otras tecnologías de cifrado. Sin embargo, Tor usa cifrado por 
capas internamente, lo cual logra dos efectos. Primero, asegura que cada router 
onion (OR) conoce sólo a los nodos adyacentes del circuito. Segundo, previene que 
los atacantes puedan directamente comparar el tráfico en cualquier conjunto de dos 
puntos del circuito, debido a que el tráfico es cifrado de forma diferente (Por tanto 
se ve diferente) en cada punto. El proxy onion (OP) hace este cifrado negociando 
una clave simétrica con cada uno de los routers en el circuito y cifrando cada 
mensaje con cada llave simétrica, como se describe a continuación. 
Supongamos que son router en un circuito de tamaño n y que es una clave 
simétrica negociada entre el OP de Alice y . Las claves para son negociadas a 
través de los routers previos en el circuito . Cuando se envía un mensaje M, el 
cliente lo cifra con la llave , luego , etc., hasta llegar a . Consideremos el caso 
donde Alice está enviando un mensaje a Bob en un circuito de tamaño-3 → → . 
Digamos que denota el mensaje M cifrado con la clave simétrica y denota el 
mensaje M cifrado primero con , luego , posteriormente . El OP de Alice primero 
cifrará ese mensaje con la clave , luego y luego , y entonces el mensaje que envíe 
el OP de Alice será . 
Como el mensaje pase a través del circuito, cada router descifra el mensaje 
que recibe con su propia llave . Puede entonces pasar al siguiente router en el 
circuito (o a Bob, si este router es el último en el circuito). Así que mientras M 
vaya a través del circuito, se ve así:
Cuando Bob quiera regresar un mensaje M’, envía M’ a , que lo encripta 
con , y luego lo devuelve al circuito. Cada router lo encripta con su llave , y así el 
camino de vuelta de M’ es muy similar al camino de ida de M. Debido a que sólo 
Alice conoce las 3 claves , , y ,únicamente Alice puede descifrar el mensaje y leer 
M’. 
1.2. Células 
de Tor 
TOR se comunica sobre TCP para asegurar la entrega en orden. Toda 
la comunicación entre proxies y routers TOR se da en un protocolo a nivel de 
aplicación usando mensajes llamados Tor Cells (células TOR). El protocolo está 
especificado en el documento principal de las especificaciones de Tor, tor-spec.txt 
[3]. Hay dos versiones del protocolo. A día de hoy todos los procesos de TOR usan 
siempre la versión 2 de la especificación, y eso es lo que discutiremos aquí. 
CircId Command Payload (0-padded) 
2 bytes 1 byte PAYLOAD_LEN bytes 
FIGURA 1.1. Formato de las Células de Tor 
Las células TOR son de 512 bytes. El formato es el presentado en la Figura 
1.1. El campo Command define el tipo y propósito de la célula. Los valores 
comunes para Command incluyen: 
● CREATE 
● CREATED 
● RELAY 
● RELAY_EARLY 
● DESTROY
Las células CREATE son usadas para iniciar una conexión entre dos 
procesos Tor. Son enviadas por los proxies onion para crear el primer tramo en 
un circuito y también por los routers onion para extender el circuito un tramo. Las 
células CREATED son la respuesta a un CREATE exitoso. Las células RELAY y 
RELAY_EARLY son empaquetadores que contiene cada mensaje enviado sobre 
un circuito establecido. Serán discutidas en detalle en un momento. Las células 
DESTROY son enviadas a nodos adyacentes para destruir un circuito. El campo 
PAYLOAD es la parte de la célula que es cifrada. 
Relay Command ‘Recognized’ StreamID Digest Length Data 
1 byte 2 bytes 2 bytes 4 bytes 2 bytes 498 bytes 
FIGURA 1.2. Formato del Payload de una Célula RELAY 
Las células RELAY tienen una cabecera relay adicional incluida en su 
payload. El formato del payload de una célula RELAY se ilustra en la Figura 1.2. 
En el campo Relay command se define el propósito de la célula. Las células con 
relay command BEGIN, END, y CONNECTED son usadas para levantar y tumbar 
flujos TCP en un circuito. Con DATA son usadas para enviar datos a través de un 
flujo TCP. EXTEND y EXTENDED son usadas para construir un nuevo circuito y 
TRUNCATE y TRUNCATED son usadas para tumbar un circuito. Otros tipos de 
célula tratan con la comunicación del servidor directorio, DNS lookup, y control de 
congestión. 
Los campos ‘Recognized’ y Digest en la cabecera le permiten a un 
router determinar si la célula está o no completamente descifrada. Una célula es 
considerada completamente descifrada si el campo Recognized está en cero y 
Digest es los primeros cuatro bytes, del digest que está corriendo, de todos los 
destinados u originados en este tramo del circuito. Si la célula no se considera 
completamente descifrada es pasada al siguiente tramo del circuito. El campo 
StreamID es establecido por el OP y le permite tanto al OP como al router de 
salida distinguir entre múltiples flujos en un circuito. El campo "Length" es el 
número de bytes del campo "Data" que contienen información real. (La 
información restante es NUL-padded [revisar http://en.wikipedia.org/wiki/ 
Padding_(cryptography)#Hash_functions Sección Zero padding]).
Las células RELAY_EARLY son un tipo especial de célula RELAY usada 
para creación de circuitos. Los clientes que se comunican con la versión 2 del 
protocolo de enlace envían células relay de tipo EXTENDED en vez de células 
RELAY_EARLY. Un OR que recibe más de 8 células RELAY_EARLY cierra el 
circuito. Esto limita el tamaño máximo de cada circuito, lo cual ayuda a protegerse 
contra ciertos tipos de ataques, tal como el ataque de spinning packets (paquetes 
insertados en un router que aumentan tanto el flujo que el router deja de ser un 
nodo de entrada o salida funcional) de Pappas et al. [9]. 
1.2.1. Creación de un Circuito. En la Figura 1.3, presentamos un esquema 
para la creación del circuito. En este diagrama Alice ejecuta un OP y crea el 
circuito → → . (Con las claves simétricas, , y negociadas durante la creación del 
circuito.) 
FIGURA 1.3. Flujo de Trabajo de la Creación de un Circuito
1.3 Servidores de directorios 
Tor no es un servidor completamente distribuido. Un pequeño número 
de servidores de directorios llevan una lista -llamada documento de censo- de 
todos los routers en la red. Cada hora los servidores de directorios combinan su 
información y votan para crear un documento de censo actualizado. Los clientes 
y routers que corren en la red extraen un censo actualizado de un servidor de 
directorio una vez cada hora. El documento de censo -junto con los descriptores 
de routers publicados por cada router- proveen información suficiente para que los 
clientes se conecten y verifiquen la identidad de los routers en la red. 
1.4 Contribuciones de esta tesis 
Tor es comúnmente considerado vulnerable a los ataques de correlación 
extremo-a-extremo. Mientras el cifrado onion realizado por Tor previene una 
comparación directa de contenidos de paquetes, un atacante controlando el primer 
y último router tiene acceso a otra información, tal como la sincronización de 
paquetes, y esta información es comúnmente considerada suficiente para romper 
el anonimato de Tor. Sin embargo, los trabajos previos acerca del tema presentan 
dos problemas. Primero, la mayor parte del trabajo ha sido hecho sólo en teoría 
o en simulaciones, y estas últimas no necesariamente toman en cuenta todos los 
factores introducidos por Tor que pueden afectar un algoritmo de correlación dado. 
Segundo, el trabajo existente que ha sido hecho usando datos reales se enfoca en 
flujos con una gran cantidad de paquetes enviados, lo cual significa que un usuario 
de Tor podría ser capaz de evadir a un atacante sólo al enviar pequeñas cantidades 
de datos a la vez. 
Este trabajo busca responder dos preguntas. Primero, buscamos determinar 
si factores adicionales (tal como la latencia) introducidos por Tor, previenen que 
un ataque de correlación extremo-a-extremo pasivo funcione. Y segundo, si la 
correlación es factible, buscamos determinar si dichos ataques pueden funcionar 
incluso cuando los clientes transfieren sólo cantidades pequeñas de datos.
El Capítulo 2 provee un repaso del trabajo previo relacionado con la 
sincronización de correlación y otros ataques relacionados contra Tor. Esta 
información nos permitirá determinar por qué ciertos algoritmos funcionan o 
fracasan. El Capítulo 4 describe nuestro experimento y resultados por realizar 
una correlación sobre Tor. Incluye descripciones detalladas de dos algoritmos de 
correlación existentes y un nuevo y sencillo algoritmo de correlación, el diseño 
está basado en la información que examinamos en el Capítulo 3. Finalmente, el 
Capítulo 5 resume todo nuestro trabajo y sugiere áreas potenciales para futura 
investigación. 
Capítulo 2 
Ataques en Tor 
Diferentes tipos de ataques han sido propuestos para que funcionen en 
redes de baja-latencia en general y en Tor en particular. Este capítulo es una breve 
inspección a algunos de esos ataques. Dos de ellos serán estudiados detalladamente
y puestos a prueba en el Capítulo 4. 
2.1. Correlación de Flujo 
En ataques de correlación de flujo, un atacante que puede observar dos 
flujos de paquetes intenta verificar que pertenecen al mismo flujo en diferentes 
flujos de la red de anonimato. Ya que los flujos en Tor tienen cifrado onion (onion 
encryption), no pueden ser comparados directamente y el atacante debe intentar 
correlacionarlos usando otra información disponible. 
2.1.1. Conteo de Paquetes. El conteo de paquetes es una forma sencilla de 
la correlación de flujos. Tal como es propuesto por Back et. al [1], un atacante que 
puede observar routers onion cuenta el número de paquetes que entran y salen del 
primer router para determinar el siguiente nodo en el circuito. El procedimiento 
es posteriormente repetido en otros routers en el circuito hasta que se determina 
el destinatario. Aunque esta manera de contar paquetes es relativamente sencilla, 
requiere que el atacante sea capaz de observar una gran cantidad en la red, y asume 
que nunca hay una variación en el número de paquetes entrantes y salientes de 
un router en un flujo dado. Como tal, el conteo de paquetes ha sido opacado por 
técnicas más sofisticadas de correlación de flujos basadas en la sincronización de 
paquetes. 
2.1.2. Análisis de Sincronización. La sincronización de paquetes es otra 
parte de los datos que puede ser usada para correlacionar flujos de redes. Una 
forma sencilla de utilizar los datos de sincronización de paquetes es usar algún tipo 
de función de correlación para intentar correlacionar flujos basados en su retardo 
entre-paquetes – el tiempo entre la llegada de paquetes adyacentes al flujo. Sin 
embargo, este método puede tener problemas con paquetes caídos. Levine et al. [6] 
propusieron un algoritmo de correlación usando las series de tiempo construidas 
desde la información de sincronización de packing. Una serie de tiempo es una 
manera de mirar los datos de sincronización de paquetes. Para crear la serie de 
tiempo, establecemos una constante de tiempo W, dividimos el flujo de paquetes 
en ventanas de tamaño W y contamos cuántos paquetes entran en cada ventana. 
La función de correlación es un producto de vector normalizado. Ellos simularon
su algoritmo de correlación con cuatro tipos de tráfico usuario (tráfico generado 
por el estudio de 1996 de Berkeley HomeIP, tráfico aleatorio, tráfico constante y 
tráfico constante con paquetes caídos aleatorios) y mostraron que podían realizar 
exitosamente correlaciones en una mayoría de situaciones con un mínimo de falsos 
positivos. 
La debilidad de la mayor parte de ataques de sincronización es que depende 
en que el atacante controle los routers Tor, y requieren que los atacantes controlen 
una gran porción de la red Tor para que sean ampliamente efectivos [6]. Aunque 
ha habido mejoras propuestas (tal como la negación de Barisov et al. del servicio 
de ataque por lo cual atacar routers mata los circuitos que no pueden controlar 
[2]), también hay ataques de sincronización que no dependen en el control de 
routers individuales Tor. Murdoch y Zieliński [8] propusieron un ataque, donde los 
adversarios controlan los Intercambios de Internet y así pueden observar el tráfico 
que entra y sale de los países. Mostraron que podían hacer correlación (usando un 
algoritmo derivado de la fórmula de Bayes) incluso cuando habían rastreado un 
solo paquete de dos mil en un flujo dado. 
2.1.3. Correlación Activa de Sincronización. Los ataques de correlación 
activa son un esfuerzo por hacer las correlaciones basadas en el tiempo mucho 
más fáciles y efectivas. Funcionan al tener un router atacante alterando la señal 
de retraso de un paquete de una conexión al soltar o retrasar paquetes en un flujo. 
Fueron propuestos, pero no puestos a prueba, por Levine et al [6]. 
Wang et al. [10] demostró que los ataques activos de sincronización son 
factibles y efectivos contra protocolos altamente interactivos como VoIP, incluso 
cuando está protegido por servicio de anonimato de findnot.com. Realizaron 
ataques activos de sincronización en llamadas Skype punto-a-punto al crear e 
inyectar una marca de agua única al flujo. Encontraron que, si los parámetros 
correctos fuesen escogidos, podrían identificar correctamente 99% de los flujos 
con marcas de agua con una tasa de falsos positivos de 0%. Incrementar la tasa de 
identificación al 100% venía con el costo de tan sólo una tasa de 0,1% de falsos 
positivos. 
2.2. Atasco.
Murdoch y Danezis [7] presentaron un ataque de atasco, donde tomaron 
ventaja del hecho de que una conexión a través de n router tiene un efecto en las 
otras conexiones a través del mismo router. El atacante debe controlar un router 
Tor y ser capaz de observar una conexión en algún punto entre la salida del router 
Tor y su destino final. Usando el router Tor involucrado, el atacante puede crear 
circuitos de tamaño-uno en todos los demás routers Tor uno por uno para ver si 
esto incrementa la latencia de la conexión que el observador percibe o no. Si lo 
hace, entonces el router está en el circuito. Murdoch y Danezis probaron su ataque 
en la naciente red Tor y encontraron que el ataque funcionó contra 11 de los 13 
router de la red de aquél entonces. Sin embargo, ya que ahora hay casi 2.500 
routers trabajando, este ataque no necesariamente es viable. 
2.3. Round-Trip Travel Time 
Hopper et al. [5] presenta dos ataques que dependían del tiempo de ida-vuelta 
(Round-Trip Travel Time (RTT)) de los clientes a los servidores. En el 
primer ataque, el atacante está en control de dos servidores que están recibiendo 
conexiones del mismo router de salida. El objetivo del atacante es determinar 
si las conexiones vienen del mismo circuito. Utilizando uno de los muchos 
métodos (forzar el navegador del usuario a descargar miles de pequeñas imágenes 
secuencialmente, forzando al navegador del usuario por medio de unas series de 
redirecciones HTTP, o el uso de un protocolo interactivo como el IRC), ambos 
servidores obtienen un gran número de tiempos de ida y vuelta del cliente al 
cual están investigando. Es entonces cuando ellos comparan la frecuencia de 
distribuciones del RTTs. Si la frecuencia de distribución es similar, entonces las 
conexiones son probablemente del mismo circuito.
Capítulo 3 
Métricas para el Tráfico de Tor 
Nuestro objetivo final es evaluar la efectividad de la sincronización de los 
ataques de correlación extremo-a-extremo en la red Tor desplegada. No obstante, 
la mayoría de los algoritmos de correlación de los que hablaremos dependen de 
distintos factores para realizar la correlación, y por lo tanto antes de poner a prueba 
los algoritmos de correlación primero los aislaremos y examinaremos algunos de 
estos factores individualmente. Esto nos permitirá porque algunos funcionan o 
fracasan así como también proveerá la justificación para un nuevo algoritmo de 
correlación que presentamos en el Capítulo 4. Ya que estamos testeando la 
efectividad de estos algoritmos contra un atacante que controle routers Tor, el 
atacante tiene acceso a cualquier información a la que los routers tengan acceso, 
esto significa que el atacante puede usar células de datos Tor en vez de los 
paquetes de datos TCP. 
3.1. Tráfico en Tor 
Primero examinaremos el efecto que tiene Tor sobre nuestro tráfico de 
red. Tendremos en cuenta dos factores usados por los algoritmos de correlación:
la latencia entre la células de Tor, y la intensidad general del flujo. En una red 
ideal, esperaríamos que la latencia se mantenga constante, y que el flujo tarde 
exactamente lo mismo enviando y recibiendo. Sin embargo, los routers Tor tienen 
velocidades y cualidades de conexión diferentes, así que asumir que Tor es siquiera 
similar a una red ideal en estos aspectos supondría un problema. 
3.1.1. Arreglo del Test. Nuestra meta es probar si la correlación funciona 
cuando el atacante controla el router tanto de entrada como de salida, para esto 
usaremos routers privados de entrada y salida trabajando en el mismo computador 
para estos tests: sólo los routers intermedios cambiarán. 
Para nuestro grupo de control, utilizaremos otro router privado como el 
router intermedio. Será ejecutado en el mismo computador como la entrada y la 
salida. El tráfico que vaya a través de este router no será objeto de latencia, pues la 
conexión no estará en una red. Y ya que que no habrá otro tráfico viajando por el 
mismo router, no supondrá una carga significativa, por lo tanto las condiciones 
serán tan ideales como sea posible. 
Para nuestro primer grupo experimental, el router intermedio será un router 
público que controlemos. Este router es ejecutado desde un computador diferente, 
pero está en la misma red de área local que el computador corriendo los routers 
privados de entrada y salida, y así la latencia es baja y considerablemente 
constante. Durante el tiempo del test, nuestro router estuvo enrutando cerca de 
1Mbit/s del tráfico Tor, por lo que tiene carga, Este test nos permitirá determinar si 
la carga de los routers Tor afecta las métricas. 
Nuestro segundo grupo experimental utilizará una gran variedad de routers 
intermedios, para cada prueba, usaremos un router al azar de los disponibles en la 
red para que sea el router intermedio. Este grupo tendrá latencias y cargas de 
router variadas, y nos posibilitará observar su efecto combinado en las métricas. 
Para cada grupo, realizaremos pruebas con dos tipos de tráfico. El primero 
es un cliente ping que envía un ping y recibe una respuesta cada 200ms durante 30 
segundos. Este tipo será usado para medir la efecto de Tor en la latencia entre-células. 
El segundo tipo de tráfico es la descarga de un archivo de 1MiB, que será 
utilizado para verificar si la intensidad promedio del flujo varia. 
Nuestra recolección de información consiste en la obtención de la marca de 
tiempo de cada célula RELAY enviada o recibida por los routers de entrada o 
salida. Recolectamos estos datos modificando el código fuente de Tor para usar el
sistema existente de logging de Tor para registrar los datos de la célula Tor en un 
archivo. 
3.1.2. Resultados. Debido a que los dos tipos de tráfico que estamos 
estudiando son muy diferentes, usaremos diferentes métricas para evaluar el efecto 
que tuvieron al pasar a través de Tor. Para el tráfico de tasa-constante intermitente 
(“ping”), miraremos las distribuciones de retrasos entre paquetes consecutivos. Ya 
que el cliente está enviando los pings, esperamos que el retraso entre las células 
en el primer router sean casi constantes a 200 milisegundos (ms) (o muy cercano 
a eso). Suponemos que el retraso se mantendrá constante (o muy próximo a ello) 
en nuestro grupo de control, y que variará en ambos grupos experimentales. 
Realizamos rondas de recolección de datos con el grupo de control y ambos grupos 
experimentales. Las distribuciones de retraso entre-células de los tres se presentan 
en la Figura 3.1. 
FIGURA 3.1. Distribuciones de Retraso del Tráfico Ping Entre-Células 
Para el archivo de descarga, observamos diferentes métricas: la cantidad de 
tiempo que tomó enviar el archivo desde la salida de vuelta al router intermedio, y 
el tiempo tomado en recibir el archivo en el router de entrada desde el router 
intermedio. Los resultados para esto se ilustran en la Figura 3.2.
FIGURA 3.2. Incremento en el Tiempo Requerido para Recibir un Archivo en Tor 
3.1.3. Conclusiones. Como podemos apreciar en la Figura 3.1(a), el retraso 
entre-paquetes del tráfico ping llendo a través de routers locales, sin carga en 
nuestro grupo de control se mantiene casi exactamente igual entre los routers de 
entrada y salida. Los resultados para el primer grupo experimental -presentados 
en la Figura 3.1(b)- varian mucho más que los del grupo de control, con una 
desviación estándar de más del doble. De todas formas, el retraso se mantiene 
dentro de los 5ms de los esperados 200ms en el 80% del tiempo. Lo mismo no 
aplica para los resultados de nuestro segundo grupo experimental -presentados 
en la Figura 3.1(c)- donde la desviación estándar es incluso mayor, y la variación 
está en 5ms en menos del 50% del tiempo. Esto significa que incluso pequeñas 
cantidades de tráfico pueden ser susceptibles a latencias cambiantes cuando viajan 
por un circuito Tor, lo cual podría ser un problema para métodos de correlación 
que dependen en que el retraso se mantenga relativamente constante. 
La Figura 3.2 nos indica que el tiempo requerido para recibir datos en 
Tor es significativamente más grande que el tiempo que tomó enviarlos, que el 
incremento del tiempo varía y no puede ser predecido, y también que al menos 
parte de este incremento ocurre incluso en redes con condiciones ideales, como 
fue el caso de nuestro primer grupo experimental. Esto sugiere que los métodos de 
correlación que comparan vectores de información de sincronización directamente 
-tal como el método presentado en Levine et al. [6]- podrían no funcionar tan bien 
en la práctica como lo hacen en la teoría, pues los dos flujos tendrán magnitudes 
muy diferentes.
3.2. Tráfico de Router de Entrada 
Ahora tenemos alguna idea de qué le ocurre al tráfico cuando viaja por Tor. 
La información adicional sobre el tráfico de Tor también es útil, pues nos permite 
determinar factores que muy probablemente son únicos. Ya que hemos establecido 
que el tráfico en Tor tiene una latencia y una magnitud promedio no-constante ( 
y. por lo tanto, que estos pueden ser factores problemáticos en los que basar la 
métrica de la correlación), estudiaremos ahora otros dos factores: el tiempo de 
creación de un circuito, y el número total de células RELAY Tor en cada flujo 
observado. 
3.2.1. Arreglo del Test. Para este test, recolectaremos datos desde nuestro 
router público Tor. Prestaremos atención a la información acerca de los circuitos 
usando nuestro router como router de entrada o intermedio. Suponemos cual somos 
al verificar si el proceso Tor anterior al nuestro en el circuito está en conclusión o 
no. Si lo está, decimos que somos el router intermedio. De lo contrario, decimos 
que somos el router de entrada. Excluimos circuitos donde menos de 3 células sean 
registradas. Se requieren 2 células para la creación del circuito cuando se están 
usando circuitos Tor estándar de longitud-3. Se hicieron circuitos con menos de 3 
células pero nunca fueron usados para enviar o recibir información, así que intentar 
correlacionarlos no le daría al atacante información provechosa. 
3.2.2. Resultados. Los resultados están basados en aproximadamente 800 
creaciones de circuitos de entrada y otras 20.000 creaciones recogidas durante 
múltiples pruebas. Los resultados para el tiempo de distribución de la creación 
de nuevos circuitos son presentados en la Figura 3.3. Los resultados para la 
distribución del conteo de células inward-bound (inward-bound cells) de circuitos 
en nuestro router Tor se ilustran en la Figura 3.4.
FIGURA 3.3. Distribución del tiempo entre la creación consecutiva de circuitos en 
nuestro router Tor 
FIGURA 3.4. Distribución del conteo de células inward-bound 
3.2.3. Conclusiones. Como podemos observar en la Figura 3.3, la forma de 
las distribuciones de tiempo es muy similar para la creación de circuitos tanto de
entrada como de no-entrada, pero los valores son muy diferentes. Sin embargo, 
nuestros datos contenían muchas más creaciones de circuitos de no-entrada que 
de circuitos de entrada, y así estas variaciones en los valores tienen sentido. La 
Figura 3(b) tiene su eje-x a escala para que los valores sean 4% de los valores en la 
Figura 3(a), La proporción de creación entre circuitos de entrada y de no-entrada 
fue 4 : 100 también, así que las distribuciones se ven similares. Esto significa 
que la razón de que los valores sean significativamente diferentes es la tasa de 
creación de circuito, nada fundamentalmente distinto sobre los diferentes tipos de 
circuitos. Esto tiene sentido, debido a que la creación de circuito de no-entrada en 
nuestro router corresponde a la creación de circuito de entrada en un router Tor 
completamente diferente. 
Asimismo, los datos del tiempo de distribución nos indican que el tiempo 
de creación de un circuito puede tener una buena métrica por diferenciarse entre 
circuitos: incluso al considerar la gran cantidad de circuitos de no-entrada, menos 
del 30% de los circuitos tuvieron tiempos iniciales dentro de un tercio de segundo 
de otro circuito. 
Los datos de distribución de conteo -presentados en la Figura 3.4- nos 
muestran que la mayoría de circuitos son cortos: 50 - 60% de los circuitos tienen 
100 o menos devueltas al OP. Esto implica que un algoritmo de correlación 
efectivo necesita ser capaz de correlacionar circuitos tanto cortos como largos. En 
tanto a la información del tiempo de inicio del circuito, la forma de las 
distribuciones para los conteos de entrada y no-entrada son muy similares. 
Capítulo 4 
Prueba de Algoritmos de Correlación
Habiendo establecido los efectos que tiene el tráfico de red en Tor, 
regresamos a nuestro objetivo original: Poner a prueba métodos de correlación de 
sincronización en un tráfico real de Tor. 
4.1. Modelo de Ataque 
Para todas las siguientes definiciones, diremos que y son el primer y último 
router en un circuito, los cuales son controlados por un atacante cuya meta es 
violar el anonimato de Tor para un subconjunto de usuarios. Diremos que son 
flujos de células Tor observados en , y que son flujos de células Tor observados 
en , el router de entrada. Para cada , la meta del atacante es determinar si existe un 
tal que y sean el mismo flujo. Debido a que todos los algoritmos de correlación 
trabajan únicamente en dos flujos registrados al mismo tiempo, nos referiremos a 
los flujos a considerar como x y y por cuestiones de simplicidad. 
4.2. Definiciones de Algoritmo de Correlación 
Consideramos dos métodos existentes de correlación -escogidos porque 
están bien definidos y trabajan de forma distinta- y un método de correlación que 
desarrollamos. Primero consideramos el método de correlación de Levine et al. [6], 
el cual es un producto de vector normalizado que tiene en cuenta datos de 
sincronización de todas la células Tor observadas, y que fue originalmente puesto 
a prueba en una simulación. Posteriormente consideramos el método propuesto por 
Murdoch y Zieliński [8], que funciona sin valorar los datos de sincronización de 
células individuales, y que originalmente fue testeado en datos reales. Finalmente, 
proponemos un nuevo y simplificado algoritmo de correlación que también 
funciona sin considerar información de células individuales, y que es 
significativamente menos intensivo computacionalmente que cualquiera de los 
otros dos métodos. 
4.2.1. Correlación de Levine et al. El método propuesto por Levine et 
al. utiliza datos de sincronización de todas las células Tor observadas. Mientras 
algunos ataques publicados previamente intentaban usar la sincronización entre
células adyacentes como vectores de correlación, Levine et al. observaron que ese 
método es frágil porque es sensible a paquetes caídos. Su método es un producto 
de vector normalizado en una serie de tiempo generado a partir de los datos 
de sincronización observados, en vez de hacerlo directamente en los datos de 
sincronización. 
Para construir una serie de tiempo , escogemos un margen de tamaño w, 
dividimos el flujo de paquetes z entre márgenes no-superpuestos de tamaño w (Con 
padding-cero (Zero-padded) para que la serie de tiempo inicie y termine al mismo 
tiempo), y contamos el número de paquetes en cada margen. El vector de conteo de 
paquetes es la serie de tiempo. 
Definen la correlación-cruzada con el retardo d de la serie de tiempo de los 
flujos x y y como 
con siendo el elemento i-ario () de la serie de tiempo , y siendo el promedio entre 
todos los en . Para sus análisis, Levine et al. usaron un retraso de 0 y un margen de 
tamaño 10 segundos. 
Aquí, consideramos dos vectores y . La fórmula de correlación es el 
producto de de vector normalizado de estos dos vectores. El producto normalizado 
de dos vectores es más grande cuanto más cerca de ser vectores paralelos, por lo 
que un resultado grande indica que los dos vectores ( y, por lo tanto, los dos flujos 
de paquetes) están mucho más correlacionados. No obstante, el valor del producto 
de vectores estándar variará dependiendo de la magnitud de los vectores que se 
comparen, así que es útil normalizar los valores. Esto puede ser hecho tomando 
ventaja de la relación entre el valor del vector normalizado y el ángulo entre los 
dos vectores. 
Donde, a y b son vectores, es el producto de los vectores a y b, y es la magnitud 
del vector a . Para aislar y obtener el ángulo, podemos reescribir la fórmula de la 
siguiente manera:
Debido a que el dominio de arccos es (y ya que conocemos que el argumento 
es válido por la desigualdad de Cauchy-Schwarz), conocemos que el argumento 
también está en el rango . Puesto que arccos cambia y decrece constantemente 
de en ese intervalo, los dos vectores son paralelos cuando el argumento es 1, y 
antiparalelos cuando el valor es -1. El argumento para arccos en la fórmula anterior 
es el equivalente a la función de correlación, ya que el numerador en la fraction 
corresponde a la definición de producto de vectores, y el denominador es el 
producto de las magnitudes, calculadas usando el caso n-dimensional del teorema 
de Pitágoras. 
Un problema con el método de correlación de Levine et al. es que el 
resultado no está definido en ciertos casos. Ya que el algoritmo sustrae el valor 
promedio de una serie de tiempo de cada index antes de hacer la correlación, una 
serie de tiempo con el mismo número en cada index terminará teniendo ceros, 
resultando en una indeterminación por dividir entre cero. Cuando eso ocurre, 
retornamos una correlación de -1, que significa que en efecto no tenemos en cuenta 
ese resultado. Asimismo, sólo consideraremos correlaciones con un retraso d de 0, 
ya que eso fue lo que Levine et al. descubrieron era efectivo. 
4.2.2. Correlación de Murdoch y Zieliński. El método propuesto por 
Murdoch y Zieliński es una derivación de la fórmula de Bayes. Ellos modelan 
cada flujo p como un proceso Poisson con un tiempo inicial s, duración l, y una 
tasa r (paquetes promedio por segundo). Ya que el flujo real p no es observable, 
consideran entonces dos flujos x y y. Ambos pueden ser directamente observados 
por el atacante, y son modelados como procesos Poisson independientes desde los 
parámetros de p. Ellos pueden entonces derivar la probabilidad de que x y sean del 
mismo flujo usando la fórmula de Bayes: 
Debido a que sólo desean probabilidades relativas (más que absolutas), ignoran 
todos los factores independientes de k, lo que les permite derivar la probabilidad 
final:
Π(n) = (n - 1)!, es el número total de paquetes en y, , es la magnitud observada de 
x , y , es la magnitud total observada de x y y. 
La fórmula tiene tres partes, las cuales se multiplican entre sí para encontrar 
la probabilidad. La primera parte está basada en la tasa de paquetes observados 
en x y y, la segunda es un factor de corrección para la tasa, y la tercera parte es 
dependiente de la magnitud, lo cual ayuda a asegurar que sólo los flujos que 
ocurrieron casi al mismo tiempo y que duraron casi lo mismo son considerados. 
Este método de correlación fue originalmente propuesto para ser usado 
por un adversario que controla los intercambios de Internet, fuera de la red Tor, 
y que pudiese observar únicamente muestras pequeñas (cerca de 1 de cada 2000 
paquetes para cada flujo) de tráfico para un flujo dado. Sin embargo, este método 
de correlación puede ser usado dentro de la red Tor por un atacante que controle 
routers Tor, el cual es nuestro modelo de ataque. Un problema al usar este método 
de correlación en nuestro modelo es que sus probabilidades son estrictamente 
relativas y no normalizadas, así que no podemos establecer un punto de referencia 
que consideremos “suficientemente bueno” para que dos flujos se consideren 
correlacionados. Esto es problemático en casos donde quizá no necesariamente 
estemos viendo todas los flujos en la red, y por lo tanto no seamos capaces de 
correlacionar correctamente un x dado con un y observable. 
El resultado final del cálculo de ésta correlación muchas veces tiene un 
exponente extremadamente pequeño (usualmente de miles negativos o decenas de 
miles). Ya que ésta fórmula sólo calcula probabilidades relativas, podemos tomar 
su logaritmo sin perder información. Tomamos ventaja de este hecho y usamos una 
aproximación de Stirling para factoriales grandes que puedan acelerar de forma 
significativa el cálculo de la correlación. 
4.2.2. Correlación Simplificada. En el capítulo 3, cuantificamos los 
efectos de Tor en el tráfico de red, y descubrimos dos cosas al respecto. Primero, 
aprendimos que la latencia de células individuales viajando a través de Tor es 
variable, incluso dentro de un circuito dado. Segundo, aprendimos que el tiempo 
total que le toma a un flujo de paquetes entrar a Tor por un extremo es usualmente
menor que el que le toma a dicho flujo salir completamente de Tor por el otro 
extremo. El primero de estos factores puede afectar a los algoritmos de correlación 
que dependan en la sincronización de paquetes individuales (como el algoritmo 
presentado por Levine et al.), y el segundo de estos factores puede afectar 
algoritmos de correlación que dependan de la sincronización general del circuito, 
como el presentado por Murdoch y Zieliński. 
En un intento por contrarrestar ambos problemas, presentamos y probamos 
nuestro propio algoritmo de correlación. Este algoritmo tiene en cuenta dos 
factores: el tiempo inicial del circuito, y el número total de células Tor enviadas 
por el circuito. Para nuestro algoritmo de correlación, definimos la correlación c 
como 
En el capítulo 3 observamos que el tiempo inicial del circuito es relativamente 
único, y por eso lo usamos como la primera parte de nuestra correlación. Nuestra 
correlación. Nuestra correlación se enfoca en la diferencia de tiempo inicial entre x 
y y, y toma en cuenta la diferencia como un porcentaje de un tiempo fijado. Ya que 
nuestras medidas de tiempo están en milisegundos, y debido a que, como vimos en 
el capítulo 3, 20 segundos es muchísimo más tiempo que cualquier retraso que se 
pueda presentar en un circuito, usamos 20 segundos (o 20.000 milisegundos) como 
nuestro tiempo fijado T. Cuando la diferencia de tiempo es pequeña, el primer 
factor será muy cercano a 1. A medida que la diferencia entre tiempos incrementa, 
esta se vuelve negativa, así que se localiza en el rango . 
También sabemos que Tor garantiza la entrega de células de Tor, así que el 
número de células Tor en x y y debería ser el mismo después de tomar en cuenta 
cualquier célula usada para comunicarse con el router intermedio. (El proceso por 
el que se hace esto se explica en la siguiente sección). Por ende, usamos el conteo 
de células Tor (el número de células en el flujo x se denota ). Puesto que este factor 
es un porcentaje inverso del total de número de células enviadas en ambos flujos, 
su rango es [0,1]. 
Cuando se multiplican, los resultados varían en un rango de , Sin embargo, 
debido a que los resultados negativos significan que los circuitos tuvieron tiempos 
iniciales muy distintos, en realidad sólo necesitamos considerar resultados en un
rango de [0,1]. Esto implica que los valores de correlación positivos son absolutos 
en vez de ser relativos, y que pueden ser comparados directamente durante 
múltiples tests del algoritmo, en vez de relativamente en una ejecución dada. 
Además de ser más simple y usar menos información que los otros dos 
métodos previos, nuestro método de correlación simplificado también es 
significativamente más veloz al computar, pues depende únicamente en 
operaciones aritméticas básicas, y opera sólo con números que entran en la clase 
estándar int, haciéndolo una operación O(1) para realizar una única correlación de 
dos flujos. A diferencia de la correlación de Levine et al., que es O(n) en el 
número de paquetes observados para realizar una sola correlación porque necesita 
calcular un producto de vectores. La correlación de Murdoch y Zieliński es O(1) 
también cuando se usa la aproximación de Stirling, pero sigue siendo 
significativamente más lenta que nuestro método de correlación en la práctica. 
4.3. Organización del Test 
Controlamos un único router Tor abierto al público, el cual usaremos para 
recolectar datos para el test. Nuestro router es estable y un guardia, esto significa 
que algunos clientes lo usarán como su router de entrada. Lo usaremos para 
recoger información mientras éste sea el router de entrada o el router intermedio de 
un circuito. Así mismo, reuniremos datos de un router privado de salida usado 
exclusivamente por nosotros. Los datos agrupados consisten de las marcas de 
tiempo de las células RELAY enviadas y recibidas, junto con las direcciones y las 
identificaciones (ids) de circuito asociadas a cada célula. Puesto que no deseamos 
comprometer el anonimato de las personas utilizando nuestro router Tor, 
reemplazaremos cada dirección IP (que es la única información que registramos) 
con un string aleatorio único. 
Crearemos flujos con nuestro router público como la entrada, un router 
intermedio aleatorio, y nuestra salida privada. Realizaremos una correlación 
mucho-a-uno, correlacionando todos los datos observados (llamados anteriormente 
) en nuestro router público de entrada con cada flujo individual (un dado) en 
nuestro router privado de salida. 
La correlación para un flujo dado registrado en nuestro router privado de 
salida (y un algoritmo de correlación dado) será considerada parcialmente exitosa 
cuando el algoritmo de correlación sea capaz de identificar correctamente el flujo
correspondiente al router de entrada. No obstante, esta información sólo le es útil a 
un atacante cuando saben que existe un tal que y provienen del mismo flujo, y 
así la correlación sólo será considerada totalmente exitosa cuando el valor 
incorrecto más elevado de correlación sea menor que todos los valores correctos de 
correlación (para todo ) en una ejecución dada. Si el algoritmo es completamente 
exitoso de manera consistente entonces el atacante puede establecer una marca 
para la correlación, lo que les permite determinar si existe o no un que provino del 
mismo flujo que , además de determinar qué flujo es. 
Realizaremos tests con tres tipos de tráfico. Los primeros dos son el archivo 
de descarga de 1MiB y cliente ping discutidos en el capítulo 3, y el tercero es un 
archivo de descarga de 10KiB, que nos permite testear si la correlación puede ser 
hecha de forma exitosa en flujos muy pequeños. 
4.4. Resultados 
FIGURA 4.1. Resultados de correlación sólo con circuitos de entrada 
Los resultados de los test de algoritmos de correlación en 3 tipos de tráfico 
se presentan en la Figura 4.1 y la Figura 4.2. Aunque un atacante en realidad 
correlacionaría flujos que estén en el primer router del circuito, mostramos en el 
Capítulo 3 que los flujos de no-entrada no son esencialmente diferentes, así que 
presentamos los resultados combinados también para que podamos observar el 
desempeño de los algoritmos cuando se correlaciona un número mucho mayor de 
circuitos al mismo tiempo.
FIGURA 4.2. Resultados de correlación de todos los circuitos 
4.4.1. Resultados de la Correlación de Levine et al. Como podemos 
observar la correlación de Levine et al. sólo es efectiva para tráfico ping y las 
variaciones de margen de tiempo no son suficiente para hacerlo competitivo 
frente a los otro dos algoritmos de correlación para otros tipos de tráfico. Es 
muy probable que sea porque la correlación de Levine et al. depende en la 
sincronización de paquetes individuales, y, como ilustramos en el capítulo 3, la 
latencia del tráfico en Tor es altamente variable, incluso dentro del flujo de un 
paquete dado. 
4.4.2. Resultados de la Correlación de Murdoch y Zieliński. El algoritmo 
Bayesiano tiene una tasa alta de éxito parcial, pero una tasa baja de éxito total. 
Esto implica que un atacante que utiliza el algoritmo Bayesiano habría tenido que 
correlacionar flujos correctamente casi todo el tiempo mientras el atacante posea 
información de todos (o casi todos) los flujos de paquetes posibles. Sin embargo, 
ya que el atacante controla routers Tor directamente en nuestro modelo de ataque, 
un atacante necesitaría controlar la mayor parte de la red Tor para que esto sea 
factible, por lo tanto es improbable que el algoritmo Bayesiano sea efectivo para 
un atacante que controla un pequeño número de routers si le importa prevenir 
falsos positivos. Debido a que el algoritmo Bayesiano solo ofrece correlaciones 
relativas, este resultado no es sorprendente: el algoritmo no está diseñado 
para manejar posibles falsos positivos, porque es mucho menos probable que 
ocurran en el caso de uso original. Esto se debe a que el algoritmo Bayesiano fue
originalmente propuesto para el uso por un atacante que controle los intercambios 
de Internet que sirvan como nodos de conexión entre países. Dicho atacante sería 
capaz de observar cantidades de tráfico mayores a la vez que aquellos controlando 
un pequeño número de routers Tor. 
4.4.3. Resultados de la Correlación Simplificada. Nuestro algoritmo 
presenta el mejor desempeño. Tiene una tasa casi perfecta de éxito parcial para 
todos los tipos de tráfico, esto significa que si un atacante es capaz de observar 
tanto el flujo de entrada como de salida, muy probablemente podrá realizar la 
correlación. Así mismo, presenta una alta tasa de éxito total, por lo tanto un 
atacante usando el algoritmo simplificado será capaz de identificar la mayoría 
de casos en los que intente correlacionar un flujo del cual no conoce el otro 
extremo. Tiene sentido, ya que nuestro algoritmo simplificado produce un valor 
de correlación absoluto que puede ser comparado de manera significativa entre 
flujos. Esto hace de nuestro algoritmo simplificado la mejor opción para el modelo 
de ataque especificado, pues le permite a los atacantes que controlen un pequeño 
número de routers algún grado de protección contra falsos positivos. Además los 
resultados de nuestro algoritmo simplificado son consistentes entre los tres tipos 
de tráfico que pusimos a prueba, indicando que la correlación de sincronización 
puede ser realizada en Tor incluso en casos donde hay tan poca información siendo 
enviada por un circuito. Los usuarios no pueden evadir atacantes que usen el 
algoritmo simplificado de correlación enviando menos tráfico. 
4.4.4. Aplicación de los Resultados. Un problema con nuestros resultados 
es que están basados en un único router público. Nuestros resultados no 
necesariamente se generalizan a atacantes ejecutando muchos routers, porque 
estarán observando significativamente mayor tráfico. Nuestro algoritmo 
simplificado depende de dos factores -el tiempo inicial de flujo y el número de 
células del flujo- que son relativamente únicos para la cantidad de datos que 
fuimos capaces de poner a prueba. Estos dos factores dejarán de ser tan únicos 
cuanta mayor información tengamos, y por lo tanto suponemos que nuestro método 
de correlación simplificado no se desempeñará tan bien. 
Consideremos nuestro arreglo del test con un único router Tor. Basados en 
el número de circuitos creados a través de nuestro router en un período de tiempo 
t, el ancho de banda de nuestro router b, el total de ancho de banda de la red B,
podemos estimar aproximadamente el número de circuitos en todo Tor en este 
tiempo: . (Dividimos entre 3 porque los circuitos Tor estándar tienen 3 routers 
de longitud, indicando que la creación de circuito tuvo que ocurrir en 3 routers 
para que un solo router fuese creado.) En nuestro caso, durante el test nuestro 
router tuvo un ancho de banda de aproximadamente 1MB/s, y el total de ancho 
de banda de la red fue aproximadamente 900MB/s. Esto significa que un atacante 
potencialmente tendría que correlacionar 300 veces los flujos que correlacionamos 
en el mismo margen de tiempo. 
No obstante, nuestros modelos de ataque controlan directamente routers Tor, 
y pueden reunir información adicional para tener esto en cuenta. Más importante 
aún, tanto el router de entrada como el router de salida conocen la identidad del 
router intermedio para cualquier tráfico que envíen o reciban. Esto implica que el 
atacante sólo requiere intentar correlacionar tráficos de flujo que tengan el mismo 
router intermedio, lo cual reduce drásticamente el número de flujos que necesitan 
ser correlacionados. Incluso si excluimos los routers de salida completamente (y el 
mecanismo de selección de ruta de Tor no lo hace), bien hay más de 1.000 routers 
que puedan ser usados como router intermedio. Si pudiesemos asumir que cada 
uno de los 1.000 routers fueron escogidos equitativamente, eso significaría que 
tendríamos que ser capaces de reducir el número de flujos a correlacionar por un 
factor de 1.000, lo cual niega de sobremanera el hecho de que hay 300 veces tantos 
flujos promedio como observa nuestro router. Mientras algunos serán usados con 
mayor frecuencia que otros pues la selección de ruta de Tor se basa en el ancho 
de banda (junto con otros factores), aún habrá una reducción significativa en el 
número de flujos que necesitamos correlacionar. 
Igualmente, un atacante puede tomar ventaja del control de un router Tor lo 
que le permite asociar flujos yendo en direcciones opuestas en el mismo circuito. 
Los algoritmos de correlación anteriormente mencionados toman en cuenta 
únicamente flujos que viajan en la misma dirección, y el par (conteo de células 
inward, conteo de células outward) será más distintivo que el conteo de células 
viajando en una dirección, que también ayudará a contrarrestar el incremento en la 
cantidad de información. 
Por lo tanto, es improbable que un atacante controlando cientos o incluso 
miles de routers necesite correlacionar un número significativamente mayor de 
flujos de los que hemos hecho nosotros mismo con nuestro router, implicando 
que los factores que son lo suficientemente únicos para realizar la correlación de
nuestros datos permanecerán así para realizar la correlación cuando un atacante 
controle más routers. 
Capítulo 5 
Conclusión 
En este trabajo, nuestra meta fue determinar si era factible o no realizar 
ataque de correlación pasivos en Tor, también si era posible para los usuarios 
evadir atacantes que usen dichos ataques al enviar únicamente pequeñas cantidades 
de datos. 
Para ese fin, probamos dos algoritmos de correlación y descubrimos que 
ambos tienen debilidades. La correlación del producto de punto propuesto por 
Levine et al. es consistentemente exitosa en sólo uno de los tres tipos de tráfico que 
pusimos a prueba, y la correlación Bayesiana propuesta por Murdoch y Zieliński 
no tiene una manera confiable de evadir falsos positivos a menos que el atacante 
controle toda o casi toda la red. Asimismo diseñamos y probamos un nuevo y
simple algoritmo de correlación, que puede correlacionar confiablemente los tres 
tipos de tráfico, y el cual puede ser mucho más eficiente computacionalmente 
que cualquiera de los otros dos métodos. Aunque nuestros resultados sólo están 
basados en los datos recolectados por un único router, también explicamos como 
nuestro algoritmo puede escalar a atacantes controlando muchos más routers. 
Con nuestro nuevo y simple algoritmo de correlación, somos capaces de 
responder ambas de nuestras preguntas originales con un ‘Sí’. Es posible y factible 
realizar ataques de correlación pasivos en Tor usando nuestro algoritmo, y nuestro 
algoritmo es capaz de realizar la correlación incluso cuando pequeñas cantidades 
de información están siendo enviadas por Tor. 
Actualmente, sin embargo, nuestro trabajo requiere que el atacante controle 
de forma directa routers Tor, porque esto les da acceso a información mucho 
más precisa y les permite trabajar con células Tor en vez de paquetes TCP. Esto 
es un problema porque un atacante necesitaría controlar muchos routers para 
poder comprometer una cantidad significativa de tráfico en Tor. Un área de 
futura investigación sería en la que se observe si esta limitación puede superarse: 
¿Observar todo el tráfico TCP entrando y saliendo de un router es tan poderoso 
como controlar el router directamente? Si lo es, esto le permitiría a un ISP 
comprometer efectivamente cualquiera de los routers Tor a los que le provee el 
servicio de internet, lo cual, en cambio, posibilitaría a un gobierno la habilidad de 
comprometer exitosamente todos los routers dentro de las fronteras del país.
Bibliografía 
[1] Adam Back, Ulf Möller, y Anton Stiglic. Traffic analysis attacks and 
trade-offs in anonymity providing systems. En Ira S. Moskowitz, editor, 
Proceedings of Information Hiding Workshop (IH 2001), páginas 245-257. 
Springer-Verlag, LNCS 2137, Abril 2001. 
[2] Nikita Borisov, George Danezis, Prateek Mittal, y Parisa Tabriz. 
Denial of service or denial of security? How attacks on reliability can 
compromise anonymity. En Proceedings of CCS 2007, Octubre 2007. 
[3] Roger Dingledine y Nick Mathewson. tor-spec.txt. https:// 
gitweb.torproject.org/torspec.git/blob_plain/ 
3b5b8804f64a4db7ec7fc0185ea1afb7a2713797:/tor-spec.txt, 
Marzo 2011. 
[4] Roger Dingledine, Nick Mathewson, y Paul Syverson. Tor: The 
second-generation onion router. En Proceedings of the 19th USENIX 
Security Symposium, páginas 303-320, Agosto 2004. 
[5] Nicholas Hopper, Eugene Y. Vasserman, y Eric Chan-Tin. How much 
anonymity does network latency leak? ACM Transactions on Information 
and System Security, 13(2), Febrero 2010. 
[6] Brian N. Levine, Michael K. Reiter, Chenxi Wang, y Matthew K. 
Wright. Timing attacks in low-latency mix-based systems. En Ari Juels, 
editor, Proceedings of Financial Cryptography (FC’ 04), páginas 251-265. 
Springer-Verlag. LNCS 3110, Febrero 2004.
[7] Steven J. Murdoch y George Danezis. Low-cost traffic analysis of 
Tor. En Proceedings of the 2005 IEEE Symposium on Security and Privacy, 
páginas 183-195. IEEE CS, Mayo 2005. 
[8] Steven J. Murdoch y Piotr Zieliński. Sampled traffic analysis by 
internet-exchange-level adversaries. En Nikita Borisov y Philippe Golle, 
editores, Proceedings of the Seventh Workshop on Privacy Enhancing 
Technologies (PET 2007), páginas 92-102, Ottawa, Canadá, Junio 2007. 
Springer. 
[9] Vasilis Pappas, Elias Athanasopoulos, Sotiris Ioannidis, y Evangelo 
P. Markatos. Compromising anonymity using packet spinning. En T.-C. Wu, 
C.-L. Lei, V. Rijmen, y D.-T. Lee, editores, Information Security: 
Proceedings of the 11th International Conference, ISC 2008 (Taipei, 
Taiwan), volumen 5222 de Lecture Notes in Computer Science, páginas 161- 
174. Springer-Verlag, 2008. 
[10] Xinyuan Wang, Shiping Chen, y Sushil Jajodia. Tracking anonymous 
peer-to-peer voip calls on the internet. En Proceedings of the ACM 
Conference on Computer and Communications Security, páginas 81-91, 
Noviembre 2005.

Más contenido relacionado

La actualidad más candente

Concept of data communication and Network Types
Concept of data communication and  Network TypesConcept of data communication and  Network Types
Concept of data communication and Network TypesToufiqueAhmed13
 
Client server technology
Client server technologyClient server technology
Client server technologyAnwar Kamal
 
Introduction to Computer Networks
 Introduction to Computer Networks Introduction to Computer Networks
Introduction to Computer NetworksGhaffar Khan
 
Topics in wireless communication for project and thesis
Topics in wireless communication for project and thesisTopics in wireless communication for project and thesis
Topics in wireless communication for project and thesisTechsparks
 
Mobile Computing UNIT-6
Mobile Computing UNIT-6Mobile Computing UNIT-6
Mobile Computing UNIT-6Ramesh Babu
 
Distributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communicationDistributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communicationMNM Jain Engineering College
 
Chapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.pptChapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.pptsirajmohammed35
 
Transmission media
Transmission mediaTransmission media
Transmission mediaVikas Yadav
 
Introduction to Tiny OS
Introduction to Tiny OSIntroduction to Tiny OS
Introduction to Tiny OSSudharsan S
 
4.file service architecture
4.file service architecture4.file service architecture
4.file service architectureAbDul ThaYyal
 
Network architecture
Network architectureNetwork architecture
Network architectureOnline
 
Distributed os
Distributed osDistributed os
Distributed ossidra naz
 

La actualidad más candente (20)

IP Routing
IP RoutingIP Routing
IP Routing
 
Wifi
WifiWifi
Wifi
 
Concept of data communication and Network Types
Concept of data communication and  Network TypesConcept of data communication and  Network Types
Concept of data communication and Network Types
 
1.intro. to distributed system
1.intro. to distributed system1.intro. to distributed system
1.intro. to distributed system
 
Client server technology
Client server technologyClient server technology
Client server technology
 
Introduction to Computer Networks
 Introduction to Computer Networks Introduction to Computer Networks
Introduction to Computer Networks
 
Topics in wireless communication for project and thesis
Topics in wireless communication for project and thesisTopics in wireless communication for project and thesis
Topics in wireless communication for project and thesis
 
Mobile Computing UNIT-6
Mobile Computing UNIT-6Mobile Computing UNIT-6
Mobile Computing UNIT-6
 
Computer network basics
Computer network basicsComputer network basics
Computer network basics
 
Distributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communicationDistributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communication
 
Chapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.pptChapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.ppt
 
Dcn lecture 3
Dcn lecture 3Dcn lecture 3
Dcn lecture 3
 
Network And Topology
Network And TopologyNetwork And Topology
Network And Topology
 
Transmission media
Transmission mediaTransmission media
Transmission media
 
Introduction to Tiny OS
Introduction to Tiny OSIntroduction to Tiny OS
Introduction to Tiny OS
 
Ipv4 & ipv6
Ipv4 & ipv6Ipv4 & ipv6
Ipv4 & ipv6
 
4.file service architecture
4.file service architecture4.file service architecture
4.file service architecture
 
Network architecture
Network architectureNetwork architecture
Network architecture
 
Distributed os
Distributed osDistributed os
Distributed os
 
Hiperlan
HiperlanHiperlan
Hiperlan
 

Similar a Análisis de algoritmos de correlación en Tor

Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Esneyder Mahecha
 
Manual tecnicas de_scaning
Manual tecnicas de_scaningManual tecnicas de_scaning
Manual tecnicas de_scaningmillor2005
 
Denegación de servicio
Denegación de servicioDenegación de servicio
Denegación de servicioYufri Soto
 
Información básica
Información básicaInformación básica
Información básicahmitre17
 
Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Esneyder Mahecha
 
Redes locales Esneyder 301121_15
Redes locales Esneyder 301121_15Redes locales Esneyder 301121_15
Redes locales Esneyder 301121_15Esneyder Mahecha
 
Semana1 Introducción modelos arquitectura.pptx
Semana1 Introducción modelos arquitectura.pptxSemana1 Introducción modelos arquitectura.pptx
Semana1 Introducción modelos arquitectura.pptxfernando241073
 
unidad 5conceptos basicos y configuracion del switch
unidad 5conceptos basicos y configuracion del switchunidad 5conceptos basicos y configuracion del switch
unidad 5conceptos basicos y configuracion del switchBrenda Betzii
 
Cuarta unidad
Cuarta unidadCuarta unidad
Cuarta unidadJavo Leon
 
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.Dani Adastra
 
Carpa de red y de transporte
Carpa de red y de transporteCarpa de red y de transporte
Carpa de red y de transportecarlos566
 

Similar a Análisis de algoritmos de correlación en Tor (20)

Tor1
Tor1Tor1
Tor1
 
Tor. The Onion Router
Tor. The Onion RouterTor. The Onion Router
Tor. The Onion Router
 
Proyecto TOR
Proyecto TORProyecto TOR
Proyecto TOR
 
Firewall
FirewallFirewall
Firewall
 
Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15
 
Arquitecturas de red
Arquitecturas de redArquitecturas de red
Arquitecturas de red
 
Ataques Informáticos
Ataques InformáticosAtaques Informáticos
Ataques Informáticos
 
Manual tecnicas de_scaning
Manual tecnicas de_scaningManual tecnicas de_scaning
Manual tecnicas de_scaning
 
Denegación de servicio
Denegación de servicioDenegación de servicio
Denegación de servicio
 
Información básica
Información básicaInformación básica
Información básica
 
Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15Redes locales basico Esneyder Sanchez 301121_15
Redes locales basico Esneyder Sanchez 301121_15
 
Redes locales Esneyder 301121_15
Redes locales Esneyder 301121_15Redes locales Esneyder 301121_15
Redes locales Esneyder 301121_15
 
Semana1 Introducción modelos arquitectura.pptx
Semana1 Introducción modelos arquitectura.pptxSemana1 Introducción modelos arquitectura.pptx
Semana1 Introducción modelos arquitectura.pptx
 
unidad 5conceptos basicos y configuracion del switch
unidad 5conceptos basicos y configuracion del switchunidad 5conceptos basicos y configuracion del switch
unidad 5conceptos basicos y configuracion del switch
 
Contenido sara
Contenido saraContenido sara
Contenido sara
 
Cuarta unidad
Cuarta unidadCuarta unidad
Cuarta unidad
 
Ud5 hasta token
Ud5 hasta tokenUd5 hasta token
Ud5 hasta token
 
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.
Cybercamp 2017: Hacking TOR & Freenet for fun, profit and stop the evil.
 
Redes ii
Redes iiRedes ii
Redes ii
 
Carpa de red y de transporte
Carpa de red y de transporteCarpa de red y de transporte
Carpa de red y de transporte
 

Más de Chema Alonso

CyberCamp 2015: Low Hanging Fruit
CyberCamp 2015: Low Hanging FruitCyberCamp 2015: Low Hanging Fruit
CyberCamp 2015: Low Hanging FruitChema Alonso
 
Índice Pentesting con Kali 2.0
Índice Pentesting con Kali 2.0Índice Pentesting con Kali 2.0
Índice Pentesting con Kali 2.0Chema Alonso
 
Configurar y utilizar Latch en Magento
Configurar y utilizar Latch en MagentoConfigurar y utilizar Latch en Magento
Configurar y utilizar Latch en MagentoChema Alonso
 
Cazando Cibercriminales con: OSINT + Cloud Computing + Big Data
Cazando Cibercriminales con: OSINT + Cloud Computing + Big DataCazando Cibercriminales con: OSINT + Cloud Computing + Big Data
Cazando Cibercriminales con: OSINT + Cloud Computing + Big DataChema Alonso
 
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...New Paradigms of Digital Identity: Authentication & Authorization as a Servic...
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...Chema Alonso
 
CritoReto 4: Buscando una aguja en un pajar
CritoReto 4: Buscando una aguja en un pajarCritoReto 4: Buscando una aguja en un pajar
CritoReto 4: Buscando una aguja en un pajarChema Alonso
 
Dorking & Pentesting with Tacyt
Dorking & Pentesting with TacytDorking & Pentesting with Tacyt
Dorking & Pentesting with TacytChema Alonso
 
Pentesting con PowerShell: Libro de 0xWord
Pentesting con PowerShell: Libro de 0xWordPentesting con PowerShell: Libro de 0xWord
Pentesting con PowerShell: Libro de 0xWordChema Alonso
 
Recuperar dispositivos de sonido en Windows Vista y Windows 7
Recuperar dispositivos de sonido en Windows Vista y Windows 7Recuperar dispositivos de sonido en Windows Vista y Windows 7
Recuperar dispositivos de sonido en Windows Vista y Windows 7Chema Alonso
 
It's a Kind of Magic
It's a Kind of MagicIt's a Kind of Magic
It's a Kind of MagicChema Alonso
 
Ingenieros y hackers
Ingenieros y hackersIngenieros y hackers
Ingenieros y hackersChema Alonso
 
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...Chema Alonso
 
Auditoría de TrueCrypt: Informe final fase II
Auditoría de TrueCrypt: Informe final fase IIAuditoría de TrueCrypt: Informe final fase II
Auditoría de TrueCrypt: Informe final fase IIChema Alonso
 
El juego es el mismo
El juego es el mismoEl juego es el mismo
El juego es el mismoChema Alonso
 
El Hardware en Apple ¿Es tan bueno?
El Hardware en Apple ¿Es tan bueno?El Hardware en Apple ¿Es tan bueno?
El Hardware en Apple ¿Es tan bueno?Chema Alonso
 
Latch en Linux (Ubuntu): El cerrojo digital
Latch en Linux (Ubuntu): El cerrojo digitalLatch en Linux (Ubuntu): El cerrojo digital
Latch en Linux (Ubuntu): El cerrojo digitalChema Alonso
 
Hacking con Python
Hacking con PythonHacking con Python
Hacking con PythonChema Alonso
 
Tu iPhone es tan (in)seguro como tu Windows
Tu iPhone es tan (in)seguro como tu WindowsTu iPhone es tan (in)seguro como tu Windows
Tu iPhone es tan (in)seguro como tu WindowsChema Alonso
 

Más de Chema Alonso (20)

CyberCamp 2015: Low Hanging Fruit
CyberCamp 2015: Low Hanging FruitCyberCamp 2015: Low Hanging Fruit
CyberCamp 2015: Low Hanging Fruit
 
Índice Pentesting con Kali 2.0
Índice Pentesting con Kali 2.0Índice Pentesting con Kali 2.0
Índice Pentesting con Kali 2.0
 
Configurar y utilizar Latch en Magento
Configurar y utilizar Latch en MagentoConfigurar y utilizar Latch en Magento
Configurar y utilizar Latch en Magento
 
Cazando Cibercriminales con: OSINT + Cloud Computing + Big Data
Cazando Cibercriminales con: OSINT + Cloud Computing + Big DataCazando Cibercriminales con: OSINT + Cloud Computing + Big Data
Cazando Cibercriminales con: OSINT + Cloud Computing + Big Data
 
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...New Paradigms of Digital Identity: Authentication & Authorization as a Servic...
New Paradigms of Digital Identity: Authentication & Authorization as a Servic...
 
CritoReto 4: Buscando una aguja en un pajar
CritoReto 4: Buscando una aguja en un pajarCritoReto 4: Buscando una aguja en un pajar
CritoReto 4: Buscando una aguja en un pajar
 
Dorking & Pentesting with Tacyt
Dorking & Pentesting with TacytDorking & Pentesting with Tacyt
Dorking & Pentesting with Tacyt
 
Pentesting con PowerShell: Libro de 0xWord
Pentesting con PowerShell: Libro de 0xWordPentesting con PowerShell: Libro de 0xWord
Pentesting con PowerShell: Libro de 0xWord
 
Foca API v0.1
Foca API v0.1Foca API v0.1
Foca API v0.1
 
Recuperar dispositivos de sonido en Windows Vista y Windows 7
Recuperar dispositivos de sonido en Windows Vista y Windows 7Recuperar dispositivos de sonido en Windows Vista y Windows 7
Recuperar dispositivos de sonido en Windows Vista y Windows 7
 
It's a Kind of Magic
It's a Kind of MagicIt's a Kind of Magic
It's a Kind of Magic
 
Ingenieros y hackers
Ingenieros y hackersIngenieros y hackers
Ingenieros y hackers
 
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...
Cuarta Edición del Curso Online de Especialización en Seguridad Informática p...
 
Auditoría de TrueCrypt: Informe final fase II
Auditoría de TrueCrypt: Informe final fase IIAuditoría de TrueCrypt: Informe final fase II
Auditoría de TrueCrypt: Informe final fase II
 
El juego es el mismo
El juego es el mismoEl juego es el mismo
El juego es el mismo
 
El Hardware en Apple ¿Es tan bueno?
El Hardware en Apple ¿Es tan bueno?El Hardware en Apple ¿Es tan bueno?
El Hardware en Apple ¿Es tan bueno?
 
Latch en Linux (Ubuntu): El cerrojo digital
Latch en Linux (Ubuntu): El cerrojo digitalLatch en Linux (Ubuntu): El cerrojo digital
Latch en Linux (Ubuntu): El cerrojo digital
 
Hacking con Python
Hacking con PythonHacking con Python
Hacking con Python
 
Shuabang Botnet
Shuabang BotnetShuabang Botnet
Shuabang Botnet
 
Tu iPhone es tan (in)seguro como tu Windows
Tu iPhone es tan (in)seguro como tu WindowsTu iPhone es tan (in)seguro como tu Windows
Tu iPhone es tan (in)seguro como tu Windows
 

Último

CommitConf 2024 - Spring Boot <3 Testcontainers
CommitConf 2024 - Spring Boot <3 TestcontainersCommitConf 2024 - Spring Boot <3 Testcontainers
CommitConf 2024 - Spring Boot <3 TestcontainersIván López Martín
 
PROYECCIÓN DE VISTAS planos de vistas y mas
PROYECCIÓN DE VISTAS planos de vistas y masPROYECCIÓN DE VISTAS planos de vistas y mas
PROYECCIÓN DE VISTAS planos de vistas y maslida630411
 
Actividades de computación para alumnos de preescolar
Actividades de computación para alumnos de preescolarActividades de computación para alumnos de preescolar
Actividades de computación para alumnos de preescolar24roberto21
 
Nomisam: Base de Datos para Gestión de Nómina
Nomisam: Base de Datos para Gestión de NóminaNomisam: Base de Datos para Gestión de Nómina
Nomisam: Base de Datos para Gestión de Nóminacuellosameidy
 
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del Perú
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del PerúRed Dorsal Nacional de Fibra Óptica y Redes Regionales del Perú
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del PerúCEFERINO DELGADO FLORES
 
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024u20211198540
 
Trabajo de tecnología excel avanzado.pdf
Trabajo de tecnología excel avanzado.pdfTrabajo de tecnología excel avanzado.pdf
Trabajo de tecnología excel avanzado.pdfedepmariaperez
 
Clasificación de Conjuntos de Datos Desequilibrados.pptx
Clasificación de Conjuntos de Datos Desequilibrados.pptxClasificación de Conjuntos de Datos Desequilibrados.pptx
Clasificación de Conjuntos de Datos Desequilibrados.pptxCarolina Bujaico
 
Herramientas que posibilitan la información y la investigación.pdf
Herramientas que posibilitan la información y la investigación.pdfHerramientas que posibilitan la información y la investigación.pdf
Herramientas que posibilitan la información y la investigación.pdfKarinaCambero3
 
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docx
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docxPLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docx
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docxhasbleidit
 
Documentacion Electrónica en Actos Juridicos
Documentacion Electrónica en Actos JuridicosDocumentacion Electrónica en Actos Juridicos
Documentacion Electrónica en Actos JuridicosAlbanyMartinez7
 
La electricidad y la electronica.10-7.pdf
La electricidad y la electronica.10-7.pdfLa electricidad y la electronica.10-7.pdf
La electricidad y la electronica.10-7.pdfcristianrb0324
 
Viguetas Pretensadas en concreto armado
Viguetas Pretensadas  en concreto armadoViguetas Pretensadas  en concreto armado
Viguetas Pretensadas en concreto armadob7fwtwtfxf
 
TALLER DE ANALISIS SOLUCION PART 2 (1)-1.docx
TALLER DE ANALISIS SOLUCION  PART 2 (1)-1.docxTALLER DE ANALISIS SOLUCION  PART 2 (1)-1.docx
TALLER DE ANALISIS SOLUCION PART 2 (1)-1.docxobandopaula444
 
Guía de Registro slideshare paso a paso 1
Guía de Registro slideshare paso a paso 1Guía de Registro slideshare paso a paso 1
Guía de Registro slideshare paso a paso 1ivanapaterninar
 
certificado de oracle academy cetrificado.pdf
certificado de oracle academy cetrificado.pdfcertificado de oracle academy cetrificado.pdf
certificado de oracle academy cetrificado.pdfFernandoOblitasVivan
 
Trabajando con Formasy Smart art en power Point
Trabajando con Formasy Smart art en power PointTrabajando con Formasy Smart art en power Point
Trabajando con Formasy Smart art en power PointValerioIvanDePazLoja
 
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptx
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptxModelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptx
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptxtjcesar1
 
David_Gallegos - tarea de la sesión 11.pptx
David_Gallegos - tarea de la sesión 11.pptxDavid_Gallegos - tarea de la sesión 11.pptx
David_Gallegos - tarea de la sesión 11.pptxDAVIDROBERTOGALLEGOS
 

Último (20)

CommitConf 2024 - Spring Boot <3 Testcontainers
CommitConf 2024 - Spring Boot <3 TestcontainersCommitConf 2024 - Spring Boot <3 Testcontainers
CommitConf 2024 - Spring Boot <3 Testcontainers
 
PROYECCIÓN DE VISTAS planos de vistas y mas
PROYECCIÓN DE VISTAS planos de vistas y masPROYECCIÓN DE VISTAS planos de vistas y mas
PROYECCIÓN DE VISTAS planos de vistas y mas
 
Actividades de computación para alumnos de preescolar
Actividades de computación para alumnos de preescolarActividades de computación para alumnos de preescolar
Actividades de computación para alumnos de preescolar
 
Nomisam: Base de Datos para Gestión de Nómina
Nomisam: Base de Datos para Gestión de NóminaNomisam: Base de Datos para Gestión de Nómina
Nomisam: Base de Datos para Gestión de Nómina
 
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del Perú
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del PerúRed Dorsal Nacional de Fibra Óptica y Redes Regionales del Perú
Red Dorsal Nacional de Fibra Óptica y Redes Regionales del Perú
 
El camino a convertirse en Microsoft MVP
El camino a convertirse en Microsoft MVPEl camino a convertirse en Microsoft MVP
El camino a convertirse en Microsoft MVP
 
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024
Inteligencia Artificial. Matheo Hernandez Serrano USCO 2024
 
Trabajo de tecnología excel avanzado.pdf
Trabajo de tecnología excel avanzado.pdfTrabajo de tecnología excel avanzado.pdf
Trabajo de tecnología excel avanzado.pdf
 
Clasificación de Conjuntos de Datos Desequilibrados.pptx
Clasificación de Conjuntos de Datos Desequilibrados.pptxClasificación de Conjuntos de Datos Desequilibrados.pptx
Clasificación de Conjuntos de Datos Desequilibrados.pptx
 
Herramientas que posibilitan la información y la investigación.pdf
Herramientas que posibilitan la información y la investigación.pdfHerramientas que posibilitan la información y la investigación.pdf
Herramientas que posibilitan la información y la investigación.pdf
 
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docx
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docxPLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docx
PLANEACION DE CLASES TEMA TIPOS DE FAMILIA.docx
 
Documentacion Electrónica en Actos Juridicos
Documentacion Electrónica en Actos JuridicosDocumentacion Electrónica en Actos Juridicos
Documentacion Electrónica en Actos Juridicos
 
La electricidad y la electronica.10-7.pdf
La electricidad y la electronica.10-7.pdfLa electricidad y la electronica.10-7.pdf
La electricidad y la electronica.10-7.pdf
 
Viguetas Pretensadas en concreto armado
Viguetas Pretensadas  en concreto armadoViguetas Pretensadas  en concreto armado
Viguetas Pretensadas en concreto armado
 
TALLER DE ANALISIS SOLUCION PART 2 (1)-1.docx
TALLER DE ANALISIS SOLUCION  PART 2 (1)-1.docxTALLER DE ANALISIS SOLUCION  PART 2 (1)-1.docx
TALLER DE ANALISIS SOLUCION PART 2 (1)-1.docx
 
Guía de Registro slideshare paso a paso 1
Guía de Registro slideshare paso a paso 1Guía de Registro slideshare paso a paso 1
Guía de Registro slideshare paso a paso 1
 
certificado de oracle academy cetrificado.pdf
certificado de oracle academy cetrificado.pdfcertificado de oracle academy cetrificado.pdf
certificado de oracle academy cetrificado.pdf
 
Trabajando con Formasy Smart art en power Point
Trabajando con Formasy Smart art en power PointTrabajando con Formasy Smart art en power Point
Trabajando con Formasy Smart art en power Point
 
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptx
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptxModelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptx
Modelo de Presentacion Feria Robotica Educativa 2024 - Versión3.pptx
 
David_Gallegos - tarea de la sesión 11.pptx
David_Gallegos - tarea de la sesión 11.pptxDavid_Gallegos - tarea de la sesión 11.pptx
David_Gallegos - tarea de la sesión 11.pptx
 

Análisis de algoritmos de correlación en Tor

  • 1. Universidad Wesleyana El Colegio de Honores Analizando la Efectividad de Ataques de Correlación Pasivos en la Red de Anonimato Tor por Sam DeFabbia-Kane Clase del 2011 Traducción hecha por: Juan Eljach y Gustavo Rendón, Exploiter.co Una tesis entregada a la facultad de la Universidad Wesleyana como cumplimiento parcial de los requerimientos para el Diploma de Bachiller de Artes con Honores Departamentales en Ciencias de la Computación Middletown, Connecticut Abril 2011 Agradecimientos Primero quiero agradecer a Norman Danner y a Danny Krizane, quienes me han permitido trabajar con ellos en proyectos relacionados con Tor desde mi segundo año, y quienes han sido mis asesores para esta tesis. Estoy sumamente agradecido
  • 2. por su tiempo, consejo y paciencia. He sido capaz de haber pasado mucho tiempo en Wesleyan trabajando en un tema que encuentro extremadamente interesante, y me considero muy afortunado de haber tenido dicha oportunidad. También quisiera agradecer a mis amigos, quienes me apoyaron durante este proceso y durante todo mi tiempo en Wesleyan. He aprendido tanto de ellos como lo he hecho de las clases que he tomado aquí. Me gustaría agradecer especialmente a mis compañeros de piso. Andrew, Dan, Dave, Ryan, Jess y Lindsey han sido pacientes conmigo estas últimas semanas a pesar de que estuviese cansado, estresado, e irritable, y han sido maravillosos amigos todo el tiempo desde que los conozco en Wesleyan. Finalmente, quisiera agradecer a mis padres. Siempre han apoyado y animado mi curiosidad e intereses, y es ese apoyo el que me ha convertido en la persona que soy hoy día. ii Resumen Tor es un sistema de anonimato de baja-latencia ampliamente usado. Permite a los usuarios de navegadores web, clientes de un chat y otras aplicaciones de baja-latencia comunicarse anónimamente en línea al enrutar sus conexiones a través de un circuito de tres routers Tor. No obstante, Tor es comúnmente considerado vulnerable a una gran variedad de ataques, que le podrían permitir a operadores
  • 3. Tor u observadores ajenos comprometer el anonimato de los usuarios de Tor. Uno de estos ataques es el ataque de correlación extremo-a-extremo, por lo cual un atacante controlando el primer y último router en un circuito puede usar la sincronización y otros datos para correlacionar flujos observados en esos routers y por lo tanto violar el anonimato de Tor. Debido a que la mayoría de pruebas previas de algoritmos de correlación han sido usados bien sea en simulación o con sólo ciertos tipos de tráfico, nuestra meta fue verificar que tan bien funcionan estos algoritmos en la red Tor desplegada. En esta tesis probamos tres algoritmos de correlación. Dos de estos algoritmos son de trabajos previos, y el tercero fue diseñado por nosotros. Su diseño estuvo basado en observaciones y análisis de datos que recolectamos durante el proceso de prueba. Encontramos que mientras los dos algoritmos previamente existentes que testeamos tienen problemas que previenen que sean usados en ciertos casos, nuestro algoritmo funciona plenamente en todo tipo de de datos. iii Contenidos Capítulo 1. Introducción 1.1. Circuitos y Cifrado Onion 1.2. Células de Tor 1.3. Servidores de Directorios 1.4. Contribuciones de esta Tesis Capítulo 2. Ataques en Tor 2.1. Correlación de Flujo 2.2. Atasco 2.3. Round-Trip Travel Time
  • 4. Capítulo 3. Métricas para el Tráfico de Tor 3.1. Tráfico En Tor 3.2. Tráfico de Router de Entrada Capítulo 4. Prueba de Algoritmos de Correlación 4.1. Modelo de ataque 4.2. Definiciones de Algoritmo de Correlación 4.3. Organización del Test 4.4. Resultados Capítulo 5. Conclusión Bibliografía iv Capítulo 1 Introducción Cada uno de los mensajes que se envían por Internet tienen información de enrutamiento que puede ser usada para identificar el remitente y el destinatario del mensaje. Para muchos usuarios de Internet, esto supone un problema. Activistas, denunciantes anónimos y defensores de derechos humanos podrían querer ser anónimos para evadir la posible represión de gobiernos o corporaciones. Militares y fuerzas del orden podrían querer ser anónimos para poder recolectar información o realizar operaciones de seguimiento y captura sin ser identificados. Personas que viven en países o trabajan en compañías con internet censurado usarían el anonimato como una forma de burlar las medidas de censura. Hasta este punto, muchos sistemas de anonimato han sido desarrollados con el objetivo de facilitar la comunicación anónima online.
  • 5. Estos sistemas de anonimato están típicamente divididos en dos categorías: Los de baja latencia y los de alta latencia. Los de alta latencia - como Babel, Mixmaster y Mixminion- implementan medidas de defensa como mixing, padding, batching, y reordering en un intento de protegerse contra un adversario pasivo global que pueda observar todo el tráfico de la red [4]. Sin embargo, dichos sistemas sólo pueden ser usados con métodos de comunicación de alta latencia como el email, lo cual limita su utilidad al igual que a sus usuarios. Los sistemas de baja latencia por lo general no intentan proteger contra un adversario pasivo global, pero pueden ser usados con una variedad mucho más amplia de aplicaciones, incluyendo navegadores, clientes de chat y streaming de vídeo. Una red muy popular de anonimato de baja latencia es Tor [4]. Tor funciona enrutando la conexión de un usuario a través de 3 routers onion (onion routers; ORs), los cuales forman un circuito y actúan como una cadena de proxies. Los mensajes enviados a través de la conexión se ponen en capas con cifrado (usando una técnica llamada onion encryption) por tanto cada OR conoce solo su origen y destino inmediato. Los routers onion son puestos por voluntarios alrededor del mundo. Los routers son coordinados y catalogados por un pequeño conjunto de servidores de directorios que proveen información acerca de la red Tor y de routers disponibles para los clientes (quienes son llamados por lo general onion proxies o OPs). A pesar de que no intenta proteger contra un adversario pasivo global, Tor intenta proteger contra un adversario más limitado que puede observar parte del tráfico que viaja en la red, o que controla routers onion. Esto es importante porque cualquier persona puede correr un router onion, y los usuarios de Tor no tienen garantía de que los operadores de estos routers no son maliciosos. Sin embargo, a pesar de los objetivos en su diseño inicial, se asume comúnmente que Tor es vulnerable a muchas clases de ataques por adversarios no globales. En esta investigación, examinaremos uno de estos tipos de ataques: un ataque de correlación extremo-a-extremo pasivo por el cual un atacante controlando el primer y último router en un circuito puede comprometer el anonimato de la conexión que viaja a través de dicho circuito. Como se asume que Tor es vulnerable a este tipo de ataques, muchos de los trabajos anteriores en este tema han sido realizados en simulación o solo en teoría. Aquí buscamos probar la efectividad de estos ataques en una red Tor desplegada, y determinar si podemos
  • 6. crear un mejor ataque examinando las métricas del tráfico Tor. Este capítulo describe cómo funciona Tor y cuales son los objetivos de esta investigación. 1.1. Circuitos y Cifrado Onion Los usuarios que desean usar Tor enrutan su tráfico a través de un proxy onion (OP), el cual maneja transparentemente la creación y cifrado del circuito. El objetivo de Tor es el anonimato. Tor no provee cifrado extremo-a-extremo porque no puede cifrar el paso entre el router de salida y el servidor al que el cliente se está conectando. Para hacer eso requeriría la cooperación de el servidor, lo que significa que Tor no sería un proxy transparente. Tor, por lo tanto, no es un reemplazo para otras tecnologías de cifrado. Sin embargo, Tor usa cifrado por capas internamente, lo cual logra dos efectos. Primero, asegura que cada router onion (OR) conoce sólo a los nodos adyacentes del circuito. Segundo, previene que los atacantes puedan directamente comparar el tráfico en cualquier conjunto de dos puntos del circuito, debido a que el tráfico es cifrado de forma diferente (Por tanto se ve diferente) en cada punto. El proxy onion (OP) hace este cifrado negociando una clave simétrica con cada uno de los routers en el circuito y cifrando cada mensaje con cada llave simétrica, como se describe a continuación. Supongamos que son router en un circuito de tamaño n y que es una clave simétrica negociada entre el OP de Alice y . Las claves para son negociadas a través de los routers previos en el circuito . Cuando se envía un mensaje M, el cliente lo cifra con la llave , luego , etc., hasta llegar a . Consideremos el caso donde Alice está enviando un mensaje a Bob en un circuito de tamaño-3 → → . Digamos que denota el mensaje M cifrado con la clave simétrica y denota el mensaje M cifrado primero con , luego , posteriormente . El OP de Alice primero cifrará ese mensaje con la clave , luego y luego , y entonces el mensaje que envíe el OP de Alice será . Como el mensaje pase a través del circuito, cada router descifra el mensaje que recibe con su propia llave . Puede entonces pasar al siguiente router en el circuito (o a Bob, si este router es el último en el circuito). Así que mientras M vaya a través del circuito, se ve así:
  • 7. Cuando Bob quiera regresar un mensaje M’, envía M’ a , que lo encripta con , y luego lo devuelve al circuito. Cada router lo encripta con su llave , y así el camino de vuelta de M’ es muy similar al camino de ida de M. Debido a que sólo Alice conoce las 3 claves , , y ,únicamente Alice puede descifrar el mensaje y leer M’. 1.2. Células de Tor TOR se comunica sobre TCP para asegurar la entrega en orden. Toda la comunicación entre proxies y routers TOR se da en un protocolo a nivel de aplicación usando mensajes llamados Tor Cells (células TOR). El protocolo está especificado en el documento principal de las especificaciones de Tor, tor-spec.txt [3]. Hay dos versiones del protocolo. A día de hoy todos los procesos de TOR usan siempre la versión 2 de la especificación, y eso es lo que discutiremos aquí. CircId Command Payload (0-padded) 2 bytes 1 byte PAYLOAD_LEN bytes FIGURA 1.1. Formato de las Células de Tor Las células TOR son de 512 bytes. El formato es el presentado en la Figura 1.1. El campo Command define el tipo y propósito de la célula. Los valores comunes para Command incluyen: ● CREATE ● CREATED ● RELAY ● RELAY_EARLY ● DESTROY
  • 8. Las células CREATE son usadas para iniciar una conexión entre dos procesos Tor. Son enviadas por los proxies onion para crear el primer tramo en un circuito y también por los routers onion para extender el circuito un tramo. Las células CREATED son la respuesta a un CREATE exitoso. Las células RELAY y RELAY_EARLY son empaquetadores que contiene cada mensaje enviado sobre un circuito establecido. Serán discutidas en detalle en un momento. Las células DESTROY son enviadas a nodos adyacentes para destruir un circuito. El campo PAYLOAD es la parte de la célula que es cifrada. Relay Command ‘Recognized’ StreamID Digest Length Data 1 byte 2 bytes 2 bytes 4 bytes 2 bytes 498 bytes FIGURA 1.2. Formato del Payload de una Célula RELAY Las células RELAY tienen una cabecera relay adicional incluida en su payload. El formato del payload de una célula RELAY se ilustra en la Figura 1.2. En el campo Relay command se define el propósito de la célula. Las células con relay command BEGIN, END, y CONNECTED son usadas para levantar y tumbar flujos TCP en un circuito. Con DATA son usadas para enviar datos a través de un flujo TCP. EXTEND y EXTENDED son usadas para construir un nuevo circuito y TRUNCATE y TRUNCATED son usadas para tumbar un circuito. Otros tipos de célula tratan con la comunicación del servidor directorio, DNS lookup, y control de congestión. Los campos ‘Recognized’ y Digest en la cabecera le permiten a un router determinar si la célula está o no completamente descifrada. Una célula es considerada completamente descifrada si el campo Recognized está en cero y Digest es los primeros cuatro bytes, del digest que está corriendo, de todos los destinados u originados en este tramo del circuito. Si la célula no se considera completamente descifrada es pasada al siguiente tramo del circuito. El campo StreamID es establecido por el OP y le permite tanto al OP como al router de salida distinguir entre múltiples flujos en un circuito. El campo "Length" es el número de bytes del campo "Data" que contienen información real. (La información restante es NUL-padded [revisar http://en.wikipedia.org/wiki/ Padding_(cryptography)#Hash_functions Sección Zero padding]).
  • 9. Las células RELAY_EARLY son un tipo especial de célula RELAY usada para creación de circuitos. Los clientes que se comunican con la versión 2 del protocolo de enlace envían células relay de tipo EXTENDED en vez de células RELAY_EARLY. Un OR que recibe más de 8 células RELAY_EARLY cierra el circuito. Esto limita el tamaño máximo de cada circuito, lo cual ayuda a protegerse contra ciertos tipos de ataques, tal como el ataque de spinning packets (paquetes insertados en un router que aumentan tanto el flujo que el router deja de ser un nodo de entrada o salida funcional) de Pappas et al. [9]. 1.2.1. Creación de un Circuito. En la Figura 1.3, presentamos un esquema para la creación del circuito. En este diagrama Alice ejecuta un OP y crea el circuito → → . (Con las claves simétricas, , y negociadas durante la creación del circuito.) FIGURA 1.3. Flujo de Trabajo de la Creación de un Circuito
  • 10. 1.3 Servidores de directorios Tor no es un servidor completamente distribuido. Un pequeño número de servidores de directorios llevan una lista -llamada documento de censo- de todos los routers en la red. Cada hora los servidores de directorios combinan su información y votan para crear un documento de censo actualizado. Los clientes y routers que corren en la red extraen un censo actualizado de un servidor de directorio una vez cada hora. El documento de censo -junto con los descriptores de routers publicados por cada router- proveen información suficiente para que los clientes se conecten y verifiquen la identidad de los routers en la red. 1.4 Contribuciones de esta tesis Tor es comúnmente considerado vulnerable a los ataques de correlación extremo-a-extremo. Mientras el cifrado onion realizado por Tor previene una comparación directa de contenidos de paquetes, un atacante controlando el primer y último router tiene acceso a otra información, tal como la sincronización de paquetes, y esta información es comúnmente considerada suficiente para romper el anonimato de Tor. Sin embargo, los trabajos previos acerca del tema presentan dos problemas. Primero, la mayor parte del trabajo ha sido hecho sólo en teoría o en simulaciones, y estas últimas no necesariamente toman en cuenta todos los factores introducidos por Tor que pueden afectar un algoritmo de correlación dado. Segundo, el trabajo existente que ha sido hecho usando datos reales se enfoca en flujos con una gran cantidad de paquetes enviados, lo cual significa que un usuario de Tor podría ser capaz de evadir a un atacante sólo al enviar pequeñas cantidades de datos a la vez. Este trabajo busca responder dos preguntas. Primero, buscamos determinar si factores adicionales (tal como la latencia) introducidos por Tor, previenen que un ataque de correlación extremo-a-extremo pasivo funcione. Y segundo, si la correlación es factible, buscamos determinar si dichos ataques pueden funcionar incluso cuando los clientes transfieren sólo cantidades pequeñas de datos.
  • 11. El Capítulo 2 provee un repaso del trabajo previo relacionado con la sincronización de correlación y otros ataques relacionados contra Tor. Esta información nos permitirá determinar por qué ciertos algoritmos funcionan o fracasan. El Capítulo 4 describe nuestro experimento y resultados por realizar una correlación sobre Tor. Incluye descripciones detalladas de dos algoritmos de correlación existentes y un nuevo y sencillo algoritmo de correlación, el diseño está basado en la información que examinamos en el Capítulo 3. Finalmente, el Capítulo 5 resume todo nuestro trabajo y sugiere áreas potenciales para futura investigación. Capítulo 2 Ataques en Tor Diferentes tipos de ataques han sido propuestos para que funcionen en redes de baja-latencia en general y en Tor en particular. Este capítulo es una breve inspección a algunos de esos ataques. Dos de ellos serán estudiados detalladamente
  • 12. y puestos a prueba en el Capítulo 4. 2.1. Correlación de Flujo En ataques de correlación de flujo, un atacante que puede observar dos flujos de paquetes intenta verificar que pertenecen al mismo flujo en diferentes flujos de la red de anonimato. Ya que los flujos en Tor tienen cifrado onion (onion encryption), no pueden ser comparados directamente y el atacante debe intentar correlacionarlos usando otra información disponible. 2.1.1. Conteo de Paquetes. El conteo de paquetes es una forma sencilla de la correlación de flujos. Tal como es propuesto por Back et. al [1], un atacante que puede observar routers onion cuenta el número de paquetes que entran y salen del primer router para determinar el siguiente nodo en el circuito. El procedimiento es posteriormente repetido en otros routers en el circuito hasta que se determina el destinatario. Aunque esta manera de contar paquetes es relativamente sencilla, requiere que el atacante sea capaz de observar una gran cantidad en la red, y asume que nunca hay una variación en el número de paquetes entrantes y salientes de un router en un flujo dado. Como tal, el conteo de paquetes ha sido opacado por técnicas más sofisticadas de correlación de flujos basadas en la sincronización de paquetes. 2.1.2. Análisis de Sincronización. La sincronización de paquetes es otra parte de los datos que puede ser usada para correlacionar flujos de redes. Una forma sencilla de utilizar los datos de sincronización de paquetes es usar algún tipo de función de correlación para intentar correlacionar flujos basados en su retardo entre-paquetes – el tiempo entre la llegada de paquetes adyacentes al flujo. Sin embargo, este método puede tener problemas con paquetes caídos. Levine et al. [6] propusieron un algoritmo de correlación usando las series de tiempo construidas desde la información de sincronización de packing. Una serie de tiempo es una manera de mirar los datos de sincronización de paquetes. Para crear la serie de tiempo, establecemos una constante de tiempo W, dividimos el flujo de paquetes en ventanas de tamaño W y contamos cuántos paquetes entran en cada ventana. La función de correlación es un producto de vector normalizado. Ellos simularon
  • 13. su algoritmo de correlación con cuatro tipos de tráfico usuario (tráfico generado por el estudio de 1996 de Berkeley HomeIP, tráfico aleatorio, tráfico constante y tráfico constante con paquetes caídos aleatorios) y mostraron que podían realizar exitosamente correlaciones en una mayoría de situaciones con un mínimo de falsos positivos. La debilidad de la mayor parte de ataques de sincronización es que depende en que el atacante controle los routers Tor, y requieren que los atacantes controlen una gran porción de la red Tor para que sean ampliamente efectivos [6]. Aunque ha habido mejoras propuestas (tal como la negación de Barisov et al. del servicio de ataque por lo cual atacar routers mata los circuitos que no pueden controlar [2]), también hay ataques de sincronización que no dependen en el control de routers individuales Tor. Murdoch y Zieliński [8] propusieron un ataque, donde los adversarios controlan los Intercambios de Internet y así pueden observar el tráfico que entra y sale de los países. Mostraron que podían hacer correlación (usando un algoritmo derivado de la fórmula de Bayes) incluso cuando habían rastreado un solo paquete de dos mil en un flujo dado. 2.1.3. Correlación Activa de Sincronización. Los ataques de correlación activa son un esfuerzo por hacer las correlaciones basadas en el tiempo mucho más fáciles y efectivas. Funcionan al tener un router atacante alterando la señal de retraso de un paquete de una conexión al soltar o retrasar paquetes en un flujo. Fueron propuestos, pero no puestos a prueba, por Levine et al [6]. Wang et al. [10] demostró que los ataques activos de sincronización son factibles y efectivos contra protocolos altamente interactivos como VoIP, incluso cuando está protegido por servicio de anonimato de findnot.com. Realizaron ataques activos de sincronización en llamadas Skype punto-a-punto al crear e inyectar una marca de agua única al flujo. Encontraron que, si los parámetros correctos fuesen escogidos, podrían identificar correctamente 99% de los flujos con marcas de agua con una tasa de falsos positivos de 0%. Incrementar la tasa de identificación al 100% venía con el costo de tan sólo una tasa de 0,1% de falsos positivos. 2.2. Atasco.
  • 14. Murdoch y Danezis [7] presentaron un ataque de atasco, donde tomaron ventaja del hecho de que una conexión a través de n router tiene un efecto en las otras conexiones a través del mismo router. El atacante debe controlar un router Tor y ser capaz de observar una conexión en algún punto entre la salida del router Tor y su destino final. Usando el router Tor involucrado, el atacante puede crear circuitos de tamaño-uno en todos los demás routers Tor uno por uno para ver si esto incrementa la latencia de la conexión que el observador percibe o no. Si lo hace, entonces el router está en el circuito. Murdoch y Danezis probaron su ataque en la naciente red Tor y encontraron que el ataque funcionó contra 11 de los 13 router de la red de aquél entonces. Sin embargo, ya que ahora hay casi 2.500 routers trabajando, este ataque no necesariamente es viable. 2.3. Round-Trip Travel Time Hopper et al. [5] presenta dos ataques que dependían del tiempo de ida-vuelta (Round-Trip Travel Time (RTT)) de los clientes a los servidores. En el primer ataque, el atacante está en control de dos servidores que están recibiendo conexiones del mismo router de salida. El objetivo del atacante es determinar si las conexiones vienen del mismo circuito. Utilizando uno de los muchos métodos (forzar el navegador del usuario a descargar miles de pequeñas imágenes secuencialmente, forzando al navegador del usuario por medio de unas series de redirecciones HTTP, o el uso de un protocolo interactivo como el IRC), ambos servidores obtienen un gran número de tiempos de ida y vuelta del cliente al cual están investigando. Es entonces cuando ellos comparan la frecuencia de distribuciones del RTTs. Si la frecuencia de distribución es similar, entonces las conexiones son probablemente del mismo circuito.
  • 15. Capítulo 3 Métricas para el Tráfico de Tor Nuestro objetivo final es evaluar la efectividad de la sincronización de los ataques de correlación extremo-a-extremo en la red Tor desplegada. No obstante, la mayoría de los algoritmos de correlación de los que hablaremos dependen de distintos factores para realizar la correlación, y por lo tanto antes de poner a prueba los algoritmos de correlación primero los aislaremos y examinaremos algunos de estos factores individualmente. Esto nos permitirá porque algunos funcionan o fracasan así como también proveerá la justificación para un nuevo algoritmo de correlación que presentamos en el Capítulo 4. Ya que estamos testeando la efectividad de estos algoritmos contra un atacante que controle routers Tor, el atacante tiene acceso a cualquier información a la que los routers tengan acceso, esto significa que el atacante puede usar células de datos Tor en vez de los paquetes de datos TCP. 3.1. Tráfico en Tor Primero examinaremos el efecto que tiene Tor sobre nuestro tráfico de red. Tendremos en cuenta dos factores usados por los algoritmos de correlación:
  • 16. la latencia entre la células de Tor, y la intensidad general del flujo. En una red ideal, esperaríamos que la latencia se mantenga constante, y que el flujo tarde exactamente lo mismo enviando y recibiendo. Sin embargo, los routers Tor tienen velocidades y cualidades de conexión diferentes, así que asumir que Tor es siquiera similar a una red ideal en estos aspectos supondría un problema. 3.1.1. Arreglo del Test. Nuestra meta es probar si la correlación funciona cuando el atacante controla el router tanto de entrada como de salida, para esto usaremos routers privados de entrada y salida trabajando en el mismo computador para estos tests: sólo los routers intermedios cambiarán. Para nuestro grupo de control, utilizaremos otro router privado como el router intermedio. Será ejecutado en el mismo computador como la entrada y la salida. El tráfico que vaya a través de este router no será objeto de latencia, pues la conexión no estará en una red. Y ya que que no habrá otro tráfico viajando por el mismo router, no supondrá una carga significativa, por lo tanto las condiciones serán tan ideales como sea posible. Para nuestro primer grupo experimental, el router intermedio será un router público que controlemos. Este router es ejecutado desde un computador diferente, pero está en la misma red de área local que el computador corriendo los routers privados de entrada y salida, y así la latencia es baja y considerablemente constante. Durante el tiempo del test, nuestro router estuvo enrutando cerca de 1Mbit/s del tráfico Tor, por lo que tiene carga, Este test nos permitirá determinar si la carga de los routers Tor afecta las métricas. Nuestro segundo grupo experimental utilizará una gran variedad de routers intermedios, para cada prueba, usaremos un router al azar de los disponibles en la red para que sea el router intermedio. Este grupo tendrá latencias y cargas de router variadas, y nos posibilitará observar su efecto combinado en las métricas. Para cada grupo, realizaremos pruebas con dos tipos de tráfico. El primero es un cliente ping que envía un ping y recibe una respuesta cada 200ms durante 30 segundos. Este tipo será usado para medir la efecto de Tor en la latencia entre-células. El segundo tipo de tráfico es la descarga de un archivo de 1MiB, que será utilizado para verificar si la intensidad promedio del flujo varia. Nuestra recolección de información consiste en la obtención de la marca de tiempo de cada célula RELAY enviada o recibida por los routers de entrada o salida. Recolectamos estos datos modificando el código fuente de Tor para usar el
  • 17. sistema existente de logging de Tor para registrar los datos de la célula Tor en un archivo. 3.1.2. Resultados. Debido a que los dos tipos de tráfico que estamos estudiando son muy diferentes, usaremos diferentes métricas para evaluar el efecto que tuvieron al pasar a través de Tor. Para el tráfico de tasa-constante intermitente (“ping”), miraremos las distribuciones de retrasos entre paquetes consecutivos. Ya que el cliente está enviando los pings, esperamos que el retraso entre las células en el primer router sean casi constantes a 200 milisegundos (ms) (o muy cercano a eso). Suponemos que el retraso se mantendrá constante (o muy próximo a ello) en nuestro grupo de control, y que variará en ambos grupos experimentales. Realizamos rondas de recolección de datos con el grupo de control y ambos grupos experimentales. Las distribuciones de retraso entre-células de los tres se presentan en la Figura 3.1. FIGURA 3.1. Distribuciones de Retraso del Tráfico Ping Entre-Células Para el archivo de descarga, observamos diferentes métricas: la cantidad de tiempo que tomó enviar el archivo desde la salida de vuelta al router intermedio, y el tiempo tomado en recibir el archivo en el router de entrada desde el router intermedio. Los resultados para esto se ilustran en la Figura 3.2.
  • 18. FIGURA 3.2. Incremento en el Tiempo Requerido para Recibir un Archivo en Tor 3.1.3. Conclusiones. Como podemos apreciar en la Figura 3.1(a), el retraso entre-paquetes del tráfico ping llendo a través de routers locales, sin carga en nuestro grupo de control se mantiene casi exactamente igual entre los routers de entrada y salida. Los resultados para el primer grupo experimental -presentados en la Figura 3.1(b)- varian mucho más que los del grupo de control, con una desviación estándar de más del doble. De todas formas, el retraso se mantiene dentro de los 5ms de los esperados 200ms en el 80% del tiempo. Lo mismo no aplica para los resultados de nuestro segundo grupo experimental -presentados en la Figura 3.1(c)- donde la desviación estándar es incluso mayor, y la variación está en 5ms en menos del 50% del tiempo. Esto significa que incluso pequeñas cantidades de tráfico pueden ser susceptibles a latencias cambiantes cuando viajan por un circuito Tor, lo cual podría ser un problema para métodos de correlación que dependen en que el retraso se mantenga relativamente constante. La Figura 3.2 nos indica que el tiempo requerido para recibir datos en Tor es significativamente más grande que el tiempo que tomó enviarlos, que el incremento del tiempo varía y no puede ser predecido, y también que al menos parte de este incremento ocurre incluso en redes con condiciones ideales, como fue el caso de nuestro primer grupo experimental. Esto sugiere que los métodos de correlación que comparan vectores de información de sincronización directamente -tal como el método presentado en Levine et al. [6]- podrían no funcionar tan bien en la práctica como lo hacen en la teoría, pues los dos flujos tendrán magnitudes muy diferentes.
  • 19. 3.2. Tráfico de Router de Entrada Ahora tenemos alguna idea de qué le ocurre al tráfico cuando viaja por Tor. La información adicional sobre el tráfico de Tor también es útil, pues nos permite determinar factores que muy probablemente son únicos. Ya que hemos establecido que el tráfico en Tor tiene una latencia y una magnitud promedio no-constante ( y. por lo tanto, que estos pueden ser factores problemáticos en los que basar la métrica de la correlación), estudiaremos ahora otros dos factores: el tiempo de creación de un circuito, y el número total de células RELAY Tor en cada flujo observado. 3.2.1. Arreglo del Test. Para este test, recolectaremos datos desde nuestro router público Tor. Prestaremos atención a la información acerca de los circuitos usando nuestro router como router de entrada o intermedio. Suponemos cual somos al verificar si el proceso Tor anterior al nuestro en el circuito está en conclusión o no. Si lo está, decimos que somos el router intermedio. De lo contrario, decimos que somos el router de entrada. Excluimos circuitos donde menos de 3 células sean registradas. Se requieren 2 células para la creación del circuito cuando se están usando circuitos Tor estándar de longitud-3. Se hicieron circuitos con menos de 3 células pero nunca fueron usados para enviar o recibir información, así que intentar correlacionarlos no le daría al atacante información provechosa. 3.2.2. Resultados. Los resultados están basados en aproximadamente 800 creaciones de circuitos de entrada y otras 20.000 creaciones recogidas durante múltiples pruebas. Los resultados para el tiempo de distribución de la creación de nuevos circuitos son presentados en la Figura 3.3. Los resultados para la distribución del conteo de células inward-bound (inward-bound cells) de circuitos en nuestro router Tor se ilustran en la Figura 3.4.
  • 20. FIGURA 3.3. Distribución del tiempo entre la creación consecutiva de circuitos en nuestro router Tor FIGURA 3.4. Distribución del conteo de células inward-bound 3.2.3. Conclusiones. Como podemos observar en la Figura 3.3, la forma de las distribuciones de tiempo es muy similar para la creación de circuitos tanto de
  • 21. entrada como de no-entrada, pero los valores son muy diferentes. Sin embargo, nuestros datos contenían muchas más creaciones de circuitos de no-entrada que de circuitos de entrada, y así estas variaciones en los valores tienen sentido. La Figura 3(b) tiene su eje-x a escala para que los valores sean 4% de los valores en la Figura 3(a), La proporción de creación entre circuitos de entrada y de no-entrada fue 4 : 100 también, así que las distribuciones se ven similares. Esto significa que la razón de que los valores sean significativamente diferentes es la tasa de creación de circuito, nada fundamentalmente distinto sobre los diferentes tipos de circuitos. Esto tiene sentido, debido a que la creación de circuito de no-entrada en nuestro router corresponde a la creación de circuito de entrada en un router Tor completamente diferente. Asimismo, los datos del tiempo de distribución nos indican que el tiempo de creación de un circuito puede tener una buena métrica por diferenciarse entre circuitos: incluso al considerar la gran cantidad de circuitos de no-entrada, menos del 30% de los circuitos tuvieron tiempos iniciales dentro de un tercio de segundo de otro circuito. Los datos de distribución de conteo -presentados en la Figura 3.4- nos muestran que la mayoría de circuitos son cortos: 50 - 60% de los circuitos tienen 100 o menos devueltas al OP. Esto implica que un algoritmo de correlación efectivo necesita ser capaz de correlacionar circuitos tanto cortos como largos. En tanto a la información del tiempo de inicio del circuito, la forma de las distribuciones para los conteos de entrada y no-entrada son muy similares. Capítulo 4 Prueba de Algoritmos de Correlación
  • 22. Habiendo establecido los efectos que tiene el tráfico de red en Tor, regresamos a nuestro objetivo original: Poner a prueba métodos de correlación de sincronización en un tráfico real de Tor. 4.1. Modelo de Ataque Para todas las siguientes definiciones, diremos que y son el primer y último router en un circuito, los cuales son controlados por un atacante cuya meta es violar el anonimato de Tor para un subconjunto de usuarios. Diremos que son flujos de células Tor observados en , y que son flujos de células Tor observados en , el router de entrada. Para cada , la meta del atacante es determinar si existe un tal que y sean el mismo flujo. Debido a que todos los algoritmos de correlación trabajan únicamente en dos flujos registrados al mismo tiempo, nos referiremos a los flujos a considerar como x y y por cuestiones de simplicidad. 4.2. Definiciones de Algoritmo de Correlación Consideramos dos métodos existentes de correlación -escogidos porque están bien definidos y trabajan de forma distinta- y un método de correlación que desarrollamos. Primero consideramos el método de correlación de Levine et al. [6], el cual es un producto de vector normalizado que tiene en cuenta datos de sincronización de todas la células Tor observadas, y que fue originalmente puesto a prueba en una simulación. Posteriormente consideramos el método propuesto por Murdoch y Zieliński [8], que funciona sin valorar los datos de sincronización de células individuales, y que originalmente fue testeado en datos reales. Finalmente, proponemos un nuevo y simplificado algoritmo de correlación que también funciona sin considerar información de células individuales, y que es significativamente menos intensivo computacionalmente que cualquiera de los otros dos métodos. 4.2.1. Correlación de Levine et al. El método propuesto por Levine et al. utiliza datos de sincronización de todas las células Tor observadas. Mientras algunos ataques publicados previamente intentaban usar la sincronización entre
  • 23. células adyacentes como vectores de correlación, Levine et al. observaron que ese método es frágil porque es sensible a paquetes caídos. Su método es un producto de vector normalizado en una serie de tiempo generado a partir de los datos de sincronización observados, en vez de hacerlo directamente en los datos de sincronización. Para construir una serie de tiempo , escogemos un margen de tamaño w, dividimos el flujo de paquetes z entre márgenes no-superpuestos de tamaño w (Con padding-cero (Zero-padded) para que la serie de tiempo inicie y termine al mismo tiempo), y contamos el número de paquetes en cada margen. El vector de conteo de paquetes es la serie de tiempo. Definen la correlación-cruzada con el retardo d de la serie de tiempo de los flujos x y y como con siendo el elemento i-ario () de la serie de tiempo , y siendo el promedio entre todos los en . Para sus análisis, Levine et al. usaron un retraso de 0 y un margen de tamaño 10 segundos. Aquí, consideramos dos vectores y . La fórmula de correlación es el producto de de vector normalizado de estos dos vectores. El producto normalizado de dos vectores es más grande cuanto más cerca de ser vectores paralelos, por lo que un resultado grande indica que los dos vectores ( y, por lo tanto, los dos flujos de paquetes) están mucho más correlacionados. No obstante, el valor del producto de vectores estándar variará dependiendo de la magnitud de los vectores que se comparen, así que es útil normalizar los valores. Esto puede ser hecho tomando ventaja de la relación entre el valor del vector normalizado y el ángulo entre los dos vectores. Donde, a y b son vectores, es el producto de los vectores a y b, y es la magnitud del vector a . Para aislar y obtener el ángulo, podemos reescribir la fórmula de la siguiente manera:
  • 24. Debido a que el dominio de arccos es (y ya que conocemos que el argumento es válido por la desigualdad de Cauchy-Schwarz), conocemos que el argumento también está en el rango . Puesto que arccos cambia y decrece constantemente de en ese intervalo, los dos vectores son paralelos cuando el argumento es 1, y antiparalelos cuando el valor es -1. El argumento para arccos en la fórmula anterior es el equivalente a la función de correlación, ya que el numerador en la fraction corresponde a la definición de producto de vectores, y el denominador es el producto de las magnitudes, calculadas usando el caso n-dimensional del teorema de Pitágoras. Un problema con el método de correlación de Levine et al. es que el resultado no está definido en ciertos casos. Ya que el algoritmo sustrae el valor promedio de una serie de tiempo de cada index antes de hacer la correlación, una serie de tiempo con el mismo número en cada index terminará teniendo ceros, resultando en una indeterminación por dividir entre cero. Cuando eso ocurre, retornamos una correlación de -1, que significa que en efecto no tenemos en cuenta ese resultado. Asimismo, sólo consideraremos correlaciones con un retraso d de 0, ya que eso fue lo que Levine et al. descubrieron era efectivo. 4.2.2. Correlación de Murdoch y Zieliński. El método propuesto por Murdoch y Zieliński es una derivación de la fórmula de Bayes. Ellos modelan cada flujo p como un proceso Poisson con un tiempo inicial s, duración l, y una tasa r (paquetes promedio por segundo). Ya que el flujo real p no es observable, consideran entonces dos flujos x y y. Ambos pueden ser directamente observados por el atacante, y son modelados como procesos Poisson independientes desde los parámetros de p. Ellos pueden entonces derivar la probabilidad de que x y sean del mismo flujo usando la fórmula de Bayes: Debido a que sólo desean probabilidades relativas (más que absolutas), ignoran todos los factores independientes de k, lo que les permite derivar la probabilidad final:
  • 25. Π(n) = (n - 1)!, es el número total de paquetes en y, , es la magnitud observada de x , y , es la magnitud total observada de x y y. La fórmula tiene tres partes, las cuales se multiplican entre sí para encontrar la probabilidad. La primera parte está basada en la tasa de paquetes observados en x y y, la segunda es un factor de corrección para la tasa, y la tercera parte es dependiente de la magnitud, lo cual ayuda a asegurar que sólo los flujos que ocurrieron casi al mismo tiempo y que duraron casi lo mismo son considerados. Este método de correlación fue originalmente propuesto para ser usado por un adversario que controla los intercambios de Internet, fuera de la red Tor, y que pudiese observar únicamente muestras pequeñas (cerca de 1 de cada 2000 paquetes para cada flujo) de tráfico para un flujo dado. Sin embargo, este método de correlación puede ser usado dentro de la red Tor por un atacante que controle routers Tor, el cual es nuestro modelo de ataque. Un problema al usar este método de correlación en nuestro modelo es que sus probabilidades son estrictamente relativas y no normalizadas, así que no podemos establecer un punto de referencia que consideremos “suficientemente bueno” para que dos flujos se consideren correlacionados. Esto es problemático en casos donde quizá no necesariamente estemos viendo todas los flujos en la red, y por lo tanto no seamos capaces de correlacionar correctamente un x dado con un y observable. El resultado final del cálculo de ésta correlación muchas veces tiene un exponente extremadamente pequeño (usualmente de miles negativos o decenas de miles). Ya que ésta fórmula sólo calcula probabilidades relativas, podemos tomar su logaritmo sin perder información. Tomamos ventaja de este hecho y usamos una aproximación de Stirling para factoriales grandes que puedan acelerar de forma significativa el cálculo de la correlación. 4.2.2. Correlación Simplificada. En el capítulo 3, cuantificamos los efectos de Tor en el tráfico de red, y descubrimos dos cosas al respecto. Primero, aprendimos que la latencia de células individuales viajando a través de Tor es variable, incluso dentro de un circuito dado. Segundo, aprendimos que el tiempo total que le toma a un flujo de paquetes entrar a Tor por un extremo es usualmente
  • 26. menor que el que le toma a dicho flujo salir completamente de Tor por el otro extremo. El primero de estos factores puede afectar a los algoritmos de correlación que dependan en la sincronización de paquetes individuales (como el algoritmo presentado por Levine et al.), y el segundo de estos factores puede afectar algoritmos de correlación que dependan de la sincronización general del circuito, como el presentado por Murdoch y Zieliński. En un intento por contrarrestar ambos problemas, presentamos y probamos nuestro propio algoritmo de correlación. Este algoritmo tiene en cuenta dos factores: el tiempo inicial del circuito, y el número total de células Tor enviadas por el circuito. Para nuestro algoritmo de correlación, definimos la correlación c como En el capítulo 3 observamos que el tiempo inicial del circuito es relativamente único, y por eso lo usamos como la primera parte de nuestra correlación. Nuestra correlación. Nuestra correlación se enfoca en la diferencia de tiempo inicial entre x y y, y toma en cuenta la diferencia como un porcentaje de un tiempo fijado. Ya que nuestras medidas de tiempo están en milisegundos, y debido a que, como vimos en el capítulo 3, 20 segundos es muchísimo más tiempo que cualquier retraso que se pueda presentar en un circuito, usamos 20 segundos (o 20.000 milisegundos) como nuestro tiempo fijado T. Cuando la diferencia de tiempo es pequeña, el primer factor será muy cercano a 1. A medida que la diferencia entre tiempos incrementa, esta se vuelve negativa, así que se localiza en el rango . También sabemos que Tor garantiza la entrega de células de Tor, así que el número de células Tor en x y y debería ser el mismo después de tomar en cuenta cualquier célula usada para comunicarse con el router intermedio. (El proceso por el que se hace esto se explica en la siguiente sección). Por ende, usamos el conteo de células Tor (el número de células en el flujo x se denota ). Puesto que este factor es un porcentaje inverso del total de número de células enviadas en ambos flujos, su rango es [0,1]. Cuando se multiplican, los resultados varían en un rango de , Sin embargo, debido a que los resultados negativos significan que los circuitos tuvieron tiempos iniciales muy distintos, en realidad sólo necesitamos considerar resultados en un
  • 27. rango de [0,1]. Esto implica que los valores de correlación positivos son absolutos en vez de ser relativos, y que pueden ser comparados directamente durante múltiples tests del algoritmo, en vez de relativamente en una ejecución dada. Además de ser más simple y usar menos información que los otros dos métodos previos, nuestro método de correlación simplificado también es significativamente más veloz al computar, pues depende únicamente en operaciones aritméticas básicas, y opera sólo con números que entran en la clase estándar int, haciéndolo una operación O(1) para realizar una única correlación de dos flujos. A diferencia de la correlación de Levine et al., que es O(n) en el número de paquetes observados para realizar una sola correlación porque necesita calcular un producto de vectores. La correlación de Murdoch y Zieliński es O(1) también cuando se usa la aproximación de Stirling, pero sigue siendo significativamente más lenta que nuestro método de correlación en la práctica. 4.3. Organización del Test Controlamos un único router Tor abierto al público, el cual usaremos para recolectar datos para el test. Nuestro router es estable y un guardia, esto significa que algunos clientes lo usarán como su router de entrada. Lo usaremos para recoger información mientras éste sea el router de entrada o el router intermedio de un circuito. Así mismo, reuniremos datos de un router privado de salida usado exclusivamente por nosotros. Los datos agrupados consisten de las marcas de tiempo de las células RELAY enviadas y recibidas, junto con las direcciones y las identificaciones (ids) de circuito asociadas a cada célula. Puesto que no deseamos comprometer el anonimato de las personas utilizando nuestro router Tor, reemplazaremos cada dirección IP (que es la única información que registramos) con un string aleatorio único. Crearemos flujos con nuestro router público como la entrada, un router intermedio aleatorio, y nuestra salida privada. Realizaremos una correlación mucho-a-uno, correlacionando todos los datos observados (llamados anteriormente ) en nuestro router público de entrada con cada flujo individual (un dado) en nuestro router privado de salida. La correlación para un flujo dado registrado en nuestro router privado de salida (y un algoritmo de correlación dado) será considerada parcialmente exitosa cuando el algoritmo de correlación sea capaz de identificar correctamente el flujo
  • 28. correspondiente al router de entrada. No obstante, esta información sólo le es útil a un atacante cuando saben que existe un tal que y provienen del mismo flujo, y así la correlación sólo será considerada totalmente exitosa cuando el valor incorrecto más elevado de correlación sea menor que todos los valores correctos de correlación (para todo ) en una ejecución dada. Si el algoritmo es completamente exitoso de manera consistente entonces el atacante puede establecer una marca para la correlación, lo que les permite determinar si existe o no un que provino del mismo flujo que , además de determinar qué flujo es. Realizaremos tests con tres tipos de tráfico. Los primeros dos son el archivo de descarga de 1MiB y cliente ping discutidos en el capítulo 3, y el tercero es un archivo de descarga de 10KiB, que nos permite testear si la correlación puede ser hecha de forma exitosa en flujos muy pequeños. 4.4. Resultados FIGURA 4.1. Resultados de correlación sólo con circuitos de entrada Los resultados de los test de algoritmos de correlación en 3 tipos de tráfico se presentan en la Figura 4.1 y la Figura 4.2. Aunque un atacante en realidad correlacionaría flujos que estén en el primer router del circuito, mostramos en el Capítulo 3 que los flujos de no-entrada no son esencialmente diferentes, así que presentamos los resultados combinados también para que podamos observar el desempeño de los algoritmos cuando se correlaciona un número mucho mayor de circuitos al mismo tiempo.
  • 29. FIGURA 4.2. Resultados de correlación de todos los circuitos 4.4.1. Resultados de la Correlación de Levine et al. Como podemos observar la correlación de Levine et al. sólo es efectiva para tráfico ping y las variaciones de margen de tiempo no son suficiente para hacerlo competitivo frente a los otro dos algoritmos de correlación para otros tipos de tráfico. Es muy probable que sea porque la correlación de Levine et al. depende en la sincronización de paquetes individuales, y, como ilustramos en el capítulo 3, la latencia del tráfico en Tor es altamente variable, incluso dentro del flujo de un paquete dado. 4.4.2. Resultados de la Correlación de Murdoch y Zieliński. El algoritmo Bayesiano tiene una tasa alta de éxito parcial, pero una tasa baja de éxito total. Esto implica que un atacante que utiliza el algoritmo Bayesiano habría tenido que correlacionar flujos correctamente casi todo el tiempo mientras el atacante posea información de todos (o casi todos) los flujos de paquetes posibles. Sin embargo, ya que el atacante controla routers Tor directamente en nuestro modelo de ataque, un atacante necesitaría controlar la mayor parte de la red Tor para que esto sea factible, por lo tanto es improbable que el algoritmo Bayesiano sea efectivo para un atacante que controla un pequeño número de routers si le importa prevenir falsos positivos. Debido a que el algoritmo Bayesiano solo ofrece correlaciones relativas, este resultado no es sorprendente: el algoritmo no está diseñado para manejar posibles falsos positivos, porque es mucho menos probable que ocurran en el caso de uso original. Esto se debe a que el algoritmo Bayesiano fue
  • 30. originalmente propuesto para el uso por un atacante que controle los intercambios de Internet que sirvan como nodos de conexión entre países. Dicho atacante sería capaz de observar cantidades de tráfico mayores a la vez que aquellos controlando un pequeño número de routers Tor. 4.4.3. Resultados de la Correlación Simplificada. Nuestro algoritmo presenta el mejor desempeño. Tiene una tasa casi perfecta de éxito parcial para todos los tipos de tráfico, esto significa que si un atacante es capaz de observar tanto el flujo de entrada como de salida, muy probablemente podrá realizar la correlación. Así mismo, presenta una alta tasa de éxito total, por lo tanto un atacante usando el algoritmo simplificado será capaz de identificar la mayoría de casos en los que intente correlacionar un flujo del cual no conoce el otro extremo. Tiene sentido, ya que nuestro algoritmo simplificado produce un valor de correlación absoluto que puede ser comparado de manera significativa entre flujos. Esto hace de nuestro algoritmo simplificado la mejor opción para el modelo de ataque especificado, pues le permite a los atacantes que controlen un pequeño número de routers algún grado de protección contra falsos positivos. Además los resultados de nuestro algoritmo simplificado son consistentes entre los tres tipos de tráfico que pusimos a prueba, indicando que la correlación de sincronización puede ser realizada en Tor incluso en casos donde hay tan poca información siendo enviada por un circuito. Los usuarios no pueden evadir atacantes que usen el algoritmo simplificado de correlación enviando menos tráfico. 4.4.4. Aplicación de los Resultados. Un problema con nuestros resultados es que están basados en un único router público. Nuestros resultados no necesariamente se generalizan a atacantes ejecutando muchos routers, porque estarán observando significativamente mayor tráfico. Nuestro algoritmo simplificado depende de dos factores -el tiempo inicial de flujo y el número de células del flujo- que son relativamente únicos para la cantidad de datos que fuimos capaces de poner a prueba. Estos dos factores dejarán de ser tan únicos cuanta mayor información tengamos, y por lo tanto suponemos que nuestro método de correlación simplificado no se desempeñará tan bien. Consideremos nuestro arreglo del test con un único router Tor. Basados en el número de circuitos creados a través de nuestro router en un período de tiempo t, el ancho de banda de nuestro router b, el total de ancho de banda de la red B,
  • 31. podemos estimar aproximadamente el número de circuitos en todo Tor en este tiempo: . (Dividimos entre 3 porque los circuitos Tor estándar tienen 3 routers de longitud, indicando que la creación de circuito tuvo que ocurrir en 3 routers para que un solo router fuese creado.) En nuestro caso, durante el test nuestro router tuvo un ancho de banda de aproximadamente 1MB/s, y el total de ancho de banda de la red fue aproximadamente 900MB/s. Esto significa que un atacante potencialmente tendría que correlacionar 300 veces los flujos que correlacionamos en el mismo margen de tiempo. No obstante, nuestros modelos de ataque controlan directamente routers Tor, y pueden reunir información adicional para tener esto en cuenta. Más importante aún, tanto el router de entrada como el router de salida conocen la identidad del router intermedio para cualquier tráfico que envíen o reciban. Esto implica que el atacante sólo requiere intentar correlacionar tráficos de flujo que tengan el mismo router intermedio, lo cual reduce drásticamente el número de flujos que necesitan ser correlacionados. Incluso si excluimos los routers de salida completamente (y el mecanismo de selección de ruta de Tor no lo hace), bien hay más de 1.000 routers que puedan ser usados como router intermedio. Si pudiesemos asumir que cada uno de los 1.000 routers fueron escogidos equitativamente, eso significaría que tendríamos que ser capaces de reducir el número de flujos a correlacionar por un factor de 1.000, lo cual niega de sobremanera el hecho de que hay 300 veces tantos flujos promedio como observa nuestro router. Mientras algunos serán usados con mayor frecuencia que otros pues la selección de ruta de Tor se basa en el ancho de banda (junto con otros factores), aún habrá una reducción significativa en el número de flujos que necesitamos correlacionar. Igualmente, un atacante puede tomar ventaja del control de un router Tor lo que le permite asociar flujos yendo en direcciones opuestas en el mismo circuito. Los algoritmos de correlación anteriormente mencionados toman en cuenta únicamente flujos que viajan en la misma dirección, y el par (conteo de células inward, conteo de células outward) será más distintivo que el conteo de células viajando en una dirección, que también ayudará a contrarrestar el incremento en la cantidad de información. Por lo tanto, es improbable que un atacante controlando cientos o incluso miles de routers necesite correlacionar un número significativamente mayor de flujos de los que hemos hecho nosotros mismo con nuestro router, implicando que los factores que son lo suficientemente únicos para realizar la correlación de
  • 32. nuestros datos permanecerán así para realizar la correlación cuando un atacante controle más routers. Capítulo 5 Conclusión En este trabajo, nuestra meta fue determinar si era factible o no realizar ataque de correlación pasivos en Tor, también si era posible para los usuarios evadir atacantes que usen dichos ataques al enviar únicamente pequeñas cantidades de datos. Para ese fin, probamos dos algoritmos de correlación y descubrimos que ambos tienen debilidades. La correlación del producto de punto propuesto por Levine et al. es consistentemente exitosa en sólo uno de los tres tipos de tráfico que pusimos a prueba, y la correlación Bayesiana propuesta por Murdoch y Zieliński no tiene una manera confiable de evadir falsos positivos a menos que el atacante controle toda o casi toda la red. Asimismo diseñamos y probamos un nuevo y
  • 33. simple algoritmo de correlación, que puede correlacionar confiablemente los tres tipos de tráfico, y el cual puede ser mucho más eficiente computacionalmente que cualquiera de los otros dos métodos. Aunque nuestros resultados sólo están basados en los datos recolectados por un único router, también explicamos como nuestro algoritmo puede escalar a atacantes controlando muchos más routers. Con nuestro nuevo y simple algoritmo de correlación, somos capaces de responder ambas de nuestras preguntas originales con un ‘Sí’. Es posible y factible realizar ataques de correlación pasivos en Tor usando nuestro algoritmo, y nuestro algoritmo es capaz de realizar la correlación incluso cuando pequeñas cantidades de información están siendo enviadas por Tor. Actualmente, sin embargo, nuestro trabajo requiere que el atacante controle de forma directa routers Tor, porque esto les da acceso a información mucho más precisa y les permite trabajar con células Tor en vez de paquetes TCP. Esto es un problema porque un atacante necesitaría controlar muchos routers para poder comprometer una cantidad significativa de tráfico en Tor. Un área de futura investigación sería en la que se observe si esta limitación puede superarse: ¿Observar todo el tráfico TCP entrando y saliendo de un router es tan poderoso como controlar el router directamente? Si lo es, esto le permitiría a un ISP comprometer efectivamente cualquiera de los routers Tor a los que le provee el servicio de internet, lo cual, en cambio, posibilitaría a un gobierno la habilidad de comprometer exitosamente todos los routers dentro de las fronteras del país.
  • 34. Bibliografía [1] Adam Back, Ulf Möller, y Anton Stiglic. Traffic analysis attacks and trade-offs in anonymity providing systems. En Ira S. Moskowitz, editor, Proceedings of Information Hiding Workshop (IH 2001), páginas 245-257. Springer-Verlag, LNCS 2137, Abril 2001. [2] Nikita Borisov, George Danezis, Prateek Mittal, y Parisa Tabriz. Denial of service or denial of security? How attacks on reliability can compromise anonymity. En Proceedings of CCS 2007, Octubre 2007. [3] Roger Dingledine y Nick Mathewson. tor-spec.txt. https:// gitweb.torproject.org/torspec.git/blob_plain/ 3b5b8804f64a4db7ec7fc0185ea1afb7a2713797:/tor-spec.txt, Marzo 2011. [4] Roger Dingledine, Nick Mathewson, y Paul Syverson. Tor: The second-generation onion router. En Proceedings of the 19th USENIX Security Symposium, páginas 303-320, Agosto 2004. [5] Nicholas Hopper, Eugene Y. Vasserman, y Eric Chan-Tin. How much anonymity does network latency leak? ACM Transactions on Information and System Security, 13(2), Febrero 2010. [6] Brian N. Levine, Michael K. Reiter, Chenxi Wang, y Matthew K. Wright. Timing attacks in low-latency mix-based systems. En Ari Juels, editor, Proceedings of Financial Cryptography (FC’ 04), páginas 251-265. Springer-Verlag. LNCS 3110, Febrero 2004.
  • 35. [7] Steven J. Murdoch y George Danezis. Low-cost traffic analysis of Tor. En Proceedings of the 2005 IEEE Symposium on Security and Privacy, páginas 183-195. IEEE CS, Mayo 2005. [8] Steven J. Murdoch y Piotr Zieliński. Sampled traffic analysis by internet-exchange-level adversaries. En Nikita Borisov y Philippe Golle, editores, Proceedings of the Seventh Workshop on Privacy Enhancing Technologies (PET 2007), páginas 92-102, Ottawa, Canadá, Junio 2007. Springer. [9] Vasilis Pappas, Elias Athanasopoulos, Sotiris Ioannidis, y Evangelo P. Markatos. Compromising anonymity using packet spinning. En T.-C. Wu, C.-L. Lei, V. Rijmen, y D.-T. Lee, editores, Information Security: Proceedings of the 11th International Conference, ISC 2008 (Taipei, Taiwan), volumen 5222 de Lecture Notes in Computer Science, páginas 161- 174. Springer-Verlag, 2008. [10] Xinyuan Wang, Shiping Chen, y Sushil Jajodia. Tracking anonymous peer-to-peer voip calls on the internet. En Proceedings of the ACM Conference on Computer and Communications Security, páginas 81-91, Noviembre 2005.