SUSE y el Arranque Seguro: Los detalles

En este artículo podrás encontrar la traducción del artículo escrito en inglés por Vojtěch Pavlík: “SUSE and Secure Boot: The Details” una visión interesante de SUSE ante UEFI.

Desde los blogs de SUSE Olaf Kirch y Vojtěch Pavlík nos han dado una visión de los planes de esta empresa de GNU/Linux ante la nueva medida UEFI y Arranque Seguro. Estos son los planteamientos propuestos por SUSE.

openSUSE es una comunidad aparte que puede tomar sus propias decisiones, pero siempre está bien saber qué es lo que dicen los desarrolladores de SUSE y cuales son sus medidas ante esta nueva característica de seguridad.

GRACIAS a Vojtěch Pavlík por permitirme la traducción y la publicación de su artículo. Puedes ver el original en este enlace: www.suse.com/blogs/uefi-secure-boot-details/

GRACIAS también a Javier Llorente, miembro destacado de la comunidad de openSUSE por sacar tiempo de sus múltiples proyectos y su tiempo libre y ayudarme a corregir la traducción, bueno, y por todo!! ;)

Espero que aclare un poco la forma en la que SUSE tratará de mantener la libertad en tu PC y al mismo tiempo no renunciar a la seguridad del mismo. Vamos con la traducción:

En artículos anteriores Olaf Kirch nos ha hecho una introducción sobre el arranque seguro UEFI y el enfoque de SUSE sobre cómo abordar este tema. En este artículo os daré los detalles técnicos de nuestro plan sobre el arranque seguro. Así que prepararos para un artículo un tanto minucioso y técnico.

El objetivo del arranque seguro es prevenir que el malware se esconda de forma embebida durante el proceso de arranque realizando una comprobación de todos los componentes y tareas que se ejecuten durante un arranque en frío de todo el sistema.

Para lograr su objetivo, el arranque seguro debe impedir cualquier modificación del proceso de verificación, de las llaves, o de cualquier otra variable como código no confiable o entidades que no sean de confianza. Un ejemplo de una entidad en la que no se confía podría ser un pirata informático que ha penetrado en el sistema a través de un agujero de seguridad sin parchear en el sistema operativo.

Hay dos tipos de usuarios en los que se puede confiar:

  1. Primero, aquellos que tienen las llaves. La llave de la plataforma (Platform Key ó PK) permite casi todo. La llave de intercambio de llaves (Key Exchange Key ó KEK) permite todo, excepto que una PK pueda cambiar la PK.
  2. Segundo, cualquiera con acceso físico a la máquina. Un usuario con acceso físico puede reiniciar la máquina, y configurar el UEFI.

El arranque seguro UEFI ofrece dos tipos de variables para satisfacer las necesidades de los usuarios:

  1. La primera son las denominadas “variables autenticadas” – “Authenticated Variables” en inglés. Que se pueden actualizar tanto durante el proceso de arranque (denominado Entorno de Servicios de Arranque – Boot Services Environment) o desde el sistema operativo, pero sólo cuando el nuevo valor de la variable este firmada con la misma llave que el valor antiguo con el que la variable se firmó . Y sólo se puede añadir o cambiar a un valor con un número de serie mayor.
  2. La segunda es la denominada “variables exclusivas para Servicios de Arranque” – “Boot Services Only Variables”. Estas variables son accesibles para cualquier código que se ejecuta durante el proceso de arranque. Después de que el proceso de arranque termine y antes de que se inicie el sistema operativo, el gestor de arranque debe llamar a ExitBootServices(). Después de eso, estas variables ya no son accesibles, el sistema operativo no las puede tocar.

Las diferentes listas de llaves UEFI son del primer tipo, ya que esto permite la actualización on-line, añadir y poner en una lista negra de llaves, huellas digitales de controladores y firmware. El segundo tipo de variables, “variables exclusivas para servicios de arranque” son las que nos ayudarán en nuestra búsqueda de una implementación de arranque seguro que sea a la vez segura y compatible con la filosofía de código abierto. Y compatible con la GPLv3.

Como Olaf explicó en el anterior artículo, en SUSE hemos empezado desarrollando una “aplicación cuña” basada en la de Fedora, firmada con un certificado firmado por el KEK de SUSE o con un certificado emitido por Microsoft, basado en las KEK’s que están disponibles en la base de datos de llaves de UEFI del sistema

Esto permite a esta aplicación cuña cargarse y ejecutarse.

Esta aplicación cuña arranca para verificar que el gestor de arranque GRUB2 que quiere arrancar es de confianza. Para ésto no usará ni la KEK de SUSE ni el certificado emitido por Microsoft. En una situación por defecto, la aplicación cuña usará un certificado de SUSE independiente embebido en su código. Además, la aplicación cuña permitirá “grabar” nuevas llaves, reemplazando la llave de SUSE por defecto. A estas las llamaremos “llaves propietarias de la máquina – Machine Owner Keys” lo que para abreviar llamaremos MOKs

El proceso de grabado empieza reiniciando la máquina e interrumpiendo el proceso de arranque (por ejemplo, pulsando una tecla) mientras la aplicación cuña arranca. La aplicación cuña entrará entonces en un modo de grabado, permitiendo al usuario reemplazar la llave por defecto de SUSE con llaves que están en un fichero en la partición de arranque.

Si el usuario elige hacer ésto, la aplicación cuña entonces calculará un nuevo hash de ese archivo y pondrá el resultado en una variable “exclusivas para servicios de arranque”. Ésto permite a la aplicación cuña detectar cualquier cambio del fichero hecho fuera de los servicios de arranque y evitar así la manipulación usando la lista de usuarios autorizados de MOKs.

Un aspecto importante a tener en cuenta es que todo ésto pasa durante el tiempo de arranque, en el cual sólo se ejecuta código verificado. Por lo tanto, sólo un usuario presente delante de la consola puede decir “quiero usar mi propio juego de llaves”. Cosa que no podrían hacer ni un pirata informático ni malware con acceso remoto a nuestro PC, ya que los piratas o el malware sólo pueden cambiar el archivo pero no el hash almacenado en las variables exclusivas para los servicios de arranque.

Una vez cargado y verificado GRUB2 por la aplicación cuña, volverá a llamar a esta aplicación cuña cuando quiera verificar el kernel, para evitar la duplicación de verificación de código. La cuña utilizará la misma lista que MOKs para esto y dirá a GRUB2 si se puede cargar el kernel o no.

¡Y ésto es todo!

Ésto es todo lo que necesitas para ser capaz de trabajar mejorando el kernel o el gestor de arranque. Instalar un nuevo juego de llaves y autorizarlas in situ durante el primer reinicio.

También gracias a que los MOKs son una lista y no una sola MOK, puedes hacer que el proceso intermedio o cuña valide llaves de varios fabricantes diferentes, permitiendo un arranque no sólo dual, sino múltiple desde el GRUB2 del gestor de arranque.

Al final la implementación real de este sistema puede ser algo más complicada, por ejemplo, proteger con contraseña la autorización de MOK para permitir una actualización autentificada y segura de la lista de MOKs desde el propio sistema operativo, pero este es el quid de la cuestión, y como puedes modificar libremente el GRUB2 y el kernel de una máquina, puedes estar tranquilo ya que tu máquina seguirá cumpliendo la licencia GPLv3 y no será tivoizada (saltarse a la torera la licencia)

Quizás te preguntes si ésto va en contra de lo que permiten las especificaciones UEFI o de los requisitos del logo de Win8 de Microsoft o de cualquier otro contrato relacionado.

Yo no creo eso – incluso las especificaciones de la UEFI permiten, pero no obligan, que la implementación UEFI permita a un usuario autorizar código EFI con una firma no válida añadiendo un hash a una variable especial.

Y la Linux Foundation ha preguntado a los fabricantes para asegurarse de que incluyan una manera de limpiar los PK para permitir a el usuario grabar su propio juego de llaves.

Nuestro enfoque es simplemente asegurarse que una característica como ésta está disponible en todas partes. Y mantener libre la plataforma “PC”.

—————————————————-

Si quieres, puedes descargarte el documento traducido en PDF pinchando en este botón:   

NOTA:

About these ads

2 pensamientos en “SUSE y el Arranque Seguro: Los detalles

  1. Según lo que entiendí, todo el aspecto de integridad de una computadora, que es de mi propiedad, depende de lo que se grabe en el BIOS. Esto permite el acceso a la GRUB y al consecuente arranque del DD (donde se almacena la información, SO, programas, archivos, etc.) y utilizar el sistema.
    Entonces, la guerra esta en en este lugar, en una porción del BIOS de la que Window$ quiere apoderarse para no permitir más ingreso que a su SO y poseer la casa (computadora) de la cuál soy dueño y responsable de su integridad.
    ¿es esto así?

Me gustaría saber tu opinión. Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s