Resumo

  • A arquitetura atual de Key Transparency admite que todas as solicitações e provas de um usuário sejam válidas enquanto outros usuários recebem uma visão incompatível. A consistência mantém o cliente em uma linha; sozinha, não mostra que existe outra.
  • A descoberta depende de uma comparação independente: auditor ou gestor que não coopere com o registro, acesso anônimo, ou troca entre pares. Cada desenho transfere confiança, informação, estado e obrigação operacional para atores diferentes.

O resultado verde pode pertencer a uma história isolada

A abertura é um cenário operacional construído, não o relato de uma invasão real. Ela separa duas perguntas que um botão de “verificado” costuma misturar. A resposta estende corretamente aquilo que este dispositivo já viu? E todos os dispositivos receberam a mesma história? A primeira cabe em um cálculo local. A segunda precisa de um encontro entre observações.

O draft-ietf-keytrans-architecture-09 trata dessa diferença sem rodeios. O Datatracker o classifica como Internet-Draft ativo. A revisão 09 foi publicada em 29 de junho de 2026 e o processo foi atualizado em 9 de julho. O grupo de trabalho o enviou para publicação; o estado no IESG é Publication Requested, sem data de telechat, e o status pretendido é Informational. Portanto, o texto não é um RFC aprovado nem uma especificação final.

O ponto de partida é uma autoridade que o conteúdo cifrado não elimina. Um serviço de comunicação pode proteger as mensagens de ponta a ponta e ainda controlar o diretório que associa cada identidade visível a uma chave pública. Se o operador trocar a chave da pessoa por uma chave que controla, a conexão continua cifrada, mas a identidade do destino foi alterada.

Key Transparency registra essas associações em um log append-only protegido por criptografia. Search devolve o valor de um rótulo e uma prova. Update acrescenta uma versão. Monitor verifica periodicamente se valores observados continuam representados e se o rótulo do usuário mudou sem seu conhecimento. O mecanismo comum torna a história verificável; não absorve a política inteira do aplicativo.

Um log malicioso ainda pode praticar equivocation: entrega um ramo a Marina e outro a Caio. Cada cliente exige que respostas futuras sejam consistentes com o checkpoint anterior. Assim, fica preso a uma visão linearizável e rejeitará uma resposta que contradiga sua memória. Isso impede que o fork seja apagado por uma junção conveniente. Também cria evidência persistente. Mas não faz um cliente saber o que o outro viu.

Detectar requer uma função que atravesse o isolamento

O documento apresenta três famílias de comparação: terceiro confiável, comunicação anônima com o log e comunicação entre pares. Todas acrescentam uma visão externa à sessão autenticada que poderia estar sendo segmentada.

Na auditoria por terceiro, um auditor acompanha o crescimento append-only e assina uma raiz recente. O serviço inclui essa assinatura nas respostas. A segurança depende de auditor e log não se associarem para assinar a mesma mentira. Há também atraso: a auditoria normalmente ocorre de forma assíncrona, e a assinatura pode ficar atrás da visão mais recente. O máximo tolerado é política configurada, com dono e consequência, não um valor universal da criptografia.

Na gestão por terceiro, o gestor armazena e opera a maior parte do log. O serviço mantém o controle de acesso e autentica a criação de novas versões. A separação reduz poder unilateral, mas o serviço precisa detectar forks enviados pelo gestor. Vários terceiros podem produzir assinatura de limiar, desde que pelo menos uma maioria seja exigida. Ainda assim, seleção, substituição e rotação desses participantes são decisões institucionais.

Contact Monitoring não usa uma testemunha institucional permanente. O proprietário confere regularmente seu rótulo. Quem consultou uma versão muito recente retorna depois para confirmar que ela não foi removida antes de o proprietário poder percebê-la. Para detectar forks, o aplicativo ainda deve executar comparação anônima ou entre pares. O custo muda para dispositivos, disponibilidade dos usuários e conectividade social.

Uma consulta anônima obtém uma raiz por um canal que não identifica quem pergunta e a compara com a raiz do canal autenticado. Um log que mantém vários ramos não sabe com segurança qual deles devolver. Repetição aumenta a probabilidade de exposição, desde que o anonimato seja efetivo e o caminho não seja bloqueado seletivamente.

O gossip entre pares pode levar poucos bytes por um canal fora de banda, até por QR code. O requisito difícil é que os encontros formem um grafo conectado. Se duas comunidades nunca cruzarem testemunhos, o log pode mantê-las em histórias diferentes. Padronizar o pacote não cria a relação humana necessária para transportá-lo.

Estado perdido transforma um cliente antigo em testemunha sem memória

O cliente detecta uma resposta incompatível porque guardou algo do passado. Se perde a última raiz, assinaturas externas ou obrigações pendentes, pode aceitar uma história de substituição sem ter um checkpoint para contestá-la.

A arquitetura dedica atenção explícita a essa perda. Em Contact Monitoring, versões recentes dentro da janela de monitoramento ou trechos pouco difundidos são especialmente sensíveis. Com auditoria externa, existe uma área de risco durante o atraso aceitável do auditor. Uma sessão web efêmera, troca de telefone, restauração incompleta ou reset provocado podem alterar a garantia sem tocar no verificador.

Recuperação de conta precisa declarar o que continua: última raiz aceita, tarefas Monitor pendentes, assinaturas de testemunhas, horários de comparação e identidade da configuração do log. Quando a continuidade não pode ser demonstrada, o serviço deve registrar a lacuna e aplicar uma política local de recuperação, em vez de chamar o dispositivo de novo e esquecer seu passado.

O tempo de descoberta depende de vários relógios: idade máxima de resposta, Reasonable Monitoring Window, frequência real do trabalho de fundo, cadência de consultas anônimas ou gossip, atraso do auditor e eficiência da detecção do gestor. O usuário pode ter de permanecer on-line por um período. A promessa de “detecção limitada no tempo” só é auditável quando cada limite aparece em telemetria e tem um responsável.

Por isso, taxa de aprovação de prova é insuficiente. Registre idade do checkpoint por dispositivo, idade da atestação, atraso de auditor, falhas de comparação, fila de Monitor, eventos de recuperação, respostas antigas rejeitadas e tempo entre evidência conflitante e decisão. Um painel verde pode ser exatamente o que uma população isolada vê.

O aplicativo continua decidindo acesso

Key Transparency não substitui transporte, login ou autorização. O serviço pode limitar pesquisas a contatos, aplicar rate limit, exigir autenticação e impedir alterações em rótulos de terceiros. O log dá evidência sobre a operação permitida; não concede o direito de executá-la.

Contact Monitoring traz uma obrigação que atravessa a revogação. Uma pessoa autorizada a consultar um rótulo ontem pode perder acesso hoje, mas ainda precisa executar Monitor para garantir que o valor visto ontem não foi ocultado. O rascunho exige que essa verificação continue permitida. Uma revogação que fecha tudo pode remover o caminho que detectaria o abuso.

As opções também expõem informações distintas. O auditor conhece quantidade, ordem e horário aproximado das mudanças, sem ver rótulos e valores em texto claro. O gestor costuma conhecer rótulos, valores, histórico e padrões de consulta. O canal anônimo precisa proteger metadados. A troca entre pares reduz um observador central, mas pode revelar encontros. Não há testemunha sem superfície de privacidade.

Um arranjo independente precisa, portanto, definir observação, retenção, correlação, conteúdo assinado, distribuição de chave, tolerância a atraso e substituição. A palavra “independente” não basta se a operação diária concentra todos os incentivos no mesmo lugar.

Migrar sem aposentar o ponto de comparação

Clientes devem estar preparados para vários logs porque mudar de log é uma recuperação recomendada após falha. Na migração gradual, o log antigo precisa continuar disponível até usuários que passam longos períodos desconectados concluírem o monitoramento. Desligá-lo antes retira deles a chance de descobrir certos comportamentos anteriores.

Na migração imediata, tamanho final e hash raiz do log antigo precisam chegar por um canal confiável. Todos devem fechar a história no mesmo checkpoint. Em federação, também deve haver política consistente para escolher qual entidade e qual log respondem por uma identidade. Uma resolução de autoridade divergente cria separação antes mesmo da prova.

A poda exige outra distinção. Dados serializados podem expirar ou ficar permanentemente inacessíveis, enquanto partes criptográficas ainda são necessárias para provar o estado restante. Exclusão de conteúdo e preservação de evidência devem ser coordenadas, não confundidas.

Evidência de fork não é comando automático

Quando duas visões verificáveis entram em conflito, o usuário pode produzir evidência não repudiável do mau comportamento. O aplicativo ainda decide a consequência: alertar, congelar a troca de chave, segurar mensagens, pedir confirmação fora de banda, isolar um aparelho ou manter serviço limitado durante a investigação.

Falso positivo, personificação e indisponibilidade custam coisas diferentes em cada contexto. O mecanismo compartilhado deve tornar o conflito observável e portátil. A decisão final deve permanecer com quem conhece o caso e suporta a perda, documentada de modo que possa ser revista e revertida.

Uma implantação não está provada porque um teste de laboratório validou a árvore. É preciso verificar se as comparações independentes realmente ocorrem, se o estado atravessa a recuperação cotidiana, se a migração preserva o log antigo e se a equipe sabe quem pode interromper a comunicação. Um log só é transparente quando suas testemunhas conseguem se encontrar.

Fontes