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 Windows Hello y el módulo de plataforma de confianza virtual, el firmware y el hardware de un sistema deben ser de confianza.

Protección del sistema 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 que se ejecutan 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)

Protección del sistema Secure Launch, introducido por primera vez en Windows 10 versión 1809, tiene como objetivo mitigar estos problemas aprovechando 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.

Protección del sistema inicio seguro.

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 enmascarable (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 se usa Protección del sistema inicio seguro 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 Protección del sistema 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, Protección del sistema incluye una serie de tecnologías que permiten el análisis remoto de la integridad del dispositivo.

Al iniciar Windows, Protección del sistema toman una serie de medidas de integridad mediante el módulo de plataforma segura 2.0 (TPM 2.0) del dispositivo. Protección del sistema Inicio seguro 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.

Integridad del tiempo de arranque.

Después de iniciar el sistema, Protección del sistema 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 su análisis remoto. Si Protección del sistema indica que el dispositivo carece de 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 Protección del sistema:

Windows Pro Windows Enterprise Windows Pro Education/SE Windows Education
Sí Sí Sí Sí

Protección del sistema derechos de licencia 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 Protección del sistema

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, consulte 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:
  • Exactamente los atributos de estilo "TXT PS2" en la creación como se indica a continuación:
    • AuthWrite
    • PolicyDelete
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • Noda
    • Escrito
    • PlatformCreate
  • Una directiva exactamente PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg y Policy)
  • Tamaño de exactamente 70 bytes
  • NameAlg = SHA256
  • Además, debe haberse inicializado y bloqueado (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) en el momento del inicio del sistema operativo.
Los datos de índice de PS DataRevocationCounters, SINITMinVersion y PolicyControl deben estar 0x00
Directiva AUX La directiva AUX necesaria debe ser la siguiente:
  • A = TPM2_PolicyLocality (localidad 3 & localidad 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
Í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:
  • Identificador: 0x01C101C0
  • Atributos:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Una directiva de:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valor de resumen de 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
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:
  • Intel® SINIT ACM debe transportarse en el BIOS oem
  • Las plataformas deben enviarse con un ACM de producción firmado por el firmante de producción correcto de Intel® ACM para la plataforma.
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, consulte 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:
  • Identificador: 0x01C101C0
  • Atributos:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Una directiva de:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valor de resumen de 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Firmware de la plataforma El firmware de la plataforma debe llevar todo el código necesario para ejecutar El inicio seguro:
  • Las plataformas de inicio seguro de AMD® deben enviarse con el devnode del controlador AMD® DRTM expuesto y el controlador AMD® DRTM instalado

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:
  • NO contiene ninguna asignación a EfiConventionalMemory (por ejemplo, ninguna memoria propiedad del sistema operativo o VMM)
  • NO deben tener permisos de ejecución y escritura para la misma página
  • Las plataformas solo deben permitir páginas de modo de supervisión marcadas como ejecutables
  • La asignación de memoria debe notificar el modo de supervisión como EfiReservedMemoryType.
  • Las plataformas deben proporcionar un mecanismo para proteger las tablas de página Modo de supervisión frente a modificaciones
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.