Résumé

  • RFC 9523 définit Khronos comme un gardien NTP qui tire aléatoirement quelques serveurs d'un grand vivier, élimine les offsets extrêmes et peut reprendre la conduite de l'horloge.
  • Sa garantie porte sur une proportion bornée d'échantillons compromis ; elle ne démontre ni l'indépendance des opérateurs et des chemins, ni celle des logiciels et des références amont.
  • Une assertion de temps fiable doit joindre sept reçus : composition, indépendance, sélection, échantillons bruts, estimation, action sur l'horloge et référence extérieure.

Un comité de risque ne devrait pas commencer par la moyenne affichée. Il devrait demander la liste de ceux qui ont pu contribuer à cette moyenne.

Avec Khronos, quinze réponses peuvent être tirées d'un vivier de cinq cents serveurs. Les valeurs basses et hautes sont écartées, le groupe central satisfait les tests et l'écart reste inférieur au seuil d'intervention. Le calcul est conforme. Pourtant, plusieurs adresses peuvent dépendre du même opérateur, du même réseau, du même logiciel ou de la même horloge de référence. Ce scénario est une hypothèse de contrôle, pas un incident constaté.

RFC 9523 améliore fortement la résistance d'un client NTP. Il ne prétend pas certifier la généalogie de tout serveur découvert. Confondre ces deux fonctions reviendrait à transformer une preuve statistique locale en attestation de gouvernance globale.

Une mécanique précise, donc vérifiable

Khronos accompagne NTPv4 sans modifier le protocole sur le fil. En situation normale, il observe en arrière-plan et laisse le client NTP ordinaire discipliner l'horloge. Il calcule toutefois son propre offset. Lorsque celui-ci dépasse H, un seuil préétabli, Khronos considère qu'une attaque peut être en cours et prend la main sur l'horloge locale.

À chaque intervalle, il choisit uniformément m serveurs parmi n. La configuration illustrative du RFC retient m=15 et n=500. Le tirage doit employer un aléa sûr. Les absences de réponse sont retirées ; si l'effectif devient insuffisant, un nouveau tirage commence. Khronos retranche ensuite le tiers inférieur et le tiers supérieur des offsets. Le noyau restant doit respecter une limite de dispersion et une condition liée au déplacement cumulé depuis le sondage précédent. Après K échecs, le mode de panique est atteint.

Chaque étape peut produire une trace utile : population admissible, choix exact, délais, offsets, exclusions, noyau conservé, tests, nombre de nouveaux tirages et action finale. La qualité de Khronos tient aussi à cette possibilité de distinguer calcul, décision et effet.

Le « plus de vingt ans » dépend de ses prémisses

Le RFC indique que Khronos empêche le déplacement lorsque la part d'échantillons compromis demeure inférieure aux deux tiers. Il propose aussi un cas chiffré : un septième d'un vivier de 500 contrôlé par l'attaquant, quinze requêtes par intervalle et un déplacement supérieur à 100 ms conduisent à une attente de plus de vingt ans avant une réussite.

Ce résultat est une espérance conditionnelle. Il ne décrit pas automatiquement un déploiement réel. Pour l'appliquer, il faut savoir comment la fraction compromise a été estimée et si les membres considérés séparés échouent réellement séparément.

Cinq cents adresses ne signifient pas cinq cents autorités. Deux opérateurs peuvent utiliser le même hébergeur ; plusieurs réseaux peuvent suivre la même référence amont ; une diversité géographique peut conserver une monoculture logicielle. Le filtre voit des offsets. Il ne voit pas spontanément les contrats, les chaînes d'approvisionnement ni les dépendances de référence qui les ont produits.

La calibration appartient au périmètre de sécurité

La population locale est constituée par des requêtes DNS répétées vers des pools NTP. Le RFC recommande des pools généraux, plutôt qu'un choix limité à l'État ou à la région du client, et permet aussi des ajouts manuels ou d'autres services. Cette calibration est actualisée périodiquement.

Le tirage sécurisé commence donc après plusieurs décisions : noms interrogés, résolveur et chemin DNS, réponses retenues, doublons éliminés, durée de conservation et sources ajoutées manuellement. L'aléa protège le choix au sein de cette population ; il ne peut pas corriger une concentration déjà présente dans celle-ci.

Le premier reçu doit figer la calibration. Le deuxième doit documenter, lorsque c'est possible, opérateur, ASN, chemin, famille d'implémentation, hébergement et lignée de référence de chaque source. « Inconnu » est une observation honnête. « Indépendant parce que différent par son IP » ne l'est pas.

Le NTP Pool Project organise un service volontaire, avec des exigences de stabilité et de suivi. Ce service rend la découverte possible à grande échelle. Son appartenance n'est pas pour autant une certification de diversité administrative ou métrologique, et le projet ne la présente pas comme telle.

Une réponse authentique peut être fausse

NTS protège l'échange et complique l'action d'un intermédiaire. Il aide peu si le serveur lui-même est compromis, rappelle RFC 9523. Il ne résout pas davantage une erreur commune reçue d'une référence amont : un serveur peut signer loyalement une heure incorrecte.

Il faut donc séparer le reçu de canal—endpoint, authentification, requête et réponse—du reçu de référence—strate, identifiant utile, filiation connue et comparaison extérieure. L'identité du locuteur et la justesse de son horloge sont deux faits différents.

Sept reçus, une assertion bornée

Le reçu de composition décrit le vivier. Celui d'indépendance révèle les dépendances communes. Le reçu de sélection conserve le générateur, la provenance de sa graine, n, m et les membres choisis. Le reçu d'échantillon retient réponses et silences, délais, offsets, strate et état leap.

Le reçu d'estimation montre les tiers retranchés, le noyau restant, les tests et le résultat. Celui d'action consigne H, K, l'état passif, actif ou panique, et la correction appliquée. Enfin, une référence gouvernée séparément permet une comparaison avec sa propre incertitude.

Cette dernière ne devient pas un oracle. Elle empêche simplement le même écosystème de produire l'heure et d'être seul à certifier son exactitude. Selon la distinction de Heng Lu entre spécification minimale, code exécuté et réalité observée, le RFC fournit le mécanisme ; l'exploitation doit encore établir ce qu'il autorise à affirmer.

Limites des preuves disponibles

Le dossier ne contient ni recensement d'adoption, ni matrice fournisseurs, ni panne nommée, ni taux mondial mesuré. Le scénario de dépendance commune reste illustratif. Un franchissement de H indique une divergence ; sans autre preuve, il n'identifie pas uniquement une attaque. Une estimation acceptée signifie que les conditions de Khronos ont été satisfaites, pas que l'UTC a été démontré.

Sources