Resumo

  • O RFC 10013 define nome e valor bruto ou digerido obrigatórios para um componente medido, além de versão, autoridades que assinam o componente e flags de perfil opcionais. A estrutura pode ser transportada em JSON ou CBOR numa claim de medição EAT.
  • A autoridade do componente não é automaticamente o signatário do EAT. Um digest igual não comprova que todo o estado relevante foi coletado, e um Attestation Result favorável não demonstra propriedade, cadastro ou direito ao recurso.
  • A decisão explicável mantém separados o limite da medição, o coletor, o Attester, o frescor, o perfil, a Reference Value, a política do Verifier e a autorização específica do Relying Party.

A saída da quarentena não cabe em um selo verde

Imagine um equipamento de borda de telecomunicações que recebeu manutenção e tenta sair da rede de quarentena.

Ele apresenta um Entity Attestation Token assinado pela chave esperada e ligado a um nonce recente. O componente medido identifica o boot loader, informa versão e traz um SHA-256 igual ao valor de referência de produção. O array de authorities contém dois signatários aprovados do firmware. O perfil é conhecido. O Verifier devolve “compliant”.

Ainda não existe razão suficiente para devolver acesso administrativo ao equipamento.

O coletor pode ter medido o carregador assinado e deixado fora a configuração mutável que escolhe os próximos módulos. A referência pode continuar aceitando uma versão cuja falha acabou de ser publicada. O aparelho pode estar íntegro, mas pertencer a um integrador. Pode estar autorizado a transmitir telemetria e não a alterar roteamento. As posições no array de autoridades podem ter sido lidas com a semântica de outro perfil.

Nada disso torna o digest falso. Torna imprópria a conclusão automática.

Publicado em julho de 2026 na trilha de padrões do IETF, o RFC 10013 cria um modelo de informação e representações coordenadas para descrever o estado amostrado de um componente. Ele facilita a troca de evidência; não concentra todas as decisões de confiança dentro do objeto.

O recorte da medição é uma decisão anterior

Um componente medido pode ser firmware em flash, software carregado na memória durante a inicialização, uma verificação de integridade em execução, um objeto do sistema de arquivos, um bloco de configuração ou um registrador de CPU.

O RFC 9393 usa CoSWID para identificar software e acompanhar instalação, correção e atualização. Isso não descreve naturalmente todo estado de boot inicial, registrador ou objeto sem sistema de arquivos. O RFC 10013 oferece uma forma mais geral para essas amostras.

Mas não escolhe o que medir.

O projetista traça a fronteira; o coletor lê o que ficou dentro dela. Hardware protegido pode elevar a resistência à falsificação sem ampliar magicamente o escopo. Um hash perfeito de uma região incompleta continua sendo evidência perfeita sobre uma região incompleta.

Por isso, o registro precisa guardar Target Environment, fronteira, mecanismo, tempo ou boot epoch e dependências excluídas. “Secure boot aprovado” é um resumo de interface, não a prova reproduzível.

A primazia do código em execução exige a ordem correta: o padrão organiza a declaração; a operação demonstra bytes coletados, código executado e efeito autorizado.

Nome, versão e valor não têm o mesmo alcance

O nome é obrigatório e legível. Sua convenção depende do tipo de componente. A consistência ao longo das versões ajuda a acompanhar atualizações, mas não cria um identificador global. Dois fornecedores podem escolher nomes próximos; o caminho /boot/loader.bin pode permanecer enquanto o papel do arquivo muda.

A versão é opcional e pode usar os esquemas de versão do CoSWID. Semantic Versioning é recomendada no modelo de informação, não imposta a registradores, blobs e todos os ecossistemas de firmware.

O valor pode ser bruto ou digerido. O bruto preserva o conteúdo, mas varia de poucos bytes a uma configuração enorme. O decodificador pode limitar memória; sem limite, a evidência vira vetor de exaustão e repositório de dados sensíveis.

O formato digerido leva algoritmo e valor. O algoritmo é interpretado pelo registro IANA Named Information Hash Algorithms, e o RFC exige função forte. Força criptográfica não comprova que o estado certo foi lido, que a referência segue segura ou que a coleta pertence ao boot atual.

Existem dois signatários em perguntas diferentes

No RFC 10013, uma authority é a entidade capaz de identificar o componente instalado por assinatura digital. Seu identificador pode ser certificado X.509, chave pública, impressão da chave ou outra associação exclusiva. A assinatura pode ser verificada durante a instalação, como na arquitetura do RFC 9019, ou pelo firmware de boot, sistema operacional ou launcher.

Essa assinatura não é a assinatura do Attester no EAT.

Uma prova a procedência ou aprovação do artefato. A outra protege o conjunto de claims e o liga a um ambiente de atestação. Confundi-las apaga quem observou o estado e com quais proteções.

Pode haver várias autoridades: sistema de atualização, dono da frota, auditor. A ordem pode carregar significado. É o perfil EAT que deve dizer se o campo é usado, o papel de cada entrada e como interpretar seus bytes.

As flags ocupam exatamente oito bytes, mas o padrão base não define nenhum dos 64 bits. Se o consumidor desconhece o perfil e encontra authorities ou flags, deve rejeitar o EAT. Adivinhar uma disposição conhecida cria política sem proveniência.

JSON, CBOR, 295 e 296 resolvem a leitura

O EAT em CBOR pode carregar um componente CBOR de forma homogênea ou encapsular JSON. O EAT em JSON pode levar JSON diretamente ou CBOR codificado em base64url. A IANA registra application/measured-component+cbor e application/measured-component+json, e o registro CoRE Content-Formats atribui 295 e 296.

Esses registros identificam a representação. Não certificam o produtor nem escolhem o resultado.

A divisão segue a lógica de especificação inicial mínima e decisão futura localizada: padronizar identidade, valor e codificação; deixar perfil, referências, appraisal e autorização como escolhas explícitas de quem suporta a consequência.

A busca oficial de errata do RFC 10013 não retornava correspondências em 30 de agosto de 2026. É uma fotografia do registro, não uma auditoria de implementações.

EAT padroniza claims, não a segurança do Attester

O RFC 9711 afirma que a semântica de uma claim não impõe um nível de segurança à sua implementação nem ao Attester. O receptor julga confiabilidade conhecendo a implementação do fornecedor e/ou o processamento realizado pelo Verifier.

O mesmo formato pode vir de hardware fortemente isolado ou de uma aplicação com proteção modesta. Sintaxe comum não iguala garantias.

Todo uso de EAT precisa de freshness. Nonce ou mecanismo equivalente combate replay. Ainda assim, o token pode ser novo e carregar uma medição obtida no boot. Amostragem, emissão e boot epoch precisam de registros separados.

A claim measres comunica comparação com valores esperados — sucesso, falha, não executada ou ausente — e não o resultado geral de um Verifier. Uma UI que chama measres=success de “dispositivo confiável” inventa um alcance.

O RFC 9783, sobre o PSA Attestation Token, mostra que uma política pode exigir valor exato, aceitar uma sequência de versões ou confiar num signatário. São escolhas distintas, não conclusões do token.

Appraisal e autorização pertencem a papéis diferentes

O RFC 9334 organiza a arquitetura RATS. O Attester produz Evidence. O Reference Value Provider fornece valores esperados. O Endorser sustenta determinadas capacidades. O Verifier aplica Appraisal Policy for Evidence e cria Attestation Results. O Relying Party decide quanto confiar e qual operação liberar.

Uma plataforma pode acumular papéis, mas não elimina as responsabilidades.

Reference Values têm fornecedor, versão, vigência e retirada. Quando uma vulnerabilidade é descoberta, o mesmo digest pode deixar de ser aceitável sem alteração no equipamento. Quem controla a referência e a política exerce poder remoto sobre a frota.

O Verifier traduz Evidence específica de fornecedor. Essa conveniência concentra confiança; o resultado deve manter identidade do Verifier, versão da política, força e frescor da evidência.

Saúde não é direito. O RFC 9334 observa que uma empresa pode reconhecer equipamentos saudáveis de um fabricante e aceitar na rede apenas os que ela possui. Um aparelho legítimo de terceiro continua sendo de terceiro.

O Relying Party conhece recurso, operação, cadastro, propriedade, conta e impacto. O Attestation Result é insumo, não ordem.

A investigação precisa de todas as setas

A sequência mínima é:

fronteira → coletor e tempo → valor → nome e versão → sentido das authorities → signatário e freshness do EAT → perfil → Reference Value → política e resultado do Verifier → política do Relying Party → permissão → efeito observado.

Um booleano não guarda essa história.

Após um incidente, é necessário separar omissão de coleta, referência obsoleta, erro de appraisal e autorização excessiva. Sem estados intermediários, todas as equipes apontam para o mesmo selo verde.

A análise de Heng Lu sobre camadas de realidade e poder simbólico impede essa inversão. Nome, digest, autoridade e resultado representam uma parte escolhida da realidade em execução. O valor da prova depende de sua fronteira permanecer visível.

A evidência revela a frota

Nome e versão podem expor produto, patch e configuração; a estabilidade pode permitir rastreamento. Valores brutos revelam mais.

Se um consumidor descriptografa o EAT e passa subconjuntos para outros, perde-se a proteção original. O RFC 9711 exige proteção equivalente e recomenda minimizar a exposição.

A distinção entre controle formal e realidade prática da soberania de dados obriga mapear Verifier, logs, traces, analytics e suporte. O dono do hardware pode não controlar as cópias de sua configuração.

Cada consumidor deve receber apenas o necessário. O controle de acesso pode precisar do resultado com escopo, não do blob bruto; a remediação pode precisar da versão, não de uma identidade durável.

A modéstia do padrão preserva responsabilidade

O RFC 10013 define objeto, JSON/CBOR, semântica de perfil, digest forte, rejeição quando o perfil é desconhecido e alertas de privacidade. Ele não declara o dispositivo seguro.

O coletor responde pelo recorte. O Attester pela Evidence. O signatário pela procedência do componente. O Reference Value Provider pelo estado esperado. O Verifier pela avaliação. O Relying Party pela autorização.

Reconhecer o firmware inicia a decisão. Não entrega a decisão pronta.