Universidad Wesleyana

El Colegio de Honores

Analizando la Efectividad de Ataques de Correlacin

Pasivos en la Red de Anonimato Tor
por
Sam DeFabbia-Kane
Clase del 2011

Traduccin hecha por: Juan Eljach y Gustavo Rendn, 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 Computacin

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
ao, 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.
Tambin 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 gustara agradecer especialmente
a mis compaeros 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 da.

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 bajalatencia comunicarse annimamente en lnea al enrutar sus conexiones a travs
de un circuito de tres routers Tor. No obstante, Tor es comnmente considerado
vulnerable a una gran variedad de ataques, que le podran permitir a operadores

Tor u observadores ajenos comprometer el anonimato de los usuarios de Tor.

Uno de estos ataques es el ataque de correlacin extremo-a-extremo, por lo cual
un atacante controlando el primer y ltimo router en un circuito puede usar la
sincronizacin y otros datos para correlacionar flujos observados en esos routers y
por lo tanto violar el anonimato de Tor.
Debido a que la mayora de pruebas previas de algoritmos de correlacin
han sido usados bien sea en simulacin o con slo ciertos tipos de trfico, nuestra
meta fue verificar que tan bien funcionan estos algoritmos en la red Tor
desplegada. En esta tesis probamos tres algoritmos de correlacin. Dos de estos
algoritmos son de trabajos previos, y el tercero fue diseado por nosotros. Su
diseo estuvo basado en observaciones y anlisis 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
Captulo 1. Introduccin
1.1. Circuitos y Cifrado Onion
1.2. Clulas de Tor
1.3. Servidores de Directorios
1.4. Contribuciones de esta Tesis
Captulo 2. Ataques en Tor
2.1. Correlacin de Flujo
2.2. Atasco
2.3. Round-Trip Travel Time

Captulo 3. Mtricas para el Trfico de Tor

3.1. Trfico En Tor
3.2. Trfico de Router de Entrada
Captulo 4. Prueba de Algoritmos de Correlacin
4.1. Modelo de ataque
4.2. Definiciones de Algoritmo de Correlacin
4.3. Organizacin del Test
4.4. Resultados
Captulo 5. Conclusin
Bibliografa

iv
Captulo 1

Introduccin
Cada uno de los mensajes que se envan por Internet tienen informacin 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 annimos y defensores de derechos humanos podran querer ser
annimos para evadir la posible represin de gobiernos o corporaciones. Militares
y fuerzas del orden podran querer ser annimos para poder recolectar informacin
o realizar operaciones de seguimiento y captura sin ser identificados. Personas
que viven en pases o trabajan en compaas con internet censurado usaran 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
comunicacin annima online.

Estos sistemas de anonimato estn tpicamente divididos en dos categoras:

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 trfico de la red [4]. Sin embargo,
dichos sistemas slo pueden ser usados con mtodos de comunicacin 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 ms amplia de
aplicaciones, incluyendo navegadores, clientes de chat y streaming de vdeo.
Una red muy popular de anonimato de baja latencia es Tor [4]. Tor funciona
enrutando la conexin de un usuario a travs de 3 routers onion (onion routers;
ORs), los cuales forman un circuito y actan como una cadena de proxies. Los
mensajes enviados a travs de la conexin se ponen en capas con cifrado (usando
una tcnica 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 pequeo
conjunto de servidores de directorios que proveen informacin 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 ms limitado que puede observar parte
del trfico 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 garanta de que los operadores de estos routers no son maliciosos. Sin
embargo, a pesar de los objetivos en su diseo inicial, se asume comnmente que
Tor es vulnerable a muchas clases de ataques por adversarios no globales. En esta
investigacin, examinaremos uno de estos tipos de ataques: un ataque de
correlacin extremo-a-extremo pasivo por el cual un atacante controlando el
primer y ltimo router en un circuito puede comprometer el anonimato de la
conexin que viaja a travs 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 simulacin o solo en teora. Aqu buscamos probar la
efectividad de estos ataques en una red Tor desplegada, y determinar si podemos

crear un mejor ataque examinando las mtricas del trfico Tor. Este captulo
describe cmo funciona Tor y cuales son los objetivos de esta investigacin.

1.1. Circuitos y Cifrado Onion

Los usuarios que desean usar Tor enrutan su trfico a travs de un proxy
onion (OP), el cual maneja transparentemente la creacin 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 requerira la cooperacin de el servidor,
lo que significa que Tor no sera un proxy transparente. Tor, por lo tanto, no es un
reemplazo para otras tecnologas de cifrado. Sin embargo, Tor usa cifrado por
capas internamente, lo cual logra dos efectos. Primero, asegura que cada router
onion (OR) conoce slo a los nodos adyacentes del circuito. Segundo, previene que
los atacantes puedan directamente comparar el trfico en cualquier conjunto de dos
puntos del circuito, debido a que el trfico es cifrado de forma diferente (Por tanto
se ve diferente) en cada punto. El proxy onion (OP) hace este cifrado negociando
una clave simtrica con cada uno de los routers en el circuito y cifrando cada
mensaje con cada llave simtrica, como se describe a continuacin.
Supongamos que son router en un circuito de tamao n y que es una clave
simtrica negociada entre el OP de Alice y . Las claves para son negociadas a
travs de los routers previos en el circuito . Cuando se enva 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 tamao-3 .
Digamos que denota el mensaje M cifrado con la clave simtrica 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 enve
el OP de Alice ser .
Como el mensaje pase a travs 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 travs del circuito, se ve as:

Cuando Bob quiera regresar un mensaje M, enva 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 slo
Alice conoce las 3 claves , , y ,nicamente Alice puede descifrar el mensaje y leer
M.
1.2.
de

Clulas
Tor

TOR se comunica sobre TCP para asegurar la entrega en orden. Toda

la comunicacin entre proxies y routers TOR se da en un protocolo a nivel de
aplicacin usando mensajes llamados Tor Cells (clulas TOR). El protocolo est
especificado en el documento principal de las especificaciones de Tor, tor-spec.txt
[3]. Hay dos versiones del protocolo. A da de hoy todos los procesos de TOR usan
siempre la versin 2 de la especificacin, 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 Clulas de Tor

Las clulas TOR son de 512 bytes. El formato es el presentado en la Figura
1.1. El campo Command define el tipo y propsito de la clula. Los valores
comunes para Command incluyen:
CREATE
CREATED
RELAY
RELAY_EARLY
DESTROY

Las clulas CREATE son usadas para iniciar una conexin entre dos
procesos Tor. Son enviadas por los proxies onion para crear el primer tramo en
un circuito y tambin por los routers onion para extender el circuito un tramo. Las
clulas CREATED son la respuesta a un CREATE exitoso. Las clulas RELAY y
RELAY_EARLY son empaquetadores que contiene cada mensaje enviado sobre
un circuito establecido. Sern discutidas en detalle en un momento. Las clulas
DESTROY son enviadas a nodos adyacentes para destruir un circuito. El campo
PAYLOAD es la parte de la clula que es cifrada.
Relay Command

Recognized

StreamID

1 byte

2 bytes

2 bytes

Digest
4 bytes

Length
2 bytes

Data
498 bytes

FIGURA 1.2. Formato del Payload de una Clula RELAY

Las clulas RELAY tienen una cabecera relay adicional incluida en su
payload. El formato del payload de una clula RELAY se ilustra en la Figura 1.2.
En el campo Relay command se define el propsito de la clula. Las clulas 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 travs 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
clula tratan con la comunicacin del servidor directorio, DNS lookup, y control de
congestin.
Los campos Recognized y Digest en la cabecera le permiten a un
router determinar si la clula est o no completamente descifrada. Una clula 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 clula 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 mltiples flujos en un circuito. El campo "Length" es el
nmero de bytes del campo "Data" que contienen informacin real. (La
informacin restante es NUL-padded [revisar http://en.wikipedia.org/wiki/
Padding_(cryptography)#Hash_functions Seccin Zero padding]).

Las clulas RELAY_EARLY son un tipo especial de clula RELAY usada

para creacin de circuitos. Los clientes que se comunican con la versin 2 del
protocolo de enlace envan clulas relay de tipo EXTENDED en vez de clulas
RELAY_EARLY. Un OR que recibe ms de 8 clulas RELAY_EARLY cierra el
circuito. Esto limita el tamao mximo 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. Creacin de un Circuito. En la Figura 1.3, presentamos un esquema
para la creacin del circuito. En este diagrama Alice ejecuta un OP y crea el
circuito . (Con las claves simtricas, , y negociadas durante la creacin del
circuito.)

FIGURA 1.3. Flujo de Trabajo de la Creacin de un Circuito

1.3 Servidores de directorios

Tor no es un servidor completamente distribuido. Un pequeo nmero
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
informacin 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 informacin 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 comnmente considerado vulnerable a los ataques de correlacin
extremo-a-extremo. Mientras el cifrado onion realizado por Tor previene una
comparacin directa de contenidos de paquetes, un atacante controlando el primer
y ltimo router tiene acceso a otra informacin, tal como la sincronizacin de
paquetes, y esta informacin es comnmente 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 slo en teora
o en simulaciones, y estas ltimas no necesariamente toman en cuenta todos los
factores introducidos por Tor que pueden afectar un algoritmo de correlacin 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 podra ser capaz de evadir a un atacante slo al enviar pequeas 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 correlacin extremo-a-extremo pasivo funcione. Y segundo, si la
correlacin es factible, buscamos determinar si dichos ataques pueden funcionar
incluso cuando los clientes transfieren slo cantidades pequeas de datos.

El Captulo 2 provee un repaso del trabajo previo relacionado con la

sincronizacin de correlacin y otros ataques relacionados contra Tor. Esta
informacin nos permitir determinar por qu ciertos algoritmos funcionan o
fracasan. El Captulo 4 describe nuestro experimento y resultados por realizar
una correlacin sobre Tor. Incluye descripciones detalladas de dos algoritmos de
correlacin existentes y un nuevo y sencillo algoritmo de correlacin, el diseo
est basado en la informacin que examinamos en el Captulo 3. Finalmente, el
Captulo 5 resume todo nuestro trabajo y sugiere reas potenciales para futura
investigacin.

Captulo 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 captulo es una breve
inspeccin a algunos de esos ataques. Dos de ellos sern estudiados detalladamente

y puestos a prueba en el Captulo 4.

2.1. Correlacin de Flujo

En ataques de correlacin 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 informacin disponible.
2.1.1. Conteo de Paquetes. El conteo de paquetes es una forma sencilla de
la correlacin de flujos. Tal como es propuesto por Back et. al [1], un atacante que
puede observar routers onion cuenta el nmero 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 variacin en el nmero de paquetes entrantes y salientes de
un router en un flujo dado. Como tal, el conteo de paquetes ha sido opacado por
tcnicas ms sofisticadas de correlacin de flujos basadas en la sincronizacin de
paquetes.
2.1.2. Anlisis de Sincronizacin. La sincronizacin 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 sincronizacin de paquetes es usar algn tipo
de funcin de correlacin para intentar correlacionar flujos basados en su retardo
entre-paquetes el tiempo entre la llegada de paquetes adyacentes al flujo. Sin
embargo, este mtodo puede tener problemas con paquetes cados. Levine et al. [6]
propusieron un algoritmo de correlacin usando las series de tiempo construidas
desde la informacin de sincronizacin de packing. Una serie de tiempo es una
manera de mirar los datos de sincronizacin de paquetes. Para crear la serie de
tiempo, establecemos una constante de tiempo W, dividimos el flujo de paquetes
en ventanas de tamao W y contamos cuntos paquetes entran en cada ventana.
La funcin de correlacin es un producto de vector normalizado. Ellos simularon

su algoritmo de correlacin con cuatro tipos de trfico usuario (trfico generado

por el estudio de 1996 de Berkeley HomeIP, trfico aleatorio, trfico constante y
trfico constante con paquetes cados aleatorios) y mostraron que podan realizar
exitosamente correlaciones en una mayora de situaciones con un mnimo de falsos
positivos.
La debilidad de la mayor parte de ataques de sincronizacin es que depende
en que el atacante controle los routers Tor, y requieren que los atacantes controlen
una gran porcin de la red Tor para que sean ampliamente efectivos [6]. Aunque
ha habido mejoras propuestas (tal como la negacin de Barisov et al. del servicio
de ataque por lo cual atacar routers mata los circuitos que no pueden controlar
[2]), tambin hay ataques de sincronizacin que no dependen en el control de
routers individuales Tor. Murdoch y Zieliski [8] propusieron un ataque, donde los
adversarios controlan los Intercambios de Internet y as pueden observar el trfico
que entra y sale de los pases. Mostraron que podan hacer correlacin (usando un
algoritmo derivado de la frmula de Bayes) incluso cuando haban rastreado un
solo paquete de dos mil en un flujo dado.
2.1.3. Correlacin Activa de Sincronizacin. Los ataques de correlacin
activa son un esfuerzo por hacer las correlaciones basadas en el tiempo mucho
ms fciles y efectivas. Funcionan al tener un router atacante alterando la seal
de retraso de un paquete de una conexin 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 sincronizacin 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 sincronizacin en llamadas Skype punto-a-punto al crear e
inyectar una marca de agua nica al flujo. Encontraron que, si los parmetros
correctos fuesen escogidos, podran identificar correctamente 99% de los flujos
con marcas de agua con una tasa de falsos positivos de 0%. Incrementar la tasa de
identificacin al 100% vena con el costo de tan slo 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 conexin a travs de n router tiene un efecto en las
otras conexiones a travs del mismo router. El atacante debe controlar un router
Tor y ser capaz de observar una conexin en algn punto entre la salida del router
Tor y su destino final. Usando el router Tor involucrado, el atacante puede crear
circuitos de tamao-uno en todos los dems routers Tor uno por uno para ver si
esto incrementa la latencia de la conexin 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 aqul 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 dependan del tiempo de idavuelta (Round-Trip Travel Time (RTT)) de los clientes a los servidores. En el
primer ataque, el atacante est en control de dos servidores que estn 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
mtodos (forzar el navegador del usuario a descargar miles de pequeas imgenes
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 nmero de tiempos de ida y vuelta del cliente al
cual estn investigando. Es entonces cuando ellos comparan la frecuencia de
distribuciones del RTTs. Si la frecuencia de distribucin es similar, entonces las
conexiones son probablemente del mismo circuito.

Captulo 3

Mtricas para el Trfico de Tor

Nuestro objetivo final es evaluar la efectividad de la sincronizacin de los
ataques de correlacin extremo-a-extremo en la red Tor desplegada. No obstante,
la mayora de los algoritmos de correlacin de los que hablaremos dependen de
distintos factores para realizar la correlacin, y por lo tanto antes de poner a prueba
los algoritmos de correlacin primero los aislaremos y examinaremos algunos de
estos factores individualmente. Esto nos permitir porque algunos funcionan o
fracasan as como tambin proveer la justificacin para un nuevo algoritmo de
correlacin que presentamos en el Captulo 4. Ya que estamos testeando la
efectividad de estos algoritmos contra un atacante que controle routers Tor, el
atacante tiene acceso a cualquier informacin a la que los routers tengan acceso,
esto significa que el atacante puede usar clulas de datos Tor en vez de los
paquetes de datos TCP.

3.1. Trfico en Tor

Primero examinaremos el efecto que tiene Tor sobre nuestro trfico de
red. Tendremos en cuenta dos factores usados por los algoritmos de correlacin:

la latencia entre la clulas de Tor, y la intensidad general del flujo. En una red
ideal, esperaramos 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 conexin diferentes, as que asumir que Tor es siquiera
similar a una red ideal en estos aspectos supondra un problema.
3.1.1. Arreglo del Test. Nuestra meta es probar si la correlacin 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: slo los routers intermedios cambiarn.
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 trfico que vaya a travs de este router no ser objeto de latencia, pues la
conexin no estar en una red. Y ya que que no habr otro trfico viajando por el
mismo router, no supondr una carga significativa, por lo tanto las condiciones
sern tan ideales como sea posible.
Para nuestro primer grupo experimental, el router intermedio ser un router
pblico 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 trfico Tor, por lo que tiene carga, Este test nos permitir determinar si
la carga de los routers Tor afecta las mtricas.
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 mtricas.
Para cada grupo, realizaremos pruebas con dos tipos de trfico. El primero
es un cliente ping que enva un ping y recibe una respuesta cada 200ms durante 30
segundos. Este tipo ser usado para medir la efecto de Tor en la latencia entreclulas. El segundo tipo de trfico es la descarga de un archivo de 1MiB, que ser
utilizado para verificar si la intensidad promedio del flujo varia.
Nuestra recoleccin de informacin consiste en la obtencin de la marca de
tiempo de cada clula RELAY enviada o recibida por los routers de entrada o
salida. Recolectamos estos datos modificando el cdigo fuente de Tor para usar el

sistema existente de logging de Tor para registrar los datos de la clula Tor en un
archivo.
3.1.2. Resultados. Debido a que los dos tipos de trfico que estamos
estudiando son muy diferentes, usaremos diferentes mtricas para evaluar el efecto
que tuvieron al pasar a travs de Tor. Para el trfico 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 clulas
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 prximo a ello)
en nuestro grupo de control, y que variar en ambos grupos experimentales.
Realizamos rondas de recoleccin de datos con el grupo de control y ambos grupos
experimentales. Las distribuciones de retraso entre-clulas de los tres se presentan
en la Figura 3.1.

FIGURA 3.1. Distribuciones de Retraso del Trfico Ping Entre-Clulas

Para el archivo de descarga, observamos diferentes mtricas: 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 trfico ping llendo a travs 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 ms que los del grupo de control, con una
desviacin estndar de ms 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 desviacin estndar es incluso mayor, y la variacin
est en 5ms en menos del 50% del tiempo. Esto significa que incluso pequeas
cantidades de trfico pueden ser susceptibles a latencias cambiantes cuando viajan
por un circuito Tor, lo cual podra ser un problema para mtodos de correlacin
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 ms grande que el tiempo que tom enviarlos, que el
incremento del tiempo vara y no puede ser predecido, y tambin 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 mtodos de
correlacin que comparan vectores de informacin de sincronizacin directamente
-tal como el mtodo presentado en Levine et al. [6]- podran no funcionar tan bien
en la prctica como lo hacen en la teora, pues los dos flujos tendrn magnitudes
muy diferentes.

3.2. Trfico de Router de Entrada

Ahora tenemos alguna idea de qu le ocurre al trfico cuando viaja por Tor.
La informacin adicional sobre el trfico de Tor tambin es til, pues nos permite
determinar factores que muy probablemente son nicos. Ya que hemos establecido
que el trfico en Tor tiene una latencia y una magnitud promedio no-constante (
y. por lo tanto, que estos pueden ser factores problemticos en los que basar la
mtrica de la correlacin), estudiaremos ahora otros dos factores: el tiempo de
creacin de un circuito, y el nmero total de clulas RELAY Tor en cada flujo
observado.
3.2.1. Arreglo del Test. Para este test, recolectaremos datos desde nuestro
router pblico Tor. Prestaremos atencin a la informacin 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 conclusin 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 clulas sean
registradas. Se requieren 2 clulas para la creacin del circuito cuando se estn
usando circuitos Tor estndar de longitud-3. Se hicieron circuitos con menos de 3
clulas pero nunca fueron usados para enviar o recibir informacin, as que intentar
correlacionarlos no le dara al atacante informacin provechosa.
3.2.2. Resultados. Los resultados estn basados en aproximadamente 800
creaciones de circuitos de entrada y otras 20.000 creaciones recogidas durante
mltiples pruebas. Los resultados para el tiempo de distribucin de la creacin
de nuevos circuitos son presentados en la Figura 3.3. Los resultados para la
distribucin del conteo de clulas inward-bound (inward-bound cells) de circuitos
en nuestro router Tor se ilustran en la Figura 3.4.

FIGURA 3.3. Distribucin del tiempo entre la creacin consecutiva de circuitos en

nuestro router Tor

FIGURA 3.4. Distribucin del conteo de clulas 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 creacin de circuitos tanto de

entrada como de no-entrada, pero los valores son muy diferentes. Sin embargo,
nuestros datos contenan muchas ms 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 proporcin de creacin entre circuitos de entrada y de no-entrada
fue 4 : 100 tambin, as que las distribuciones se ven similares. Esto significa
que la razn de que los valores sean significativamente diferentes es la tasa de
creacin de circuito, nada fundamentalmente distinto sobre los diferentes tipos de
circuitos. Esto tiene sentido, debido a que la creacin de circuito de no-entrada en
nuestro router corresponde a la creacin de circuito de entrada en un router Tor
completamente diferente.
Asimismo, los datos del tiempo de distribucin nos indican que el tiempo
de creacin de un circuito puede tener una buena mtrica 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 distribucin de conteo -presentados en la Figura 3.4- nos
muestran que la mayora de circuitos son cortos: 50 - 60% de los circuitos tienen
100 o menos devueltas al OP. Esto implica que un algoritmo de correlacin
efectivo necesita ser capaz de correlacionar circuitos tanto cortos como largos. En
tanto a la informacin del tiempo de inicio del circuito, la forma de las
distribuciones para los conteos de entrada y no-entrada son muy similares.

Captulo 4

Prueba de Algoritmos de Correlacin

Habiendo establecido los efectos que tiene el trfico de red en Tor,

regresamos a nuestro objetivo original: Poner a prueba mtodos de correlacin de
sincronizacin en un trfico 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 clulas Tor observados en , y que son flujos de clulas 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 correlacin
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 Correlacin
Consideramos dos mtodos existentes de correlacin -escogidos porque
estn bien definidos y trabajan de forma distinta- y un mtodo de correlacin que
desarrollamos. Primero consideramos el mtodo de correlacin de Levine et al. [6],
el cual es un producto de vector normalizado que tiene en cuenta datos de
sincronizacin de todas la clulas Tor observadas, y que fue originalmente puesto
a prueba en una simulacin. Posteriormente consideramos el mtodo propuesto por
Murdoch y Zieliski [8], que funciona sin valorar los datos de sincronizacin de
clulas individuales, y que originalmente fue testeado en datos reales. Finalmente,
proponemos un nuevo y simplificado algoritmo de correlacin que tambin
funciona sin considerar informacin de clulas individuales, y que es
significativamente menos intensivo computacionalmente que cualquiera de los
otros dos mtodos.
4.2.1. Correlacin de Levine et al. El mtodo propuesto por Levine et
al. utiliza datos de sincronizacin de todas las clulas Tor observadas. Mientras
algunos ataques publicados previamente intentaban usar la sincronizacin entre

clulas adyacentes como vectores de correlacin, Levine et al. observaron que ese
mtodo es frgil porque es sensible a paquetes cados. Su mtodo es un producto
de vector normalizado en una serie de tiempo generado a partir de los datos
de sincronizacin observados, en vez de hacerlo directamente en los datos de
sincronizacin.
Para construir una serie de tiempo , escogemos un margen de tamao w,
dividimos el flujo de paquetes z entre mrgenes no-superpuestos de tamao w (Con
padding-cero (Zero-padded) para que la serie de tiempo inicie y termine al mismo
tiempo), y contamos el nmero de paquetes en cada margen. El vector de conteo de
paquetes es la serie de tiempo.
Definen la correlacin-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 anlisis, Levine et al. usaron un retraso de 0 y un margen de
tamao 10 segundos.
Aqu, consideramos dos vectores y . La frmula de correlacin es el
producto de de vector normalizado de estos dos vectores. El producto normalizado
de dos vectores es ms grande cuanto ms 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) estn mucho ms correlacionados. No obstante, el valor del producto
de vectores estndar 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 relacin 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 frmula de la
siguiente manera:

Debido a que el dominio de arccos es (y ya que conocemos que el argumento

es vlido por la desigualdad de Cauchy-Schwarz), conocemos que el argumento
tambin 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 frmula anterior
es el equivalente a la funcin de correlacin, ya que el numerador en la fraction
corresponde a la definicin de producto de vectores, y el denominador es el
producto de las magnitudes, calculadas usando el caso n-dimensional del teorema
de Pitgoras.
Un problema con el mtodo de correlacin 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 correlacin, una
serie de tiempo con el mismo nmero en cada index terminar teniendo ceros,
resultando en una indeterminacin por dividir entre cero. Cuando eso ocurre,
retornamos una correlacin de -1, que significa que en efecto no tenemos en cuenta
ese resultado. Asimismo, slo consideraremos correlaciones con un retraso d de 0,
ya que eso fue lo que Levine et al. descubrieron era efectivo.
4.2.2. Correlacin de Murdoch y Zieliski. El mtodo propuesto por
Murdoch y Zieliski es una derivacin de la frmula de Bayes. Ellos modelan
cada flujo p como un proceso Poisson con un tiempo inicial s, duracin 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
parmetros de p. Ellos pueden entonces derivar la probabilidad de que x y sean del
mismo flujo usando la frmula de Bayes:

Debido a que slo desean probabilidades relativas (ms que absolutas), ignoran
todos los factores independientes de k, lo que les permite derivar la probabilidad
final:

(n) = (n - 1)!, es el nmero total de paquetes en y, , es la magnitud observada de

x , y , es la magnitud total observada de x y y.
La frmula 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 correccin para la tasa, y la tercera parte es
dependiente de la magnitud, lo cual ayuda a asegurar que slo los flujos que
ocurrieron casi al mismo tiempo y que duraron casi lo mismo son considerados.
Este mtodo de correlacin 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 pequeas (cerca de 1 de cada 2000
paquetes para cada flujo) de trfico para un flujo dado. Sin embargo, este mtodo
de correlacin 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 mtodo
de correlacin 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 problemtico 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 clculo de sta correlacin muchas veces tiene un
exponente extremadamente pequeo (usualmente de miles negativos o decenas de
miles). Ya que sta frmula slo calcula probabilidades relativas, podemos tomar
su logaritmo sin perder informacin. Tomamos ventaja de este hecho y usamos una
aproximacin de Stirling para factoriales grandes que puedan acelerar de forma
significativa el clculo de la correlacin.
4.2.2. Correlacin Simplificada. En el captulo 3, cuantificamos los
efectos de Tor en el trfico de red, y descubrimos dos cosas al respecto. Primero,
aprendimos que la latencia de clulas individuales viajando a travs 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 correlacin
que dependan en la sincronizacin de paquetes individuales (como el algoritmo
presentado por Levine et al.), y el segundo de estos factores puede afectar
algoritmos de correlacin que dependan de la sincronizacin general del circuito,
como el presentado por Murdoch y Zieliski.
En un intento por contrarrestar ambos problemas, presentamos y probamos
nuestro propio algoritmo de correlacin. Este algoritmo tiene en cuenta dos
factores: el tiempo inicial del circuito, y el nmero total de clulas Tor enviadas
por el circuito. Para nuestro algoritmo de correlacin, definimos la correlacin c
como

En el captulo 3 observamos que el tiempo inicial del circuito es relativamente

nico, y por eso lo usamos como la primera parte de nuestra correlacin. Nuestra
correlacin. Nuestra correlacin 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 estn en milisegundos, y debido a que, como vimos en
el captulo 3, 20 segundos es muchsimo ms 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 pequea, 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 .
Tambin sabemos que Tor garantiza la entrega de clulas de Tor, as que el
nmero de clulas Tor en x y y debera ser el mismo despus de tomar en cuenta
cualquier clula usada para comunicarse con el router intermedio. (El proceso por
el que se hace esto se explica en la siguiente seccin). Por ende, usamos el conteo
de clulas Tor (el nmero de clulas en el flujo x se denota ). Puesto que este factor
es un porcentaje inverso del total de nmero de clulas enviadas en ambos flujos,
su rango es [0,1].
Cuando se multiplican, los resultados varan en un rango de , Sin embargo,
debido a que los resultados negativos significan que los circuitos tuvieron tiempos
iniciales muy distintos, en realidad slo necesitamos considerar resultados en un

rango de [0,1]. Esto implica que los valores de correlacin positivos son absolutos
en vez de ser relativos, y que pueden ser comparados directamente durante
mltiples tests del algoritmo, en vez de relativamente en una ejecucin dada.
Adems de ser ms simple y usar menos informacin que los otros dos
mtodos previos, nuestro mtodo de correlacin simplificado tambin es
significativamente ms veloz al computar, pues depende nicamente en
operaciones aritmticas bsicas, y opera slo con nmeros que entran en la clase
estndar int, hacindolo una operacin O(1) para realizar una nica correlacin de
dos flujos. A diferencia de la correlacin de Levine et al., que es O(n) en el
nmero de paquetes observados para realizar una sola correlacin porque necesita
calcular un producto de vectores. La correlacin de Murdoch y Zieliski es O(1)
tambin cuando se usa la aproximacin de Stirling, pero sigue siendo
significativamente ms lenta que nuestro mtodo de correlacin en la prctica.
4.3. Organizacin del Test
Controlamos un nico router Tor abierto al pblico, el cual usaremos para
recolectar datos para el test. Nuestro router es estable y un guardia, esto significa
que algunos clientes lo usarn como su router de entrada. Lo usaremos para
recoger informacin 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 clulas RELAY enviadas y recibidas, junto con las direcciones y las
identificaciones (ids) de circuito asociadas a cada clula. Puesto que no deseamos
comprometer el anonimato de las personas utilizando nuestro router Tor,
reemplazaremos cada direccin IP (que es la nica informacin que registramos)
con un string aleatorio nico.
Crearemos flujos con nuestro router pblico como la entrada, un router
intermedio aleatorio, y nuestra salida privada. Realizaremos una correlacin
mucho-a-uno, correlacionando todos los datos observados (llamados anteriormente
) en nuestro router pblico de entrada con cada flujo individual (un dado) en
nuestro router privado de salida.
La correlacin para un flujo dado registrado en nuestro router privado de
salida (y un algoritmo de correlacin dado) ser considerada parcialmente exitosa
cuando el algoritmo de correlacin sea capaz de identificar correctamente el flujo

correspondiente al router de entrada. No obstante, esta informacin slo le es til a

un atacante cuando saben que existe un tal que y provienen del mismo flujo, y
as la correlacin slo ser considerada totalmente exitosa cuando el valor
incorrecto ms elevado de correlacin sea menor que todos los valores correctos de
correlacin (para todo ) en una ejecucin dada. Si el algoritmo es completamente
exitoso de manera consistente entonces el atacante puede establecer una marca
para la correlacin, lo que les permite determinar si existe o no un que provino del
mismo flujo que , adems de determinar qu flujo es.
Realizaremos tests con tres tipos de trfico. Los primeros dos son el archivo
de descarga de 1MiB y cliente ping discutidos en el captulo 3, y el tercero es un
archivo de descarga de 10KiB, que nos permite testear si la correlacin puede ser
hecha de forma exitosa en flujos muy pequeos.
4.4. Resultados

FIGURA 4.1. Resultados de correlacin slo con circuitos de entrada

Los resultados de los test de algoritmos de correlacin en 3 tipos de trfico
se presentan en la Figura 4.1 y la Figura 4.2. Aunque un atacante en realidad
correlacionara flujos que estn en el primer router del circuito, mostramos en el
Captulo 3 que los flujos de no-entrada no son esencialmente diferentes, as que
presentamos los resultados combinados tambin para que podamos observar el
desempeo de los algoritmos cuando se correlaciona un nmero mucho mayor de
circuitos al mismo tiempo.

FIGURA 4.2. Resultados de correlacin de todos los circuitos

4.4.1. Resultados de la Correlacin de Levine et al. Como podemos
observar la correlacin de Levine et al. slo es efectiva para trfico ping y las
variaciones de margen de tiempo no son suficiente para hacerlo competitivo
frente a los otro dos algoritmos de correlacin para otros tipos de trfico. Es
muy probable que sea porque la correlacin de Levine et al. depende en la
sincronizacin de paquetes individuales, y, como ilustramos en el captulo 3, la
latencia del trfico en Tor es altamente variable, incluso dentro del flujo de un
paquete dado.
4.4.2. Resultados de la Correlacin de Murdoch y Zieliski. 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 habra tenido que
correlacionar flujos correctamente casi todo el tiempo mientras el atacante posea
informacin 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 necesitara 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 pequeo nmero 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 diseado
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 conexin entre pases. Dicho atacante sera
capaz de observar cantidades de trfico mayores a la vez que aquellos controlando
un pequeo nmero de routers Tor.
4.4.3. Resultados de la Correlacin Simplificada. Nuestro algoritmo
presenta el mejor desempeo. Tiene una tasa casi perfecta de xito parcial para
todos los tipos de trfico, esto significa que si un atacante es capaz de observar
tanto el flujo de entrada como de salida, muy probablemente podr realizar la
correlacin. As mismo, presenta una alta tasa de xito total, por lo tanto un
atacante usando el algoritmo simplificado ser capaz de identificar la mayora
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 correlacin absoluto que puede ser comparado de manera significativa entre
flujos. Esto hace de nuestro algoritmo simplificado la mejor opcin para el modelo
de ataque especificado, pues le permite a los atacantes que controlen un pequeo
nmero de routers algn grado de proteccin contra falsos positivos. Adems los
resultados de nuestro algoritmo simplificado son consistentes entre los tres tipos
de trfico que pusimos a prueba, indicando que la correlacin de sincronizacin
puede ser realizada en Tor incluso en casos donde hay tan poca informacin siendo
enviada por un circuito. Los usuarios no pueden evadir atacantes que usen el
algoritmo simplificado de correlacin enviando menos trfico.
4.4.4. Aplicacin de los Resultados. Un problema con nuestros resultados
es que estn basados en un nico router pblico. Nuestros resultados no
necesariamente se generalizan a atacantes ejecutando muchos routers, porque
estarn observando significativamente mayor trfico. Nuestro algoritmo
simplificado depende de dos factores -el tiempo inicial de flujo y el nmero de
clulas del flujo- que son relativamente nicos para la cantidad de datos que
fuimos capaces de poner a prueba. Estos dos factores dejarn de ser tan nicos
cuanta mayor informacin tengamos, y por lo tanto suponemos que nuestro mtodo
de correlacin simplificado no se desempear tan bien.
Consideremos nuestro arreglo del test con un nico router Tor. Basados en
el nmero de circuitos creados a travs de nuestro router en un perodo 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 nmero de circuitos en todo Tor en este

tiempo: . (Dividimos entre 3 porque los circuitos Tor estndar tienen 3 routers
de longitud, indicando que la creacin 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 tendra 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 informacin adicional para tener esto en cuenta. Ms importante
an, tanto el router de entrada como el router de salida conocen la identidad del
router intermedio para cualquier trfico que enven o reciban. Esto implica que el
atacante slo requiere intentar correlacionar trficos de flujo que tengan el mismo
router intermedio, lo cual reduce drsticamente el nmero de flujos que necesitan
ser correlacionados. Incluso si excluimos los routers de salida completamente (y el
mecanismo de seleccin de ruta de Tor no lo hace), bien hay ms 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 significara que
tendramos que ser capaces de reducir el nmero 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 sern usados con
mayor frecuencia que otros pues la seleccin de ruta de Tor se basa en el ancho
de banda (junto con otros factores), an habr una reduccin significativa en el
nmero 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 correlacin anteriormente mencionados toman en cuenta
nicamente flujos que viajan en la misma direccin, y el par (conteo de clulas
inward, conteo de clulas outward) ser ms distintivo que el conteo de clulas
viajando en una direccin, que tambin ayudar a contrarrestar el incremento en la
cantidad de informacin.
Por lo tanto, es improbable que un atacante controlando cientos o incluso
miles de routers necesite correlacionar un nmero 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 correlacin de

nuestros datos permanecern as para realizar la correlacin cuando un atacante

controle ms routers.

Captulo 5

Conclusin
En este trabajo, nuestra meta fue determinar si era factible o no realizar
ataque de correlacin pasivos en Tor, tambin si era posible para los usuarios
evadir atacantes que usen dichos ataques al enviar nicamente pequeas cantidades
de datos.
Para ese fin, probamos dos algoritmos de correlacin y descubrimos que
ambos tienen debilidades. La correlacin del producto de punto propuesto por
Levine et al. es consistentemente exitosa en slo uno de los tres tipos de trfico que
pusimos a prueba, y la correlacin Bayesiana propuesta por Murdoch y Zieliski
no tiene una manera confiable de evadir falsos positivos a menos que el atacante
controle toda o casi toda la red. Asimismo diseamos y probamos un nuevo y

simple algoritmo de correlacin, que puede correlacionar confiablemente los tres

tipos de trfico, y el cual puede ser mucho ms eficiente computacionalmente
que cualquiera de los otros dos mtodos. Aunque nuestros resultados slo estn
basados en los datos recolectados por un nico router, tambin explicamos como
nuestro algoritmo puede escalar a atacantes controlando muchos ms routers.
Con nuestro nuevo y simple algoritmo de correlacin, somos capaces de
responder ambas de nuestras preguntas originales con un S. Es posible y factible
realizar ataques de correlacin pasivos en Tor usando nuestro algoritmo, y nuestro
algoritmo es capaz de realizar la correlacin incluso cuando pequeas cantidades
de informacin estn 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 informacin mucho
ms precisa y les permite trabajar con clulas Tor en vez de paquetes TCP. Esto
es un problema porque un atacante necesitara controlar muchos routers para
poder comprometer una cantidad significativa de trfico en Tor. Un rea de
futura investigacin sera en la que se observe si esta limitacin puede superarse:
Observar todo el trfico TCP entrando y saliendo de un router es tan poderoso
como controlar el router directamente? Si lo es, esto le permitira a un ISP
comprometer efectivamente cualquiera de los routers Tor a los que le provee el
servicio de internet, lo cual, en cambio, posibilitara a un gobierno la habilidad de
comprometer exitosamente todos los routers dentro de las fronteras del pas.

Bibliografa
[1] Adam Back, Ulf Mller, 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), pginas 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, pginas 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), pginas 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,
pginas 183-195. IEEE CS, Mayo 2005.
[8] Steven J. Murdoch y Piotr Zieliski. 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), pginas 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, pginas 161174. 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, pginas 81-91,
Noviembre 2005.