Resumo

  • A revisão 01 diz que o Initiator autentica o Responder depois de verificar message_4_KEM; o Responder só autentica o Initiator ao verificar message_5_KEM.
  • A mensagem 3 pode ter confidencialidade e integridade sem autenticar o Initiator. A chave final deve esperar autenticação mútua, integridade da transcrição, autenticidade das credenciais e prova de posse.

O atalho aparece no meio do handshake

Depois da terceira mensagem, uma tela operacional já teria material suficiente para pintar a sessão de verde. O KEM efêmero produziu um segredo. O Initiator validou uma credencial do Responder, encapsulou para a chave estática dele e enviou a própria credencial em ciphertext protegido. O Responder conseguiu decapsular e decifrar.

Esse comprovante chega cedo demais.

A revisão 01 de KEM-based Authentication for EDHOC, submetida em 28 de setembro de 2026, afirma que a chave usada na mensagem 3 não autentica o Initiator. O Responder ainda não enviou o MAC que o autenticará; o Initiator também não enviou o seu. O dono de uma chave KEM estática precisa primeiro receber uma encapsulação feita pelo peer para a chave pública correspondente antes de provar a posse da chave privada. É por isso que aparecem duas mensagens extras.

O Datatracker registra um Internet-Draft ativo do grupo LAKE, com estado IESG apenas I-D Exists. O texto pretende Standards Track, mas não é RFC, padrão aprovado nem evidência de implementação. A versão expira em 1º de abril de 2027 se não for atualizada ou avançar.

Há dois momentos de conclusão

A mensagem 1 carrega a chave pública KEM efêmera. O Responder encapsula para ela e devolve na mensagem 2 o ciphertext e seu identificador de credencial. Antes de revelar a própria credencial, o Initiator precisa recuperar, validar e aceitar a credencial do Responder conforme sua política local. O rascunho faz a distinção correta: uma credencial pode ser criptograficamente válida e ainda pertencer a uma parte não confiável ou não pretendida.

Na mensagem 3, o Initiator encapsula para a chave KEM estática do Responder e protege seus próprios dados de credencial. A decapsulação pelo Responder não fecha a identidade. message_4_KEM traz o MAC explícito do Responder. Só depois de verificá-lo o Initiator pode autenticar o peer e persistir PRK_out ou chaves de aplicação.

A direção oposta continua aberta. O Responder autentica o Initiator apenas ao verificar o MAC de message_5_KEM. O documento reconhece que um possível misbinding pode ficar invisível até essas duas verificações. Por isso EAD deve ser tratado como desprotegido e material de chave não deve ser persistido antes do fim.

Um único campo authenticated=true apagaria o intervalo em que uma ponta já confirmou o peer e a outra ainda não. Também transformaria posse de chave em resposta para perguntas que ela não resolve: a identidade atribuída, a política de confiança aplicada e a autorização concedida.

Pós-quântico não significa reutilizável

O key schedule mistura uma contribuição KEM efêmera com dois segredos ligados às chaves estáticas. Cada sessão precisa gerar encapsulações novas. ss_I, ss_R e os ciphertexts correspondentes não podem ser reutilizados. O KEM também deve ser IND-CCA2 e vincular criptograficamente o segredo à chave pública do destinatário, pois IND-CCA2 isoladamente não exclui reencapsulação e unknown key share.

RFC 9935 e FIPS 203 especificam ML-KEM, não a autoridade de uma organização. SP 800-227 orienta o uso seguro de KEM, e RFC 9528 continua sendo a base EDHOC. O novo rascunho propõe a transcrição, as credenciais e os pontos de confirmação do LAKE; não traz resultado de implantação, interoperabilidade ou desempenho.

A seção de segurança também exclui non-repudiation: há apenas prova implícita de participação. Um peer LAKE autenticado não recebe automaticamente permissão para mudar uma rota, instalar software, movimentar dinheiro ou operar um equipamento. O ledger precisa separar método e suite; validação local da credencial; estados das mensagens 2 a 5; verificações de MAC_2 e MAC_3; identificador de freshness sem segredos; transição que permite persistência; autorização; requisição e resposta protegidas; e efeito final.

A análise anterior do BTW sobre RFC 9668 tratou de outro limite: combinar a mensagem 3 do EDHOC com uma requisição OSCORE não prova execução da aplicação. Aqui o limite vem antes. Na proposta KEM, a mensagem 3 ainda não concluiu a autenticação.

Running-Code Primacy pede interrupções reais das mensagens 4 e 5, replay de encapsulações, troca de credenciais e observação do estado sobrevivente. Minimum Initial Specification sustenta um mínimo comum estreito — estados explícitos e freshness por sessão — sem tomar a política local. Reality Layers impede que posse, identidade confiável, autorização e efeito emprestem autoridade umas às outras.

Fontes