De acordo com meu entendimento do Secure Boot, ele provavelmente funciona assim:
- O firmware UEFI tem uma chave fornecida pela Microsoft que é usada para verificação criptográfica de binários inicializáveis.
- Shim é um bootloader assinado, que é assinado por chaves da Microsoft. Como essas mesmas chaves estão presentes no UEFI, Shim é reconhecido como confiável.
- Agora, o Shim foi projetado com a capacidade de usar chaves personalizadas com ele.
- O Debian implementa suas chaves personalizadas no Shim, compilando o Shim com sua CA (arquivo .der).
- O Debian assina kernels com as chaves públicas confiáveis por esta CA. Essas chaves públicas também são disponibilizadas publicamente.
- Agora, quando o Shim é carregado pelo UEFI, ele carrega ainda mais os kernels assinados e, assim, o Secure Boot é implementado.
Minha pergunta é: por que o Debian tornou o arquivo .der e as chaves públicas diretamente disponíveis em seu código-fonte? Isso significa que se um invasor de alguma forma obtiver acesso root a um sistema, ele pode assinar kernels modificados com as chaves públicas do Debian, quebrando o modelo de segurança. Agora, obter acesso root é certamente difícil de um ataque executado remotamente, mas não é completamente impossível.
Ou meu entendimento do mecanismo Secure Boot está errado, ou há outro propósito pelo qual essas chaves são disponibilizadas publicamente. Por favor, corrija meu entendimento.
Você não pode assinar nada com uma chave pública que seria verificável com a mesma chave pública. Os algoritmos usados são todos assimétricos. Por isso é chamado de "chave pública": é por design seguro revelar ao público.
Em vez disso, uma chave diferente (a chave privada da qual a chave pública também foi derivada) precisa fazer a assinatura, que será então verificável com a chave pública (e, de fato, verificá-la requer ter a chave pública; sem ela, a assinatura não tem sentido).
O mesmo princípio se aplica à maioria dessas assinaturas digitais – incluindo as "outras" assinaturas e chaves que o Secure Boot usa, bem como certificados TLS, chaves de autenticação SSH e assim por diante. Em todos esses casos, ter a chave pública é necessário para que uma assinatura tenha algum valor, mas ao mesmo tempo não é suficiente para criar uma assinatura.
Dito isso, você está certo sobre o root ser capaz de assinar coisas, embora com uma chave completamente diferente – a "Chave do Proprietário da Máquina" (MOK) que Shim introduz no modelo Secure Boot, e cuja chave privada foi gerada localmente e armazenada na máquina. O propósito disso é permitir a construção local de drivers de kernel baseados em DKMS, e o modelo de segurança em geral não considera o root como parte do ataque
Provavelmente, o foco estava em ataques vindos de fora, e especificamente com o sistema de arquivos raiz (que armazena a chave privada MOK) sendo criptografado e inacessível sem a frase-senha e o SB impedindo adulterações no bootloader para registrar a frase-senha... Mas, na verdade, o foco provavelmente está apenas em tornar possível que o Linux inicialize em sistemas onde o SB está ativo por padrão, sem ter que pedir ao usuário para desativá-lo manualmente.