Trusted Platform Module (TPM)

24 registradores de configuração de plataforma são comuns em TPM 2.0 e recebem medições por uma operação de extensão, não por simples sobrescrita. Cada etapa do boot mede a próxima antes de transferir controle. Firmware, bootloader e componentes críticos geram hashes que são estendidos em PCRs. O resultado representa uma sequência de estados. O TPM não decide sozinho se o software é bom; ele registra valores. Uma política pode exigir valores esperados para liberar uma chave. Essa técnica é chamada sealing. Em um gateway residencial, a chave de disco pode ficar selada ao estado de boot. Se o bootloader for alterado, a liberação automática falha e o equipamento pede recuperação. A consequência prática é que o roubo do SSD não basta para ler os dados. Porém, uma atualização legítima também altera medições. O sistema precisa de mecanismo de atualização de política e chave de recuperação. PCRs podem usar bancos SHA-256 e outros algoritmos. SHA-1 existe em legado, mas não deve ser a escolha de novos projetos. O TPM também mantém chaves que nunca precisam sair em formato bruto. Operações de assinatura ou decriptação ocorrem internamente. A proteção física varia conforme a implementação: um TPM discreto em barramento, um módulo integrado e um fTPM têm superfícies diferentes. O termo TPM 2.0 descreve comportamento e comandos; não garante, sozinho, resistência física específica.

TPM 2.0 organiza objetos em hierarquias como endorsement, storage e platform. A Endorsement Key identifica o módulo e pode participar de atestação, enquanto Storage Root Keys protegem uma árvore de objetos. Chaves podem ter atributos que impedem exportação, exigem autorização, restringem uso a assinatura ou decriptação e vinculam a políticas. O TPM usa autorização por senha, HMAC sessions e policy sessions. Uma chave pode exigir PCRs, comando específico, presença física ou segredo. Isso permite desenho de menor privilégio. Um serviço de automação pode usar uma chave TPM para autenticação mTLS sem armazenar PEM exportável em disco. O processo solicita assinatura ao TPM. Se o sistema for comprometido, o atacante pode usar a chave enquanto controla a máquina, mas não consegue necessariamente copiá-la para outro host. Essa limitação é crucial: não exportável reduz clonagem; não impede uso abusivo no equipamento comprometido. A proteção precisa de controle de processo, SELinux/AppArmor, atualização e revogação. NV storage do TPM guarda pequenos valores, contadores e políticas, não arquivos grandes. Certificados e dados permanecem no sistema, cifrados ou associados a handles. A capacidade é limitada e o número de objetos persistentes varia. O software deve recriar contextos e não tratar o TPM como disco. Limpar o TPM remove hierarquias e pode tornar dados inacessíveis. Procedimentos de manutenção precisam de backup das chaves de recuperação.

Atestação permite que um verificador receba uma declaração assinada sobre o estado medido. O TPM usa uma Attestation Key para assinar PCRs e dados de frescor, como nonce. O verificador compara medições com valores aceitos. Em uma frota de hubs, isso pode limitar acesso do dispositivo à cloud quando firmware e boot não correspondem ao inventário. A arquitetura exige serviço de verificação, banco de medições, provisionamento e privacidade. A Endorsement Key não deve ser usada indiscriminadamente como identificador global, porque pode facilitar rastreamento. Credenciais e Attestation Keys intermediárias reduzem. Atestação não prova que toda a aplicação está livre de vulnerabilidades. Ela prova determinadas medições e que foram relatadas por uma raiz de confiança. Código carregado depois, ataques de runtime e credenciais roubadas continuam. Medir todos os componentes pode ser inviável. Linux IMA amplia medições de arquivos; a complexidade cresce. Em casa inteligente, atestação é mais comum em gateways corporativos, PCs e plataformas cloud do que em lâmpadas. O requisito de implantação inclui TPM 2.0 habilitado, firmware com measured boot, software de coleta e verificador. Sem o verificador, PCRs são apenas registros locais. A interoperabilidade segue comandos e estruturas TCG, mas políticas de fabricantes e sistemas operacionais variam.

O TPM não é um HSM de alta capacidade. Ele executa operações em baixa taxa, protege poucos objetos e fica dentro do endpoint. Um HSM de rede atende várias aplicações, oferece alta disponibilidade, auditoria e controles de operador. O TPM é adequado à identidade e proteção local. Ataques físicos avançados, falhas de firmware, side channels e comprometimento do sistema hospedeiro permanecem possíveis. fTPM compartilha mais recursos com firmware e processador; um TPM discreto adiciona isolamento, mas o barramento pode ser alvo se não houver proteção. Certificações como Common Criteria e perfis TCG ajudam, mas precisam ser verificadas por produto. Outro erro é habilitar BitLocker e descartar a chave de recuperação. Mudança de firmware, placa-mãe ou política pode exigir. A chave deve ficar em cofre separado. Em servidores de automação, limpar CMOS ou atualizar UEFI pode disparar recuperação. O proprietário precisa documentar. O TPM também não substitui Secure Boot; os mecanismos se complementam. Secure Boot verifica assinaturas antes de executar. Measured Boot registra. TPM protege chaves e atesta. A consequência prática é uma plataforma mais resistente a clonagem e adulteração de boot, desde que o ciclo de recuperação seja mantido.