column

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Construcciones reproducibles

Submitted by gwolf on Thu, 05/04/2017 - 10:56
Wolf G.  2017.  Construcciones reproducibles. Software Gurú. :46-47.

El premio Turing1 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 Reproducibles4 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 Tor5 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 mensaje6 del cual traduzco y reproduzco porciones a continuación:

No pasé seis semanas logrando una construcción reproducible para demostrar que soy honesto o cofiable. 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 — A 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 continua7 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 lleven 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.

Nota al pie de página:

1 Al que comunmente se hace referencia como el
premio Nóbel de la computación

2 https://doi.org/10.1145/358198.358210

3 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/

( categories: )

Los detalles de implementación en la era de las abstracciones

Submitted by gwolf on Fri, 09/04/2015 - 11:58
Wolf G.  2015.   Los detalles de implementación en la era de las abstracciones . Software Gurú. :48-49.

– Me llamo Gunnar, y soy programador.

– ¡Hola, Gunnar!

– Tengo que contarles hoy respecto a mi abuso de las abstracciones y de la automatización. Por aprovechar lasfacilidades de un /framework/ completo y poderoso, me he ido olvidando de las interacciones reales. Me engolosiné con un ORM que me presenta los datos como objetos, y me olvido de la realidad de su representación entidad-referencial. Mis métodos son todos cortitos y asumo que el ciclo de atención a solicitudes es corto, olvidando que dejo referencias en memoria. Hago llamadas a procedimientos remotos en proveedores SaaS y no considero que pueden fallar.

– Pero ahora estas consciente de ello. ¡Has dado el Primer Paso! ¡Ese es el camino para ser un Programador, para ser!

– Sí, pero… ¿Por dónde comienzo? Hay tantas abstracciones, tanto por reaprender. A todos lados a donde volteo a buscar, me encuentro con más abstracciones. ¡Me siento perdido! ¿Dónde quedó la simple realidad del cómputo que teníamos antes?

Sí, no hay ni cómo esconderlo: Tiene ya varias décadas que me apasionó comprender lo que pasa dentro de una computadora, cómo opera su aparente magia. Y cuando aprendí, cuando muchos de nosotros aprendimos, incluso un niño de diez años podía comprender cómo operaban ciertos procesos, si bien tal vez no a nivel electrónico, sí a partir de una visión muy cercana. Piensen, por ejemplo, en qué tan a profundidad podía un niño de los 1980s conocer a una magnífica /Commodore 64/, e incluso cuánto puede haber aprendido con una PC. Recuerdo largas horas de leer documentación, modificar binarios a mano con un editor hexadecimal para cambiar las cadenas que presentaban al usuario, buscando comprender todo lo que veía — Simplemente, porque era posible hacerlo.

Como nota al calce: Si alguno de ustedes se siente identificado con este disfrute histórico, no puedo dejar de invitarlos a una de las lecturas que más he disfrutado en los últimos meses: Un libro titulado sencillamente /«10 PRINT CHR$(205.5+RND(1)); : GOTO 10»/, y que pueden descargar gratuitamente de [http://10print.org/]. Este libro aborda muy distintos aspectos que se desprenden de la línea de BASIC que lleva por título; un análisis técnico, social, cultural, incluso artístico de esa era que a tantos nos atrapó convirtió en lo que hoy somos.

Como segunda nota al calce y recomendación literaria: El libro /«Lauren Ipsum: A story about computer science and other improbable things»/, de Carlos Bueno ([http://laurenipsum.org/]). Aprender los fundamentos del cómputo siendo aún niño definió mi vida. Este libro presenta, a través de un cuento inspirado en /Alicia en el país de las maravillas/, conceptos fundamentales de la ciencia de la computación: Problemas clásicos, estructuras de datos, conceptos fundamentales, presentados con el cuento de una niña perdida en el bosque de los árboles rojo-negros, buscando volver a casa.

Pero volviendo a nuestro tema: con el tiempo, el mundo ha ido cambiando. Y yo también. Al volverme un miembro útil a la sociedad, como les habrá pasado a ustedes también, fui eligiendo mi /nicho ecológico/: Desarrollo de aplicaciones Web y administración de sistemas. Primero, exprimiendo los detallitos que me ofrecía cada pedacito del protocolo… Aunque recuerdo muy bien una discusión con un colega: Yo era bastante reacio a emplear /frameworks/ de desarrollo precisamente porque, al automatizar las tareas repetitivas, esconden del programador su funcionamiento real, y dificultan tener verdadero control de lo que hacen, pero él me mostró las ventajas que conllevaban.

Pero bueno, acortando la historia: De desarrollar mis aplicaciones completas con el lenguaje Perl, cabalgando /a pelo/ sobre el API de Apache, me /subí al tren/ de Ruby on Rails. Y disfruté muchísimo de la libertad que me brindó esta experiencia: Una programación más limpia, orientada a objetos. Configuración por convención. Muchas muy buenas prácticas de desarrollo, y un marco de desarrollo con opiniones propias que me marcó cómo estructurar mi desarrollo. Y sí, las aplicaciones resultantes eran comprensiblemente más rápidas de desarrollar, y al tener el comportamiento base resuelto, me topé con muchos menos errores lógicos en las capas más bajas.

Pero la vida sobre un /framework/ también trae sus desencantos. En mi caso, me topé con los primeros al encontrar la cantidad de código que había que reescribir cuando Rails pasó de su versión 1 a 2, de 2 a 3… Como es de esperarse, los cambios que introducen las versiones mayores no son /compatibles hacia atrás/, y buena parte de mi código histórico iba emitiendo advertencias por usos desaconsejados — O rompiéndose por completo. Y entre más sistemas desarrollaba, menos tiempo tenía para mantenerlos a todos al día.

La respuesta de la comunidad Rails a mis cuitas es relativamente simple: Un sistema que ya está en producción no requiere ser actualizado. El programador puede /congelar/ el sistema base y las /gemas/ (bibliotecas) que emplea, y convivir fácilmente en el mismo sistema con otras aplicaciones Rails — Incluso si estas usan otras versiones de prácticamente todo en el sistema.

En ese momento, comenzó una lucha interior, entre mi Dr. Jekyll, un administrador de sistemas que prepara las cosas y, con la cabeza fría, mantiene una visión consistente y coherente del conjunto, y mi Mr. Hyde, un programador que quiere vivir al límite probando las últimas versiones del último grito de la moda, cambiando de arquitectura subyacente, abandonando a /FCGI/ por /Mongrel/, a /Mongrel/ por /Thin/, a /Thin/ por /Passenger/, incorporando a /Rack/… Y claro, encarnando a esa aberración de la que hablaremos en otra ocasión que hoy deambula libremente: el temido /DevOp/, criatura que encarna lo más obscuro tanto de desarrolladores como de administradores.

Y ojo, me centro en este aspecto porque mi Dr. Jekyll es administrador de sistemas. Pueden imaginar lo que diría uno con formación de DBA al ver el caos resultante del ORM: ¿Cómo se grea mi esquema de datos? ¿Dónde están las verificaciones de integridad? ¿Cómo se generan las consultas para cada una de las operaciones que el buen ActiveRecord realiza?

En fin, podemos recordar esa máxima de la ciencia de la computación, que he visto atribuída tanto a David Wheeler como a Butler Lampson: /Todos los problemas en la ciencia de la computación pueden resolverse/ /con un nivel adicional de indirección — A excepción del de tener/ /demasiados niveles de indirección./

Mientras esa pelea ocurría en mi /yo desarrollador/, muchos otros importantes cambios se presentaron en mi vida. Uno de ellos, me convertí en profesor en la Facultad de Ingeniería de la UNAM. Imparto una materia que siempre me emocionó: Sistemas Operativos. He disfrutado muchísimo con la preparación del material y con el dictado de las clases. En esta materia estudiamos las funciones básicas de todo sistema operativo — Comunicación entre procesos, multiplexión de recursos, organización de sistemas de archivos, gestión de memoria, etc.

Conforme estudio y repito mi material, y conforme comento al respecto con mis colegas, vuelvo a uno de los planteamientos de origen que siempre hago a mis alumnos: No espero que de mi clase salgan autores de sistemas operativos; sería un gran orgullo que así fuera, pero no es lo que la materia persigue. Una de las principales razones para estudiar esta materia es que, si no se comprenden los fundamentos de lo que estamos haciendo, nuestros programas van a resultar de muy baja calidad.

Si nos olvidamos que a fin de cuentas todo nuestro código se traduce a instrucciones de muy bajo nivel, si nos olvidamos de cuidar la eficiencia de los /cachés/ y de reducir accesos a disco, si no tenemos en cuenta el costo de cada llamada al sistema, si no consideramos la necesaria sincronización en problemas que enfrentan concurrencia… Vamos a terminar creando código lento y frágil. Vamos a terminar siendo malos desarrolladores.

Entonces bien… El motivo de esta columna no es llamar a que abandonemos las herramientas que facilitan nuestra tarea. Los /frameworks/ no únicamente son cómodos, sino que son necesarios para la realidad del desarrollo de software hoy en día. Pero debemos mantener en mente, siempre, la importancia de /comprender qué pasa/. Si hay un comportamiento dado que parece mágico, ese es el punto donde debemos revisar el código fuente del /framework/ y averiguar cómo está haciéndolo. Porque sólo de esa forma podremos sacar el provecho correcto del sistema — y escribir mejor código, que a fin de cuentas, por eso nos hacemos llamar /profesionales/.

Entonces, vestidos de investigadores privados y lupa en mano, ¡vamos a investigar implementaciones! ¡Disfruten el viaje!

( categories: )

Criptografía y seguridad: Bibliotecas y prácticas

Submitted by gwolf on Thu, 10/09/2014 - 11:22
Wolf G.  2014.  Criptografía y seguridad: Bibliotecas y prácticas. Software Gurú. :22-23.

El pasado mes de julio tuve nuevamente la oportunidad de participar en el congreso anual que organiza Software Gurú, presentando la conferencia Desarrollo de software y criptografía.1

Me doy cuenta que, si bien su relevancia resulta clara y hay interésen la comunidad de desarrolladores por comprenderlo, el tema de la criptografía es visto por muchos como un tema casi mágico o místico: Hay unos pocos expertos, pero está fuera del alcance para el común de nosotros, los simples desarrolladores que carecemos de un sólido conocimiento matemático de fondo.

Y sí, no puedo negarlo: El uso correcto de la criptografía requiere de darse una pequeña zambullida en un mar de conceptos nuevos. Sin embargo, me da gusto ver que estamos cada vez más conscientes de la importancia de proteger los datos de nuestras aplicaciones, tanto como sea posible, por criptografía fuerte. Aquí aparece la primer tensión que abordo: ¿Cómo responder a las necesidades de seguridad de información sin tener un sólido conocimiento matemático en cuestiones de criptografía?

Afortunadamente, en ese punto es donde aparece el hilo conductor con el tema de la presente edición de Software Gurú: La era de las APIs: Hay varias bibliotecas criptográficas ampliamente disponibles, implementando los diferentes algoritmos y modos de operación. Y no es necesario implementar los protocolos criptográficos, sino únicamente llamar a las funciones indicadas de la biblioteca de nuestra elección.

Y, claro, el hablar de etas principales implementaciones también da pie a abordar del impacto de los no pocos ni triviales problemas que han aquejado a este campo en los últimos meses. Y sí, aunque probablemente muchos asocien en primer término al término API con las interfaces presentadas por el uso de facilidades provistas por los famosos servicios en la nube, toda biblioteca que empleemos para el desarrollo (incluyendo las bibliotecas estándar, parte de la definición de nuestro lenguaje) expone una interfaz de programación de aplicaciones.

Claro está, estamos viviendo en la era de las APIs — Desde hace más de 60 años.

Criptografía: ¿Para qué?

La criptografía nos brinda distintas herramientas para proteger nuestra información — Y si partimos de que la información es el activo más valioso de todos nuestros sistemas, resulta obvio que la criptografía es uno de nuestros mayores aliados.

Si bien la criptografía es casi tan vieja como la escritura misma, apenas fue abordada como una disciplina científica matemática a partir de mediados del siglo XX. Y si bien durante la mayor parte de la historia su principal afán (y, claro, el concepto relacionado directamente en el imaginario popular) fue el de brindar confidencialidad a la información valiosa, esta hoy en día representa sólo una de las propiedades de la información que la criptografía nos permite asegurar.

La segunda propiedad es la integridad: Partiendo de un texto origen arbitrariamente largo, las llamadas funciones digestoras calculan su hash, una cadena de longitud fija con la propiedad fundamental de ser muy dificil encontrar otro texto que genere la misma salida.

Esta definición de integridad posiblemente deje a más de uno insatisfecho. Y sí, por sí sola no sirve para garantizar gran cosa… Pero la tercer propiedad hará clara su utilidad.

Hasta mediados de los 1970, todos los esquemas de criptografía dependían de una llave única: El equivalente a una contraseña que permitía tanto convertir un texto claro en una representación inintelegible como manipular a dicha representación para obtener de vuelta al texto claro.

Entre el breve lapso comprendido 1976 y 1980, el mundo de la criptografía cambió por completo: Nació la criptografía de llave pública, con los principales protocolos que siguen siendo utilizados al día de hoy. Esencialmente, en vez de manejar una sola llave, se descubrieron varias funciones matemáticas que permiten llaves compuestas de dos mitades: Una privada, que cada indivduo debe custodiar celosamente, y una pública, que puede ser ampliamente distribuída. Estas dos llaves actúan como inversas: Lo que se cifra con una sólo puede descifrarse con la otra.

Este hecho, que parecería una mera curiosidad, permitió la creación de mecanismos para proteger las tercera propiedad de la información: La Autenticación. Si un mensaje cifrado por mi llave privada puede ser descifrado por cualquiera que conozca mi llave pública, y existen directorios de llaves públicas, este mensaje sólo puede haber sido generado por mí.

Ya con estos antecedentes, ¿qué es la cadena que aparece en todas las facturas electrónicas y ocasionalmente incluso en los correos electrónicos? Tomando un texto origen, se obtiene su hash, y se firma con la llave privada del emisor. ¡Listo! Una firma electrónica con un tamaño constante, estableciendo una relación no repudiable entre un documento y su emisor.

Partiendo de distintas formas de emplear estas tres propiedades pueden derivarse otros varios patrones de validación de documentos; este es sólo el más común y sencillo de muchos de los patrones de uso de criptografía.

Pero… ¿Se puede confiar en la criptografía?

Al hablar de la integridad, mencioné que debía ser muy dificil encontrar dos textos que produzcan el mismo resultado. A pesar de que el término puede no inspirar mucha confianza, sin embargo, debe leerse no como algo que intuitivamente (y sin ser especialista) me parezca dificil, sino definido desde la teoría de la complejidad computacional: Computacionalmente dificil significa que es sumamente resistente a ser atacada por búsqueda exhaustiva (o lo que es lo mismo, por fuerza bruta): Idealmente, la complejidad crece de forma exponencial con el espacio de búsqueda.

Por ejemplo: un algoritmo de cifrado simétrico ampliamente utilizado como el AES puede operar con llaves de 128 a 256 bits. Esto significa que, con una llave de 128 bits, el espacio de búsqueda es de \(2^{128}\) (del órden de \(10^{38}\)) posibilidades. Si tuviéramos poder de cómputo suficiente para intentar decodificar un billón de llaves por segundo, una búsqueda exhaustiva tomaría sólo 719 millones de veces la edad del universo. En contraste (e ilustrando el crecimiento exponencial), una llave de 64 bits tomaría sólo 213 días.

Los algoritmos que se han desarrollado, es cierto, no son perfectos. Por ejemplo, Alex Biryukov y Dmitry Khovratovich presentaron en 2009 un artículo2 detallando un tipo de análisis permitiendo reducir dramáticamente (a sólo unas decenas de veces la edad del universo según nuestro cálculo) el espacio de búsqueda. La búsqueda de debilidades en algoritmos criptográficos es un campo vibrante de investigación matemática, con muchos talentosos académicos buscando cómo ganarle un bit más, un pasito más. De encontrarse alguna debilidad, aparecerá sin duda publicada en las más importantes revistas académicas del ramo.

Bibliotecas criptográficas

Pero, dado que nuestro campo es el desarrollo de sistemas y no la criptografía desde un punto de partida matemático, recordemos que hay una gran regularidad entre los parámetros que requieren los diferentes algoritmos. Si empleamos una biblioteca de funciones criptográficas, como la muy conocida OpenSSL, y un algoritmo ampliamente utilizado es descubierto como vulnerable, hacer el cambio para emplear otro algoritmo resultará casi trivial.

Por otro lado, me permito citar la máxima de Adi Shamir, uno de los padres de la criptografía moderna:

La criptografía normalmente es evadida, no penetrada.

Decenas de productos han implementado soluciones criptográficas (generalmente basadas en el firmado) en los últimos años, sólo para encontrar que su mecanismo fue roto al muy poco tiempo de salir al mercado.3 /sup> Todos estos ejemplos derivan de un uso incorrecto de la criptografía: Para hacer un jailbreak, el atacante burla la llamada a la función criptográfica, aprovechando un error de programación para secuestrar el flujo antes de que se lleve a cabo la validación.

Y antes de cerrar esta columna: Mencioné a la popular biblioteca OpenSSL. A más de uno de ustedes debe haberle sonado una alarma: ¿En serio está recomendando OpenSSL? ¿Después de Heartbleed?4 Sí, sí lo recomiendo. Vamos paso por paso.

OpenSSL es la biblioteca criptográfica por excelencia, y su principal fuerza es también su principal desgracia: Es una biblioteca con 20 años de historia, y profundamente multiplataforma. Vamos, su herencia multiplataforma ha mantenido el soporte para arquitecturas que desde hace años son consideradas obsoletas, como VMS u OS/2. Además, el estilo del código es de muy dificil comprensión — Los desarrolladores justifican esto puesto que, siendo la criptografía tan demandante de recursos de cómputo, se vieron orillados a tomar decisiones motivados
más por el rendimiento que por la claridad.

Como sea: El fallo conocido como Heartbleed expuso lo inadecuadas que dichas prácticas son hoy en día. Sin embargo, y analizando el fenómeno desde la perspectiva de un promotor del software libre, la respuesta de la comunidad ha sido de lo más interesante: Por un lado, la Linux Foundation (a través de su Core Infrastructure Initiative) está fondeando una auditoría del código de OpenSSL. Y por otro lado, surgieron dos proyectos derivados de OpenSSL, buscando corregir sus defectos de formas más radicales, aunque signifique romper la compatibilidad a nivel API: LibReSSL,5 del equipo de sistema operativo OpenBSD, y BoringSSL,6 de Google. ¿Por qué BoringSSL? En palabras de Shawn Wilden:

Los componentes fundamentales de seguridad (…) debrían ser muy aburridos. No son el lugar para inovar y experimentar, (ni) para el código que demuestra el virtuosismo del autor. (…) Son donde quieres implementaciones simples, directas y aburridas de los algoritmos y protocolos (…) Cuando se habla de seguridad, lo aburrido es bueno.

Que Heartbleed fue un fallo nefasto nadie lo pone en duda. Sin embargo, ante estos fallos siempre es interesante ver la reacción de las comunidades de desarrolladores. Al igual que cuando otros fallos severos, Heartbleed ha llevado a los desarrolladores (al menos dentro de las comunidades de software libre, cuyo código y cuyas discusiones son claramente visibles desde fuera) a iniciar auditorías y replantearse prácticas que seguramente redundarán en el avance global de la calidad del software.

Nota al pie de página:

1 http://gwolf.org/desarrollo_y_criptografia

2 http://eprint.iacr.org/2009/317

3 La excelente presentación Crypto won't save you either, disponible en http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf, presenta más de 20 casos.

4 ¿No supiste acerca de la vulnerabilidad de seguridad más publicitada por lo menos en este lustro? http://heartbleed.com

5 http://www.libressl.org

6 https://www.imperialviolet.org/2014/06/20/boringssl.html

( categories: )

Conforme las nieves del tiempo platean mi sien

Submitted by gwolf on Thu, 06/26/2014 - 10:26
Wolf G.  2014.  Conforme las nieves del tiempo platean mi sien. Software Gurú. :46.

Para este número, nuestra coordinadora editorial nos pidió enfocarnos a una retrospectiva de lo que significa esta década que se cumple. E inevitablemente, cada vez que comienzo a pensar al respecto, el plazo se me duplica, y termino tarareando una de dos melodías. Dos hermosas canciones que relatan, melancólicamente, a muy distinto ritmo y desde muy distintas ópticas, el recuerdo de un amor al paso de un largo intervalo de tiempo: La contradanza cubana ``Veinte años'', de María Teresa Vera, y el tango ``Volver'', de Le Pera y Gardel.

En ``Veinte años'', se recuerda algo que terminó de forma irremisible, volviendo a que el amor que ya ha pasado no se debe recordar. Sin embargo, en ``Volver'', si bien parte de una historia de desamor y distancia, culmina en la esperanza de un reencuentro — Y aunque el olvido, que todo destruye, haya matado mi vieja ilusión, guardo escondida una esperanza humilde que es toda la fortuna de mi corazón.

Ambas canciones son de las más identificables y definitorias de sus respectivos géneros. Tal vez sea por lo importantes que nos resultan (obviamente, muy por debajo de una relación amorosa de esperanza y de desgarre, pero sigamos el argumento) los números cerrados, los plazos que nos hacen recordar lo que hacíamos hace toda una vida… Y, en este caso, me quedo con ``Volver'', por la esperanza de seguir adelante, la expectativa ante el futuro.

Mucha gente insiste en que en nuestra área más que en otras el cambio es la única constante. Yo soy de la opinión contraria: Hay un gran desarrollo tecnológico, pero las cosas se mantienen igual mucho más de lo que cambian. Cambian, sí, los detalles, los sistemas específicos que empleamos, alguna metodología que esté de moda… Pero viendo la imagen en grande, nuestro ámbito de acción profesional no da los grandes saltos que algunos suponen. SG nos va dando una importante memoria histórica de lo que va ocurriendo en este campo, en nuestro país.

Revisando los temas de portada de una década de SG, hay una clara lista de temas recurrentes — Los temas candentes que representan la mayor parte de las dudas, necesidades y nuevos desarrollos. Estos temas seguramente nos seguirán dando de qué hablar en los próximos años. El cómputo en la nube (SG #22, #32, #43), metodologías y procesos, en particular los ágiles (SG #1, #9, #25, #26), móviles y embebidos (SG #5, #17, #24, #42, y de cierto modo #28 y #29). Obviamente, siendo el objeto primario declarado de SG, el análisis de la industria de software en nuestro país es uno de los temas más recurrentes (#21, #27, #33, incluyendo los estudios de salarios, #18, #30, #37). 18 de los 44 números que ha publicado SG, pues, tocan temas que se han abordado por lo menos en tres ocasiones.

Claro está, este agrupamiento temático que hago es simplista, y basado únicamente en el el título destacado visualmente en la portada; hacer un ejercicio con las editoriales, columnas y artículos que han formado parte de nuestra revista a lo largo de todo este tiempo sin duda nos arrojaría un interesante árbol temático del ramo con nuestras principales recurrencias.

Entonces, pues… Festejo un lustro. Festejamos una década. Y festejemos con la esperanza de seguir haciéndolo para los veinte años, y para después de ello. Este es el inicio de una historia. Software Gurú cubre un espacio importante y necesario para el desarrollo de nuestro país; el proyecto ha crecido desde su planteamiento original, y definir a SG es cada vez más difícil; revista, congresos, seminarios, y toda una comunidad de profesionales del desarrollo de sistemas. Una comunidad formada por empresarios, académicos, estudiantes, gente con intereses muy diversos, que aquí hemos ido encontrando nuestro espacio.

Nuestro campo demanda que nos mantengamos actualizados, que trabajemos en equipo, que compartamos conocimiento. El espacio que SG brinda a los desarrolladores de software en nuestro país es
fundamental. Sigamos haciendo historia juntos — No cinco o diez años más. Sigamos impulsando al desarrollo de software a largo plazo, como una vocación de vida.

¡Muchas felicidades!

( categories: )
Syndicate content