Introdução
Nesse artigo vamos começar a entender um conceito bastante importante relacionado aos PCs. O amado e odiado Secure Boot.
Vale ressaltar que o conceito denominado Secure Boot se aplica a diversos contextos. Nesse caso estaremos focando unicamente no Secure Boot no tocante aos sistemas operacionais de alto nível (ex.: windows / Linux) e bootloaders (Bootmgfw.efi, grub.efi, shim.efi, etc…).
Etapas de Inicialização de um PC x86/x64
Como visto no artigo anterior, o processo de inicialização de um PC possui várias etapas. As etapas relacionadas a BIOS são apresentadas na imagem a seguir:
Não entraremos a fundo em cada etapa mas será apresentada uma breve descrição de cada etapa e sua finalidade (em artigos futuros estudaremos cada etapa mais a fundo):
- SEC: Verificação inicial da segurança da plataforma. Também conhecido como RoT (Root-of-Trust). Não é aqui que o Secure Boot ocorre!!
- PEI: Inicialização dos componentes básicos da plataforma (CPU, RAM, Chipset)
- DXE: Inicialização de componentes mais elaborados (barramento PCIe, USB, placas RAID, etc.). Algumas validações do Secure Boot podem acontecer nessa etapa para verificação de driver de terceiros que estejam embarcados em memórias flash existentes em placas de periféricos, como controladoras RAID
- BDS: Etapa qual a unidade de inicialização e selecionada (aquela telinha que você escolhe se quer dar boot pelo SSD ou pelo pendrive)
- TSL: Momento no qual aplicações uefi (a.k.a boot loaders grub2.efi, win.efi, etc…) podem ser executadas. É aqui que as verificações mais comuns através do Secure Boot ocorrem!
- RT: Phase na qual o SO está rodando e alguns módulos da BIOS rodam em paralelo (conhecidos como SMM – System Management Mode)
- AL:Desalocação dos recursos para desligamento seguro da plataforma
Para simplificar o conceito, podemos dizer que as verificações feitas pelo secure boot ocorrem quando módulos .efi existentes em memórias diferentes da flash na qual a BIOS está localizada sejam carregados. Como é o caso dos option roms (placas PCIe) e boot loaders (grub2.efi do linux, bootmgfw.efi do windows, entre outros) os quais ficam salvos no HDD/SSD.
Evitando assim que versões não assinadas desses módulos sejam carregados durante o processo de inicialização, o que poderia colocar a plataforma como um todo em risco.
Ou seja, o Secure Boot não vai conseguir detectar se sua BIOS foi infectada. Essa verificação é feita por outros componentes da placa, como o embedded controller (EC), o Chipset dentre outros componentes e tecnologias criadas para esse fim (os quais serão detalhados em outros artigos).
O que faz o secureboot?
Agora que já entendemos por que o Secure Boot existe, é hora de entender como ele funciona.
Mas antes disso, outra informação importante para que tudo faça sentido.
As BIOS UEFI possuem algo parecido com as variáveis de ambiente dos sistemas operacionais, e são chamadas “UEFI Variables”. Não vamos nos aprofundar nesse tópico, pois o mesmo já precisaria de um artigo inteiro para correta explicação, mas para o momento vamos simplesmente entender que estas variáveis são utilizadas para troca de informações entre o SO e a BIOS, e também para salvar informações de forma persistente entre os boots da plataforma.
De volta ao Secure Boot.
Antes de mais nada precisamos entender que a BIOS possui alguns certificados que são adicionados durante o processo de compilação da mesma. Vale lembrar que as BIOS na atualidade são em sua maioria desenvolvidas utilizando linguagem c e algum código de referência como o edk2 [2].
Esses certificados ficam salvos diretamente na memória flash como parte da BIOS, e possuem diversas chaves públicas de diferentes fabricantes. Vale ressaltar que somente a parte pública dos certificados fica salva na BIOS. Já as chaves privadas fica em poder das empresas
Estes certificados podem ser acessados através de duas variáveis UEFI chamadas DB, e DBX. Em sistemas operacionais Linux as variáveis UEFI podem ser acessadas em /sys/firmware/efi/efivars
A variável DB possui diversos certificados ou hashes de módulos uefi permitidos (os quais a plataforma vai confiar) e a variável DBX possui certificados ou hashes revogados (ou seja que não podem mais ser confiados), conforme apresentado na imagem a seguir:
Agora temos o conhecimento necessário para entender como o Secure Boot funciona.
Quando um dado equipamento é ligado, assim que chega a hora de o bootloader ser executado, antes que isso ocorra, será feita uma validação da assinatura deste bootloader. E o mesmo será executado somente se as condições a seguir forem verdadeiras:
- Tiver sido assinado por uma chave privada a qual a parte pública está no DB
- O certificado utilizado para assinatura não estiver no DBX
- O Hash desse bootloader não estiver no DBX
O fluxo a seguir detalha essa verificação:
Com base nesse diagrama é possível entender que um dado bootloader só será executado, e consequentemente o SO o qual ele carregará, caso o Secure Boot tenha confirmado que o bootloader foi assinado por uma empresa a qual a plataforma confie (pois o certificado deve estar no DB) e que seu hash não tenha sido revogado (pois o hash não pode estar no DBX).
Conclusão
Como foi apresentado, a tecnologia Secure Boot existe para evitar que bootloaders e option roms maliciosos sejam carregados durante o processo de inicialização de um dado equipamento, neste caso notebooks/desktops.
Não sendo assim uma tecnologia criada com intuito de detectar invasões em tempo real ao nível de sistema operacional.
É importante lembrar que a segurança de um equipamento nunca deve se apoiar em um único elemento. Se um atacante porventura conseguir a senha de administrador do equipamento, será muito difícil garantir a segurança do mesmo.
A segurança é composta de diversas camadas e o monitoramento constante é primordial para detecção, mitigação e diminuição dos riscos, principalmente no caso de grandes infraestruturas e sistemas críticos.
Em futuros artigos explicarei mais sobre assuntos relacionados à arquitetura de PCs.









