Sobre el Cifrado Completo de Disco ("Full Disk Encryption")
La semana pasada llegaba las portadas de muchos medios informáticos la noticia de que Barnes & Noble había decidido retirar de la venta un artículo titulado "Learn to Hack". Esto provocó, como era de esperar, que el susodicho artículo (disponible en http://www.tuxradar.com/content/learn-hack/) tuviese una difusión mucho mayor.
En dicho artículo se mencionaba la fragilidad de los sistemas de cifrado parcial de disco ofrecidos por algunas distribuciones (Fedora, Ubuntu, por ejemplo) de Linux. En dichos esquemas, la partición del sistema operativo y programas no está cifrada, pero se cifra la partición /home, donde los usuarios guardan sus datos personales.
Partimos de la base de que si ciframos un disco es para que en caso de que nos roben o se extravíe el equipo, los datos valiosos que contenga (dejemos que cada uno defina "valiosos" como prefiera) no caigan en manos de quien no los debe tener. Es decir, intentamos proteger los datos de un ataque al equipo en el que el atacante tiene acceso físico al equipo.
Con esta premisa, el artículo explicaba cómo este método de protección parcial de datos era ineficaz: el atacante que nos ha robado el equipo puede desconectar el disco duro, conectarlo a otro equipo, poner un programa especial en el arranque de la máquina (un troyano) que se encargue de conectar automáticamente con el ordenador del atacante, y volver a dejarnos el equipo disponible como si nada hubiese pasado (y un escenario mucho más plausible aún: esto nos puede pasar en un rato en el que perdemos de vista nuestro equipo, sin que ni siquiera nos demos cuenta de que nos lo han sustraído)...
Con este ataque, el atacante solo tiene que esperar a que el usuario vuelva a iniciar sesión en su ordenador (ahora "troyanizado"), y a que introduzca la clave para desbloquear el dispositivo cifrado. Una vez hecho esto, el atacante, a través de la conexión remota del troyano, puede acceder sin problemas a los datos prohibidos, ya que estos están disponibles para el usuario, los acaba de desbloquear.
Este ataque puede ampliarse a otro tipo de troyanos, como uno que pida la clave de forma idéntica que el sistema para luego enviarla por red al atacante (una especie de "phishing local").
En fin, la conclusión es que si tenemos una parte del disco abierta, el sistema entero está comprometido si lo perdemos de vista.
Solución 1: el Cifrado Completo de Disco ("Full Disk Encryption")
La supuesta solución a este tipo de ataques es usar la solución de Cifrado Completo de Disco que incluyen las distribuciones desde hace tiempo. Este esquema hace que solo una pequeña partición (normalmente /boot, cuyos contenidos además, suelen ser prácticamente idénticos en todas las instalaciones de una misma versión de distribución) esté disponible sin cifrar, y el resto del disco se configura como un volumen LUKS cifrado. Sobre este volumen se definen después los volúmenes lógicos necesarios para la partición root, el espacio de swap
(también cifrado), etc. En el mismo arranque de la máquina, el propio sistema pide la clave para abrir el dispositivo LUKS, de forma que si no la proporcionamos, el kernel ni siquiera es capaz de montar la partición raíz, y por tanto no arranca. Aparentemente estamos seguros con este esquema, no?
La realidad es que no. Este esquema tiene el mismo problema que el del cifrado parcial: tenemos una parte del disco que es accesible y modificable sin clave, y es precisamente la partición /boot. ¿Y cómo podemos instalar un troyano en la partición boot? Pues usando la imagen "initrd" que todos los sistemas de arranque de Linux usan hoy en día: un sistema Linux en miniatura que se ejecuta en memoria y que es el que muestra las bonitas pantallas de inicio de Ubuntu y Fedora, y además entre otras cosas, el que se encarga de pedirnos la clave para desbloquear el volumen LUKS que da acceso al sistema de ficheros raíz.
Es cierto que incluir un troyano en el "initrd" no es tan sencillo como ponerlo directamente en la partición raíz, pero no es mucho más complicado: el formato del "initrd" está perfectamente documentado y las herramientas para reconstruirlo son libres (por supuesto!). De hecho, cada vez que actualizamos el kernel de nuestra distribución, el initrd se reconstruye con los módulos y la configuración del nuevo kernel instalado.
Así que seguimos como antes: ni siquiera con Cifrado Completo de Disco estamos a salvo de un ataque con acceso físico al equipo.
Solución 2: Firma digital de imágenes initrd
Una posible solución al problema anterior podría ser la siguiente: si la imagen initrd está firmada con una clave pública, y si GRUB soportase imágenes initrd firmadas, GRUB podría comprobar la firma y rechazar el arranque en caso de que el initrd hubiese sido manipulado.
GRUB no tiene este soporte aún, pero sería interesante proponerlo a los autores como una funcionalidad deseable. Si GRUB guarda una serie de certificados válidos para firmar initrd's (los de los fabricantes, p.e. RedHat, Ubuntu, Debian, etc.), al menos tendríamos una forma de validar la imagen initrd y contar con un entorno seguro. Esto originaría sin embargo otros problemas, como por ejemplo la imposibilidad de arrancar kernels compilados por el usuario, etc.
Sin embargo, este sistema también está viciado. El propio GRUB (o algo de su código al menos) se almacena en una zona del disco que necesitamos que esté disponible sin cifrar: el MBR (master Boot Record). Aunque tuviésemos el /boot cifrado, o las imágenes initrd firmadas digitalmente, nada impide al atacante sustituir el gestor de arranque del MBR por otro código que contenga el código "troyanizado", o que ejecute initrds sin firmar.
Como vemos, a medida que vamos tirando del hilo se va reduciendo el espacio sin cifrar (o firmar digitalmente) del disco a proteger. Sin embargo, hemos llegado al mínimo imprescindible: 1 sector, el MBR. También es cierto que a medida que el espacio de disco sin cifrar o autenticar se reduce, aumenta la complejidad del ataque y la experiencia necesaria de quien lo tiene que ejecutar, pero el hecho es que sigue siendo posible.
La conclusión es que para tener el disco completamente protegido, debemos cifrarlo (o firmarlo digitalmente) de forma TOTAL para evitar su modificación, incluido el MBR. No nos vale el "Full Disk Encryption" y necesitamos, por tanto, ir un paso más atrás en el proceso de arranque del sistema: la BIOS.
Solución 3: Cifrado hardware de disco completo ("Hardware Based Full Disk Encryption")
Desde hace unos años, los discos duros tienen la capacidad de cifrar los datos antes de escribirlos en el soporte magnético. En teoría estos cifrados son potentes, y muchos fabricantes los ofrecen de serie. La BIOS se encarga normalmente de pedir la clave que desbloquea el disco y de enviarla al aparato, que a partir de entonces se comporta como un disco normal, sin pérdida de rendimiento, pero manteniendo los datos cifrados en el soporte.
Aunque hace algún tiempo hubo noticias de algún fabricante prometiendo que sus discos usaban AES como método de cifrado hardware, cuando en realidad estaban usando un simple XOR, parece que actualmente estos sistemas son seguros.
¿Seguro? Pues no del todo. Volvemos a estar en una tesitura parecida a las anteriores: el atacante puede haber "troyanizado" la propia BIOS (es complejo, pero puede hacerse, la inmensa mayoría de las BIOS actuales son actualizables por software), de forma que puede a su vez infectar el gestor de arranque, y entonces volvemos a estar en el problema anterior (GRUB troyanizado).
Para evitar el problema de la BIOS troyana, debemos protegerla.
Solución 4: Entorno Seguro de Arranque
Básicamente consiste en un entorno en el que el sistema de arranque (el equivalente a la BIOS) está firmado digitalmente, y el propio sistema de arranque se niega a ejecutarse en caso de haber sido manipulado. Las claves públicas y el código que realiza la verificación del entorno de arranque se encuentran disponibles en un chip que no se puede actualizar (idealmente ROM).
Finalmente, a base de tirar del hilo, hemos llegado a la solución al problema: un sistema que permite la verificación de todo el proceso de arranque porque su código y claves están en ROM y no pueden ser manipuladas.
En cualquier caso, incluso aunque los fabricantes de Linux se encargasen de poner en los módulos hardware sus propios certificados, este esquema impediría la instalación de kernels a medida compilados por nosotros mismos, y en general el "cacharreo" con nuestros propios sistemas.
Conclusión
Parece que la conclusión obligatoria es que si queremos tener total seguridad con nuestros datos, todo pasa por disponer de un entorno hardware cuyo código no se pueda modificar. Sin embargo, este entorno hardware se da de tortas con la filosofía del software libre, todo debe poder abrirse y modificarse a nuestro gusto.
De hecho este esquema, que a nosotros nos ha servido para garantizar la seguridad de nuestros datos, puede usarse también para propósitos perversos. Este mismo esquema es el usado por Microsoft en Windows 8, con su tecnología "Secure Boot", para evitar que se instale en el equipo otro software que no sea de Microsoft (incluyendo Linux). Solo tiene que convencer a los fabricantes de placas base para que en sus módulos hardware solo incluyan claves de Microsoft.
Una posible solución a esto sería disponer de placas base en el que nosotros pudiésemos cambiar las claves de firma a base de cambiar el chip donde están almacenadas y que esos chips fuesen de un solo uso (como las antiguas PROM). Pero por otro lado, ¿quién nos garantiza que el programa o aparato que grabe esos chips no introduce además su propio certificado, que a su vez permite arrancar código troyanizado, lo que puede pervertir el gestor de arranque, y con eso acceder al disco... etc. etc.?
La solución más práctica desde mi punto de vista es, como siempre, la de compromiso: ¿Cuánto valen mis datos como para que alguien invierta dinero en craquear mi equipo? ¿Valen 300 EUR que vale contratar a un experto en Linux un par de horas para saltar el "Full Disk Encryption" de las distribuciones Linux? ¿Valen los 20.000 EUR (por ejemplo) que pueda valer contratar a alguien experto que pueda troyanizar una BIOS? ¿Valen los (posibles) varios millones de euros necesarios para disponer de un equipo capaz de sustituir el modulo TPM de una placa con Secure Boot?
De la respuesta a estas preguntas deberemos sacar nuestras propias conclusiones sobre el tipo de cifrado que necesitamos. Porque, recordemos, la seguridad absoluta no existe (desgraciadamente).
