Traducción de la tesis de Sam DeFabbia-Kane en el año 2011. 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

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.