Resumo

  • O NTS identifica o serviço NTS-KE e autentica uma resposta NTP contra uma solicitação pendente. Ele não atesta a exatidão do relógio remoto, não elimina atraso assimétrico, não escolhe entre fontes discordantes nem autoriza um salto no relógio do sistema.
  • Uma decisão auditável exige quatro provas separadas: identidade e estabelecimento de chaves, aceitação do pacote, aptidão e seleção da fonte, disciplina e atuação no relógio. Um único selo “seguro” apaga justamente a cadeia de autoridade.

Duas respostas válidas não formam uma ordem

A abertura é um experimento construído, não um incidente real. As fontes A e B apresentam certificados válidos. As duas sessões NTS-KE terminam com sucesso. Cada serviço fornece cookies e material de chave. Depois, as respostas NTP são validadas com a chave no sentido servidor-cliente, repetem um identificador ainda pendente e não são replays. Mesmo assim, uma aponta correção quase nula e a outra, 800 milissegundos.

A divergência não exige quebra criptográfica. Uma fonte pode ter recebido hora ruim de montante; um caminho pode ter atraso assimétrico; a distância de sincronização pode exceder o limite local; ou os candidatos podem não formar a interseção majoritária esperada pelo algoritmo.

O cliente ainda precisa classificar a evidência. Pode escolher A, aceitar B com apoio de outras fontes, combinar um conjunto coerente ou permanecer sem sincronização. Não mover o relógio quando as provas não convergem é uma decisão válida.

A afirmação precisa do NTS

O RFC 8915 divide o NTS em dois protocolos. O NTS Key Establishment funciona sobre TLS. A transferência de tempo usa campos de extensão NTS em pacotes NTP cliente-servidor. Identidade e chaves são resolvidas primeiro; as trocas frequentes permanecem leves.

O NTS-KE usa TCP 4460, TLS 1.3 ou posterior e o identificador ALPN ntske/1. O servidor pode indicar o endpoint NTP, negociar o algoritmo autenticado e entregar cookies opacos. O exportador TLS deriva chaves diferentes para cliente-servidor e servidor-cliente. Fechada a conexão, o servidor não precisa manter estado por cliente.

O cliente devolve esse estado em um cookie, além de mandar um identificador único e um autenticador. A resposta aceitável deve ser validada pela chave servidor-cliente e corresponder a uma solicitação em aberto. Cookies novos podem voltar no campo protegido, renovando o estoque sem tornar as aparições sucessivas facilmente vinculáveis.

Isso prova uma proposição limitada: a resposta veio da parte associada às chaves NTS, não foi alterada e responde a um pedido real. Não prova que o oscilador, a referência de montante ou o UTC servido estejam corretos.

A IANA registra os tipos compartilhados de identificador, cookie, espaço reservado e autenticador com extensões criptografadas. O registro fixa a gramática interoperável; não certifica relógios.

Identidade não é exatidão

O certificado verifica a identidade do serviço NTS-KE, não a hora por trás dele. O cookie recupera parâmetros de autenticação, não a verdade temporal. O identificador liga pedido e resposta, mas não mede a simetria da rede.

O ataque de atraso descrito no RFC 8915 torna a fronteira clara. Um agente no caminho pode atrasar os sentidos de forma desigual sem modificar ou reordenar o conteúdo. Todas as verificações passam, enquanto o deslocamento calculado fica errado. A variável manipulada é o tempo de trânsito. Uma política de distância máxima limita a exposição; múltiplas fontes ou rotas melhoram a resistência se não compartilharem o mesmo controle.

A confidencialidade também é limitada. O cabeçalho NTP básico permanece aberto; o NTS pode criptografar campos de extensão. Disponibilidade é outra camada: pacotes podem ser descartados e algumas respostas Kiss-o’-Death não são autenticadas.

Por isso, a falha do NTS-KE não deve produzir retorno automático ao NTP sem proteção. Um atacante poderia provocar a falha e retirar a segurança. O rebaixamento precisa de ação local explícita.

O relógio de partida já contém política

Certificados X.509 têm período de validade. A máquina que procura hora porque não confia no próprio relógio ainda precisa de uma aproximação para verificar o serviço. Não há solução perfeita para toda implantação.

O RFC 8915 cita relógio com bateria, estimativa manual, último horário persistido e comparação de várias fontes. A resposta recebida logo após NTS-KE também deve ser compatível com a validade do certificado. São janelas de plausibilidade, não fontes exatas de UTC.

Antes do primeiro pacote autenticado, o operador já escolheu: quais raízes aceitar, quão antigo pode ser o estado salvo, quando uma exceção temporal é tolerável e quantas fontes devem concordar antes da correção. Se a organização não responde, os padrões do produto respondem por ela.

A seleção começa depois da autenticação

O RFC 5905 mantém uma cadeia local. O processamento gera medições; o filtro reduz ruído por associação; a seleção procura uma interseção apoiada pela maioria; o agrupamento remove extremos; a combinação produz o deslocamento final; e a disciplina controla fase e frequência do relógio.

O NTS fortalece a entrada, rejeitando falsificação e replay antes que virem medidas. Não substitui as etapas seguintes. Uma fonte autenticada pode ser falseticker. Uma medição válida pode exceder atraso ou distância. Sem candidatos suficientes, o sistema pode ficar não sincronizado.

A documentação atual do chrony mostra essa separação. authdata informa mecanismo de autenticação, estabelecimentos de chave, tentativas, respostas negativas e cookies. Outros relatórios mostram alcance, concordância e seleção. maxdelay e testes relacionados rejeitam atraso inadequado; minsources impede atualização até haver fontes selecionáveis suficientes; opções de confiança e exigência governam a participação de fontes autenticadas e abertas.

O NTPsec oferece controles próprios para certificados, cliente, servidor e persistência de chaves de cookie. A variedade marca a fronteira entre interoperabilidade comum e política operacional.

Quatro provas, não um selo

A prova de identidade registra nome NTS-KE, cadeia, identidade do serviço, conjunto de confiança e momento do estabelecimento.

A prova de pacote registra geração de chave, identificador, cookies, autenticador, solicitação correspondente e mudança de estado por replay ou resposta negativa.

A prova de medição registra deslocamento, atraso, dispersão, distância raiz, alcance, histórico, interseção e condição de fonte discordante. É aqui que uma resposta autêntica pode se tornar inútil.

A prova de atuação registra fonte ou combinação escolhida, limiar que permitiu ajuste gradual ou salto, processo responsável e estado anterior. É o registro da autoridade sobre a máquina.

Guardar apenas “NTS ativo” comprova o uso do mecanismo, não a razão do movimento do relógio.

Regra comum mínima, decisão local

A Minimum Initial Specification de Heng Lu limita a camada comum às regras determinísticas necessárias para interoperabilidade, segurança e validação local. Escolhas posteriores ficam com quem executa o código. Publicação não é adoção, e sintaxe comum não cria poder permanente.

Lido assim, o NTS é estreito e útil. A IETF define negociação, chaves, cookies e validação. A IANA registra números. A autoridade certificadora participa da identidade. Nenhuma delas escolhe as fontes do cliente, define sua distância máxima, julga o horário de partida ou autoriza a chamada de sistema que altera o relógio.

Running-Code Primacy acrescenta o teste prático: sistemas independentes devem implementar e verificar as mesmas propriedades localmente. O cliente pode aceitar o pacote e rejeitar a medição; confiar na identidade e negar o salto. Essa separação é parte da segurança.

Fontes e escopo

Os 800 milissegundos são ilustrativos e não representam fornecedor, defeito, incidente ou ataque. Fontes congeladas: