Habilitando a Inicialização Segura, o BitLocker e o Device Guard no Windows 10 IoT Core

Artigo
04/03/2023

O Windows 10 IoT Core inclui ofertas de recursos de segurança, como Inicialização Segura UEFI, Criptografia de Dispositivo BitLocker e Device Guard. Isso ajudará os construtores de dispositivos a criar dispositivos Windows IoT totalmente bloqueados que são resilientes a muitos tipos diferentes de ataques. Juntos, esses recursos fornecem a proteção ideal que garante que uma plataforma seja lançada de forma definida, bloqueando binários desconhecidos e protegendo os dados do usuário por meio do uso de criptografia de dispositivo.

Ordem de inicialização

É necessária uma compreensão da ordem de inicialização em um dispositivo Windows 10 IoT Core antes que possamos nos aprofundar nos componentes individuais que fornecem uma plataforma segura para o dispositivo IoT.

Há três áreas principais que ocorrem desde quando um dispositivo IoT é ligado, até o carregamento do kernel do sistema operacional e a execução do aplicativo instalado.

Inicialização segura da plataforma
Inicialização segura UEFI (Unified Extensible Firmware Interface)
Integridade do código do Windows

Boot Order

Informações adicionais sobre o processo de inicialização do Windows 10 podem ser encontradas aqui.

Bloqueando dispositivos IoT

Para bloquear um dispositivo Windows IoT, as seguintes considerações devem ser feitas.

Inicialização segura da plataforma

Quando o dispositivo é ligado pela primeira vez, a primeira etapa no processo de inicialização geral é carregar e executar carregadores de inicialização de firmware, que inicializam o hardware nos devies e fornecem funcionalidade de piscamento de emergência. O ambiente UEFI é então carregado e o controle é entregue.

Esses carregadores de inicialização de firmware são específicos do SoC, então você precisará trabalhar com o fabricante do dispositivo apropriado para que esses carregadores de inicialização sejam criados no dispositivo.

UEFI - Inicialização Segura

A Inicialização Segura UEFI é o primeiro ponto de imposição de política e está localizada na UEFI. Ele restringe o sistema para permitir apenas a execução de binários assinados por uma autoridade especificada, como drivers de firmware, ROMs de opção, drivers ou aplicativos UEFI e carregadores de inicialização UEFI. Esse recurso impede que códigos desconhecidos sejam executados na plataforma e enfraqueçam sua postura de segurança. A Inicialização Segura reduz o risco de ataques de malware pré-inicialização ao dispositivo, como rootkits.

Como OEM, você precisa armazenar os bancos de dados de Inicialização Segura UEFI no dispositivo IoT no momento da fabricação. Esses bancos de dados incluem o banco de dados de assinatura (db), o banco de dados de assinatura revogada (dbx) e o banco de dados de chave de registro de chave (KEK). Esses bancos de dados são armazenados na RAM NÃO VOLÁTIL (NV-RAM) do firmware do dispositivo.

Banco de dados de assinatura (db): lista os signatários ou hashes de imagem de carregadores do sistema operacional, aplicativos UEFI e drivers UEFI que podem ser carregados no dispositivo
Banco de Dados de Assinatura Revogado (dbx): lista os signatários ou hashes de imagem de carregadores do sistema operacional, aplicativos UEFI e drivers UEFI que não são mais confiáveis e NÃO têm permissão para serem carregados no dispositivo
Banco de dados de chaves de registro de chaves (KEK): contém uma lista de chaves de assinatura que podem ser usadas para atualizar os bancos de dados de assinatura e de assinatura revogada.

Depois que esses bancos de dados são criados e adicionados ao dispositivo, o OEM bloqueia a edição do firmware e gera uma PK (chave de assinatura de plataforma). Essa chave pode ser usada para assinar atualizações para o KEK ou para desabilitar a Inicialização Segura UEFI.

Aqui estão as etapas tomadas pelo UEFI Secure Boot:

Depois que o dispositivo é ligado, os bancos de dados de assinatura são verificados em relação à PK (chave de assinatura de plataforma).
Se o firmware não for confiável, o firmware UEFI iniciará a recuperação específica do OEM para restaurar o firmware confiável.
Se o Gerenciador de Inicialização do Windows não puder ser carregado, o firmware tentará inicializar uma cópia de backup do Gerenciador de Inicialização do Windows. Se isso também falhar, o firmware UEFI iniciará a correção específica do OEM.
O Gerenciador de Inicialização do Windows é executado e verifica a assinatura digital do Kernel do Windows. Se confiável, o Gerenciador de Inicialização do Windows passa o controle para o Kernel do Windows.

Detalhes adicionais sobre a Inicialização Segura, juntamente com orientações de criação e gerenciamento de chaves, estão disponíveis aqui.

Integridade do código do Windows

O Windows Code Integrity (WCI) melhora a segurança do sistema operacional validando a integridade de um driver ou aplicativo sempre que ele é carregado na memória. O CI contém dois componentes principais - Integridade do Código do Modo Kernel (KMCI) e Integridade do Código do Modo do Usuário (UMCI).

A CCI (Integridade de Código Configurável) é um recurso do Windows 10 que permite que os construtores de dispositivos bloqueiem um dispositivo e só permitam que ele execute e execute código assinado e confiável. Para fazer isso, os construtores de dispositivos podem criar uma política de integridade de código em um dispositivo 'dourado' (versão final de hardware e software) e, em seguida, proteger e aplicar essa política em todos os dispositivos no chão de fábrica.

Para saber mais sobre como implantar políticas de integridade de código, auditoria e aplicação, confira a documentação mais recente do technet aqui.

Aqui estão as etapas executadas pelo Windows Code Integrity:

O Kernel do Windows verificará todos os outros componentes em relação ao banco de dados de assinatura antes de carregar. Isso inclui drivers, arquivos de inicialização e ELAM (Early Launch Anti-Malware).
O Kernel do Windows carregará os componentes confiáveis no processo de inicialização e proibirá o carregamento dos componentes não confiáveis.
O sistema operacional Windows 10 IoT Core é carregado, juntamente com todos os aplicativos instalados.

Criptografia de dispositivo BitLocker

O Windows 10 IoT Core também implementa uma versão leve da Criptografia de Dispositivo BitLocker, protegendo dispositivos IoT contra ataques offline. Esse recurso tem uma forte dependência da presença de um TPM na plataforma, incluindo o protocolo pré-OS necessário no UEFI que realiza as medições necessárias. Essas medições pré-OS garantem que o sistema operacional tenha um registro definitivo de como o sistema operacional foi lançado; no entanto, não impõe quaisquer restrições de execução.

Dica

A funcionalidade BitLocker no Windows 10 IoT Core permite a criptografia automática do volume do sistema operacional baseado em NTFS enquanto vincula todos os volumes de dados NTFS disponíveis a ele. Para isso, é necessário garantir que o GUID do volume EFIESP esteja definido como C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Device Guard no Windows IoT Core

A maioria dos dispositivos IoT são criados como dispositivos de função fixa. Isso implica que os construtores de dispositivos sabem exatamente qual firmware, sistema operacional, drivers e aplicativos devem ser executados em um determinado dispositivo. Por sua vez, essas informações podem ser usadas para bloquear totalmente um dispositivo IoT, permitindo apenas a execução de código conhecido e confiável. O Device Guard no Windows 10 IoT Core pode ajudar a proteger dispositivos IoT, garantindo que códigos executáveis desconhecidos ou não confiáveis não possam ser executados em dispositivos bloqueados.

Segurança chave na mão no IoT Core

Para facilitar a habilitação fácil dos principais recursos de segurança em dispositivos IoT Core, a Microsoft está fornecendo um Pacote de Segurança Turnkey que permite que os construtores de dispositivos criem dispositivos IoT totalmente bloqueados. Este pacote ajudará com:

Provisionando chaves de Inicialização Segura e habilitando o recurso em plataformas IoT com suporte
Instalação e configuração de criptografia de dispositivo usando o BitLocker
Iniciando o bloqueio de dispositivo para permitir apenas a execução de aplicativos e drivers assinados

As etapas a seguir conduzirão o processo para criar uma imagem de bloqueio usando o Pacote de Segurança Turnkey:

Create lockdown image

Pré-requisitos

Um PC com o Windows 10 Enterprise (outras versões do Windows não são suportadas pelos scripts fornecidos)
SDK do Windows 10 - Necessário para geração de certificados
Windows 10 ADK - Necessário para a geração CAB
Plataforma de referência - hardware de lançamento com firmware de envio, sistema operacional, drivers e aplicativos será necessário para o bloqueio final

Desenvolvimento de dispositivos IoT

O Windows 10 IoT Core funciona com vários silícios que são utilizados em centenas de dispositivos. Dos dispositivos de desenvolvimento de IoT sugeridos, os seguintes fornecem funcionalidade TPM de firmware pronta para uso, juntamente com recursos de Inicialização Segura, Inicialização Medida, BitLocker e Device Guard:

Qualcomm DragonBoard 410c

Para habilitar a Inicialização Segura, pode ser necessário provisionar RPMB. Depois que o eMMC tiver sido piscado com o Windows 10 IoT Core (conforme instruções aqui, pressione [Power] + [Vol+] + [Vol-] simultaneamente no dispositivo ao ligar e selecione "Provisionar RPMB" no menu BDS. Por favor, note que este é um passo irreversível.
Intel MinnowBoardMax

Para o MinnowBoard Max da Intel, a versão do firmware deve ser 0.82 ou superior (obtenha o firmware mais recente). Para habilitar os recursos do TPM, ligue a placa com um monitor de teclado & conectado e pressione F2 para entrar na configuração UEFI. Vá para Gerenciador de dispositivos - Configuração do sistema - Configuração de segurança - PTT e defina-o>>> como< Habilitar.> Pressione F10 para salvar as alterações e prosseguir com uma reinicialização da plataforma.

Observação

O Raspberry Pi 2 nem 3 não suportam TPM e, portanto, não podemos configurar cenários de bloqueio.

Gerar pacotes de bloqueio

Siga as instruções nos dois links a seguir:

Testar pacotes de bloqueio

Você pode testar os pacotes de segurança gerados aqui <YOUR_IOT_ADD_ON_WORKSPACE>\Build<ARCH><OEM_NAME>. Segurança.* .cab> instalando-os manualmente em um dispositivo desbloqueado seguindo as seguintes etapas:

Pisce o dispositivo com a imagem desbloqueada (imagem usada para digitalização na etapa anterior).
Conectar-se ao dispositivo (usando SSH ou PowerShell )
Copie os seguintes arquivos .cab para o dispositivo em um diretório, por exemplo. c:\OemInstall
- OEM. Custom.Cmd.cab
- OEM. Security.BitLocker.cab
- OEM. Security.SecureBoot.cab
- OEM. Security.DeviceGuard.cab
Inicie o preparo dos pacotes gerados emitindo os seguintes comandos
```
applyupdate -stage c:\OemInstall\OEM.Custom.Cmd.cab
```
Se você estiver usando uma imagem personalizada, então você terá que ignorar este arquivo e editar manualmente o com o c:\windows\system32\oemcustomization.cmd conteúdo disponível no Output\OEMCustomization\OEMCustomization.cmd arquivo
```
applyupdate -stage c:\OemInstall\OEM.Security.BitLocker.cab
applyupdate -stage c:\OemInstall\OEM.Security.SecureBoot.cab
applyupdate -stage c:\OemInstall\OEM.Security.DeviceGuard.cab
```
Finalmente, confirme os pacotes via
```
applyupdate -commit
```
O dispositivo será reinicializado no sistema operacional de atualização (mostrando engrenagens) para instalar os pacotes e será reinicializado novamente no sistema operacional principal. Assim que o dispositivo for reinicializado novamente no MainOS, a Inicialização Segura será ativada e o SIPolicy deverá ser ativado.
Reinicialize o dispositivo novamente para ativar a criptografia BitLocker.
Testar os recursos de segurança
- SecureBoot: tente bcdedit /debug on , você receberá um erro informando que o valor está protegido pela política de inicialização segura
- BitLocker: Execute start /wait sectask.exe -waitencryptcomplete:1, se ERRORLEVEL for -2147023436 (ERROR_TIMEOUT), a criptografia não estará concluída. Ao executar sectask.exe de um arquivo .cmd, omita o start /waitarquivo .
- DeviceGuard: Execute qualquer binário não assinado ou um binário assinado com certificado que não esteja na lista SIPolicy e confirme se ele não é executado.

Gerar imagem de bloqueio

Depois de validar que os pacotes de bloqueio estão funcionando de acordo com as configurações definidas anteriormente, você pode incluir esses pacotes na imagem seguindo as etapas abaixo. Leia o guia de fabricação de IoT para obter instruções de criação de imagens personalizadas.

No diretório do espaço de trabalho, atualize os seguintes arquivos do diretório de saída gerado acima
- SecureBoot : Copy ..\Output\SecureBoot\*.bin ..\Workspace\Common\Packages\Security.SecureBoot
  - SetVariable_db.bin
  - SetVariable_kek.bin
  - SetVariable_pk.bin
- BitLocker : Copy ..\Output\Bitlocker\*.* ..\Workspace\Common\Packages\Security.Bitlocker
  - DETask.xml
  - Security.Bitlocker.wm.xml
  - setup.bitlocker.cmd
- DeviceGuard: Copy ..\Output\DeviceGuard\*.* ..\Workspace\Common\Packages\Security.DeviceGuard
  - SIPolicyOn.p7b
  - SIPolicyOff.p7b
Adicionar RetailOEMInput.xml e TestOEMInput.xml no diretório ProductName com ID de recurso do pacote de bloqueio
- <Feature>SEC_BITLOCKER</Feature>
- <Feature>SEC_SECUREBOOT</Feature>
- <Feature>SEC_DEVICEGUARD</Feature>
Gerar imagem novamente
- buildpkg all (isso gera novos pacotes de bloqueio com base nos arquivos de política acima)
- buildimage ProductName test(or)retail (isso gera novo Flash.ffu)
Atualize o dispositivo com este novo Flash.ffu e valide os recursos de segurança.

Consulte SecureSample como um exemplo de uma configuração de placa de dragão de bloqueio.

Desenvolvendo com a imposição de assinatura de código habilitada

Uma vez que os pacotes são gerados e o bloqueio é ativado, quaisquer binários introduzidos na imagem durante o desenvolvimento precisarão ser assinados adequadamente. Verifique se os binários do modo de usuário estão assinados com a chave *.\Keys\ **-UMCI.pfx. Para assinatura no modo kernel, como para drivers, você precisará especificar suas próprias chaves de assinatura e certificar-se de que elas também estejam incluídas no SIPolicy acima.

Desbloqueando unidades criptografadas

Durante o desenvolvimento e teste, ao tentar ler conteúdo de um dispositivo criptografado off-line (por exemplo, cartão SD para MinnowBoardMax ou eMMC da DragonBoard através do modo de armazenamento em massa USB), 'diskpart' pode ser usado para atribuir uma letra de unidade ao MainOS e ao volume de dados (vamos supor v: para MainOS e w: para Dados). Os volumes aparecerão bloqueados e precisarão ser desbloqueados manualmente. Isso pode ser feito em qualquer máquina que tenha o certificado OEM-DRA.pfx instalado (incluído no exemplo DeviceLockDown). Instale o PFX e execute os seguintes comandos a partir de um prompt CMD administrativo:

manage-bde -unlock v: -cert -cf OEM-DRA.cer
manage-bde -unlock w: -cert -cf OEM-DRA.cer

Se o conteúdo precisar ser acessado offline com frequência, o desbloqueio automático do BitLocker poderá ser configurado para os volumes após o desbloqueio inicial usando os seguintes comandos:

manage-bde -autounlock v: -enable
manage-bde -autounlock w: -enable

Desabilitando o BitLocker

Se houver a necessidade de desabilitar temporariamente o BitLocker, inicie uma sessão remota do PowerShell com seu dispositivo IoT e execute o seguinte comando: sectask.exe -disable.