Origem: sessão claude.ai, 2026-07-04, auditoria + pesquisa de hierarquia TPM pro SDK zero-trust bidirecional (ver também stealthy-stoat#2, tidy-tortoise#5, issue de Light/Augmented no homing-robin).
Sensibilidade: PÚBLICA — arquitetura de hardening, sem detalhe de parceiro/pricing.
Contexto
Hoje o core/integrity_anchor.py (Phase E) e o LicenseGuard/JWT são 100% software — SHA-256 + arquivo local, Ed25519 assinando. Funciona e é honesto (tamper-evident, nunca clama proof), mas existe um degrau intermediário de hardware que nenhum dos dois usa hoje: TPM local.
Por que TPM, especificamente, sem virar dependência de rede
TPM eleva o piso de garantia sem exigir rede — o chip sela o hash do anchor/estado de licença num PCR, e adulteração de boot/binário vira detectável de um jeito que arquivo-sozinho não pega. Continua funcionando air-gapped, porque é chip local, não beacon.
TPM 1.2 vs 2.0 — tratar como gerações distintas, não binário presente/ausente
TPM 2.0 tem mais bancos de PCR, algoritmos melhores, suporte a remote attestation mais rico que TPM 1.2. Parques de hardware mais antigos (cenário real em cliente industrial/portuário) podem ter só 1.x — a detecção precisa diferenciar, não tratar TPM como sim/não.
A progressão de garantia que isso habilita (nomear explicitamente na doutrina)
Tier 0: file+SHA local, sem Robin → tamper-evident (piso atual)
Tier 1: file+SHA local + Robin freshness → tamper-evident+ (testemunha externa, paid)
Tier 2: TPM local, sem Robin → tamper-resistant
Tier 3: TPM local + Robin freshness → tamper-resistant+
Tier 4: HSM (local ou via Robin) + Robin → aproximando de tamper-proof (nunca absoluto)
Cada tier de "+Robin" eleva a classe porque tamper passa a exigir coordenar dois sistemas (mentir local e continuar batendo com o que o HQ espera ver remotamente) — mesmo princípio do Sigstore/Rekor (log de transparência externo transforma assinatura local forjável em evento com testemunha independente). Ver pesquisa completa da sessão sobre SPIFFE/SPIRE, hashicorp/go-plugin, e literatura de Remote Attestation (RFC 9683, arxiv 2105.02466) para as fontes.
Distinção importante — o que Robin PODE e NÃO PODE emprestar
(A) Robin retransmitindo pra HSM remoto executar uma operação (assinar, verificar) — válido, mesmo padrão já usado por Stoat/Tortoise.
(B) Robin substituindo o papel do TPM de atestar que ESTA máquina não foi adulterada — não é possível estruturalmente. TPM Quote prova algo sobre a máquina física específica porque a chave vive dentro do chip nesta máquina. Serviço remoto confirma frescor, nunca conjura uma raiz de confiança física ausente localmente.
O que fazer (avaliação, não implementação)
O que NÃO fazer
- Não prometer "tamper-proof" absoluto em nenhuma documentação — manter o mesmo padrão de honestidade já praticado
- Não implementar código nesta issue — é avaliação/doutrina primeiro
- Não tornar nenhum tier dependente de rede obrigatória — air-gap sempre preservado como piso funcional
Origem: sessão claude.ai, 2026-07-04, auditoria + pesquisa de hierarquia TPM pro SDK zero-trust bidirecional (ver também
stealthy-stoat#2,tidy-tortoise#5, issue de Light/Augmented nohoming-robin).Sensibilidade: PÚBLICA — arquitetura de hardening, sem detalhe de parceiro/pricing.
Contexto
Hoje o
core/integrity_anchor.py(Phase E) e oLicenseGuard/JWT são 100% software — SHA-256 + arquivo local, Ed25519 assinando. Funciona e é honesto (tamper-evident, nunca clama proof), mas existe um degrau intermediário de hardware que nenhum dos dois usa hoje: TPM local.Por que TPM, especificamente, sem virar dependência de rede
TPM eleva o piso de garantia sem exigir rede — o chip sela o hash do anchor/estado de licença num PCR, e adulteração de boot/binário vira detectável de um jeito que arquivo-sozinho não pega. Continua funcionando air-gapped, porque é chip local, não beacon.
TPM 1.2 vs 2.0 — tratar como gerações distintas, não binário presente/ausente
TPM 2.0 tem mais bancos de PCR, algoritmos melhores, suporte a remote attestation mais rico que TPM 1.2. Parques de hardware mais antigos (cenário real em cliente industrial/portuário) podem ter só 1.x — a detecção precisa diferenciar, não tratar TPM como sim/não.
A progressão de garantia que isso habilita (nomear explicitamente na doutrina)
Cada tier de "+Robin" eleva a classe porque tamper passa a exigir coordenar dois sistemas (mentir local e continuar batendo com o que o HQ espera ver remotamente) — mesmo princípio do Sigstore/Rekor (log de transparência externo transforma assinatura local forjável em evento com testemunha independente). Ver pesquisa completa da sessão sobre SPIFFE/SPIRE, hashicorp/go-plugin, e literatura de Remote Attestation (RFC 9683, arxiv 2105.02466) para as fontes.
Distinção importante — o que Robin PODE e NÃO PODE emprestar
(A) Robin retransmitindo pra HSM remoto executar uma operação (assinar, verificar) — válido, mesmo padrão já usado por Stoat/Tortoise.
(B) Robin substituindo o papel do TPM de atestar que ESTA máquina não foi adulterada — não é possível estruturalmente. TPM Quote prova algo sobre a máquina física específica porque a chave vive dentro do chip nesta máquina. Serviço remoto confirma frescor, nunca conjura uma raiz de confiança física ausente localmente.
O que fazer (avaliação, não implementação)
tpm2-tools/tpm2-pytssno Linux)integrity_anchor.py— complementar ao SHA-256 existente, não substitutoLicenseGuard/JWTINTEGRITY_CHECK_ALPHA_LOGIC.mdexistente ouPLAN_BUILD_IDENTITY_RELEASE_INTEGRITY.md)O que NÃO fazer