Sim, mas você deve ter suas chaves de inicialização segura em mãos. Primeiro, saiba que há pelo menos três formas que as chaves públicas de inicialização segura podem usar:
-
.cer
/.der
files - Esses arquivos são usados pela maioria das implementações do UEFI, bem como pela ferramenta MokManager que está emparelhada com o Shim. -
.crt
- Esses arquivos são usados nativamente pela maioria das ferramentas de segurança do Linux, comosbsigntool
esbverify
. -
.esl
- Esses arquivos combinam várias chaves em um arquivo. (Os outros arquivos contêm uma única chave.) Se você usar uma interface de usuário de firmware ou KeyTool para salvar suas chaves, os arquivos resultantes estarão nesse formato.
Se você instalou sua própria Chave de Proprietário de Máquina (MOK) usando o MokManager, você deve ter o arquivo em .cer
/ .der
form. Se você quiser testar se o binário funcionará quando iniciado com outra chave (como as chaves usadas para assinar a versão do GRUB do Ubuntu ou do Fedora), você terá que obtê-lo. Por conveniência, colecionei vários com rEFInd; você pode baixá-los parceladamente aqui. Se você tiver assumiu o controle total do Secure Boot no seu sistema, você também deve ter as chaves que criou.
Para verificar um binário, você deve ter uma chave em .crt
form. Se você tiver uma chave no formato .der
ou .cer
, poderá convertê-la:
openssl x509 -in mykey.cer -inform der -out mykey.crt
Em seguida, você pode verificar se o binário está corretamente assinado:
sbverify --cert mykey.crt binary.efi
O resultado deve ser uma mensagem com a leitura Signature verification OK
ou Signature verification failed
.
Observe que alguns UEFIs não iniciam nem mesmo binários assinados adequadamente. Isso parece ser aleatório; O binário A será lançado OK, enquanto o Binário B, assinado com a mesma chave, falhará. Acredito que isso seja um bug nos UEFIs afetados, mas não o investiguei em detalhes. AFAIK, isso não afeta os binários verificados via Shim, mas pode afetar o próprio Shim ou os binários lançados sem a ajuda do Shim.