Redefiniendo la seguridad del firmware

Un artículo reciente enfatizó la amenaza de ataques basados ​​en firmware en plataformas de servidor y explicó en detalle cómo un proveedor de servicios como Cloudflare puede defender su plataforma. Se analizó la implementación de una raíz de confianza de hardware para la firma de código de entidades de arranque críticas, lo que permite que el hardware se convierta en una primera línea de defensa para garantizar que la integridad del software y el hardware del servidor pueda generar confianza a través de medios criptográficos y, lo que es más importante, defender a los clientes contra tales ataques. . El artículo concluyó con una mirada al futuro e indicó que, si bien la solución funciona para el presente, siempre hay margen de mejora como parte de un esfuerzo continuo por brindar la mejor seguridad de la industria.

Este artículo continúa esta discusión al revisar los vectores potencialmente no abordados inherentes a las plataformas actuales y ofrece una vista previa de una solución óptima para prevenir ataques de firmware y elevar la seguridad de la plataforma al siguiente nivel, basada en el procesador de seguridad de la unidad de control / computación (TCU) confiable de Axiado.

Enraizamiento de la confianza en el firmware

El problema clave es la suposición implícita de la seguridad de la raíz de confianza (RoT) en la cadena de arranque. Ubicado en el firmware de la Interfaz de firmware extensible unificada (UEFI), se supone que el RoT no es un objetivo potencial para un ataque. Esta suposición ha demostrado ser peligrosa, como lo demuestra el crecimiento de los ataques basados ​​en firmware a lo largo de los años, y en particular, más de diez veces en 2019 en comparación con 2010. Los piratas informáticos pronto se dieron cuenta de que, al corromper este firmware, el módulo de plataforma confiable (TPM) Las mediciones con fines de atestación remota también podrían estar dañadas, ya que las mediciones se basan en la interacción con el firmware para validar dichas mediciones (no se le llama "raíz de confianza" por nada). Para garantizar la integridad de la plataforma, es imperativo que el firmware UEFI esté autenticado, es decir, se promulgue una política de confianza cero en el RoT.

Solución inicial

Para abordar este problema, las empresas han dado el importante paso de autenticar el firmware UEFI en sus servidores con Cloudflare utilizando el procesador AMD EPYC que admite esta autenticación. El subsistema de seguridad de hardware de EPYC llamado AMD Secure Processor realiza una función llamada plataforma de arranque seguro (PSB) que autentica el primer bloque de UEFI antes de liberar la CPU principal del reinicio. PSB es la implementación de AMD de integridad de arranque con raíz de hardware. Es mejor que la raíz de confianza basada en firmware UEFI porque pretende afirmar, mediante una raíz de confianza anclada en el hardware, la integridad y autenticidad de la imagen de la ROM del sistema antes de que pueda ejecutarse. Lo hace realizando las siguientes acciones:

• Autentica el primer bloque de BIOS / UEFI antes de liberar las CPU x86 del reinicio.
• Autentica el contenido de la memoria de solo lectura (ROM) del sistema en cada inicio, no solo durante las actualizaciones.
• Mueve la cadena de confianza de arranque seguro UEFI a hardware inmutable.

Esto se logra mediante el procesador de seguridad de la plataforma AMD (PSP), un microcontrolador ARM Cortex-A5 que es una parte inmutable del sistema en chip (SoC).

Con este enfoque, Cloudflare ha habilitado una solución que parece abordar sus necesidades de autenticación de firmware UEFI.

Problemas con el arranque seguro UEFI

Controladores no autenticados

Un componente común que se encuentra en casi todos los servidores es un controlador de administración de placa base (BMC). Los BMC tienen múltiples conexiones al sistema host, lo que brinda la capacidad de monitorear el hardware, actualizar el firmware BIOS / UEFI, otorgar acceso a la consola a través de KVM en serie o físico / virtual, apagar y encender los servidores y registrar eventos.

Como parte de la cadena de inicio, el método de firma actual de PSB no aborda la firma del BMC, lo que limita la extensión del límite de confianza a un controlador que tiene muchas interfaces con los componentes del sistema.

Arranque con una CPU específica de la plataforma

La incorporación de la autenticación de firmware UEFI dentro de un bloque que está integrado en la CPU principal de un servidor presenta problemas de logística en el área de gestión de la unidad de mantenimiento de existencias (SKU). Uno de esos problemas implica bloquear una CPU en una plataforma en particular. Con la autenticación UEFI y las claves criptográficas relacionadas vinculadas tanto al código en el flash de arranque integrado como a la CPU AMD EPYC, todo debe estar presente en la plataforma para que el servidor arranque correctamente. Sin embargo, esto limita la capacidad de actualizar o cambiar una CPU en esa placa base. Este efecto secundario se ha observado en el mercado de revendedores de valor agregado, ya que los dispositivos EPYC que utilizan la función PSB no se pueden intercambiar. Algunas empresas (como HPE) han reconocido esta limitación y han desactivado la función PSB en sus servidores basados ​​en EPYC, optando por autenticar su firmware UEFI externamente con su solución de silicio interna en su lugar.

Axiado cree que un coprocesador externo que maneja la autenticación de firmware UEFI al tiempo que permite la flexibilidad de la CPU es ideal para la industria en general.

Desafíos con múltiples plataformas

Otro problema relacionado con la administración de SKU se relaciona con la administración de plataformas con potencialmente múltiples metodologías de arranque seguro. Una implementación de servidores en un centro de datos puede incluir una combinación de procesadores, como Intel, AMD y Arm, cada uno con su dirección de implementación de la autenticación de firmware UEFI. Este escenario puede causar una carga indebida con la administración de diferentes metodologías de arranque seguro / raíz de confianza de cada proveedor de CPU.

Por lo tanto, un coprocesador externo para manejar la autenticación de firmware UEFI con flexibilidad de CPU es ideal para la industria en general.

¿Una posible ventanilla única para una seguridad de firmware óptima?

Una solución que permite una ventanilla única para las necesidades de seguridad, mientras que al mismo tiempo mejora la seguridad del firmware y no agrega componentes a la lista de materiales, es el coprocesador confiable de la unidad de control / computación (TCU) de Axiado. Esto ofrece la mejor autenticación de firmware UEFI de su clase para una solución de arranque seguro uniforme en todos los SKU, sin importar la elección de la empresa en el proveedor principal de CPU, y todo sin agregar componentes a la plataforma.

Como coprocesador en un servidor, Axiado TCU asume la función del chip del controlador de gestión de la placa base (BMC), por lo que este dispositivo no requiere espacio adicional en el servidor. La TCU es responsable de la certificación de todos los componentes del sistema, incluido él mismo. Ofrece una atractiva solución de consolidación de componentes al admitir toda la funcionalidad heredada que se espera de un dispositivo BMC e incluir una funcionalidad adicional que permite a TCU asumir el papel de módulo de plataforma confiable (TPM) y dispositivo lógico programable complejo (CPLD) que se encuentra en los servidores.

En el corazón de TCU se encuentra la tecnología de bóveda segura patentada por Axiado, que proporciona autenticación de firmware UEFI basada en hardware inmutable y resistente a manipulaciones y arranque seguro. Entre otras cosas, esta tecnología incluye protecciones contra ataques de análisis de poder diferencial que se utilizan para realizar ingeniería inversa en las claves criptográficas que brindan a los piratas informáticos acceso a información privada cifrada.

La TCU incluye una tecnología de inteligencia artificial segura con un subsistema de procesador de red neuronal (NNP) dedicado diseñado para modelar el comportamiento normal del dispositivo y, por lo tanto, para identificar anomalías que podrían indicar la presencia de un ataque. Esto permite adoptar las contramedidas necesarias para proteger el sistema antes de los ataques, incluidos los que no se han identificado formalmente. Además, el NNP tiene conexiones a varias E / S del dispositivo, por lo que puede modelar el comportamiento normal e identificar anomalías de la plataforma del servidor en general, expandiendo el radio de protección de la TCU contra intentos de piratería.

Al ofrecer una solución de coprocesador de seguridad, Axiado resuelve los problemas presentados en este artículo con respecto a las ofertas de SKU. Primero, una única solución minimiza la cantidad de superficies de ataque que los piratas informáticos pueden intentar explotar en toda una línea de SKU. No es necesario protegerse contra ataques a AMD, Intel, Arm y las soluciones de seguridad de otros proveedores. Esto también simplifica la administración y el mantenimiento de las implementaciones de SKU del servidor, minimizando el número de variantes de actualización de firmware / software de la plataforma. En segundo lugar, al descargar el subsistema de arranque seguro a la TCU, la CPU ya no está bloqueada en el hardware del servidor específico. Entonces, uno puede tener la libertad de mezclar y combinar CPU en diferentes variantes de hardware y realizar actualizaciones sin tener que pasar por la tarea de configurar la CPU para el hardware específico en el que está instalada.

En resumen, el coprocesador TCU proporciona una solución de protección de firmware UEFI basada en hardware uniforme y segura para todas sus plataformas, con la capacidad de aprender nuevos ataques incluso antes de que sean reconocidos formalmente. Esto permite una red segura impulsada por subsistemas de CPU de alto rendimiento y ricos en funciones, junto con una red que es más fácil de administrar y mantener.