Nos últimos anos, os módulos TPM 2.0 deixaram de ser um mistério de hardware e se tornaram uma parte comum de qualquer computador moderno com UEFI e Secure Boot. Este artigo explica o que são /dev/tpm0 e /dev/tpmrm0 e como usar tpm2_pcread e tpm2_pcrextend. (bem como seu comando real em tpm2-tools), além de explicar como eles se encaixam em políticas de inicialização medida, criptografia de disco e PCR assinadas no Linux.
Existe documentação útil, mas ela está espalhada entre páginas de manual do systemd, entradas wiki e postagens muito densas; Aqui reunimos todas as informações principais (PCRs, exemplos práticos, riscos e defesas) para que os técnicos, mesmo que não sejam especialistas em TPM, possam trabalhar com essas ferramentas sem se perder em detalhes obscuros.
O que é um TPM 2.0 e por que você pode se interessar
Um Trusted Platform Module é um chip de segurança que fica na sua placa-mãe (ou dentro da CPU, como fTPM/Intel PTT) e atua como um armazenamento seguro, gerador de números aleatórios e raiz de confiança para o sistema. É passivo: se você não o usa, ele não faz nada., mas quando você o integra ao seu fluxo de inicialização e criptografia de disco, ele fornece verificação de integridade e chaves protegidas por hardware.
Na prática, um TPM 2.0 permite dois modos principais de utilização na criptografia de discos: a) gerar/salvar uma chave forte e proteger seu uso com um PIN com bloqueio anti-força bruta; b) ativar o chamado boot medido, onde Cada componente da inicialização é medido em registros de PCR, então a chave só é “desembrulhada” se o sistema não tiver sido adulterado (e opcionalmente com um PIN de pré-inicialização).
/dev/tpm0 e /dev/tpmrm0: diferenças e quando usar cada um
No Linux, você verá dois dispositivos de caracteres quando o TPM 2.0 estiver disponível. /dev/tpm0 é a interface “bruta” do TPMEnquanto /dev/tpmrm0 expõe o acesso através do Gerenciador de Recursos (um gerenciador que multiplica clientes, gerencia sessões e recursos), sendo o recomendado pelo tpm2-tools na maioria dos cenários.
Se você não tiver certeza se um TPM existe ou não, você pode testá-lo em modo dinâmico. Se /sys/class/tpm/ estiver vazio ou o comando wiki não retornar nada, nenhum TPM está visível: ele pode não existir fisicamente ou pode estar desabilitado no firmware.
# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*
Quando ambos os nós do dispositivo estiverem presentes, o tpm2-tools normalmente detectará /dev/tpmrm0 e o usará automaticamente. Se você precisar forçar um dispositivo, a maioria das ferramentas aceita –tcti ou usar variáveis de ambiente TCTI, mas para tarefas comuns geralmente não é necessário.
PCRs TPM: como funcionam e o que medem
Os Registros de Configuração de Plataforma são registros que armazenam hashes (geralmente SHA-256) do estado de componentes críticos em cada fase de inicialização. Eles são inicializados em zero no ciclo de inicialização e só podem ser “estendidos”: nunca reescreva ou apague (exceto em casos de depuração como PCR 16).
A operação fundamental é a extensão: novo_valor = SHA256(valor_atual || SHA256(dados))É assim que as medições são encadeadas sem permitir redefinições oportunistas. Esse padrão é usado para medir firmware, configuração, inicialização segura, kernel, initrd e parâmetros do kernel, entre outros.
Em equipamentos modernos, você verá 24 PCRs (0–23). Os mais relevantes na inicialização UEFI com systemd são:
– PCR 0: código de firmware.
– PCR 1: configuração de firmware (configurações UEFI).
– PCR 7: Status do Secure Boot e certificados em que ele confia.
– PCR 9: initrd(s) medidos pelo kernel.
– PCR 11: UKI (Unified Kernel Image) e marcas de fase via systemd-stub/systemd-pcrphase.
– PCR 12: linha de comando do kernel.
Leia e estenda PCRs com tpm2-tools: tpm2_pcrread e tpm2_pcr_extend
Em tpm2-tools a leitura é feita com tpm2_pcread e a extensão com tpm2_pcrextend. Às vezes você verá “tpm2_pcr_extend” referido como a operação conceitual de extensão, mas O comando atual do conjunto é tpm2_pcrextend.
Para inspecionar o status atual dos PCRs SHA-256, é tão simples como:
# Leer PCRs en SHA-256 (ejemplos de índices habituales)
sudo tpm2_pcrread sha256:0,1,7,9,11,12
# O todos los PCRs SHA-256 disponibles
tpm2_pcrread sha256:all
Para estender um PCR com o hash de dados arbitrários (como um exemplo pedagógico, o hash de /etc/passwd), calcule o SHA-256 e estenda-o. Lembre-se: o TPM não recebe dados gigantescos, mas sim seu hash, por limites e design.
# 1) Guardar el hash de /etc/passwd
echo -n $(sha256sum /etc/passwd | cut -d' ' -f1) > passwd.sha
# 2) Extender PCR 7 (ejemplo) con el hash previo
sudo tpm2_pcrextend 7:sha256=$(cat passwd.sha)
# 3) Ver el nuevo valor del PCR 7
tpm2_pcrread sha256:7
Se você quiser reproduzir a matemática de extensão fora do TPM, Você concatena o valor PCR atual (binário) com o novo hash e você aplica SHA-256 novamente para verificar o resultado.
Um PCR pode ser reiniciado?
Em condições normais, não. A filosofia é que um PCR só cresce com extensõesHá uma exceção: o PCR 16 normalmente é reservado para “depuração” e pode ser redefinido em certos fluxos, mas não é útil como raiz de segurança da sua política.
Inicialização medida, LUKS e systemd-cryptenroll: juntando as peças
Ao integrar o TPM à criptografia do seu disco, você pode “vincular” o desbloqueio da chave a um conjunto de PCRs. Se na inicialização atual esses PCRs tiverem os mesmos valores de quando você registrou a chave, o TPM é desbloqueado e o volume LUKS é aberto automaticamente (com ou sem um PIN de pré-inicialização, dependendo da sua configuração).
Isso é feito muito bem com systemd-cryptenroll e systemd-cryptsetup. A ideia é criar seu volume, registrar a chave TPM e adicionar uma chave de recuperação. para que você não fique de fora caso as medições mudem (por exemplo, após atualizar o firmware ou o kernel).
# Ejemplo: crear LUKS, matricular TPM y añadir recuperación (pseudoflujo)
# 1) Crear el volumen con contraseña temporal
sudo cryptsetup luksFormat /dev/nvme0n1p2
# 2) Matricular TPM en LUKS usando PCRs concretos y PIN
sudo systemd-cryptenroll \
--tpm2-device=auto \
--tpm2-with-pin=yes \
--tpm2-pcrs=1+2+3+4 \
--wipe-slot=empty \
/dev/nvme0n1p2
# 3) Añadir clave de recuperación aleatoria
sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p2
# 4) Abrir con TPM o con recovery cuando proceda
systemd-cryptsetup attach root /dev/nvme0n1p2 - tpm2-device=auto
Se você forçar uma discrepância (por exemplo, você estende o PCR 4 de propósito), o TPM não liberará mais a chave e você precisará usar a chave de recuperação. Posteriormente, você poderá registrar novamente o TPM com os novos valores atuais usando –wipe-slot=tpm2 e outra execução do systemd-cryptenroll.
Quais PCRs escolher e por quê
Quanto mais PCRs relevantes você vincular, maior será a área de superfície que você reduzirá, mas com mais frequência você terá que se registrar novamente após alterações legítimas. Alguns critérios práticos:
– PCR 7 (Inicialização Segura): Deve ser muito estável se o seu conjunto de chaves não mudar.
– PCR 0/1 (firmware e configuração): raramente mudam; eles exigem um novo registro após atualizar o firmware ou alterar o BIOS/UEFI.
– PCR 9/11/12 (kernel, initrd, UKI e cmdline): Eles mudam frequentemente se você não usar UKI ou assinatura/política estável.
Em alguns ambientes, foi visto vincular apenas o PCR 7, contando com o Secure Boot verificando o kernel e o initrd se eles foram iniciados como UKI assinado e usando o systemd-boot que não permite a edição de parâmetros do kernel quando o SB está ativo. Isso funciona, mas se sua inicialização segura depende de chaves de terceiros (como Microsoft 3rd Party), é mais fácil orquestrar uma inicialização alternativa que preserve o PCR 7 e, portanto, Não é a opção mais restritiva.
Assinatura das políticas UKI e PCR: estabilidade sem perder a segurança
Uma solução prática para evitar o novo registro toda vez que você atualiza o kernel é usar UKI (Unified Kernel Image) e uma política de PCR assinadaVocê gera um par de chaves, vincula a chave pública ao TPM no momento do registro e assina seu UKI após cada atualização. O TPM confia nessa assinatura e permite o desbloqueio mesmo que o hash específico do kernel seja alterado.
A ferramenta systemd-measure e o auxiliar systemd-ukify tornam isso fácil: ukify empacota kernel, initrd e cmdline no UKI (geralmente medido em PCR 11) e o systemd-measure assina a política. Com o mkinitcpio, o ukify pode ser integrado para que pós-instalação a assinatura é executada sozinha.
# Esquema típico (pseudocomandos)
# 1) Crear claves para política PCR firmada
openssl genpkey -algorithm RSA -out /etc/kernel/pcr-initrd.key.pem -pkeyopt rsa_keygen_bits:3072
openssl req -new -x509 -key /etc/kernel/pcr-initrd.key.pem -out /etc/kernel/pcr-initrd.pub.pem -subj "/CN=UKI PCR Policy"
# 2) Configurar ukify/mkinitcpio para generar UKI y firmar política
# (consultar man ukify y systemd-measure para parámetros)
# 3) Matricular en LUKS atando PCRs y clave pública de la política
sudo systemd-cryptenroll \
--tpm2-device=auto \
--wipe-slot=tpm2 \
--tpm2-with-pin=yes \
--tpm2-pcrs=0+1+2+7 \
--tpm2-public-key=/etc/kernel/pcr-initrd.pub.pem \
--tpm2-public-key-pcrs=11 \
/dev/nvme0n1p2
Deste modo, Sua política permanece estável contra alterações de kernel/initrd enquanto você continuar assinando o UKI com sua chave.Se você renovar suas senhas ou alterar seu conjunto de PCR, será necessário se inscrever novamente.
Exemplos de cadeias de medição com systemd
Durante a inicialização, systemd-stub e systemd-pcrphase estendem PCRs em momentos específicos. Por exemplo, “enter-initrd” é registrado no PCR 11, permitindo que um desbloqueio seja válido apenas dentro do initrd (reduzindo vetores em que um invasor tenta reutilizar a chave posteriormente).
Em sistemas com UKI, o conteúdo de UKI é medido em PCR 11; em sistemas sem UKI, o kernel mede initrds em PCR 9 e o bootloader pode medir o cmdline no PCR 12. Certifique-se de cobrir initrd e cmdline em sua política, ou alguém pode porta dos fundos o initrd ou inicialize com um cmdline malicioso como init = / bin / bash.
Riscos reais: inicialização a frio, detecção de TPM e muito mais
O que pode dar errado? Há vários pontos a serem considerados ao modelar ameaças. Ataques de inicialização a frio ainda são viáveis: se o desbloqueio for totalmente automático, um invasor pode repetir tentativas ilimitadas. A mitigação clara é exigir um PIN de pré-inicialização (PBA), reduzindo as tentativas para uma por ciclo de energia.
Outra categoria é a ataques de sniffing no barramento TPMA CPU solicita a chave, o TPM a envia; se o link for interceptado, a chave pode vazar. Para isso, o systemd implementa "criptografia de parâmetros" para que a troca seja criptografada; alternativamente, o uso de fTPM/Intel PTT ou memória criptografada reduz a exposição. Há demonstrações públicas relativamente acessíveis (mesmo com microcontroladores) que ilustram a viabilidade em laptops de grandes marcas.
Também houve vulnerabilidades acadêmicas e práticas: TPM-Fail, faultTPM (com impacto notável na AMD) e o caso bitpixie (CVE-2023-21563)Isso não significa que o TPM seja inútil, mas você deve manter seu firmware atualizado, entender seu modelo de ameaça e não confiar cegamente nele.
Status do BitLocker contra essas ameaças
No mundo Windows, a criptografia de disco mais amplamente utilizada é o BitLocker. Já foi observado que sua configuração padrão (desbloqueio automático somente com TPM) Ele deixa a porta aberta tanto para inicialização a frio quanto para detecção de canal TPM, já que não implementa criptografia de parâmetros no estilo systemd. Isso torna certos computadores corporativos vulneráveis a ataques em minutos.
A recomendação é permitir autenticação pré-inicialização via políticas/registro ou CLI, algo que não é suficientemente exposto ao usuário comum. Além disso, lembre-se de verificar onde a chave de recuperação está armazenada: ela geralmente reside na conta Microsoft do usuário, o que É outro ângulo de risco se não for controlado.
Truque ofensivo/defensivo: substitua a raiz LUKS para forçar sua senha
Existe um vetor interessante quando não há autenticação pré-inicialização. Um invasor pode clonar a partição LUKS real, substitua-o por outro LUKS com o mesmo UUID e uma senha que ele conheçae inicialize o computador. Como as medições do PCR correspondem, o TPM libera a chave, mas ela não corresponde aos LUKS falsos, então o initrd solicitará a chave de "recuperação". Ao inserir a senha conhecida pelo invasor, seu sistema será executado como root no initrd, e você poderá orquestrar o roubo da chave original (por exemplo, montando a cópia real na rede e usando systemd-cryptsetup).
Mitigações claras: ativar autenticação pré-inicialização, aproveite o systemd-pcrphase para vincular o desbloqueio estritamente à fase initrd e considere medir/vincular também o volume LUKS de destino (requer um design cuidadoso para evitar círculos viciosos).
Escolha de particionamento e segunda chave: melhores práticas
Manter uma chave de recuperação É obrigatório: se o TPM ou a placa-mãe falharem, sua chave vinculada ao TPM será inútil. O LUKS permite vários slots (o TPM usa um, a recuperação usa outro). Além disso, separar as partições / e /home tem vantagens: você pode aplicar medição rigorosa com TPM a/ e usar uma chave forte ou dispositivo FIDO2/YubiKey para /home, reduzindo a confiança geral em um único mecanismo.
O que acontece quando você atualiza o firmware ou o kernel?
Se você alterar o firmware ou tocar nas opções UEFI, PCRs como 0/1 serão alterados e o TPM não liberará a chave até que você faça o novo registro. Para kernel e initrd, as mudanças são frequentesSe você não usar um UKI com apólice assinada, cada atualização poderá forçá-lo a usar a opção de recuperação e se registrar novamente mais tarde. Com um UKI assinado, basta assiná-lo e pronto.
Notas e Observações da Comunidade
Em alguns guias populares de certas distribuições foi recomendado vincular apenas PCR 7 sempre que usar UKI e systemd-boot, contando com as proteções do Secure Boot e a impossibilidade de editar o cmdline. Funciona, mas há riscos se você depender de terceiros. Um bug também foi documentado no passado em que pressionar Enter abria um shell de recuperação após o desbloqueio; é uma boa ideia manter suas versões atualizadas para evitar surpresas.
Comentários interessantes foram compartilhados em 2025/06: Falha no TPM continua afetando a AMD até certo ponto; os wikis adicionaram seções específicas sobre políticas de PCR assinadas; e o instalador para uma distribuição que oferece FDE com TPM como um recurso experimental foi testado, com alguns problemas práticos (exigindo recuperação na primeira inicialização, dependência de snaps, criptografia de disco duplo), um problema que merece uma auditoria mais aprofundada.
Um acompanhamento focado na criptografia de disco no Windows foi publicado em 2025/07. A conclusão geral reforça a necessidade de PBA e criptografia do canal TPM., além de limitar a dependência de chaves de terceiros no Secure Boot.
Dicas operacionais com tpm2-tools e systemd
Para uso diário: Instale tpm2-tools e tpm2-tss. Usa /dev/tpmrm0 por padrãoe tpm2_pcread/tpm2_pcrextend para testes e experimentos com PCRs. Evite estender PCRs de produção com dados arbitrários: faça isso em laboratórios ou use o PCR 16 para testes.
Ao se registrar com systemd-cryptenroll: –tpm2-device=auto detecta TPM; –tpm2-com-pino adiciona PBA; –tpm2-pcrs=… selecione seus PCRs; –tpm2-public-key=… e –tpm2-public-key-pcrs=… ativar uma política de PCR assinada (por exemplo, vinculada ao PCR 11 para UKI). Não se esqueça –limpe o slot quando você quiser limpar um slot anterior.
Se você não tem TPM e o systemd faz você esperar na inicialização
Ocasionalmente, após uma atualização, um serviço tenta usar o TPM mesmo que sua máquina não o tenha visível, causando tempos limite na inicialização. Primeiro verifique se nenhum /dev/tpm* aparece nem entradas em /sys/class/tpm.
# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/
Se não houver TPM, verifique seu /etc/crypttab não tem opções como tpm2-device=autoSe existirem, exclua-os e reconstrua seu initrd. Você também pode desabilitar a fase de medição em computadores sem TPM:
# 1) Eliminar referencias TPM en /etc/crypttab y regenerar initrd
sudo mkinitcpio -P # (o dracut/rebuildinitrd según distro)
# 2) Evitar carga de módulos TPM si el firmware publica algo extraño
echo -e "blacklist tpm\nblacklist tpm_tis\nblacklist tpm_crb" | sudo tee /etc/modprobe.d/no-tpm.conf
# 3) Opcional: evitar pcrphase si te da problemas
sudo systemctl mask systemd-pcrphase.service
Isso elimina esperas desnecessárias caso seu equipamento não tenha TPM. Se você habilitar o TPM posteriormente no BIOS/UEFI, remova a lista negra e desmascare a unidade para recuperar as medições.
Boas práticas e decisões de confiança
Algumas pessoas desconfiam do TPM por ser uma "caixa preta", assim como os discos autocriptografados. Essa é uma dúvida razoável. Avalie seu modelo de ameaça e equilibra usabilidade, privacidade e manutenção. Para muitas pessoas, TPM+PBA+UKI assinado representa um grande salto de segurança sem atrito excessivo.
Em hardware que permita, adicione memória criptografada e evite depender de chaves de terceiros no Secure Boot; limite a cadeia às suas próprias chaves sempre que possível. Mantenha o firmware e o kernel atualizados para incorporar mitigações para vulnerabilidades publicadas.
Dominar as operações /dev/tpm0, /dev/tpmrm0 e tpm2_pcrread/tpm2_pcr_extend abre as portas para inicialização medida e criptografia de disco robusta no Linux; com UKI e uma política de PCR assinada, você obtém estabilidade operacional, e adicionar um PIN de pré-inicialização também protege você de ataques mais práticos. O segredo é escolher bem os PCRs, assinar o que muda com frequência e sempre manter uma boa chave de recuperação..
