Acabei de terminar de configurar o secure boot em uma instalação do Arch. Ao contrário de outras distros, isso não está funcionando imediatamente. No entanto, o processo para criar suas próprias chaves e configurar a assinatura de cada atualização do kernel com elas automagicamente com a ajuda do sbctl e um hook pacman é relativamente simples.
No entanto, tenho um problema com essa abordagem: se eu tiver que manter minhas chaves na minha máquina e puder usá-las para assinar qualquer coisa com credenciais disponíveis para uma ferramenta que eu possa invocar no espaço do usuário... Como isso protege meu sistema?
Eu acharia muito mais conveniente e seguro se essas coisas já estivessem assinadas pelos mantenedores do Arch. Eu poderia então simplesmente adicionar a chave deles ao meu banco de dados de inicialização segura permitindo-a nas configurações do BIOS (ou banco de dados de shim assinado pela Microsoft como outras distros fazem, não me importo), uma vez. Mas não encontro nenhuma maneira de fazer isso. Por que todos os métodos de configuração que vejo online são tão complicados, quando essa solução parece tão óbvia e direta? Existe uma razão técnica, ideológica ou processual que eu esteja esquecendo?
Principalmente porque eles não têm atualmente infraestrutura adequada para armazenar e acessar uma chave de assinatura.
Diferentemente dessas outras distribuições, os pacotes Arch não são atualmente construídos em uma "build farm" central – a construção é feita manualmente, seja nas máquinas dos próprios desenvolvedores, ou descarregada para um servidor de construção comum via SSH. Os pacotes são então assinados usando a chave PGP do próprio desenvolvedor (e são entregues com essa assinatura, não assinados novamente).
(As imagens .iso são criadas de forma semelhante – observe como elas são assinadas pela chave PGP de uma pessoa e não por uma chave genérica "Debian buildd" e, quando essa pessoa não está disponível, às vezes todo o processo é atrasado.)
Até agora, isso atendeu às necessidades de assinatura de pacotes , porque o pacman tem um procedimento para revogação de chaves (chaves de desenvolvedor podem ser removidas, mantendo as mesmas CAs), bem como o modelo de confiança "M de N" nativo do PGP. Mas mapear esse modelo 1:1 para assinatura Secure Boot (assumindo que você só quer assinatura interna "Arch CA") não permitiria mais a revogação automática de certificados, pois as únicas atualizações 'dbx' que podem ser instaladas automaticamente são aquelas assinadas pela Microsoft (porque apenas a Microsoft está na sua lista 'KEK' e não há garantia de que o firmware da sua máquina permitirá que você registre uma KEK personalizada sem fazer totalmente sua própria assinatura Secure Boot a partir do PK de qualquer maneira).
Ele também não atende aos requisitos para Secure Boot "completo" (como outras distribuições fazem), pois o kernel precisa ser assinado por uma única chave que precisa ser incorporada em uma compilação assinada pela Microsoft do carregador 'Shim'. Para evitar o risco de vazamentos de chaves (e revogações/reconstruções/novas assinaturas do Shim), precisa haver algum tipo de infraestrutura de compilação central, que ainda está em processo de ser construída, e idealmente algum tipo de armazenamento de chaves seguro (TPM ou smartcard ou Nitrokey ou HSM similar) que impediria que a chave fosse extraída, o que requer acordos com a empresa de hospedagem (o Arch não tem seus próprios datacenters).
Essa é a mesma situação do Ubuntu, por exemplo, que também faz com que você armazene uma chave na sua máquina – a MOK (Machine Owner Key) – que pode ser usada para assinar qualquer módulo do kernel, tanto legítimo (pacotes DKMS) quanto não.
(Pelo que me lembro, ele também vem com um programa EFI que permite que alguém com acesso físico registre qualquer MOK que desejar, embora a maioria dos firmwares permita isso para inicialização segura de qualquer maneira.)
O Secure Boot por si só não protege muito seu sistema (se é que protege), em primeiro lugar – especialmente considerando que ele nem mesmo valida a imagem initrd (na verdade, a menos que o processo de assinatura local 'UKI' seja usado). 90% de sua utilidade vem de ser usado em combinação com a criptografia do disco do sistema (o que também significa que suas chaves de assinatura também serão criptografadas).
De fato, na maioria das distribuições Linux, a cadeia segura para no kernel e seus módulos e não faz nada para impedir a adulteração externa nem mesmo dos arquivos mais críticos do espaço do usuário — apenas o fato de o disco ser criptografado impede isso.
Para ser mais útil, o Secure Boot precisa ser combinado com o measured boot – por exemplo, onde as chaves de criptografia de disco são seladas usando o TPM e vinculadas ao estado específico do sistema. É isso que o BitLocker faz; seu desbloqueio automático não quer "Secure Boot pass", ele quer "Secure Boot diz que o kernel do Windows foi assinado por este certificado MS especificamente", ou seja, ele se torna um ingrediente na atestação geral do estado do sistema.
(Os sistemas DRM e anticheat também usam medições SB TPM sem criptografia de disco.)
Existem alguns paralelos entre o funcionamento do TLS e do SSH: primeiro, as chaves de criptografia são trocadas de forma não autenticada (DH), e somente depois a chave privada do servidor é usada para vincular o certificado e a transcrição do processo anterior; isso significa que o DH é uma parte crítica do protocolo, mas seria quase inútil por si só.