Gunnar Wolf

Entre todos cuidamos mejor los secretos. ¡Hagamos crecer las redes de anonimato en la región!

Ivett Sanchez — Tue, 19 Oct 2021 15:53:58 +0000

Entre todos cuidamos mejor los secretos. ¡Hagamos crecer las redes de anonimato en la región!

Evento

CCOSS 2021

Ivett Sanchez Tue, 10/19/2021 - 10:53

Conferencista(s)

Gunnar Wolf

En esta charla daré un panorama general de cómo funciona Tor, y de cómo podemos participar en esta red. Pero más allá de participar como usuarios, y siguiendo el espíritu de CCOSS, lo más importante para que una red de anonimato sea fuerte es que sea diversa: Invitaré a los participantes a contribuir con Tor instalando relays, tal vez incluso nodos de salida.

Fecha de sesión

Thu, 10/07/2021 - 12:00

Retos para la red de servidores de llaves públicas PGP (HKP)

Ivett Sanchez — Tue, 19 Oct 2021 14:32:01 +0000

Retos para la red de servidores de llaves públicas PGP (HKP)

Evento

CCOSS 2021

Ivett Sanchez Tue, 10/19/2021 - 09:32

Conferencista(s)

Gunnar Wolf

open source

Muchos proyectos de software libre utilizan al ya venerable OpenPGP como punto de partida para asegurar la identidad de sus participantes y garantizar comunicaciones seguras entre ellos. Las fiestas de firmado de llaves en sus distintas presentaciones son un ritual habitual en las comunidades de desarrollo, y muchos las utilizamos para firmar los correos que consideramos importantes o las versiones de software que vamos liberando oficialmente.

El Dr. Jorge Luis Ortega Arjona es director de tesis de la investigación en la que se basa esta ponencia y coautor del contenido.

Fecha de sesión

Tue, 10/05/2021 - 12:00

Caso de estudio local: LIDSOL

lasr21 — Wed, 02 Oct 2019 01:25:09 +0000

Caso de estudio local: LIDSOL

Evento

CCOSS 2019

lasr21 Tue, 10/01/2019 - 20:25

Conferencista(s)

Gunnar Wolf

El Laboratorio de Investigación y Desarrollo de Software Libre (LIDSOL) es un laboratorio de la Facultad de Ingeniería de la UNAM, establecido en 2001, con el objetivo de promover e impulsar la investigación y desarrollo de tecnologías libres. En esta plática darmos a conocer algunos de los retos y logros que hemos enfrentado, así como tips para replicar iniciativas similares en otras instituciones educativas.

Debian: El sistema operativo universal

AlbertoRJ — Sun, 15 Sep 2019 20:37:44 +0000

Debian: El sistema operativo universal

Evento

CCOSS 2019

AlbertoRJ Sun, 09/15/2019 - 15:37

Conferencista(s)

Gunnar Wolf

La distribución Debian es mundialmente conocida como "el Sistema Operativo Universal". Es una de las pocas distribuciones creada exclusivamente por una comunidad de voluntarios de todo el mundo, sin afiliación específica con una empresa que la dirija, y eso nos permite cubrir básicamente los gustos y las necesidades de... Bueno, básicamente de cualquiera que quiera partirse el lomo y colaborar con nosotros ☺ Y nos gustaría que uno de estos voluntarios fueras tú.

Mecánica Cuántica y Computación

Ivett Sanchez — Tue, 15 Jan 2019 18:50:56 +0000

Mecánica Cuántica y Computación

Ivett Sanchez Tue, 01/15/2019 - 12:50

Publicado en

SG #58

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Saber e ignorar al mismo tiempo

La mecánica cuántica corresponde a un club muy selecto: al de las cosas que todos conocemos y comprendemos un poquito, un pedacito tan diminuto, que nos permite hablar al respecto y hasta parecer que estamos medianamente informados … pero la cantidad de tonterías y suposiciones que flotan al respecto resultan desproporcionadamente grandes.

Ésta aparece en 1900, cuando Max Planck busca explicar el efecto fotoeléctrico, esto es, que hay materiales que cuando reciben haces de luz emiten electrones. Planck sugirió que la energía no es un flujo continuo, sino que se comporta como una serie de "paquetes" o "quanta". Tras dos décadas, el desarrollo sobre esta línea de ideas llevó a que los premios Nobel de 1921 y 1923 se otorgaran (respectivamente, a Albert Einstein y Robert Andrews Millikan) por demostrar que esta hipótesis queda confirmada por ocurrir en otros experimentos, y fundamentando matemáticamente la teoría.

Ondas, partículas y observadores que interfieren

Hasta aquí, todo bien y tranquilo. Sin embargo, las cosas comienzan a complicarse rápidamente. Un experimento cien años anterior, el experimento de la doble rendija, propuesto por Thomas Young, buscaba determinar si la luz consistía en ondas o en partículas. Young llegó al resultado, celebrado y largamente incontrovertido, de que la luz consistía en ondas: este experimento muestra patrones de interferencia, crestas y valles que apoyan a la noción de que existen ondas de luz.

Sin embargo, cuando este experimento se repitió en 1927, con una interpretación cuántica, los resultados fueron diferentes: si se parte de una fuente coherente de luz (como podría ser un láser), puede observarse mayormente el comportamiento de onda —excepto cuando se intenta detectar por cuál de las ranuras pasa la partícula de luz (el fotón) en cuestión. Es decir que a las partículas no les gusta que las espiemos; si intentamos averiguar la posición de una partícula, el sólo hecho de hacerlo destruye la información acerca de su estado (esto se conoce como el efecto del observador). Yendo incluso un paso más allá, Werner Heisenberg propuso en 1927 el principio de la incertidumbre: cuanta mayor certeza se busca en determinar la posición de una partícula, menos se puede conocer su momento lineal y, por tanto, su velocidad.

Llevando este último punto al área que a los lectores de Software Gurú resulta más familiar, si bien con un poco de humor: se conoce como Heisenbug un fallo de software que, cuando lo intentamos ubicar o depurar, altera su funcionamiento. Los Heisenbugs son particularmente habituales cuando intentamos depurar la interacción entre varios hilos de ejecución en busca de una condición de carrera debida a falta de sincronización entre operaciones concurrentes y alteramos el mecanismo de paso de control al lanzar nuestro programa en modo de desarrollo, o a la ubicación específica del contenido de la memoria, que resulta alterada al insertarse instrucciones de depuración.

Las limitaciones de un humano de a pie

No intentaré seguir desarrollando los fundamentos de la cuántica a partir de este punto. La física fue por muchísimos años la ciencia que describe al mundo observable, que permite predecir por medio de la matemática los efectos que una fuerza tendrá sobre un objeto, o la forma en que un impulso surcará las vastas profundidades interestelares.

Como recordaremos de nuestro paso por la secundaria, la física es laboriosa y puede ser frustrante por la cantidad de fórmulas a memorizar y variables a considerar para cuestiones tan simples como un cálculo de trayectoria balística (¿cuál creen que era el principal uso de las primeras computadoras?) … pero son, en general, conceptos tangibles y llenos de sentido.

Con la cuántica, la física pareció por un momento salirse de su carácter. Se presentaron ideologías y posiciones basadas en el «me parece inconcebible.» Y, claro, dada la notoriedad de que gozaron prominentes físicos en los años de las grandes guerras del siglo XX, estas discusiones permearon —carentes de los fundamentos y la comprensión— al público en general. Desde principios del siglo XX, sabemos que si bien la física explica bastante bien al universo macroscópico (física clásica), y también explica con toda la precisión que podemos comprender al mundo subatómico (física cuántica) … la frontera entre uno y otro resultan conflictivas. Los físicos llevan un siglo buscando cómo aterrizar en un modelo unificado que describa al universo a todo nivel de acercamiento.

Tiempo de explicaciones, tiempo de charlatanes

Creo que a nadie le quedará duda de que este tema cuenta con la capacidad de hacer explotar a todos los cerebros que pasen por ahí por casualidad, intentando comprender sin sólidos fundamentos.

Mucha gente ha realizado honestos y valientes intentos por explicar la cuántica en términos que el resto de nosotros pueda entender. Pero la complejidad del tema es todavía superior a explicar por qué una excepción, una interrupción y una llamada al sistema se implementan de la misma manera a alguien que nunca ha escuchado hablar de la Máquina de Turing o, ya que el buen Padre del Cómputo hizo su aparición materializándose en mi párrafo, explicar la diferencia entre una verdadera prueba de Turing y todas las marometas publicitarias que se han realizado en los últimos años para “demostrar” que hemos alcanzado a la Inteligencia Artificial por medio de chatbots superinteligentes.

¿Quién no se ha reído con cierta sorna de imaginar cómo un científico serio puede tragarse el planteamiento del Gato de Schrödinger como ejemplo de los efectos cuánticos? ¿Existen los gatos simultáneamente vivos y muertos? No, obviamente no. Claro, comprenderíamos mejor la situación si partiéramos de que Erwin Schrödinger, científico suficientemente serio como para ser —como sus colegas antes mencionados— merecedor del Nobel, lo presentó como tan sólo un párrafo bien perdido a la mitad de un interesante artículo que contrasta los principios de las mecánicas clásicas y cuánticas. Y el párrafo comienza diciendo, «podríamos incluso considerar casos ridículos…» — No, señores, don Erwin no era un científico loco que jugaba con las catorce vidas medias de su pobre gato. ¿Y Einstein, opinando acerca de si Dios juega a los dados? Otra distorsión popular…

Claro, por ese camino puede seguirse ad insaniam. ¿Recuerdan la muy popularizada película de misticismo cuántico, «¿¡Y tú qué sabes!?», éxito de taquilla mundial? ¿Han visto los anuncios de estudios médicos basados en la resonancia cuántica, que por un muy módico precio son capaces de curar cáncer, diabetes y demás dolencias? Y, y…. bueno, ejemplos hay tantos que no me atrevo a seguir. No. Eso no es la cuántica.

¿Y el cómputo cuántico?

Volvamos, pues a los terrenos donde tanto ustedes como yo nos sentimos más cómodos, en los cuales me atrevo a decir un par de líneas. Cuando hablamos de cómputo cuántico, nos referimos particularmente a aprovechar una característica muy particular de la mecánica cuántica: el entrelazamiento cuántico (quantum entanglement).

La explicación del cómputo cuántico normalmente inicia diciendo que un qubit es un bit cuántico, y que puede ser simultáneamente falso y verdadero. Bueno… olviden eso, sólo por un par de minutos. No es que sea falso, pero creo que tiende a confundir más de lo que explica. El chiste de una computadora cuántica radica en que, si se logra vincular y mantener coherente el estado de un grupo suficientemente grande de partículas, puede explorarse un espacio combinatorio grandísimo sin emplear una sola comparación condicional.

Como comentábamos hace algunos párrafos, a las partículas no les gusta ser observadas; cualquier interferencia que hagamos sobre un sistema cuántico lo obliga a colapsar a uno de los estados posibles. Claro… El chiste es obligarlo a colapsar al estado correcto: Se puede establecer la configuración del sistema con entrelazamiento cuántico para que sólo colapse con la solución que describa a la programación que se le pidió al sistema.

El cómputo cuántico es, al mismo tiempo (¡y en superposición! Jajajaj, ¡soy un genio del humor!) nuestro terror y nuestra esperanza. ¿Y qué tiene de real?

En primer lugar, es absolutamente real. Desde los primeros planteamientos teóricos de qué significaría el cómputo cuántico (hace cosa de 40 años) los avances han sido impresionantes. Hoy en día hay algunas decenas de computadoras cuánticas; D-Wave es una empresa que se dedica primordialmente al cómputo cuántico, y tiene dos modelos que se comercializan. Su modelo cuántico es débil, no presenta un buen entrelazamiento, por lo cual no se consideran verdaderamente computadoras cuánticas (no son capaces de ejecutar los algoritmos diseñados para éstas). Google, IBM y Microsoft diseñan hardware a la medida, logrando el entrelazamiento de ya varias decenas de átomos.

En segundo lugar, sin embargo, si bien el cómputo cuántico es real y va creciendo, es altamente improbable que lo veamos salir de entornos muy controlados. Los procesadores cuánticos, para exhibir las propiedades que nos interesan, deben mantenerse apenas unos grados por sobre el cero absoluto. Hoy en día, dos de los principales retos son las técnicas para operar en presencia de los niveles de errores que necesariamente resultan muy caras (típicamente duplicando, cuando menos, el número de qubits requerido para cualquier operación), y la dificultad para entrelazar qubits adicionales — y mantenerlos en un estado coherente el tiempo necesario para realizar el algoritmo requerido sin que colapsen prematuramente.

Hay entre los especialistas una cantidad considerable de escépticos de que la computación cuántica para fines prácticos vaya a ser posible. Hay, claro, un grandísimo impulso e inversión al desarrollo de la tecnología requerida. Desde hace veinte años, cuelga sobre nosotros la advertencia de que entre cinco y diez años se logrará la supremacía cuántica (esto es, se logrará diseñar una computadora cuántica rival en velocidad a las computadoras normales). No nos queda más que comprender el modelo… Y esperar, ya sea a que se logre o a que no. Mientras tanto, toca aprender qué conlleva el modelo, entrelazados en un estado habrá-no habrá.

De event-stream, npm, y Arquitecturas que Invitan al Desastre

Ivett Sanchez — Tue, 15 Jan 2019 18:48:07 +0000

De event-stream, npm, y Arquitecturas que Invitan al Desastre

Ivett Sanchez Tue, 01/15/2019 - 12:48

Publicado en

SG #58

Columna invitada

Autor

Gunnar Wolf

En los últimos días de noviembre pasado se dio a conocer una noticia que armó revuelo — Y cuya intersección me atañe e interesa mucho en lo personal: Seguridad informática, software libre, integración de proyectos libres, arquitecturas de gestión de paquetes, mecanismos de compilación y distribución… Cuando me invitaron a participar con este texto adicionalmente a mi columna habitual, lo primero que pensé es, "¿cómo no escribí mi columna con ese tema? ¿Será que ya lo anticipábamos tanto que no me resultó de suficiente importancia?"

Y es que tiene mucho, muchísimo tiempo que venimos anticipando que esto ocurra. Y ha ocurrido, aunque de formas menos graves.

¿Qué pasó con event-stream?

Con este texto no busco reportar de forma ágil y oportuna, sino que hacer un pequeño análisis sobre las causas, y algunas recomendaciones para evitar que casos como este se repitan. El tema fue ya cubierto oportunamente por SG Buzz [1] al muy poco tiempo de reportarse. Hay, además, un análisis mucho más completo en LWN.net [2]. Para quien quiera ver detalles mucho más finos, Zach Schneider presentó en su blog personal otro artículo [3] incluyendo un desglose técnico de cómo se realizó el ataque. Me salto, pues, tanto de los detalles como me es posible.

Así que, resumiendo tremendamente: event-stream es una biblioteca de Javascript, muy frecuentemente utilizada para la manipulación de flujos (streams) de datos en aplicaciones basadas en Node. Si bien es una biblioteca que goza de muy alta popularidad, como frecuentemente pasa, su desarrollador original fue perdiendo motivación para desarrollarla, indicando que "ya ni siquiera la utilizaba". Esto es muy comprensible: A lo largo de los ocho años de vida que tiene este proyecto, ¿cómo se le puede exigir a una persona comprometerse a mantener los mismos intereses y proyectos de vida?

En septiembre de 2018, un usuario con alias right9ctrl solicitó al autor de event-stream el convertirse en su nuevo mantenedor. Esto ocurre todo el tiempo en distintos proyectos. Este nuevo mantenedor inició con un muy buen ritmo de actividad, subió nuevas versiones. Como es frecuente, una de esas nuevas versiones incluía una dependencia sobre una nueva biblioteca — flatmap-stream. Esta biblioteca contiene código legítimo y válido, lo único que podría llamar la atención al respecto es que no tenía ninguna instalación previa a su inclusión — Pero no resulta incomprensible que un desarrollador intente modularizar más su código, separando alguna funcionalidad para poderla utilizar sin depender de todo el código…

Hasta aquí todo bien. Ahora, flatmap-stream se distribuía tanto en el formato fuente, como minificada. ¿Qué es esto? Dado que el código Javascript muy frecuentemente se transmite a clientes Web (sean éstos navegadores, aplicaciones celulares, o incluso aplicaciones nativas en diversos entornos de escritorio), se busca que la descarga sea tan corta y ágil como sea posible. La minificación es, a fines prácticos, una compilación hacia el mismo lenguaje: Elimina todos los comentarios, todo el espacio en blanco, y reemplaza los nombres descriptivos de funciones y variables por el más corto posible. El código minificado, si bien semánticamente idéntico al código fuente, no puede considerarse modificable o, siquiera, legible por otra persona.

La estrategia de nuestro inteligente atacante, pues, fue no incluir nada malicioso en el código fuente, pero sí lo hizo en la versión minificada. Y otro punto importante: ¿Qué es lo que buscaba atacar? No era al grueso de usuarios de event-stream… Su uso es demasiado genérico. Sin embargo, identificó a una aplicación en particular que tiene a event-stream entre sus dependencias: copay-dash, un gestor de billeteras de criptomonedas.

Habiendo leído esto último, estoy seguro de que, como decimos en México, ya les cayó el veinte respecto el efecto de este ataque: Lo que logra es transferir el control de la billetera que tenga el desafortunado usuario que corra el código malicioso a right9ctrl.

¡Ah! Y un punto importante, específico a la cultura de desarrollo de npm: La búsqueda de un punto vulnerable en una aplicación relacionada con manejo de billeteras… Puede no haber sido tan difícil. El La cultura de npm apunta a que se empaqueten como biblioteca independientes pedacitos incluso triviales de cinco o diez líneas de código. Es imposible que un sólo desarrollador controle el conjunto de dependencias de ese proyecto: copay-dash incluye… ¡1277 dependencias de 378 mantenedores diferentes!4

¿Cómo podría haberse evitado?

Los usuarios afectados no pidieron actualizar manualmente las dependencias de sus sistemas. Esto se debe a la cultura de moverse rápido y romper cosas que ha sido conscientemente adoptada por la comunidad de desarrolladores de Node, particularmente por conducto de su gestor de paquetes, npm. Este gestor busca ofrecerle a los desarrolladores siempre las últimas versiones disponibles de todas sus bibliotecas, actualizándolas automáticamente desde fuentes sin relación explícita de confianza entre sí, hospedadas en cualquier lugar de la red, y bastando con el mero hecho de listarlos en un registro central. La página de npm5 dice ser el registro de software más grande del mundo, con más de 800,000 bloques de construcción (módulos independientes).

El blog de Schneider sugiere como primer medida de mitigación a este tipo de ataques el uso de lock-files. Estos no son archivos de bloqueo en el sentido del control de escritura concurrente a archivos — Son archivos que, en vez de permitir que npm actualice automáticamente, especifiquen la versión específica que requieren de cada biblioteca. Esta estrategia es frecuentemente utilizada con gestores de paquetes específicos a lenguaje, e incluso tiene soporte en npm mismo, pero relativamente poca gente lo usa al ser antitético a la citada cultura de moverse rápido.

Esa recomendación, me parece, es una buena mitigación — Pero no previene ni cura el problema. Mi recomendación se aleja un par de pasos de la gratificación instantántea que brindan los gestores de paquetes específicos a lenguaje (npm para Node/Javascript, Gems para Ruby, Pip para Python, etcétera.

Una visión consistente, coherente, completa del sistema

En lo particular, abrevo mis prácticas de la cultura de las distribuciones de Linux, en particular de Debian. Desde hace varios años he defendido las ventajas de la filosofía de empaquetamiento a nivel sistema: Si bien tiene sentido que un desarrollador tenga las últimas versiones de las bibliotecas que emplea y conozca los detalles de su funcionamiento, no puede esperarse lo mismo de los usuarios finales de una herramienta.

Si estoy instalando un paquete determinado para gestionar mi billetera Bitcoin (o para cualquier otra cosa), no debería siquiera importarme en qué lenguaje está escrito, y mucho menos si la voy a instalar utilizando una u otra infraestructuras de empaquetamiento. La mayor parte de los usuarios están intersados en resolver su problema desde una única interfaz de gestión de software. De acuerdo, en el caso deNode, muchas de sus aplicaciones están pensadas para instalarse de forma centralizada, en un servidor, por un administrador de sistemas y no un usuario final. Aún así — Si se espera que dicho administrador emplee el desarrollo (en contraposición a utilizarlo como base para un desarrollo adicional), ¿para qué obligarlo a aprender otra idiosincracia más, otra manera más de gestionar un pequeño pedacito del sistema?

Por el trabajo que realizo con Debian, desde hace más de una década he venido lamentando el abandono de la consistencia y coherencia a nivel sistema que caracteriza a dicha distribución, y al uso de Linux en general. Uno de los principales puntos que me atrajo hacia Debian hace ya muchos ayeres es conocer y enamorarme de su documento de políticas del sistema: Todos los paquetes que forman parte del sistema siguen una lógica común; el usuario sabe de antemano dónde está cada archivo de configuración, datos, programas, y se cumple un conjunto de expectativas que permiten el uso de un entorno operativo plenamente integrado.

Insisto — Un sistema empaquetado como lo presenta una distribución completa no busca reemplazar, ni lograría hacerlo con la oportunidad y agilidad necesarias, a los sistemas de paquetes por lenguaje. Éstos son el vehículo correcto para el desarrollador, para quien tiene que estar permanentemente en lo último — y sin filtros que exijan un nivel mínimo de madurez en cada uno de los componentes. Pero no podemos esperar que la respuesta sea la misma para los usuarios finales de nuestros desarrollos: Para ellos, estabilidad y predictibilidad valen muchísimo más.

A lo largo de las décadas en que se ha desarrollado el movimiento de software libre, han existido unos cuantos casos de software "troyanizado" de diferentes maneras, como event-stream, el caso que aquí nos ocupa. Afortunadamente, han sido pocos, y su impacto negativo mayormente ha logrado contenerse. Sin embargo, con la masificación del uso de los sistemas de empaquetamiento de modelos más ágiles y orientados naturalmente a desarrolladores más que a usuarios, como npm, muchos usuarios están quedando expuestos a este tipo de ataques.

Está en todos nosotros, como profesionales del ramo, racionalizar el uso de estas herramientas y contribuir con una cultura de seguridad informática en todo el mundo.

Referencias

SG Buzz: Crónica de la inyección de código malicioso a biblioteca de JavaScript https://sg.com.mx/buzz/cronica-de-la-inyeccion-de-codigo-malicioso-biblioteca-de-javascript
LWN.net: event-stream, npm, and trust https://lwn.net/Articles/773121/
Zach Schneider: event-stream vulnerability explained https://schneid.io/blog/event-stream-vulnerability-explained/
NPMGraph, http://npm.broofa.com/?q=copay-dash

Privacidad y Anonimato en Redes: ¿y la sociedad?

Ivett Sanchez — Mon, 03 Sep 2018 01:04:02 +0000

Privacidad y Anonimato en Redes: ¿y la sociedad?

Ivett Sanchez Sun, 09/02/2018 - 20:04

Publicado en

SG #57

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Esta es la tercera columna de una pequeña “serie” en que, desde distintos ángulos, les presento algunas reflexiones respecto a la privacidad en la red, o como lo presento en relación al proyecto UNAM/DGAPA/PAPIME PE102718 que estoy desarrollando, los mecanismos de privacidad y anonimato en redes.

En el número 55 de Software Gurú expuse cómo la sociedad asumía y reaccionaba al hecho de estar sometida a una vigilancia cada vez más profunda y constante, y cómo esta reacción ha ido mutando al pasar los años. En el número 56, expuse brevemente el funcionamiento de la red Tor, principal tecnología de anonimato empleada a nivel mundial.

Toca ahora levantar nuestra mirada de nuestras computadoras: ¿Cómo se inserta esto en la sociedad? ¿Qué necesidades verdaderas hay? ¿Quién puede aprovecharlo? Y más aún: Sostener una red de anonimato requiere de gran talento y de amplios recursos. ¿Quién está interesado en invertir sus recursos (intelectuales, económicos o de cualquier índole) para implementarla y sustentarla?

¿Quién se anonimiza?

¿Por qué tanto interés en promover tecnologías que permiten el anonimato en línea? ¿Qué tipo de usuario puede beneficiarse de estas redes?

Es difícil responder a estas preguntas. Si pudiera perfilarse de una forma clara cuál es el perfil principal de usuarios de una red de anonimato… ¡El sólo hecho de utilizarla nos identificaría! No tendríamos siquiera que sostener comunicaciones sensibles: Bastaría conectarnos a dicha red para revelar información acerca de nuestra demografía.

Las redes anonimizadoras superpuestas a Internet requieren, por tanto, de una masa crítica. Es imposible lograr el anonimato entre unos pocos; redes como Tor requieren de la participación masiva de usuarios diversos. Y, más allá del resumido texto que alcanzo a cubrir en esta sección, sugiero al lector interesado dirigirse a la página ¿Quién usa Tor? [1]

A mucha gente le sorprende saber que la ya mencionada red Tor fue creada inicialmente con participación y fondeo militares. El primer grupo objetivo de usuarios era el ejército de los Estados Unidos — Si lo piensan bien, resulta natural. Un ejército que, de formas más oficiales o más ocultas, está esparcido por todo el mundo y rutinariamente requiere de mantener comunicaciones de naturaleza altamente secreta, empleando infraestructura potencialmente enemiga… ¿No resulta natural que requieran de la protección que brinda el anonimato?

Uno de los perfiles de usuario que más fácilmente nos vienen a la mente son los periodistas. Es tristemente ampliamente sabido que México se ha convertido en el país sin guerra declarada más peligroso para los periodistas en el mundo; la organización internacional Artículo 19 documenta a 116 casos desde el año 2000 [2]. Si bien en el día a día los periodistas firman sus notas, para casos especialmente sensibles y para la etapa de investigación puede resultar literalmente de vida o muerte poder ir armando un expediente o entregándolo al medio que lo difundirá empleando mecanismos de anonimato.

La situación se presenta similar para los activistas de derechos humanos, organizaciones sociales, e incluso agrupaciones políticas. Escribo esta columna algunos días antes de las elecciones nacionales, y una noticia que retumba de forma recurrente es que 121 aspirantes a algún puesto de elección han sido asesinados este año. Claro, un político requiere dar a conocer su persona, sus planteamientos ante la sociedad… Pero muchas veces, las razones para atacarlos vienen del espionaje de la comunicación privada que sostienen.

Dejando de lado los casos de ocultamiento y violencia extrema… Vamos a nuestra ocupación habitual. ¿Alguna vez se han preguntado si el sitio realmente funciona cuando es accedido desde fuera de nuestra red? ¿O si las reglas del firewall están correctamente escritas? ¿Si algún filtro que configuramos en nuestros servicios para brindar contenido diferenciado según el país de origen de la solicitud funciona correctamente? Todos estos son casos de uso habituales para la red Tor.

Como usuario individual sin ninguna particularidad o distinción: ¿Sospecho de algún tipo de censura por parte de mi proveedor de Internet? ¿Me conecto desde alguna red con políticas restrictivas, y obtener autorización para determinado recurso resulta engorroso o difícil? ¿O simplemente me molesta estar bajo la siempre vigilante mirada de los mercadólogos que controlan nuestra “experiencia”' de navegación?

Hay muchísimos posibles casos de uso. Claro, lo que los amarillistas quieren hacernos creer es que las redes de anonimato constituyen una red obscura paralela, la temible Dark Web, llena de amenazas y gente mala. Y, sí, hay quien usa a estas tecnologías para fines nefastos —pero no se ha demostrado que sea una mayor proporción que como ocurre en las redes abiertas.

¿Quién te anonimiza?

Hablemos de la contraparte: Como mencionamos en la sección anterior, una red de anonimato requiere de la participación de mucha gente — A mayor cantidad de participantes, más difícil resulta romper el anonimato, y mayor protección brinda una red a cada uno de sus usuarios.

Pero una red de anonimato no se construye únicamente con sus usuarios. Requiere en primer lugar, como casi todos los proyectos que podamos mencionar en esta columna, de quien realice la implementación tecnológica —y requiere de una gran cantidad de recursos sostenidos a lo largo de los años. Requiere de gente dispuesta a compartir su ancho de banda, su tiempo de cómputo.

Vamos primero sobre del primer punto: ¿Quién implementa las redes de anonimato?

Un vistazo rápido a los principales participantes de Tor [3] nos revela una riqueza que cualquier proyecto tecnológico desearía poder presumir: La participación femenina es en general muy baja en proyectos de cómputo, y sobre todo en proyectos de participación voluntaria (lo cual incluye a prácticamente todo el software libre), típicamente inferior al 10%. Pero en el caso de Tor aproximadamente la cuarta parte de los miembros son mujeres, y muy en particular, cabe destacar que tanto su directora ejecutiva actual (Isabela Bagueros) y anterior (Shari Steele) son mujeres. ¿Por qué Tor ha logrado acercarse tanto más que muchísimos otros proyectos al balance? No lo sé. Pero es un punto que no puedo dejar de enfatizar. A lo largo del último año, me he ido acercando a trabajar con esta comunidad, y tengo que reconocer que me sorprende lo acogedora que resulta a novatos e intermedios.

En segundo lugar, recursos de red: Cada uno de los poco más de 6,000 equipos por los cuales cruzan los paquetes de la red Tor son operados por voluntarios [4], donando un poquito de ancho de banda y de tiempo de cómputo. En general, quienes operamos un nodo intermedio (relay) nos acercamos a Tor por cualquiera de las razones mencionadas en la sección anterior, y nos pareció natural contribuir al igual que lo hacen tantos más; operar un relay es una actividad sencilla y sin riesgo legal alguno. Los operadores de relays somos personas tan diversas como pueden serlo los usuarios de esta red.

Unos 900 relays están configurados como nodos de salida. Estos nodos presentan un perfil mucho más comprometido, requieren de una infraestructura más estable y monitoreada, y sí requieren de que el operador esté atento (y se comprometa a actuar) ante reclamos de abuso.

¿Y qué haces tú?

En fin, esta serie de columnas merece cerrar con un llamado a la participación. Estimado lector, ¿te ha resultado interesante o atractivo el planteamiento que hago? Te invito a utilizar Tor, a unirte a la comunidad, y a participar en ella. Hace algunos párrafos hablé de lo inclusivo y balanceado que es el grupo —es cierto, pero hay grandes agujeros en su representatividad. El uso y la participación en Tor desde Latinoamérica es desproporcionadamente bajo.

He estado colaborando con la ONG Derechos Digitales [5]. Ellos están impulsando un proyecto para la creación de documentación y contenido en español, así como para la instalación de más relays y particularmente nodos de salida en la región. Extiendo, pues, la invitación a todos ustedes a considerar instalar uno. Es más —si me escriben a mi dirección de correo (gwolf@gwolf.org) y mientras me sea posible (tengo una cantidad limitada de equipos), ofrezco ir dando a cada uno de los interesados que se comprometa a mantener un nodo de tor un equipo de cómputo para que puedan hacerlo y la asesoría que me sea posible brindar.

Por último, este año se celebrará en nuestro país la reunión de desarrollo de Tor. Si bien esta es una reunión de trabajo, inmediatamente después de ella (4 y 5 de octubre) el grupo de trabajo que coordino está organizando un coloquio, en el Auditorio Sotero Prieto de la Facultad de Ingeniería (UNAM), con el tema de mecanismos de anonimización y privacidad en redes. Todos están bienvenidos.

Referencias

“Users of Tor”, Tor Project. https://www.torproject.org/about/torusers.html.en#normalusers
“Periodistas asesinados en México”, Artículo 19. https://articulo19.org/periodistasasesinados
“Core People”, Tor Project. https://www.torproject.org/about/corepeople.html.en
“Metrics”, Tor Project. https://metrics.torproject.org/networksize.html

Derechos Digitales. https://www.derechosdigitales.org

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM

Funcionamiento de una Red Anonimizadora: La red Tor

sg — Mon, 12 Mar 2018 05:09:58 +0000

Funcionamiento de una Red Anonimizadora: La red Tor

sg Sun, 03/11/2018 - 23:09

Publicado en

SG #56

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Ha pasado medio año desde que nos encontramos en la última columna, en el número 55 de Software Gurú. En dicha columna abordé algunos argumentos importantes relativos al tipo de vigilancia al cual estamos sometidos, tanto por gobiernos como por empresas particulares. Dejé varias ideas inconclusas, apuntando a que retomaría el tema.

Y, en efecto, hay mucho que retomar. Muchas cosas han ocurrido en los últimos meses, y hasta parecería que algunas de ellas se apresuraron a ocurrir en los días previos a la escritura de esta columna, para asegurarse que no se me olviden.

La columna anterior llevó como pieza central una cita del pensamiento de John Perry Barlow, uno de los soñadores que en primer término imaginó, y poco a poco ayudó a conformar y, como fundador de la Electronic Frontier Foundation, defender un conjunto de reglas de la interacción en línea cementadas en el respeto a las libertades individuales. Hay que subrayarlo — La fundación misma de la EFF, en 1990, resulta por sí misma tremendamente visionaria. El pasado 7 de febrero, después de una larga y muy interesante vida, Barlow falleció. Nos toca continuar imaginando y luchando por un ciberespacio libre, un espacio para la invención y el desarrollo de la humanidad.

Cerramos la columna anterior mencionando el arresto de Dmitry Bogatov, joven profesor de matemáticas y desarrollador de software libre en Rusia, por causas relacionadas con la operación de un nodo de salida de la red Tor, actividad que, de propio, no es ilegal en Rusia. Bogatov pasó arrestado diez meses. El 31 de enero fue puesto nuevamente en libertad parcial (con restricciones de movilidad fuera de su región). Desafortunadamente, esto no significa que el sistema judicial ruso comprendió la naturaleza de la red Tor. Menos de dos semanas más tarde, otro operador de un nodo de salida Tor, Dmitry Klepikov, fue arrestado. La movilización en medios y la presión internacional logradas tras el caso de Bogatov afortunadamente lograron que Klepikov fuera liberado 48 horas más tarde.

El tercer punto a recapitular es probablemente de mucho menor importancia en el gran esquema de las cosas, pero no puedo pasarlo por alto: Mencioné que estaba comenzando con los preparativos de un proyecto que me llevaría a profundizar más acerca de la privacidad y el anonimato. Me da mucho gusto reportarles que, en efecto, DGAPA-UNAM aceptó mi proyecto PE102718, con lo cual me comprometo a desarrollar por dos años los temas que en esta columna comienzo a arañar.

¿Cómo funciona la anonimización?

El principio básico bajo el cual opera Tor, la principal red de anonimización en Internet, es sencillo; fue presentado ya en 1981 por David Chaum, y si bien Tor es la más importante, hay varias otras redes construidas sobre este mismo fundamento.

Un conjunto de usuarios normales de Internet configuran sus computadoras como nodos de una red superpuesta. El anonimato que esta red pueda brindar depende, necesariamente, de que la cantidad de nodos sea suficiente para esconder al tráfico de un individuo entre la multitud de usuarios de esta red.

Cuando un usuario de Tor desea conectarse a la red, contacta como primer paso a los servidores de directorio, que le proveen un listado de nodos activos. De éstos nodos, el cliente de Tor elige a tres para el establecimiento de un circuito: Un nodo «guardia» (de entrada), un nodo intermedio, y un nodo de salida.

El cliente Tor tiene varios mecanismos locales para recibir la comunicación de programas variados — Puede ser un navegador cualquiera (si bien recomiendan fuertemente el uso de Tor Browser [1], pero también puede ser casi cualquier programa que se comunique sobre TCP/IP. Lo más frecuente es crear un túnel para la comunicación sobre Tor empleándolo como un Proxy SOCKS.

El cliente cifra a cada uno de los paquetes para su comunicación tres veces, con las llaves públicas de los tres nodos elegidos: Al nivel más interno, con la del nodo de salida; el resultante de esa operación, con la del nodo intermedio, y por último, lo hace con la del nodo guardia.

Cada uno de los paquetes que conforma determinada comunicación es entregado al nodo guardia. Éste sabe su ubicación en el circuito, por lo que podría revelar la identidad del usuario, pero desconoce el tráfico que está reenviando, sólo sabe que debe entregarlo a determinado nodo intermedio. El nodo intermedio no sabe nada respecto a la comunicación, únicamente la dirección de sus dos compañeros. Por último, el nodo de salida sabe a qué IP destino se dirige la conexión, y en caso de no estar ésta cifrada (por ejemplo, empleando HTTPS en vez de HTTP — ¡es importante preferir HTTPS incluso sobre redes anonimizadoras! [2]), puede conocer el contenido de la comunicación, pero no la dirección de donde ésta se originó.

A modo de ejemplo, la figura 1 presenta una captura de pantalla de mi visita a la página de Software Gurú: el servidor registró una visita proveniente de la IP alemana 94.130.183.184; dicha IP, del nodo fallbacksen, provino de nullstreet en Canadá, y ésta de Fission3 en Francia. Claro, esta conexión se originó en mi computadora de escritorio, en la ciudad de México. Naturalmente, esto tiene como efecto un fuerte aumento en la latencia. Si bien una medición seria tendría que hacerse entre cada uno de dichos puntos, estimando la latencia desde mi computadora en México suma unos 450 milisegundos a cada conexión.

Figura 1. Navegación anonimizada con Tor

A quienes acostumbran trabajar con redes de cómputo, puede resultarles chocante mi reiterado uso del término “circuitos”. ¿Qué no acaso las redes de cómputo nos liberaron de los circuitos, que se establecían en las viejas redes telefónicas punto a punto, resultando en una arquitectura más frágil y de menor rendimiento que nuestras actuales redes basadas en paquetes?

La red Tor hace esto para reducir la varianza en las comunicaciones y lograr una red de relativamente baja latencia, comparada con las verdaderas redes anonimizadoras basadas en paquetes. Al establecer cada circuito una sola vez, éste se mantiene estable a lo largo de una serie de conexiones IP relacionadas, evitando el costo de establecimiento de canal seguro paquete por paquete. Además, permiten que, a lo largo de una misma sesión, todas las conexiones de determinado usuario que llegan a cierto servidor parezcan originarse en el mismo punto — De no ser así, muchos sistemas rechazarían a dicha sesión.

La forma en que se eligen los nodos que atravesamos no es aleatoria; los circuitos construidos buscan evitar tocar puntos que compartan estructura general de ruteo (sistemas autónomos).

¿Qué sigue? El componente social

En la columna anterior presenté una argumentación general y, hasta cierto punto, anclada en mis vivencias personales respecto al avance del anonimato en línea a lo largo de los últimos 20 años. Esta columna presenta, muy a grandes rasgos, el funcionamiento de Tor, la principal red de anonimato. Pero queda pendiente un importante punto — El social. ¿Por qué fomentar redes de anonimato? ¿Qué casos de uso se encuentran en ellas que puedan ameritar dedicarle recursos y tiempo? Y, es más, ya que mencionamos los recursos: ¿Como puedo invitarlos a participar en ellas?

Abordaré dichos puntos en la próxima entrega de esta misma columna. ¡Hasta entonces!

Anotaciones

[1] El navegador Tor está basado en Firefox. Puedes leer más respecto a los fundamentos de diseño y los puntos particulares en que se diferencia en https://www.torproject.org/projects/torbrowser/design/

[2] En https://www.eff.org/pages/tor-and-https encontrarás un simple y claro diagrama interactivo que explica qué porción de nuestra información es protegida por HTTPS, qué porción es protegida por Tor, y por qué hay que usarlos a ambos cuando estos temas nos importan.

Independencia en el Ciberespacio

sg — Mon, 21 Aug 2017 19:37:51 +0000

Independencia en el Ciberespacio

sg Mon, 08/21/2017 - 14:37

Publicado en

SG #55

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Es de sobra conocido que la comunicación sobre redes de datos TCP/IP es fácil de espiar — El diseño de Internet desde sus inicios está enfocado a la confiabilidad, no a la privacidad, hecho que se hace obvio en sus protocolos a todos niveles. Esta es una realidad a la cual los usuarios de Internet nos hemos acostumbrado desde siempre.

La respuesta clásica se centró en el cifrado de las comunicaciones (usar secure shell en lugar de telnet, emplear https en vez de http, etc.) Esto, sí, lleva a que el contenido de las comunicaciones cuyos protocolos pueden ser cifrados se vuelvan inintelegibles para un adversario. Esta respuesta, tristemente, ha demostrado ser insuficiente por la profundidad y seriedad de cómo se ha configurado el modelo de adversario.

La sospecha de que las redes de telecomunicaciones (sean analógicas o digitales) sean utilizadas para el espionaje no es nada nuevo. A inicios de la década de los noventa, era frecuente que los jóvenes que enviábamos mensajes a través de las redes de BBSes (Bulletin Board Systems, sistemas de boletín electrónico, y de cierto modo antecesores de Internet para las comunicaciones personales) agregáramos al final de todos nuestros mensajes, como parte de nuestras firmas, líneas autogeneradas con palabras clave alineadas para la idiosincrasia contraterrorista del momento, por el estilo de «Bomb Lybia Arafat Plane Washington Kill President». Hacíamos esto, argumentábamos, porque el gobierno estadounidense analizaba todas nuestras conversaciones, primero efectuando un filtrado grueso y posteriormente haciendo trabajo a detalle; si incluíamos estos mensajes en todas nuestras comunicaciones, obligaríamos al filtrado grueso a reportar muchos falsos positivos, sobrecargando sus (mucho más valiosos) sistemas de filtrado fino. Hubo varios nombres clave que tuvo este espionaje en los años que a mí me tocó ser parte de la vanguardia que luchaba por proteger a nuestro amado ciberespacio, ese entorno que apasionadamente defendió John Perry Barlow (músico, poeta, ensayista, y uno de los primeros pensadores sociales que se dedicaron a analizar el significado de la red para la sociedad) en su Declaración de Independencia del Ciberespacio [1] en 1996. Cito el inicio de esta declaración, en traducción propia:

Gobiernos del Mundo Industrial, viejos gigantes de carne y acero, vengo del Ciberespacio, el nuevo hogar de la Mente. A nombre del futuro, les pido que nos dejen en paz. No son bienvenidos entre nosotros. No gozan de soberanía donde nos reunimos.

No tenemos un gobierno electo, y es poco probable que lleguemos a tenerlo, así que me dirijo a ustedes sin más autoridad que aquella con que siempre habla la libertad misma. Declaro que el espacio social global que estamos construyendo es naturalmente independiente de las tiranías que ustedes buscan imponernos. No tienen derecho moral de gobernarnos, ni poseen método alguno de coerción que tengamos alguna razón para temer.

Los gobiernos obtienen sus justos poderes del consentimiento de los gobernados. Ustedes no han ni solicitado ni recibido el nuestro. No los invitamos. No nos conocen, ni conocen nuestro mundo. El ciberespacio no yace dentro de sus fronteras. No piensen que pueden construirlo, cual si fuera un proyecto de construcción pública. No pueden. Es un acto de la naturaleza, y se crece a sí mismo mediante nuestras acciones colectivas.

Hace veinte años, este escrito resonó muy fuertemente con todos nosotros, quienes llevábamos cinco, diez, veinte años creando nuevos medios de comunicación con la tecnología y los recursos que teníamos a nuestra disposición; la variedad tecnológica en esa época era impresionante, y había espacio para la participación de todo tipo de perfiles… Siempre alineados a lo que con el tiempo dio en conocerse como la ética hacker.

Pero me estoy yendo por las ramas hacia un tema del cual se puede hablar mucho más, y del cual disfruto mucho rememorar y escribir. A los interesados en esta temática, puedo recomendarles el libro publicado el año pasado por la Universidad del Claustro de Sor Juana, «Ética hacker, seguridad y vigilancia» [2], en el que tuve el honor de participar con un capítulo.

Aterricemos: Hace veinte años, lo que sabíamos al respecto eran meras suposiciones. Claro está, las telecomunicaciones internacionales estaban a un nivel incomparable de donde están ahora; las llamadas telefónicas internacionales eran carísimas, y las comunicaciones digitales estaban al alcance de un porcentaje risible de la población. Si en esa época dedicáramos nuestro tiempo real de trabajo, o espacio en una revista como Software Gurú, a hablar de la vigilancia generalizada… Se nos tacharía indudablemente de "conspiranóicos".

Este tema no es del todo nuevo en nuestra revista: En esta misma columna, escribí ya al respecto en los números 32 (mayo de 2011) y 42 (noviembre de 2013).

Desde las primeras revelaciones de Wikileaks, parte muy importante de las filtraciones de alto nivel que se han presentado son relativas a la profundidad del espionaje que se realiza de forma indiscriminada. Vemos por un lado acuerdos entre agencias de seguridad de diferentes gobiernos y conjuntos de puertas traseras en software de uso generalizado que se mantienen por años ocultamente escondidos por las mismas, y por el otro la proliferación de técnicas analíticas a profundidad, sustentadas en el indefinible Big Data, en manos de particulares.

Cabe mencionar, los marcos regulatorios que norman el funcionamiento de las citadas agencias de seguridad nacional se mantienen firme y convenientemente anclados en su anticuado lugar, hace cuando menos veinte años. Por ejemplo, ante la restricción de que el gobierno estadounidense no debe espiar la comunicación entre sus ciudadanos, analizar conexiones de red que se mantengan dentro de sus fronteras se vuelve complicado. Bueno, recientemente salió a la luz que la NSA efectúa ataques de ruteo BGP (Border Gateway Protocol, empleado para el ruteo a gran escala, entre los llamados Sistemas Autónomos) — "Empuja" las rutas de algunos paquetes para pasar por conexiones fuera de los Estados Unidos, facilitando el marco regulatorio dentro del cual pueden operar. Esto, volviendo al punto mencionado al inicio de esta columna, es posible porque BGP está diseñado para confiar; cualquier sistema autónomo puede indicar que es mejor o peor candidato que sus vecinos para determinadas rutas.

Hasta cierto punto, la respuesta de la sociedad ha cambiado. ¿Para bien? No me atrevo a afirmarlo ni rechazarlo categóricamente: Ya no se burlan de quienes hablamos de un espionaje a gran escala etiquetándonos como conspiranóicos con sombreros de papel aluminio… Pero, bajo el credo de que "la privacidad ha muerto, ya supérenlo", se le resta importancia y se relega a segundo término. Después de todo, ¿por qué habríamos de escondernos de empresas que mediante la analítica de Big Data nos entregan la información que nos importa, así sea publicidad enfocada o noticias que encajan con nuestra ideología, buscando mantenernos como fieles seguidores de sus sitios? Y… ¿los gobiernos? Bueno, si no tengo nada que esconder, ¿qué tengo que temer?

Afortunadamente, existen muchas herramientas cuyo uso puede llevarnos a dejar un rastro mucho menos seguible en la red; la más popular de ellas tal vez sea la Red Tor, una serie de nodos provistos por voluntarios en todo el mundo que proveen una malla de anonimización mediante ocultamiento criptográfico. El funcionamiento de Tor es verdaderamente sencillo, y espero abordarlo en una posterior entrega, y parte importante del esfuerzo del proyecto que la sustenta se ha enfocado en llevar a la Red Tor a quien la necesite, desarrollando herramientas para su usabilidad sin requerir de avanzados conocimientos técnicos.

Sé que dejo esta columna aparentemente inconclusa. Estoy iniciando con un proyecto que me llevará a trabajar el tema a mayor profundidad; retomaré esta temática en la próxima edición, profundizando en Tor y en cómo los usuarios de distintos niveles técnicos pueden aprovecharlo.

No quiero cerrar esta entrega sin mencionar el caso de Dmitry Bogatov, un jóven maestro universitario de matemáticas, activista y desarrollador de software libre, participante al igual que yo del proyecto Debian. Dmitry fue acusado de publicar material subversivo extremista en Internet, aunque está demostrado que no pudo haberlo hecho; es muy creíble que su acusación esté más bien relacionada con que operaba un nodo de salida de Tor. Dmitry fue encarcelado el pasado diez de abril, y hasta el momento de entrega de mi columna, no ha habido avance real en su proceso. Desde esta modesta trinchera, y con la poca influencia que una publicación tecnológica en México pueda tener, los invito a visitar el sitio Web https://freebogatov.org/en/ para enterarse de más detalles del caso y, en caso de que lo juzguen correcto, apoyar al caso.

Referencias

Construcciones Reproducibles

ana2lp — Wed, 03 May 2017 06:15:52 +0000

Construcciones Reproducibles

ana2lp Wed, 05/03/2017 - 01:15

Publicado en

SG #54

Programar es un Estilo de Vida

Autor

Gunnar Wolf

El premio Turing [1] de 1983 fue otorgado a Ken Thompson y Dennis Ritchie por «su desarrollo de la teoría genérica de los sistemas operativos, y específicamente, por la implementación del sistema operativo Unix». Su discurso de aceptación del premio, «Reflections on Trusting Trust» [2] (pensamientos acerca de confiar en la confianza) ha sido uno de los pilares de la práctica de la seguridad informática.

En dicho trabajo, Thompson sostiene que mientras haya gente como él, capaces de escribir un compilador a pelo, no podremos confiar auditoría alguna que hagamos a nuestro código —su artículo demuestra cómo se puede troyanizar un compilador para ocultar en él comportamiento maligno que sólo se dispara al compilar un programa determinado— o al compilar a una nueva copia del compilador mismo.

Si bien ya ha llovido en los más de treinta años que han transcurrido desde este artículo [3] el principal argumento de Ken Thompson se sostiene: en el supuesto de que hagamos una auditoría al código de determinado proyecto, ¿qué garantiza que ese sea el código que realmente ejecuta el despliegue productivo?

El planteamiento que hago no tiene nada de hipotético, y seguramente muchos de ustedes podrán encontrar ejemplos de código que no concuerda a detalle con el que pasó un proceso de certificación; parte del papel de quien audite y certifique un sistema debe ser una forma de asegurar que el software estudiado sea efectivamente el empleado.

El ecosistema de las distribuciones de software libre

Conviene mencionar, pues, el punto de partida del proyecto del cual voy a hablar en esta columna. El proyecto de Construcciones Reproducibles [4] nace de la inquietud de un grupo de desarrolladores de software libre, en un principio mayormente desarrolladores de la distribución de Linux Debian.

Debian es uno de los proyectos de software libre más grandes y longevos que hay que sigue llevándose a cabo como hace veinte años: como un esfuerzo comunitario, colaborativo; como la suma de miles de pequeñas contribuciones personales. No existe una compañía detrás de Debian, y todos quienes participamos en su desarrollo lo hacemos como voluntarios y a título personal.

Esto puede verse tanto como una ventaja (el soporte para cada una de las ideas que forman parte del proyecto depende del interés de un individuo, no hay una decisión corporativa que pueda "matar" ideas que no generen ingresos) como una desventaja (al depositar la confianza de nuestra infraestructura en un proyecto tan profundamente descentralizado, estamos confiando en cada uno de los individuos involucrados). Y las Construcciones Reproducibles nacen como respuesta a esta desventaja.

La principal garantía de funcionamiento no-malicioso que ofrecen los proyectos de software libre a sus usuarios es que, dado que el código fuente está disponible, cualquier usuario preocupado de que su sistema pueda estar de alguna manera troyanizado o capturando y reportando datos sin su autorización puede inspeccionar el código fuente de los programas que emplea y compilarlos. Como dicen, ¡pare de sufrir! Sin embargo… esta solución no escala.

Hay distribuciones de Linux, como Gentoo o Arch, que basan su modelo de operación únicamente en la distribución de fuentes, y cada uno de los usuarios compila los paquetes al instalarlos. Estas distribuciones gozan del favor de los usuarios con inclinaciones más técnicas, pero si bien ganan en flexibilidad, resultan imprácticas para su uso en producción para la mayor parte de los operadores. La mayor parte de las distribuciones opta por la distribución de binarios, paquetes precompilados, con información para una resolución automática de dependencias.

Todas las distribuciones de Linux hoy en día proporcionan repositorios de software con verificaciones criptográficas fuertes, asegurando que éste fue construido en el sistema que sus políticas de desarrollo depositen su confianza. Para muchos, y por muchos años, eso ha sido suficiente.

¡No es para que confíen en mí!

Sin embargo, en junio de 2013, Mike Perry (desarrollador de la red anonimizadora Tor [5] pasó dos meses afinando el navegador derivado de Firefox que emplea Tor para que, si se compila dos veces, el resultado sea idéntico bit por bit. Al explicar su motivación para hacer esto, envió un mensaje [6] del cual traduzco y reproduzco porciones a continuación:

No pasé seis semanas logrando una construcción reproducible para demostrar que soy honesto o confiable. Lo hice porque no creo que los modelos de desarrollo de software basados en la confianza a una única persona puedan estar seguros contra adversarios serios.

Los últimos años hemos visto un sostenido crecimiento en el (…) uso de explotación de software por múltiples gobiernos. (…)

Esto significa que el desarrollo de software debe evolucionar más allá del "confía en el repositorio firmado por GPG de mi máquina confiable". (…) Aquí es donde las construcciones reproducibles entran en juego: cualquier individuo puede usar nuestra red de anonimato, bajar nuestro código fuente, verificar ante una serie de repositorios públicos, firmados, auditados y replicados, y reproducir nuestra construcción exactamente, asegurándose no ser víctima de tales ataques dirigidos.

Hay antecedentes previos, pero este es el primer esfuerzo serio y dedicado para lograrlo; quien esté familiarizado con la red Tor comprenderá la importancia que históricamente han dado a una fuerte protección al anonimato mediante herramientas técnicas apropiadas. Perry puso el tema sobre la mesa, y pocos meses más tarde, Jérémy Bobbio comenzó a explorar lo que haría falta para aplicar las modificaciones y principios que Perry fue descubriendo y documentando al repositorio Debian —formado por cerca de 25,000 paquetes independientes.

El trabajo iniciado por Jérémy demostró resonar en la mente de diversos desarrolladores interesados en la seguridad. El proyecto aceleró velozmente, y dos años más tarde habían ya logrado una amplia concientización respecto al problema y lograr la construcción de la mayoría del archivo; participantes de otros proyectos de software libre comenzaron a verlo con interés, y a fines de 2015 celebraron un primer congreso en Atenas.

Si bien Debian es el proyecto con mayor avance, al día de hoy están trabajando en conjunto con Coreboot, OpenWRT, NetBSD, FreeBSD, Archlinux y Fedora. En consonancia con el tema de este número de Software Gurú, pueden ver en la herramienta de integración continua [7] el impresionante grado de avance que han logrado: Al momento de escribir este artículo, más del 93% de los paquetes de la próxima versión estable de Debian logra una construcción reproducible; apenas hace un año y medio la meta era llegar a un 80%.

¿Y dónde radica el problema?

Muchos de ustedes recordarán sus años formativos, y puede que cueste un poco ver el problema. Estamos hablando de la compilación de software. Si yo tengo el mismo código fuente y lo compilo dos veces, ¿no debería obtener exactamente el mismo resultado? ¿Por qué este punto resulta problemático?

Hagan la prueba. Compilen su proyecto favorito. Guarden el resultado en un tar.gz (o en un zip, dependiendo de su sistema favorito). Salgan al patio, tómense un café, y vuelvan a hacerlo. Hagan un checksum sencillo de los archivos. Les garantizo que será diferente. Imaginen ahora hacerlo desde la computadora de un compañero de trabajo, o de arbitrariamente cualquier otra computadora en el mundo (que tenga el mismo compilador instalado).

Algunas de las fuentes de variación que el proyecto de construcciones reproducibles ha tenido que abordar son:

La hora y fecha de compilación
Algunas de las variables de entorno (TZ, LANG, USER, etc.)
El nombre del directorio desde donde se compila
El ordenamiento de los archivos que presenta el sistema de archivos subyacente
Nombre de la computadora
Versión del kernel
ID del usuario y grupo, permisos de sesión (p.ej. umask)

Claro, parte importante del trabajo ha radicado en identificar y aislar factores que llevan a que una construcción no sea reproducible; si el tema les interesa, los invito a probar la sorprendente herramienta diffoscope [8], que encuentra y presenta las diferencias entre dos archivos de entre un tipo impresionante de formatos.

En suma

El problema planteado por Thompson puede ampliarse, dada la realidad del mundo interconectado en el que vivimos, a que a un agente suficientemente poderoso le basta hacerse del control en una computadora (la de un desarrollador de software que trabaje dentro de una distribución de Linux, en nuestro ejemplo) para, desde ella, hacerse de privilegios elevados en millones de computadoras en todo el mundo. Las construcciones reproducibles harán evidente cuando un ataque de este tipo se dirija al producto binario.

Y no es que examinar a detalle el código fuente buscando código malicioso sea sencillo, pero… por lo menos, es posible hacerlo. Este proyecto plantea un fuerte cambio en el modelo de seguridad que ofrecen los proyectos de software libre, con el que todos los usuarios ganarán mucho mayor confianza en que el software que corren está efectivamente libre de código malicioso.

Referencias y notas

Al que comúnmente se hace referencia como el premio Nóbel de la computación
https://doi.org/10.1145/358198.358210
Para los interesados en el argumento académico, David A. Wheeler hizo su tesis doctoral en 2009 acerca de cómo «contrarrestar la confianza en la confianza mediante la doble compilación diversa», https://www.dwheeler.com/trusting-trust/
https://reproducible-builds.org/
https://torproject.org/
https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html
https://tests.reproducible-builds.org/
https://diffoscope.org/