O texto cifrado chegou à chave. Não nomeou quem o enviou: RFC 9180 e a autoridade ausente no modo Base do HPKE

Resumo

• O modo Base do HPKE estabelece confidencialidade para quem possui a chave privada KEM do destinatário. Um Open() bem-sucedido não identifica, por si só, a parte remota.
• PSK, Auth e AuthPSK acrescentam prova limitada de posse de segredo ou chave configurada. Não escolhem uma identidade empresarial, não definem uma mensagem completa e não aprovam uma ação.
• A operação segura começa com a distribuição da chave e termina com evidência de política e efeito; o resultado criptográfico fica no meio dessa cadeia, não no fim.

Há um erro de arquitetura escondido em muitas integrações: chamar a função que abre o texto e, na linha seguinte, tratar o objeto resultante como uma ordem confiável. O software parece simples. Recebe enc, ciphertext, uma chave privada e contexto; devolve plaintext. A tentação é fazer do retorno uma decisão.

RFC 9180 não autoriza essa promoção. Hybrid Public Key Encryption padroniza a combinação de um KEM, um KDF e um AEAD. Ela cria um contexto no qual o emissor sela conteúdo e o destinatário o abre. É uma camada comum importante justamente porque não tenta ser diretório de identidades, protocolo de transporte, motor de autorização nem registro de execução.

No modo Base, o limite fica visível. Quem tem a chave pública do destinatário pode cifrar para ela. O titular da chave privada correspondente pode recuperar o segredo compartilhado, reconstruir o contexto e tentar abrir o conteúdo. A propriedade resolve a confidencialidade para o destinatário. Ela não prova que o autor era o cliente, o parceiro, a equipe ou a pessoa cujo nome aparece no plaintext.

É possível que cada byte esteja criptograficamente correto e que a decisão de negócio seja completamente errada. Uma mensagem pode estar associada a uma chave válida, trazer um identificador de cliente íntegro e ainda ser enviada pelo processo errado, repetida fora de prazo ou dirigida a uma operação para a qual aquela identidade nunca recebeu poder.

Três primitivas não são uma constituição

Uma ciphersuite HPKE combina mecanismos distintos. O KEM cuida da encapsulação e da decapsulação do segredo; o KDF deriva material do contexto; o AEAD protege plaintext e dados associados. Essa divisão torna explícito qual algoritmo trabalha em cada etapa e permite implementações diferentes chegarem ao mesmo resultado.

Em Base, a preparação do emissor usa a chave pública receptora pkR e info, fornecido pela aplicação. A preparação do receptor usa a encapsulação recebida enc, a sua chave privada skR e o mesmo contexto. Se tudo for compatível, o receptor obtém a capacidade de abrir a mensagem.

A afirmação verificável é estreita: determinado conteúdo foi aceito sob determinada suite, determinado contexto e determinada chave receptora. A tabela de propriedades de RFC 9180 não atribui autenticação de emissor ao modo Base. Esse vazio não é um detalhe de implementação. Uma parte não reconhecida que tenha acesso à chave pública também pode produzir um ciphertext Base para esse destinatário.

Pense numa chave publicada para receber atualizações confidenciais. Ela pode estar visível a muitos componentes: agentes de monitoramento, pipelines, ferramentas de suporte e possíveis observadores externos. HPKE não distingue qual desses componentes tinha autorização para pedir uma alteração de produção. A regra que faz essa separação pertence ao serviço receptor e à sua política de origem.

AAD não preenche o vazio. A aplicação pode incluir um número de contrato, uma rota, um locatário ou a versão do formato como dados autenticados. A alteração desses bytes fará a abertura falhar. Mas a biblioteca não determina se o número foi informado por alguém que podia usá-lo. Integridade sobre um campo escolhido não é comprovação de competência para fazer a declaração.

A posse reconhecida ainda precisa de um dono

Os modos adicionais existem para os casos em que confidencialidade não basta. Em PSK, o receptor pode confirmar que o emissor possuía o segredo compartilhado configurado. Em Auth, a garantia se liga à posse da chave privada KEM do emissor. AuthPSK reúne as duas formas.

Esse ganho é real, desde que o aprovisionamento também seja real. Ainda assim, a palavra correta é posse. Uma organização pode vincular a mesma chave a uma pessoa, conta de serviço, função coletiva, dispositivo ou fornecedor. Quem fez esse vínculo, quais mensagens ele cobre, quando expira e como é revogado são fatos administrativos e operacionais, não saídas do HPKE.

RFC 9180 diz que Auth e AuthPSK autenticam a chave do emissor, não qualquer outro identificador. Se um protocolo precisa ligar a mensagem a endereço, domínio ou identidade de negócio, deve incluir esse identificador em info. A aplicação tem, portanto, de definir o valor, preservar a versão e verificar o significado. Não é suficiente registrar uma string amigável ao lado da impressão digital da chave.

Há também a limitação de key-compromise impersonation indicada pelo RFC para as variantes DHKEM Auth/AuthPSK nas condições de comprometimento da chave receptora que ele descreve. Um evento Auth não deve ser arquivado como prova eterna de autoria humana ou autorização irrevogável. É uma garantia delimitada por materiais de chave, tempo e modelo de ameaça.

Essa diferença muda os painéis. auth=true pode significar que o teste de posse de chave passou. “Empresa X aprovou o pedido” exige outro conjunto de registros: a associação válida entre chave e Empresa X, o escopo dessa associação, a política que aceita aquele pedido e a decisão que o aprovou. Quando todos recebem o mesmo rótulo, o incidente perde seu responsável.

O envelope, a ordem e a semântica ficam do lado de fora

HPKE oferece info na montagem do contexto e AAD nas operações de Seal() e Open(). Há ainda contexto para a exportação de segredos. São instrumentos para amarrar informação de aplicação ao cálculo criptográfico, em escopos diferentes.

Eles não constituem uma mensagem de rede. RFC 9180 não especifica wire format para HPKE. A aplicação deve dizer sem ambiguidade onde estão enc, os ciphertexts, sua ordem quando há mais de um e os valores de info que não sejam implícitos. Se o receptor tiver várias chaves públicas, talvez seja necessário carregar também qual delas foi escolhida.

O formato externo é uma superfície de autoridade. Ele decide como o receptor divide campos, reconhece versão, escolhe modo e suite, reconstrói contexto e associa as peças a um pedido. Uma abertura correta não conserta um envelope ambíguo.

Depois da abertura, a semântica ainda é local. O mesmo plaintext pode ser telemetria, pedido de exclusão, aprovação condicional ou dado de teste. HPKE não fornece schema, regra de função, condição de negócio ou executor limitado. Antes de produzir efeito, o aplicativo deve validar a estrutura, reconhecer a origem dentro de seu próprio modelo, verificar revogação, prazo e repetição, aplicar a política e restringir a ação permitida.

Também não há frescor automático. Dentro de um contexto, apresentar mensagens na mesma ordem em que foram seladas fornece uma proteção limitada contra replay. Fora desse fluxo, RFC 9180 não oferece outra proteção de repetição. Sequência, janela de tempo, nonce, idempotência e reação a perda são escolhas que o protocolo de aplicação precisa assumir.

Uma mensagem aceitável ontem pode ser uma mensagem proibida hoje, mesmo que seu ciphertext continue perfeitamente válido. Confundir validade criptográfica com vigência de mandato deixa a política presa a um passado que ninguém pretendia renovar.

O que deve sobreviver à investigação

Na seleção da chave, guarde identificador do receptor, proprietário, propósito aceito, origem de distribuição, rotação e revogação. Uma chave pública existente é endereço para cifrar, não autorização universal para qualquer tipo de solicitante.

Na emissão, guarde modo, suite, fonte do PSK ou da chave emissora, info, AAD, formato e qualquer evidência de negociação. No recebimento, guarde referência segura a enc e ciphertext, a chave escolhida, o resultado de construir o contexto e o resultado de Open(). Esse último deve conservar seu significado próprio, sem substituir parser ou política.

Na interpretação, guarde tipo e versão da mensagem, identidade associada, estado de chave, decisão de ordem/replay, teste de prazo, política e motivo de aceitar ou recusar. Uma carga pode ser válida e ainda assim ser recusada corretamente por chave aposentada, escopo errado, sequência usada ou ação proibida.

No efeito, separe pedido, autorização, execução, observação independente e rollback. Uma autorização pode falhar ao executar. Uma execução pode causar um efeito diferente do esperado. O rastro útil é aquele que consegue voltar do efeito à regra que permitiu cada transição.

As chaves receptoras também exigem memória de longo prazo. RFC 9180 afirma que os ciphertexts não têm forward secrecy diante do comprometimento da chave receptora: a obtenção posterior do segredo de longo prazo pode abrir mensagens antigas enviadas a essa chave. Isso não descreve um incidente específico; orienta retenção, rotação, resposta a comprometimento e classificação de arquivo.