Zenilto Soluções em Tecnologia
Intel Boot Guard é uma tecnologia introduzida pela Intel na 4ª geração Intel Core (Haswell) para verificar o processo de inicialização. Isso é feito pela atualização da chave pública da assinatura do BIOS nos fusíveis programáveis em campo (FPFs), uma memória programável única dentro do Intel ME, durante o processo de fabricação; desta forma, ele possui a chave pública do BIOS e pode verificar a assinatura correta durante cada inicialização subseqüente. Obviamente, uma vez ativado pelo fabricante, o Intel Boot Guard não pode mais ser desativado.
Infelizmente para nós, o Intel Boot Guard não é compatível com o me_cleaner , pois a máquina não ligará se o Intel ME estiver desativado, mesmo que o BIOS não tenha sido modificado .
me_cleaner deve funcionar com o Intel Boot Guard quando executado com o -ssinalizador e pode funcionar sem sinalizadores ou com a -Sopção. A interação entre o Intel Boot Guard e o me_cleaner ainda não é totalmente compreendida, há um trabalho em andamento.
Agora a pergunta é: você tem o Intel Boot Guard no seu computador?
- Se você tiver uma CPU mais antiga que a 4ª geração (Haswell), não
- Se você não tiver um computador pré-montado, não , pois a CPU e o chipset devem estar fisicamente conectados durante o processo de fabricação para fundir a chave pública na CPU e habilitar o Intel Boot Guard
- Se o seu PC não tiver vPro (geralmente há um adesivo em algum lugar do gabinete), provavelmente não
Portanto, se você tiver um PC pré-montado, com o adesivo vPro e pelo menos Haswell (ou mais recente), poderá ter o Intel Boot Guard ativado.
Intel Boot Guard
Conforme definido pela Wikipedia: “Intel Boot Guard é um recurso do processador que impede que o computador execute imagens de firmware não lançadas pelo fabricante do sistema. Quando ativados, os processadores verificam uma assinatura contida na imagem do firmware antes de executá-la, usando o hash da metade pública da chave de assinatura, que é fundida no Platform Controller Hub (PCH) do sistema pelo fabricante do sistema (não pela Intel ). O Intel Boot Guard é um recurso opcional do processador, o que significa que não precisa ser ativado durante a fabricação do sistema. Como resultado, o Intel Boot Guard, quando ativado, impossibilita que os usuários finais instalem um firmware de substituição, como o Coreboot. ”
O Boot Guard tenta proteger o sistema antes do início do Secure Boot. O Boot Guard é um grande novo player na equação segurança versus controle do usuário. Para economizar palavras, vou apenas apontar para algumas outras postagens de blog sobre este tópico por outras pessoas:
http://patrick.georgi-clan.de/2015/02/17/intel-boot-guard/
https://hacked.com/quick-hack-bios-passwords-computer/
https://mjg59.dreamwidth. org/33981.html
https://news.ycombinator.com/item?id=9135767
http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from- modiying-your-pcs-firmware.html
A segurança deve ser abordada, mas o custo pode ser Computação de uso geral?
http://boingboing.net/2012/01/10/lockdown.html
http://readwrite.com/2012/01/13/the-four-horsemen-of-the-gener
https://github.com/ jwise/28c3-doctorow/blob/master/transcript.md
Espero que a Intel — ou outros fornecedores de chips — possam ajudar ambos os públicos, não apenas os fornecedores corporativos que desejam usar a instalação OEM do Windows e nunca alterar seus sistemas. O usuário presente localmente deve ser capaz de substituir recursos como esse e instalar o que deseja, no firmware, pré-SO e software no nível do SO. Alguns sistemas podem precisar ser invioláveis para usuários locais, mas isso é apenas para funcionários de bancos corporativos, não para cidadãos. Intel: dê-nos mais controle sobre os produtos que compramos.
O problema que a Intel tenta resolver…
Intel Boot Guard é o mais recente esforço de uma longa série da Intel e outros para permitir que os computadores forneçam algumas informações confiáveis sobre o estado em que um computador está. Eles estão trabalhando nisso desde pelo menos 2003, com projetos e grupos comerciais chamados Palladium, TCPA, e agora TCG , e alguns deles já enfrentaram escrutínio no passado porque a liberdade de computação foi considerada sob ataque (medos realistas, mas com algumas hipérboles desnecessárias).
O esquema que a Intel e outros desses grupos comerciais desenvolveram requer um processador separado no sistema que rastreia o estado do sistema e é capaz de manter segredos da CPU até provar que o sistema está em um estado seguro. Esse processador é chamado de TPM (abreviação de Trusted Platform Module).
Desde o início, o TPM foi projetado como um componente passivo: alguma outra parte do sistema precisa atualizar a visão da plataforma do TPM, o TPM não é capaz de bloquear nenhum componente do sistema, exceto o acesso à sua própria memória.
O TPM consiste em alguma forma de rastrear o estado do sistema, alguma memória não volátil (para os “segredos”), uma forma de vincular segredos aos estados do sistema e também fornece algumas operações criptográficas – entre elas: criar pares de chaves RSA , e trabalhar com eles.
Um grande problema de design é onde a confiança está enraizada: a primeira verificação de assinaturas ocorre por código na CPU, portanto, se você for capaz de interceptá-lo e substituí-lo pelo seu, é trivial emular um sistema inicializado “corretamente” ( apenas enviando os valores corretos para o TPM). Movendo esse problema cada vez mais cedo no processo de inicialização, a última fronteira é eventualmente o bootblock, a parte do firmware que contém as primeiras instruções executadas pela CPU: Como vem primeiro, verifica a parte que vem depois, que novamente verifica seu sucessor, e assim por diante. Análogo a uma prova por indução, todo o estado do sistema permanece bem conhecido desde que o primeiro componente teste o próximo componente, e todos os outros componentes fazem o mesmo. Mas se você não pode confiar no bootblock para enviar um estado verdadeiro para o TPM,
Enter Boot Guard: permite que o fornecedor de hardware bloqueie o bloco de inicialização com uma chave que eles escrevem na CPU para que a máquina só inicie se o código corresponder a essa chave.
… e seus próprios problemas
O principal problema dessa abordagem é que essa chave não pode ser reescrita depois de inserida. Portanto, quando o fornecedor de hardware (digamos, Lenovo) define essa chave, eles são os únicos que podem fornecer firmware para a máquina, mesmo que o proprietário da máquina quer outra coisa.
Em combinação com a complexidade do UEFI, que geralmente inclui uma pilha de rede (e, portanto, a capacidade de se comunicar com o mundo) e a capacidade de carregar e executar código (por exemplo, através da rede), algumas pessoas se sentem desconfortáveis com essa perspectiva.
Outros querem apenas a capacidade de substituir todo o código em um sistema, incluindo firmware, por uma questão de princípio – e como eles são donos de suas máquinas, acho muito difícil argumentar que essas pessoas não deveriam ser capazes de fazê-lo.
Há mais: Inicialização Verificada vs. Inicialização Medida
Mas esta não é toda a história do Boot Guard da Intel. A opção de instalar uma chave é o que a Intel chama de “inicialização verificada”. É descrito em algumas palavras curtas no resumo do produto para essas CPUs .
Esse documento também fala sobre outro modo, “Inicialização medida”. Nesse modo, o Boot Guard cria um hash sobre o bootblock e o envia para o TPM. O valor é armazenado em um dos registradores de abundância do TPM e, em particular, em um registrador que não é gravável por código em execução na CPU (existem alguns circuitos para garantir isso). Isso deve evitar ataques de repetição nos quais seria possível falsificar um determinado estado do Boot Guard se um invasor conseguir desabilitar o Boot Guard completamente.
Segurança amigável, desenvolvida pelo Boot Guard
Como o TPM é capaz de vincular os dados que armazena a esses registros, é possível verificar o estado do sistema em relação a uma chave armazenada no TPM que está vinculada a um estado válido conhecido:
Na fábrica, faça com que o TPM crie um par de chaves e associe-o ao bootblock instalado. Exporte a parte pública da chave (o TPM não abrirá mão da chave privada, portanto esta operação é segura).
Ao tentar afirmar se o sistema ainda está em bom estado, criptografe um valor aleatório (nonce) com a chave pública e envie-o ao sistema para teste. Se ele puder descriptografar o valor e enviá-lo de volta, o estado é conhecido (caso contrário, o TPM não usaria a chave correta) e está tudo bem.
O Windows pode usar isso para logins de domínio, para afirmar que o sistema não foi adulterado. Para usuários pessoais, a Conta / Loja / Atualização do Windows pode verificar se algo suspeito está acontecendo: você já precisa registrar a máquina na Microsoft ao usar o Windows, então por que não usá-la para algo amigável?
Ou vincule a chave de criptografia do disco a esse estado, para que os dados sejam legíveis apenas nesse computador com esse firmware. (Como a criptografia TPM é tão lenta, isso é um pouco mais complicado, mas conceitualmente é o que pode ser feito com ela)
Um usuário instalando seu próprio firmware (incluindo bootblock), perderá o acesso aos dados desse disco criptografado e a um Domínio que faça essa verificação. De uma perspectiva de segurança, ambos são desejáveis.
Mas eles podem usar o Boot Guard com seu próprio firmware e criptografar o disco com seu próprio segredo armazenado no TPM. Compare isso com o “Modo Verificado”, em que a substituição do firmware apenas transforma o computador em um tijolo bom, caro e morto.
Então, o que deu errado?
A questão não é que a Intel adicionou o Boot Guard à sua plataforma. É que a Intel fornece o modo de inicialização verificada. Se eles não tivessem feito isso, o esforço seria universalmente elogiado como uma tecnologia que melhora a segurança de seus usuários (e sem abrir buracos em sua estrutura de segurança como o Intel TXT fez ).
Mas como é, como afirma Matthew Garrett, “os fornecedores são forçados a escolher entre segurança e liberdade” . E esse é um exercício que a maioria dos fornecedores rotineiramente deixa de fazer corretamente.
Portanto, Intel, por favor – proteja os fornecedores de si mesmos e seus usuários dos fornecedores que conectam você com seus usuários e faça a coisa certa: descarte a inicialização verificada em chipsets futuros e desencoraje os fornecedores de usá-la agora.
