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: 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.