Reducción de la superficie expuesta a ataques de firmware (FASR)

En octubre de 2019, Microsoft trabajó estrechamente con nuestros asociados oem y Silicon para lanzar equipos de núcleo protegido. Estos dispositivos cuentan con hardware, firmware y software profundamente integrados para ayudar a garantizar una mayor seguridad para los dispositivos, la identidad y los datos. Uno de los pilares de seguridad principales de los equipos de núcleo protegido es ayudar a ofrecer protección de firmware para dispositivos. Una característica fundamental basada en hardware necesaria para satisfacer este pilar es la raíz dinámica de confianza para la medición (D-RTM). Sin embargo, actualmente no hay muchos dispositivos que ofrecen D-RTM debido a la dependencia del conjunto de chips subyacente para admitir esta funcionalidad, lo que impide nuestro compromiso de ayudar a elevar y mantener una barra de seguridad alta para todos los dispositivos Windows.

Se puede hacer más para mejorar la posición de seguridad de todos los dispositivos Windows, incluidos los que no tienen D-RTM. Para ayudar a cerrar esta brecha, Microsoft ha empezado a trabajar con asociados para superar los problemas de compatibilidad que han impedido que se apliquen protecciones de memoria en el firmware UEFI mediante el desarrollo de un conjunto de mejoras de seguridad SMM de código abierto para proporcionar flexibilidad adicional para que los OEM puedan aprovechar.

Para reflejar este compromiso con la seguridad del firmware, hemos identificado un nuevo enfoque para garantizar que los dispositivos puedan cumplir los requisitos de protección de firmware de los equipos de núcleo protegido.

Introducción a FASR

En el caso de los equipos de núcleo protegido que carecen de funcionalidades D-RTM basadas en hardware, debemos definir un pequeño conjunto de componentes de firmware que presentan una superficie expuesta a ataques reducida y que se pueden atestiguar en el sistema operativo. Este enfoque se denomina Reducción de superficie expuesta a ataques de firmware (FASR). Para que el firmware basado en FASR se escale a través de equipos de distintos proveedores, es necesario definir un nuevo enfoque para el proceso de arranque del firmware.

FASR admite dos rutas de acceso de arranque:

1. Ruta de acceso de arranque certificada:

   • Solo se permite ejecutar código de confianza, firmado e integrado por Microsoft.

   • El sistema operativo detecta la manipulación de la ruta de acceso de arranque.

   En la ilustración siguiente se muestra el flujo de arranque de FASR S-RTM en la ruta de acceso de arranque certificada. Esta ruta de acceso de arranque ayuda a evitar que se ejecute código de firmware de plataforma inesperado. Sin embargo, hace uso de algunos datos específicos de la plataforma proporcionados por la ruta de acceso de arranque personalizada. En el diagrama siguiente se muestra el flujo de arranque de FASR en la ruta de acceso de arranque certificada.

   

2. Ruta de acceso de arranque personalizada: Todo el código de firmware de la plataforma se puede ejecutar. La información crítica para el arranque específica de un OEM o plataforma determinado se convierte en datos en la ruta de acceso de arranque personalizada y la usa la ruta de acceso de arranque certificada para configurar el sistema correctamente en esa ruta de acceso de arranque. En el diagrama siguiente se muestra el flujo de arranque de FASR en la ruta de acceso de arranque personalizada.

   

   Un dispositivo FASR habilitado para el cumplimiento de PC de núcleo seguro, tiene como valor predeterminado la ruta de acceso de arranque certificada, a menos que se haya producido un evento que haga que el arranque cambie a la ruta de acceso de arranque personalizada al principio del proceso de arranque del firmware. Algunos ejemplos de estos eventos incluyen una actualización de firmware, el usuario solicitó una interfaz de usuario de firmware o el usuario ha elegido deshabilitar el equipo básico protegido, lo que significa que siempre arrancará en la ruta de acceso de arranque personalizada hasta que se vuelva a habilitar.

   Tenga en cuenta que el arranque personalizado se puede usar para arrancar cualquier sistema operativo o software de terceros como compatible con el firmware de la plataforma en un dispositivo compatible con FASR, pero Windows no reconocerá el arranque en la ruta de acceso de arranque personalizada como compatible con el equipo con núcleo seguro.

Para comprender mejor las tecnologías de seguridad detrás de FASR, nos gustaría compartir una visión general rápida del proceso de arranque de Windows.

Proceso de arranque de Windows

Raíz de confianza

La ejecución inicial del firmware en un equipo moderno sigue un proceso de arranque donde un conjunto inicial de código carga otro código y el nivel de funcionalidad se expande a medida que avanza el arranque. Cada conjunto de código comprueba el siguiente conjunto de código que forma una cadena de confianza. Cuando el firmware UEFI obtiene el control, sigue el estándar de arranque seguro de comprobar las firmas de software para continuar la cadena de confianza hasta el sistema operativo. A continuación, el cargador de arranque de Windows continúa la cadena de confianza con arranque seguro, que comprueba todos los demás componentes del sistema operativo en el proceso de inicio antes de cargarlo.

En general, los atacantes buscan obtener el control lo antes posible en el proceso de arranque antes de habilitar las características y bloqueos de seguridad que ayudan a proteger el sistema. Cuando el sistema se saca del restablecimiento, el conjunto inicial de código ejecutado debe estar anclado en confianza. La tecnología de verificación de hardware que cumple el rol para realizar esta comprobación temprana del código se denomina raíz de confianza. Aunque los detalles exactos varían según el proveedor de hardware, todas las raíces de confianza normalmente se basan en hardware inmutable o ROM en el SOC.

Arranque medido

El arranque seguro anclado en una raíz de confianza ayuda a garantizar que se compruebe la firma digital de todo el firmware; sin embargo, también es conveniente tener un registro de exactamente qué firmware se ejecutó. El Programa de compatibilidad de hardware de Windows requiere que todos los equipos Windows 10 y Windows 11 incluyan un chip denominado Módulo de plataforma segura (TPM). El TPM contiene ubicaciones de memoria denominadas Registros de configuración de plataforma (PCR). Cada PCR contiene el hash de un tipo de código o datos cargados durante el arranque, como el código de firmware en el dispositivo de almacenamiento no volátil (por ejemplo, el flash SPI), las ROM de opción de los dispositivos PCI o el cargador de arranque del sistema operativo. El tamaño de un valor que se puede almacenar en un PCR viene determinado por el tamaño de resumen del algoritmo hash admitido. Por ejemplo, un PCR SHA-1 puede almacenar 20 bytes mientras que un PCR SHA-2 puede almacenar 32 bytes. Varios PCR asociados con el mismo algoritmo hash se denominan banco. La especificación de perfil TPM del cliente TPM de TCG define la inclusión de al menos un banco PCR con 24 registros.

Con un TPM presente, cada componente de firmware también puede actualizar o ampliar el PCR adecuado a medida que el código y los datos nuevos se cargan en el proceso de arranque. El proceso de extensión actualiza el valor de PCR para que sea la salida del algoritmo hash mediante el valor de PCR actual concatenado con el nuevo código o argumento de datos como entrada. El resultado es que las PCR se pueden inspeccionar después del proceso de arranque para determinar qué se ejecutó. Esto permite que el software del sistema operativo comprenda si el proceso de arranque era diferente al de los arranques anteriores. En un entorno sensible a la seguridad, el sistema operativo se puede informar del conjunto exacto de medidas de código esperadas en determinados PCR para detectar la ejecución de código inesperado. Puesto que los primeros 16 PCR de un banco solo se pueden restablecer restableciendo todo el TPM, son de confianza y la ubicación preferida para almacenar medidas importantes en el TPM.

Raíz de confianza para la medición

Ahora que hemos examinado el rol de una raíz de confianza y cómo se usa el arranque medido, veremos dos enfoques comunes para establecer una raíz de confianza para notificar una cadena de medida al TPM: estático y dinámico.

Una raíz estática de confianza para medición (S-RTM) establece la confianza en el restablecimiento del sistema y requiere que la confianza se mantenga durante todo el proceso de arranque. Si la confianza está en peligro en cualquier momento del proceso de arranque, es irrecuperable hasta el restablecimiento del sistema. En el diagrama siguiente se muestra cómo se usa S-RTM en la ruta de acceso de arranque certificada.

En cambio, la raíz dinámica de confianza para la medición (D-RTM) solo confía en una pequeña parte del código de firmware de inicialización del chipset temprano, así como un agente de hardware que se usa para volver a establecer la confianza dinámicamente durante el arranque. El sistema puede arrancar inicialmente en código de firmware que no es de confianza, pero poco después del inicio vuelve a un estado de confianza tomando el control de todas las CPU y forzandolas a una ruta de acceso conocida y medida. En el diagrama siguiente se proporciona información general sobre un flujo D-RTM tradicional.

Existe un equilibrio entre S-RTM y D-RTM. S-RTM no requiere funcionalidades de hardware especiales, pero requiere software para tener en cuenta mejor el código que se ejecutó durante todo el arranque. D-RTM requiere funcionalidades de hardware especiales, pero permite que el software se inicie en un estado de confianza dinámicamente durante la vigencia del sistema.

Los equipos con núcleo protegido de Windows han usado un D-RTM en el inicio seguro para permitir la flexibilidad para que el amplio conjunto de fabricantes del sistema implemente características y experiencias únicas en el firmware, a la vez que ayuda a garantizar que el sistema pueda alcanzar un estado de confianza y medido que sea aceptable hospedar un entorno de sistema operativo seguro. Un evento de inicio D-RTM se usa para restablecer la confianza desde un entorno desconocido antes de cargar un kernel seguro. En el diagrama siguiente se muestra el evento de inicio D-RTM para volver a establecer un entorno de sistema conocido.

En el pasado, S-RTM podría implementarse en más dispositivos debido a su falta de dependencia en funcionalidades de hardware especiales para comprobar el estado de seguridad del sistema, pero el sistema operativo no tenía un método confiable para confirmar que podía confiar en las medidas notificadas en cualquier dispositivo Windows determinado mediante S-RTM.

Mejoras de seguridad de firmware

Minimizar los componentes de firmware en la ruta de acceso de arranque del sistema operativo

Una manera de confiar en las medidas de S-RTM es reducir los componentes de firmware que se pueden ejecutar en un conjunto mínimo. Si todos los dispositivos que usan S-RTM usan el mismo conjunto de componentes de firmware, el sistema operativo solo tendría que confiar en un único conjunto de valores de PCR esperados para esos componentes conocidos y de confianza. Con este enfoque basado en SRTM, se puede considerar que un dispositivo ha cumplido el requisito de protección de firmware de los equipos de núcleo seguro cuando el conjunto de firmware de arranque se comprueba para que solo contenga software firmado por Microsoft que Windows pueda atestiguar. Para comprender mejor cómo estos componentes de firmware difieren de los de un arranque de PC normal, vamos a examinar el proceso de arranque antes y después.

Debido a la flexibilidad y al amplio conjunto de características que ofrece el firmware de PC moderno, el código que se ejecuta antes del sistema operativo da como resultado una mayor superficie expuesta a ataques. En el diagrama siguiente se muestra un ejemplo de un flujo de arranque S-RTM tradicional.

Las principales responsabilidades del firmware durante el arranque se pueden simplificar considerablemente para:

• Específico de la plataforma: funcionalidad que solo se aplica al diseño de hardware de plataforma específico.

• No específico de la plataforma: funcionalidad que es estándar del sector y común a otro hardware.

Un subconjunto relativamente pequeño del firmware moderno suele ser específico de la plataforma. Gran parte del código de infraestructura de firmware que realiza tareas comunes, como asignar memoria, enviar controladores de firmware, controlar eventos, etc. es lo mismo entre todos los sistemas basados en UEFI (o la mayoría). Los controladores binarios de firmware para estas tareas se pueden reutilizar en equipos. Además, las especificaciones e interfaces de hardware estándar del sector permiten a los controladores de firmware comunes inicializar discos duros, controladores USB y otros periféricos. Los controladores binarios de firmware para este hardware también se pueden reutilizar en equipos. En resumen, los equipos se pueden arrancar con un conjunto muy mínimo de controladores de firmware comunes.

Reducir el conjunto total de controladores de firmware cargados durante el arranque puede dar lugar a otras ventajas:

• Tiempo de arranque mejorado

• Reducción de la coordinación del proveedor para las actualizaciones

• Reducción de la exposición a errores

• Superficie expuesta a ataques reducida

Comprobación de la ruta de arranque de FASR y cumplimiento de núcleos protegidos

Para que un sistema FASR cumpla los requisitos de protección de firmware de los equipos de núcleo protegido, debe haber arrancado en la ruta de acceso de arranque certificada. El firmware FASR facilita esto proporcionando al sistema operativo un manifiesto firmado por Microsoft denominado manifiesto FASR (medido en el TPM) que contiene los valores de PCR esperados para la secuencia de arranque del módulo en la ruta de acceso certificada. Esto se puede comparar con la secuencia de arranque real que se produjo en la ruta de acceso certificada. Si estas medidas coinciden, se considera que el sistema ha cumplido el requisito de protección de firmware del programa Secured-core PC. Cualquier desviación de la secuencia de ruta de acceso de arranque certificada esperada producirá medidas inesperadas que se realicen en los registros de configuración de plataforma (PCR) del TPM que detectará el sistema operativo.

Además, Windows solo liberará secretos protegidos por hipervisor tras la validación correcta del manifiesto FASR firmado con las medidas registradas durante el arranque actual. Si en una ruta de arranque certificada o una actualización de cápsula, el manifiesto faSR no está presente, se produce un error en la comprobación de la firma o se produce un error de coincidencia de PCR y los secretos de VSM no se eliminarán ni migrarán.

Cómo el firmware de FASR aborda las protecciones de memoria y SMM

Ahora que se ha definido un único binario firmado por Microsoft con un conjunto mínimo de funcionalidades, puede incluir las protecciones de seguridad de firmware fundamentales, pero que faltan, Microsoft está trabajando con asociados para comercializar. La ruta de acceso de arranque certificada debe cumplir como mínimo los siguientes requisitos:

1. El código no lee/escribe en NULL/Página 0

2. El código de imagen y las secciones de datos están separados

3. Las secciones de imagen se alinean en un límite de página (4 KB)

4. Los datos solo se asignan a tipos de memoria de datos y código en tipos de memoria de código

5. Las imágenes de código no se cargan desde el código distribuido como archivos binarios ueFI (solo los distribuidores designados)

6. El código permanece dentro de los límites de los búferes de memoria asignados con páginas de protección alrededor de las asignaciones de páginas

7. Se puede detectar un desbordamiento de pila

8. El código no se ejecuta desde la pila

9. La característica dll /NXCOMPAT se establece para habilitar protecciones NX.

Las ROM de opciones de terceros, las aplicaciones UEFI y los controladores UEFI a menudo no se han compilado ni validado con este conjunto de requisitos. Por lo tanto, no se ejecutarían en la ruta de acceso de arranque certificada. Opcionalmente, la ruta de acceso de arranque personalizada puede optar por reducir el nivel de protecciones necesarias, pero esa ruta de acceso de arranque no se considera compatible con el equipo principal protegido por el sistema operativo.

Modo de administración del sistema (SMM)

SMM es un modo de funcionamiento de procesador especial en la arquitectura x86. Presenta un desafío único para la seguridad del sistema, ya que el código ejecutado en el entorno SMM es opaco para el sistema operativo y normalmente se ejecuta en el nivel de privilegios más alto (a veces denominado "Anillo -2") de cualquier software en el procesador host. Tras la entrada, SMM configura su propio entorno mediante la configuración de la tabla de páginas, la tabla de distribución de interrupciones (IDT) y otras estructuras del sistema. Por lo tanto, SMM representa una superficie de ataque significativa que podría aprovechar el código malintencionado para poner en peligro o eludir las protecciones del sistema operativo habilitadas a través de la seguridad basada en virtualización (VBS). Para ayudar a mitigar el peligro que supone SMM, la funcionalidad de SMM se puede dividir conceptualmente en la infraestructura principal de SMM y los controladores SMM de la siguiente manera:

• Núcleo de SMM: código común a todas las implementaciones de SMM que realizan responsabilidades de arquitectura e infraestructura

• Controladores SMM: código que se escribe para realizar una tarea específica de la plataforma en SMM

Algunos momentos clave del ciclo de vida de SMM son los siguientes:

1. Cuando se establece la base SMM (o núcleo): la carga del programa inicial (IPL) de SMM

2. Cuando se cargan los controladores SMM, denominado envío de controladores SMM

3. Cuando se produce la entrada a SMM: a través de una interrupción de administración del sistema (SMI)

Carga del programa inicial (IPL) de SMM

La CPU tiene características especiales que conceden a SMM su alto privilegio y ayudan a protegerla. Por ejemplo, se define un mecanismo para escribir SMM a través de eventos de software o hardware, se usa una instrucción de CPU para devolver de SMM y se definen varios registros para controlar el acceso y la configuración de bloqueo de SMM. Muchos de estos registros de control están configurados por el código IPL de SMM para restringir el acceso al área de memoria donde se almacenan el código y los datos de SMM (denominados RAM de administración del sistema o SMRAM).

Dado que el área SMRAM está en memoria principal (DRAM), no se puede establecer hasta que DRAM esté habilitado durante el arranque. Los procedimientos de habilitación de DRAM varían según el proveedor de silicio, pero bastantes megabytes de código se pueden ejecutar directamente desde la memoria caché de CPU LLC (incluido el código que inicializa DRAM) antes de que la memoria principal esté disponible.

El firmware FASR trae el punto IPL de SMM antes en el arranque que la mayoría de los demás sistemas. Esto reduce la oportunidad de que un atacante tenga que dañar este proceso y tomar el control del sistema antes de configurar SMM. Para comprender mejor esto y otras mejoras realizadas en SMM en el firmware FASR, es necesario obtener más información sobre el proceso de arranque del firmware.

Arranque de inicialización de plataforma (PI) en firmware UEFI

El firmware de PC moderno se basa en muchas especificaciones. La especificación UEFI define la interfaz entre un sistema operativo compatible con UEFI como Windows y el firmware en el dispositivo. Otra especificación denominada Especificación de inicialización de plataforma (PI) define la forma en que se compilan los controladores de firmware y detallan el propio proceso de arranque. En un nivel alto, la especificación UEFI se puede considerar como una de las normalizaciones que permite que una sola imagen de Windows funcione con tantos dispositivos diferentes, y la especificación de PI se puede considerar como una de las normalizaciones que permite que tantas imágenes de firmware de diferentes proveedores de hardware funcionen conjuntamente. El foro uefi mantiene ambas especificaciones.

La especificación pi define las fases de arranque y los controladores que se escriben en las fases de arranque. Durante el arranque del firmware, cada fase pasa a la siguiente y, en la mayoría de los casos, los controladores de la entrega de fase ya no se usan y solo se pasan datos importantes a la siguiente fase para que pueda continuar con el proceso de arranque. Las fases de arranque se pueden resumir de la siguiente manera:

1. SEC: obtener el control en el vector de restablecimiento de CPU y pasar del ensamblado al código C para cargar PEI

2. PEI: inicialización del estado del sistema para cargar DXE e inicializar DRAM

3. DXE: realice la inicialización del sistema restante, que incluye proporcionar la compatibilidad con BDS necesita cargar un sistema operativo.

4. BDS: descubra la opción de arranque para el arranque actual (por ejemplo, cargador de arranque del sistema operativo) e intente arrancar esa opción.

5. SO: kernel del sistema operativo

Protección de la carga del programa inicial (IPL) de SMM

El firmware compatible con la especificación PI de UEFI tradicional carga la IPL SMM en la fase de arranque DXE. El firmware FASR carga la IPL SMM en la fase de arranque de PEI. La base informática de confianza (TCB) de un sistema es el conjunto total de mecanismos de protección que lo protegen, incluido el hardware, el firmware y el software. Al mover el IPL SMM de DXE a PEI, toda la fase DXE (que es un entorno mucho mayor y más rico que PEI) se quita del TCB. En el diagrama siguiente se muestra la IPL de SMM que se movió anteriormente en el proceso de arranque de UEFI.

El código PEI y DXE se ejecutan en el anillo 0 y no persisten (con pocas excepciones) en el sistema operativo. El código SMM se ejecuta con un privilegio mucho mayor que el anillo 0 (y el hipervisor) y se conserva en el sistema operativo, por lo que no permite que una vulnerabilidad DXE afecte al establecimiento de SMM reduce la superficie de ataque general del sistema. Además, dado que SMM se inicia anteriormente en el proceso de arranque, los bits de bloqueo establecidos para ayudar a proteger SMM se pueden habilitar anteriormente en el arranque, lo que minimiza aún más la ventana de un atacante para poner en peligro SMM.

Protección del proceso de distribución del controlador SMM

Dentro de la especificación PI, se definen dos modos SMM: MM tradicional y MM independiente. MM tradicional es equivalente al modelo de software SMM que históricamente se usa en el firmware compatible con PI, que constituye la mayoría del firmware UEFI del sector. MM independiente es un modo relativamente nuevo que revisa el modelo histórico para mejorar la seguridad del entorno SMM y evitar errores comunes cometidos en implementaciones tradicionales de MM que llevaron a numerosos desafíos de portabilidad y seguridad a lo largo de los años.

El firmware FASR funciona exclusivamente en modo MM independiente. Esto permite que el firmware faSR siga un enfoque disciplinado para la ejecución de software en SMM. Muchas vulnerabilidades basadas en SMM en la actualidad se deben a prácticas incorrectas permitidas en el código SMM en MM tradicional que simplemente se pueden quitar en MM independiente. En un nivel alto, esto sucede porque, en el modelo MM tradicional, un controlador SMM se envía dos veces, una vez por el distribuidor DXE en el anillo 0, y de nuevo por el distribuidor SMM en SMM. Esto ofrece una amplia oportunidad para que el código del controlador ejecutado en el entorno DXE almacene en caché punteros a los recursos fuera de SMRAM a los que no deben tener acceso después de que el punto de entrada vuelva. Los ataques que dependen del código SMM para llamar al código fuera de SMM a menudo se conocen como "ataques de llamada de SMM".

Protección de la entrada a SMM

Los datos se pasan a un controlador de SMI a través de una estructura denominada "búfer de comunicación". El controlador SMI es responsable de validar si los datos cumplen ciertos requisitos en su punto de entrada. La tabla de mitigación de seguridad (WSMT) de Windows SMM es un mecanismo que se usa para ayudar a mitigar los controladores de SMI sin comprobar que representan la seguridad basada en virtualización en el sistema operativo. Microsoft ha contribuido al código al proyecto TianoCore para mejorar la validación del búfer de comunicación. Además de aprovechar estas dos técnicas, el código FASR también implementa protecciones estrictas de acceso a memoria, lo que permite que el código SMM solo acceda explícitamente a intervalos de memoria permitidos explícitamente.

Supervisor del modo de administración (Supervisor mm)

El código principal de SMM es común y se comparte con un mínimo o ningún cambio entre sistemas. La superficie expuesta a ataques impuesta por SMM se puede reducir considerablemente mediante la introducción de la separación de privilegios en el entorno de SMM. Por ese motivo, el firmware de FASR incluye un supervisor de SMM que se ejecuta en MM independiente. Esto da como resultado un entorno SMM bien definido con un TCB mínimo que tiene niveles de privilegios aplicados desde la creación. El Supervisor de MM establece restricciones en los accesos de puerto de E/S, el registro específico del modelo (MSR), el acceso MMIO, el acceso a la CPU y las instrucciones permitidas en el entorno de SMM. Se usa una directiva de supervisor de SMM para configurar los detalles exactos de los recursos de hardware que se van a restringir y esos detalles exactos están sujetos a cambios por generación de silicio.

La directiva ha pasado recientemente a un enfoque de denegación por defecto que reduce significativamente los recursos de hardware disponibles para el código fuera del supervisor de SMM. Este supervisor funciona sin una dependencia de hardware en las funcionalidades de hardware que no se encuentran normalmente en equipos modernos.

MM Supervisor se usa en FASR es de código abierto y está disponible en el repositorio supervisor de Mm de Project Mu.

Cumplimiento del sistema FASR con los requisitos de PC de núcleo protegido

En la tabla siguiente se indican los amplios pilares de seguridad o los objetivos de los equipos de núcleo protegido y cómo los sistemas FASR arrancan en la ruta de acceso certificada pueden lograr los requisitos de los equipos de núcleo protegido:

Ventajas de seguridad	Características de seguridad en equipos de núcleo protegido
Creación de una raíz de confianza respaldada por hardware	Arranque seguro
	Módulo de plataforma segura 2.0
	Protección de acceso directo a memoria (DMA)
Defensa contra ataques de nivel de firmware (consulte la nota siguiente)	Protección del sistema inicio seguro (D-RTM) o S-RTM (FASR FW)
	Aislamiento del modo de administración del sistema (SMM) o MM independiente con MM Supervisor (FASR FW)
Protección del sistema operativo frente a la ejecución de código no comprobado	Integridad de memoria (también conocida como HVCI)
Proporcionar protección y comprobación de identidades avanzadas	Windows Hello
Protección de datos críticos en caso de dispositivos perdidos o robados	Cifrado de BitLocker

Si el sistema no tiene funcionalidades de seguridad avanzadas para admitir D-RTM, se pueden cumplir los requisitos de protección de firmware mediante una combinación de S-RTM y MM independiente con MM Supervisor, ambos ofrecidos por el firmware FASR.

Resumen

Estas son algunas de las inversiones que Microsoft ha realizado para abordar el creciente número de ataques de firmware que son frecuentes en todo el sector hoy en día. Mediante el uso de código abierto para estos cambios, estamos capacitando a nuestros asociados para aprovechar algunas de estas ventajas de seguridad que, a su vez, beneficiarán al ecosistema más amplio y al sector en general.

El objetivo principal de la iniciativa secured-core PC es ayudar a garantizar que los clientes tengan acceso a algunas de las funcionalidades de seguridad más avanzadas disponibles para equipos Windows. Con algunos de estos cambios de firmware, estamos un paso más cerca de lograr ese objetivo y hemos actualizado los requisitos de protección de firmware de los equipos de núcleo protegido para reflejar esta inclusión. Obtenga más información sobre los equipos de núcleo protegido aquí.