Resumo

  • Cada solicitação protegida por NTS contém exatamente um Unique Identifier produzido por um gerador aleatório criptograficamente seguro, com pelo menos 32 octetos; o servidor ecoa o mesmo valor.
  • O cliente só processa a resposta quando o valor corresponde a uma solicitação ainda pendente e o pacote é autenticado com a chave servidor-para-cliente daquela operação.
  • A prova detecta repetição e correlaciona uma troca; não é identidade estável de pessoa, conta ou dispositivo, não é o cookie NTS e não certifica a correção do horário.

Um comprovante válido apenas enquanto há pergunta

Duas respostas de tempo podem parecer legítimas. Uma acabou de ser criada para a consulta aberta; a outra foi gravada quando era válida e voltou à rede depois. A autenticação mostra uma propriedade essencial do pacote, mas, sozinha, não informa se ele responde à pergunta que o cliente ainda aguarda.

O RFC 8915 entrega ao cliente um comprovante de emissão própria. Toda solicitação protegida inclui exatamente um campo Unique Identifier. Seu corpo deve vir de um gerador de números aleatórios criptograficamente seguro e ter ao menos 32 octetos. Depois de validar a solicitação, o servidor inclui exatamente um campo equivalente na resposta e copia a sequência de octetos sem nenhuma mudança.

Na recepção, duas verificações formam uma única decisão. O identificador precisa corresponder a uma solicitação pendente, e o pacote deve ser autêntico sob a chave S2C associada a ela. A falha de qualquer uma obriga o descarte antes de processamento adicional. Uma resposta antiga, embora autêntica em seu contexto original, não pode ocupar a vaga de uma resposta atual.

O campo não é cifrado, mas é autenticado. Ele fica nos dados cuja integridade é coberta pelo AEAD, antes do autenticador, mesmo permanecendo legível. Um observador pode enxergar o valor; não pode trocá-lo e fabricar uma resposta válida sem a chave correspondente. Confidencialidade e integridade respondem a perguntas diferentes.

É nesse limite que o nome “único” funciona. O valor distingue, para o cliente, uma operação ainda aberta. Não é número de conta distribuído pelo servidor, não é credencial e não declara qual pessoa ou máquina originou o pacote. Seu valor probatório termina com a aceitação ou o vencimento da solicitação.

Por que o relógio não bastava como desafio

O NTP já possuía correlação. O RFC 5905 define o Origin Timestamp de 64 bits como o momento, no relógio do cliente, em que a solicitação partiu. A resposta devolve esse dado, e a comparação com o estado transmitido ajuda a detectar pacotes falsos, duplicados ou repetidos.

O RFC 8915 preserva essa função, mas explicita a limitação criptográfica. Sessenta e quatro bits formam um espaço menor e, conforme a implementação, muitos bits podem ser previsíveis. Um horário é útil para cronologia e cálculo de atraso; não é, por natureza, um valor imprevisível diante de um adversário.

O novo campo separa as tarefas. Seu corpo tem no mínimo 32 octetos e nasce de um gerador seguro, oferecendo imprevisibilidade e resistência a colisões mais apropriadas. O RFC 4086, porém, impede uma conclusão fácil: 256 bits de comprimento não garantem 256 bits de entropia. Uma sequência visualmente variada ainda pode sair de um estado inicial pequeno. Saúde do gerador e qualidade da semeadura pertencem à evidência.

O RFC 8915 também permite usar o campo sem NTS para ajudar a detectar falsificações de um atacante fora do caminho. No NTS, a alegação mais forte vem do par. O eco aleatório aponta para a solicitação aberta; a autenticação S2C aponta para o contexto criptográfico. Nenhum dos dois deve ser promovido, isoladamente, à prova inteira.

Três objetos, três responsabilidades

Primeiro, o NTS-KE usa TLS para autenticação inicial do servidor, negociação e extração de chaves. Depois a conexão TLS é encerrada. O identificador de uma solicitação NTP posterior não é certificado nem refaz aquela identidade.

Segundo, o cookie NTS carrega estado de associação opaco. O cliente devolve um cookie fornecido antes, e o servidor recupera o algoritmo AEAD e as chaves direcionais sem manter estado por cliente. Um texto anterior de Sofia Ren sobre Dieter Sibold acompanhou justamente esse estado depois do fim do TLS. O cookie recompõe o contexto; o Unique Identifier correlaciona uma resposta a uma solicitação pendente.

Terceiro, o autenticador protege o pacote. Na solicitação, cookie e identificador são autenticados e não cifrados. Na resposta, o identificador continua visível, enquanto os novos cookies ficam dentro da região cifrada e autenticada. Misturar esses objetos apaga escolhas distintas sobre sigilo e duração.

A separação também corrige uma leitura de privacidade. Um identificador permanente permitiria agregar atividade ao longo do tempo. Este deve ser novo e imprevisível a cada solicitação. Reutilização, colisões ou retenção indefinida em logs podem criar riscos, mas são desvios operacionais, não a identidade definida pelo padrão.

Resposta autêntica não é sinônimo de hora certa

A proteção contra repetição impede que uma velha resposta protegida satisfaça uma nova consulta. Não encerra todos os riscos de tempo falso. O RFC 7384 distingue repetição, alteração, falsificação, manipulação de atraso e ataque à fonte externa do relógio mestre. Um servidor pode produzir uma resposta atual e autêntica alimentada por uma fonte errada; o caminho também pode ter atraso manipulado.

Por isso o RFC 8633 trata seleção, diversidade e monitoramento de fontes como responsabilidades próprias. Com uma única fonte, seu erro chega diretamente ao cliente. O Unique Identifier diz “esta resposta protegida corresponde a esta solicitação pendente”. Para dizer se o tempo está correto, são necessários outros comprovantes.

Fontes