O que seu cliente verifica antes de enviar os dados dele

"A gente roda num TEE" é uma afirmação. Do outro lado da mesa existe alguém cujo trabalho é transformar afirmações em verificações, e essa pessoa vai fazer três perguntas: que código está rodando, quem garante isso, e o que esse código faz com os meus dados?

A boa notícia é que as três têm resposta mecânica. O trabalho é publicar essas respostas antes da reunião, e não durante.

A lista que eles executam§

1. Buscar a identidade. Um serviço atestado publica GET /.well-known/attestation: o documento assinado pela plataforma, a chave pública, o hash do programa e o hash da configuração sob a qual ele roda.

2. Verificar o documento. Assinatura, cadeia de certificados até a raiz da plataforma, janela de validade — falhando fechado na primeira dúvida. Com Synsema no cliente isso é uma chamada, com o relógio passado explicitamente em vez de lido do host:

let v be attestation_verify(bytes(seen["document"], "base64"),
    {"format": seen["format"], "now": floor(now()),
     "expect": {"measurements": {"pcr0": PINNED}}})

3. Recalcular a amarração. O documento se compromete com sha256(chave_pública ‖ program_sha ‖ config_sha). Um documento que verifica mas amarra outra chave ou outro programa não vale nada; uma chave que bate mas não tem documento é só uma chave. A ordem importa: verificar, recalcular, comparar e só então enviar.

4. Ler a configuração. config carrega o teto sob o qual o programa rodou, se os rótulos de fluxo de informação estavam ligados, o perfil, e se a chave anunciada é a que termina o TLS. O hash dela está dentro do payload assinado, então não dá para atestar uma configuração endurecida e servir uma frouxa.

5. Perguntar o que sai. Esta é a pergunta que o hardware não responde, e a que decide o negócio. synsema code check --json lista cada declassify do programa com a linha e a frase que quem escreveu registrou:

"declassify": [
  {"line": 11, "reason": "the yes/no is what the lender asked for; the score stays inside"}
]

Uma entrada, uma frase, aplicada em tempo de execução: todo o resto que for privado é recusado na resposta, no log e no arquivo — antes de o efeito acontecer.

O que o seu lado publica§

Coloque estas quatro coisas onde um desconhecido consiga achar sem te perguntar:

• O program_sha da versão, e a medição esperada da plataforma (PCR0 no Nitro, MRTD/RTMRs no TDX, measurement no SEV-SNP) tirada da própria etapa de build da plataforma.
• A procedência do motor. gh attestation verify synsema-linux-x86_64 --repo kitecosmic/synsema responde com o workflow, o commit e a tag que produziram exatamente aqueles bytes. Atestar um programa executado por um interpretador de origem desconhecida atesta a metade errada, e um bom revisor sabe disso.
• A lista de desclassificações da versão que você está rodando, em palavras.
• Um verificador que eles possam rodar — vinte linhas, sem SDK, sem conta.

Uma página com essas quatro coisas vale mais numa conversa de compras do que qualquer quantidade de prosa sobre isolamento por hardware.

Os limites — diga você primeiro§

Marcar a fronteira você mesmo é o que separa uma afirmação de engenharia de uma de marketing, e quem revisa percebe:

• Uma atestação prova que código roda, não que o código é bom. É exatamente por isso que a lista de desclassificações fica ao lado.
• Ela não impede o operador de recusar o serviço, descartar uma requisição ou desligar a máquina. Confidencialidade e disponibilidade são propriedades diferentes.
• Canais laterais não são cobertos por uma assinatura. Tempo, tamanhos e a quantidade de linhas que um programa imprime vazam, e por isso a linguagem trata um print dentro de um ramo que dependeu de dados privados como violação em vez de redigir o valor — mas ninguém deveria afirmar que a classe está fechada.
• O suporte de verificação varia por plataforma. Hoje o Synsema verifica documentos do Nitro contra a raiz da AWS fixada; quotes de TDX e SEV-SNP são produzidos pelo motor e verificados com o material do fabricante no lado do cliente. Diga à contraparte qual dos dois ela está recebendo.

Quem pede isso§

O padrão se repete em setores que não se parecem em nada:

• Salas limpas de dados — duas empresas cruzam suas listas de clientes e cada uma vê só a interseção.
• IA confidencial — um hospital roda o modelo de um terceiro sobre prontuários que o fornecedor não pode reter, e os pesos do fornecedor também continuam ilegíveis.
• Custódia e assinatura — uma chave que pode ser usada e nunca exportada, com cada uso registrado.
• Matching privado — ordens casadas sem que ninguém veja o livro antes do casamento.

São a mesma arquitetura: um programa pequeno, dados que ninguém de fora pode ler, e um valor que sai com um motivo anexado.

Por onde começar§

Construa primeiro a versão pequena: uma rota, uma decisão, os rótulos ligados, um documento de identidade e o verificador nas mãos de um cliente amigo. Todo o resto — o site, o cadastro, o dashboard, os jobs, a cobrança — é trabalho de produto comum que fica fora da caixa, e é implantado aqui com um comando.

A referência do lado do motor é Atestação e Rótulos de fluxo de informação.