Partilhar via

Diretrizes de Criação e Gerenciamento de Chaves de Inicialização Segura do Windows

  • Artigo

Este documento ajuda a orientar OEMs e ODMs na criação e gerenciamento de chaves e certificados de inicialização segura em um ambiente de fabricação. Ele aborda questões relacionadas à criação, ao armazenamento e à recuperação de chaves de plataforma (PKs), chaves seguras de atualização de firmware e chaves de troca de chave (KEKs) de terceiros.

Observação

OEMs de dispositivos, empresas e clientes podem encontrar os binários PK, KEK, DB e DBX recomendados pela Microsoft em Repositório de código aberto de inicialização segura da Microsoft. Os binários são formatados no formato EDKII esperado para integração fácil ao firmware.

Observação

O Microsoft Corporation KEK CA 2011 está programado para expirar em 2026, e todos os OEMs devem criar, assinar e enviar atualizações para o novo Microsoft Corporation KEK CA 2023 à Microsoft. Isso permitirá que a Microsoft atualize dispositivos no mercado com o novo Microsoft KEK CA, permitindo que os sistemas continuem recebendo atualizações de DB e DBX após 2026. Para obter instruções e material de teste, visite https://aka.ms/KEKUpdatePackage

Os requisitos do Windows para UEFI e inicialização segura podem ser encontrados nos Requisitos de certificação de hardware do Windows. Este documento não introduz novos requisitos nem representa um programa oficial do Windows. Seu objetivo é servir de orientação além dos requisitos de certificação, para auxiliar na construção de processos eficientes e seguros para criação e gerenciamento de chaves de inicialização seguras. Isso é importante porque a Inicialização Segura UEFI é baseada no uso de Infraestrutura de Chave Pública para autenticar o código antes de sua execução ser permitida.

Espera-se que o leitor conheça os fundamentos da UEFI, a compreensão básica da inicialização segura (Capítulo 27 da especificação UEFI) e o modelo de segurança PKI.

Requisitos, testes e ferramentas que validam a inicialização segura no Windows estão disponíveis hoje por meio do Kit de Certificação de Hardware (HCK) do Windows. No entanto, esses recursos do HCK não abordam a criação e o gerenciamento de chaves para implantações do Windows. Este documento aborda o gerenciamento de chaves como um recurso para ajudar a orientar os parceiros na implantação das chaves usadas pelo firmware. Não se destina a ser uma orientação prescritiva e não inclui quaisquer novos requisitos.

Nesta página:

Este documento serve como ponto de partida no desenvolvimento de computadores prontos para o cliente, ferramentas de implantação de fábrica e principais práticas recomendadas de segurança.

1. Inicialização segura, Windows e gerenciamento de chaves

A especificação UEFI (Unified Extensible Firmware Interface) define um processo de autenticação de execução de firmware chamado inicialização segura. Como padrão do setor, a inicialização segura define como o firmware da plataforma gerencia certificados, autentica o firmware e como o sistema operacional faz interface com esse processo.

A inicialização segura é baseada no processo de Infraestrutura de Chave Pública (PKI) para autenticar módulos antes que eles possam ser executados. Esses módulos podem incluir drivers de firmware, ROMs opcionais, drivers UEFI em disco, aplicativos UEFI ou carregadores de inicialização UEFI. Por meio da autenticação de imagem antes da execução, a inicialização segura reduz o risco de ataques de malware pré-inicialização, como rootkits. A Microsoft depende da UEFI - Inicialização Segura no Windows 8 e superior como parte de sua arquitetura de segurança Inicialização Confiável para melhorar a segurança da plataforma para nossos clientes. A inicialização segura é necessária para computadores clientes com Windows 8 e versões superiores e para o Windows Server 2016, conforme definido nos Requisitos de compatibilidade de hardware do Windows.

O processo de inicialização segura funciona da seguinte maneira e conforme mostrado na Figura 1:

  1. Componentes de inicialização de firmware: o firmware verifica se o carregador do sistema operacional é confiável (Windows ou outro sistema operacional confiável).
  2. Componentes de inicialização do Windows: BootMgr, WinLoad, inicialização do kernel do Windows. Os componentes de inicialização do Windows verificam a assinatura de cada componente. Nenhum componente não confiável será carregado e, em vez disso, acionará a correção da inicialização segura.
    • Inicialização do software antivírus e antimalware: este software é verificado quanto a uma assinatura especial emitida pela Microsoft, analisando se é um driver crítico de inicialização confiável e será iniciado no início do processo de inicialização.
    • Inicialização do driver crítico de inicialização: as assinaturas em todos os drivers críticos para inicialização são verificadas como parte da verificação de inicialização segura no WinLoad.
  3. Inicialização adicional do sistema operacional
  4. Tela de logon do Windows

imagem da arquitetura de integridade da plataforma

Figura 1: arquitetura de inicialização confiável do Windows

A implementação da UEFI - Inicialização Segura faz parte da arquitetura de inicialização confiável da Microsoft, introduzida no Windows 8.1. Uma tendência crescente na evolução das explorações de malware é direcionar o caminho de inicialização como vetor de ataque preferencial. Tem sido difícil se proteger contra essa classe de ataque, uma vez que os produtos antimalware podem ser desativados por um software malicioso que os impede de serem totalmente carregados. Com a arquitetura de inicialização confiável do Windows e o estabelecimento de uma raiz de confiança com a inicialização segura, o cliente fica protegido contra códigos maliciosos em execução no caminho de inicialização, garantindo que apenas códigos e carregadores de inicialização assinados e certificados como "em boas condições" possam ser executados antes que o próprio sistema operacional seja carregado.

1.1 Infraestrutura de Chave Pública (PKI) e inicialização segura

A PKI estabelece autenticidade e confiança em um sistema. A inicialização segura aproveita a PKI para duas finalidades de alto nível:

  1. Durante a inicialização para determinar se os módulos de inicialização iniciais são confiáveis para execução.
  2. Para autenticar solicitações de serviço, inclua a modificação dos bancos de dados da inicialização segura e atualizações do firmware da plataforma.

Uma PKI consiste em:

  • Uma autoridade de certificação (CA) que emite os certificados digitais.
  • Uma autoridade de registro que verifica a identidade dos usuários que solicitam um certificado da CA.
  • Um diretório central no qual armazenar e indexar chaves.
  • Um sistema de gerenciamento de certificados.

1.2 Criptografia de chave pública

A criptografia de chave pública usa um par de chaves criptográficas matematicamente relacionadas, conhecidas como chave pública e chave privada. Se você conhece uma das chaves, não poderá calcular facilmente qual é a outra. Se uma chave for usada para criptografar informações, somente a chave correspondente poderá descriptografar essas informações. Para inicialização segura, a chave privada é usada para assinar digitalmente o código e a chave pública é usada para verificar a assinatura desse código para provar sua autenticidade. Se uma chave privada for comprometida, os sistemas com chaves públicas correspondentes não serão mais seguros. Isso pode levar a ataques de kit de inicialização e prejudicará a reputação da entidade responsável por garantir a segurança da chave privada.

Em um sistema de chave pública de inicialização segura, você tem o seguinte:

  • 1.2.1 Criptografia RSA 2048

    RSA-2048 é um algoritmo criptográfico assimétrico. O espaço necessário para armazenar um módulo RSA-2048 na forma bruta é de 2.048 bits.

  • 1.2.2 Certificado autoassinado

    Um certificado assinado pela chave privada que corresponde à chave pública do certificado é conhecido como certificado autoassinado. Os certificados da autoridade de certificação raiz (CA) se enquadram nesta categoria.

  • 1.2.3 Autoridade de certificação

    A autoridade de certificação (CA) emite certificados assinados que afirmam a identidade do titular do certificado e vinculam essa identidade à chave pública contida no certificado. A CA assina o certificado usando sua chave privada. Ela emite a chave pública correspondente a todas as partes interessadas em um certificado de CA raiz autoassinado.

    Na inicialização segura, as autoridades de certificação (CAs) incluem o OEM (ou seus delegados) e a Microsoft. As CAs geram os pares de chaves que formam a raiz da confiança e, em seguida, usam as chaves privadas para assinar operações legítimas, como módulos EFI de inicialização antecipada permitida e solicitações de manutenção de firmware. As chaves públicas correspondentes são enviadas incorporadas ao firmware UEFI em PCs habilitados para inicialização segura e são usadas para verificar essas operações.

    (Mais informações sobre o uso de CAs e trocas de chave estão prontamente disponíveis na Internet relacionadas ao modelo de inicialização segura.)

  • 1.2.4 Chave pública

    A chave pública da plataforma vem no PC e é acessível ou “pública”. Neste documento, usaremos o sufixo “pub” para denotar a chave pública. Por exemplo, PKpub denota a metade pública da PK.

  • 1.2.5 Chave privada

    Para que a PKI funcione, a chave privada precisa ser gerenciada com segurança. Deve ser acessível a alguns indivíduos altamente confiáveis em uma organização e localizado em um local fisicamente seguro, com fortes restrições de política de acesso em vigor. Neste documento, usaremos o sufixo “priv” para denotar a chave privada. Por exemplo, o PKpriv indica a metade privada da PK.

  • 1.2.6 Certificados

    O principal uso dos certificados digitais é verificar a origem dos dados assinados, como binários etc. Um uso comum dos certificados é para segurança de mensagens da Internet usando Transport Layer Security (TLS) ou Secure Sockets Layer (SSL). A verificação dos dados assinados com um certificado permite ao destinatário saber a origem dos dados e se estes foram alterados durante o trânsito.

    Um certificado digital em geral contém, em alto nível, um nome distinto (DN), uma chave pública e uma assinatura. O DN identifica uma entidade (uma empresa, por exemplo) que detém a chave privada que corresponde à chave pública do certificado. Assinar o certificado com uma chave privada e colocar a assinatura no certificado vincula a chave privada à chave pública.

    Os certificados podem conter alguns outros tipos de dados. Por exemplo, um certificado X.509 inclui o formato do certificado, o número de série do certificado, o algoritmo usado para assinar o certificado, o nome da CA que emitiu o certificado, o nome e a chave pública da entidade que solicita o certificado e a assinatura de CA.

  • 1.2.7 Encadeamento de certificados

    De: Cadeias de certificados:

    autoridade de certificação raiz autoassinada, outros assinados por autoridade de certificação

    Figura 2: cadeia de três certificados

    Os certificados de usuário geralmente são assinados por uma chave privada diferente, como uma chave privada da CA. Isso constitui uma cadeia de dois certificados. A verificação de que um certificado de usuário é genuíno envolve a verificação de sua assinatura, que requer a chave pública da CA, a partir de seu certificado. Mas antes que a chave pública da CA possa ser usada, o certificado da CA anexa precisa ser verificado. Como o certificado de CA é autoassinado, a chave pública de CA é usada para verificar o certificado.

    Um certificado de usuário não precisa ser assinado pela chave privada da CA raiz. Pode ser assinado pela chave privada de um intermediário cujo certificado seja assinado pela chave privada da CA. Esta é uma instância de uma cadeia de três certificados: certificado de usuário, certificado intermediário e certificado de CA. Contudo, como mais de um intermediário pode fazer parte da cadeia, as cadeias de certificados podem ter qualquer comprimento.

1.3 Requisitos de PKI de inicialização segura

A raiz de confiança definida pela UEFI consiste na chave da plataforma e em quaisquer chaves que um OEM ou ODM inclua no núcleo do firmware. A segurança pré-UEFI e uma raiz de confiança não são abordadas pelo processo UEFI - Inicialização Segura, mas pelas publicações do National Institute of Standards and Technology (NIST) e do Trusted Computing Group (TCG) mencionadas neste artigo.

  • 1.3.1 Requisitos de inicialização segura

    Você precisará considerar os seguintes parâmetros para implementar a inicialização segura:

    • Requisitos do cliente
    • Requisitos de compatibilidade de hardware do Windows
    • Principais requisitos de geração e gerenciamento.

    Você precisará escolher hardware para gerenciamento de chaves de inicialização segura, como módulos de segurança de hardware (HSMs), bem como considerar requisitos especiais em PCs para envio a governos e outras agências e, por fim, o processo de criação, preenchimento e gerenciamento do ciclo de vida de várias chaves de inicialização segura.

  • 1.3.2 Chaves relacionadas à inicialização segura

    As chaves usadas para inicialização segura estão abaixo:

    pk, kek, db, dbx e chave de firmware, chave winrt

    Figura 3: chaves relacionadas à inicialização segura

    A Figura 3 acima representa as assinaturas e chaves em um PC com inicialização segura. A plataforma é protegida por uma chave de plataforma que o OEM instala no firmware durante a fabricação. Outras chaves são usadas pela inicialização segura para proteger o acesso a bancos de dados que armazenam chaves para permitir ou proibir a execução de firmware.

    O banco de dados autorizado (db) contém chaves públicas e certificados que representam componentes de firmware confiáveis e carregadores de sistema operacional. O banco de dados de assinaturas proibidas (dbx) contém hashes de componentes maliciosos e vulneráveis, bem como chaves e certificados comprometidos e bloqueia a execução desses componentes maliciosos. A força dessas políticas é baseada na assinatura de firmware usando Authenticode e Infraestrutura de Chave Pública (PKI). PKI é um processo bem estabelecido para criar, gerenciar e revogar certificados que estabelecem confiança durante a troca de informações. A PKI está no centro do modelo de segurança para inicialização segura.

    Veja abaixo mais detalhes sobre essas chaves.

  • 1.3.3 Chave de plataforma (PK)

    De acordo com a seção 27.5.1 da Errata C do UEFI 2.3.1, a chave da plataforma estabelece uma relação de confiança entre o proprietário da plataforma e o firmware da plataforma. O proprietário da plataforma inscreve a metade pública da chave (PKpub) no firmware da plataforma conforme especificado na Seção 7.2.1 da Errata C do UEFI. Esta etapa move a plataforma para o modo de usuário a partir do modo de configuração. A Microsoft recomenda que a chave da plataforma seja do tipo EFI_CERT_X509_GUID com algoritmo de chave pública RSA, comprimento de chave pública de 2.048 bits e algoritmo de assinatura sha256RSA. O proprietário da plataforma pode usar o tipo EFI_CERT_RSA2048_GUID se o espaço de armazenamento for uma preocupação. As chaves públicas são usadas para verificar assinaturas conforme descrito anteriormente neste documento. O proprietário da plataforma pode posteriormente usar a metade privada da chave (PKpriv):

    • Para alterar a propriedade da plataforma, você deve colocar o firmware no modo de configuração definido pela UEFI, que desativa a inicialização segura. Reverta para o modo de configuração somente se houver necessidade de fazer isso durante a fabricação.
    • Para dispositivos de desktop e servidores, os OEMs podem gerenciar a PK e a PKI necessária associada a ela ou optar por usar a PK gerenciada pela Microsoft para OEMs. A PK gerenciada pela Microsoft é protegida por HSMs da Microsoft e gerenciada como parte das práticas recomendadas de PKI. É a PK preferida para o ecossistema Windows.

    1.3.3.1 Para registrar ou atualizar uma chave de troca de chaves (KEK) registrando a chave da plataforma

    O proprietário da plataforma inscreve a metade pública da chave da plataforma (PKpub) chamando o UEFI Boot Service SetVariable() conforme especificado na Seção 7.2.1 da errata C da UEFI Spec 2.3.1 e redefinindo a plataforma. Se a plataforma estiver em modo de configuração, o novo PKpub deverá ser assinado com sua contraparte PKpriv. Se a plataforma estiver em modo de usuário, o novo PKpub deverá ser assinado com o PKpriv atual. Se a PK for do tipo EFI_CERT_X509_GUID, então deve ser assinada pelo PKpriv imediato; não é uma chave privada de qualquer certificado emitido de acordo com a PK.

    1.3.3.2 Limpeza da chave da plataforma

    O proprietário da plataforma limpa a metade pública da chave da plataforma (PKpub) chamando o UEFI Boot Service SetVariable() com um tamanho variável de 0 e redefinindo a plataforma. Se a plataforma estiver no modo de configuração, a variável vazia não precisará ser autenticada. Se a plataforma estiver no modo de usuário, a variável vazia deverá ser assinada com o PKpriv atual; consulte a Seção 7.2 (Serviços variáveis) em Especificação UEFI 2.3.1 Errata C para detalhes. É altamente recomendável que o PKpriv de produção nunca seja usado para assinar um pacote para redefinir a plataforma, pois isso permite que a inicialização segura seja desabilitada programaticamente. Este é principalmente um cenário de teste de pré-produção.

    A chave da plataforma também pode ser apagada usando um método seguro específico da plataforma. Nesse caso, o modo de configuração de variável global também deve ser atualizada para 1.

    imagem: pk determina o modo de configuração ou modo de usuário

    Figura 4: diagrama de estado de chave da plataforma

    1.3.3.3 Geração de APK

    De acordo com as recomendações da UEFI, a chave pública deve ser armazenada em armazenamento não volátil que seja resistente a adulteração e exclusão no PC. As chaves privadas permanecem seguras com o Parceiro ou no Escritório de Segurança do OEM, e apenas a chave pública é carregada na plataforma. Há mais detalhes nas seções 2.2.1 e 2.3.

    A Microsoft fornece uma PK para OEMs para eliminar a responsabilidade de manter e proteger o certificado da PK. A PK é protegida por HSMs da Microsoft e gerenciada como parte de nossas operações de PKI da Microsoft.

    O número de PK gerado fica a critério do proprietário da plataforma (OEM). Essas chaves podem ser:

    1. Uma por PC. Ter uma chave exclusiva para cada dispositivo. Isso pode ser necessário para agências governamentais, instituições financeiras ou outros clientes de servidores com necessidades de alta segurança. Pode ser necessário armazenamento adicional e capacidade de processamento de criptografia para gerar chaves públicas e privadas para um grande número de PCs. Isso aumenta a complexidade do mapeamento de dispositivos com sua PK correspondente ao enviar atualizações de firmware para os dispositivos no futuro. Existem algumas soluções HSM diferentes disponíveis para gerenciar um grande número de chaves com base no fornecedor do HSM. Para obter mais informações, consulte Geração segura de chave de inicialização usando HSM.

    2. Uma por modelo. Ter uma chave por modelo de PC. A desvantagem aqui é que, se uma chave for comprometida, todas as máquinas do mesmo modelo ficarão vulneráveis. Isso é recomendado pela Microsoft para PCs desktop.

    3. Uma por linha de produto. Se uma chave for comprometida, toda uma linha de produtos ficará vulnerável.

    4. Uma por OEM. Embora possa ser o mais simples de configurar, se a chave for comprometida, todos os PCs que você fabricar ficarão vulneráveis. Para acelerar a operação no chão de fábrica, a PK e outras chaves podem ser pré-geradas e armazenadas em um local seguro. Elas podem ser posteriormente recuperadas e usadas na linha de montagem. Os capítulos 2 e 3 têm mais detalhes.

    1.3.3.4 Rechaveamento da PK

    Isso pode ser necessário se a PK for comprometida ou como exigência de um cliente que, por motivos de segurança, decida registrar sua própria PK.

    O rechaveamento pode ser feito para um modelo ou computador com base no método selecionado para criar a PK. Todos os computadores mais novos serão assinados com a PK recém-criada.

    A atualização da PK em um computador de produção exigiria uma atualização variável assinada com a PK existente que substitui a PK ou um pacote de atualização de firmware. Um OEM também pode criar um pacote SetVariable() e distribuí-lo com um aplicativo simples como o PowerShell, que apenas altera a PK. O pacote de atualização de firmware será assinado pela chave segura de atualização de firmware e verificado pelo firmware. Ao fazer uma atualização de firmware para atualizar a PK, tome cuidado para garantir que KEK, db e dbx sejam preservados.

    Em todos os computadores, é recomendável não usar a PK como chave segura de atualização de firmware. Se o PKpriv estiver comprometido, a chave segura de atualização de firmware também estará (já que são iguais). Nesse caso, a atualização para inscrever um novo PKpub pode não ser possível, uma vez que o processo de atualização também foi comprometido.

    Em computadores SOCs, há outro motivo para não usar a PK como chave segura de atualização de firmware. Isso ocorre porque a chave segura de atualização de firmware é permanentemente queimada em fusíveis de computadores que atendem aos requisitos de Certificação de Hardware do Windows.

  • 1.3.4 Chave de Troca de Chaves (KEK) As chaves de troca de chaves estabelecem uma relação de confiança entre o sistema operacional e o firmware da plataforma. Cada sistema operacional (e possivelmente cada aplicativo de terceiros que precisa se comunicar com o firmware da plataforma) registra uma chave pública (KEKpub) no firmware da plataforma.

    1.3.4.1 Registro de chaves de troca de chave

    As chaves de troca de chave são armazenadas em um banco de dados de assinaturas conforme descrito em 1.4 Bancos de dados de assinatura (Db e Dbx)). O banco de dados de assinaturas é armazenado como uma variável UEFI autenticada.

    O proprietário da plataforma registra as chaves de troca de chave chamando SetVariable() conforme especificado na Seção 7.2 (Serviços variáveis) em Especificação UEFI 2.3.1 Errata C com o conjunto de atributos EFI_VARIABLE_APPEND_WRITE e o parâmetro Data contendo as novas chaves, ou lendo o banco de dados usando GetVariable(), anexando a nova chave de troca de chave às chaves existentes e então gravando o banco de dados usando SetVariable() conforme especificado na Seção 7.2 (Serviços variáveis) em Especificação UEFI 2.3.1 Errata C sem o conjunto de atributos EFI_VARIABLE_APPEND_WRITE.

    Se a plataforma estiver no modo de configuração, a variável do banco de dados de assinatura não precisa ser assinada, mas os parâmetros para a chamada SetVariable() ainda devem ser preparados conforme especificado para variáveis autenticadas na Seção 7.2.1. Se a plataforma estiver em modo de usuário, o banco de dados de assinaturas deverá ser assinado com o PKpriv atual

    1.3.4.2 Limpeza da KEK

    É possível “limpar” (excluir) a KEK. Observe que se a PK não estiver instalada na plataforma, as solicitações "limpar" não precisam ser assinadas. Se elas estiverem assinadas, para limpar a KEK, é necessário um pacote assinado por PK. E, para limpar db ou dbx, é necessário um pacote assinado por qualquer entidade presente na KEK.

    1.3.4.3 Microsoft KEK

    Os 2 certificados Microsoft KEK a seguir são necessários para permitir a revogação de imagens inválidas, atualizando o dbx e, possivelmente, o db para se preparar para imagens assinadas do Windows mais recentes.

  1. Microsoft Corporation KEK CA 2011

    • Hash do certificado SHA-1: 31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O certificado Microsoft KEK pode ser baixado em: https://go.microsoft.com/fwlink/?LinkId=321185.

  2. Microsoft Corporation KEK 2K CA 2023

    • Hash do certificado SHA-1: 45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O certificado Microsoft KEK pode ser baixado em: https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault O fornecedor da plataforma deve fornecer um conjunto padrão de chaves de troca de chaves na variável KEKDefault. Consulte a seção 27.3.3 Especificação UEFI para obter mais informações.

1.3.4.5 KEK do OEM/terceiros: adição de várias KEK

Os clientes e proprietários de plataformas não precisam ter sua própria KEK. Em computadores que não sejam Windows RT, o OEM pode ter KEKs adicionais para permitir OEM adicional ou um controle de terceiros confiável do banco de dados e do dbx.

  • 1.3.5 Chave de atualização de firmware de inicialização seguraA chave de atualização segura de firmware é usada para assinar o firmware quando ele precisa ser atualizado. Essa chave deve ter uma força mínima de RSA-2048. Todas as atualizações de firmware devem ser assinadas com segurança pelo OEM, seu delegado confiável, como o ODM ou IBV (fornecedor independente de BIOS), ou por um serviço de assinatura seguro.

    De acordo com a Publicação NIST 800-147 Atualização de firmware de campo deve ser compatível com todos os elementos das diretrizes:

    Qualquer atualização do armazenamento flash do firmware deve ser assinada pelo criador.

    O firmware deve verificar a assinatura da atualização.

  • 1.3.6 Criação de chaves para atualização segura de firmware

    A mesma chave será usada para assinar todas as atualizações de firmware, já que a metade pública residirá no computador. Você também pode assinar a atualização do firmware com uma chave vinculada à chave de atualização do firmware seguro.

    Pode haver uma chave por computador, como PK, ou uma por modelo ou uma por linha de produto. Se houver uma chave por computador, isso significa que milhões de pacotes de atualização exclusivos precisarão ser gerados. Considere, com base na disponibilidade de recursos, qual método funcionará para você. Ter uma chave por modelo ou linha de produto é um bom compromisso.

    A chave pública da Atualização Segura de Firmware (ou seu hash para economizar espaço) será armazenada em algum armazenamento protegido na plataforma, geralmente flash protegido (PC) ou fusíveis programáveis únicos (SOC).

    Se apenas o hash dessa chave for armazenado (para economizar espaço), então a atualização do firmware incluirá a chave, e a primeira etapa do processo de atualização será verificar se a chave pública na atualização corresponde ao hash armazenado na plataforma.

    As cápsulas são um meio pelo qual o sistema operacional pode passar dados para o ambiente UEFI durante uma reinicialização. O Windows chama UEFI UpdateCapsule() para fornecer atualizações de firmware do sistema e do computador. No momento da inicialização, antes de chamar ExitBootServices(), o Windows transmitirá todas as novas atualizações de firmware encontradas no Windows Driver Store para UpdateCapsule(). O firmware do sistema UEFI pode usar esse processo para atualizar o firmware do sistema e do computador. Ao aproveitar esse suporte de firmware do Windows, um OEM pode contar com o mesmo formato e processo comuns para atualizar o firmware do sistema e do computador. O firmware deve implementar a tabela ACPI ESRT para oferecer suporte a UEFI UpdateCapsule() para Windows.

    Para obter detalhes sobre a implementação do suporte para a plataforma de atualização de firmware UEFI do Windows, consulte a seguinte documentação: plataforma de atualização de firmware UEFI do Windows.

    As cápsulas de atualização podem estar na memória ou no disco. O Windows oferece suporte a atualizações de memória.

    1.3.6.1 Cápsula (cápsula na memória)

    Veja a seguir o fluxo de eventos para que uma cápsula de atualização na memória funcione.

    1. Uma cápsula é colocada na memória por um aplicativo no sistema operacional
    2. O evento da caixa de correio está definido para informar o BIOS sobre atualização pendente
    3. O computador reinicia, verifica a imagem da cápsula e a atualização é realizada pelo BIOS

  • 1.3.7 Fluxo de trabalho de uma atualização típica de firmware

    1. Baixe e instale o driver de firmware.
    2. Reinicialize.
    3. O Carregador de Sistema Operacional detecta e verifica o firmware.
    4. O Carregador de Sistema Operacional transmite um blob binário para UEFI.
    5. A UEFI realiza a atualização do firmware (esse processo é de propriedade do fornecedor do silício).
    6. A detecção do Carregador de Sistema Operacional foi concluída com sucesso.
    7. O sistema operacional termina a inicialização.

1.4 Bancos de dados de assinatura (Db e Dbx)

  • 1.4.1 Banco de dados de assinaturas permitidas (db)

    O conteúdo do banco de dados EFI _IMAGE_SECURITY_DATABASE controla quais imagens são confiáveis ao verificar imagens carregadas. O banco de dados pode conter vários certificados, chaves e hashes para identificar imagens permitidas.

    Os 2 certificados a seguir devem ser incluídos no banco de dados para permitir o carregamento do Carregador de Sistema Operacional do Windows:

  1. Microsoft Windows Production PCA 2011

    • Hash do certificado SHA-1: 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O Windows Production PCA 2011 pode ser baixado aqui: https://go.microsoft.com/fwlink/p/?linkid=321192.

  2. Windows UEFI CA 2023

    • Hash do certificado SHA-1: 45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O Windows UEFI CA 2023 pode ser baixado aqui: https://go.microsoft.com/fwlink/?linkid=2239776.

Exceto em sistemas bloqueados para inicializar apenas o Windows, o OEM deve considerar a inclusão de CAs UEFI de terceiros da Microsoft para permitir que drivers UEFI e aplicativos de terceiros sejam executados no computador sem exigir etapas adicionais para o usuário.

  1. Microsoft Corporation UEFI CA 2011

    • Hash do certificado SHA-1: 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O Microsoft Corporation UEFI CA 2011 pode ser baixado aqui: https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Microsoft UEFI CA 2023

    • Hash do certificado SHA-1: b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • A Microsoft fornecerá o certificado aos parceiros e ele poderá ser adicionado como uma assinatura de tipo EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • O Microsoft UEFI CA 2023 pode ser baixado aqui: https://go.microsoft.com/fwlink/?linkid=2239872.

  • 1.4.2 DbDefault: o fornecedor da plataforma deve fornecer um conjunto padrão de entradas para o banco de dados de assinaturas na variável dbDefault. Para obter mais informações, consulte a seção 27.5.3 na especificação UEFI.

  • 1.4.3 Banco de dados de assinaturas proibidas (dbx)

    O conteúdo do dbx EFI_IMAGE_SIGNATURE_DATABASE1 deve ser marcado ao verificar imagens antes de marcar o db e qualquer correspondência deve impedir a execução da imagem. O banco de dados pode conter vários certificados, chaves e hashes para identificar imagens proibidas. Os Requisitos de Certificação de Hardware do Windows afirmam que um dbx deve estar presente; portanto, qualquer valor fictício, como o hash SHA-256 de 0, pode ser usado como um espaço reservado seguro até que a Microsoft comece a fornecer atualizações do dbx. Clique aqui para baixar a lista de revogação UEFI mais recente da Microsoft.

  • 1.4.4 DbxDefault: o fornecedor da plataforma pode fornecer um conjunto padrão de entradas para o banco de dados de assinaturas na variável dbxDefault. Para obter mais informações, consulte a seção 27.5.3 na especificação UEFI.

1.5 Chaves necessárias para inicialização segura em todos os computadores

Observação

OEMs de dispositivos, empresas e clientes podem encontrar os binários PK, KEK, DB e DBX recomendados pela Microsoft em Repositório de código aberto de inicialização segura da Microsoft. Os binários são formatados no formato EDKII esperado para integração fácil ao firmware.

Nome da chave/db Variável Proprietário Observações

PKpub

PK

OEM

PK – 1 apenas. Deve ser RSA 2048 ou mais forte.

https://go.microsoft.com/fwlink/?linkid=2255361

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

Permite atualizações para db e dbx:

https://go.microsoft.com/fwlink/p/?linkid=321185

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Microsoft Windows Production CA 2011

Windows UEFI CA 2023

db

Microsoft

Esta CA no banco de dados de assinatura (db) permite a inicialização do Windows: https://go.microsoft.com/fwlink/?LinkId=321192

https://go.microsoft.com/fwlink/p/?linkid=2239776.

Banco de dados de assinaturas proibidas

dbx

Microsoft

Lista de chaves, CAs ou imagens inválidas conhecidas da Microsoft

Chave segura de atualização de firmware

OEM

A recomendação é que esta chave seja diferente da PK

Tabela 1: chaves/db necessários para inicialização segura

2. Soluções de gerenciamento de chaves

Veja abaixo algumas das métricas que usamos para comparação.

2.1 Métricas utilizadas

As métricas a seguir podem ajudar você a selecionar um computador HSM com base nos requisitos de Especificação UEFI 2.3.1 Errata C e suas necessidades.

  • É compatível com RSA 2048 ou superior? - A Especificação UEFI 2.3.1 A Errata C recomenda que as chaves sejam RSA-2048 ou melhor.
  • Tem a capacidade de gerar chaves e assinar?
  • Quantas chaves pode armazenar? Armazena chaves no HSM ou em um servidor conectado?
  • Método de autenticação para recuperação de chave. Alguns computadores permitem a presença de múltiplas entidades de autenticação para recuperação de chaves.

Preços

  • Qual é o preço? O preço dos HSMs pode variar de US$ 1.500 a US$ 70.000, dependendo dos recursos disponíveis.

Ambiente de fabricação

  • Velocidade de operação no chão de fábrica. Os processadores criptográficos podem acelerar a criação e o acesso de chaves.
  • Facilidade de configuração, implantação e manutenção.
  • Conjunto de habilidades e treinamento são necessários?
  • Acesso à rede para backup e alta disponibilidade

Padrões e conformidade

  • Que nível de conformidade com FIPS possui? É inviolável?
  • Suporte para outros padrões, por exemplo, APIs de criptografia MS.
  • Atende aos requisitos do governo e de outras agências?

Confiabilidade e recuperação de desastres

  • Permite backup de chaves?

    Os backups podem ser armazenados no local, em um lugar seguro que seja físico diferente do computador CA e do HSM e/ou em um local externo.

  • Permite alta disponibilidade para recuperação de desastres?

2.2 Opções de gerenciamento de chaves

  • 2.2.1 Módulo de segurança de hardware (HSM)

    Com base nos critérios acima, essa é provavelmente a solução mais adequada e segura. A maioria dos HSM tem conformidade com FIPS 140-2 nível 3. A conformidade com o FIPS 140-2 nível 3 é rigorosa em termos de autenticação e exige que as chaves não sejam exportadas ou importadas do HSM.

    Elas oferecem suporte a várias formas de armazenamento de chaves. Elas podem ser armazenados localmente no próprio HSM ou no servidor conectado ao HSM. No servidor as chaves são criptografadas e armazenadas e é preferível para soluções que requerem o armazenamento de muitas chaves.

    A política de segurança do módulo criptográfico deve especificar uma política de segurança física, incluindo mecanismos de segurança física que são implementados em um módulo criptográfico, tais como selos invioláveis, bloqueios, respostas de violação e interruptores de zeragem e alarmes. Também permite especificar ações exigidas pelo(s) operador(es) para garantir que a segurança física seja mantida, como inspeção periódica de selos invioláveis ou testes de resposta de violação e interruptores de zeragem.

    • 2.2.1.1 HSM de rede

      Esta solução é a melhor da sua categoria em termos de segurança, adesão a padrões, geração de chaves, armazenamento e recuperação. A maioria desses computadores oferece suporte a alta disponibilidade e capacidade de fazer backup de chaves.

      Os custos desses produtos podem chegar a dezenas de milhares de dólares com base nos serviços extras que oferecem.

    • 2.2.1.2 Standalone HSM

      Eles funcionam muito bem com servidores independentes. Podem ser usados Microsoft CAPI e CNG ou qualquer outra API segura compatível com o HSM. Esses HSMs vêm em vários formatos que são compatíveis com barramentos USB, PCIe e PCMCIA.

      Ou também pode haver compatibilidade com o backup de chaves e alta disponibilidade.

  • 2.2.2 Provedores de soluções personalizadas

    A criptografia de chave pública pode ser desafiadora e exigir a compreensão de conceitos criptográficos que podem ser novos. Existem provedores de soluções personalizadas que podem ajudar a fazer com que a inicialização segura funcione no ambiente de fabricação.

    Existem diversas soluções personalizadas oferecidas por fornecedores de BIOS, empresas de HSM e empresas de consultoria de PKI para que a PKI de inicialização segura funcione no ambiente de fabricação.

    Alguns dos provedores estão listados abaixo:

  • 2.2.3 Trusted Platform Module (TPM)

    Um Trusted Platform Module (TPM) é um chip de hardware na placa-mãe que armazena chaves criptográficas usadas para criptografia. Muitos computadores incluem um TPM, mas, se o PC não o incluir, não é viável adicionar um. Uma vez ativado, o Trusted Platform Module pode ajudar a proteger produtos completos de criptografia de disco, como os recursos do Microsoft BitLocker. Ele mantém os discos rígidos bloqueados ou lacrados até que o computador conclua uma verificação do sistema ou processo de autenticação.

    O TPM pode gerar, armazenar e proteger chaves usadas no processo de criptografia e descriptografia.

    As desvantagens dos TPMs são que eles podem não ter processadores criptográficos rápidos para acelerar o processamento no ambiente de fabricação. Eles também não são adequados para armazenar um grande número de chaves. Backup, alta disponibilidade e conformidade com os padrões FIPS 140-2 nível 3 podem não estar disponíveis.

  • 2.2.4 Cartões inteligentes

    Um cartão inteligente pode gerar e armazenar chaves. Ele compartilha alguns recursos compatíveis com o HSM, como autenticação e proteção contra adulteração, mas não inclui muito armazenamento de chaves ou backup. Requer intervenção manual e pode não ser adequado para automação e uso em ambiente de produção, pois o desempenho pode ser baixo.

    As desvantagens dos cartões inteligentes são semelhantes às dos TPMs. Eles podem não ter processadores criptográficos rápidos para acelerar o processamento no ambiente de fabricação. Eles também não são adequados para armazenar um grande número de chaves. Backup, alta disponibilidade e conformidade com os padrões FIPS 140-2 nível 3 podem não estar disponíveis.

  • 2.2.5 Certificado de validação estendida

    Os certificados EV são certificados de alta garantia cujas chaves privadas são armazenadas em tokens de hardware. Isso ajuda a estabelecer práticas mais sólidas de gerenciamento de chaves. Os certificados EV têm as mesmas desvantagens dos cartões inteligentes.

  • 2.2.6 Abordagens centradas em software (NÃO RECOMENDADAS)

    Use APIs criptográficas para gerenciamento de chaves. Isso pode envolver o armazenamento de uma chave em um contêiner de chaves em um disco rígido criptografado e é possível usar uma máquina virtual para ter área restrita adicional e segurança.

    Essas soluções não são tão seguras quanto usar um HSM e expõem um vetor de ataque maior.

    2.2.6.1 Makecert (NÃO RECOMENDADO)

    Makecert é uma ferramenta da Microsoft e pode ser usada da seguinte forma para geração de chaves. Para garantir que a superfície de ataque seja minimizada, você pode precisar de um "air gap" no computador. O PC que possui o PKpriv ativado não deve estar conectado à rede. Deve estar em um local seguro e, idealmente, usar pelo menos um leitor de cartão inteligente, se não um HSM real.

    makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r

    Para obter mais informações, consulte Ferramenta de Criação de Certificado (Makecert.exe).

    Essa solução não é recomendada.

2.3 Geração e armazenamento de chaves HSM para chaves de inicialização segura

  • 2.3.1 Armazenando de chaves privadas

    O requisito de espaço para cada chave RSA-2048 é de 2.048 bits. A localização real do armazenamento das chaves depende da solução escolhida. HSM são uma boa maneira de armazenar chaves.

    A localização física dos computadores no chão de fábrica precisaria ser uma área protegida com acesso limitado do usuário, como uma gaiola segura.

    Dependendo dos seus requisitos, essas chaves também podem ser armazenadas em uma localização geográfica diversa ou com backup em um local diferente.

    Os requisitos de rechaveamento para essas chaves podem variar de acordo com o cliente (consulte o Apêndice A para obter diretrizes de rechaveamento da autoridade de certificação de ponte federal).

    Isso poderia ser feito uma vez por ano. Talvez você precise ter acesso a essas chaves por até 30 anos (dependendo dos requisitos de rechaveamento etc.).

  • 2.3.2 Recuperação das chaves privadas

    As chaves podem precisar ser recuperadas por vários motivos.

    1. A PK pode precisar ser recuperada para emitir uma PK atualizada devido ao comprometimento ou para aderir aos regulamentos do governo/outras agências.
    2. KEKpri será usado para atualizar o db e o dbx.
    3. A chave de atualização de firmware segura –pri será usada para assinar atualizações mais recentes.

  • 2.3.3. Autenticação

    De acordo com o FIPS 140-2, a autenticação é baseada no nível de acesso.

    Nível 2

    O Nível de Segurança 2 requer, no mínimo, autenticação baseada em funções, na qual um módulo criptográfico autentica a autorização de um operador para assumir uma função específica e executar um conjunto correspondente de serviços.

    Nível 3

    O Nível de Segurança 3 requer mecanismos de autenticação baseados em identidade, melhorando a segurança fornecida pelos mecanismos de autenticação baseados em funções especificados para o Nível de Segurança 2. Um módulo criptográfico autentica a identidade de um operador e verifica se o operador identificado está autorizado a assumir uma função específica e executar um conjunto correspondente de serviços.

    Computadores como o HSM oferecem suporte ao nível de segurança 3, que requer "autenticação k of m" baseada em identidade. Isso significa que k entidades recebem acesso ao HSM com um token, mas, em determinado ponto, pelo menos k dos m tokens precisam estar presentes para que a autenticação funcione e obtenha acesso às chaves privadas do HSM.

    Por exemplo, você pode ter 3 de 5 tokens autenticados para acessar o HSM. Esses membros podem ser os agentes de segurança, o autorizador de transações e/ou membros da Gerência Executiva.

    Tokens HSM

    Você poderia ter uma política no HSM que exija a presença do token:

    • Localmente

    • Remotamente

    • Configurado para ser automatizado

    Como boa prática, use uma combinação de token e senha por token.

2.4 Inicialização segura e assinatura de terceiros

  • 2.4.1 Assinatura do driver UEFI

    Os drivers UEFI devem ser assinados por uma CA ou chave no banco de dados conforme descrito em outra parte do documento, ou ter o hash da imagem do driver incluído no banco de dados. A Microsoft fornecerá um serviço de assinatura do driver UEFI semelhante ao serviço de assinatura do driver WHQL usando o Microsoft Corporation UEFI CA 2011. Todos os drivers assinados por este serão executados perfeitamente em qualquer PC que inclua o Microsoft UEFI CA. Também é possível para um OEM assinar drivers confiáveis e incluir a CA OEM no banco de dados ou incluir hashes dos drivers no banco de dados. Em todos os casos, um driver UEFI (ROM opcional) não será executado se não for confiável no banco de dados.

    Nenhum driver incluído na imagem de firmware do sistema precisa ser verificado novamente. Fazer parte da imagem geral do sistema fornece garantia suficiente de que o driver é confiável no PC.

    A Microsoft disponibilizou esse recurso para quem deseja assinar drivers UEFI. Esse certificado faz parte dos testes de inicialização segura do Windows HCK. Siga [este blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) para ler mais sobre a política e atualizações de assinatura da CA UEFI.

  • 2.4.2 Carregadores de inicialização

    O certificado de assinatura do driver UEFI da Microsoft pode ser usado para assinar outros sistemas operacionais. Por exemplo, o gerenciador de inicialização Linux do Fedora será assinado por ele.

    Esta solução não requer a adição de mais certificados ao banco de dados de chave. Além de ser econômico, pode ser usado em qualquer distribuição Linux. Essa solução funcionaria em qualquer hardware que suporte Windows. Por isso, é útil para uma ampla variedade de hardware.

    O UEFI-CA pode ser baixado aqui: https://go.microsoft.com/fwlink/p/?LinkID=321194. Os links a seguir contêm mais informações sobre assinatura e envio UEFI do Windows HCK:

3. Resumo e recursos

Esta seção tem como propósito resumir as seções acima e mostrar uma abordagem passo a passo:

  1. Estabeleça uma CA segura ou identifique um parceiro para gerar e armazenar chaves com segurança

    Se você não estiver usando uma solução de terceiros:

    1. Instale e configure o software HSM no servidor HSM. Verifique o manual de referência do HSM para obter instruções de instalação. O servidor será conectado a um HSM independente ou de rede.

      Para obter informações sobre a configuração do HSM, consulte a Seção 2.2.1, 2.3 e o Apêndice C.

      A maioria dos HSMs oferece conformidade com FIPS 140-2 níveis 2 e 3. Configure o HSM para conformidade de nível 2 ou nível 3. A conformidade de nível 3 tem requisitos mais rígidos em relação à autenticação e acesso à chave e, portanto, é mais segura. Recomenda-se o nível 3.

    2. Configure o HSM para alta disponibilidade, backup e autenticação. Verifique o manual de referência do seu HSM.

      Siga as diretrizes do provedor do HSM sobre como configurar o HSM para alta disponibilidade e backup.

      Além disso, os HSMs de rede geralmente possuem diversas portas de rede para segregar o tráfego, permitindo que um servidor se comunique com HSMs de rede em uma rede separada da rede de produção normal.

      Depois que os membros da equipe que fazem parte da equipe de segurança forem identificados e os tokens atribuídos a eles. Você precisará configurar o hardware HSM para autenticação k-of-m.

    3. Chaves de inicialização seguras e pré-geração de certificados. Consulte as secções 1.3 a 1.5

      Use APIs HSM para pré-gerar (gerar antecipadamente) o PK e a chave de atualização de firmware e os certificados.

      Obrigatório: PK (recomenda-se 1 por modelo), chave de atualização de firmware (recomenda-se 1 por modelo), Microsoft KEK, Db, DbxNOTA: Microsoft KEK, db e dbx não precisam ser gerados pelo OEM e são mencionados para serem completos. Opcional: KEK db OEM/terceiros, dbx e quaisquer outras chaves que entrarem no OEM Db.

  2. Aplique uma imagem do Windows ao PC.

  3. Instale o Microsoft db e dbx. Consulte a Seção 1.3.6 e Apêndice B: APIs de inicialização segura.

    1. Instale o Produção PCA 2011 do Microsoft Windows no db.

    2. Instale um dbx vazio se a Microsoft não fornecer um. O Windows atualizará automaticamente o DBX para o DBX mais recente por meio do Windows Update na primeira reinicialização.

    Observação

    Use cmdlets do PowerShell que fazem parte dos testes do Windows HCK ou use métodos fornecidos pelo fornecedor do BIOS.

  4. Instale o Microsoft KEK. Consulte a seção 1.3.3.

    Instale o Microsoft KEK no banco de dados UEFI KEK

    Cuidado

    Use cmdlets do PowerShell que fazem parte dos testes do Windows HCK ou use métodos fornecidos pelo fornecedor do BIOS.

  5. Etapa opcional: componentes de inicialização segura do OEM/terceiros. Consulte a seção 1.3.4 e 1.4.

    1. Identifique se você precisa criar uma KEK, db e dbx de OEM/terceiros.

    2. Assine db de OEM/terceiros e dbx com KEK de OEM/terceiros (gerado anteriormente) usando API HSM.

    3. Instale KEK, db e dbx de OEM/terceiros.

  6. Assinatura do driver UEFI – Consulte a Seção 2.4.

    Se for compatível com placas complementares ou outros drivers/aplicativos/bootloaders UEFI, instale o Microsoft Corporation UEFI CA 2011 no db UEFI.

  7. Chave de atualização de firmware de inicialização segura - Consulte a Seção 1.3.5.

    1. Somente PCs não Windows RT: instale a chave pública de atualização segura do firmware ou seu hash para economizar espaço.

    2. Apenas no SoC, pode ser necessário fazer algo diferente (por exemplo, gravar a chave de atualização de firmware segura: pública ou seu hash).

  8. Habilitação da inicialização segura. Consulte Apêndice B – APIs de inicialização segura.

    1. Instale o OEM/ODM PKpub (certificado preferencial, mas a chave está correta) na PK UEFI.

    2. Registre a PK usando a API de inicialização segura. O PC agora deve estar habilitado para inicialização segura.

    Observação

    Se você instalar o PK no final, MS KEK, db e dbx não precisarão ser assinados; nenhum SignerInfo deverá estar presente. É um atalho.

  9. Teste da inicialização segura: execute quaisquer testes proprietários e testes do Windows HCK conforme as instruções. Consulte Apêndice B – APIs de inicialização segura.

  10. Plataforma de envio: o PKpriv provavelmente nunca mais será usado; mantenha-o seguro.

  11. Manutenção: as futuras atualizações de firmware são assinadas com segurança com a chave "privada" da atualização segura de firmware usando o serviço de assinatura.

3.1 Recursos

Artigo técnico sobre estratégias de segurança - https://go.microsoft.com/fwlink/p/?linkid=321288

Envio do Windows HCK -https://go.microsoft.com/fwlink/p/?linkid=321287

Apêndice A – Lista de verificação de PKI de inicialização segura para fabricação

Veja abaixo a lista de verificação de alto nível que resume as etapas necessárias para habilitar a inicialização segura em PCs não Windows RT.

Configuração da inicialização segura

  1. Defina a estratégia de segurança (identifique ameaças, defina estratégias proativas e reativas) conforme o white paper na seção 4.

  2. Identifique a equipe de segurança de acordo com o white paper na seção 4.

  3. Estabeleça uma CA segura ou identifique um parceiro (solução recomendada) para gerar e armazenar chaves com segurança.

  4. Identifique a política de frequência com que você redigitará as chaves. Isso pode depender se você tiver algum requisito especial de cliente, como governos ou outras agências.

  5. Tenha um plano de contingência caso a chave de inicialização segura seja comprometida.

  6. Identifique quantas PK e outras chaves você gerará conforme as seções 1.3.3 e 1.5.

    Isso será baseado na base de clientes, solução de armazenamento de chaves e segurança dos PCs.

    Você pode pular as etapas 7 a 8 se estiver usando a solução recomendada de terceiros para gerenciamento de chaves.

  7. Adquira servidor e hardware para gerenciamento de chaves. – rede ou HSM autônomo conforme a seção 2.2.1. Considere se você precisará de um ou vários HSMs para alta disponibilidade e sua principal estratégia de backup.

  8. Identifique pelo menos 3 a 4 membros da equipe que terão um token de autenticação para autenticação no HSM.

  9. Use HSM ou terceiros para pré-gerar chaves e certificados relacionados à inicialização segura. As chaves dependerão do tipo de PC: SoC, Windows RT ou não Windows RT. Para obter mais informações, consulte as Seções 1.3 a 1.5.

  10. Preencha o firmware com as chaves apropriadas.

  11. Registre a chave da plataforma de inicialização segura para ativar a inicialização segura. Consulte o Apêndice B para obter mais detalhes.

  12. Execute quaisquer testes proprietários e testes de inicialização segura do HCK conforme as instruções. Consulte o Apêndice B para obter mais detalhes.

  13. Envie o PC. O PKpriv provavelmente nunca mais será usado; mantenha-o seguro.

Manutenção (atualização de firmware)

Pode ser necessário atualizar o firmware por vários motivos, como atualizar um componente UEFI ou corrigir o comprometimento da chave de inicialização segura ou rechaveamento periódico de chaves de inicialização segura.

Para obter mais informações, consulte as seções 1.3.5 e 1.3.6.

Apêndice B – APIs de inicialização segura

  1. APIs de inicialização segura

    As seguintes APIs estão relacionadas ao UEFI/inicialização segura:

    1. GetFirmwareEnvironmentVariableEx: recupera o valor da variável de ambiente de firmware especificada.

    2. SetFirmwareEnvironmentVariableEx: define o valor da variável de ambiente de firmware especificada.

    3. GetFirmwareType: recupera o tipo de firmware.

  2. Configuração da PK

    Use o cmdlet Set-SecureBootUEFI para ativar a inicialização segura. Depois que seu código definir a PK, a aplicação da inicialização segura do sistema não entrará em vigor até a próxima reinicialização. Antes da reinicialização, seu código poderá chamar GetFirmwareEnvironmentVariableEx() ou o cmdlet do PowerShell: Get-SecureBootUEFI para confirmar o conteúdo dos bancos de dados de inicialização segura.

  3. Verificação

    Você pode usar cmdlets Msinfo32.exe ou PowerShell para verificar o estado da variável de inicialização segura. Não há interface WMI. Você também pode testar fazendo com que alguém insira um pendrive inicializável assinado incorretamente (por exemplo, do teste de logotipo manual de inicialização segura do Windows HCK) e verifique se ele falha na inicialização.

  4. Cmdlets Powershell de inicialização segura

    • Confirm-SecureBootUEFI: a UEFI - Inicialização Segura está "LIGADA", é verdadeira ou falsa?

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: defina ou anexe variáveis SecureBoot UEFI autenticadas

    • Get-SecureBootUEFI: obtenha valores de variáveis SecureBoot UEFI autenticados

    • Format-SecureBootUEFI: crie serializações EFI_SIGNATURE_LISTs e EFI_VARIABLE_AUTHENTICATION_2

  5. Windows HCK e instruções de inicialização segura

    As etapas a seguir se aplicam a testes de sistema e testes de PC de driver não pertencentes à classe.

    1. Desative as proteções de inicialização segura.

      Insira a configuração do BIOS e desative a Inicialização Segura.

    2. Instale o software cliente do HCK.

    3. Execute todos os testes do Windows HCK, exceto os seguintes:

      • Testes de senha de recuperação e TPM do BitLocker com PCR[7]
      • Testes de senha de recuperação e TPM do BitLocker para PCs do ARM com inicialização segura
      • Teste de logotipo de inicialização segura
      • Teste manual de logotipo de inicialização segura

    4. Insira a configuração do BIOS, habilite a inicialização segura e restaure-a com a configuração padrão.

    5. Execute os seguintes testes de BitLocker e inicialização segura:

      • Testes de senha de recuperação e TPM do BitLocker com PCR[7]
      • Testes de senha de recuperação e TPM do BitLocker para PCs do ARM com inicialização segura
      • Teste de logotipo de inicialização segura (automatizado)

    6. Entre na configuração do BIOS e limpe a configuração de inicialização segura. Isso restaura o PC para o modo de configuração, excluindo PK e outras chaves.

      Observação

      O suporte para compensação é necessário para PCs x86/x64.

    7. Execute o teste de logotipo manual de inicialização segura.

      Observação

      A inicialização segura requer drivers assinados pelo Windows HCK ou VeriSign em PCs não Windows RT

  6. Teste de logotipo de inicialização segura do Windows HCK (automatizado)

    Este teste verificará a configuração adequada da inicialização segura pronto para uso. Isso inclui:

    • A inicialização segura está habilitada.
    • A PK não é uma PK de teste conhecida.
    • KEK contém a produção Microsoft KEK.
    • db contém a CA de produção do Windows.
    • dbx presente.
    • Muitas variáveis de 1 kB são criadas/excluídas.
    • Uma variável de 32 kB é criada/excluída.

  7. Layout da pasta de teste manual da inicialização segura do Windows HCK

    O layout da pasta de teste do logotipo do manual de inicialização segura do Windows HCK é descrito abaixo:

    • A pasta "\Test" tem o seguinte:

      • Teste de fabricação e manutenção
      • Habilitar programaticamente a inicialização segura na configuração de teste
      • Testes de manutenção
      • Anexe um certificado ao db, verifique a função
      • Anexe um hash ao dbx, verifique a função
      • Anexe um certificado ao dbx, verifique a função
      • Anexe mais de 600 hashes ao dbx, verifique o tamanho
      • Altere programaticamente o PK

    • A pasta "\Generate" tem scripts que mostram o seguinte:

      • Como os certificados de teste foram criados

      • Os certificados de teste e chaves privadas estão incluídos

      • Como todos os testes foram criados

      • Conversão de certificados e hashes em pacotes assinados

      • Você pode executá-lo isoladamente, substituindo seus próprios certificados

    • A pasta "\certs" tem todos os certificados necessários para inicializar o Windows:

      Observação

      Não use a metodologia usada em "ManualTests\generate\TestCerts" para gerar chaves e certificados. Isso se destina apenas a fins de teste do Windows HCK. Usa chaves armazenadas em disco, o que é muito inseguro e não recomendado. Não se destina ao uso em um ambiente de produção.

  • A pasta "ManualTests\example\OutOfBox" possui scripts que você pode aproveitar para instalação da inicialização segura em PCs de produção.

    O "ManualTests\generate\tests\subcreate_outofbox_example.ps1" demonstra como esses exemplos foram gerados e possuem seções "TODO" quando um parceiro pode substituir sua PK e outros metadados.

  1. Assinatura e envio do Windows HCK UEFI

    Os links a seguir possuem mais informações:

Apêndice C – Mapeamentos de garantia de política de certificado da Federal Bridge Certification Authority

  1. Rudimentar

    Este nível fornece o menor grau de segurança em relação à identidade do indivíduo. Uma das principais funções deste nível é fornecer integridade de dados às informações que estão sendo assinadas. Este nível é relevante para ambientes nos quais o risco de atividades maliciosas é considerado baixo. Não é adequado para transações que exigem autenticação e geralmente é insuficiente para transações que exigem confidencialidade, mas pode ser usado para essas últimas quando não estiverem disponíveis certificados com níveis de garantia mais elevados.

  2. Basic

    Este nível fornece um nível básico de garantia relevante para ambientes onde existem riscos e consequências de comprometimento de dados, mas não são considerados de grande importância. Isso pode incluir o acesso a informações privadas onde a probabilidade de acesso malicioso não seja elevada. Nesse nível de segurança, presume-se que os usuários provavelmente não serão mal-intencionados.

  3. Médio

    Esse nível é relevante para ambientes onde os riscos e consequências do comprometimento dos dados são moderados. Isso pode incluir transações com valor monetário substancial ou risco de fraude, ou que envolvam acesso a informações privadas onde a probabilidade de acesso malicioso seja substancial.

  4. Alto

    Esse nível é apropriado para utilização onde as ameaças aos dados são elevadas ou as consequências da falha dos serviços de segurança são altas. Isso pode incluir transações de valor muito elevado ou altos níveis de risco de fraude.

Geração e assinatura segura de chave de inicialização usando HSM (exemplo)

Diretrizes de validação da Opção ROM de validação de UEFI

Visão geral da inicialização segura