Criptografía y seguridad: Bibliotecas y prácticas

Submitted by gwolf on Thu, 10/09/2014 - 11:22
TitleCriptografía y seguridad: Bibliotecas y prácticas
Publication TypeMagazine Article
Year of Publication2014
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number45
Pagination22-23
Date Published08/2014
Type of Articlecolumn
ISSN1870-0888
Keywordsbibliotecas, cifrado, mejores prácticas, Seguridad
URLhttp://sg.com.mx/revista/45/criptografia-y-seguridad-bibliotecas-y-practicas
Full Text

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

AttachmentSize
Versión publicada (PDF)102.25 KB
Fuentes en Emacs (org-mode)11.06 KB
( categories: )

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <br> <b> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <img> <h1> <h2> <h3> <tt> <pre> <strike> <table> <tr> <th> <td>
  • Lines and paragraphs break automatically.
  • Use <bib>citekey</bib> or [bib]citekey[/bib] to insert automatically numbered references.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. The supported tag styles are: <foo>, [foo].

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Keep in mind that all comments will also have to be administrator-moderated. Don't waste your time writing a spam that no one will read.
i
6
C
t
X
d
Enter the code without spaces and pay attention to upper/lower case.