System Guard: como uma raiz de fidedignidade baseada em hardware ajuda a proteger o Windows
Para proteger recursos críticos, como a pilha de autenticação do Windows, tokens de início de sessão único, a pilha biométrica do Windows Hello e o Módulo de Plataforma Fidedigna Virtual, o firmware e hardware de um sistema têm de ser fidedignos.
O System Guard reorganiza as funcionalidades de integridade do sistema Windows existentes sob um teto e configura o próximo conjunto de investimentos na segurança do Windows. Foi concebido para garantir estas garantias de segurança:
- Proteger e manter a integridade do sistema à medida que é iniciado
- Validar que a integridade do sistema foi verdadeiramente mantida através do atestado local e remoto
Manter a integridade do sistema à medida que começa
Raiz Estática de Confiança para Medição (SRTM)
Com o Windows 7, um dos meios que os atacantes utilizariam para persistir e evitar a deteção era instalar o que é frequentemente referido como um bootkit ou rootkit no sistema. Este software malicioso seria iniciado antes do Windows iniciar ou durante o próprio processo de arranque, permitindo-lhe começar com o nível de privilégio mais elevado.
Com o Windows 10 em execução em hardware moderno, uma raiz de fidedignidade baseada em hardware ajuda a garantir que nenhum firmware ou software não autorizado (como um bootkit) pode ser iniciado antes do bootloader do Windows. Esta raiz de fidedignidade baseada em hardware provém da funcionalidade de Arranque Seguro do dispositivo, que faz parte da UeFI (Unified Extensible Firmware Interface). Esta técnica de medição dos componentes UEFI de arranque inicial estático chama-se Raiz Estática de Confiança para Medição (SRTM).
Como existem milhares de fornecedores de PC que produzem muitos modelos com diferentes versões do UEFI BIOS, torna-se um número incrivelmente grande de medições SRTM no arranque. Existem duas técnicas para estabelecer confiança aqui: manter uma lista de medições SRTM "incorretas" conhecidas (também conhecidas como lista de bloqueios) ou uma lista de medições SRTM "boas" conhecidas (também conhecidas como listas de permissões).
Cada opção tem uma desvantagem:
- Uma lista de medições SRTM "incorretas" conhecidas permite que um hacker altere apenas 1 bit num componente para criar um hash SRTM totalmente novo que precisa de ser listado. Isto significa que o fluxo SRTM é inerentemente frágil. Uma pequena alteração pode invalidar toda a cadeia de confiança.
- Uma lista de medições SRTM "boas" conhecidas requer que cada nova medição de combinação BIOS/PC seja cuidadosamente adicionada, o que é lento. Além disso, uma correção de erros para o código UEFI pode demorar muito tempo a conceber, compilar, voltar a atestar, validar e reimplementar.
Iniciação Segura — a Raiz Dinâmica de Confiança para Medição (DRTM)
O Lançamento Seguro do System Guard, introduzido pela primeira vez no Windows 10 versão 1809, tem como objetivo aliviar estes problemas através de uma tecnologia conhecida como Raiz Dinâmica de Confiança para Medição (DRTM). O DRTM permite que o sistema arranque livremente em código não fidedigno inicialmente, mas pouco depois inicia o sistema num estado fidedigno ao assumir o controlo de todas as CPUs e forçá-las a seguir um caminho de código bem conhecido e medido. Isto tem o benefício de permitir que o código UEFI inicial não fidedigno arranque o sistema, mas, em seguida, ser capaz de transitar de forma segura para um estado fidedigno e medido.
A Iniciação Segura simplifica a gestão das medições SRTM porque o código de início não está agora relacionado com uma configuração de hardware específica. Isto significa que o número de medições de código válidas é pequeno e as atualizações futuras podem ser implementadas de forma mais ampla e rápida.
Proteção do Modo de Gestão do Sistema (SMM)
O Modo de Gestão do Sistema (SMM) é um modo de CPU para fins especiais em microcontroladores x86 que processa a gestão de energia, a configuração de hardware, a monitorização térmica e qualquer outra coisa que o fabricante considere útil. Sempre que uma destas operações do sistema é pedida, é invocada uma interrupção não máscara (SMI) no runtime, que executa o código do SMM instalado pelo BIOS. O código SMM é executado no nível de privilégio mais elevado e é invisível para o SO, o que o torna um destino apelativo para atividades maliciosas. Mesmo que o Lançamento Seguro do System Guard seja utilizado para o início tardio, o código do SMM pode potencialmente aceder à memória do hipervisor e alterar o hipervisor.
Para se defender desta situação, são utilizadas duas técnicas:
- Proteção de paginação para impedir o acesso inadequado ao código e aos dados
- Atestado e supervisão de hardware do SMM
A proteção de paginação pode ser implementada para bloquear determinadas tabelas de código para serem só de leitura para impedir a adulteração. Isto impede o acesso a qualquer memória que não tenha sido atribuída.
Uma funcionalidade de processador imposta por hardware conhecida como um processador SMI supervisor pode monitorizar o SMM e certificar-se de que não acede a nenhuma parte do espaço de endereços que não deveria.
A proteção do SMM baseia-se na tecnologia de Lançamento Seguro e requer que funcione. No futuro, o Windows 10 também medirá o comportamento deste Processador de SMI e atestará que nenhuma memória pertencente ao SO foi adulterada.
Validar a integridade da plataforma depois de o Windows estar em execução (tempo de execução)
Embora o System Guard forneça proteção avançada que ajudará a proteger e manter a integridade da plataforma durante o arranque e no tempo de execução, a realidade é que temos de aplicar uma mentalidade de "assumir violação" até às nossas tecnologias de segurança mais sofisticadas. Podemos confiar que as tecnologias estão a fazer o seu trabalho com êxito, mas também precisamos da capacidade de verificar se foram bem sucedidas na concretização dos seus objectivos. Para a integridade da plataforma, não podemos confiar apenas na plataforma, que pode potencialmente ficar comprometida, para atestar automaticamente o estado de segurança. Assim, o System Guard inclui uma série de tecnologias que permitem a análise remota da integridade do dispositivo.
À medida que o Windows arranca, uma série de medições de integridade são feitas pelo System Guard através do Trusted Platform Module 2.0 (TPM 2.0) do dispositivo. A Iniciação Segura do System Guard não suporta versões anteriores do TPM, como o TPM 1.2. Este processo e os dados estão isolados de hardware do Windows para ajudar a garantir que os dados de medição não estão sujeitos ao tipo de adulteração que pode ocorrer se a plataforma tiver sido comprometida. A partir daqui, as medidas podem ser utilizadas para determinar a integridade do firmware do dispositivo, do estado de configuração do hardware e dos componentes relacionados com o arranque do Windows, para citar alguns.
Depois de o sistema arrancar, o System Guard assina e sela estas medidas com o TPM. A pedido, um sistema de gestão como o Intune ou o Microsoft Configuration Manager pode adquiri-los para análise remota. Se o System Guard indicar que o dispositivo não tem integridade, o sistema de gestão pode efetuar uma série de ações, como negar o acesso do dispositivo aos recursos.
Edição do Windows e requisitos de licenciamento
A tabela seguinte lista as edições do Windows que suportam o System Guard:
| Windows Pro | Windows Enterprise | Windows Pro Education/SE | Windows Education |
|---|---|---|---|
| Sim | Sim | Sim | Sim |
Os direitos de licença do System Guard são concedidos pelas seguintes licenças:
| Windows Pro/Pro Education/SE | Windows Enterprise E3 | Windows Enterprise E5 | Windows Education A3 | Windows Education A5 |
|---|---|---|---|---|
| Sim | Sim | Sim | Sim | Sim |
Para obter mais informações sobre o licenciamento do Windows, consulte Visão geral do licenciamento do Windows.
Requisitos de sistema para o System Guard
Esta funcionalidade está disponível para os seguintes processadores:
- Processadores Intel® vPro™ a começar com Intel® Coffeelake, Whiskeylake ou silicone posterior
- Processadores AMD® a partir do Zen2 ou posterior
- Processadores Qualcomm® com chipsets SD850 ou posteriores
Requisitos para processadores Intel® vPro™ a partir do Intel® Coffeelake, Whiskeylake ou silicone posterior
| Nome | Descrição |
|---|---|
| CPU de 64 bits | É necessário um computador de 64 bits com um mínimo de quatro núcleos (processadores lógicos) para segurança baseada em hipervisor e virtualização (VBS). Para obter mais informações sobre o Hyper-V, consulte Hyper-V no Windows Server 2016 ou Introdução ao Hyper-V no Windows 10. Para obter mais informações sobre o hipervisor, veja Especificações do Hipervisor. |
| Trusted Platform Module (TPM) 2.0 | As plataformas têm de suportar um TPM 2.0 discreto. Os TPMs integrados/de firmware não são suportados, exceto chips Intel que suportam a Tecnologia de Confiança da Plataforma (PTT), que é um tipo de TPM de hardware integrado que cumpre a especificação TPM 2.0. |
| Proteção do Windows DMA | As plataformas têm de cumprir a Especificação de Proteção do Windows DMA (todas as portas DMA externas têm de estar desativadas por predefinição até que o SO as aprovisione explicitamente). |
| Memórias intermédias de comunicação do SMM | Todas as memórias intermédias de comunicação do SMM têm de ser implementadas nos tipos de memória EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType. |
| Tabelas de Páginas do SMM | NÃO pode conter quaisquer mapeamentos para EfiConventionalMemory (por exemplo, sem memória do SO/VMM). NÃO pode conter quaisquer mapeamentos para secções de código no EfiRuntimeServicesCode. NÃO pode ter permissões de execução e escrita para a mesma página Só tem de permitir que as páginas TSEG possam ser marcadas como executáveis e o mapa de memória tem de reportar TSEG EfiReservedMemoryType. O processador SMI do BIOS tem de ser implementado de modo a que as tabelas de páginas do SMM estejam bloqueadas em todas as entradas do SMM. |
| Modo de Espera Moderno/Ligado | As plataformas têm de suportar o Modo de Espera Moderno/Ligado. |
| Índice do TPM AUX | A plataforma tem de configurar um índice AUX com índice, atributos e política que corresponda exatamente ao índice AUX especificado no DG TXT com um tamanho de dados de exatamente 104 bytes (para dados SHA256 AUX). (NameAlg = SHA256) As plataformas têm de configurar um índice PS (Fornecedor de Plataforma) com:
|
| Política de AUX | A política AUX necessária tem de ser a seguinte:
|
| Índice NV do TPM | O firmware da plataforma tem de configurar um índice NV do TPM para utilização pelo SO com:
|
| Firmware da plataforma | O firmware da plataforma tem de ter todo o código necessário para executar um lançamento seguro da Tecnologia de Execução Fidedigna intel®:
|
| Atualização de firmware da plataforma | É recomendado atualizar o firmware do sistema através de UpdateCapsule no Windows Update. |
Requisitos para processadores AMD® a partir do Zen2 ou posterior
| Nome | Descrição |
|---|---|
| CPU de 64 bits | É necessário um computador de 64 bits com um mínimo de quatro núcleos (processadores lógicos) para segurança baseada em hipervisor e virtualização (VBS). Para obter mais informações sobre o Hyper-V, consulte Hyper-V no Windows Server 2016 ou Introdução ao Hyper-V no Windows 10. Para obter mais informações sobre o hipervisor, veja Especificações do Hipervisor. |
| Trusted Platform Module (TPM) 2.0 | As plataformas têm de suportar um TPM 2.0 discreto ou o TPM do Microsoft Pluton. |
| Proteção do Windows DMA | As plataformas têm de cumprir a Especificação de Proteção do Windows DMA (todas as portas DMA externas têm de estar desativadas por predefinição até que o SO as aprovisione explicitamente). |
| Memórias intermédias de comunicação do SMM | Todas as memórias intermédias de comunicação do SMM têm de ser implementadas nos tipos de memória EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType. |
| Tabelas de Páginas do SMM | NÃO pode conter quaisquer mapeamentos para EfiConventionalMemory (por exemplo, sem memória do SO/VMM). NÃO pode conter quaisquer mapeamentos para secções de código no EfiRuntimeServicesCode. NÃO pode ter permissões de execução e escrita para a mesma página O processador SMI do BIOS tem de ser implementado de modo a que as tabelas de páginas do SMM estejam bloqueadas em todas as entradas do SMM. |
| Modo de Espera Moderno/Ligado | As plataformas têm de suportar o Modo de Espera Moderno/Ligado. |
| Índice NV do TPM | O firmware da plataforma tem de configurar um índice NV do TPM para utilização pelo SO com:
|
| Firmware da plataforma | O firmware da plataforma tem de ter todo o código necessário para executar a Iniciação Segura:
A plataforma tem de ter a proteção Anti-Reversão de Firmware do Processador Seguro AMD® ativada A plataforma tem de ter o AmD® Memory Guard ativado. |
| Atualização de firmware da plataforma | É recomendado atualizar o firmware do sistema através de UpdateCapsule no Windows Update. |
Requisitos para processadores Qualcomm® com chipsets SD850 ou posteriores
| Nome | Descrição |
|---|---|
| Monitorizar Comunicação do Modo | Todas as memórias intermédias de comunicação do Modo de Monitorização têm de ser implementadas em EfiRuntimeServicesData (recomendado), secções de dados de EfiRuntimeServicesCode, conforme descrito pela Tabela de Atributos de Memória, EfiACPIMemoryNVS ou tipos de memória EfiReservedMemoryType |
| Monitorizar Tabelas de Páginas do Modo de Monitorização | Todas as tabelas de páginas do Modo de Monitorização têm de:
|
| Modo de Espera Moderno/Ligado | As plataformas têm de suportar o Modo de Espera Moderno/Ligado. |
| Firmware da plataforma | O firmware da plataforma tem de ter todo o código necessário para iniciar. |
| Atualização de firmware da plataforma | É recomendado atualizar o firmware do sistema através de UpdateCapsule no Windows Update. |