System Guard: como uma raiz de confiança baseada em hardware ajuda a proteger o Windows
Para proteger recursos críticos, como a pilha de autenticação do Windows, tokens de logon único, a pilha biométrica Windows Hello e o Módulo de Plataforma Confiável Virtual, o firmware e o hardware de um sistema devem ser confiáveis.
System Guard reorganiza os recursos existentes de integridade do sistema Windows sob um mesmo teto e configura o próximo conjunto de investimentos em segurança do Windows. Ele foi projetado para fazer essas garantias de segurança:
- Proteger e manter a integridade do sistema à medida que ele é iniciado
- Validar que a integridade do sistema foi realmente mantida por meio de atestado local e remoto
Mantendo a integridade do sistema à medida que ele começa
Raiz estática da confiança para medição (SRTM)
Com o Windows 7, um dos meios que os invasores usariam para persistir e evitar a detecção era instalar o que geralmente é chamado de bootkit ou rootkit no sistema. Esse software mal-intencionado começaria antes do Windows começar ou durante o processo de inicialização em si, permitindo que ele começasse com o nível mais alto de privilégio.
Com Windows 10 em execução em hardware moderno, uma raiz de confiança baseada em hardware ajuda a garantir que nenhum firmware ou software não autorizado (como um bootkit) possa começar antes do bootloader do Windows. Essa raiz de confiança baseada em hardware vem do recurso de Inicialização Segura do dispositivo, que faz parte da UEFI (Interface de Firmware Extensível Unificada). Essa técnica de medição dos componentes UEFI de inicialização inicial estática é chamada de Raiz Estática de Confiança para Medição (SRTM).
Como há milhares de fornecedores de computadores que produzem muitos modelos com diferentes versões do BIOS UEFI, torna-se um número incrivelmente grande de medidas SRTM após o inicialização. Existem duas técnicas para estabelecer confiança aqui— manter uma lista de medidas conhecidas de SRTM 'ruins' (também conhecidas como blocklist) ou uma lista de medidas conhecidas de SRTM 'boas' (também conhecidas como lista de permissões).
Cada opção tem uma desvantagem:
- Uma lista de medidas conhecidas de SRTM 'ruins' permite que um hacker altere apenas 1 bit em um componente para criar um hash SRTM totalmente novo que precisa ser listado. Isso significa que o fluxo SRTM é inerentemente frágil - uma pequena alteração pode invalidar toda a cadeia de confiança.
- Uma lista de medidas conhecidas de SRTM 'boas' requer que cada nova medida de combinação BIOS/PC seja adicionada cuidadosamente, o que é lento. Além disso, uma correção de bug para o código UEFI pode levar muito tempo para projetar, compilar, reteste, validar e reimplantar.
Lançamento seguro– a raiz dinâmica da confiança para medição (DRTM)
System Guard Secure Launch, introduzido pela primeira vez no Windows 10 versão 1809, visa aliviar esses problemas aproveitando uma tecnologia conhecida como A Raiz Dinâmica da Confiança para Medição (DRTM). O DRTM permite que o sistema inicialize livremente em código não confiável inicialmente, mas pouco depois inicia o sistema em um estado confiável, assumindo o controle de todas as CPUs e forçando-as a seguir um caminho de código bem conhecido e medido. Isso tem o benefício de permitir que o código UEFI inicializado não confiável inicialize o sistema, mas, em seguida, ser capaz de fazer a transição com segurança para um estado confiável e medido.
O Secure Launch simplifica o gerenciamento de medidas srtm porque o código de inicialização agora não está relacionado a uma configuração de hardware específica. Isso significa que o número de medidas de código válidas é pequeno e as atualizações futuras podem ser implantadas de forma mais ampla e rápida.
Proteção do SMM (Modo de Gerenciamento do Sistema)
O SMM (Modo de Gerenciamento de Sistema) é um modo de CPU de uso especial em microcontroladores x86 que lida com gerenciamento de energia, configuração de hardware, monitoramento térmico e qualquer outra coisa que o fabricante considerar útil. Sempre que uma dessas operações do sistema é solicitada, uma SMI (interrupção não mascarada) é invocada no runtime, que executa o código SMM instalado pelo BIOS. O código SMM é executado no nível de privilégio mais alto e é invisível para o sistema operacional, o que o torna um destino atraente para atividades mal-intencionadas. Mesmo que System Guard o Lançamento Seguro seja usado para o lançamento tardio, o código SMM pode potencialmente acessar a memória do hipervisor e alterar o hipervisor.
Para se defender disso, duas técnicas são usadas:
- Proteção contra paginação para impedir acesso inadequado a códigos e dados
- Supervisão e atestado de hardware do SMM
A proteção contra paginação pode ser implementada para bloquear determinadas tabelas de código a serem somente leitura para evitar adulteração. Isso impede o acesso a qualquer memória que não tenha sido atribuída.
Um recurso de processador imposto por hardware conhecido como manipulador de SMI de supervisor pode monitorar o SMM e garantir que ele não acesse nenhuma parte do espaço de endereço que ele não deveria.
A proteção SMM é criada sobre a tecnologia de Lançamento Seguro e exige que ela funcione. No futuro, Windows 10 também medirá o comportamento desse Manipulador de SMI e atestará que nenhuma memória de propriedade do sistema operacional foi adulterada.
Validando a integridade da plataforma após a execução do Windows (tempo de execução)
Embora System Guard forneça proteção avançada que ajudará a proteger e manter a integridade da plataforma durante a inicialização e em tempo de execução, a realidade é que devemos aplicar uma mentalidade de "assumir violação" até mesmo às nossas tecnologias de segurança mais sofisticadas. Podemos confiar que as tecnologias estão fazendo seu trabalho com êxito, mas também precisamos da capacidade de verificar se elas foram bem-sucedidas em alcançar seus objetivos. Para integridade da plataforma, não podemos confiar apenas na plataforma, que potencialmente pode ser comprometida, para auto-atestar seu estado de segurança. Portanto, System Guard inclui uma série de tecnologias que permitem a análise remota da integridade do dispositivo.
Conforme o Windows inicializa, uma série de medidas de integridade são tomadas por System Guard usando o Módulo de Plataforma Confiável 2.0 do dispositivo (TPM 2.0). System Guard o Secure Launch não dá suporte a versões anteriores do TPM, como o TPM 1.2. Esse processo e os dados estão isolados de hardware longe do Windows para ajudar a garantir que os dados de medição não estejam sujeitos ao tipo de adulteração que poderia acontecer se a plataforma fosse comprometida. A partir daqui, as medidas podem ser usadas para determinar a integridade do firmware do dispositivo, do estado de configuração de hardware e dos componentes relacionados à inicialização do Windows, para citar alguns.
Depois que o sistema inicializa, System Guard assina e sela essas medidas usando o TPM. Após solicitação, um sistema de gerenciamento como Intune ou Microsoft Configuration Manager pode adquiri-los para análise remota. Se System Guard indicar que o dispositivo não tem integridade, o sistema de gerenciamento poderá executar uma série de ações, como negar o acesso do dispositivo aos recursos.
Edição do Windows e requisitos de licenciamento
A tabela a seguir lista as edições do Windows que dão suporte a System Guard:
| Windows Pro | Windows Enterprise | Windows Pro Education/SE | Windows Education |
|---|---|---|---|
| Sim | Sim | Sim | Sim |
System Guard direitos de licença 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 do sistema para System Guard
Esse recurso está disponível para os seguintes processadores:
- Processadores intel® vPro™ começando com Intel® Coffeelake, Whiskylake ou silicone posterior
- Processadores AMD® começando com o silício Zen2 ou posterior
- Processadores Qualcomm® com chipsets SD850 ou posteriores
Requisitos para processadores Intel® vPro™ começando com Intel® Coffeelake, Whiskylake ou silicone posterior
| Nome | Descrição |
|---|---|
| CPU de 64 bits | Um computador de 64 bits com pelo menos quatro núcleos (processadores lógicos) é necessário para o hipervisor e a VBS (segurança baseada em virtualização). Para obter mais informações sobre o Hyper-V, consulte Hyper-V em Windows Server 2016 ou Introdução ao Hyper-V no Windows 10. Para obter mais informações sobre o hipervisor, consulte Especificações do Hipervisor. |
| Módulo de Plataforma Confiável (TPM) 2.0 | As plataformas devem dar suporte a um TPM 2.0 discreto. TPMs integrados/firmware não têm suporte, exceto chips Intel que dão suporte à PTT (Platform Trust Technology), que é um tipo de TPM de hardware integrado que atende à especificação TPM 2.0. |
| Proteção DMA do Windows | As plataformas devem atender à Especificação de Proteção contra DMA do Windows (todas as portas DMA externas devem estar desligadas por padrão até que o sistema operacional as acione explicitamente). |
| Buffers de comunicação do SMM | Todos os buffers de comunicação do SMM devem ser implementados em tipos de memória EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType. |
| Tabelas de página do SMM | NÃO deve conter mapeamentos no EfiConventionalMemory (por exemplo, sem memória de propriedade do SISTEMA OPERACIONAL/VMM). NÃO deve conter mapeamentos para seções de código no EfiRuntimeServicesCode. NÃO deve ter permissões de execução e gravação para a mesma página Deve permitir SOMENTE que as páginas TSEG possam ser marcadas como executáveis e o mapa de memória deve relatar TSEG EfiReservedMemoryType. O manipulador de SMI do BIOS deve ser implementado de modo que as tabelas de páginaS do SMM sejam bloqueadas em cada entrada do SMM. |
| Espera moderna/conectada | As plataformas devem dar suporte a Espera Moderna/Conectada. |
| Índice AUX do TPM | A plataforma deve 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 devem configurar um índice PS (Fornecedor de Plataforma) com:
|
| Política do AUX | A política de AUX necessária deve ser a seguinte:
|
| Índice TPM NV | O firmware de plataforma deve configurar um índice TPM NV para uso pelo sistema operacional com:
|
| Firmware de plataforma | O firmware de plataforma deve levar todo o código necessário para executar uma inicialização segura da Tecnologia de Execução Confiável da Intel®:
|
| Atualização de firmware da plataforma | É recomendável atualizar o firmware do sistema por meio do UpdateCapsule no Windows Update. |
Requisitos para processadores AMD® começando com o silício Zen2 ou posterior
| Nome | Descrição |
|---|---|
| CPU de 64 bits | Um computador de 64 bits com pelo menos quatro núcleos (processadores lógicos) é necessário para o hipervisor e a VBS (segurança baseada em virtualização). Para obter mais informações sobre o Hyper-V, consulte Hyper-V em Windows Server 2016 ou Introdução ao Hyper-V no Windows 10. Para obter mais informações sobre o hipervisor, consulte Especificações do Hipervisor. |
| Módulo de Plataforma Confiável (TPM) 2.0 | As plataformas devem dar suporte a um TPM 2.0 ou TPM do Microsoft Pluton discreto. |
| Proteção DMA do Windows | As plataformas devem atender à Especificação de Proteção contra DMA do Windows (todas as portas DMA externas devem estar desligadas por padrão até que o sistema operacional as acione explicitamente). |
| Buffers de comunicação do SMM | Todos os buffers de comunicação do SMM devem ser implementados em tipos de memória EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType. |
| Tabelas de página do SMM | NÃO deve conter mapeamentos no EfiConventionalMemory (por exemplo, sem memória de propriedade do SISTEMA OPERACIONAL/VMM). NÃO deve conter mapeamentos para seções de código no EfiRuntimeServicesCode. NÃO deve ter permissões de execução e gravação para a mesma página O manipulador de SMI do BIOS deve ser implementado de modo que as tabelas de páginaS do SMM sejam bloqueadas em cada entrada do SMM. |
| Espera moderna/conectada | As plataformas devem dar suporte a Espera Moderna/Conectada. |
| Índice TPM NV | O firmware de plataforma deve configurar um índice TPM NV para uso pelo sistema operacional com:
|
| Firmware de plataforma | O firmware de plataforma deve carregar todo o código necessário para executar o Lançamento Seguro:
A plataforma deve ter a proteção anti-reversão do Firmware do Processador Seguro AMD® habilitada A plataforma deve ter o AmD® Memory Guard habilitado. |
| Atualização de firmware da plataforma | É recomendável atualizar o firmware do sistema por meio do UpdateCapsule no Windows Update. |
Requisitos para processadores Qualcomm® com chipsets SD850 ou posteriores
| Nome | Descrição |
|---|---|
| Monitorar comunicação de modo | Todos os buffers de comunicação do Modo Monitor devem ser implementados em EfiRuntimeServicesData (recomendado), seções de dados de EfiRuntimeServicesCode conforme descrito pela Tabela de Atributos de Memória, EfiACPIMemoryNVS ou tipos de memória EfiReservedMemoryType |
| Monitor Mode Page Tables | Todas as tabelas de página modo monitor devem:
|
| Espera moderna/conectada | As plataformas devem dar suporte a Espera Moderna/Conectada. |
| Firmware de plataforma | O firmware de plataforma deve carregar todo o código necessário para iniciar. |
| Atualização de firmware da plataforma | É recomendável atualizar o firmware do sistema por meio do UpdateCapsule no Windows Update. |
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de