Os TPMs devem resolver um problema de ovo e galinha de onde armazenar chaves de criptografia de disco não criptografadas, de modo que alguém não possa simplesmente inserir outro disco rígido na máquina, inicializar um sistema operacional diferente e ler as chaves diretamente do disco / flash / BIOS / ...
Os AFAIK TPMs basicamente fazem isso verificando qual software inicializou e, se esse software não corresponder a um hash predefinido, ele permanecerá bloqueado e se recusará a fornecer as chaves de criptografia de disco.
Eu li vários artigos apontando para o fato de que systemd pode ajudar a incorporar minhas chaves LUKS em um TPM com systemd-cryptenroll . Mas eles falam apenas em incorporar a chave no TPM e não impedir que invasores leiam essas chaves.
Onde estou preso é descobrir como garantir que haja uma sólida cadeia de confiança do firmware do BIOS para o login, garantindo que, se o sistema operacional for adulterado, ele não inicialize ou o TPM se recuse a entregar a chave de criptografia.
Por exemplo, não há muito uso em criptografar meu disco rígido se alguém no terminal puder simplesmente pressionar Eno prompt do grub e inicializar o Linux init=/bin/bashpara obter um login root sem precisar de uma senha. A criptografia seria totalmente inútil nessa situação.
Estou preso em dois pontos bastante específicos:
- O que uma distribuição típica baseada em systemd (Debian ou Ubuntu) faz para bloquear o TPM em primeiro lugar. Quais arquivos isso protege contra adulteração?
- Que outras coisas na sequência de inicialização devo proteger contra adulteração?
- por exemplo: grub EFI binary, grub.cfg in EFI, grub passwordles editando entradas de inicialização, initramfs, ...
Isso está embutido no processo; é a
--tpm-pcrs=opção que você dá ao systemd-cryptenroll.O TPM mantém um "log de eventos" na memória de vários eventos fornecidos a ele pelo firmware do sistema, pelo bootloader e, ocasionalmente, pelo sistema operacional. Cada evento "mede" alguma parte do sistema – por exemplo, o firmware registrará um hash do executável grubx64.efi conforme ele é carregado; O GRUB registrará todos os comandos e (provavelmente?) registrará um hash da imagem do kernel que está sendo executada; o kernel registrará um hash do initrd e um hash da linha de comando – e cada evento "estende" uma cadeia de hash que também é armazenada na memória do TPM.
O destino de todas essas medições é um conjunto de PCRs, "registros de configuração de plataforma", cada um contendo um hash SHA. Cada evento estende um dos PCRs usando a fórmula:
para que o hash final no PCR autentique toda a cadeia de eventos para esse PCR, exatamente como um único hash de commit do Git autentica todo o histórico de commits que o antecederam. (Embora haja apenas um log de eventos, cada evento atualiza apenas um único PCR, portanto, cada um dos PCRs atua como uma cadeia de hash independente.)
Sozinhos, os PCRs não fazem absolutamente nada, mas a operação "seal" pode ser usada para especificar uma política que pode exigir que PCRs específicos tenham valores específicos; se a política não for atendida, o TPM se recusará a liberar os dados.
Portanto, sempre que
systemd-cryptenrollpedir ao TPM para selar (criptografar) a chave de volume LUKS, ele inclui uma política baseada no que--tpm-pcrs=você especificou. O que exatamente está sendo protegido depende de quais PCRs você seleciona.Por exemplo, PCR[4] conterá eventos gerados por firmware que medem cada executável .efi que está sendo executado. (Isso pode incluir o kernel Linux se estiver sendo executado como um "stub EFI" com seu próprio gerenciador de inicialização incorporado.) Isso pode ser irritante, pois os hashes mudam a cada atualização, portanto, o Windows com BitLocker geralmente vincula a proteção contra adulteração ao Secure Boot – liga-se ao PCR[7] que, em vez disso, contém eventos para os certificados que foram usados para assinar os executáveis; qualquer coisa assinada pelo "certificado original oficial do Windows" da Microsoft será aprovada.
Então, se você também quisesse medir o initramfs, com kernels Linux modernos (5.17+), você incluiria PCR[9] na política. Para o cmdline do kernel, o systemd-boot atualizaria o PCR[8]. (Não tenho certeza do que o GRUB usa ou quando.) Recentemente, os desenvolvedores do systemd colocaram mais ênfase nas "Imagens Unificadas do Kernel" que contêm o kernel, o initramfs e a linha de comando agrupados; todo o pacote seria autenticado como um único binário .efi.
(Tenho um projeto antigo capaz de despejar o log de eventos em formato de texto, além de suas funções regulares.)
Especificamente para Linux, há um guia não oficial para quais índices de PCR são usados para quais propósitos aqui .
No Ubuntu, o pacote tpm2-tools inclui o comando
tpm2_eventlogque pode ser usado para ler o log de eventos do TPM via kernel:Isso pode ajudar a determinar exatamente qual conteúdo foi usado para gerar os valores de PCR e, portanto, quais arquivos e configurações estão efetivamente protegidos contra adulteração.