UEFI e Boot Seguro - Conceitos básicos

Esse artigo discute os conceitos básicos da especificação UEFI e tenta esclarer o que é "Boot Seguro".

[ Hits: 37.004 ]

Por: Perfil removido em 18/03/2013


Boot Seguro



Na versão UEFI 2.2, foi adicionado o serviço Boot Seguro.

Sua função é evitar que drivers e loaders não autorizados, sejam executados em tempo de boot. Isso evita falhas de segurança exploradas por malwares do tipo bootkit.

Essas falhas são difíceis de detectar, já que ocorrem em ambiente pré-O.S. O boot seguro trabalha em três modos:
  1. Quando é ativado o boot seguro, entra em modo "SETUP", isso permite que uma chave pública de infraestrutura (PKI), conhecida como chave PK (Platform Key) seja gravada no firmware.
  2. Uma vez que a chave PK é gravada, o boot seguro entra em modo "USER". Neste modo, somente drivers e loaders assinados por chaves KEK (Key Exchange Key) podem ser carregados.
  3. O boot seguro também pode ser colocado em modo "CUSTOM", onde chaves públicas adicionais são inseridas no sistema sem qualquer relação com a chave PK. Essas são as chaves MOK (Machine Owner Keys). Isso permite que usuários certifiquem seus próprios programas como seguros.

No momento, distribuições GNU/Linux sem uma chave Shim, não podem ser inicializadas em Boot Seguro. Segundo [6], as versões "x86_64" de algumas distribuições, estão preparadas para utilizar boot seguro com chaves Shim certificadas pelas chaves KEK da Microsoft:
  • Ubuntu 12.10 (64 bits)
  • Fedora 18 (64 bits)
  • Sabayon (daily/snapshot de 64 bits)
  • openSUSE (provável na versão 12 de 64 bits)

Observe a figura abaixo, que ilustra como as chaves (PK/KEK/MOK) são implementadas no GNU/Linux com suporte a Boot Seguro:
Linux: UEFI e Boot Seguro - Conceitos básicos
A chave PK (OEM) garante a integridade das bases de dados (DB e DBX) que mantém, respectivamente, as chaves KEK do "O.S. vendor" e as chaves revogadas.

Apenas uma única chave PK pode existir no firmware, e ela é um certificado do tipo X.509. Se essa chave PK for removida do firmware, imediatamente ele entra em modo "SETUP", o que significa que o Boot Seguro está desabilitado.

A chave KEK (O.S. vendor) garante a integridade da chave pública da distribuição GNU/Linux (chave Shim) certificando-a. Pode haver diversas chaves KEK, mas elas devem ter sido certificadas pela chave PK instalada.

As chaves KEK são certificados X.509 ou RSA 2048. No modo "USER", qualquer tentativa de escrita em uma variável UEFI segura é checada, a procura de um descritor assinado.

Em modo "USER", os binários UEFI são executados mediante condições de segurança baseadas nas chaves KEK ou em hashes. Os aplicativos UEFI só podem ser executados quando:
  • NÃO são assinados, mas TEM um hash SHA-256 presente em DB e NÃO tem uma assinatura presente em DBX;
  • SÃO assinados, TEM um hash sha-256 presente em DB e NÃO tem assinatura presente em DBX;
  • SÃO assinados por uma chave KEK mantida em DB e NÃO tem assinatura presente em DBX.

Pode haver um terceiro tipo de chave, chamada de MOK (Machine Owner Keys) essa é uma lista de chaves locais para o usuário autenticar seus próprios programas.

De acordo com a especificação UEFI, a chave PK funciona como uma CA (Autoridade Certificadora) inserida no firmware. Apenas essa chave permite a validação de um bootloader assinado, que valida um estágio 2 e um kernel, ambos assinados, que também usa módulos assinados.

Neste processo são utilizados dois bancos de dados, presentes na NVRAM (Non-Volatile Random Access Memory) do firmware e que garantem a integridade dos certificados armazenados localmente:
  1. DB :: Conhecido como banco de assinaturas, contém as chaves KEK de confiança do sistema utilizadas para executar aplicações ou drivers de hardware (EBC) no ambiente UEFI.
  2. DBX :: Conhecido como banco de assinaturas proibidas, é uma espécie de lista negra (blacklist) de assinaturas revogadas ou proibidas. Aplicações e drivers que têm assinaturas mantidas na lista DBX, tem sua execução NEGADA.

As chaves KEK mantém a integridade de DB e DBX. As chaves KEK somente são atualizadas se a cadeia de confiança for estabelecida com a chave PK. No momento, isso tem funcionado do seguinte modo:
  • Chave PK do fabricante OEM.
  • Chave KEK do O.S. vendor em DB. OEM pode manter sua chave KEK em DB, mas isso é opcional.

Canonical e Red Hat estão trabalhando juntos com a Microsoft para permitir o uso de GNU/Linux em computadores que utilizam hardware UEFI da classe 3.

O esquema atual, estabelece uma cadeia de confiança das chaves da seguinte maneira:
  • Microsoft certifica a "chave Shim" da Canonical/Red Hat com sua chave KEK, estabelecendo a confiança em um bootloader de estágio 1 assinado pela chave Shim. Isso é um serviço oferecido pela Microsoft por US$ 99 e disponível para qualquer um interessado em usá-lo;
  • O segundo estágio do bootloader (grub-efi-amd-signed), é assinado com uma chave da própria Canonical/Red Hat que é certificada contra a chave Shim certificada pela Microsoft;
  • O kernel assinado com a chave Shim da Canonical/Red Hat inicializa, e se houver suporte, passa o controle para um initrd, que busca por módulos assinados. O sistema é carregado com toda a cadeia de confiança estabelecida e garantido pela chave PK do OEM mantida no firmware, que atua como uma CA.
É possível substituir PK e KEK por certificados autoassinados pelo usuário. O processo é complexo e está fora do escopo desse material. Fazer isso, equivale a retomar o controle da máquina.

Classes de sistemas UEFI

O processo de adoção de UEFI foi gradual. A especificação vem sendo atualizada desde de 2000. O ano de 2013 foi um marco para sua total adoção.

Esse processo gradual, criou uma classificação para os sistemas de hardware de acordo com seu grau de compromisso com a especificação UEFI:
  • Classe 0 - Sistemas legados ou BIOS-MBR nativo.
  • Classe 1 - Sistemas UEFI do tipo CSM - Compatibility Support Module.
  • Classe 2 - Sistemas Switch - Alterna entre BIOS ou UEFI.
  • Classe 3 - Sistemas 100% compatíveis com a versão UEFI 2.3.1 ou maior onde, por padrão, o modo CSM é desabilitado e o serviço Boot Seguro é habilitado.

Em hardwares classe 3, somente loaders e drivers autenticados podem ser executados. Máquinas certificadas pela Microsoft para Windows 8 devem ter esse comportamento.

Todavia, a especificação define que o boot seguro PODE ser desabilitado a qualquer momento pelo usuário. Nem todas implementações estão permitindo isso de modo fácil e seguro.

E há casos de "brick" de notebooks da Samsung, após desabilitado o UEFI com Boot Seguro com Windows 8 para instalação de distribuições GNU/Linux não certificadas.

Página anterior    

Páginas do artigo
   1. IBM - BIOS
   2. UEFI - BIOS
   3. Boot Seguro
Outros artigos deste autor

Outros recursos no OpenOffice: colunas, fundo e bordas

Usando classes em conexão e consultas à banco de dados em PHP

Sistemas de arquivos - Conceitos básicos

Instalação do Squid com autenticação NTLM e Kerberos

Mplayer e Mencoder com placa de TV

Leitura recomendada

Windows é mais fácil que Linux!? Tá louco!? Você sabe ler!?

Diferenças postas à mesa

HOWTO: Como se tornar moderador do Viva o Linux

Software Livre - GNU x LPG e o Governo x Economia (parte 1)

Diferentes distribuições GNU/Linux e diferentes usuários

  
Comentários
[1] Comentário enviado por lcavalheiro em 18/03/2013 - 10:51h

Excelente artigo, Kyetoy! Matando a questão a pau, e com estilo!

[2] Comentário enviado por mpsnet em 18/03/2013 - 10:59h

Alguém poderia me ajudar ?
Após habilitar o EFI boot secure no setup do meu notebook e instalar o windows 8, notei que após o termino da instalação não entrou no Windows8.
Apareceu uma tela como se fosse um boot loader, mas não existia opção alguma para escolher.
Então reiniciei a máquina e tentei entrar no setup novamente. Para minha surpresa após teclar <F2> para entrar no setup padrão (BIOS), não entra mais....vai direto para esta tal tela mencionada anteriormente.
Então removi todos os discos, achando que poderia ser algo ligado aos discos, mas mesmo assim nao consigo acessar mas o setup original da maquina.
A máquina continua "butando" um USB/DVD Live.... mas setup nada....

Como posso resolver isso ?

[3] Comentário enviado por julio_hoffimann em 18/03/2013 - 20:57h

Parabéns, artigo de excelente nível técnico.

Abs.

[4] Comentário enviado por konishi em 19/03/2013 - 11:13h

Excelente!

[5] Comentário enviado por striker_rafael em 25/03/2013 - 16:42h

Excelente artigo!! Pra acabar de vez com aquelas dúvidas sobre UEFI e Secure Boot.. Parabéns!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts