Especificación de testability de seguridad de hardware

  • Artículo

Introducción

HSTI protege contra la configuración incorrecta de las características de seguridad en dispositivos Windows. Para los clientes, HSTI proporciona una garantía de mejor esfuerzo de que la máquina que ha comprado es segura de forma predeterminada. En el caso de los IVS e IBV, HSTI se asegura de que se mantengan sus promesas de seguridad. En el caso de los OEM y los OEM con facilidad, asegúrese de que los sistemas que envía están configurados de forma segura y se mantendrán seguros, sin tener que desarrollar soluciones propietarias.

Las pruebas de compatibilidad de Windows consumirán los resultados de las pruebas de HSTI y se pueden usar para comprobar que los dispositivos se han configurado correctamente para habilitar las características de seguridad admitidas. Estas pruebas se pueden usar para identificar dispositivos de ingeniería no seguros en el campo, por ejemplo, dispositivos de ingeniería que pueden contener claves de prueba no seguras. El sistema operativo Windows puede usar los resultados de estas pruebas para mostrar una marca de agua (o un indicador similar) en dispositivos no seguros.

Nota

  La plataforma es necesaria para implementar una interfaz de hardware y compartir documentación y herramientas como se especifica en este tema.

Fondo

Se espera que el lector conozca los aspectos básicos de UEFI y comprenda las tecnologías de arranque seguro, incluida la sección 27 "Seguridad" de la especificación UEFI y NIST SP 800-147.

Este requisito tiene tres aspectos:

  • Interfaces independientes de la plataforma para consultar estados de seguridad de hardware y firmware
  • Diseño y revisión de código opcional de las implementaciones de interfaz anteriores
  • Uso compartido de documentación y herramientas

Implementación de alto nivel

Campo de bits

El IHV define un campo de bits que representa las características de seguridad que se pueden probar de la plataforma. Este campo de bits cubre completamente todos los bits definibles disponibles para los objetos HSTI devueltos por cualquier prueba de HSTI de IHV, IBV o OEM. El implementador de IHV tiene que diseñar la definición del campo de bits y proporcionar la documentación adecuada para que los IBV devuelvan correctamente los resultados de sus pruebas HSTI.

SecurityFeaturesRequired

El campo SecurityFeaturesRequired solo se usa en el procesamiento cuando un campo de un objeto HSTI de IHV y es el método por el que el IHV define el campo de bits de las características de seguridad necesarias.

SecurityFeaturesImplemented

Este es un campo de bits de las características de seguridad implementadas por las pruebas que devuelven el objeto HSTI.

SecurityFeaturesVerified

Se trata de un campo de bits de las características de seguridad que han comprobado las pruebas que devuelven el objeto HSTI.

Directrices de implementación

El IHV desarrollará diseños de seguridad de referencia para sus plataformas que cumplan los requisitos de compatibilidad de Windows. Además, los IHD e IBV también implementarán pruebas programáticas que comprueben la habilitación adecuada de las implementaciones de seguridad de referencia e informarán de los resultados a través de la interfaz de prueba de seguridad de hardware. Estas pruebas se entregan a los OEM & como módulos compilados (no origen) y deben funcionar sin modificaciones. Si un OEM/ODM se desvía de los diseños de seguridad de referencia, estos módulos de prueba pueden notificar errores y el OEM/ODM tendrá que ponerse en contacto con Microsoft para revisar las modificaciones e implementar una instancia de HSTI adicional que notifica estas excepciones. Los OEM deben poder aprovechar estos módulos de seguridad sin modificarlos siguiendo el diseño y la documentación de referencia. Los OEM que deseen agregar módulos de seguridad adicionales o modificar el comportamiento de cualquier módulo de seguridad deben someterse a una revisión de diseño con Microsoft.

Como parte de su implementación de los implementadores de módulos de pruebas, se incluirá una estructura. A continuación se incluye un prototipo de esta estructura en la sección "Prototipo". El IHV definirá el significado de cada bit en la lista de comprobación de referencia de seguridad. El IHV definirá aún más el significado de cada bit en los campos de bits. Por último, el IHV incluye un campo de bits "Obligatorio" en la estructura oem y, para todos los requisitos, pueden probar mediante programación, establecerán un bit en el campo de bits "Implementado".

Los IBV y los OEM pueden establecer bits en el campo "Implementado" si han presentado un diseño para comprobar mediante progamática la presencia de las características de seguridad representadas por esos bits en Microsoft. Si esas pruebas superan, pueden establecer el campo "Verificado" en sus respectivos structs.

Los módulos de prueba para IHV, IBV y OEM se ejecutarán si están presentes. Un valor true establecido en un bit en el campo SecurityFeaturesEnabled indica un resultado de prueba superada. Si no se ejecuta una prueba o no se supera, se establecerá un valor de 0 para el bit representativo.

Ejemplo de lógica de procesamiento de resultados

Este ejemplo es representativo de la lógica que usará el procesamiento de resultados. Los campos de bits implementados deben seguir el formato que un medio 1 significa implementado y un 0 significa no implementado. Si se implementa algo, es necesario. Los campos de bits de resultados deben seguir el formato que significa que un error o una prueba no están presentes y 1 significa que solo se ha superado afirmativamente.

Una vez calculados todos los resultados, el campo de bits Resultados de IHV será NXORd con su campo de bits Requerido. Todos los campos de bits de resultados que no son IHV se agrupan con sus respectivos campos de bits implementados. Los campos de bits resultantes son todos juntos ORd para obtener los resultados generales. Un resultado de paso de esta operación será un campo de bits que consta de completamente 1s.

Entregas y propiedad

Proveedores de hardware independientes (IHD) y proveedores de BIOS independientes (IBV)

Los proveedores de Silicon e IBV que admiten sistemas conectados en espera deben implementar las interfaces independientes de la plataforma para consultar los respectivos estados de seguridad de hardware y firmware de sus plataformas de referencia. Estas implementaciones se deben entregar como módulos compilados. Es preferible firmar estos módulos y se realiza una comprobación de firma cuando se ejecutan. El propósito es consultar los estados de los diseños & de hardware y firmware para informar sobre el aprovisionamiento de seguridad adecuado de la plataforma.

OEM y OEM

Los OEM y los OEM no deben modificar ni manipular las pruebas de HSTI que los proveedores les han proporcionado. Los OEM y los OEM son necesarios para garantizar que sus sistemas pasarán las pruebas de HSTI como componente de los requisitos de certificación de Windows:

Requisito de certificación de hardware de Windows: Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

En lugar de modificarlo, si un OEM requiere un método para proporcionar un método alternativo para proporcionar la misma o mejor seguridad, ese OEM puede proporcionar comprobaciones de seguridad adicionales. Las comprobaciones de seguridad de OEM deben cubrir al menos una prueba de seguridad de IHV o IBV. Antes de su uso, los OEM deben enviar a una revisión de diseño de Microsoft y están sujetos a los mismos requisitos de divulgación de documentación y herramientas que otros proveedores de pruebas de HSTI. Tras la aprobación de Microsoft, el OEM puede incluir pruebas de seguridad que se extienden a las pruebas de IHV e IBV.

Tenga en cuenta que la atestación de OEM no es necesaria como parte del diseño de HSTI. HSTI no es una lista de requisitos para los OEM, es una interfaz para garantizar pruebas eficaces de seguridad mediante programación de los parámetros de firmware, hardware y configuración.

Interfaces de estado de seguridad

Las interfaces se basan en el protocolo de información del adaptador EFI definido en la versión 2.4 de UEFI.

Interfaz de estado de seguridad de la plataforma

Resumen

Información de seguridad de la plataforma: devuelve información sobre la conformidad de la plataforma con el requisito de certificación de hardware de Windows System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby y System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Prototipo

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

InformationBlock correspondiente:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
Término Descripción

Version

Devolver PLATFORM_SECURITY_VERSION_VNEXTCS

Papel

Rol del publicador de esta interfaz. Se espera que los diseñadores de plataformas de referencia como IHD e IBV devuelvan PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE y PLATFORM_SECURITY_ROLE_PLATFORM_IBV respectivamente. Si los módulos de prueba de los diseñadores no pueden comprobar completamente todas las características de seguridad, los implementadores de plataforma, los OEM y los OEM, tendrán que publicar esta interfaz con un rol de Implementador.

ImplementationID

Proveedor legible, modelo y & versión de esta implementación. Por ejemplo, "SiliconVendorX Chip1234 v1" y "BIOSvendorY BIOSz v2".

SecurityFeaturesSize

Tamaño en bytes de las matrices SecurityFeaturesRequired y SecurityFeaturesEnabled. Las matrices deben tener el mismo tamaño.

SecurityFeaturesRequired

Campo de bits definido por IHV correspondiente a todas las características de seguridad que se deben implementar para cumplir los requisitos de seguridad definidos por PLATFORM_SECURITY_VERSION versión. Por ejemplo, es posible que se necesite implementar 7 características para satisfacer la versión, es posible que se notifique un valor de 0b0111111111.

SecurityFeaturesImplemented

Campo de bits definido por el publicador correspondiente a todas las características de seguridad que han implementado pruebas mediante programación en este módulo.

SecurityFeaturesVerified

Campo de bits definido por el publicador correspondiente a todas las características de seguridad que esta implementación ha comprobado.

ErrorString

Una cadena terminada en Null, un error por línea (CR/LF finalizado), con un identificador único que el OEM/ODM puede usar para buscar la documentación que describirá los pasos para corregir el error: se recomienda una dirección URL a la documentación. Por ejemplo,

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

Consideraciones sobre la administración de memoria

Con fines de compatibilidad entre módulos HSTI, los implementadores usarán AllocatePool() y no AllocatePages().

Revisión de diseño de la implementación de HSTI

Microsoft realizará revisiones preliminares de diseño de todas las implementaciones de interfaz de prueba. En la sección Consideraciones de diseño de HSTI se proporcionan ejemplos de las preguntas que se pueden formular en una revisión de diseño.

Revisiones de código opcionales

Los implementadores de HSTI pueden solicitar revisiones de código realizadas por Microsoft. Las revisiones de código se pueden proporcionar en función de la prioridad y la disponibilidad de los recursos y no están garantizadas. Las revisiones de código se llevarán a cabo con arreglo a un acuerdo de no divulgación.

Uso compartido de documentación y herramientas

Los proveedores de silicon y firmware deben poner a disposición de Microsoft toda la documentación de referencia relacionada con la seguridad necesaria y las herramientas que proporcionan a los OEM. Esta documentación y herramientas deben estar disponibles más adelante de lo que se proporcionan a los OEM de Windows. Esto debe incluir, entre otros, toda la documentación y herramientas relacionadas con la fusión, instalación y actualización de firmware, firmware y recuperación de arranque, diagnósticos de hardware, diagnósticos de firmware, & diagnósticos de arranque. Esta documentación y herramientas proporcionadas deben ser totalmente suficientes para realizar comprobaciones de HSTI en un entorno de laboratorio.

Consideraciones de diseño de HSTI

A continuación se muestra una lista ilustrativa de consideraciones de diseño que un implementador de HSTI debe tener en cuenta para su implementación de HSTI. Esta no es una lista estricta de requisitos, ni es una lista exhaustiva de consideraciones. Como implementador de HSTI, escribirá pruebas para validar las características de seguridad que tiene trabajando para lograr una cobertura lo más completa posible. Antes de que su revisión de diseño con Microsoft le recomendamos que revise esta lista para obtener inspiración y tenga en cuenta que Es probable que Microsoft desee que si implementa estas características, las pruebe lo más ampliamente posible.

Comprobaciones HSTI de proveedores o proveedores de Silicon (IHV)

  1. ¿Usa RSA 2048 y SHA256 solo (o una seguridad criptográfica similar)
  2. El código de firmware debe estar presente en el almacenamiento protegido
    1. ¿Proteges spiflash?
    2. ¿Implementa solo lectura hasta el restablecimiento de las particiones de eMMC?
    3. ¿Es compatible con la comprobación de firmware firmada: el firmware instalado por OEM es de solo lectura o está protegido por el proceso de actualización de firmware seguro.
  3. Proceso de actualización segura de firmware
    1. ¿El proceso de actualización de firmware seguro está activado de forma predeterminada con claves de prueba? (RECOMENDADO)
    2. ¿Comprueba si se usan claves de prueba en producción?
    3. ¿Permite la reversión a una versión de firmware no segura? Si es así, ¿cuál es el mecanismo de protección? ¿Borra TPM cuando se produce la reversión?
  4. ¿Tiene puertas traseras para invalidar SecureBoot?
    1. ¿El sistema admite mensajes en línea para omitir Secureboot? Si es así, ¿está deshabilitado mientras SecureBoot está habilitado?
    2. ¿Tienes puertas traseras de fabricación? ¿Comprueba que se deshabiliten mientras SecureBoot está habilitado y siempre deshabilitado en el sistema de producción?
  5. [CS] Compatibilidad con la integridad de arranque
    1. ¿Es compatible con la integridad de arranque y está habilitada de forma predeterminada?
    2. La plataforma usa rom on-die o One-Time memoria programable (OTP) para almacenar el código de arranque inicial y proporciona lógica de restablecimiento de encendido para ejecutar desde rom de diedo o SRAM seguro en die.
  6. [CS] Protección contra DMA interno y externo
    1. ¿Mantiene DMA interno en solo para los componentes necesarios durante el arranque? Y está deshabilitado para todos los demás componentes.
    2. ¿Mantiene DMA externo solo en para los componentes necesarios durante el arranque? Y está deshabilitado para todos los demás componentes.
    3. Si el firmware tiene una opción para habilitar y deshabilitar la protección DMA, la configuración de envío debe tener habilitada la protección DMA de forma predeterminada.
    4. ¿Qué buses/dispositivos (fusibles, motores de seguridad, TZ, vídeo, cachés, IMEM, memoria del kernel) son capaces de acceder a DMA a diferentes regiones de almacenamiento nv y volátiles y cómo están protegidas?
    5. ¿Admite la implementación de bits mor?
  7. Protección contra el depurador de hardware externo
    1. ¿Es compatible con JTAG? Es JTAG OFF cuando SecureBoot está activado
    2. ¿Proporciona la puerta trasera de fabricación para deshabilitar la protección de JTAG? ¿Comprueba si esta puerta trasera no está presente en los sistemas de producción?
    3. ¿Borra TPM cuando JTAG está habilitado?
    4. ¿Es compatible con cualquier otro depurador de hardware? Y haga las mismas comprobaciones.
  8. ¿Ha aprovisionado correctamente el secreto único por dispositivo?
  9. ¿Cuáles son los fusibles de seguridad que tiene (específico del proveedor)
    1. Fusible de SOC SecureBoot
    2. Secretos únicos por dispositivo, como fusibles de aprobación o cifrado
    3. Fusibles JTAG
    4. Fusible secureBoot del procesador de aplicaciones SOC
    5. Fusible secureBoot del procesador DE MBA de SOC
    6. Fusible secureBoot del procesador moderno soC
    7. Cualquier otro fusible específico de SOC para la plataforma

Comprobaciones de HSTI de IBV

  1. ¿Usa RSA 2048 y SHA256 solo (o superior, pero no inferior a este)
  2. Módulos de compatibilidad compatibles (CSM)
    1. ¿Proporciona la opción para habilitar CSM?
    2. ¿Comprueba el bloqueo de carga de CSM cuando SecureBoot está habilitado?
    3. [CS] ¿Comprueba si CSM no está presente en los sistemas CS de forma permanente?
  3. El código de firmware debe estar presente en el almacenamiento protegido
    1. ¿Proteges spiflash?
    2. ¿Implementa solo lectura hasta el restablecimiento de las particiones de eMMC?
    3. ¿Es compatible con la comprobación de firmware firmada: el firmware instalado por OEM es de solo lectura o está protegido por el proceso de actualización de firmware seguro.
  4. Proceso de actualización segura de firmware
    1. ¿El proceso de actualización de firmware seguro está activado de forma predeterminada con claves de prueba?
    2. ¿Comprueba si se usan claves de prueba en producción?
    3. ¿Permite la reversión a una versión de firmware no segura? Si es así, ¿cuál es el mecanismo de protección? ¿Borra TPM cuando se produce la reversión?
    4. ¿Se usan claves de prueba?
  5. ¿Tiene puertas traseras para invalidar SecureBoot?
    1. ¿El sistema admite mensajes en línea para omitir Secureboot? Si es así, ¿está deshabilitado mientras SecureBoot está habilitado?
    2. ¿Tienes puertas traseras de fabricación? ¿Comprueba que se deshabiliten mientras SecureBoot está habilitado y siempre deshabilitado en el sistema de producción?
  6. [CS] Protección contra DMA interno y externo
    1. ¿Mantiene DMA interno en solo para los componentes necesarios durante el arranque? Y está deshabilitado para todos los demás componentes.
    2. ¿Mantiene DMA externo solo en para los componentes necesarios durante el arranque? Y está deshabilitado para todos los demás componentes.
    3. Si el firmware tiene una opción para habilitar y deshabilitar la protección DMA, la configuración de envío debe tener habilitada la protección DMA de forma predeterminada.
    4. ¿Qué buses/dispositivos (fusibles, motores de seguridad, TZ, vídeo, cachés, IMEM, memoria del kernel) son capaces de acceder a DMA a diferentes regiones de almacenamiento nv y volátiles y cómo están protegidas?
    5. ¿Admite la implementación de bits mor?