Resumo

  • A RFC 9973 coloca uma PSK externa e o segredo (EC)DHE no calendário de chaves do TLS 1.3, preservando a autenticação por certificado.
  • Um binder válido prova a coincidência do segredo selecionado neste handshake; não prova a procedência, a exclusividade de posse, o escopo permitido ou o resultado da aplicação.
  • A operação precisa reconciliar o ciclo do segredo com a negociação TLS, a validação do par, a decisão de negócio e a evidência de conclusão.

Uma empresa recebe sensores de três fabricantes. Cada unidade vem com chave pública e um segredo provisionado. O objetivo é fazer o primeiro ingresso na rede sem deixar o tráfego arquivado depender apenas do acordo assimétrico habitual. A implementação de RFC 9973 pode ser apropriada: tls_cert_with_extern_psk permite que uma PSK externa contribua, com o segredo (EC)DHE, para as chaves de sessão TLS 1.3, enquanto os certificados continuam a autenticar os pares.

O problema começa se o cadastro de compras declarar que a PSK “pertence ao dispositivo” e encerrar a discussão. O dispositivo não gera necessariamente a chave. Um processo fabril pode criá-la; um integrador pode injetá-la; uma plataforma de suporte pode restaurá-la; uma equipe de segurança pode rotacioná-la. A criptografia não apaga essas jurisdições práticas.

A extensão tem requisitos claros. O cliente a apresenta com key_share, supported_groups, psk_key_exchange_modes e pre_shared_key, sem early_data. No handshake inicial, usa-se psk_dhe_ke; as chaves listadas devem ser PSK externas, não PSK de retomada. O servidor só devolve a extensão se aceitar uma PSK oferecida e fizer autenticação por certificado. O registro da IANA atribui o tipo 33, mas não mede adoção nem confirma implementação.

O que o protocolo confirma — e o que ele deixa fora

O servidor escolhe uma identidade da lista do cliente. O binder, construído com HMAC e parte do transcript, permite verificar que ambos associam o mesmo valor ao item escolhido. Essa é uma confirmação de coerência de chave na sessão. Não é uma certidão de que a PSK veio de um gerador robusto, de que ninguém mais a conhece, de que não foi copiada para backup, ou de que o portador do certificado tem autorização para alterar um ativo.

Essa ausência não é lacuna acidental. RFC 9973 coloca geração, distribuição e gerenciamento das PSK externas fora do escopo, embora sua justificativa de confidencialidade de longo prazo dependa da confidencialidade, entropia e autenticidade da chave. A RFC 4086 ajuda a avaliar exigências de aleatoriedade; não valida a linha de produção de ninguém. Cabe à organização definir quem cria, transporta, lê, troca e destrói cada classe de segredo.

Também não se deve vender a composição como autenticação pós-quântica completa. Segundo a RFC, uma PSK forte pode preservar uma condição de confidencialidade se no futuro o (EC)DH for quebrado e o agressor não souber a PSK. A assinatura do certificado continua com sua própria exposição futura. A PSK externa não pode ser o único fundamento de autenticação. RFC 9958 delimita o debate, sem prometer comportamento de fornecedor.

Uso repetido amplia a área de risco. Uma PSK exclusiva de uma sessão e conhecida apenas por duas partes tem propriedades diferentes de uma PSK reutilizada ou compartilhada por um grupo. Identidades PSK viajam no ClientHello em texto claro e podem facilitar correlação. Rotação e Encrypted Client Hello são opções de mitigação; não respondem por si mesmas quem recebe uma nova identidade, qual serviço a aceita ou como se preserva atribuição forense.

Evidência que acompanha o segredo sem copiá-lo

Para cada classe de PSK, mantenha o propósito, método de criação ou derivação, população autorizada, versão e hash permitidos, rota de provisão, detentores, limite de reutilização, condição de rotação e prova de destruição. O log de auditoria não deve armazenar o segredo; deve permitir reconstruir sua guarda de forma segura.

No plano TLS, guarde o aceite da extensão, uma referência segura à identidade escolhida, psk_dhe_ke, o resultado da validação de certificado e o Finished ou alert. No plano de negócio, guarde outra trilha: qual política concedeu acesso, qual ação foi solicitada, qual regra de atualização ou replay valia, se houve commit e como o efeito foi verificado fora do canal. A evidência de um plano não substitui a do próximo.

Para Heng Lu, código em execução vale mais que uma intenção declarada. Aplicado a este caso, “suportamos RFC 9973” não é a resposta; a resposta é a sequência observada e atribuída. A diferença entre forma técnica e controle prático também impede que o nome do proprietário no inventário esconda quem ainda consegue exportar a PSK.

Fontes