Vigilancia de seguridadBitLocker y la complejidad de la confianza

Justin Troutman

Windows Vista. Hasta ahora no había tenido la oportunidad de escribir ningún artículo en el que aparecieran estas palabras, por eso me siento como un niño de cinco años con un cheque en blanco para gastar en una juguetería. Existen muchas características de las que hablar, propiedades que vale la pena explorar y muchos caminos por los que puede discurrir una conversación.

Hace poco, leyendo el blog de Bruce Schneier, el gurú de la seguridad, encontré una entrada que hablaba sobre un concepto nuevo para mí en ese momento: BitLocker™. Deduje que se trataba de un producto pensado para ofrecer la funcionalidad de criptografía en Windows Vista® y me estremecí y pensé "Oh no, Windows Vista incorpora criptografía. No puede tratarse de nada bueno. Y, aunque el resultado sea presentable, seguro que hay una puerta trasera oculta.".

Existen argumentos históricos, que pueden ser discutibles, respecto a la falta de confianza en las características de seguridad integradas en Windows®. Pero esta no es la razón por la que escribo esta columna. En realidad, quiero explicar con argumentos por qué creo que hay razones de peso para dar una oportunidad a BitLocker. Además, quiero hacer algún comentario sobre el tipo de filosofía que garantiza la vitalidad del software y hardware criptográficos.

Pero no me malinterprete: no creo que BitLocker sea la panacea de la seguridad en conjunto, ya que solo es una de las piezas que componen el puzzle de la seguridad. Su objetivo es ofrecer resistencia frente a determinados modelos de amenaza.

En particular, BitLocker se centra en la pérdida o el robo de equipos portátiles. Los trabajadores móviles manejan todo tipo de información confidencial en diferentes lugares: trenes, aviones, restaurantes, hoteles, oficinas de la empresa y sucursales. Esta información la transportan en equipos portátiles y otros dispositivos móviles que suelen carecen de una seguridad real, por lo que los datos que contienen son muy vulnerables. ¿Qué pasa con los datos cuando uno de los usuarios se deja un equipo portátil en algún lugar?

Esta claro que no se pueden evitar los descuidos de la naturaleza humana. Por suerte, se pueden limitar las consecuencias negativas derivadas. Para una empresa, el costo de reemplazar un equipo portátil es pequeño, comparado con el costo de la pérdida de datos confidenciales. Es ésta la seguridad que BitLocker pretende ofrecer.

Más allá de los créditos

Estoy analizando BitLocker desde una perspectiva interesante porque todavía no lo he probado. Sé lo que estará pensando: ¿cómo es posible que alguien que no ha usado nunca BitLocker opine sobre él y que además diga algo útil sobre el tema? Siga leyendo. Lo que quiero analizar en realidad es la criptografía desde un nivel más alto y las filosofías de diseño que son importantes para obtener una solución satisfactoria.

Toda la historia empezó cuando leí el blog de Bruce Schneier. Supongamos que desea ver una película nueva. A partir del trailer y los actores principales del reparto ya ha sacado algunas conclusiones sobre la película. Es cierto que un buen reparto no garantiza que la película sea buena. Sin embargo, la lista del reparto puede decir mucho acerca de la película y de lo que se puede esperar de ella. Por ejemplo, no será lo mismo una película en la que aparezcan Chris Rock y Ben Stiller que una de Kate Winslet y Johnny Depp.

Del mismo modo, cuando comprobé que un gurú de la seguridad respetado a escala internacional analizaba BitLocker en su blog, saqué algunas conclusiones. Primero pensé que esta tecnología debía ser lo suficientemente buena para merecer un comentario tan respetuoso o bien, tan absolutamente nefasta que era necesario hacerlo público. Para mi sorpresa, la opinión de Bruce Schneier era positiva.

Había una frase en particular que destacaba en su crítica: "No tiene puertas traseras para la policía". Esta declaración tiene mucho alcance; se expresaba con gran confianza y se incluía un vínculo al blog del equipo de integridad de sistema de Microsoft®. Seguí el vínculo y encontré un artículo de Niels Ferguson, un desarrollador de Microsoft especializado en seguridad, en el que se denunciaban los rumores especulativos de que Microsoft había incluido en BitLocker puertas traseras de forma intencionada por motivos legales. Ferguson declaraba abiertamente que las puertas traseras son inaceptables y que no formaría parte de un proyecto que las admitiera. Además explicaba que aunque Microsoft estuviera obligado a incluir una puerta trasera por ley, la empresa anunciaría la puerta trasera, o bien, retiraría completamente dicha característica.

El nombre que aparecía en el artículo, Niels Ferguson, explica la confianza de Schneier y también la mía. Ferguson sabe de lo que habla y tiene un historial que garantiza que se puede confiar en lo que dice. Bruce Schneier y Niels Ferguson son coautores de Practical Cryptography (una obra imprescindible acerca de la aplicación de criptografía de calidad de forma sencilla, correcta y segura) y codiseñadores del cifrado de bloques Twofish, una red Feistel de 128 bits, que se ganó la denominación de red criptoanalítica por quedar finalista en el proceso de selección del Estándar de cifrado avanzado (AES).

Por supuesto, tener un criptógrafo veterano en un proyecto no garantiza que el producto final será seguro. Incluso los maestros de esta arte en ocasiones pueden dejar pasar algún trazo. Pero con independencia del éxito que pueda llegar a tener BitLocker con el tiempo, al menos puede estar seguro de que en su creación se han usado estrategias de diseño solventes.

Si hay que hablar de intentos fallidos, hay que mencionar los intentos realizados con buena fe por desarrolladores que no tienen ni una pizca de sentido criptográfico y los intentos realizados con mala fe de aquéllos cuya única preocupación es sacar un producto al mercado. Ambas posibilidades, con independencia de las distintas intenciones de cada una de ellas, suponen fracasos para la seguridad en preparación. Sin embargo, no parece que éste sea el caso de BitLocker. La intervención de al menos un criptógrafo competente y la existencia de amplios recursos para apoyar el esfuerzo, es una perfecta combinación.

Unas palabras sobre la confianza

Hace poco, Phil Zimmerman, creador del cifrado de PGP, compartió algunos principios generales conmigo. Si alguna vez se confeccionara un "Credo de la seguridad para desarrolladores", sus consejos seguramente figurarían en uno de los lugares destacados. Aunque sus declaraciones no pretendían centrarse en BitLocker, las filosofías de diseño que promueven se pueden aplicar a la mayoría de las soluciones criptográficas. Es posible que las encuentre demasiado obvias o entusiastas, pero dado el estado de la seguridad de hoy en día, vale la pena describirlas explícitamente.

Al diseñar una infraestructura criptográfica, el desarrollador debe actuar de forma sencilla, correcta y segura. Aunque los errores son inevitables, no se deben aceptar con normalidad sin darles importancia. El desarrollador debe ser un incondicional del perfeccionismo meticuloso. En palabras de Zimmerman, "diseña como si cometer un error costará la vida de alguien". ¿Cree que es una exageración? En el congreso anual de 2005 sobre aplicaciones de seguridad para equipos, el criptógrafo Brian Snow, de la NSA, que ahora está jubilado, dijo: "En un dispositivo de seguridad, lo que busco son funciones y garantías. No se puede usar el cliente para probar la versión beta. Si mi producto falla, alguien podría morir". Así que recuerde: los errores pueden acarrear algo más que un simple costo económico.

Los usuarios tienen derecho a que existan garantías. Ganar la confianza de los usuarios (y mantenerla) es esencial. Zimmerman lo dice alto y claro: "Gánese la confianza de los usuarios. En cuanto asuma esa carga, ya no podrá desprenderse de ella". De esta forma, la empresa conserva la confianza del usuario y su propia reputación en cuanto a la seguridad. Si se pierden estos dos elementos, es posible que sean irrecuperables.

Espero que éstas sean las perspectivas que haya tenido presente Microsoft al diseñar BitLocker (o cualquiera de los demás productos en esta materia). Dicho esto, ahora explicaré por qué creo que Microsoft ha seguido estas premisas y ha conseguido una tecnología criptográfica que se debe tomar en serio.

Poor-man y Elephant

En esencia, BitLocker es ser la forma que usa Windows Vista para cifrar todos los datos de volumen del sistema (especialmente, en las ediciones Enterprise y Ultimate). Puede parecer que se trate de una aplicación sencilla, pero hay tener en cuenta las restricciones existentes. Debido a que BitLocker cifra los datos por sector y el texto cifrado no puede superar la longitud del texto sin formato, no hay espacio para nada más, como por ejemplo, el nonce (valor de seguridad, que puede ser número o cadena, y que se usa sólo una vez para la autenticación), el un vector de inicialización (IV) o el código de autenticación de mensajes (MAC). Preví que dichas estrictas restricciones y las condiciones que imponen son posibles, sin embargo, también sabía que la autenticación de ese mensaje se debería tener en cuenta de alguna manera.

BitLocker depende de lo que habitualmente se llama autenticación económica. El riesgo no es lo conservador que debería, porque asume que el texto cifrado manipulado no tiene como resultado texto sin formato significativo. Es decir, si se manipula el texto cifrado se bloqueará el sistema por ejemplo, en lugar de permitir que un adversario lleve a cabo alguna función.

El equipo de Microsoft responsable de BitLocker sabía que el nuevo cifrado de bloques necesitaría más tiempo del aceptable para realizar el análisis, pero los diseños existentes todavía no se habían analizado lo suficiente o bien no eran lo bastante eficaces. Por ello, Microsoft eligió AES (estándar de cifrado avanzado) en modo CBC (encadenamiento de bloques de cifrado) para el cifrado, al que haré referencia como AES-CBC. Esto no se puede distinguir en el modelo elegido de ataque de texto sin formato (abreviado, IND-CPA) y, además, no protege la integridad. Asimismo, debido a que no hay espacio para un MAC, y CBC es un modo de confidencialidad, no se protege la integridad. Hay que ponerse en la cola de Elephant para entrar.

El nuevo componente Elephant tiene dos difusores creados para procesar autenticación económica mejor que como lo hace el AES-CBC sin formato. Sin embargo, hay que recalcar que existe una opción para ejecutar el AES-CBC sin Elephant para quienes deban ajustarse a las estrictas directivas de cumplimiento de estándares. Aunque no siempre es ideal, la autenticación económica es la solución más conveniente dadas las restricciones existentes, y Elephant se propone sacar lo mejor de la situación. ¿Cómo funciona todo esto exactamente?

En la figura 1 se ilustra el flujo de datos. Cuando se lleva a cabo el cifrado, el texto sin formato se combina a través de XOR, con una clave de sector. A continuación, el texto fluye a través de dos difusores sin clave. A partir de ahí, el texto se cifra mediante AES-CBC. La clave de sector y AES-CBC requieren el material de clave y, por lo tanto, se les aplica claves por separado. Este método simplifica la formalización de una prueba para reducir la seguridad de la creación de AES-CBC y Elephant a la de AES-CBC. Elephant es un primitivo nuevo y es posible que haya resistencia a su aplicación hasta que se haya analizado rigurosamente. Pero este método equilibra la escala ya que BitLocker puede demostrar que AES-CBC con Elephant no es tan vulnerable como AES-CBC por sí solo.

Figura 1** La autenticación económica con Elephant **

La clave de sector y los componentes de AES-CBC reciben 256 bits de material de clave cada uno, por lo que la longitud de la clave tiene un total de 512 bits. Sin embargo, de forma predeterminada, cada uno de los componentes solo usa 128 bits del material de clave, por lo que no se usa parte de dicho material. La razón es que resulta más sencillo eliminar los bits que no son necesarios que cambiar la infraestructura de administración de claves ya que la longitud de éstas puede variar.

La longitud del bloque puede ser cualquier potencia de dos, dentro del intervalo comprendido entre los 512 y los 8.192 bytes. Para garantizar que cualquier modificación del texto cifrado tenga como resultado la modificación aleatoria de todo el texto sin formato del sector, el cifrado de bloques está diseñado para reaccionar en función de este tamaño de bloque variable. Además, si se comporta como un cifrado de bloques modificable (tal como lo describen Liskov, Rivest y Wagner), y el algoritmo cambia ligeramente entre sector y sector, un adversario no podrá mover correctamente un texto cifrado de un sector a otro.

El tiempo lo dirá

Al especular acerca del árbol de la seguridad criptográfica de BitLocker se pierde la noción de todo el bosque del proyecto. Para BitLocker, la seguridad no es suficiente para funcionar, ya que BitLocker no es una solución independiente, si no uno de los apéndices de Windows Vista. Microsoft afirma que BitLocker está integrado perfectamente en Windows Vista. Pero si está perfecta integración con el sistema operativo es real, ¿no es posible que el error de otro componente pueda provocar un error en BitLocker o ponerlo en peligro?

Personalmente, soy partidario del trabajo por módulos y del aislamiento de errores. La integración total sin modularidad implica complejidad. De acuerdo, es posible que éste no sea el caso de Windows Vista y BitLocker, pero sólo el tiempo y un análisis exhaustivo lo dirán.

Entonces, ¿qué opino de BitLocker? Me quito el sombrero ante el equipo de integridad del sistema de Microsoft por confiar en criptógrafos auténticos y confiables, que han trabajado como deben hacerlo los criptógrafos. Es obvio que esta característica se ha diseñado en aras de la criptografía y no de una campaña de marketing. Por tanto, mi respuesta es que BitLocker se debe tomar en serio. Tenga en cuenta que esto deja a un lado la opinión acerca de la perfección de su seguridad. De nuevo, lo dirá el tiempo y su evaluación en el mundo real. Se han roto muchos protocolos y primitivos criptográficos, pero como mínimo, el equipo de integridad del sistema de Microsoft nos ha proporcionado información y plataformas en las que crear soluciones aún mejores.

Justin Troutman es un criptógrafo en aprendizaje y estudiante universitario de matemáticas. Su trabajo se centra principalmente en la criptografía simétrica. Además es el fundador de Extorque, empresa especializada en la investigación y la consultoría criptográficas.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.