A coisa mais próxima da alternativa da UEFI é coreboot .
Pelo que eu sei, o UEFI e seu Secure Boot são profundamente problemáticos e certamente não são o caminho a seguir.
Veja: link
Também aqui diz:
In case of SecureBoot the UEFI system which needs to validate the signatures is not open source. And even if it would be open source this does not mean that systems come pre-installed with the key you used for signing.
Então estou perguntando se existe uma versão de código aberto do que o Secure Boot da UEFI pretende fazer?
A coisa mais próxima da alternativa da UEFI é coreboot .
Na verdade, a parte que verifica se as assinaturas do Secure Boot estão abertas. Faz parte do TianoCore da Intel. O problema é que, quando você compra hardware pronto para uso, não há como verificar o que o fornecedor de hardware realmente coloca nele. Mas esse é um problema geral com o firmware do PC, não com o Boot Seguro como tal.
O lado do sistema dos próprios sistemas operacionais de Inicialização Segura em Código Aberto - por exemplo, Linux ou FreeBSD - também é totalmente Open Source.
O Secure Boot tem seus problemas - o esquema de assinatura é horrível - mas "falta de abertura" não é um deles.
Esta não é realmente uma alternativa direta e pode não ser exatamente o que você está procurando, mas uma solução semelhante que requer um TPM (Trusted Platform Module) é chamada de "Inicialização Confiável" ou tboot. Ela difere de algumas maneiras principais, mas seu objetivo final é o mesmo - estabelecer um nível de confiança na cadeia de inicialização e no estado do sistema.
O próprio Tboot é, na verdade, uma implementação de código aberto de um conceito chamado MLE ou Measured Launch Environment. Em suma, é um blob de código binário que executa e utiliza o Intel TXT para colocar a máquina em um estado privilegiado e confiável, onde pode fazer medições (hashes SHA-1 no TPM 1.2) do sistema operacional e componentes relacionados, e empurre-os para o TPM para serem armazenados com segurança. Por exemplo, no Linux, o tboot pode ser configurado para ser executado imediatamente antes do carregamento do kernel e irá gerar hashes do binário do kernel, parâmetros do kernel e imagem initramfs e enviá-los para o TPM.
Além disso, um TPM e placa-mãe / BIOS compatíveis permitem que sejam tomadas também medidas de vários componentes do sistema muito antes no processo de inicialização, como a própria imagem do BIOS, configurações personalizadas do BIOS, firmware da placa PCI (GPU, NIC e mais), o bootloader (grub, por exemplo) e muito mais. Você pode estar se perguntando o que valem essas medições? Bem, não muito por si mesmos. Em vez disso, o TPM pode ser usado para fazer várias coisas se e somente se essas medidas tiverem um valor específico, como ler / gravar em TPM NVRAM ou descriptografar uma chave, somente o TPM pode descriptografar. Essas medições também podem ser transmitidas com segurança (e anonimamente, se desejado) a outra parte, para que a parte possa estabelecer confiança remotamente. Posteriormente, um sistema pode ser projetado para inicializar ou executar apenas alguns softwares se o TPM tiver algumas medições específicas em seus PCRs, o que significa que inicializou um conjunto específico de software - isto é, fornece integridade.
Fundamentalmente, o TPM e o tboot combinados fornecem um amplo espectro de cobertura do sistema e pelo menos no papel do que eu entendo pode ser estendido para medir / hash virtualmente qualquer coisa usando uma API para enviar hashes ao TPM para armazenamento. Uma coisa importante a notar é que os hashes não são simplesmente carregados diretamente no TPM. Em vez disso, quando um hash deve ser armazenado em um registro interno no TPM (PCR ou Platform Configuration Register), ele é concatenado com o valor anterior do registrador, e o blob é fragmentado e o resultado armazenado no registrador. O resultado é que cada registrador acumula estado e qualquer diferença ao longo do caminho faz com que o valor final seja alterado. Isso é chamado de tpm 'estender'.
Fundamentalmente, acho que o TPM e o tboot oferecem muito mais capacidade do que a inicialização segura. O TPM é uma espécie de coprocessador criptográfico de uso geral que pode ser usado para armazenamento seguro, RNG, relatório de estado do sistema para outros hosts (atestado) e muito mais.
Ao contrário do Secure Boot, que utiliza assinaturas e interrompe o processo de inicialização se uma assinatura não fizer check-out, o TPM / tboot não usa assinaturas e não interrompe diretamente a sequência de inicialização. Em vez disso, um sistema precisa ser projetado para falhar na inicialização, exigindo que o TPM execute alguma ação, o que só fará se o sistema estiver em algum estado definido, se desejado.
Quanto à sua preocupação com o bit de código aberto e a transparência de tudo, até mesmo o tboot / TPM investiga uma camada de confiança implícita e, na verdade, é um salto de fé inevitável em minha mente, a menos que literalmente todo software era de código aberto, e o hardware também e os esquemas de hardware eram compreendidos. No caso do tboot e do TPM, essa confiança implícita vai até o chipset e o próprio processador. Supostamente, uma soma de verificação de chave pública é embutida no chipset usado pelo microcódigo do processador para iniciar a cadeia de confiança. Essa soma de verificação não é explicada completamente nos textos que possuo, mas o que é explicado é que uma assinatura é verificada pelo microcódigo do processador em um bloco de código residente na imagem do BIOS chamado ACM do BIOS para o SRTM ou SINIT ACM para DRTM. A fim de verificar uma assinatura, é claro, uma chave pública deve ser usada e meu palpite é que a chave pública é embutida no ACM por razões espaciais e verificada em relação ao checksum residente no hardware mencionado anteriormente.
Tags security uefi secure-boot