04 - Secure Boot e Assinatura de Bootloaders

1. A Cadeia de Confiança Criptográfica (Root of Trust)

O advento da especificação UEFI trouxe a capacidade de execução nativa de binários ricos em formato PE32+ (Portable Executable) na fase inicial do boot. Com essa capacidade de execução irrestrita, abriu-se um vetor crítico de ataque: os Bootkits e Rootkits de firmware, malwares capazes de se alojar na Partição de Sistema EFI (ESP) e assumir o controle do hardware antes mesmo do sistema operacional ser carregado.

Para mitigar essa vulnerabilidade, a especificação UEFI introduziu o Secure Boot (Inicialização Segura). Sob o aspecto arquitetural, o Secure Boot não é uma tecnologia de criptografia de disco, mas sim um protocolo estrito de verificação de integridade baseado em Infraestrutura de Chaves Públicas (PKI) e assinaturas digitais X.509.

Quando o Secure Boot está ativado (status de Classe 3+), o firmware (fase BDS da UEFI) recusa-se sumariamente a executar a instrução LoadImage() de qualquer binário PE32+ (seja o grubx64.efi, systemd-bootx64.efi ou o próprio vmlinuz em caso de EFISTUB) a menos que seu código inteiro corresponda a um hash criptográfico seguro (geralmente SHA-256) que esteja assinado de forma assimétrica por uma chave pública previamente arquivada na matriz de confiança da placa-mãe.

2. A Matriz de Variáveis de Autenticação UEFI

O gerenciamento criptográfico do Secure Boot não é monolítico. Ele opera através de uma estrutura hierárquica estrita de quatro variáveis fundamentais, armazenadas de forma protegida na memória NVRAM da placa-mãe. Cada variável possui privilégios estritos sobre quem pode atualizá-la ou revogá-la:

1. PK (Platform Key): É a raiz absoluta de confiança. A PK é um par de chaves (pública/privada) gerada pelo OEM (Fabricante do Hardware) ou pelo proprietário do sistema. A chave pública reside na NVRAM. O detentor da chave privada correspondente possui autoridade suprema sobre a máquina. A utilidade primária da PK é permitir ou negar atualizações na camada KEK. Se a PK for excluída (apagada via setup do firmware), o Secure Boot entra em "Setup Mode", desativando a verificação de assinaturas e permitindo a injeção irrestrita de novas chaves.

2. KEK (Key Exchange Key): É a camada intermediária de confiança. Os detentores das chaves privadas correspondentes aos certificados contidos na variável KEK (frequentemente o OEM da placa-mãe e a Microsoft) têm permissão exclusiva para modificar as bases de dados de assinatura db e dbx.

3. db (Signature Database): É a lista de permissões (Whitelist). Esta variável contém um banco de dados de certificados X.509, chaves públicas e hashes de arquivos de bootloaders explicitamente autorizados a executar no sistema. Quando um executável EFI tenta ser carregado, sua assinatura digital (Authenticode) é validada matematicamente contra o conteúdo da variável db. Se o cálculo falhar ou a chave não constar no db, a inicialização é abortada com uma interrupção de segurança.

4. dbx (Forbidden Signature Database): É a lista de revogação (Blacklist). Possui prioridade arquitetural absoluta sobre a variável db. Se o hash exato de um bootloader comprometido (ou o certificado da entidade que o assinou) for incluído no dbx, o firmware negará a execução permanentemente, mesmo que outra assinatura válida coexista no db. Este mecanismo é crucial para neutralizar chaves vazadas de distribuidores Linux ou bootloaders com falhas de segurança conhecidas (como a vulnerabilidade "BootHole" do GRUB2).

3. O Gargalo de Autoria e o Carregador Intermediário (Shim)

O modelo de PKI do Secure Boot foi consolidado tendo a Microsoft como Autoridade Certificadora (CA) de fato do ecossistema de hardware x86_64. As placas-mãe vêm de fábrica contendo a chave "Microsoft Windows Production PCA" no seu db, permitindo que o bootmgfw.efi (Windows Boot Manager) inicie de forma nativa.

O ecossistema Linux apresenta uma bifurcação ideológica e estrutural. Compilar o GRUB2 ou o Kernel Linux assinando-o diretamente com uma chave da Microsoft não é viável (devido às restrições da GPLv3 do GRUB e às frequentes atualizações de kernel em dezenas de distribuições). Para evitar que o Linux se tornasse inelegível para boot em máquinas modernas, a comunidade, liderada por engenheiros da Red Hat, arquitetou o paradigma do Shim.

O shim (geralmente nomeado shimx64.efi) é um micro-bootloader de Estágio 0. Seu código-fonte é ínfimo, contendo pouco mais do que lógicas de verificação criptográfica.

A genialidade do shim reside em sua diplomacia criptográfica:

1. O binário do shim é submetido à Microsoft, que o assina utilizando o certificado específico "Microsoft Corporation UEFI Third Party Marketplace Root", o qual também vem embutido no db das placas-mãe.

2. Quando a placa-mãe inicializa, ela valida e executa o shimx64.efi sem ressalvas, pois sua assinatura emana da CA autorizada.

3. Uma vez na memória, o shim atua como uma sub-Autoridade Certificadora dinâmica em tempo de execução. Ele não possui drivers de leitura de tela, teclado ou discos; sua única função existencial é interceptar os hooks de execução da UEFI (substituindo o serviço padrão LoadImage).

4. O shim lê o próximo estágio do bootloader (o GRUB2 empacotado, nomeado grubx64.efi). O grubx64.efi do Ubuntu, Fedora ou Debian não é assinado pela Microsoft. Ele é assinado por chaves geradas internamente pelas próprias distribuições (ex: Canonical Ltd. Master Certificate).

5. O shim carrega essa chave pública de fornecedor de dentro de seu próprio binário (compilado estaticamente), calcula o hash do GRUB2, verifica a assinatura em memória e, sendo válida, repassa o controle para ele.

Esta arquitetura isola o escopo: apenas o shim diminuto precisa passar pelas auditorias drásticas da Microsoft, enquanto as distribuições mantêm controle total sobre as atualizações volumosas do GRUB2 e do Kernel usando suas chaves próprias.

4. Machine Owner Key (MOK) e o Enclave de Confiança do Usuário

A arquitetura do shim atende perfeitamente grandes distribuições (como RHEL, SLES, Ubuntu), cujas chaves públicas estão embutidas estaticamente no shimx64.efi. Contudo, o Linux é profundamente customizável. Um administrador pode desejar compilar seu próprio kernel nativo ou utilizar distribuições não-corporativas (como Arch Linux), cujos binários do systemd-boot ou EFISTUB não estarão assinados nem pela Microsoft nem por um shim padronizado.

Para devolver ao proprietário da máquina o controle sobre sua cadeia de inicialização sem a necessidade de manipular as perigosas variáveis PK ou KEK na NVRAM crua do firmware, o shim introduziu o ecossistema MOK (Machine Owner Key).

O MOK é um banco de dados de certificados complementar, armazenado em variáveis de NVRAM separadas (MokList, MokListX), manipuladas exclusivamente através de um aplicativo secundário associado ao shim chamado MokManager (mmx64.efi).

O Fluxo de Inscrição MOK (MOK Enrollment)

1. O administrador gera seu próprio par de chaves RSA-2048 em formato DER no espaço de usuário do Linux e assina seus próprios bootloaders ou kernels utilizando utilitários como o sbsign.

2. O certificado de chave pública resultante (.cer ou .der) não é carregado no kernel imediatamente. O utilitário mokutil é usado para agendar a requisição de injeção na NVRAM, configurando uma variável temporária MokNew.

3. Ao reiniciar o sistema, o shim identifica que a variável MokNew possui conteúdo. Antes de prosseguir para o bootloader principal, o shim desvia a execução forçadamente para o aplicativo MokManager.

4. Uma tela azul em modo texto é exibida pelo próprio firmware UEFI, exigindo intervenção física do operador (prova de presença) e uma senha de uso único definida na etapa 2. O MokManager então grava a chave pública do administrador na variável MokList.

5. Nos boots subsequentes, quando o shim tentar validar um kernel autocompilado, ele consultará a MokList do proprietário, além das chaves da distribuição, permitindo a execução de códigos assinados customizados mantendo a robustez do Secure Boot contra invasores virtuais.

5. Reflexos Operacionais: O Kernel Lockdown e Autenticação de Módulos

A ativação do Secure Boot impacta radicalmente não apenas os binários de estágio de carregamento, mas altera a própria forma como o núcleo do sistema operacional (Kernel Linux) governa os espaços de permissão, mesmo para o usuário root.

A premissa lógica é: de nada adianta garantir criptograficamente que um kernel puro foi carregado se, no milissegundo seguinte, um invasor em espaço de usuário (mesmo com UID 0) puder modificar as estruturas do kernel na memória usando recursos como /dev/mem ou inserindo drivers (módulos) maliciosos no ring 0.

Quando o Kernel detecta (via variáveis de estado UEFI exportadas pelo shim) que o Secure Boot está fisicamente ativo na placa-mãe, ele entra inexoravelmente em um estado de autodefesa compulsória conhecido como Kernel Lockdown (acionando o Linux Security Module - LSM lockdown).

Níveis Estritos de Lockdown

1. Lockdown Mode [integrity] (Integridade):

   • Assinatura Mandatória de Módulos: O uso clássico de insmod ou modprobe é sumariamente rejeitado se o módulo anexado (.ko, como drivers da NVIDIA, VirtualBox ou VMware) não possuir uma assinatura X.509 aderente atrelada ao arquivo que bata criptograficamente com uma chave pública registrada no MOK ou no chaveiro (keyring) construído (builtin) do próprio Kernel. Módulos obscuros e sem assinatura falham na montagem.

   • Kexec Bloqueado: A chamada de sistema kexec_load (que permite sobrepor o kernel atual por outro sem reiniciar o hardware) é bloqueada, a não ser que utilize o equivalente seguro kexec_file_load em que o arquivo também deve ser verificado antes da carga.

   • Blindagem de I/O Bruto: O acesso direto à memória física do sistema e do barramento PCIe via /dev/mem e /dev/kmem é desativado para leitura e gravação, blindando os buffers. A porta ioperm/iopl na arquitetura x86 e a injeção via barramento MSR (Model-Specific Registers) sofrem bypass negado.

2. Lockdown Mode [confidentiality] (Confidencialidade): (Ainda mais severo, frequentemente ativado em arquiteturas corporativas rigorosas).

   • Aplica todas as regras do nível integrity.

   • Bloqueia a leitura de chaves extraíveis via anel de acesso ao chaveiro do kernel (keyctl).

   • Desativa a interface de despejo de estado no espaço de kernel kcore, o comando perf não extrai dados profundos, e ferramentas como o BPF (Berkeley Packet Filter) de monitoramento que analisam o interior do kernel passam a sofrer restrições de leitura na extração de traces, assegurando que malwares não consigam roubar chaves de descriptografia de discos hospedadas passivamente na memória RAM.