Share via

Especificação de testabilidade de segurança de hardware

  • Artigo

Introdução

O HSTI protege contra configuração incorreta de recursos de segurança em dispositivos Windows. Para os clientes, o HSTI fornece a melhor garantia de esforço de que o computador que eles compraram é seguro por padrão. Para IHVs e IBVs, o HSTI garante que suas promessas de segurança sejam mantidas. Para OEMs e ODMs, certifique-se facilmente de que os sistemas que você envia estejam configurados com segurança e permaneçam seguros, sem precisar desenvolver soluções proprietárias.

Os resultados dos testes de HSTI serão consumidos pelos Testes de Compatibilidade do Windows e poderão ser usados para verificar se os dispositivos foram configurados corretamente para habilitar os recursos de segurança com suporte. Esses testes podem ser usados para identificar dispositivos de engenharia não seguros no campo, por exemplo, dispositivos de engenharia que podem conter chaves de teste inseguras. Os resultados desses testes podem ser usados pelo sistema operacional Windows para exibir uma marca d'água (ou indicador semelhante) em dispositivos inseguros.

Observação

  A plataforma é necessária para implementar uma interface de hardware e compartilhar documentação e ferramentas, conforme especificado neste tópico.

Fundo

Espera-se que o leitor conheça os conceitos básicos da UEFI e tenha uma compreensão das tecnologias de Inicialização Segura, incluindo a Seção 27 "Segurança" da especificação UEFI e NIST SP 800-147.

Esse requisito tem três aspectos:

  • Interfaces independentes de plataforma para consultar estados de segurança de hardware e firmware
  • Design e revisão de código opcional das implementações de interface acima
  • Compartilhamento de documentação e ferramentas

Implementação de alto nível

O campo de bits

O IHV define um campo de bits que representa os recursos de segurança testáveis da plataforma. Esse campo de bits abrange totalmente todos os bits definiveis disponíveis para os objetos HSTI retornados por qualquer teste de HSTI IHV, IBV ou OEM. O implementador IHV precisa projetar a definição do campo de bits e fornecer a documentação apropriada para que os IBVs retornem corretamente os resultados de seus testes de HSTI.

SecurityFeaturesRequired

O campo SecurityFeaturesRequired só é usado no processamento quando um campo em um objeto HSTI IHV e é o método pelo qual o IHV define o campo de bits dos recursos de segurança necessários.

SecurityFeaturesImplemented

Esse é um campo de bits dos recursos de segurança implementados pelos testes que retornam o objeto HSTI.

SecurityFeaturesVerified

Esse é um campo de bits dos recursos de segurança que foram verificados pelos testes que retornam o objeto HSTI.

Diretrizes de implementação

O IHV desenvolverá designs de segurança de referência para suas plataformas que estão em conformidade com os Requisitos de Compatibilidade do Windows. Além disso, IHVs e IBVs também implementarão testes programáticos que verificam a habilitação adequada das implementações de segurança de referência e relatam os resultados por meio da Interface de Teste de Segurança de Hardware. Esses testes são entregues aos ODMs do OEMs & como módulos compilados (não de origem) e devem funcionar sem modificação. Se um OEM/ODM se desviar de designs de segurança de referência, esses módulos de teste poderão relatar falhas e o OEM/ODM precisará entrar em contato com a Microsoft para examinar as modificações e implementar uma instância de HSTI adicional que relata essas exceções. Os OEMs devem ser capazes de aproveitar esses módulos de segurança sem nenhuma modificação exigida seguindo o design e a documentação de referência. Os OEMs que desejam adicionar módulos de segurança adicionais ou modificar o comportamento de qualquer módulo de segurança devem passar por uma revisão de design com a Microsoft.

Como parte de sua implementação de implementadores de módulo de testes, incluirá um struct. Um protótipo desse struct está incluído abaixo na "seção Protótipo". O IHV definirá o significado de cada bit na lista de verificação de referência de segurança. O IHV definirá ainda mais o significado de cada bit nos campos de bits. Por fim, o IHV inclui um campo de bits "Obrigatório" no struct OEM e, para todos os requisitos, eles podem testar programaticamente que definirão um pouco no campo de bits "Implementado".

IBVs e OEMs podem definir bits no campo "Implementado" se apresentarem um design para marcar progamaticamente para a presença dos recursos de segurança representados por esses bits para a Microsoft. Se esses testes forem aprovados, eles poderão definir o campo "Verificado" em seus respectivos structs.

Os módulos de teste para IHV, IBV e OEM serão executados se estiverem presentes. Um valor verdadeiro definido em um bit no campo SecurityFeaturesEnabled indica um resultado de teste aprovado. Se um teste não for executado ou não for aprovado, um valor de 0 será definido para o bit representativo.

Exemplo de lógica de processamento de resultados

Este exemplo representa a lógica que será usada pelo processamento de resultados. Os campos de bits implementados devem seguir o formato que um 1 significa implementado e um 0 significa não implementado. Se algo for implementado, será necessário. Os campos de bits de resultados devem seguir o formato de que um 0 significa falha ou teste não presente e um 1 significa somente aprovado afirmativamente.

Depois que todos os resultados forem calculados, o campo de bits Resultados IHV será NXORd com o campo de bits Necessário. Todos os campos de bits de resultados não IHV são ANDed com seus respectivos campos de bits implementados. Os campos de bits resultantes são todos ORd juntos para obter os resultados gerais. Um resultado aprovado dessa operação será um campo de bits que consiste em inteiramente 1s.

Entregas e Propriedade

Fornecedores independentes de hardware (IHVs) e FORNECEDORes independentes de BIOS (IBVs)

Os fornecedores de silício e os IBVs que dão suporte a sistemas de espera conectados devem implementar as interfaces independentes da plataforma para consultar os respectivos estados de segurança de hardware e firmware de suas plataformas de referência. Essas implementações devem ser entregues como módulos compilados. É preferível que esses módulos sejam assinados e uma assinatura marcar seja executada quando forem executados. A finalidade é consultar os estados de design de & hardware e firmware para relatar o provisionamento de segurança adequado da plataforma.

OEMs e ODMs

Os OEMs e os ODMs não devem modificar ou adulterar os testes de HSTI que foram fornecidos a eles por fornecedores. Os OEMs e os ODMs são necessários para garantir que seus sistemas passem nos testes de HSTI como um componente dos requisitos de Certificação do Windows:

Requisito de certificação de hardware do Windows – Windows 8.1 WHCR

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

Em vez de modificação, se um OEM exigir um método para fornecer um método alternativo para fornecer a mesma segurança ou melhor, esse OEM poderá fornecer verificações de segurança adicionais. As verificações de segurança do OEM devem, pelo menos, cobrir totalmente um teste de segurança IHV ou IBV. Antes do uso, os OEMs devem enviar para uma revisão de design pela Microsoft e estão sujeitos aos mesmos requisitos de documentação e divulgação de ferramentas que outros provedores de teste de HSTI. Após a aprovação da Microsoft, o OEM pode incluir testes de segurança que se estendem nos testes IHV e IBV.

Observe que o atestado OEM não é necessário como parte do design do HSTI. O HSTI não é uma lista de requisitos para OEMs, é uma interface para garantir testes de segurança programáticos eficazes de parâmetros de firmware, hardware e configuração.

Interfaces de estado de segurança

As interfaces são criadas no Protocolo de Informações do Adaptador EFI definido na UEFI versão 2.4.

Interface de estado de segurança da plataforma

Resumo

Informações de segurança da plataforma – retorna informações sobre a conformidade da plataforma com o Sistema de Requisitos de Certificação de Hardware do Windows.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby e System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Protótipo

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 correspondente:

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;
Termo Descrição

Version

Retornar PLATFORM_SECURITY_VERSION_VNEXTCS

Papel

A função do editor dessa interface. Designers de plataforma de referência, como IHVs e IBVs, devem retornar PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE e PLATFORM_SECURITY_ROLE_PLATFORM_IBV, respectivamente. Se os módulos de teste dos designers não puderem verificar totalmente todos os recursos de segurança, os implementadores de plataforma, OEMs e ODMs precisarão publicar essa interface com uma função de Implementador.

ImplementationID

Fornecedor legível humano, modelo, & versão dessa implementação. Por exemplo, "SiliconVendorX Chip1234 v1" e "BIOSz biosvendory v2".

SecurityFeaturesSize

O tamanho em bytes das matrizes SecurityFeaturesRequired e SecurityFeaturesEnabled. As matrizes devem ter o mesmo tamanho.

SecurityFeaturesRequired

Campo de bits definido por IHV correspondente a todos os recursos de segurança que devem ser implementados para atender aos requisitos de segurança definidos pelo PLATFORM_SECURITY_VERSION Versão. Por exemplo, 7 recursos podem ser necessários para serem implementados para atender à Versão, um valor de 0b011111111 pode ser relatado.

SecurityFeaturesImplemented

Campo de bits definido pelo publicador correspondente a todos os recursos de segurança que implementaram testes programáticos neste módulo.

SecurityFeaturesVerified

Campo de bits definido pelo publicador correspondente a todos os recursos de segurança que foram verificados implementados por essa implementação.

ErrorString

Uma cadeia de caracteres terminada em nulo, uma falha por linha (CR/LF encerrado), com um identificador exclusivo que o OEM/ODM pode usar para localizar a documentação que descreverá as etapas para corrigir a falha – uma URL para a documentação é recomendada. Por exemplo,

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

Considerações sobre gerenciamento de memória

Para fins de compatibilidade entre módulos HSTI, os implementadores devem usar AllocatePool() e não AllocatePages().

Revisão de design da implementação do HSTI

A Microsoft realizará revisões preliminares de design de todas as implementações de interface de teste. Exemplos das perguntas que podem ser feitas em uma revisão de design são fornecidos na seção Considerações de design do HSTI.

Revisões de código opcionais

Os implementadores de HSTI podem solicitar revisões de código executadas pela Microsoft. As revisões de código podem ser fornecidas com base na prioridade e disponibilidade dos recursos e não são garantidas. As revisões de código ocorrerão sujeitas a um Contrato de Não Divulgação.

Documentação e compartilhamento de ferramentas

Os fornecedores de silício e firmware devem disponibilizar à Microsoft todas as documentações e ferramentas de referência relacionadas à segurança necessárias que eles fornecem aos OEMs. Essa documentação e as ferramentas não devem ser disponibilizadas mais tarde do que são fornecidas aos OEMs do Windows. Isso deve incluir, mas não se limita a, todas as documentações e ferramentas relacionadas à fusão, instalação e atualização de firmware, firmware e recuperação de inicialização, diagnóstico de hardware, diagnóstico de firmware, & diagnóstico de inicialização. Essa documentação e as ferramentas fornecidas devem ser totalmente suficientes para executar verificações de HSTI em um ambiente de laboratório.

Considerações sobre o design do HSTI

Veja a seguir uma lista ilustrativa de considerações de design que um implementador HSTI deve considerar para sua implementação de HSTI. Esta não é uma lista estrita de requisitos, nem é uma lista exaustiva de considerações. Como um implementador HSTI, você escreverá testes para validar os recursos de segurança que você tem trabalhando para a cobertura mais abrangente possível. Antes da revisão de design com a Microsoft, recomendamos que você examine esta lista para se inspirar e considere que a Microsoft provavelmente desejará que, se você implementar esses recursos, os teste da forma mais ampla possível.

Verificações de HSTI de Fornecedores/Fornecedores de Silício (IHV)

  1. Você usa somente rsa 2048 e SHA256 (ou força de criptografia semelhante)
  2. O Código do Firmware deve estar presente no armazenamento protegido
    1. Você protege o spiflash?
    2. Você implementa somente leitura até a redefinição para partições eMMC
    3. Você dá suporte à Verificação de Firmware Assinado – o firmware instalado pelo OEM é somente leitura ou protegido pelo processo de atualização de firmware seguro.
  3. Processo de atualização de firmware seguro
    1. O processo de atualização de firmware seguro está ativado por padrão com chaves de teste? (RECOMENDADO)
    2. Você marcar se as chaves de teste forem usadas na produção?
    3. Você permite a reversão para a versão de firmware insegura? Se sim, então qual é o mecanismo de proteção? Você limpa o TPM quando a reversão acontece?
  4. Você tem backdoors para substituir SecureBoot
    1. O sistema dá suporte à solicitação embutida para ignorar o Secureboot? Se sim, ele será desabilitado enquanto SecureBoot estiver habilitado?
    2. Você tem backdoors de fabricação? Você marcar para que eles sejam desabilitados enquanto SecureBoot estiver habilitado e sempre desabilitado no sistema de produção?
  5. [CS] Suporte à integridade de inicialização
    1. Você dá suporte à Integridade de Inicialização e ela está habilitada por padrão?
    2. A plataforma usa memória OTP (ROM on-die ou One-Time Programmable) para armazenar o código de inicialização inicial e fornece lógica de redefinição de ativação para executar de ROM on-die ou SRAM on-die seguro.
  6. [CS] Proteção contra DMA interno e externo
    1. Você mantém o DMA interno ativado apenas para componentes necessários durante a inicialização? E está desabilitado para todos os outros componentes.
    2. Você mantém o DMA externo ativado apenas para componentes necessários durante a inicialização? E está desabilitado para todos os outros componentes.
    3. Se o firmware tiver uma opção para habilitar e desabilitar a proteção contra DMA, a configuração de envio deverá ter a proteção de DMA habilitada por padrão
    4. Quais barramentos/dispositivos (fusíveis, mecanismos de segurança, TZ, vídeo, caches, IMEM, memória de kernel) são capazes de acessar o DMA a diferentes regiões de armazenamento NV e voláteis e como eles são protegidos?
    5. Você dá suporte à implementação de bits MOR
  7. Proteção contra depurador de hardware externo
    1. Você dá suporte à JTAG? É JTAG OFF quando SecureBoot está ATIVADO
    2. Você fornece backdoor de fabricação para desabilitar a proteção JTAG? Você marcar se esse backdoor não estiver presente nos sistemas de produção?
    3. Você limpa o TPM quando o JTAG está habilitado?
    4. Você dá suporte a qualquer outro depurador de hardware? E faça as mesmas verificações para ele.
  8. Você provisionou o segredo exclusivo por dispositivo corretamente?
  9. Quais são os fusíveis de segurança que você tem (específico do fornecedor)
    1. Fusível SOC SecureBoot
    2. Segredos exclusivos por dispositivo, como fusíveis de endosso ou encypherment
    3. Fusíveis JTAG
    4. Fusível SecureBoot do Processador de Aplicativos SOC
    5. Fusível SecureBoot do processador soc MBA
    6. SoC Modern Processor SecureBoot fuse
    7. Qualquer outro fusível específico do SOC para sua plataforma

Verificações de HSTI do IBV

  1. Você usa somente RSA 2048 e SHA256 (ou superior, mas não menor que isso)
  2. CSM (Módulos de Suporte à Compatibilidade)
    1. Você fornece a opção para habilitar o CSM
    2. Você marcar o bloqueio de carregamento de CSM quando SecureBoot estiver habilitado
    3. [CS] Você marcar se o CSM não estiver presente em sistemas CS permanentemente
  3. O Código do Firmware deve estar presente no armazenamento protegido
    1. Você protege o spiflash?
    2. Você implementa somente leitura até a redefinição para partições eMMC
    3. Você dá suporte à Verificação de Firmware Assinado – o firmware instalado pelo OEM é somente leitura ou protegido pelo processo de atualização de firmware seguro.
  4. Processo de atualização de firmware seguro
    1. O processo de atualização de firmware seguro está ativado por padrão com chaves de teste?
    2. Você marcar se as chaves de teste forem usadas na produção?
    3. Você permite a reversão para a versão de firmware insegura? Se sim, então qual é o mecanismo de proteção? Você limpa o TPM quando a reversão acontece?
    4. As chaves de teste estão sendo usadas?
  5. Você tem backdoors para substituir SecureBoot
    1. O sistema dá suporte à solicitação embutida para ignorar o Secureboot? Se sim, ele será desabilitado enquanto SecureBoot estiver habilitado?
    2. Você tem backdoors de fabricação? Você marcar para que eles sejam desabilitados enquanto SecureBoot estiver habilitado e sempre desabilitado no sistema de produção?
  6. [CS] Proteção contra DMA interno e externo
    1. Você mantém o DMA interno ativado apenas para componentes necessários durante a inicialização? E está desabilitado para todos os outros componentes.
    2. Você mantém o DMA externo ativado apenas para componentes necessários durante a inicialização? E está desabilitado para todos os outros componentes.
    3. Se o firmware tiver uma opção para habilitar e desabilitar a proteção contra DMA, a configuração de envio deverá ter a proteção de DMA habilitada por padrão
    4. Quais barramentos/dispositivos (fusíveis, mecanismos de segurança, TZ, vídeo, caches, IMEM, memória de kernel) são capazes de acessar o DMA a diferentes regiões de armazenamento NV e voláteis e como eles são protegidos?
    5. Você dá suporte à implementação de bits MOR