Resumo

  • RFC 10042 especifica três métodos híbridos ML-KEM/ECDH para a camada de transporte SSH e deriva um segredo a partir de dois componentes efêmeros.
  • A assinatura da chave de host participa da autenticação do transporte, mas a escolha de confiar naquela chave e as decisões sobre o usuário permanecem locais e separadas.

O ponto de partida não é uma senha, nem uma conta: é um segredo de sessão. RFC 10042 faz o cliente enviar SSH_MSG_KEX_HYBRID_INIT com C_INIT, que concatena uma chave pública ML-KEM e uma chave pública clássica. A resposta contém SSH_MSG_KEX_HYBRID_REPLY, a chave pública de host K_S, S_REPLY com um ciphertext ML-KEM e uma chave pública clássica do servidor, e a assinatura do hash de troca. O par produz K_PQ e K_CL; o RFC determina a codificação fixa e o hash que formam K.

Essa sequência é deliberadamente disciplinada. O servidor deve verificar o comprimento de C_INIT antes de encapsular. O cliente deve verificar S_REPLY antes de desencapsular. Uma falha de comprimento ou de decapsulação exige desconexão por falha de troca de chaves. A cada conexão, novos pares efêmeros ECDH e ML-KEM devem ser gerados, e a aleatoriedade do ciphertext ML-KEM não pode ser reutilizada. A codificação de comprimento fixo evita que a forma do segredo revele um sinal temporal desnecessário.

Nada disso escolhe o host certo. A resposta inclui K_S e uma assinatura sobre um hash que também inclui identificação de cliente e servidor, ambos os KEXINIT, C_INIT, S_REPLY e K. Isso vincula a troca a uma chave de host apresentada. Para que ela seja a chave do host pretendido, porém, o cliente precisa de uma base anterior. RFC 4251 descreve uma associação local entre nome de host e chave pública ou uma associação certificada por uma CA aceita. RFC 4253 manda o cliente verificar K_S por certificado ou banco local e alerta que aceitar sem verificação mantém vulnerabilidade a ataque ativo.

O detalhe é importante para quem audita automação. Uma linha dizendo “ML-KEM habilitado” prova somente uma configuração. Uma lista KEXINIT pode provar uma oferta. Uma captura completa pode demonstrar que um método comum foi selecionado e que os controles previstos foram concluídos. Já a confiança na chave depende do registro local ou da cadeia de certificação efetivamente aplicada. E a autenticação do usuário vem depois da camada de transporte: a arquitetura SSH reserva ao servidor e à sua política local a escolha dos métodos aceitos para cada usuário e do acesso permitido.

Os nomes registrados deixam a separação legível. mlkem768nistp256-sha256, mlkem1024nistp384-sha384 e mlkem768x25519-sha256 definem famílias de troca; não descrevem um host, um usuário ou um privilégio. Os números de mensagem de troca de chave ocupam uma faixa específica, enquanto os SSH_MSG_USERAUTH_* ocupam outra. Tratar ambos como uma mesma evidência destrói a capacidade de investigar onde uma conexão deixou de ser apenas criptográfica e passou a ser uma decisão de acesso.

RFC 10042 tampouco promete que qualquer implementação, rede ou organização use esses métodos. Ele define um mecanismo e seus limites: nomes, mensagens, tamanhos, derivação e tratamento de erro. O princípio editorial de Heng Lu é útil aqui apenas como disciplina: um mecanismo comum pode ser exato sem centralizar a decisão posterior. A evidência operacional precisa acompanhar essa arquitetura, não apagá-la.