El arranque seguro (del inglés - "secure boot") es un protocolo que forma parte de la especificación UEFI [1] . Consiste en verificar la firma digital electrónica de las aplicaciones EFI en ejecución mediante criptografía asimétrica con respecto a las claves almacenadas en el almacén de claves del sistema.
En 2011, Microsoft incluyó en los requisitos para la certificación de equipos que ejecutan Windows 8 la condición de entrega de dichos sistemas con arranque seguro habilitado mediante una clave de Microsoft. Además, los sistemas ARM (teléfonos inteligentes y algunas computadoras portátiles) requerían la incapacidad de deshabilitar el Arranque seguro. Esto provocó un gran clamor público y críticas hacia Microsoft, ya que tales requisitos hacían mucho más difícil, y en el caso de los sistemas ARM, instalar sistemas operativos distintos a Microsoft Windows [2] [3] [4] .
Variable autenticada: variables que requieren autenticación para cambiar. El arranque seguro implica almacenar claves públicas, firmas y hashes de aplicaciones en variables autenticadas almacenadas en memoria no volátil. Dichas variables se pueden sobrescribir de dos maneras [5] [6] [7] :
La transición a este modo es posible desde el modo de usuario borrando el PK.
Este modo no requiere autenticación para escribir PK, KEK, db, dbx.
La entrada PK pone el sistema en modo de usuario. Escribir una unidad en la variable especial AuditMode (solo se puede escribir en el modo de configuración y en el modo de usuario) pone el sistema en modo de auditoría.
Modo de auditoría (modo de auditoría)Es posible cambiar a este modo desde el modo de configuración o el modo de usuario escribiendo una unidad en la variable AuditMode. Cuando cambia el modo al modo de auditoría, el PK se borra.
Este modo no requiere autenticación para escribir PK, KEK, db, dbx. En el modo de auditoría, se pueden iniciar imágenes no verificadas y la información sobre todas las etapas de validación de imágenes se registrará en una tabla especial accesible desde el sistema operativo, lo que le permite probar combinaciones de claves y firmas guardadas sin temor a perder el sistema [9 ] .
La entrada PK pone el sistema en modo implementado.
Modo de usuario (modo de usuario)Es posible cambiar a este modo desde el modo de configuración mediante la entrada de PK, o desde el modo implementado utilizando un método dependiente de la plataforma (no especificado en la especificación).
Este modo requiere autenticación para cambiar los almacenes de claves y valida las imágenes de inicio.
Quitar el PK pone el sistema en modo de configuración. Escribir 1 en la variable AuditMode pone el sistema en modo de auditoría. Escribir uno en la variable DeployedMode (solo se puede escribir en modo de usuario) pone el sistema en modo implementado.
Modo desplegadoEs posible cambiar a este modo desde el modo de auditoría escribiendo PK, o desde el modo de usuario escribiendo uno en la variable DeployedMode.
El modo más seguro [9] . Se diferencia del modo de usuario al establecer todas las variables de modo (AuditMode, DeployedMode, SetupMode) en modo de solo lectura.
El cambio a otros modos (modo personalizado o de configuración) solo es posible a través de métodos específicos de la plataforma o borrado de PK autenticado [9] .
Antes de ejecutar una imagen UEFI desconocida, debe pasar por un proceso de autorización.
La actualización de la base de datos de aplicaciones confiables también está disponible desde el sistema operativo [10] .
El usuario puede generar e instalar de forma independiente sus propias claves. Génelos usted mismo, fírmelos e instálelos en su computadora. El "ciclo completo" de generación de claves se implementa para los sistemas operativos Linux y Windows.
Como regla, la siguiente cadena de transformaciones se utiliza en el proceso de generación de claves:
PEM => DER => ESL => AUTORIZACIÓN
Para Windows, hay herramientas especiales de Microsoft, y en Linux, se utilizan OpenSSL y el conjunto de utilidades EfiTools. Existe un problema relacionado con la falta de una interfaz para configurar claves personalizadas en el BIOS de algunos fabricantes. Esto también requiere a veces una utilidad separada.
La complejidad adicional crea la necesidad de garantizar la compatibilidad con equipos de Microsoft en algunos casos. La verificación funciona en ambos sentidos y sin claves de Microsoft, su software y hardware (por ejemplo, controladores GOP para tarjetas de video externas y controladores PXE para tarjetas de red externas y, por lo tanto, las propias tarjetas) no funcionarán. Es decir, en un cierto nivel, deberá confiar en MS en cualquier caso.
El usuario deberá agregar la clave de Microsoft a la base de datos o KEK, lo que presenta riesgos de seguridad adicionales.
Puede haber varios KEK y db en una computadora. De esta manera, se pueden formar varias ramas de confianza. O viceversa, un db puede estar firmado por varios KEC (aunque esto no es obligatorio)
HP Sure Start, una solución de Hewlett-Packard, es en realidad una SDZ de hardware y software integrada. Implementa la función de protección de clave de arranque seguro. Microsoft ofrece el arranque seguro en su forma actual como un estándar de seguridad mínimo para la protección contra rootkits. Al mismo tiempo, algunos fabricantes desarrollan sus propias soluciones que brindan un arranque confiable junto con una solución de Microsoft, un ejemplo de tal solución es HP Sure Start [11] .
Cuando los rootkits interfieren con los componentes críticos del sistema operativo, las firmas de los componentes correspondientes se vuelven inválidas. Tal sistema operativo simplemente no se cargará [12] .
Si es necesario, limite la lista de posibles sistemas operativos para ejecutar, esto se puede hacer ingresando las firmas apropiadas en la base de datos de firmas [12] .
Los controladores de dispositivos que requieren soporte en la etapa de arranque del sistema deben tener una firma que pase correctamente la verificación en todas las plataformas donde se pueden usar dichos dispositivos. Para ello, todos los fabricantes de dichos equipos tendrán que ponerse de acuerdo con todos los fabricantes de plataformas para añadir sus claves a las tiendas del sistema. O dichos controladores deberán firmarse con una clave que ya está incluida en la mayoría de las plataformas, pero luego los fabricantes tendrán que confiar completamente en el propietario de dicha clave (por ejemplo, Microsoft firma el gestor de arranque shim [13] [14] ) . También es posible crear firmas en una cadena que termine con una clave contenida en la mayoría de las plataformas, pero incluso este enfoque tiene un inconveniente: cuando la clave correspondiente se elimina del almacén de claves (por ejemplo, para prohibir la carga de un determinado sistema operativo) , las firmas de los controladores también se vuelven inválidas [12] .
Los proveedores de sistemas no están obligados a implementar la capacidad de desactivar el Arranque seguro. El procedimiento para agregar claves de terceros a la bóveda debe ser inaccesible para software malicioso, lo que dificulta este procedimiento para los usuarios. Estos dos factores juntos hacen mucho más difícil el uso de sistemas operativos no firmados, así como aquellos firmados con una clave desconocida para la plataforma [12] .
Las implementaciones de firmware específicas de dispositivos de diferentes fabricantes pueden contener vulnerabilidades, cuya explotación puede conducir a la omisión del mecanismo de arranque seguro o su nivelación [15] [16] .
El mecanismo de arranque seguro puede impedir que funcionen las herramientas de arranque de confianza. Dado que SDZ reemplaza el cargador de arranque del sistema operativo con su propio cargador de arranque, que generalmente no tiene una firma, Secure Boot puede bloquear el cargador de arranque SDZ y, por lo tanto, interferir con el funcionamiento de SDZ en su conjunto.
Hay dos soluciones para este problema.
El primero es deshabilitar el arranque seguro en computadoras con SDZ instalado. Un ejemplo de este enfoque es SDZ SafeNode System Loader [17] .
El segundo es la entrega de un conjunto de variables autenticadas junto con SDZ, certificando la validez de la firma del cargador. Después de configurar las variables, SDZ funcionará sin restricciones desde el arranque seguro. Un ejemplo de este enfoque es Dallas Lock SDZ. En este caso, la utilidad keytool.efi [18] también se suministra con las claves .