Según esta noticia, publicada por El País, la U.E. se dispone a legalizar la supresión del derecho al secreto de las comunicaciones.

“La comisión de mercado interior del Parlamento Europeo debatió ayer el llamado paquete de telecomunicaciones, la propuesta de directiva que debería estar vigente a partir de 2012, cuando el apagón analógico será una realidad en la UE. El texto es muy complejo, modifica cinco directivas y será votado en sesión plenaria el próximo otoño con las tres enmiendas más polémicas que los grupos de defensa de los derechos digitales denunciaron.

De este modo, se autorizará a acceder a los datos personales de los usuarios por motivos de seguridad sin su consentimiento; se autorizará la venta de software que incluya programas espías destinado a interceptar los intercambios de archivos, impedir la copia de material protegido, "controlar al usuario" e "interceptar sus comunicaciones", explicó Cristophe Espern, de la Fundación por una Infraestructura de Información Libre (FFII). Ambas enmiendas, sin embargo, deberán ser revisadas mediante el informe de la Comisión de Libertades Civiles antes de su primera lectura en sesión plenaria, el próximo septiembre.

Además, ayer se "autorizó" a los estados a que instauren en sus países el plan Sarkozy para frenar la distribución de contenidos en Internet. Un modelo que corta el acceso a Internet a aquellos usuarios franceses que después de tres advertencias continúen descargándose contenidos con derechos de autor a través de las redes p2p (intercambio de archivos). En este caso no impone, se autoriza.

Más allá de la polémica, la directiva pretende ordenar un espectro radioeléctrico común. Se trata de "un bien público escaso y muy solicitado", aseguró el eurodiputado de CiU Ignasi Guardans. El espectro se regula por frecuencias, que a su vez deberán repartirse entre televisión, radio, telefonía, Internet y servicios de valor añadido, como la información del tráfico en el coche o los servicios de emergencia y seguridad”.

 

La expresión alemana, Nacht und Nebel (noche y niebla) Se refiere a un siniestro decreto según el cual los presos de la Gestapo y de las SS desaparecían en la noche y en la niebla para no volver a aparecer jamás. Sin embargo, la noche y la niebla también protegían a los partisanos que minaron una novísima forma de tiranía incompatible con la vida de la especie humana. La noche y la niebla pueden ocultar el mal en estado destilado o el bien en su última manifestación posible: la del emboscado, pero ocultar no es lo mismo que invisibilidad.

Recopilando lo visto hasta el momento, estamos en condiciones de utilizar cifrado fuerte con claves asimétricas en el envío de correo y en el almacenamiento de archivos. Podemos utilizar Tor, un sistema de onion routing para navegar por la Red sin revelar nuestra dirección IP y, por tanto, nuestro origen y nuestro destino y, también, podemos utilizar los protocolos Mixmaster II para reenvío de correo con cifrado fuerte y de origen no rastreable.

Falta por dedicar una entrada a los remailers de tipo III, es decir, a Mixminion y a algún otro sistema de anonimato válidos para dispositivos portátiles, como llaves USB y DVDs. Pero, antes de eso, es necesario sembrar algunas dudas sobre la seguridad real de la Red Tor, porque ya son numerosos los ataques descritos y de los que hay documentación.

Aquí tenemos el propósito declarado de poner a disposición de personas normales las herramientas que les permitan proteger un derecho fundamental de carácter constitucional y de protegerlo de la manera más efectiva posible. Por eso sería irresponsable afirmar que cualquiera de estas herramientas proporcionan una seguridad completa.

Ataques más conocidos contra Tor

Bloqueo de Tor

La medida hostil más sencilla contra el tráfico a través de Tor, posiblemente, sea bloquear los nodos de salida de la Red. Tor necesita mantener un directorio de servidores que puede ser interrogado fácilmente por cualquier programa y, luego, usar esa información para bloquear el tráfico.

Es muy posible que, desde hace un tiempo, los usuarios de Tor se hayan encontrado con un extraño mensaje proveniente de Google avisándoles de que la conexión se se ha podido establecer porque un programa espía o un virus proveniente de su ordenador ha sido detectado. La treta es ingenua y se puede burlar usando el menú de Vidalia para adquirir una “nueva identidad”, es decir, una nueva ruta a través de Tor y, por supuesto, una nueva IP. Con uno o dos cambios de esta “identidad” se puede eludir, sin mayores problemas, el bloqueo de Google.

Por otro lado, estas medidas de bloqueo son poco peligrosas. De hecho la inestabilidad de las rutas a través de Tor, que cambian continuamente, de momento, es suficiente para eludirlas. Además, no representan un peligro real para el anonimato de los navegantes. Lo que veremos a continuación, ya es otra cosa más comprometida.

 

Descubrimiento de la IP real.

Correlación entre uso de tor y producción de cierto acontecimiento.

Parece que la forma más elemental de descubrir la IP de alguien consiste en rastrear quién está usando Tor cuando se produce un determinado evento: un ataque a cierta dirección, la modificación de un blog, etc. y después comprobar si cierta dirección IP cliente de Tor estaba constantemente en línea cuando se produjo el evento. En cualquier caso, esto sólo sería una forma efectiva de desvelar la IP si la máquina a descubrir estaba funcionando como cliente de Tor en ese momento. Además, su eficacia se reduce considerablemente a medida que aumenta el número de usuarios de Tor. Desgraciadamente, hay otras formas más eficaces.

 

Inclusión de códigos activos en la máquina espiada.

Una forma mucho más efectiva es tomar el control de la máquina que pretende estar enmascarada mediante Tor. Esto no representa ninguna dificultad incluyendo los llamados Java “connect-back applet” o “Flash applets” en la página. La página visitada puede descargar estos códigos ejecutables, (o las aparentemente inofensivas Cookies) Que proporcionarán el control suficiente de nuestra máquina, no sólo para que la página visitada conozca la IP real, sino también la MAC de la tarjeta gráfica, los números de serie de la placa base, del disco duro... Los controles ActivX del Explorer de Windows son igual, si es que no más peligrosos. Conclusión: No existe navegación segura con cookies, java o javascript activados en el navegador y tampoco existe posibilidad de navegación segura usando Internet Explorer de Windows.

Esto es un problema, no sólo porque impide la visión de vídeos u otras características de la página visitada, sino y sobre todo, porque no parece posible ingresar en ningún servicio de correo o de publicación de blogs, sin tener cookies, java o javascript activado y si esto es así, y lo es, Tor no ofrece ninguna protección cuando se trata de publicar textos o documentos. Cada vez que, por ejemplo, se ingrese en Blogger de Google para publicar una entrada o para subir una imagen o para comprobar el estado de nuestro blog, Google recopilará una cantidad asombrosa de datos que nos identificarán sin lugar a dudas o, mejor dicho, que identificarán a nuestra máquina y señalarán el lugar exacto desde el que se estableció la conexión. Quien necesite una prueba, sólo tiene que activar el servicio google analytics en su blog y luego repasar los datos de los visitantes que este servicio le proporciona.

 

Pistas indirectas. Identificación de características de la máquina a desvelar.

Otro dato significativo para la identificación real de la IP es identificar el buscador y el sistema operativo que se está usando durante la conexión. Es muy probable que este dato no sea accesible directamente, pero hay medios para llegar hasta él. Por ejemplo, viendo las diferencias entre Firefox e Internet Explorer en la forma en que estos dos navegadores utilizan las suites de cifrado cuando visitan una página vía SSL.

La diferencia en los protocolos de cifrado sirve para identificar el navegador aunque no se pueda conocer el contenido real de la comunicación o se utilice un proxy para consiguir aparentar que se está utilizando un “User-Agent” distinto al real.

La extensión “User-Agent Swicher” para el navegador Firefox puede paliar este problema pero parece ser que no siempre resulta completamente efectiva. Por ejemplo, esta página, descubre la trampa y este es el dato que nos devuelve cuando la visitamos usando Firefox tratando de hacerle pasar por Internet Explorer: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1). Por el contrario, aquí, Firefox pasa perfectamente como IE y, además, confunde a la página espía haciéndola creer que estamos utilizando Windows XP en lugar de Linux.

Telnet o Netcat también pueden revelar datos. Tanto Telnet como Netcat, cuando se estén usando para escuchar puertos, expondrán cierta información relativa a la máquina cliente, como el número de versión utilizado, la capacidad de la conexión o el tamaño de la ventana lo que puede servir para el tipo de máquina desde la que se está usando Telnet. Esto no es mucho, aparentemente, pero unido a los datos proporcionados por otros ataques pueden, muy bien, ser decisivos para establecer con certeza quién es el espiado.

El cliente SSH que se esté usando también puede identificarse sin problemas y, a partir de ahí, deducirse datos identificativos sobre la plataforma y la información conexa a ésta.

 

Marcas en el tráfico de Tor.

Más efectivo y, por tanto más peligroso que lo dicho hasta aquí, es el etiquetado del tráfico de Tor. Esto es posible porque Tor no proporciona ninguna protección en las conexiones de extremo a extremo. Así, si el fisgón puede monitorizar el tráfico de datos que sale de una computadora y, también, el tráfico que llega a una página de destino (por ejemplo, un blog) A la que mantiene bajo vigilancia, no tardará mucho en establecer una correlación entre una y otra máquina con un simple análisis estadístico.

La situación aún se simplifica mucho más para los husmeadores si “etiquetan” el tráfico que sale de cierta máquina. Luego sólo tendrán que buscar esa “etiqueta” en los nodos de salida de Tor y ver a dónde van esos datos.

No se trata de otra cosa sino de incluir un “patrón” reconocible en la comunicación, de tal manera que, aún con el tráfico cifrado y sin que éste se pueda ver en claro, el hecho de que un cierto número de paquetes llegue en un cierto tiempo, seguido de un también cierta pausa de milisegundos, por ejemplo, será suficiente para establecer la correlación entre el origen de la comunicación y la página de destino.

¿Estamos perdidos? No del todo. Contra esto aún se pueden tomar algunas “contramedidas”: a) Configurar el cortafuegos de la máquina en la que está funcionando el cliente Tor, de modo que sólo se permita el tráfico de la propia red Tor. b) Hacer funcionar Tor a través de otra infraestructura de red comprometida como un router propietario o una red wireless. c) Utilizar un script, un pequeño programa, que reclame páginas aleatoriamente a través de Tor o que mantenga abierta una conexión con algún sitio remoto y le envíe datos regularmente.

Ninguna de estas contramedidas parecen lo suficientemente simples como para que puedan ser usadas por personas sin conocimientos técnicos, aunque estos tengan que ser mínimos. Quizás, lo más fácil sea establecer las conexiones seguras a través de otra máquina, es decir, utilizar las posibilidades de las redes Wifi abiertas, pero sin olvidar que eso no soluciona el problema de Java, Javascript, aplets o cookies, todos ellos códigos activos que la página visitada introduce en la nuestra y, a través de la cual, se pueden identificar componentes únicos de ésta, tales como la dirección MAC u otros datos de fábrica de los componentes.

Con esto, el atacante no podrá identificar un lugar comprometido, ni el nombre de la persona que contrató la conexión a la Red, pero si, por otros medios, llega a tener sospechas de estos datos, le cabe (según las circunstancias, claro) Actuar legalmente contra el atacado, por ejemplo, mediante una denuncia por daños al honor. A partir de ahí, es muy probable que el juez que instruya el procedimiento ordene un registro domiciliario, que la máquina perseguida caiga en poder de la policía forense y que ésta, con los datos aportados en la denuncia o con los que solicite a la compañía en la que está alojado el blog perseguido, establezca una relación indubitada entre dicho blog y el propietario del ordenador intervenido...

Hay más ataques descritos contra el anonimato de Tor. En otra entrada nos referiremos a dos trabajos que andan circulando por la Red: “Practical Traffic Analysis: Extending an Resisting Statistical Disclosure” de Nick Mathewson y Roger Dingledine, y “Low-Cost Traffic Analysis or Tor”, escrito por Steven J. Murdoc y George Danezis del Laboratorio de computación de Cambridge.

 

Vamos a copiar aquí una noticia aparecida en Kriptópolis que, de confirmarse, supondría un gravísimo ataque contra los algoritmos de cifrado fuerte actualmente en uso. Como no somos técnicos en esta materia, poco es lo que podemos decir sobre la ingeniería que fundamenta este ataque, pero lo que sí se puede deducir es algo que el sentido común venía advirtiendo ya a los usuarios comunes: cualquiera que sea el sistema de cifrado, si la máquina en la que éste se realiza acaba bajo el control de un atacante, la clave caerá.

Hasta ahora el problema era sencillo de atajar. Las claves PGP o Gnupg tienen un punto intrínsecamente frágil. La contraseña o "frase de paso", por muy larga y aleatoria que sea, siempre será vulnerable a una ataque de fuerza bruta y si la contraseña cae y, además, la clave está presente, la clave también caera.

Es decir, teniendo en cuenta que "clave" y contraseña no son la misma cosa; que la clave es la que se genera mediante la aplicación del algoritmo de cifrado y la contraseña sólamente es una palabra, frase o serie aleatoria de números y letras que debe proporcionarse al programa de cifrado para que ponga en funcionamiento la "clave" y, con ella, se cifre el mensaje, la contraseña siempre será vulnerable porque su complejidad nunca podrá ser tanta que impida su uso habitual en la máquina.

De esto se deducía que es muy mala idea tener guardadas las claves de cifrado en el disco duro de un ordenador al que un atacante pudiera llegar a tener acceso. El problema era fácil de solucionar, puesto que dichas claves siempre se podían almacenar en un CD o en una llave USB y, a la vez, tratar de mantener el ordenador limpio de programas espías que, por ejemplo, fueran capaces de enviar al atacante, el registro de las teclas que se han estado pulsando.

La situación, según parece deducirse del texto adjunto, viene a dar una vuelta más a este eslabón débil de la cadena de cifrado. El nuevo ataque necesita, también, tener acceso a la máquina en la que están almacenadas o se están usando las claves a romper, pero la novedad es la facilidad y rapidez con la que obtener la totalidad o la práctica totalidad de la clave atacada y sin ninguna necesidad de descubrir, por el método de ensayo y error, la contraseña.

La conslusión viene a ser la misma. Si un atacante consigue acceder al ordenador en el que se almacenan o están funcionado las claves de cifrado, la seguridad de los mensajes se esfuma. En fin, he aquí la noticia y el comentario que hace de ella Fernando Acero:

 

Nuevo ataque contra RSA: la vulnerabilidad está en el chip

Por admin

Creado 18/11/2006 - 11:37pm

Yahoo! ha levantado [1] hoy la liebre en la Red, pero tanto ese medio como el artículo original [2] en Le Monde, hacen referencia a un misterioso trabajo "aún confidencial".

Sin embargo, Kriptópolis ha podido encontrar on-line una versión preliminar [3] del que parece ser el artículo que ambos mencionan, pendiente tan sólo de revisión editorial.

El artículo en cuestión explica un nuevo ataque contra RSA, que profundiza en una vía recientemente abierta -denominada BPA (Branch Prediction Analysis)- y que aprovecha una peculiaridad del diseño de los microprocesadores actuales...

En muy pocas palabras, los autores del trabajo afirman que los procesadores actuales han tomado un atajo de diseño (el módulo de predicción) en aras de favorecer la velocidad de las operaciones, lo que perjudica seriamente la seguridad de ciertas operaciones.

De hecho, debido a esa debilidad, y mediante un simple software que espiara determinadas operaciones de la CPU, sería posible romper con suma facilidad las claves RSA en las que descansa hoy en día la seguridad del comercio electrónico mundial.

A modo de ejemplo, los autores afirman haber hallado al primer intento una clave de 512 bit utilizada en OpenSSL, en sólo varias milésimas de segundo.

Según Le Monde, fuentes de la máxima solvencia confirman la realidad de la amenaza. Afirman que la solución radical pasaría por rediseñar los microprocesadores, pero que un posible atajo sería que las implementaciones dejaran de utilizar el módulo de predicción del procesador, aunque tal medida podría convertir en cuatro veces más lentas las operaciones criptográficas en línea.

Al parecer, el trabajo será presentado públicamente en febrero de 2007, durante la Conferencia RSA 2007 [4], a celebrar este año en San Francisco (EE.UU.).

 

Veamos algunas cosas... que no es así.

Enviado por Fernando Acero el 20. Noviembre 2006 - 22:03.

He estado leyendo con más detenimiento los documentos de este artículo y el que envié yo y la cosa puede tener más miga de la que parece.

Los hechos parece que son los siguientes:

a) Están afectados todos los sistemas superescalares con predicción, con independencia de que se implementen mediante software o hardware. Las smartcards con sistemas operativos WCET (Worst Case Execution Analysis) también están afectadas ¿cuáles son?, habrá que verlo, pero con el esfuerzo dedicado a optimizarlas, casi podemos decir que todas.

b) No es necesario tener acceso físico al sistema, un troyano puede hacer el trabajo. No es necesario que el programa "espia" corra con privilegios especiales y basta con que se esté ejecutando antes que el algoritmo de cifrado. Lo único que puede cambiar algo del código del espía con cada modelo o velocidad de procesador, pero ese es un problema fácilmente salvable ya que los procesadores son habas contadas.

c) Todos los sistemas de seguridad ideados para proteger sistemas, tales como los que comenta Shevek en su post, son completamente inútiles ante este ataque. Por ejemplo, las smartcards con protección contra ataques side-chanel (usados con mucho éxito en los ataques a las plataformas de tv digital) también están afectadas, así como los sistemas que usan randomizadores, inversores, equilibradores de rama, o sistemas similares de protección también están afectados, con independencia de que su implementación sea por software o hardware.

d) Este sistema usa un proceso paralelo "espia" que interactua con el proceso "seguro" en los elementos comunes de la arquitectura.

A diferencia de los sistemas estadísticos o diferenciales, este sistema solamente necesita una pasada para lograr el 90% o más de la clave.

El ataque es relativamente simple, el programa "espia" ejecuta un determinado número de ramas y mide el tiempo de ejecución medio de cada rama en esa única ejecución.

Simplemente, ejecutando las ramas del programa "espía" y midiendo el tiempo total de ejecución de las mismas. Por lo tanto, el proceso "espía" puede conocer la traza completa de predicción del programa objetivo en las pilas y con ello, ser capaz de obtener la clave secreta, si no completa, en un porcentaje muy alto.

Para simplificar, podemos decir que el programa "espía" afecta al funcionamiento del programa "seguro" a través de las áreas comunes de la arquitectura del procesador y mediante la medición del tiempo de ejecución o metadatos de control, obtiene la información de la clave de forma bastante precisa.

Por lo tanto, como hemos dicho, los esquemas de protección usados hasta el momento, son completamente inútiles, como se comenta en el artículo, ante este novedoso ataque.

e) Las operaciones "sensibles" son las reducción modular y la inversión modular, aunque operaciones como la multiplicación o potenciación también pueden servir para detectar la clave.

Lo que implica que no solamente está afectado el algoritmo RSA, están afectados prácticamente todos los algoritmos de cifrado.

Sigo leyendo e intentando asimilar ya que el documento para mi gusto no es muy completo y deja algunas lagunas, pero revisando la bibliografía que le acompaña, se pueden sacar conclusiones más que interesantes, pero eso requiere algo más de tiempo.

De verdad, recomiendo la atenta lectura de los dos artículos ya que son muy interesantes y entre todos, podemos sacar algunas conclusiones interesantes.

Si se manifiesta que esta vulnerabilidad es explotable de forma práctica, las soluciones son pocas, complicadas y posiblemente caras.

"Copyleft 2006 Fernando Acero Martí­n. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".

---

URL original
http://www.kriptopolis.org/nuevo-ataque-contra-rsa

 

Otra forma sencilla de utilizar Mixmaster y Gnupg sin necisidad de ningún conocimiento específico, es el uso del servidor de correo Mutt. Se trata de una aplicación sumamente versátil aunque de apariencia “primitiva” para quien esté acostumbrado a los entornos gráficos.

Su instalación resulta elemental en Ubuntu (y es de suponer que en cualquier otra distribución, también) Teniendo en cuenta que todas las aplicaciones necesarias están disponibles en los repositorios y dicha instalación se realiza automáticamente desde el gestor de paquetes Synaptic:

 

Mutt.

Sendmail o, mejor Postfix.

Echolot, el pinger para mantener actualizada la lista de remailers de Mixmaster.

Mixmaster.

Vim, el editor de texto que ya se vio en la entrada dedicada al uso de Mixmaster en Linus.

Pues bien, buscados e instalados todos estos paquetes con Synaptic, Mutt estará en condiciones de funcionar sin hacer ninguna otra modificación, en Ubuntu al menos.

El programa se abre desde la consola tecleando su nombre en la línea de comando. A continuación nos aparecerá la siguiente ventana:

Para comenzar a enviar un correo, en esta pantalla y sin hacer nada más, se pulsa la tecla "m". A continuación, en la línea inferior de la ventana nos aparecerá la posibilidad de teclear la dirección de correo del destinatario, primero, y el asunto del mensaje, después.

Tanto en el caso de la dirección de correo, como en el del "asunto", cuando se haya terminado, habrá que pulsar "intro" para pasar a la siguiente opción o a la siguiente pantalla que será, precisamente, la del editor de texto Vim:

Cuando se haya terminado de redactar el mensaje, se saldrá de Vin, como ya se ha visto, pulsando por este orden: Tecla "Insert"; "Alt-w"; "Mayúsculas - q" y, finalmente, escribiendo "exit" en la línea de comando que aparece al final de la ventana.

La pantalla que aparece a continuación vuelve a ser la de Mutt pero, ahora, en ella veremos la dirección del destinatario y el asunto, así como una referencia al mensaje escrito. Es el momento de fijar las indicaciones de reenvío a través de Mixmaster. Para ello pulsaremos la tecla "M", poniendo atención en que sea la letra mayúscula. Aparece la siguiente pantalla:

Como vemos, aparece la lista de remailers disponible. Para elegir aquellos con los que se quiera construir la cadena de reenvío, basta pulsar, sucesivamente, los números correspondientes a cada uno de los remailers elegidos. En el caso de que se quiera formar una cadena aleatoria, se pulsará, tantas veces como remailers se quieran utilizar, la tecla "i". Cuando se considere que la cadena está formada, se pulsará "intro" y el programa abrirá esta pantalla:

En esta ventana, en la última línea, vemos que aparece el texto "PGP" con distintas opciones. Para que esto ocurra, antes se ha tenido que pulsar la tecla "p". Bien, aparecidas las opciones pgp, pulsando la tecla "e" se abrirá la ventana en la que se nos mostrará la clave asociada por Gnupg a la cuenta de correo del destinatario y, si no es así, el programa nos dará la opción de teclear el "identificador de la clave que se quiera usar para cifrar el mensaje. Este identificador se puede ver usando la opción "OpenPGP" de Thunderbird y su gestor de claves, o abriendo "Kgpg", una aplicación sencillísima de gestión de claves que también está disponible a través de Synaptic. En el caso del ejemplo, el identificador de clave es: 3F109BCT:

Hecho esto y pulsada la tecla "intro", aparecerá la siguiente pantalla con el identificador del mensaje y la clave asociada. Es el momento de enviar el correo. Eso se hará pulsando la tecla "y". Aquí, es posible que Mutt nos advierta que la clave usada es de duración indefinida y que nos pregunte si, aún así, queremos utilizarla. Pulsaremos la tecla "s" para decirle que sí y el mensaje se enviará.

Como en el caso de Mixmaster, en unas horas o en uno o dos días, si todo ha ido bien y nuestro correo no ha quedado atascado en algún remailer fuera de servicio, el destinatario lo recibirá cifrado con su clave pública. 

 

Hasta aquí, hemos visto el sentido y uso de los sistemas de envío anónimo y cifrado de correos electrónicos basados en remailers de tipo II y en claves asimétricas. Los remailers de tipo III vienen a ser lo mismo, sólo que, como veremos, incluyen sistemas que hacen posible responder a los mensajes recibidos.

Ahora hay que reflexionar sobre la seguridad real que ofrecen estos sistemas, dando por hecho que algo que esté por debajo de este nivel, es decir, algo que no incluya cifrado con clave asimétrica no menor de 4.096 bits (no hay ninguna razón, salvo que se tenga un ordenador desesperadamente obsoleto, para elegir un tamaño menor) Y el protocolo Mixmaster, no debe ni siquiera plantearse.

Las medidas de seguridad vistas: reenvío a través de cadenas cifradas de remailers, fragmentación de mensajes en partes iguales, tiempos de latencia, medidas antispan, etc. pueden impedir o dificultar los ataques basados en análisis de tráfico, pero tienen una evidente brecha en sus murallas. Nada impide que organismos oficiales u oficiosos o decididamente delictivos organicen y pongan en funcionamiento sus propios remailers, controlando así, todo el tráfico que pase a través de ellos.

La fragmentación del mensaje y el envío de estas partes por separado, a través de distintas cadenas de remailers, es una buena defensa contra este ataque pero siempre y cuando tengamos la certeza de que los servidores comprometidos son pocos. Así, con cadenas de diez o doce remailers, la posibilidad de que la totalidad del mensaje se vea interceptada, puede reducirse razonablemente, aunque, también, aumenta y mucho, la posibilidad de que el mensaje quede bloqueado en algún punto y jamás llegue a su destino.

Sin embargo, la situación se vuelve mucho más siniestra si empezamos a pensar que son la mayoría de los servidores activos los que podrían estar controlados por organismos u organizaciones de interceptación. Si además, se considera la posibilidad de que, mediante ataques de denegación de servicio u otras técnicas en modo alguno sofisticadas, el tráfico pueda ser “dirigido” hacia las cadenas comprometidas, haciendo que los remailers no controlados queden fuera de servicio; la cosa se pone realmente negra.

¿Es esto, precisamente, lo que está ocurriendo? Como ya se señala en el artículo publicado en SET nº 34, el estado de la tecnología en materia de cifrado y correo anónimo no ha evolucionado en los últimos diez años, al menos de manera sensible y eso, ya, es una debilidad a tener muy en cuenta.

Por otro lado, es notable el descuido de los Legisladores sobre la materia. Mientras empieza a ser universal la obligación legal que se impone a los proveedores de servicios de conocer y archivar un número indeterminado, pero creciente, de datos de tráfico y de identificación personal, y de mantener esos datos a disposición de la “autoridad competente”, no tanto judicial, como administrativa o gubernamental; cosa tan fácil como ilegalizar los servicios de los remailers, parece ser algo que no se les ha ocurrido ni a gobernantes, ni a jueces, ni a espías... ¿No es sospechoso?.

Y ya metidos en esta harina de “inteligencia” y “contrainteligencia” ¿por qué no pensar que la difusión de noticias sobre la infiltración de los servidores de correo anónimo, es pura intoxicación, un modo más de ataque que empuje a desistir de su uso?

“Die Rotte Kapelle” no tiene respuesta para esto y menos después de leer la noticia que publica Jacob Appelbaum en “Debian Administration” y cuyo texto original junto con una traducción, más o menos lamentable, de su contenido principal, incluimos a continuación:

“Asistí la última semana al simposio “Información. Políticas e Infraestructura Internacional” en la Escuela de Derecho de Harvard, organizado por la Comisión Global de Infraestructura de la Información, la Escuela Kenedy y el Instituto de Tecnología de la Información de Leyes y Políticas de la Escuela de Derecho de Harvard.

Durante la presentación de Paul Strassmann, de la Universidad Nacional de la Defensa, y de William Marlow, de la Comisión Internacional de Aplicaciones Científicas; titulada “ Anonymous Remailers as Risk-Free International Infoterrorists”; se plantearon preguntas por parte de la audiencia en un extenso debate. El profesor Charles Nesson, de la Escuela de Derecho de Harvard, preguntó si la CIA y Agencias gubernamentales similares, estaban implicadas en la gestión de remailers anónimos, ya que esto sería un medio perfecto para escanear posibles mensajes ilegales.

Ambos ponentes reconocieron explícitamente que una serie de remailers anónimos de EE.UU son administrados por organismos oficiales de escaneo de tráfico.

Marlow afirmó que el Gobierno controla, al menos, una docena de remailers que los más populares de Francia y Alemania están a cargo de respectivas agencias gubernamentales de estos paises.

Además, mencionaron que la N.S.A (Agencia Nacional de Seguridad) Ha desarrollado con éxito sistemas para romper mensajes cifrados con claves de 1000 bits, por lo que aconsejaron intensamente la utilización de claves de, al menos, 1024 bits. Dijeron que ellos mismos usan claves de este tamaño...”

Es muy curioso que la NSA haga pública su capacidad de romper claves de 1000 bits cuando la utilidad de romper una clave sólo existe mientras esa habilidad se mantenga en secreto. En fin, aquí está (al final de la página de Debian Administration) El texto original:

Cypherpunks archive-96.02.29-96.03.06: List of reliable remailers

List of reliable remailers

Anonymous Remail Service (nobody@vegas.gateway.com) Sun, 3 Mar 199609:18:03-0500

(       Messages sorted by: [date][ threa4][ subject][ author]

(       Next message: Adam Shostack: "Re: NYT on Crypto Bills"

(       Previous message: Raph Levien: "List of reliable remailers"

(       Next in thread: Black Unicorn: "Re: your mail"

Thought that this was worth reposting:

>1 attended last weeks "Information, National Policies; and International

>Infrastructure" Symposium at Harvard Law School, organized by the Global

>Information Infrastructure Commission, the Kennedy School and the

>Institute for Information Technology Law & Policy of Harvard Law School.

>During the presentation by Paul Strassmann, National Defense University

>and William Marlow, Science Applications International Corporation,

>entitled 'Anonymous Remailers as Risk-Free International Infoterrorists"

>the questions was raised from audience (Professor Chaarles Nesson,

>Harvard LAw School) - in a rather extended debate - whether the CIA and

>similar government agencies are involved in running anonymous remailers

>as this would be a perfect target to scan possibly illegal messages.

>Both presenters explicitly acknowledged that a number of anonymous

>remailers in the US are run by government agencies scanning traffic.

>Marlow said that the government runs at least a dozen remailers and that

>the most popular remailers in France and Germany are run by the

>respective government agencies in these countries In addition they

>mentioned that the NSA has successfully developed Systems to break

>encrypted messages below 1000 bit of key length and strongly suggested

>to use at least 1024 bit keys. They said that they themselves use 1024

>bit keys.

>J ask Marlos afterwards if these comments were off or on record, he

>paused then said that he can be quoted.

>So I thought I pass that on. ft seems interesting enough, don 't you

> think?

>Best

> Viktor Mayer-Schoenberger

>Information Law Project

>Austrian Institute for Legal Policy

Groundfog@alpha.c2.org

(       Next message: Adam Shostack: "Re: NYT on Crypto Bills"

(       Previous message: Raph Levien: "List of reliable remailers"

(       Next in thread: Black Unicorn: "Re: your mail"

I of 1                                                          05.09.96 01:58

 

Después de realizar no pocas pruebas para comprobar el funcionamiento de Mixmaster en Linux, concretamente en Ubuntu 7.10, es necesario corregir la entrada que se publicó aquí hace unos días.

Como se había dicho, no existe una aplicación gráfica en Linux que permita un manejo fácil de este programa. Eso dificulta las cosas, pero tampoco en exceso. Veámos cómo, desentrañados ciertos misterios, también desde una distribución Linux, es posible el envío de correo anónimo con facilidad.

 

INSTALACIÓN.

La instalación de Mixmaster en Ubuntu, por tanto en cualquier otra distribución basada en Debian, carece por completo de dificultad. La aplicación está en los repositorios y lo único que se ha de hacer es buscarla en el gestor de paquetes Synaptic, marcarla para su instalaión y pulsar el botón "aceptar".

No obstante, como será necesario actualizar el estado y las estadísticas de los "remailers", también se debe instalar "Echolot". Se trata de un "pinger" que regularmente comprueba el estado (activo o no) De los "remailers que serán utilizados en el envío de los mensajes. Lo mismo que en el caso anterior, su instalación se puede hacer perfectamente desde Synaptic.

Hay otra cosa más que instalar: El agente de transporte de correo Postfix y esto como alternativa a Sendmail. Este programa también está disponible en Synaptic.

 

USO DE MIXMASTER. 

En Ubuntu, Mixmaster debe manejarse desde la consola, bien utilizando la línea de comandos, bien mediante un entorno gráfico, desde luego primitivo pero, no obstante, sencillo de usar. Esto será lo que haremos aquí.

En primer lugar es necesario actualizar la lista de remailers y sus claves públicas, para asegurarnos, en la medida de lo posible, que nuestro mensaje no quedará atascado en algún punto de su recorrido. Para ello, abriremos la consola e introduciremos el siguiente comando:

sudo mixmaster-update

 A continuación, en la misma consola, escribiremos "mixmaster" y pulsando la tecla "Intro" aparecerá la siguiente pantalla:

Pulsando la letra "m" el programa nos dirigirá a una segunda pantalla en la que se introducirá la cuenta de correo del destinatario y el "asunto" del mensaje:

Una vez completados estos datos y pulsada la tecla "Intro", el programa mostrará otra pantalla en la que es posible modificar la cadena de remailers, bien especificando varios determinados o, mediante asteríscos, un número aleatorio de estos.También, en esta pantalla, se podrá especificar el número de copias del mensaje que se quieren enviar: "redundancy". Ello se hará pulsando, respectivamente, las letras "c" o "r".

La opción "e" (edit) Que igualmente aparece en esta pantalla, abrirá el editor Vim, donde se podrá escribir el mensaje. Por otra parte, si lo que se pretende es enviar un archivo de texto existente, la opción será "f" y, en la pantalla que aparezca, se deberá teclear el nombre del archivo en cuestión junto con su ruta completa:

Bien, determinada la cadena de remailers y si se quiere o no enviar más de una copia, pulsaremos la letra "e" para pasar a redactar el mensaje:

Esta pantalla es la que esconde uno de los quebraderos de cabeza que proporciona Mixmaster en Linux. Lo primero que hay que hacer para comenzar a escribir, es pulsar la tecla "Insert". Terminada la redacción del mensaje, es necesario salir de esta pantalla. Para ello, hay que pulsar nuevamente la tecla "Insert". Después, con un doble click del ratón, nos situaremos en la última línea de la ventana. Hecho esto, pulsaremos, simultáneamente, las teclas "Alt-w" y, a continuación, las teclas "Mayúsculas-q". Finalmente, en la línea que aparece, tal y como se ve en la imagen anterior, escribiremos "exit". Esto nos llevará a la siguiente pantalla:

En este momento es necesario enviar el mensaje que se acaba de redactar al "Pool" de Mixmaster, una carpeta en la que quedan depositados los correos a la espera de su envío. Para ello se pulsará la tecla "m".

Así volveremos a la pantalla del menú inicial, pero ahora, en su parte superior, veremos el número de mensajes depositados en el "pool" a la espera de su envío, uno en el caso de este ejemplo:

Desde esta pantalla, podemos repetir el proceso cuantas veces se quiera, acumulando los distintos mensajes en el pool hasta que llegue el momento de enviarlos todos juntos. Para ello, simplemente, hay que pulsar la tecla "s":

Ahora, más o menos en un día o, si hay suerte, en unas horas, nuestro correo llegará a su destinatario, aunque es posible que con algunos problemas de tipográfía en palabras con tilde o en distintos signos de puntuación. Esta es una servidumbre impuesta por lo precario del editor Vim.

No obstante, aún queda otra cuestión que resolver. En Windows, utilizando "Quick Silver" podía usarse, sin ninguna complicación, el cifrado mediante PGP o Gnupg. En Linux, con toda certeza, también será posible cifrar los mensajes con la clave pública del destinatario... Solo que aún no hemos averiguado cómo hacerlo. Seguiremos investigando y, por supuesto, encontrada la solución, daremos buena cuenta de ella aquí.

 

Por su interés sobre la materia que se está tratando aquí, se reproduce íntegramente el siguiente artículo aparecido en SET (Saqueadores Edición Técnica) Nº 34:

 
DIEZ AÑOS DESPUES 
 
Parece imposible pero lo cierto es que han pasado un montón de años desde que empezó a necesitar un poco de anonimato en sus andanzas por la red. Todo empezó cuando por motivos extravagantes se le ocurrió comunicar al administrador de  una lejana red, que tenia un agujero enorme de seguridad. Nada le obligaba,  podía pasar de largo y dejar las cosas como estaban. En el fondo era la 
necesidad de autoafirmarse, de que alguien ademas de él conociera sus  capacidades. Muchos han sido descubiertos movidos por esta ansia de notoriedad. Ya en aquella época, era consciente de este peligro y para comunicar sus descubrimientos utilizó un servidor nymserv. Ya sabéis, uno de esos servidores que permiten recibir y enviar mensajes de forma anónima. ¿O tal vez no tenéis ni idea? En todo caso este viejo recuerdo nos puede servir de excusa para hacer un repaso a la evolución del anonimato en la red.
 
HACE DIEZ AÑOS 
 
En aquellos lejanos tiempos, no hacia ni cinco años, que la red tal como hoy la conocemos se había constituido, pero los problemas y las preocupaciones que  tenemos afloraban ya como temas de portada, tal vez porque eran y son problemas inherentes a la naturaleza humana. Ya se empezaba a hablar de dinero virtual,  de robo de información, patentes infringidas, cesión gratuita de bienes 
inmateriales y un largo etcétera. Entre ellos existía el problema del  anonimato, también algo que es viejo como el mundo. En cualquier asamblea  griega estamos seguros que mas de uno habría expresado su opinión de forma  distinta si no tuviera que soportar las miradas desaprobadoras de los que 
ostentaban la verdad oficial y correcta. Hoy todavía pasa lo mismo en todas las reuniones empresariales. No digamos los deseos que tendría cualquier romano de  opinar libremente sobre los excesos del ultimo emperador desquiciado y no dejan de ser curiosos los sistemas que se utilizaban hace dos mil años para esquivar  una deportación a la díscola Judea o una visita de solo ida a los leones del  anfiteatro.
 
Con nuestra red global ocurrió rápidamente lo mismo. Muchos pensaron que iba a  ser el método ideal para proclamar sus ideas sin resultar afectado  posteriormente por los todopoderosos mandamases. Era la época en que  ingenuamente se decía que “en Internet nadie sabe que soy un perro”, no se si 
os acordáis de este chiste, pero a mas de uno se le atragantó la gracia cuando  recibió una visita policial. Ahora todos sabemos que no basta con poner un  seudónimo en la descripción de nuestro gestor de correo y que la dirección IP  puede ser difícil de relacionar con una persona en concreto para un común  mortal, pero es un asunto de chiste para cualquier departamento policial. Fue  en aquel momento cuando aparecieron los primeros servidores que pretendían  facilitar un poco de anonimato a quienes desearan expresarse libremente sin  miedo a represalias.
 
PRIMER TENTATIVO, anon.penet.fi
 
Fue el primer tentativo de crear un dispositivo publico que permitiera a  cualquiera enviar un mensaje sin que el destinatario conociera el origen real  del remitente, pero al que se pudiera responder de forma privada. El “pero” es  importante, si no se puede responder a alguien es imposible establecer una  conversación. Si hay alguno que le gusta la ciencia ficción y ha leído “El  juego de Hender” se dará cuenta que enviar mensajes anónimos al universo puede  que sea aleccionador, pero no deja de ser un poco unilateral. En fin, el  operador de anon.penet.fi tenia muy buena voluntad pero el sistema que puso en  marcha tenia muchas carencias.
 
La mas grave era que el operador conocía la dirección real de los usuarios.  Todo el sistema se basaba en una tabla interna en el servidor donde se  relacionaba el seudónimo utilizado por la persona que quería guardar el  anonimato y su dirección real. Ademas los mensajes viajaban sin ningún tipo de 
cifrado, cualquiera podía interceptarlos en la red y leerlos, entre ellos los  agentes de la policía. Cuando el operador del servidor se vio ante el riesgo de ser obligado a suministrar la base de datos a las autoridades, suspendió  parcialmente el servicio.
 
Después se encontró en frente a otro problema. Había limitado el numero de  mensajes y su tamaño de forma drástica para evitar el spam y la sobrecarga del  sistema. Estas precauciones no fueron suficientes cuando finalmente debió de  suspender el servicio cuando se vio inundado de peticiones de altas de nuevos  usuarios. Fue un buen intento que duró poco tiempo. 
 
SEGUNDO INTENTO, REMAILERS ANONIMOS TIPO-1 
 
También se les conoce como “remailers cipherpunks” nacieron con un sistema de  clave publica que cifraba todos los mensajes, esto dejaba con dos palmos de  narices a los curiosos que estaban a la escucha. Sin embargo hay otros sistemas de ponerse a la escucha y uno de ellos es medir el tamaño de los mensajes a la  entrada y a la salida. No os riáis porque el asunto es totalmente cierto. Se 
puede establecer el origen de una serie suficiente grande de mensajes solamente conociendo el numero de bit que lo componen y hay gente que se dedica a hacer  este tipo de análisis. Los personajes que practican estos hobbys no son los que escogeríamos como compañeros de copas para una salida nocturna.
 
Resultaron de gran utilidad para enviar mensajes sin que fuera posible conocer  el origen de los mismos, incluso frente a una citación judicial. El operador de un remailer tipo-1 puede conocer el origen de los mensajes y por tanto no puede negarse a suministrar esta información a un investigador judicial, pero si el  usuario del servicio a utilizado dos remailers encadenados, todo lo que pueden  decir, incluso en el caso de que desearan colaborar con la justicia, es que una serie de personas utilizaron el primer remailer para enviar mensajes al segundo, pero no saben que relación hay entre los mensajes salidos del segundo remailer  y los entrados entre el primero. Todo esto es en parte teórico. Si un  departamento judicial poderoso con medios financieros suficientes, puede  encargar un análisis estadístico y en base a los tamaños de los mensajes y las  horas de entrada y salida, finalmente se puede saber quien ha enviado que y a  donde.
 
Resumiendo, este tipo de servicios son útiles si estas delatando que el  presidente de la comunidad de propietarios donde vives, se entiende con la  administradora de la comunidad y entre ambos se están beneficiando de las  ultimas derramas para sufragar los gastos de mantenimiento de la fachada. Si lo
que quieres es anunciar un sistema fácil de clonar tarjetas de crédito del  Banco A, ya puedes quitarte la idea de la cabeza, pues si hay algo mas sucio  que los intereses políticos esos son los intereses económicos de las grandes  corporaciones. Te descubrirán y puedes acabar bajo las aguas del río mas 
cercano con una piedra en el cuello.
 
SEGUNDO INTENTO, REMAILERS ANONIMOS TIPO-2 
 
En general estos remailers adoptaron medidas para evitar el traceado de los  mensajes. Disponen de sistemas de retención de salida de los mensajes, todos  los mensajes salen troceados en pedazos idénticos y  detección de “replay”. Son mucho mas seguros pero tienen el mismo problema básico, es posible enviar  mensajes pero no es posible saber quien los envía y por tanto es imposible  contestar al remitente, salvo que incluyas dentro del mismo mensaje la  dirección del remitente Para poner un ejemplo con el correo de papel clásico es como si las cartas se enviaran cerradas y selladas, pero sin la dirección del  remitente Tienen que abrir el sobre para saber quien la ha enviado y en caso de
actúes así, el receptar conocerá quien envió la información y puede utilizar  esta información de forma indeseada.
 
TERCER INTENTO, nym.alias.net 
 
Para cubrir esta laguna y poder enviar y recibir mensajes de forma anónima y  segura, un par de estudiantes del MIT Laboratory for Computer Science, crearon  en 1998 un software que pretendía resolver el problema. El sistema se basaba  por encima de todo en un vacío legal en los Estados Unidos. La maquina que  alojaba, y aloja, el servicio se encuentra físicamente en dicho país y por 
tanto se debe regir por sus leyes. Lo primero que hicieron con muy buen  criterio los desarrolladores, fue comprobar que no había ninguna ley que  prohibiera la puesta en marcha, pero el caso es que tampoco existe de forma  explicito el derecho al anonimato. Todavía hoy se encuentra el problema en un  vacío legal que sucesivos gobiernos han intentado colmar sobre todo después del atentado del 11 de Septiembre. Su funcionamiento en suelo español seria  probablemente imposible.
 
El aspecto técnico es bastante sencillo aunque hay mucha gente que no acaba de  entenderlo. Todo el sistema se basa en les remailers Tipo-1. Como hemos  explicado estos remailers se comunican bajo mensajes cifrados. Esta es la base  del sistema. El servidor nym solo retiene tres informaciones de cada usuario,  su alias, la clave publica pgp y un bloque de respuesta que se encuentra  cifrado con la clave del servidor. En caso de que los administradores del  servidor tengan curiosidad o bien reciban una citación judicial, podrán abrir  el bloque de respuesta  pero ahí se van a encontrar con una pequeña sorpresa. 

Si el usuario ha sido inteligente, no va a encontrar la dirección del correo  real del utilizador sino la dirección de un remailer Tipo-1. De esta forma el  administrador nym se encuentra al abrigo de cualquier curiosidad malsana o de  un ataque legal. Si la policía quiere saber algo mas tiene que mandar otra  citación al administrador del remailer, suponiendo que se encuentre en el mismo
país ya que si esta fuera de las fronteras las cosas se complican claramente en la investigación Los bloques de respuesta se pueden complicar todo lo que se  quiera aunque los mismos creadores de nym.alias.net aconsejan tres como mínimo.

En casos extremos en que el presunto delincuente haya hecho algo muy gordo, las policías de los países occidentales tienen suficientes medios y paciencia para  ir desenredando la madeja de un bloque de respuesta bien creado, pero sin embargo hay todavía una solución que permite ser realmente anónimo. Basta con  poner como ultimo destinatario una new como por ejemplo alt.anonymous.messages después con leer diariamente dicha news se puede estar al corriente de lo que se te envía  y es realmente difícil identificarte entre el cumulo de gente que 
utiliza el servicio.
 
Tan pronto como el servicio se hizo publico empezaron todo tipo de ataques, pero el sistema demostró ser muy robusto.  El mas obvio es crear múltiples cuentas y después no utilizarlas, ahogando la maquina servidora. Para evitar esto, el software mantiene la fecha del ultimo mensaje cifrado que utilizo la  cuenta. Después de 90 días sin utilización y de tres mensajes de advertencia la cuenta se borra. Otro sistema de acallar un servicio incomodo para ciertos  gobiernos es enviar un gran numero de mensajes. Fácilmente se puede controlar este ataque limitando el numero de mensajes que puede recibir una cuenta diariamente. Si se supera este limite, la cuenta se bloquea y el usuario recibe
un mensaje de advertencia. Pasados 24 horas el legitimo usuario puede reactivar la cuenta y desde luego el atacante puede volverla a atacar pero difícilmente puede hacerlo sin revelar su identidad. Es solo un ejemplo de las modificaciones y mejoras que se fueron implementando durante el primer año de  servicio y que finalmente hicieron del esquema algo legendario y de gran robustez, sobreviviendo incluso, según sus autores, a una citación del FBI por pornografía infantil.
 
Y PASARON CINCO AÑOS     
 
Pocas cosas cambiaron desde el aspecto puramente técnico Los sistemas remailer mantenidos de forma altruista siguieron floreciendo como las hierbas en primavera y con igual rapidez desaparecían Se hicieron diversos intentos de desarrollar servidores anónimos que prestaban anonimato tanto en navegación como en almacenamiento y envío de información, sin embargo ninguno tuvo gran éxito aunque algunos languidecen todavía en la red. Los motivos son diversos, pero a nuestro entender son de naturaleza puramente económica. Poner en marcha un remailer es sumamente fácil, pero no hay forma humana de obtener rentabilidad por el mismo. Todos los gastos son a cargo del supervisor. Si para su desgracia se vuelve popular, rápidamente vera como el ancho de banda que tiene contratado se reduce a la nada y su altruismo decrece rápidamente. Si recibe una citación judicial el proceso de desmejora de su amor por la humanidad se reduce a la mínima expresión y se dedica a otras cosas menos peligrosas. Todo ello si únicamente a puesto en marcha algo casero, porque si lo que desea de entrada es dar un servicio de calidad, tiene que pensar en diversas maquinas situadas bajo legislaciones diferentes y esto no hay economía privada que lo soporte.
 
No es raro que en aquellos tiempos se empezaran a detectar remailer supersecretos. Nunca se publicaban en sitio alguno y nadie conocía su existencia. La motivación que creo su existencia fue un cierto movimiento en los Estados Unidos contra los remailers anónimos De forma acertada esta presión  contra los remailers desapareció rápidamente y el motivo no fue por amor a los derechos de los demás sino simplemente para evitar que la tecnología se le escaparan de las manos. Todos sabemos que la necesidad agudiza el ingenio, en el caso que nos ocupa si alguien presiona a los operadores de estos equipos,  estos se van a trasladar fue de los EEUU. Nada impide montarse un equipo virtual sobre un proveedor en Angola y ahí que te busque la CIA si lo desea. 

Peor todavía puede ser si algún estado paupérrimo y que tanta es su pobreza que ni si quiera tiene deudas y por tanto no puede temer a las represalias del Banco Mundial, se dedique a incentivar la implantación en su territorio de remailers anónimos, puede ser un negocio magnifico con escaso riesgo y nula  inversión Protegidos por las leyes internacionales, pueden operar indefinidamente sin problemas. Algo parecido a lo que ocurrió en la navegación marítima con las banderas de conveniencia.
 
Esto no es una elucubración, en el 2001, Matt Goyer anuncio la creación de un “offshore Napster” en Sealand. Si buscáis este estado en el registro de las  aciones Unidos, no lo vais a encontrar, pero existir existe. Se trata ni mas ni menos de una antigua plataforma de comunicaciones militares inglesas, que por una carambola del destino y un vacío legal en los años 1967, permitió al  tal muchacho autoproclamarse príncipe de dicho miniestado. El que no se crea la  historia que se pase por www.sealandgov.org Si el proyecto del “offshore Napster” no prosperó fue únicamente porque aparecieron nuevos tecnologías y redes, como emule, que hicieron obsoleta la idea. Si no hubiera existida la presión contra Napster, no hubiera habido razón ni motivo para que alguien desarrollara una solución alternativa. Fue probablemente esto lo que condujo a limitar los ataques contra los remailers en suelo americano. Debieron pensar los jerifaltes de aquellas tierras, que si estaban cerca y la tecnología era conocida siempre se podía ejercer algún tipo de control e impedir que alguien 
se fuera a dedicara desarrollar algo nuevo de consecuencias imprevisibles.
 
Y PASARON DIEZ AÑOS 
 
Pasaron diez años y estamos en sorprendentemente al mismo nivel tecnológico que  a finales del siglo veinte. La tecnología de cifrado es la misma, los remailers  siguen basándose en los mismos softawares, los servidores nym son idénticos y las news de mensajes anónimos siguen funcionando de idéntica manera. Nada ha evolucionado en estos años y ello es mas sorprendente cuando en otros campos 
tecnológicos la diferencia es abismal. Nadie hubiera pensado hace una década que podríamos escuchar música en un aparatito que almacena no se cuantos miles de canciones en un espacio donde no podríamos ni meter una moneda de valor ínfimo Nadie hubiera podido pensar en la posibilidad de sintonizar cien emisoras de radio por satélite mediante un módico abono. ¿Quien hubiera pensado 
en la posibilidad de almacenar varias películas comerciales en un dispositivo de lectura portátil? Sin embargo todo eso es hoy posible y comercialmente viable.
 
En nuestra opinión han habido dos factores que han desembocado en esta  situación Por un lado las potencias occidentales han tenido buen cuidado en  medir la presión legal contra los remailers anónimos y por otra han desincentivado al máximo todo desarrollo en el campo del anonimato. Pero veamos  que es lo que ha quedado de todo aquel movimiento efervescente de la década 
anterior.
 
Los sistemas comerciales languidecen sin un fuerte empuje. Sitios como www.mailvault.com o www.anonymizer.com dan servicio pero no han tenido el éxito que se esperaban, o que al menos 
esperaban sus creadores. Aunque aquí los motivos son un poco mas evidentes. Por mucho que proclame su total anonimato desde el momento que se produce una factura y un pago, la red no permite todavía una total anonimato. Si ademas las claves de intercambio se encuentran almacenadas dentro del mismo sistema se puede empezar a desconfiar. Finalmente nadie puede realmente estar seguros que no se registran los accesos y la utilización del sistema. Todo ello lleva a valorar servicios con cierta precaución y tan solo utilizarlo cuando realmente el riesgo en juego sea limitado.
 
Estudio separado merecen los servidores nym. Si buscamos en google por “nymserver” el problema es que encontramos demasiadas referencias y escondidos entre la hojarasca es difícil encontrar las buenas referencias. Para acercarnos a nuestra presa hace falta un poco de suerte y con ella es donde encontramos una cierta información En http://www.panta-rhei.eu.org/pantawiki/nimservers y casi por casualidad encontramos una lista de servidores nym. Os invitamos a seguirnos en esta investigación
 
En la propia pagina daban indicaciones de los servidores que eran conocidos. Por riguroso orden de aparición eran, nym.panta-rhei.eu.org, nym.alias.net, nym.at, blackhole.riot.eu.org, hod.aarg.net, nym.komite.net , nymph.paranoici.org , nym.xganon.com . La primera decepción es que diez años 
después de la aparición de esta tecnología, tan solo existan en todo el mundo ocho servidores disponibles. Pueden parecer muchos o pocos pero el caso es que en la red solo puedes confiar en la que puedas comprobar por fuentes independientes y fiables. Fiables somos nosotros e independientes significa cotejar la información que nos daban con nuestras propias investigaciones. Si os leéis las instrucciones originales de nym.alias.net, os enterareis que lo primero que hay que hacer es obtener las instrucciones concretas del servidor que deseamos utilizar y que estas se pueden obtener enviando un mensaje en blanco a una dirección de correo concreta, que empieza siempre por help@.
 
De entrada la misma pagina nos comunica que el servidor hod.aarg.net no respondía a este estimulo desde 2005. Otra opción para saber si nos encontramos con algo vivo o moribundo es obtener la lista de usuarios nym del servidor y para ello basta con enviar un mensaje vacío a otra dirección especifica de correo, en este caso es list@. Nos decantamos con esta segunda técnica y obtuvimos el resultado siguiente. nym.at, sin respuesta; hod.aarg.net, 338 usuarios; nym.mixmin.net, 24 usuarios; nym.komite.net, 90 usuarios; nymph.paranoici.org, 147 usuarios; nym.alias.net, 171 usuarios; nym.panta-rhei.eu.org 162 usuarios; riot.eu.org, sin respuesta.
 
De cualquier ristra de números se pueden sacar estadísticas, que nos impide hacerlo para los datos anteriores ? Para empezar de los ocho servidores anunciados tan solo seis estaban vivos en el momento de la prueba, o sea un veinticinco por ciento han desaparecido de la escena. El numero total de usuarios es de 932. Si nos paramos a pensarlo es un numero ridículamente pequeño. Estamos hablando de un servicio que rinde anonimato a todo el planeta Tierra y resulta que apenas un millar de ellos sienten la necesidad de ocultar sus datos personales. Es todavía mas pequeño si analizamos los nombres de usuarios ya que hay repeticiones y todo indica que mas que otra cosa son pruebas y ensayos. El que nym.alias.net se encuentre en tercer lugar como numero de usuarios es otra prueba de que no hay realmente utilizadores de verdad. nym.alias es un servidor alojado en una universidad y mantenido por estudiantes y algún profesor nostálgico. Fue y sigue siendo una prueba de concepto mas que un verdadero servicio y no creemos que el publico que lo utilice emplee sus servicios para cosas importantes.
 
Si alguien quiere realmente servirse de esta técnica utilizara una maquina que este bien mantenida. Normalmente esto se encuentra en empresas que ofrecen algo como publicidad. Es el caso de hod.aarg.net, que como era de esperar acumula el solo mas de un tercio de los buscadores del anonimato, pero incluso en este caso las cosas se ponen difíciles de una forma no muy clara. La técnica nymserver es sencilla de entender pero todo un engorro de utilizar. Cuando se recibe un mensaje a través de toda la cadena de remailers, los mensajes se cifran sucesivamente, por la tanto se deben descifrar de la misma forma y esto hacerlo a mano es simpático una vez por curiosidad, pero si se reciben varios mensajes diarios es simplemente una tortura. Resumiendo, para poder utilizar 
esta técnica no hay mas remedio que pasar por un programa que te automatice todas las tareas. Este es el caso de Jack B, Nymble. El único problema es que este soft carece de mantenimiento desde la ultima glaciación y la versión oficial solo soporta pgp 2.6 o 5.5, en ambos casos la llave a utilizar debe ser RSA. Pues resulta que el mejor servidor utiliza una clave DH/DSS lo que impide apoyarse sobre la versión oficial de Jack.
 
No es un problema irresoluble, pero no deja de fastidiar y mosquear que se tenga que utilizar un parche que suministra el mismo hod.aarg para utilizar el servicio y encima instalarse una versión de PGP superior. Lo dicho. Puede que sus buenas razones existan pero lo cierto que se puede empezar a desconfiar. Personalmente nosotros solo hemos sido capaces de utilizar de forma estable este servidor, aunque otras voces en la red indican que panta también es fiable. nym.alias.net siempre ha estado funcionando durante sus mas de diez años de historia pero puede dejar de reenviar durante periodos que pueden pasar del mes completo. No puede basarse toda una estrategia de comunicación sobre semejante fiabilidad.
 
DONDE ESTAMOS
 
La realidad es que falta un verdadero interés por parte del publico que debiera buscar activamente una solución al problema real de nuestra indefension ante el espionaje al que estamos sometidos. Muchos se reirán, pero el asunto es  simplemente serio. No hace falta ningún tipo de mandato judicial para que 
cualquiera lea nuestra correspondencia. Puede que este sea un probo funcionario que esté tras las trazas de un pedófilo y puede que sea un político que se encuentra sumamente molesto sobre la serie de mensajes incómodos que estamos enviando durante la campana electoral y quiere intentar un chantaje. Puede que se trate de alguien que trabaje dentro de tu misma corporación y está buscando 
un punto flaco por donde atacarte y dejarte en ridículo durante la próxima reunión plenaria. Todo es posible y nadie parece interesarse. Los pocos usuarios de las cuentas nym es una prueba. La única realidad es que dichas cuentas son un poco complicadas de utilizar y el genero humano es tan sumamente vago que todo el mundo prefiere llenarse la boca con grandes palabras y elogios 
de principios inalienables pero no esta dispuesto emplear ni medio segundo en gastar energías propias. Siempre es mejor culpar a otros y quejarse.
 
No hemos hablado de otras técnicas que salieron hace algunos años o redes virtuales. Freenet, remailers de tipo III, y otros proyectos intentan jugar nuevas bazas. Tampoco nos ha quedado tiempo para describir sistemas semiprivados envueltos en un halo de misterio como por ejemplo www.mailvault.com  Desde luego no queremos meternos en líos y dejamos para otros mas valientes desvelar que esta pasando donde se juega mucho dinero y las leyes que conocemos no son de aplicación Estas lineas han sido dirigidas a los normales y mortales usuarios de nuestra red.
 
2007 SET, Saqueadores Ediciones Técnicas. 
Información libre para gente libre
www.set-ezine.org
 
*EOF*

 

Contra los posibles ataques destinados a averiguar qué se dice en un mensaje de correo electrónico enviado mediante un “remailer” y a quién se le dice, hay distintas medidas de seguridad que se van uniendo.

En primer lugar el mensaje deberá cifrarse con la clave pública del destinatario. Esto impide al atacante conocer el texto, pero aún está a su disposición la cuenta del destinatario y los datos de reenvío que se proporcionan al “remailer”.

La solución está en cifrar, a su vez, todo el mensaje, incluyendo las indicaciones al remailer, con la clave pública de éste.

El “asunto” del mensaje es otro problema serio. Asumiendo que todos los mensajes que entran y salen de un remailer están siendo “monitorizados”, el "asunto" será una señal inequívoca de identidad que delatará tanto al remitente como al destinatario. Los remailers han solucionado esto modificando automáticamente el campo del “asunto”.

El tamaño del mensaje es otro elemento característico que permitirá identificarlo y, por tanto, que delatará a los corresponsales. Contra esto existen varias técnicas de defensa. En primer lugar el tiempo de “latencia”. Un mensaje que entra en un remailer, no saldrá de él inmediatamente, sino después de un tiempo determinado que los fisgones desconocen. Otra variante del tiempo de latencia, es el “pool” o depósito. Los mensajes son mantenidos en depósito, al menos hasta que entra un número determinado de mensajes nuevos, luego se elige alguno de los almacenados, al azar, y se envía.

Aún así, el atacante tiene varias posibilidades de solventar este inconveniente. Puede lanzar un ataque de denegación de servicio, de forma que impida que ningún mensaje nuevo entre en el pool hasta que éste esté vacío. Con esto neutraliza los efectos del tiempo de latencia. También puede, si el remailer ha tomado la precaución de no dar salida a ningún mensaje hasta que otros nuevos entren, introducir en él un número masivo de mensajes nuevos para provocar el vaciado del pool. Aún mejor, puede interceptar el mensaje entrante que quiere rastrear, a su entrada al remailer, y remitir un número masivo de copias, esperando ver quién recibe, poco después, un número igual de mensajes de similar tamaño. Los remailers se defienden de estos ataques bloqueando el “span” o, en el caso de las cuentas “nyms” (ya se verá qué son) No dando salida a más de un mensaje con idéntica “firma” cifrada.

El problema del tamaño también ha sido resuelto de dos formas: añadiendo datos inútiles al mensaje para modificar éste, o dividiéndolo en partes iguales que sólo se unirán al final de la cadena, esto en el supuesto de que se enlacen varios remailers.

Otro medio de aumentar la seguridad es, como se acaba de decir, el enlace de varios remailers. Naturalmente, alguien interesado en interceptar mensajes siempre tiene la posibilidad de creael suyo propio y cazar en él a sus víctimas como a conejos. Al establecer una cadena de sucesivos remailer, el compromiso de uno de ellos, no compromete la seguridad del mensaje. Éste viaja cifrado, de forma anidada, con las claves públicas de todos los remailers por los que ha de pasar de forma que, cada uno de ellos sólo sabe de dónde le llegó y a dónde lo ha de enviar, pero desconoce el origen real y el destino real, salvo el último de la cadena que, naturalmente sabrá cual es el destinatario final.

La primera aplicación que reunió todos estos sistemas de defensa contra los ataques de análisis de tráfico fue “Mixmaster”. Los remailer de tipo Mixmaster cifran los mensajes con una triple llave DES; mantienen una lista de mensajes enviados de forma que a ninguno se le de salida más de una vez; enlazan, sistemáticamente, varios remailers de forma que cada uno de ellos sólo pueda conocer de dónde le llega cierto mensaje y a dónde lo envía; y dividen los mensajes en partes iguales de 10 Kb y cada una de estas partes las trata como mensajes independientes que sólo se unirán al final de la cadena. Además, el mensaje original también podrá ser cifrado con la clave pública del destinatario de modo que, ni aún el último remailer de la cadena, pueda conocer su contenido.

 

Uso en Windows.

En Windows existen varios clientes de correo para uso del protocolo Mixmaster. El que aquí se va a ver es, posiblemente, el de más fácil uso y cuyo funcionamiento está probado, también, en Windows Vista.

Antes de continuar es preciso volver a repetir que la proposición Windows y seguridad, es una contradicción en los términos, pero en materia de manejo de clientes de correo para los remailers de tipo II (Mixmaster) y tipo III (Mixminion) Desgraciadamente, este sistema operativo es el único que dispone de aplicaciones lo suficientemente sencillas como para que estén al alcance de cualquier usuario.

No obstante, la elección ha de hacerse sabiendo que la seguridad de estas comunicaciones puede estar comprometida gravemente desde el principio y, especialmente, en Windows Vista, sobre todo teniendo en cuenta que la NSA, la agencia estadounidense de espionaje, ha colaborado, según informó el Washignton Post, en su desarrollo.

Desde distribuciones Linux, naturalmente, también es posible su uso, pero sólo desde línea de comandos y de forma considerablemente menos intuitiva que en el caso Windows.

Pues bien, teniendo esto presente, pasamos a la instalación y configuración del que nos parece el servidor de correo para remailers de tipo II más sencillo de utilizar: Quick Silver. El programa de instalación se baja desde esta página.

Terminada la descarga, bastará pinchar sobre el icono del ejecutable para que comience la instalación. Ésta es similar a la de cualquier programa para Windows, salvo que, en cierto momento, la aplicación solicitará los datos de los servidores de entrada y salida, pop y smtp, respectivamente. En cualquier caso, los datos de estos servidores se podrán cambiar posteriormente desde la opción herramientas (tools) del menú.

No obstante, aquí sí debe hacerse alguna anotación. En principio, para incluir un servidor de salida smtp, el programa solicita un usuario, por ejemplo “theshadow@gmail.com”; un Host, que en el caso del ejemplo sería: smtp.gmail.com; y una contraseña, la propia de la cuenta de correo correspondiente al servidor smtp.

Por alguna razón que se nos escapa pero que, posiblemente, tenga que ver con los puertos de conexión, dato que el programa no permite modificar, el envío con servidores de gmail y otros, provoca errores y el mensaje no puede salir. Esto no ocurre con cuentas de Yahoo, así que o se prueban distintos servicios hasta que uno funcione o se utiliza un servidor de salida de Yahoo.

Cuando el programa esté instalado, al abrirlo aparecerá esta pantalla. Pulsando en “File” aparecerá un menú con la opción “New” y dentro de ella “New mesage”

Pulsando en dicha opción aparecerá una nueva ventana como la siguiente:

 

Se trata de la ventana en la que se escribirá el mensaje y en la que aparece una cabecera por defecto. De ella, en principio, lo único que habrá que asegurarse es que en el campo Host, está el servidor de salida smtp que se introdujo durante la instalación del programa.

En el campo “Chain” se escribirá, separados con comas, los distintos remailers a través de los cuales viajará el mensaje. En el caso del ejemplo lo que se ve son asteriscos. Esto significa que el programa elegira ocho remailers, de forma aleatoria, de entre todos los que en el momento del envío del mensaje, estén en funcionamiento. El programa, antes de enviar el correo, actualizará automáticamente, la lista de remailers que estén funcionando.

Evidentemente, en el campo “To” habrá que escribir la cuenta de correo del destinatario y, en el campo “Subject”, el asunto del mensaje, si es que se quiere.

Ahora es importante recordar que, entre el final de la cabecera y el inicio del texto del mensaje ha de dejarse una línea en blanco.

Antes de enviar el correo, es posible ordenar su cifrado con la clave del destinatario. Para eso Quick Silver tiene una extensión que no se instala por defecto. Es necesario actualizar el programa pulsando en la opción “Help” y, a continuación, en “Updates”. Se abrirá, entonces, la siguiente ventana:

 

En la lista que aparece buscaremos, sucesivamente, todo lo que tenga que ver con PGP. Con un doble click del ratón comenzará su descarga y su posterior instalación.

Con la extensión PGP instalada, será necesario importar, usando el menú correspondiente, las claves públicas de los destinatarios de los mensajes y nuestro propio par de claves. Cuando esto esté hecho, antes de enviar el mensaje, habrá que pulsar sobre el icono que aparece en la venta de envío con un candado dibujado. A continuación, al pulsar el botón de enviar (Send) se abrirá un ventana con las distintas claves PGP disponibles para que seleccionemos (doble click) La correspondiente al destinatario. A partir de ese momento, comienza el envío del mensaje. Primero el programa realizará el cifrado del texto, luego actualizará la lista de remailers válidos, cifrará todo el mensaje con las claves de los remailers elegidos y enviará el mensaje.

Por alguna razón que también se nos escapa, en las ventanas que van apareciendo durante el envío del mensaje, aparece una con la opción de chequear errores marcada. Si no se quita la marca de esa opción, el envío quedará abortado provocando al usuario serias dudas sobre su capacidad intelectual y su cordura. Bien, parece ser que el problema, como se acaba de decir, queda solucionado quitando la marca en la casilla “Chek errors”.

Por fin, si todo se ha hecho correctamente, nuestro mensaje comienza a viajar, convenientemente cifrado y despedazado en trozos iguales, a lo largo de la cadena de remailers que le hayamos indicado. Evidentemente, cuanto más larga sea esa cadena, mayor será la seguridad del envío, pero, desgraciadamente, también serán mayores las posibilidades de que alguno de esos remailers haya dejado de funcionar. En ese caso, el correo jamás llegará a su destino. Si todo va bien, en uno o dos días, como máximo, ha de llegar a la bandeja de entrada del destinatario.

Considero aconsejable, pese a este problema, que no se utilicen cadenas inferiores a seis remailers y que, además, se permita, mediante asteriscos, que el programa los elija aleatoriamente.

Por último, hay que asegurar que el programa funciona, por lo tanto, si en los primeros intentos se producen errores o problemas, es recomendable la perseverancia y la aplicación del método de ensayo y error.

En la próxima entrada, haremos referencia a la instalación y uso de Mixmaster en Linux, concretamenteen Ubuntu, para ocuparnos después de los remailers de tipo III.

 

Como hemos dicho, es posible enviar correo con cifrado fuerte de clave asimétrica, pero eso sólo es una solución parcial frente a los fisgones que husmean en la Red. Es muy razonable pensar que en no pocas ocasiones el contenido de un mensaje tiene importancia secundaria y que la identidad de quienes intercambian esos mensajes es lo prioritario. En cualquier caso, siempre será útil saber quién envía y quién recibe una comunicación. Si, además, es posible acceder a su contenido, mejor que mejor.

¿Existen herramientas que permitan ocultar con eficacia la identidad de los comunicantes? Existen y, en principio, su eficacia es alta, incluso muy alta, pero sería temerario asegurar que son invulnerables a cualquier ataque conocido o desconocido. En cualquier caso, lo que sí harán es dificultar mucho el trabajo de cualquier fisgón.

Antes de pasar a describir el uso de las herramientas informáticas existentes, es necesario hablar sobre el tipo de ataques que se pueden poner en funcionamiento contra la intimidad de las comunicaciones por Internet.

En primer lugar es necesario descartar aquello que parece anónimo sin serlo en absoluto. Cualquiera puede crear, con datos falsos, una cuenta en el servicio de correo de Google, por ejemplo. Luego tendrá mucho cuidado de no colocar su nombre en los mensajes y de no dar datos que revelen su identidad. Además, como tiene asignada una dirección IP dinámica (de las que cambian cada vez que el ordenador se conecta a la Red) Estará muy seguro de que ningún ser humano podrá dar con su identidad.

Tan seguro está que envía un mensaje a un foro diciendo que cierto capo político de su ciudad guarda parte del botín de sus actividades públicas en un local de la calle X, número Y. Acaba de torpedear una trama mafiosa y, ese día, se va a dormir con la satisfacción del deber cumplido.

Aproximadamente unos 20 o 30 días después de su cívica acción, teniendo en cuenta la lentitud de la Administración pública, recibe en su casa la visita de la policía que le hace entrega de una citación para declarar. El capo ha presentado una denuncia por daños contra su honor (todo el mundo sabe que estos tipos son “hombres de honor”). El Juez de instrucción ha evacuado oficio a la policía para que averigüen los datos de conexión relativos al mensaje enviado al foro en cuestión. Con ese mandamiento, la policía (la Brigada de Delitos Informáticos que, como todo el mundo sabe, sólo se dedica a perseguir pederastas y terroristas) Se ha puesto en contacto con el proveedor de servicios en el que está alojado el foro solicitándole la dirección IP y titularidad de la línea asociada a esa IP, correspondiente al mensaje aparecido en el foro tal, el día tal, a la hora tal... Naturalmente, el proveedor del servicio proporciona, inmediatamente, esos datos a la policía, que a su vez los remite al Juzgado de Instrucción, el cual los hace constar en las diligencias previas, documentos que son accesibles al denunciante y, así, ya tenemos a disposición del Capo, el nombre, los apellidos, la dirección, el Nif, etc. etc. de quien le denunció. Que el juicio se llegue a celebrar o que quien denunció la trama mafiosa sufra un accidente antes del día de la vista, ya es cosa del destino.

En definitiva, que el aparente anonimato de las cuentas de correo electrónico es radical y absolutamente falso. Todos los datos esenciales de la conexión están a disposición del proveedor del servicio, convenientemente almacenados a la espera de que alguien se los reclame, incluso sin mandato judicial.

Eso, precisamente, es lo que hizo Google con respecto a un blogger israelí que acusó a tres candidatos a unas elecciones de aceptar sobornos, relaciones con bandas delictivas, y fraude a las administraciones públicas. Google llegó a un acuerdo con los denunciantes según el cual daría al blogger la posibilidad de identificarse en las 72 horas previas a la vista y, si éste no lo hacía, su IP sería desvelada, cosa que es lo que realmente ocurrió.

Además, hay que recordar que los datos almacenados por los proveedores de servicios pueden ir mucho más allá de la mera dirección IP, de la hora de conexión, lugares conectados, contenidos, etc. Para crear y usar una cuenta, sigamos con el ejemplo de Google, es necesario introducir un usuario y una clave. Para que esto funcione, la máquina desde la que se realiza la conexión, ha de tener activadas las “cookies” y “Javascript”, es decir, deben estar activados programas capaces de recoger cuanta información se pueda uno imaginar de la máquina que se conecta y enviarla al proveedor del servicio, el cual tomará las precauciones oportunas para que quede indefinidamente almacenada y disponible.

Bien, sentado que los servicios web de correo no ofrecen ningún anonimato, sino todo lo contrario, comencemos con los “remailer”. Se trata de servicios web que recogen un correo electrónico y realizan ciertos cambios en él para que al destinatario le llegue como originado en el remailer y no en el remitente original.

Esto es aún más perverso que la cuenta de Google porque aumenta la apariencia de anonimato sin advertir que eso es sólo apariencia. En realidad tanto el texto, la ruta y el destinatario, son elementos que podrán ser observados por todos los sitios por los que el correo va pasando, naturalmente por el ISP (el proveedor del servicio de internet) Pero también por cualquiera que tenga interés en interceptar los datos que entran o salen del remailer, cosa que podrá hacer con cualquier sniffer bajado gratuitamente de la Red o con cosas más sofisticadas como esta siniestra aplicación informática llamada “NarusInsight Intercept Suite”.

Naturalmente, las cosas se pueden mejorar. Es posible establecer una sesión segura del tipo SSL o TLS. Esto quiere decir que los datos viajarán cifrados hasta el remailer, pero saldrán de él en claro y por lo tanto todos los datos y su contenido podrán ser interceptados por cualquiera que esté husmeando el buzón de destino, por el proveedor de destino, etc. etc.

No obstante, así, el origen del mensaje podría permanecer anónimo, pero es aquí donde entra la forma más simple de “análisis de tráfico”. El esquema es simple. Dando por supuesto que lo que entra y sale del remailer está siendo “monitorizado”, el proceso es el siguiente: Entra un mensaje en “R” y sale de “R” recibiéndolo “b”. el receptor “b” contesta, su mensaje entra en R y “a” lo recibe. Ahora es “a” quien contesta... En un tiempo mínimo se habrá establecido la correlación entre “a” y “b” con lo que no sólo se conocerán los datos de la comunicación, sino también la identidad de los comunicantes.

La lucha contra el análisis de tráfico se ha ido haciendo todo lo compleja que es posible y, en la totalidad de los casos, gracias al trabajo voluntario de activistas que lo único que pueden cosechar por su dedicación, son problemas. Así sucesivos remailers han ido añadiendo características como la del cifrado con clave asimétrica tanto del texto como de los datos de conexión, la partición del mensaje en trozos de igual tamaño para evitar que éste sea identificado precisamente por esa característica, la latencia en el reenvío, es decir, la espera de un tiempo indeterminado desde que un mensaje llega al remailer hasta que sale de él, para evitar que se pueda establecer una secuencia temporal que identifique a emisor y receptor, el reenvío, con cifrado anidado, entre un número indeterminado de remailers de las distintas partes de un correo despedazado y cifrado, etc.

Todas estas medidas de seguridad, que se explican mejor que aquí en este enlace, concretamente en el número 14 del boletín SET, están disponibles, en estos momentos, en dos programas de correo anónimo: Mixmaster y Mixminion.

Las páginas de ambos programas, con toda seguridad, producirán un grave desánimo en un usuario normal de informática. No es para tanto. Es más, a pesar de que su desarrollo tiene su origen en entornos Linux, irónicamente, su instalación y uso en Windows resultan asombrosamente sencillos, muchísimo más, en todo caso, que en sistemas Linux, pero esto será objeto de las próximas entradas.

 

El cifrado con clave asimétrica del correo puede proporcionar una seguridad alta y razonable sobre la privacidad del contenido de las comunicaciones, pero el contenido no siempre es lo más relevante. En una situación de represión o de previsible represión, el enemigo que acecha a las puertas puede estar mucho más interesado en conocer la identidad de los comunicantes y contra eso el cifrado del texto no ofrece ninguna protección, porque tanto la dirección de correo electrónico, como los datos de conexión incluidos en las cabeceras de los correos (dirección IP de origen y de destino, distintos servidores a través de los que ha viajado el mensaje, etc.) Viajan “en claro”, es decir, sin cifrar.

De hecho, conocida la identidad de los corresponsales, las claves se convierten en un problema secundario cuando quien pretende romperlas es el Estado. Según el artículo 36 de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, “1.- Cualquier tipo de información que se transmita por redes de comunicaciones electrónicas podrá ser protegida mediante procedimientos de cifrado. 2.- El cifrado es un instrumento de seguridad de la información. Entre sus condiciones de uso, cuando se utilice para proteger la confidencialidad de la información, se podrá imponer la obligación de facilitar a un órgano de la Administración General del Estado o a un organismo público, los algoritmos o cualquier procedimiento de cifrado utilizado, así como la obligación de facilitar sin coste alguno los aparatos de cifra a efectos de su control de acuerdo con la normativa vigente”.

Es decir, en España, pese a la consideración de derecho fundamental que tiene el secreto de las comunicaciones, pese a la obligación de desarrollar su contenido mediante ley orgánica y no ley ordinaria y a pesar de la especial protección reconocida a los derechos fundamentales, cualquier organismo administrativo o, en sentido más amplio, público, podrá imponer, sin necesidad de ningún otro instrumento legal o reglamentario, la obligación de que se le faciliten las claves necesarias para descifrar cualquier información confidencial, sin que para ello le sea exigible orden judicial alguna.

Esto no se produce sólo en España. En una noticia que recoge la bitácora “Efecto Mariposa” se lee que “la Federal Communications Commission americana ha decidido que para preservar el carácter abierto que caracteriza hoy en día a Internet, «los consumidores tienen derecho a ejecutar aplicaciones y usar los servicios de su elección, sujetos a las necesidades de las fuerzas de orden público».

No es razonable, por tanto, poner en duda la ocupación de la Red por servicios de inteligencia, instituciones públicas o policías de cualquier estado y todo ello al margen de controles judiciales o de garantías legales.

La situación es aún más perversa porque el desconocimiento técnico y la comodidad empujan con mucha eficacia a los usuarios a la capitulación y a la entrega sin condiciones de sus derechos constitucionales a la intimidad y al secreto de las comunicaciones. Por ejemplo, las herramientas necesarias para el uso de redes de túneles virtuales como Tor, se instalan, al menos en Windows, con extrema facilidad. Los usuarios podrán disponer de la seguridad que proporcionan sin que la dificultad de uso suponga ningún inconveniente; sin embargo, la red Tor impone ciertos precios. El principal es la lentitud de las conexiones que, en determinadas horas del día, puede llegar a ser desesperante.

Es más, las personas “decentes” se sentirán inclinadas a pensar que este colapso del derecho a la intimidad y al secreto de las comunicaciones es necesario y ajustado a Derecho. De otra manera los criminales, incluso criminales especialmente repugnantes como los pederastas, encontrarían en la Red un espacio de impunidad blindado.

Este es el argumento con el que los Gobiernos están legitimando el colapso del derecho fundamental a la intimidad, pero tal argumento es una falacia en un doble sentido. El control de la Red se ha vuelto tan esencial para las Administraciones, no porque en ella deambulen criminales, que lo hacen, igual que lo hacen por las calles de cualquier ciudad, sino porque ese control, en primer lugar, es posible; en segundo, porque puede ser masivo; y en tercero porque las ventajas del uso de la Red y de las comunicaciones electrónicas atraen, potencialmente, a la totalidad de la población.

Dicho de otra manera, porque la “monitorización” de la Red de forma total y masiva es técnicamente posible, porque el almacenamiento de esa información también es posible e igualmente posible su acceso a voluntad y porque la propia naturaleza de la Red y de las comunicaciones electrónicas engulle como un agujero negro, a masas crecientes de población que, de esa forma, podrán ser vigiladas.

También es falaz ese argumento, porque la ausencia de secreto en las comunicaciones