O que é TPM 2.0 na prática
O trusted platform module 2 é um chip de segurança presente em hardware moderno. Ele armazena chaves criptográficas de forma isolada, controla a integridade da inicialização e facilita operações como BitLocker no Windows, encriptação de disco no Linux e verificação de identidade em dispositivos Azure AD. Não é apenas um recurso opcional — tornou-se requisito para Windows 11, Secure Boot ativo e várias ferramentas de bootstrapping corporativo. A maioria das pessoas entende TPM como um cofre. Na verdade, funciona mais como um signatário hardware: você pede algo, o chip assina usando uma chave interna que nunca sai do dispositivo, e o resultado é verificável externamente. Isso elimina grande parte dos vetores de ataque baseados em roubo de chaves privadas.
Como verificar se o TPM 2.0 está ativo no seu sistema
No Windows, abra o Gerenciador de Dispositivos, expanda Segurança do hardware e procure por Trusted Platform Module. A versão aparece em Propriedades. Alternativamente, rode tpm.msc e observe o status do gerenciador de TPM. No Linux, use o comando tpm2_pcrread ou verifique a presença de /dev/tpm0. Se o dispositivo existir mas o driver não responder, pode ser um problema de firmware ou BIOS. Em máquinas virtuais com VirtualBox ou VMware, o TPM virtual precisa ser explicitamente habilitado nas configurações da VM, caso contrário você verá o dispositivo mas ele não responderá comandos reais.
Inicialização confiável e chain of trust
O TPM 2.0 mede cada etapa do boot em PCR (Platform Configuration Registers). A secuencia é: firmware UEFI mede o bootloader bootloader mede o kernel kernel mede initramfs e módulos. Cada medição é registrada como um hash em um PCR específico. Se qualquer um desses componentes for alterado por malware ou configuração incorreta, a cadeia quebra e o sistema pode se recusar a desbloquear volumes criptografados ou iniciar sessões Attested. Isso funciona bem até o dia em que uma atualização do kernel quebra a compatibilidade com alguma extensão de initramfs e os hashes nos PCRs ficam inconsistentes. Já vi isso acontecer com atualizações do Ubuntu durante migrações de versão. O workaround mais direto é acessar as configurações de inicialização do firmware, limpar os PCRs via Clear TPM (com cuidado, pois isso invalida credenciais existentes) ou, melhor ainda, usar o modo de manutenção para reconstruir o initramfs e garantir que todos os hashes sejam recalculados corretamente.
Como ativar o TPM 2.0 passo a passo
Vá ao firmware UEFI da máquina. O acesso varia: normalmente Del, F2, F10 ou Esc durante o POST. Nas opções de segurança, procure por Trusted Computing, TPM, PTT (Intel) ou fTPM (AMD). Habilite. Salve e saia. No Windows 11, o sistema detectará automaticamente. Para Linux, verifique que o módulo tpm_tis está carregado com lsmod. Se estiver ausente, carregue manualmente com modprobe tpm_tis e adicione ao /etc/modules para persistência. Em máquinas Dell com Optiplex e Latitude, há um bug conhecido em que o firmware marca o TPM como desabilitado mesmo após a ativação. A correção envolve atualizar o firmware para a versão mais recente e, se necessário, realizar um clear de propriedade no TPM antes de reativá-lo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Encriptação de disco com BitLocker eLUKS
Com TPM 2.0 habilitado, o BitLocker no Windows pode usar o chip para desbloquear automaticamente o volume durante o boot, sem exigir PIN ou chave de recuperação. O Linux faz o mesmo via LUKS com suporte a TPM2, usando tools como tpm2-tss e systemd-cryptenroll. A vantagem é conveniência; a desvantagem é que, se o chip for removido ou seu estado mudar (por exemplo, após troca de placa-mãe), o usuário perde acesso imediato ao volume e depende exclusivamente da chave de recuperação. Eu configurei TPM-backed LUKS em servidores Dell R740 rodando Debian. Uma atualização de firmware do servidor reiniciou o estado do TPM e o volume parou de desbloquear automaticamente no próximo boot. A solução foi montar um live USB, usar o comando cryptopen com a chave de recuperação e depois reenrolar a chave com systemd-cryptenroll --tpm2-device=auto. Isso leva cerca de 15 minutos por máquina. Para um parque de 200 servidores, isso não escala bem.
Limitações e problemas reais
TPM 2.0 não protege contra tudo. Ele não impede ataques side-channel, nem garante a confidencialidade do firmware em si. Se o atacante tiver acesso físico prolongado à máquina, existem técnicas de cold boot e DMA attack que contornam parcialmente as garantias do chip. Além disso, muitas placas-mãe baratas ou antigas implementam o TPM de forma inconsistente — alguns fabricantes desabilitam funções críticas por padrão ou incluem builds do firmware com bugs conhecidos de leitura de PCR. Outro ponto importante: Clear TPM apaga todas as chaves armazenadas. Isso destrói credenciais BitLocker, chaves SSH provisionadas via TPM, certificados de identidade de dispositivo e tokens de Attestation. Sempre faça backup das chaves de recuperação antes de qualquer clear. Sem backup, a perda de dados é real e irreversível.
Ferramentas e recursos
O TCG (Trusted Computing Group) mantém a especificação completa do TPM 2.0 disponível gratuitamente. Para administração prática no Windows, use o TPM Management console (tpm.msc) ou PowerShell com os cmdlets Get-Tpm. No Linux, o pacote tpm2-tools oferece comandos como tpm2_pcrread, tpm2_createkey e tpm2_policyrestart. Para entornos corporativos com múltiplas máquinas, ferramentas como Microsoft Intune, Ansible com módulos tpm2 e scripts de provisioning via cloud-init são o caminho habitual. Links úteis: a documentação da Microsoft sobre TPM e Windows 11 está em docs.microsoft.com/security/platform-security/device-guard. A especificação oficial TCG TPM 2.0 pode ser baixada em trustedcomputinggroup.org. Para Linux, o projeto tpm2-software GitHub contém as ferramentas de linha de comando e bibliotecas TSS (TPM Software Stack).
Dica técnica sobre ATTESTAÇÃO DE DISPOSITIVO
Quando um dispositivo com TPM 2.0 participa de um domínio Windows ou Entra ID, ele gera uma attestation que prova ao serviço cloud que aquele hardware passou por um boot íntegro. Isso é usado para Conditional Access e dispositivos confiáveis. Porém, se a máquina foi clonada de uma imagem WIM ou VHDX antes do provisionamento do TPM, a attestation falha silenciosamente porque os objetos de identidade já estão vinculados ao chip original. A correção exige limpar a identidade de dispositivo com Remove-WindowsSRS ou desvincular via Azure AD Join reset antes de reimplementar a imagem. Em resumo, TPM 2.0 é útil e geralmente transparente quando funciona. Mas seu ciclo de vida está atrelado à saúde do firmware e à qualidade da implementação do fabricante. Antes de depender dele para criptografia de produção, teste em ambiente controlado, faça backup das chaves de recuperação e documente o procedimento de recuperação. É o tipo de coisa que parece simples até o dia em que você precisa dela e o servidor não levanta.
