Protección del sistema: cómo una raíz de confianza basada en hardware ayuda a proteger Windows
Para proteger los recursos críticos, como la pila de autenticación de Windows, los tokens de inicio de sesión único, la pila biométrica de Windows Hello y el módulo de plataforma de confianza virtual, el firmware y el hardware de un sistema deben ser de confianza.
System Guard reorganiza las características de integridad del sistema de Windows existentes bajo un mismo techo y configura el siguiente conjunto de inversiones en seguridad de Windows. Está diseñado para garantizar estas garantías de seguridad:
- Proteger y mantener la integridad del sistema a medida que se inicia
- Validar que la integridad del sistema se ha mantenido realmente a través de la atestación local y remota
Mantener la integridad del sistema a medida que se inicia
Raíz estática de confianza para la medición (SRTM)
Con Windows 7, uno de los medios que usarían los atacantes para conservar y evitar la detección era instalar lo que a menudo se conoce como bootkit o rootkit en el sistema. Este software malintencionado se iniciaría antes de que Windows se iniciara o durante el propio proceso de arranque, lo que le permitiría empezar con el mayor nivel de privilegios.
Con Windows 10 en ejecución en hardware moderno, una raíz de confianza basada en hardware ayuda a garantizar que no se pueda iniciar ningún firmware o software no autorizado (como un bootkit) antes del cargador de arranque de Windows. Esta raíz de confianza basada en hardware procede de la característica de arranque seguro del dispositivo, que forma parte de la interfaz de firmware extensible unificada (UEFI). Esta técnica de medición de los componentes de UEFI de arranque temprano estáticos se denomina raíz estática de confianza para la medición (SRTM).
Como hay miles de proveedores de PC que producen muchos modelos con diferentes versiones de BIOS UEFI, se convierte en un número increíblemente grande de medidas SRTM al arrancar. Existen dos técnicas para establecer la confianza aquí: mantener una lista de medidas SRTM "malas" conocidas (también conocidas como lista de bloqueos) o una lista de medidas SRTM "buenas" conocidas (también conocidas como listas de permitidos).
Cada opción tiene un inconveniente:
- Una lista de medidas SRTM "incorrectas" conocidas permite a un hacker cambiar solo 1 bit en un componente para crear un hash SRTM totalmente nuevo que se debe enumerar. Esto significa que el flujo SRTM es inherentemente quebradizo: un cambio menor puede invalidar toda la cadena de confianza.
- Una lista de medidas SRTM "buenas" conocidas requiere que cada nueva medición de combinación de BIOS/PC se agregue cuidadosamente, lo que es lento. Además, una corrección de errores para el código UEFI puede tardar mucho tiempo en diseñar, compilar, volver a probar, validar y volver a implementar.
Inicio seguro: raíz dinámica de confianza para la medición (DRTM)
System Guard Secure Launch, introducido por primera vez en windows 10 versión 1809, tiene como objetivo mitigar estos problemas mediante el uso de una tecnología conocida como raíz dinámica de confianza para la medición (DRTM). DRTM permite al sistema arrancar libremente en código que no es de confianza inicialmente, pero poco después inicia el sistema en un estado de confianza al tomar el control de todas las CPU y forzarlas a una ruta de acceso de código bien conocida y medida. Esto tiene la ventaja de permitir que el código UEFI temprano que no es de confianza arranque el sistema, pero luego ser capaz de realizar la transición de forma segura a un estado de confianza y medido.
Secure Launch simplifica la administración de las medidas de SRTM porque el código de inicio ahora no está relacionado con una configuración de hardware específica. Esto significa que el número de medidas de código válidas es pequeño y que las actualizaciones futuras se pueden implementar de forma más amplia y rápida.
Protección del modo de administración del sistema (SMM)
El modo de administración del sistema (SMM) es un modo de CPU de uso especial en microcontroladores x86 que controla la administración de energía, la configuración de hardware, la supervisión térmica y cualquier otra cosa que el fabricante considere útil. Cada vez que se solicita una de estas operaciones del sistema, se invoca una interrupción no mascarable (SMI) en tiempo de ejecución, que ejecuta el código SMM instalado por el BIOS. El código SMM se ejecuta en el nivel de privilegios más alto y es invisible para el sistema operativo, lo que lo convierte en un destino atractivo para la actividad malintencionada. Incluso si el inicio seguro de System Guard se usa para el inicio tardío, el código SMM puede acceder a la memoria del hipervisor y cambiar el hipervisor.
Para defenderse de esto, se usan dos técnicas:
- Protección de paginación para evitar el acceso inadecuado al código y a los datos
- Supervisión y atestación de hardware de SMM
La protección de paginación se puede implementar para bloquear determinadas tablas de código para que sean de solo lectura para evitar alteraciones. Esto impide el acceso a cualquier memoria que no se haya asignado.
Una característica de procesador aplicado por hardware conocida como controlador SMI de supervisor puede supervisar el SMM y asegurarse de que no tiene acceso a ninguna parte del espacio de direcciones a la que se supone que no tiene acceso.
La protección SMM se basa en la tecnología Secure Launch y requiere que funcione. En el futuro, Windows 10 también medirá el comportamiento de este controlador SMI y atestiguará que no se ha manipulado ninguna memoria propiedad del sistema operativo.
Validación de la integridad de la plataforma después de que Windows se esté ejecutando (tiempo de ejecución)
Aunque System Guard proporciona protección avanzada que ayudará a proteger y mantener la integridad de la plataforma durante el arranque y en tiempo de ejecución, la realidad es que debemos aplicar una mentalidad de "asumir vulneración" incluso a nuestras tecnologías de seguridad más sofisticadas. Podemos confiar en que las tecnologías están realizando correctamente sus trabajos, pero también necesitamos la capacidad de comprobar que han tenido éxito en el logro de sus objetivos. Para la integridad de la plataforma, no solo podemos confiar en la plataforma, que podría verse comprometida, para dar fe de su estado de seguridad. Por lo tanto, System Guard incluye una serie de tecnologías que permiten el análisis remoto de la integridad del dispositivo.
Al iniciar Windows, System Guard realiza una serie de medidas de integridad mediante el módulo de plataforma segura 2.0 (TPM 2.0) del dispositivo. System Guard Secure Launch no admite versiones anteriores de TPM, como TPM 1.2. Este proceso y los datos están aislados por hardware de Windows para ayudar a garantizar que los datos de medición no estén sujetos al tipo de manipulación que podría producirse si la plataforma estuviera en peligro. Desde aquí, las medidas se pueden usar para determinar la integridad del firmware del dispositivo, el estado de configuración de hardware y los componentes relacionados con el arranque de Windows, por nombrar algunos.
Después de iniciar el sistema, System Guard firma y sella estas medidas mediante el TPM. A petición, un sistema de administración como Intune o Microsoft Configuration Manager puede adquirirlos para el análisis remoto. Si System Guard indica que el dispositivo no tiene integridad, el sistema de administración puede realizar una serie de acciones, como denegar el acceso del dispositivo a los recursos.
Requisitos de licencia y de la edición de Windows
En la tabla siguiente se enumeran las ediciones de Windows que admiten System Guard:
| Windows Pro | Windows Enterprise | Windows Pro Education/SE | Windows Education |
|---|---|---|---|
| Sí | Sí | Sí | Sí |
Los derechos de licencia de System Guard se conceden mediante las siguientes licencias:
| Windows Pro/Pro Education/SE | Windows Enterprise E3 | Windows Enterprise E5 | Windows Education A3 | Windows Education A5 |
|---|---|---|---|---|
| Sí | Sí | Sí | Sí | Sí |
Se puede obtener más información sobre las licencias de Windows en Información general sobre las licencias de Windows.
Requisitos del sistema para System Guard
Esta característica está disponible para los procesadores siguientes:
- Procesadores Intel® vPro™ a partir de Intel® Coffeelake, Whiskylake o silicio posterior
- Procesadores AMD® a partir del silicio Zen2 o posterior
- Procesadores Qualcomm® con chipsets SD850 o posteriores
Requisitos para procesadores Intel® vPro™ a partir de Intel® Coffeelake, Whiskylake o silicio posterior
| Nombre | Descripción |
|---|---|
| CPU de 64 bits | Se requiere un equipo de 64 bits con un mínimo de cuatro núcleos (procesadores lógicos) para el hipervisor y la seguridad basada en virtualización (VBS). Para obtener más información sobre Hyper-V, consulta Hyper-V en Windows Server 2016 o Introducción a Hyper-V en Windows 10. Para obtener más información sobre el hipervisor, vea Especificaciones del hipervisor. |
| Módulo de plataforma segura (TPM) 2.0 | Las plataformas deben admitir un TPM 2.0 discreto. No se admiten los TPMs integrados o de firmware, excepto los chips intel que admiten la tecnología de confianza de plataforma (PTT), que es un tipo de TPM de hardware integrado que cumple la especificación de TPM 2.0. |
| Protección contra DMA de Windows | Las plataformas deben cumplir la especificación de protección de DMA de Windows (todos los puertos DMA externos deben estar desactivados de forma predeterminada hasta que el sistema operativo los encienda explícitamente). |
| Búferes de comunicación SMM | Todos los búferes de comunicación SMM deben implementarse en los tipos de memoria EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS o EfiReservedMemoryType. |
| Tablas de páginas SMM | NO debe contener ninguna asignación a EfiConventionalMemory (por ejemplo, ninguna memoria propiedad del sistema operativo o VMM). NO debe contener ninguna asignación a secciones de código dentro de EfiRuntimeServicesCode. NO debe tener permisos de ejecución y escritura para la misma página Solo debe permitir que las páginas TSEG se puedan marcar como ejecutables y que el mapa de memoria informe de TSEG EfiReservedMemoryType. El controlador SMI de BIOS debe implementarse de forma que las tablas de páginas SMM estén bloqueadas en cada entrada de SMM. |
| Modo de espera moderno o conectado | Las plataformas deben admitir el modo de espera moderno o conectado. |
| Índice AUXILIAR de TPM | La plataforma debe configurar un índice AUX con índices, atributos y directivas que se correspondan exactamente con el índice AUX especificado en txt dg con un tamaño de datos de exactamente 104 bytes (para datos AUX SHA256). (NameAlg = SHA256) Las plataformas deben configurar un índice de PS (proveedor de plataforma) con:
|
| Directiva AUX | La directiva AUX necesaria debe ser la siguiente:
|
| Índice de NV de TPM | El firmware de la plataforma debe configurar un índice de NV de TPM para que lo use el sistema operativo con:
|
| Firmware de la plataforma | El firmware de la plataforma debe llevar todo el código necesario para ejecutar un inicio seguro de Intel® Trusted Execution Technology:
|
| Actualización del firmware de la plataforma | Se recomienda actualizar el firmware del sistema a través de UpdateCapsule en Windows Update. |
Requisitos para procesadores AMD® a partir del silicio Zen2 o posterior
| Nombre | Descripción |
|---|---|
| CPU de 64 bits | Se requiere un equipo de 64 bits con un mínimo de cuatro núcleos (procesadores lógicos) para el hipervisor y la seguridad basada en virtualización (VBS). Para obtener más información sobre Hyper-V, consulta Hyper-V en Windows Server 2016 o Introducción a Hyper-V en Windows 10. Para obtener más información sobre el hipervisor, vea Especificaciones del hipervisor. |
| Módulo de plataforma segura (TPM) 2.0 | Las plataformas deben admitir un TPM 2.0 discreto o tpm de Microsoft Pluton. |
| Protección contra DMA de Windows | Las plataformas deben cumplir la especificación de protección de DMA de Windows (todos los puertos DMA externos deben estar desactivados de forma predeterminada hasta que el sistema operativo los encienda explícitamente). |
| Búferes de comunicación SMM | Todos los búferes de comunicación SMM deben implementarse en los tipos de memoria EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS o EfiReservedMemoryType. |
| Tablas de páginas SMM | NO debe contener ninguna asignación a EfiConventionalMemory (por ejemplo, ninguna memoria propiedad del sistema operativo o VMM). NO debe contener ninguna asignación a secciones de código dentro de EfiRuntimeServicesCode. NO debe tener permisos de ejecución y escritura para la misma página El controlador SMI de BIOS debe implementarse de forma que las tablas de páginas SMM estén bloqueadas en cada entrada de SMM. |
| Modo de espera moderno o conectado | Las plataformas deben admitir el modo de espera moderno o conectado. |
| Índice de NV de TPM | El firmware de la plataforma debe configurar un índice de NV de TPM para que lo use el sistema operativo con:
|
| Firmware de la plataforma | El firmware de la plataforma debe llevar todo el código necesario para ejecutar El inicio seguro:
La plataforma debe tener habilitada la protección contra reversión de firmware del procesador seguro AMD®. La plataforma debe tener AMD® Memory Guard habilitado. |
| Actualización del firmware de la plataforma | Se recomienda actualizar el firmware del sistema a través de UpdateCapsule en Windows Update. |
Requisitos para procesadores Qualcomm® con chipsets SD850 o posteriores
| Nombre | Descripción |
|---|---|
| Supervisión de la comunicación en modo | Todos los búferes de comunicación del modo de supervisión deben implementarse en las secciones de datos EfiRuntimeServicesData (recomendado) de EfiRuntimeServicesCode, tal como se describe en la tabla De atributos de memoria, en los tipos de memoria EfiACPIMemoryNVS o EfiReservedMemoryType. |
| Supervisión de tablas de páginas en modo | Todas las tablas de páginas Modo de supervisión deben:
|
| Modo de espera moderno o conectado | Las plataformas deben admitir el modo de espera moderno o conectado. |
| Firmware de la plataforma | El firmware de la plataforma debe llevar todo el código necesario para iniciarse. |
| Actualización del firmware de la plataforma | Se recomienda actualizar el firmware del sistema a través de UpdateCapsule en Windows Update. |