NTS : une ligne de chrony pour une heure authentifiée

Ce qui se passe

Meta ouvre son service de temps public en NTS (Network Time Security, RFC 8915) sur nts.meta.com. Les réponses y sont authentifiées : un client vérifie qu'elles viennent de Meta et n'ont pas été modifiées en route. Serveur, client et implémentation du protocole sont publiés dans facebook/time.

Pourquoi l'heure devient un sujet de sécurité

NTP n'a jamais été authentifié : 48 octets partent, 48 reviennent, et le client les croit. Or c'est l'horloge locale qui tranche la validité d'un certificat (notBefore, notAfter), l'expiration d'un jeton, une fenêtre anti-rejeu ou l'ordre de deux lignes de journal.

Un attaquant sur le chemin qui recule l'horloge rend vie à des certificats expirés et à des jetons révoqués. S'il l'avance, tout expire d'un coup, et un hôte qui émet des identifiants de courte durée les signe pour une période plus longue que prévu. Meta pousse le scénario jusqu'au bout : un appareil convaincu d'être en 2037, au-delà du débordement du compteur NTP de février 2036, n'a plus aucun certificat valide et ne peut même plus télécharger le correctif.

Le calendrier aggrave l'enjeu. Le vote SC-081v3 du CA/Browser Forum réduit la durée maximale des certificats TLS publics :

À 47 jours, le renouvellement devient mensuel et automatique, par ACME. Une horloge fausse ne lève alors aucun ticket : le renouvellement échoue ou part à contretemps, sans témoin.

Comment NTS fonctionne

1. Échange de clés (NTS-KE) : TLS 1.3 sur TCP 4460, ALPN ntske/1. Les deux côtés choisissent un algorithme AEAD et dérivent deux clés de la session TLS ; le serveur remet huit cookies et l'adresse du serveur NTP à utiliser. Cela n'a lieu qu'une fois.
2. NTP authentifié : du NTPv4 ordinaire sur UDP 123, plus des champs d'extension. Chaque requête porte un identifiant unique, un cookie et un authentificateur ; la réponse renvoie l'identifiant et des cookies neufs, chiffrés.

Un paquet forgé est jeté sans message d'erreur, un paquet rejoué ne correspond à aucune requête en cours, et comme les cookies changent à chaque échange, un observateur ne peut pas suivre un client d'un réseau à l'autre.

Chez Meta, les serveurs ne gardent aucun état : la clé qui scelle les cookies est dérivée (HKDF-SHA256) d'un secret maître et du numéro de jour depuis l'epoch Unix. N'importe quel serveur ouvre donc un cookie scellé par un autre, sans clés à répliquer.

La configuration

Une ligne dans la configuration de chrony :

pool nts.meta.com nts iburst maxsources 5

nts.meta.com ne fait que l'échange de clés et renvoie vers les serveurs time.meta.com. D'où pool plutôt que server : chaque membre du pool mène son propre échange et obtient ses propres clés, soit cinq sources authentifiées indépendantes, qui apparaissent en une vingtaine de minutes. Pour contrôler :

chronyc authdata

Mode NTS, colonne NAK à 0 et Cook à 8 : tout va bien.

Ce que NTS ne règle pas

• Le retard : retenir vos paquets décale l'horloge jusqu'à la moitié du délai ajouté, sans que rien ne le détecte. D'où l'intérêt de plusieurs sources.
• Le démarrage : l'échange TLS suppose déjà une heure à peu près juste.
• Le serveur qui se trompe : NTS authentifie la provenance, pas l'exactitude.
• Les retours en arrière : l'heure murale recule parfois (seconde intercalaire, correction). Pour mesurer une durée, une horloge monotone.

Côté adoption, chrony et ntpsec gèrent NTS, Cloudflare le sert sur time.cloudflare.com depuis 2019, et la liste publique compte quelques dizaines de serveurs, dont PTB, Netnod et time.nl. Les clients de temps intégrés à Android et aux appareils Apple, eux, ne le parlent pas.

Source : NTS: Authenticated Time at Meta, Engineering at Meta, 6 octobre 2026.