Programar es un Estilo de Vida

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á.

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/

Inseguridades de IoT

ana2lp — Mon, 12 Dec 2016 21:15:49 +0000

Inseguridades de IoT

ana2lp Mon, 12/12/2016 - 15:15

Publicado en

SG #53

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Comienzo con la escritura de esta columna el 22 de octubre del 2016. Para quienes trabajamos en el campo de la seguridad informática el día de ayer fue particularmente intenso: Por un lado, nos enfrentamos con un tremendo ataque de denegación de servicio distribuido (DDoS) que dejó fuera de la red al proveedor de resolución de nombres Dyn DNS — con ello, a sitios del calibre de Twitter, Amazon, Whatsapp o Reddit. Y, por el otro, muchos administradores de sistema estuvimos atareados parchando nuestros sistemas por culpa de la “vaca sucia”, conocida formalmente como CVE-2016-5195, una vulnerabilidad de escalación de privilegios en el núcleo de Linux.

Si bien no hay más relación entre estos dos hechos que la casualidad de su fecha de publicación, es muy probable que su impacto a futuro se mantenga entrelazado.

Se ha hablado del internet de las cosas en muchos contextos, mayormente positivos, especulando con anticipación acerca de la forma que tomará el futuro de nuestro campo (tanto hacia adentro, a cómo los profesionales lo afrontamos; como hacia afuera, cómo será el impacto hacia los usuarios y la sociedad en general). Sin ir más lejos, el número 51 de Software Gurú fue dedicado íntegro a este tema.

Como en todo tema que especula acerca del futuro, siempre hay algún pesimista que le ve el lado tenebroso. En este caso, traigo a referencia un par de artículos recientemente escritos por Matthew Garrett:

En el primero de estos artículos [1], Matthew describe cómo –por mera curiosidad por ver lo que había conectado a un cable Ethernet en un hotel– pudo asumir el control de las lámparas y cortinas de todos los cuartos del hotel. El segundo [2] describe algunos ataques que lanzó contra focos inteligentes que compró para fines de mera investigación... pero que podrían volver locos a muchos usuarios menos involucrados en el tema que él.

¿A qué viene esto al caso?

El principal factor característico del ataque del 21 de octubre fue que provino de una botnet (red de equipos vulnerados, controlados por un mismo atacante) generada mediante el programa atacante Mirai, palabra que significa futuro en japonés. Mirai es un programa que busca y explota vulnerabilidades conocidas en las configuraciones por default de diversos sistemas del rango del Internet de las cosas — principalmente, cuentas abiertas por omisión. De hecho, el código fuente de Mirai está disponible en github [3].

Cabe mencionar que Mirai (cuyo código se hizo público varios días antes del ataque en cuestión), fue empleado también en el ataque al sitio Web del investigador en temas de seguridad informática Paul Krebs [4]. En ambos casos, la cantidad de tráfico generado rondaba los 600Gbps.

La forma en que Mirai obtiene control de los dispositivos es bastante sencilla y poco sofisticada. No se centra en aprovechar vulnerabilidades de validación de entradas, como la mayor parte de los gusanos; tampoco aprovecha mega-agujeros comunes, para los cuales se ha convertido en moda una publicación con todo y nombre y logotipo (piensen en Heartbleed para OpenSSL, Badlock para Windows y Samba, y el ya mencionado Dirty CoW para Linux). No, lo que hace Mirai es mucho menos sofisticado, ya que el grueso del ataque se centra en intentar autenticarse como administrador usando contraseñas comunes o predeterminadas (ej. admin/admin). La figura 1 muestra un pedazo del código de bot/scanner.c donde se aprecia esto.

Figura 1. Ejemplo de contraseñas que intenta usar Mirai.

Y es aquí donde realizamos la conexión con el maravilloso mundo del IoT ...

Al iniciar el diplomado de Linux en sistemas embebidos de la Facultad de Ingeniería en la UNAM, uno de los primeros temas que abordamos es, naturalmente, qué es un sistema embebido. Y, sin entrar en detalles y disquisiciones, uno de los principales criterios es que es un sistema en el que, independientemente del tamaño físico, la potencia de cálculo u otros factores; la principal función (esto es, la principal característica que se presenta al usuario) no es la de una computadora de propósito general y en su uso diario podemos incluso olvidarnos de la computadora que incluye. Posiblemente el usuario deba pasar por una fase de configuración, pero el dispositivo en su uso diario pasa inadvertido como parte de la funcionalidad provista por un aparato completamente distinto.

De este modo, por ejemplo, podríamos clasificar de sistema embebido a:

La compleja red de sensores y actuadores que hay dentro de un automóvil vendido en los últimos veinte años.
Se impone el ejemplo eterno de un refrigerador inteligente que facilite nuestra vida prediciendo lo que requerimos comprar o tirar (si bien la cantidad de estos dispositivos se mantiene en lo risible). Los refrigeradores inteligentes que he visto, sin embargo, se acercan al límite de esta definición, pues incorporan una pantalla con una instalación de un entorno Android completo.
Las cámaras de vigilancia y sistemas de portero automático controlables desde un teléfono celular (incluso si éste no está en la casa en cuestión).
Los sensores biométricos y asistentes de salud vestibles.
Los teléfonos VoIP, que ya se han convertido en la norma en entornos corporativos.
Los ya mencionados focos inteligentes y demás soluciones de automatización y centralización de mando en un edificio.

Y, claro, un universo de dispositivos que va creciendo imparablemente, y ya superan ampliamente a las computadoras de uso frontal. En esta lista no entrarían los dispositivos de cómputo móvil, como las tabletas y los celulares, pues para éstos, su principal función (muy por encima de la que hasta hace diez años era la primaria, mantener una conversación de voz entre dos participantes) es indefectiblemente proveer una interfaz de cómputo.

Una diferencia fundamental, de cierto modo implícita en la definición, radica en lo relativo a la flexibilidad del sistema: dado que no se trata de dispositivos de uso genérico, el conjunto de programas que ejecutan podría mantenerse estable a largo plazo. Los diseñadores del software que va a manejarlo buscan ofrecer un entorno estable y duradero… y no siempre consideran brindar funcionalidad para la actualización, ya sea por el espacio adicional que esto requeriría o por considerarlo como un factor que complica la vida del público objetivo.

Esto, claro está, no es nuevo. El mismo problema se presentaba hace diez o veinte años — Pero si los programas que controlan el funcionamiento de mi cámara digital (producida en 2005), proyector de video (del 2008) o impresora (una reliquia del 2001, todavía perfectamente funcional) tienen vulnerabilidades que los hacen susceptibles a que un atacante se apodere de su funcionamiento… ¿Cuál es el riesgo real? Dado que son equipos que no cuentan con ningún tipo de conexión a red, tan bajo que resulta despreciable.

Los dispositivos IoT dependen de una conexión a Internet, no para su función principal, pero sí para funcionalidad altamente deseable para el usuario. Cómo actualizar a estos dispositivos ante una vulnerabilidad es, por decir lo menos, un problema complejo — Si se hace de forma automática, los problemas en que incurriría su compañía en caso de que una actualización no funcionara correctamente no serían asunto nada menor.

Y… toca volver a las contraseñas. A pesar de que el usuario que busca expresamente equipos IoT probablemente pase al menos algunos minutos familiarizándose con su configuración, cambiando contraseñas y ajustando funcionalidad, la experiencia demuestra que una amplia proporción de usuarios simplemente enchufan el dispositivo y se olvidan de él o lo dejan con las configuraciones predeterminadas en aras de no tener que buscar los manuales a futuro.

Como profesionales del desarrollo de software, muy probablemente nos tocará diseñar sistemas que caigan en la definición del Internet de las Cosas. No podemos olvidar nuestra responsabilidad ante el mundo. Desplegar masivamente un sistema con contraseñas fijas (o incluso generadas algorítmicamente alrededor de un valor visible desde fuera, como la dirección MAC) es una invitación a que nuestros equipos sean víctimas de mal uso. No proveer interfaces confiables y bien probadas para la actualización es un pecado igualmente grave.

La usabilidad de Internet a futuro depende de cada uno de nosotros.

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org

Contenedores: Un poco de historia

sg — Wed, 12 Oct 2016 08:19:44 +0000

Contenedores: Un poco de historia

sg Wed, 10/12/2016 - 03:19

Publicado en

SG #52

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Recuerdo la primera vez que tuve contacto con la virtualización. En 2005, en un congreso, participé en un breve taller en el que nos presentaron esta (entonces) característica tan única de las arquitecturas IBM de gama alta: los servidores s390.

¡Parecía magia! Varios sistemas operativos corriendo a velocidad nativa, compartiendo armónicamente una misma computadora. Un hipervisor gestionando y mostrando estadísticas de uso en tiempo real. Claro, a esas alturas yo ya conocía el mecanismo que empleaba VMWare para virtualizar sobre la arquitectura PC desde fines de los noventa, pero la diferencia en el rendimiento y la confiabilidad era muy notoria. Por esos años, relativamente muy poca gente consideraba la oferta de VMWare para entornos de producción.

Un año más tarde, el panorama cambió radicalmente. Tanto Intel como AMD comenzaron a incorporar extensiones de virtualización en sus procesadores de arquitectura x86 —las instrucciones y niveles de protección necesarios para permitir este mágico aislamiento que hasta entonces estaba reservado a los sistemas de muy alto costo. Si bien la virtualización apareció primero en la gama alta de estas compañías, hoy en día (diez años más tarde) prácticamente todos sus procesadores las incluyen. Y sí, cambiaron fuertemente la forma de trabajo en los centros de datos, las ofertas de servicio de los proveedores de infraestructura— y permitieron el nacimiento del, permítanme esta redundante cacofonía, nebuloso término de "la nube".

Por un par de años, hubo un claro surgimiento de la “virtualización basada en hardware”. Proveedores de servicio de todo tamaño comenzaron a ofrecer “servidores privados virtuales” a precios que antes nunca hubiéramos esperado. Los administradores de sistemas de todo el mundo comenzamos a cambiar nuestra mecánica de trabajo, “particionando” el trabajo que realizaban nuestros grandes servidores monolíticos en cargas especializadas, a ser repartidas en cuantos servidores virtuales fuera necesario. No tardaron en aparecer numerosas tecnologías base, libres y propietarias.

De virtualización a paravirtualización

Quedaba aún mucho por mejorar, sin embargo, si bien la ejecución de código dentro de las máquinas virtuales ocurría ya a velocidad nativa, había inocultables capas de emulación que era necesario cruzar. ¿A qué me refiero? Una máquina virtual aparenta ser una computadora completa, al lanzar una, vemos cómo una interfaz comparable con el BIOS lanza al gestor de arranque, el sistema operativo se inicializa… la máquina virtual cree tener las tarjetas de red, unidades de disco y demás periféricos que le indiquemos (que normalmente corresponden con modelos simples y antiguos). El manejo del video es particularmente curioso; lo más común es que se presente como una tarjeta de video tonta, sin aceleración 3D, que interfacea mediante un framebuffer. Todos estos dispositivos tienen que ser emulados, y toda emulación tiene su costo.

Hoy en día, prácticamente la totalidad de herramientas de virtualización ofrece más bien un híbrido, entrando al terreno de la paravirtualización. ¿Qué es? Es cuando el engaño no es completo, cuando el hardware virtual ofrecido al sistema operativo ya no pretende ser una computadora completa, sino que el sistema operativo huésped “sabe” que está siendo virtualizado y coopera en la tarea. Esta cooperación estiba en que, en vez de buscar controlar a su hardware como si fuera real, lo toma como un buffer glorificado y envía, más bien, solicitudes al anfitrión (host) para cumplir lo que los programas requieren. Una diferencia aparentemente sutil, pero que —sobre todo en los casos de cargas de trabajo orientadas a la entrada y salida, como las bases de datos y el manejo de red— típicamente llevan a una diferencia de rendimiento de diez veces tanto.

Virtualización y paravirtualización brindan grandísimas ventajas a los administradores, y una en la que insistiré en este punto es que el “engaño” es a nivel sistema entero, cada computadora virtual puede ejecutar un sistema operativo distinto completo. Esto es particularmente útil al hablar de proveedores de servicio en la nube, pues cada cliente tendrá la flexibilidad absoluta de correr en su computadora el software que desee. Sin embargo, hacia adentro de las organizaciones, sigue siendo subóptimo.

Raíces, jaulas, contenedores

Como siempre, la respuesta a una nueva necesidad viene del pasado, con nuevas maneras de emplear lo ya conocido, de refinamientos técnicos que mejoran la implementación de la idea —y en este caso, de la mano de bastante mercadotecnia que llevó a mucha gente a ver hacia el lugar obvio.

Los contenedores pueden definirse como virtualización a nivel sistema operativo. Los usuarios de máquinas virtuales ya no serán engañados con lo que parece ser una computadora completa, sino que únicamente con algo que dice ser un sistema operativo dedicado a ellos. Y, siendo el sistema operativo el principal encargado de agrupar al hardware en clases, gestionar su manipulación de bajo nivel, y proveer abstracciones uniformes para los programas que corren en espacio de usuario… la diferencia es enorme.

Pero vamos por partes, ¿cómo se originaron los contenedores?, ¿cuáles son las ideas primigenias?

En 1982, Bill Joy, uno de los arquitectos del Unix de BSD y fundador de Sun Microsystems, creó la llamada al sistema chroot() para auxiliarse en el desarrollo de Unix. Dado que desarrollaba en la misma computadora donde hacía sus pruebas, quería poder mantener aislado su entorno de desarrollo y construcción del entorno de pruebas. La manera más sencilla (y, además, elegante) de hacerlo es por medio de esta llamada, se invoca con un argumento, y a partir del momento en que un proceso la llama con el nombre de un directorio y hasta el final de su ejecución, el sistema operativo le dará a dicho proceso una vista parcial del sistema, limitada al directorio que le es indicado. Esto es, tras un chroot('/home/gwolf/test'), si el proceso en cuestión da un cd /, el sistema operativo lo llevará a /home/gwolf/test.

En los manuales de sistema es común encontrar advertencias de seguridad — chroot() no está pensado para proveer aislamiento, únicamente conveniencia — Hay varias maneras por medio de las cuales un proceso puede escapar de esta jaula, además de que su funcionamiento se limita a restringir la vista del sistema de archivos, sin proteger otros aspectos del sistema como las interfaces de red, la lista de procesos, o el acceso a dispositivos.

El primer sistema operativo en ofrecer lo que hoy conocemos como contenedores (bajo el nombre de jails) fue la versión 4 de FreeBSD, liberada en el año 2000. Poco después, esta funcionalidad apareció en Solaris, Linux e incluso para Windows; en los dos últimos casos, esto fue inicialmente mediante productos de terceros (Parallels Virtuozzo Containers para Windows, Vserver y OpenVZ para Linux, OpenVZ siendo una rama libre de Virtuozzo). Varios años después de la introducción de esta funcionalidad por medio de terceros, tanto en el caso de Linux (con lxc desde 2009) como recientemente en el de Windows (desde 2015) han sido incorporados a la plataforma base del sistema operativo.

La virtualización a nivel sistema operativo implica que los contenedores engañarán a los procesos huéspedes presentándoles una vista limitada en los siguientes aspectos:

Tablas de procesos
Señales y comunicación entre procesos (IPC)
Interfaces de red
Dispositivos de hardware
Límites en el consumo de recursos (espacio en disco, memoria, o ciclos de CPU)
Información del sistema, como el nombre del equipo o la hora actual

Esto permite a los árboles de procesos que habitan dentro de un contenedor tener una vista de sistema completo, viéndose obligados a respetar las asignaciones de recursos de los demás contenedores. Uno de los principales atractivos para los administradores de sistemas es que un contenedor cuyos servicios no están siendo activamente utilizados permanece efectivamente dormido, con un nivel de consumo de recursos verdaderamente mínimo — A diferencia de la virtualización de sistema entero, en este caso el sistema operativo conoce directamente todos los eventos a que están esperando cada uno de los procesos, y mientras dicho evento no ocurra, los contenedores no pasarán de ser una estructura en memoria.

A últimos años, los contenedores se han ido popularizando ya no únicamente como una herramienta para que el administrador de sistemas particione lógicamente la carga de trabajo de servidores o provea infraestructura de cómputo con acceso privilegiado a distintos usuarios manteniendo garantías de seguridad, sino también como mecanismo de distribución de software, instalado y preconfigurado —la implementación más conocida es el proyecto docker. En lo particular, como administrador de sistemas de vieja guardia y formado en la escuela tradicionalista, le veo importantes carencias a su planteamiento… pero sin duda ha logrado una importante penetración de mercado.

Como sea, la tecnología de contenedores es una genial herramienta con la que contamos hoy, que ha cambiado de raíz la manera en que se despliegan los servicios. Invito a todos los lectores que no se hayan aún adentrado a comprenderla y utilizarla, a no dudar en hacerlo.

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org

ARM como Pivote del IoT

sg — Fri, 08 Jul 2016 17:40:36 +0000

ARM como Pivote del IoT

sg Fri, 07/08/2016 - 12:40

Publicado en

SG #51

Programar es un Estilo de Vida

Autor

Gunnar Wolf

A lo largo de los años, fuimos testigos de cómo las arquitecturas rivales de cómputo pasaron de una gran gama de implementaciones luchando por la supremacía durante los 80 y 90 a una aparente monocultura. La primera década del milenio vio sucumbir a poderosas y prometedoras plataformas como Alpha, m680x0 y HPPA-RISC. Sparc y PowerPC redujeron su participación en el mercado a únicamente casos muy especializados. MIPS pasó de ser el último grito en lo relativo a hardware de alto rendimiento a ser una arquitectura para dispositivos de bajo consumo y bajo precio, como la mayor parte de los switches y puntos de acceso inalámbrico disponibles en el mercado.

Consolidación de una arquitectura reinante

Por varios años, parecía que la plataforma x86, definida por Intel como una serie de “parches” sucesivos al procesador 8086 de 1978, reinaría sin rivalidad en prácticamente todos los mercados. Computadoras de escritorio, portátiles, servidores. Hacia 2005, la plataforma x86 se erigía como clarísimo dominante. Y esto no por ser más potente o eficiente que su competencia, sino por tener una muchísima mayor base de usuarios ya instalada, por mantener una gran compatibilidad hacia atrás, y porque prácticamente todo el software de consumo masivo aparecía únicamente para éste.

Es muy sabido que esta compatibilidad hacia atrás no siempre es lo más conveniente técnicamente. En la década de 1980 nació RISC (Reduced Instruction Set Computing, cómputo con un conjunto reducido de instrucciones), primero como concepto teórico y poco más tarde implementado en varias arquitecturas de hardware (algunas de ellas mencionadas en el primer párrafo). Ya en esos años se veía que las principales arquitecturas disponibles tenían conjuntos de instrucciones demasiado complejos (recibiendo la denominación CISC, Complex Instruction Set Computing, cómputo con un conjunto de instrucciones complejo, en contraposición con la nueva tendencia).

Intel mismo intentó en dos ocasiones diseñar una nueva familia de procesadores que reemplazara a x86. La arquitectura RISC i860, lanzada en 1989 y abandonada unos cinco años más tarde, y la Itanium o IA-64, que se ha mantenido viva de manera formal desde su debut en 2001, pero en la práctica y ante el abandono de prácticamente todos los fabricantes y proveedores de software, es una arquitectura cada vez más anecdótica.

ARM: Jaque al rey

Parecería que en este recuento de la gradual homogeneización de las plataformas de cómputo no hay mucho más que decir. Pero en los últimos años, se ha dejado sentir fuertemente un cambio drástico, y desde el segmento bajo del mercado.

La plataforma de hardware ARM no es bajo ningún concepto un nuevo jugador en el mundo del cómputo: su diseño original se produjo durante los años 1983 a 1985, al interior de la empresa Acorn, que buscaba desarrollar un sucesor para el popular CPU de 8 bits 6502 empleado en muchas computadoras de la época y, en particular, en la BBC Micro, plataforma de gran éxito en el Reino Unido. De hecho, ARM se manejó originalmente como acrónimo de “Acorn RISC Machine”, y una vez que la Acorn dejó de ser un hito reconocible en la mente de los usuarios británicos, para 1990 se independizó de la marca padre para denominarse “Advanced RISC Machines”.

Los procesadores ARM son un ejemplo para libro de texto de las diferencias y ventajas de RISC: si bien su conjunto reducido de instrucciones significa que, a una misma velocidad, pueden realizar mucho menos trabajo real que su competencia CISC, el número de transistores requerido para implementarlo resulta decenas de veces menor que el equivalente CISC de su época. Por ejemplo, cuando en 2007 se introdujo el ARM Cortex-A9, de 26 millones de transistores, los CPUs i7 de Intel excedían los 730 millones.

Menos transistores se traduce en muy distintas ventajas, todas ellas importantes para el cambio que hoy estamos observando:

• Fabricar CPUs ARM resulta más barato, dado que pueden usar procesos que requieren menor miniaturización y hay más fabricantes en condiciones de hacerlo (ARM no tiene ninguna fábrica, es dueño únicamente del diseño de los chips).

• La disipación de calor es menor. Un procesador CISC actual requiere de enfriamiento activo, empleando masivos disipadores y ventiladores. La operación normal de un procesador ARM resulta mucho más aceptable para un equipo de perfil delgado, y más aún cuando está diseñado para llevarse en contacto con el cuerpo de su usuario.

• El consumo eléctrico es menor, permitiendo mucho mayor tiempo de operación a baterías. Naturalmente, el tamaño de los chips resultantes es menor. Mientras que un CPU Intel para equipos de escritorio mide unos 4cm. por lado, los procesadores ARM apenas y sobrepasan un centímetro cuadrado.

Los procesadores ARM siempre estuvieron presentes en nuestros dispositivos “menores”, pero dado que nuestra relación con estos nunca fue tan intensa y personal como en los últimos años, rara vez nos resultó claro. Al haber dado el gran salto cualitativo el mercado de los dispositivos móviles, la plataforma ha dado un salto tal que se volvió la primera respuesta al considerar cada vez más casos de uso, incluso ya en algunos casos entrando al segmento tradicionalmente fuerte de x86.

ARM es una arquitectura muy versátil; tienen tres perfiles de CPUs definidos. De más sencillo a más poderoso, “M” (para microcontroladores), “R” (para aplicaciones de tiempo real) y “A” (para aplicación).

Complicaciones de la plataforma

La plataforma x86 tiene, sin embargo, una gran ventaja: la apertura y estandarización de las principales interfaces entre ésta y su sistema operativo. Para bien o para mal, desde la aparición de la IBM PC en 1981, todos los sistemas compatibles cuentan con un BIOS que se adhiere a una interfaz clara y pública; si bien esta ha sido extendida, mejorada y finalmente reemplazada — por UEFI, que a pesar de los puntos negativos que tenga, era una actualización largamente esperada — a lo largo de sus 35 años.

El BIOS funge de intermediario entre el hardware y el sistema operativo en sus primeras etapas (sobre todo en los primeros años de la PC; hoy en día la funcionalidad se limita casi en exclusiva a la inicialización del sistema). Al arrancar la computadora, se encarga de enumerar y realizar pruebas básicas de funcionalidad al hardware del sistema (el POST). Tras este paso, el sistema operativo puede lanzarse con conocimiento básico del hardware con el que operará.

En la arquitectura ARM, el BIOS sencillamente no existe. La razón para esto es que la compañía ARM funciona de forma distinta de Intel. La compañía no vende chips, no posee fábricas, sino que licencia a terceros sus diseños como propiedad intelectual; los chip ARM son en realidad fabricados, entre muchas otras empresas, por AMD, Broadcom, Freescale, Texas Instruments, e incluso el mismo Intel.

En el mundo ARM, es muy común que los chips encapsulen no únicamente al CPU, controlador de memoria, controlador gráfico, y otros componentes esenciales, sino que prácticamente a todo el sistema de cómputo, inclusive la RAM y los controladores de dispositivos. A esta práctica se le conoce como “SoC” (System on a Chip); de hecho, si ven cualquiera de las computadoras basadas en ARM que han surgido en años recientes, uno de los primeros puntos que llama la atención es su relativa simplicidad. Y si acostumbran abrir, en claro ejercicio de un espíritu científico, sus teléfonos o tabletas, notarán precisamente lo mismo.

Las computadoras ARM, pues, no están normalmente concebidas para su expansión. Por sus características físicas, y por su bajo costo, es más bien un enfoque de un sistema para cada tipo de necesidad; desde el punto de vista en pro de la ecología suena nefasto, pero si requieren mayor poder de cómputo, la respuesta es cambiar de computadora. Además, la mayor parte de los fabricantes buscan ubicar sus equipos como “cajas cerradas”. ¡No es de su interés que yo pueda ejecutar mi software favorito en sus teléfonos en vez del “oficial”!

Ahora, dado que la computadora no requiere de la enumeración y prueba que realiza el BIOS, se ha optado por prescindir de este elemento. Es, pues, responsabilidad del sistema operativo saber qué dispositivos tiene y dónde se ubican. En el caso de Linux, el sistema operativo más común para entornos ARM, significa que debe construirse un núcleo ligeramente distinto para cada modelo de computadora. Este conocimiento del entorno se plasma en una estructura conocida como Device Tree (árbol de dispositivos).

Las plataformas Arduino y Raspberry Pi han resultado fundamentales, no por ser únicas o por ser las más económicas, sino por masificar el acceso a esta tecnología llevándolo al mercado educativo, y servir así como base para cientos de productos tangibles.

Adecuar Linux para su funcionamiento en una nueva sub-arquitectura no es una tarea trivial. Hay un fuerte empuje hoy en día para que los desarrolladores de hardware realicen este trabajo de adecuación con mayor colaboración y en consonancia con la comunidad desarrolladora primaria. Tengo plena esperanza en que, conforme se construye el ambiente de desarrollo para el afamado IoT, irá resultando claro a los fabricantes el valor de mantener la apertura ante los usuarios entusiastas.

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux.

Sobre los pasos de Donald Knuth

sg — Sat, 05 Mar 2016 00:03:32 +0000

Sobre los pasos de Donald Knuth

sg Fri, 03/04/2016 - 18:03

Publicado en

SG #50

Programar es un Estilo de Vida

Autor

Gunnar Wolf

"La ciencia es el conocimiento que comprendemos tan bien que podemos enseñárselo incluso a una computadora; si no entendemos cabalmente algo, manejarlo es un arte
(…)
De tal suerte, debemos intentar continuamente transformar toda arte en una ciencia: Al hacerlo, lograremos su avance como arte."

– Donald Knuth, discurso de aceptación del Premio Turing (1974)

En esta ocasión, dedicaré mi columna a una persona: Donald Erwin Knuth, alrededor de quien mi atención ha estado volando a últimas fechas, y a quien debo parte importante de mi elección de carrera y desarrollo profesional.

Tenemos el privilegio de trabajar en un campo suficientemente joven como para ser contemporáneos con quienes establecieron su mismísimo significado. Gente que viene de formarse en campos disciplinarios disímiles y fue convergiendo en el naciente campo de la computación, sea por la vía de las ciencias duras, la ingeniería, la administración o el arte.

El árbol genealógico disciplinar de la computación está fuertemente dominado, claro, por los matemáticos. En muchas universidades, las principales carreras relacionadas siguen siendo parte de los departamentos de matemáticas, o (en el caso de las ingenierías) requieren un estudio de un par de años de principios matemáticos apenas para “calentar motores” e iniciar con las materias específicas del ramo.

La computación también se caracteriza por ser muy permeable a gente que desarrolló sus competencias profesionales de manera no formal. ¿Quién de ustedes no ha tenido el gusto de trabajar con colegas cuyo currículum formal parecía apuntar hacia futuros muy distintos? En lo particular, mis colegas y maestros incluyen químicos, músicos, físicos, psicólogos, matemáticos, sociólogos, y un largo etcétera (donde sin duda entramos los autodidactas puros, quienes no seguimos una carrera universitaria formal). Todos ellos comparten un punto en su historia profesional personal: reconocer la ventaja de automatizar procesos arbitrarios de una forma repetible, controlable, monitoreable. Esto es, darse cuenta cómo para prácticamente cualquier ámbito profesional, puede ser útil aprender a programar (y posteriormente, claro está, entrar al interminable laberinto fractal que supone afinar nuestras habilidades como programador).

Pero muy poca gente puede compararse siquiera con Donald Knuth. Él es uno de los grandes pioneros de prácticamente todas las disciplinas relacionadas con la computación, una suerte de Da Vinci de los siglos XX y XXI.

Y tal como Da Vinci, Knuth probablemente deba ser visto como artista en primer término, dado que todo lo demás es mera consecuencia.

"Hemos visto que la programación de computadoras es un arte,

puesto que aplica el conocimiento acumulado al mundo,

porque requiere de habilidad y de ingenuidad,

y especialmente porque puede producir objetos de gran belleza.

Un programador que subconscientemente se ve a sí mismo como artista disfrutará de lo que hace y lo hará mejor."

– Donald Knuth, discurso de aceptación del Premio Turing (1974)

El trabajo de Knuth parte de un disfrute estético, no únicamente funcional. Un enamoramiento con los diferentes niveles de lo que su código alcanza. Y eso explica, a distintos niveles de abstracción, el camino por el que llevó a su carrera. Citemos algunos ejemplos.

En 1962, Knuth comenzó a escribir lo que esperaba que fuera un simple libro de texto para la enseñanza de algoritmos —The art of computer programming. Cuatro años más tarde, siendo aún un alumno de posgrado, entregó al editor un primer borrador: más de 3,000 páginas manuscritas. Pero siendo un perfeccionista, sería este libro más lo que guiaría prácticamente la totalidad de su vida académica: pasados más de 50 años, el libro (convertido en una serie de volúmenes de referencia) sigue en desarrollo.

Knuth siguió desarrollando y embelleciendo su texto, preparándolo para la impresión. La ancestral técnica de impresión por tipos móviles, que incluía el fundido de piezas especiales para generar las complejas fórmulas requeridas por las matemáticas, comenzó a encarecer y quedar fuera del alcance para su proyecto.

Conforme avanzaba la tecnología, resultó natural que el libro sería formado por computadora… Pero las herramientas disponibles a principios y mediados de 1970 sencillamente no estaban a la altura estética de una obra con un alta carga de símbolos matemáticos, estructurada con distintos niveles de seccionamiento, cargadas de referencias internas y externas, y Knuth hizo lo que solo un verdadero hacker haría: diseñar su propio sistema de edición de texto, TeX.1 Liberó la primera versión en 1978, y la última versión mayor que introducía cambios no-compatibles, 3.0, en 1989.

Al día de hoy, Knuth ha terminado formalmente tres volúmenes (de siete que, estima, cubren suficientemente bien el campo) y avanzado fuertemente en el cuarto, que va siendo publicado por fascículos.

Me permito mencionar, como un punto muy lateral y con un dejo de soberbia en el tono, que TeX es uno de los puntos definitorios de mi vida: es el primer programa de cómputo que aprendí a usar. Knuth visitó el IIMAS (UNAM), donde con su ayuda se instaló una versión temprana de TeX. Y al día de hoy agradezco a diario a mi padre, investigador en física, las muchas noches de viernes y sábado que me llevó, aún niño, a “jugar” a la sala de terminales, donde hice mis pininos en TeX en 1983. Para 1985, mi padre y un grupo de colegas editaron empleando dicho sistema el Manual de Lenguaje y Tipografía Científica en Castellano2, libro que recomiendo a todo interesado en la escritura técnica formal y en el correcto uso de nuestro idioma. Hasta donde sé, es la tercera instalación de TeX en el mundo. Si comparan el libro referido con prácticamente cualquier obra impresa en esos años notarán, a pesar de sus imperfecciones técnicas en comparación de nuestra era de super-altas resoluciones, una enorme diferencia cualitativa.

Knuth se comprometió a que, después de la versión 3.0, la interfaz de TeX no tendría ningún cambio que rompiera la compatibilidad; todo texto debería resultar idéntico sin importar en qué equipo de cómputo se preparara. Como un guiño de humor hacker, todas las versiones menores subsecuentes se irían acercando a la perfección simbolizada por el número π; la versión actual (liberada en enero de 2014) es la 3.14159265. Knuth, quien hoy tiene 78 años y aunque formalmente retirado sigue trabajando para terminar su principal obra a la cual volveremos, autorizó que post-mortem se efectúe un último cambio a TeX, congelando para siempre su versión en π.

TeX, de la mano del conjunto de macros LaTeX diseñado por Leslie Lamport principalmente entre 1985 y 1995, se convirtió en el sistema de elección para la edición de textos científicos; prácticamente todas las revistas académicas de las ciencias exactas e ingenierías lo emplean como su principal formato para la entrega de originales.

"Cambiemos nuestra actitud tradicional respecto a la construcción de los programas:

en vez de imaginar que nuestra tarea principal es darle las instrucciones de qué hacer a una computadora,

concentrémonos en explicarle a los humanos lo que queremos que la computadora haga."

– Donald Knuth, Literate programming, 1984

Mencionábamos que Knuth apunta a un disfrute estético a diferentes niveles de abstracción. Agreguemos otro nivel más: el paradigma de programación que impulsa; es decir, la computación literaria.

Este paradigma propone que un programa debe ser escrito cual si fuera (dependiendo de su complejidad) como un libro, tratado o artículo estructurado para su lectura humana, en el cual el código fuera el material que acompaña a la exposición lógica. Por medio de un preprocesador, el documento maestro puede exportarse tanto a una versión imprimible como a una compilable. Pueden consultar un sistema de preparación de documentos para documentación literaria en la página de CWEB3 si bien es cierto que no todo programa puede verse beneficiado por esta lógica, la claridad resultante es notoria.

Knuth es, pues, una inspiración en lo estético y en lo funcional, en el purismo matemático y en la limpieza de la implementación. Si acaso, podría criticársele la falta de pragmatismo ante su obsesión por la perfección; sus elevados estándares harían enfurecer a cualquier project manager. Pero sus contribuciones al avance de nuestra disciplina han sido, naturalmente, correspondientemente brillantes.

Espero, con este breve y desordenado texto, dar a conocer algo más de la obra de Knuth, para que inspire a nuestros lectores. Autores de su talla conjuntan ciencia y arte. El tezón para realizar proyectos de décadas de envergadura hace posible avances que otros descartarían por impracticables. Y la apreciación por la belleza lleva a un disfrute en el ejercicio diario de nuestras tareas.

¡Larga vida al maestro Knuth!

La Ardua Tarea de Asegurar la Identidad

sg — Wed, 23 Dec 2015 00:11:13 +0000

La Ardua Tarea de Asegurar la Identidad

sg Tue, 12/22/2015 - 18:11

Publicado en

SG #49

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Una de las tareas que realizo dentro del Proyecto Debian es la de actuar como curador de los llaveros de identidad criptográfica que identifican a los participantes del proyecto, y con que realizamos prácticamente cualquier acción (desde mandar un mensaje a las listas moderadas hasta subir nuevos paquetes) con verificación automática de identidad.

A últimas fechas tuve la oportunidad de participar en el Congreso de Seguridad en Cómputo que organiza UNAM desde hace más de quince años [1], presentando algunas de las experiencias y aprendizajes derivados de esta tarea [2]. Dicho trabajo me lleva a algunas reflexiones que considero que pueden ser de interés para los lectores de SG.

¿Por qué no contraseñas?

El uso de pares usuario-contraseña para validar la identidad de un usuario y determinar si tiene permiso de utilizar determinado recurso se ha utilizado en el cómputo por lo menos desde la década de los sesenta, y en el desarrollo cultural humano, hay documentos que confirman su uso por lo menos desde la época del Imperio Romano. Nuestros usuarios las conocen y comprenden su funcionamiento, y nadie dirá que vamos contra las prácticas más comunes al emplearlas.

Sin embargo, tenemos que estar conscientes de la relativa fuerza (o debilidad) de este esquema: ya desde 1979 hay estudios que demuestran que son un mecanismo débil y muy falible de autenticación [3]. ¿Vamos a exigir a nuestros usuarios “contraseñas fuertes”? Esto es, ¿tenemos una política que requiera que toda contraseña sea (por ejemplo) una cadena de 10 o más caracteres, que no formen palabras, incluyendo mayúsculas, minúsculas, números y caracteres especiales? Malas noticias: si la tenemos, estamos básicamente asegurando que la contraseña será escrita en un papelito que seguramente vivirá pegado al monitor o debajo del teclado — Mucho menos seguro que una contraseña “sencillita” y memorizable.

Pero, por otro lado, ¿qué tanta expectativa de seguridad tenemos si permitimos contraseñas memorizables? La imagen que acompaña este artículo muestra las contraseñas más frecuentemente utilizadas, con tamaños asignados según su frecuencia relativa, tomadas de una muestra de un millón de cuentas (Mark Burnett, 2011). Uno de los puntos más preocupantes: Las 10,000 contraseñas más comunes corresponden al 98.8% del millón de cuentas. ¿Qué tan impredecibles esperamos que sean nuestros usuarios, o nosotros mismos?

En el caso particular de Debian, los recursos a que tendrán acceso los desarrolladores una vez autenticados son enormes. Por poner un simple ejemplo, al subir una nueva versión de un paquete, éste puede instalarse en millones de computadoras, ejecutando con privilegios de administración. Las contraseñas simplemente no son suficiente protección.

Más allá de las contraseñas

Podemos encontrar numerosos esquemas de autenticación que nos llevan más allá de las contraseñas. Casi todos los esquemas siguen los lineamientos de la autenticación multifactorial: si la contraseña es “algo que yo sé”, debo combinarla con “algo que yo tengo” y/o con “algo que yo soy” para obtener una autenticación fuerte.

Un ejemplo con el que seguro han interactuado son los tokens (pequeños dispositivos que presentan un número de seis u ocho dígitos que cambia típicamente cada minuto). Estos dispositivos son claramente “algo que tengo” físicamente, con todo lo bueno y malo que esto conlleva: siendo un objeto físico, no puedo copiarlos. Siendo un objeto que cambia dinámicamente, no puedo memorizarlo ni predecirlo. Si dejé el token en casa o lo perdí junto con mis llaves, no podré identificarme ante el recurso en cuestión.

Por otro lado, se ha popularizado el confiar en los datos biométricos: presentar a la computadora una prueba inherente a mi cuerpo, “algo que yo soy”. Ejemplos de esto son lectores de huellas digitales, sistemas de reconocimiento de voz, escáneres de retina —e incluso el reconocimiento fotográfico que podría hacerse con una webcam cualquiera. Los datos biométricos sobreviven a largo plazo (no necesariamente de por vida, pero sí a largo plazo; mi envejecimiento o un cambio radical de estilo podrían causar que una foto de mi webcam no me reconozca), no puedo olvidar traerlos conmigo, no puedo copiarlos, pero por otro lado resulta imposible pedirle a otra persona que haga algo a mi nombre. Y claro, de los ejemplos presentados, el reconocimiento por webcam sería el más débil. Una persona muy parecida a mí podría pasar bajo el umbral de decisión y reemplazarme.

Autenticación por criptografía de llave pública

En el caso de Debian (y de la gran mayoría de las comunicaciones cifradas del mundo) hemos optado por una versión ligeramente debilitada de emplear “algo que tengo”: para interactuar con el proyecto, mi interacción debe ir firmada criptográficamente por una llave que forme parte de uno de los llaveros del proyecto —que uno de los curadores haya aceptado.

Un par de llaves criptográficas es, a fin de cuentas, un par de archivos (uno para la llave pública, otro para la llave privada) en mi computadora, y de ahí que sea únicamente una versión débil de “algo que tengo”: un archivo puede ser copiado, lo que se traduce en la imperiosa necesidad de ser muy diligente protegiendo el medio en el que éste se almacena; si este par de archivos cayera en manos de terceros, quien lo tuviera podría firmar cualquier archivo de forma indistinguible de lo que haría yo. Claro, un certificado siempre debe estar protegido por una contraseña como primerísima línea de defensa —pero la seguridad de la llave privada sencillamente no puede tomarse a la ligera.

Además de Debian, el uso de certificados para autenticación es muy común en los principales proyectos de software libre. Pero su uso no permanece únicamente en este ámbito: La Firma Electrónica empleada por el Servicio de Administración Tributaria (Hacienda) en México, e incluso por el Sistema Integral de Administración Escolar de la UNAM, ambos ejemplos de sistemas donde el riesgo de mal uso por una insuficiente identificación es demasiado grande.

Aquí puede comenzar a apreciarse por qué se elige este factor “algo que tengo” debilitado. Por la distribución de material. Si Debian, el SAT o la UNAM operarán con tokens hardware, tendrían que repartir un dispositivo a cada participante, lo cual conlleva un costo nada trivial. Tendrían que establecerse mecanismos de restablecimiento ante tokens perdidos o dañados. Y si la tecnología avanza y hace obsoleta a una generación de tokens, hay que reemplazar a todos aquellos que sigan en uso. Manejando un par de llaves, este gasto se mitiga fuertemente.

¿Y qué es esto del par de llaves? Muy en resumen, la criptografía de llave pública se basa en funciones matemáticas unidireccionales (esto es, relativamente fáciles de calcular en un sentido, pero muy difíciles de calcular en sentido contrario) para las que existen parejas de valores. Por ejemplo, una operación que podemos realizar a ojo es multiplicar dos números primos de dos dígitos:

23 x 47 = 1081

Sin embargo, si queremos factorizar 1081, la tarea resulta mucho más dificil —se vuelve un ataque de fuerza bruta. Esto es, en resumen y de forma un tanto simplificado, el funcionamiento de la familia de algoritmos más ampliamente utilizada, RSA — Aunque, claro, no con números de dos dígitos, sino de cerca de mil (entre \(2^{2048}\) y \(2^{4096}\)). De estos números se puede derivar una llave pública, que puede ser presentada públicamente para que cualquiera pueda comunicarse de forma segura con su propietario, y una llave privada, que debe ser bien resguardada y jamás debe caer en manos de terceros (y en caso de hacerlo, debe revocarse inmediatamente).

Certificados e identidad

Tener este par de números no asegura, sin embargo, la identidad. ¿Cómo he de saber que la llave pública que estoy empleando corresponde realmente a la contraparte con que deseo comunicarme y no a un impostor? Agreguemos restricciones: yo no tengo trato directo con mi contraparte.

Aquí es donde entran en juego los certificados. Un certificado es un archivo que contiene la información necesaria de una llave pública junto con la firma de uno o varios (dependiendo del modelo empleado) proveedores de confianza, aseverando que verificaron la identidad del poseedor de esta llave, y asegurando que corresponde con quien dice ser.

El modelo de confianza más difundido en Internet es PKI (Public Key Infrastructure), en que una serie de empresas dedicadas a la creación de certificados goza de nuestra confianza universal. Este modelo es de fácil adopción, y no en balde sobre él se construyeron los modelos de cifrado SSL y TLS; prácticamente todo el tráfico cifrado comercial de Internet los maneja, pero su naturaleza centralizada lo ha llevado a una serie de graves fallos de confianza [4].

El proyecto Debian, entre otros muchos, emplea un modelo descentralizado, par-a-par, llamado llavero de confianza (Web of Trust). En este caso, en vez de depender de una autoridad central, cada uno de los participantes del llavero puede certificar y ser certificado por quien conozca. De este modo, sin que dos personas se conozcan, pueden establecer qué tan fuerte es el camino de confianza que los une dentro de un universo determinado.

El espacio me impide entrar más a detalle sobre este tema. Les refiero a un análisis estadístico, automático y actualizado periódicamente, del comportamiento del principal directorio de llaves PGP [5], que al día de hoy cuenta con más de 4 millones, y me comprometo a abordar algunos aspectos interesantes de la gestión de estos llaveros en números siguientes de SG.

Referencias

Congreso en Seguridad de Cómputo. UNAM. http://congreso.seguridad.unam.mx
G. Wolf. “Fortalecimiento del llavero de confianza en un proyecto geográficamente distribuido”. http://gwolf.org/node/4055
R. Morris & K. Thompson. “Password Security: A Case History”. Communications of the ACM, November 1979. http://www.cs.yale.edu/homes/arvind/cs422/doc/unix-sec.pdf
“Changes in the TLS certificate ecosystem”, LWN.net. https://lwn.net/Articles/663875
“Analysis of the strong set in the PGP web of trust”. http://pgp.cs.uu.nl/plot/

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux.

Programar es un Estilo de Vida

Mecánica Cuántica y Computación

Publicado en

Autor

Ondas, partículas y observadores que interfieren

Las limitaciones de un humano de a pie

Tiempo de explicaciones, tiempo de charlatanes

¿Y el cómputo cuántico?

Privacidad y Anonimato en Redes: ¿y la sociedad?

Publicado en

Autor

¿Quién se anonimiza?

¿Quién te anonimiza?

¿Y qué haces tú?

Funcionamiento de una Red Anonimizadora: La red Tor

Publicado en

Autor

¿Cómo funciona la anonimización?

¿Qué sigue? El componente social

Independencia en el Ciberespacio

Publicado en

Autor

Construcciones Reproducibles

Publicado en

Autor

El ecosistema de las distribuciones de software libre

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

¿Y dónde radica el problema?

En suma

Referencias y notas

Inseguridades de IoT

Publicado en

Autor

¿A qué viene esto al caso?

Tags

Contenedores: Un poco de historia

Publicado en

Autor

De virtualización a paravirtualización

Raíces, jaulas, contenedores

ARM como Pivote del IoT

Publicado en

Autor

Consolidación de una arquitectura reinante

ARM: Jaque al rey

Complicaciones de la plataforma

Sobre los pasos de Donald Knuth

Publicado en

Autor

"La ciencia es el conocimiento que comprendemos tan bien que podemos enseñárselo incluso a una computadora; si no entendemos cabalmente algo, manejarlo es un arte (…) De tal suerte, debemos intentar continuamente transformar toda arte en una ciencia: Al hacerlo, lograremos su avance como arte."

"Hemos visto que la programación de computadoras es un arte,

puesto que aplica el conocimiento acumulado al mundo,

porque requiere de habilidad y de ingenuidad,

y especialmente porque puede producir objetos de gran belleza.

Un programador que subconscientemente se ve a sí mismo como artista disfrutará de lo que hace y lo hará mejor."

"Cambiemos nuestra actitud tradicional respecto a la construcción de los programas:

en vez de imaginar que nuestra tarea principal es darle las instrucciones de qué hacer a una computadora,

concentrémonos en explicarle a los humanos lo que queremos que la computadora haga."

La Ardua Tarea de Asegurar la Identidad

Publicado en

Autor

¿Por qué no contraseñas?

Más allá de las contraseñas

Autenticación por criptografía de llave pública

Certificados e identidad

"La ciencia es el conocimiento que comprendemos tan bien que podemos enseñárselo incluso a una computadora; si no entendemos cabalmente algo, manejarlo es un arte
(…)
De tal suerte, debemos intentar continuamente transformar toda arte en una ciencia: Al hacerlo, lograremos su avance como arte."