L'heure comme dépendance de sécurité

Éditorial

Certificats, Kerberos, jetons, journaux, codes à usage unique : presque tous les contrôles de sécurité supposent une horloge juste, et presque personne ne traite l'horloge comme un actif à protéger. Le temps est une dépendance critique au même titre que le DNS, et il se défend avec les mêmes réflexes : authentifier la source, ne jamais en croire une seule, mesurer l'écart.

Mis à jour le 25 septembre 2026~27 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

La dépendance qu’on oublie parce qu’elle ne se plaint jamais

Demandez à une équipe la liste de ses dépendances critiques. Elle vous citera l’annuaire, le DNS, le fournisseur d’identité, le stockage, le réseau, et, si elle a été récemment traumatisée, l’autorité de certification interne. Elle ne vous citera pas l’heure. L’heure n’est pas une dépendance. L’heure, c’est comme l’oxygène ou le stagiaire : on ne s’aperçoit de son existence que le jour où elle manque.

Ce n’est pas un oubli de débutant, c’est un effet de caractère. Une horloge système ne tombe pas en panne comme un serveur DNS. Elle ne renvoie pas d’erreur, elle ne cesse pas de répondre, elle ne sature pas. Elle renvoie une valeur, toujours plausible, à chaque appel, avec l’aplomb tranquille des gens qui se trompent de bonne foi. Le jour où cette valeur est fausse, rien ne l’indique, et le symptôme surgit ailleurs, sous un déguisement qui ne désigne jamais la cause : un certificat « pas encore valide », une authentification refusée, un jeton expiré avant d’avoir servi, une chronologie d’incident où l’effet précède la cause, ce qui ne se voit d’ordinaire qu’en physique quantique et dans les comptes rendus de comité de direction.

Faisons pourtant l’inventaire de ce qui, dans un système ordinaire, consulte l’heure pour décider entre « accepter » et « refuser » :

la validation des certificats X.509, qui compare l’instant présent aux bornes notBefore et notAfter ;
la vérification des signatures datées, dont celles du DNSSEC ;
Kerberos, qui refuse les échanges dont l’horodatage s’écarte trop de l’heure du contrôleur ;
les jetons d’accès, assertions et cookies de session signés, qui portent une date d’émission et une date d’expiration ;
les codes à usage unique fondés sur le temps ;
les protections contre le rejeu, qui reposent presque toujours sur une fenêtre temporelle ;
la corrélation des journaux, sans laquelle aucune enquête n’aboutit.

Chacun de ces mécanismes délègue une partie de sa décision à l’horloge locale, et aucun ne vérifie cette horloge. On a donc bâti un édifice de contrôles d’une rigueur admirable, dont chaque étage demande l’heure au concierge sans jamais lui demander ses papiers.

La thèse de cet éditorial tient en une ligne : l’heure doit être traitée comme le DNS a fini par l’être, après quelques décennies de déconvenues, c’est-à-dire comme un service d’infrastructure dont la compromission compromet tout ce qui s’y adosse. Authentifier la source. Ne jamais en croire une seule. Mesurer l’écart. Et savoir ce qu’on fait quand elle ment.

Ce que l’heure décide, mécanisme par mécanisme

Tous ces consommateurs ne réagissent pas de la même façon à une horloge fausse, et la direction de l’erreur change tout. Une horloge en avance est un fâcheux qui crie. Une horloge en retard est un complice qui se tait.

Les certificats

Un certificat X.509 porte deux dates, et le client vérifie que l’instant présent tombe entre les deux. Il n’y a, dans l’opération, aucune autre source de temps que l’horloge de la machine qui valide. Le notaire, en somme, vérifie la date de l’acte en consultant la montre du client.

Une horloge en retard fait accepter des certificats expirés. C’est le cas le plus grave, et il ne fait aucun bruit. Un certificat mort dont la clé a fuité redevient vivant aux yeux de la machine attardée ; et comme un certificat expiré n’a souvent plus besoin de figurer sur les listes de révocation, il ressuscite sans casier judiciaire. La révocation elle-même dépend du temps : une réponse OCSP ou une liste de révocation porte ses propres dates, et une machine en retard acceptera volontiers une réponse ancienne, antérieure à la révocation, comme on accepte un certificat de bonne conduite daté de la veille du crime.

Une horloge en avance fait refuser des certificats valides. C’est bruyant, donc moins dangereux en apparence, mais c’est un déni de service impeccable, doublé d’une œuvre d’éducation populaire : l’utilisateur apprend à cliquer sur « continuer quand même », leçon qu’il n’oubliera jamais et qu’il appliquera ensuite avec un zèle que rien ne viendra plus tempérer.

La tendance de fond resserre l’étau. Les durées de vie maximales des certificats publics raccourcissent, et le CA/Browser Forum a adopté un calendrier qui doit les ramener à quelques semaines d’ici la fin de la décennie (le calendrier exact a déjà évolué ; vérifiez-le sur les publications du Forum). C’est une bonne chose, pour des raisons exposées dans la page consacrée aux PKI. Mais on dit rarement la conséquence : plus la fenêtre de validité est courte, moins l’horloge a le droit de se tromper. Quelques heures de dérive passaient inaperçues sur un certificat d’un an. Sur un certificat de quelques jours, elles se remarquent. Sur les certificats de quelques heures qu’émettent certaines PKI internes, elles tiennent lieu de panne générale.

Kerberos

Kerberos a le mérite de la franchise : il écrit sa dépendance au temps dans sa conception. Les authentifiants échangés portent un horodatage que le serveur compare au sien, et au-delà d’un écart toléré (cinq minutes par défaut dans les implémentations courantes, Active Directory compris), l’échange est refusé. La raison est la protection contre le rejeu : le serveur ne se souvient des authentifiants déjà vus que sur cette fenêtre.

Tout administrateur a connu la machine qui ne s’authentifie plus sur le domaine parce que son horloge a pris quelques minutes de liberté. Moins nombreux sont ceux qui ont remarqué que la fenêtre de tolérance est aussi la fenêtre de rejeu. Élargir la tolérance pour faire taire les incidents, c’est allonger la durée pendant laquelle un authentifiant intercepté reste utilisable. C’est un réglage de sécurité déguisé en réglage de confort, ce qui est d’ailleurs la définition de la plupart des réglages de confort.

Dans un domaine Active Directory, la hiérarchie de temps est une chaîne de confiance : les membres se synchronisent sur les contrôleurs de domaine, qui se synchronisent sur le détenteur du rôle d’émulateur PDC du domaine racine de la forêt, qui doit lui-même s’adosser à une source externe fiable. Si ce dernier maillon est mal réglé, la forêt entière dérive de concert, dans une harmonie parfaite, et aucune alarme interne ne s’en émeut, puisque toutes les machines sont d’accord entre elles. L’unanimité n’a jamais été une preuve d’exactitude ; elle en est même, dans les assemblées comme dans les forêts, un indice assez faible. Quant aux mécanismes d’authentification hérités, ils ne dépendent pas de l’heure, et ce n’est pas un compliment : c’est une des raisons pour lesquelles ils se laissent rejouer avec tant de bonne grâce.

Les jetons à durée de vie

Un jeton d’accès ou une assertion d’authentification porte une date d’émission, une date d’expiration, parfois une date avant laquelle il ne doit pas être accepté. Ici l’erreur se loge entre deux horloges, celle de l’émetteur et celle du consommateur. Un fournisseur d’identité en avance de quelques minutes émet des jetons que les services en retard jugent pas encore nés.

La correction habituelle consiste à introduire une tolérance, que les bibliothèques appellent leeway ou clock skew, termes anglais qui ont l’avantage de ne pas dire « trou ». Sur un jeton de cinq minutes, cinq minutes de tolérance doublent sa durée de vie effective. Et comme l’expiration courte est souvent la seule forme de révocation disponible pour les jetons autoportants, la tolérance est très exactement la durée pendant laquelle la révocation ne s’applique pas.

Les codes à usage unique

Les codes à six chiffres qui changent toutes les trente secondes sont calculés à partir d’un secret partagé et du temps découpé en intervalles. Le serveur accepte le code courant et souvent ses voisins immédiats, pour absorber la dérive du téléphone et la lenteur du pouce. Une horloge serveur fausse invalide tous les codes. Une fenêtre élargie pour compenser une horloge instable multiplie les codes acceptés à un instant donné, ce qui arrange beaucoup la page d’hameçonnage qui relaie en temps réel le code qu’on vient de lui confier.

Les journaux

C’est le consommateur le plus patient et le plus impitoyable. Pendant l’exploitation, une horloge fausse ne gêne presque rien. C’est au moment de l’incident qu’on découvre que le pare-feu, le serveur web, le contrôleur de domaine et le poste compromis avaient chacun leur conception personnelle de l’heure, et qu’on ne reconstituera jamais l’ordre des événements.

La corrélation, qui est le métier central d’une plateforme d’observabilité, suppose un référentiel temporel commun. Une règle du type « connexion réussie dans les deux minutes suivant cinq échecs sur un autre hôte » n’a aucun sens si les deux hôtes ont trois minutes d’écart. Et l’échec est muet : la règle ne se déclenche pas, voilà tout. Une horloge fausse ne produit pas de faux positifs dans la détection, elle produit des faux négatifs, et ceux-là ne se voient jamais, ce qui leur assure une longue et paisible carrière.

Pire que l’écart constant, il y a le saut. Une machine qui corrige brutalement son heure produit des journaux où des événements postérieurs portent des dates antérieures. L’enquêteur qui trie par horodatage obtient une chronologie fausse, cohérente et convaincante, ce qui est la pire espèce de chronologie fausse. D’où la règle : sur un serveur, on corrige la fréquence progressivement, et l’on ne saute qu’au démarrage.

Comment une horloge se met à mentir

La défense dépend de la cause, et les causes sont de quatre familles, de la plus bête à la plus méchante. L’expérience du métier enseigne d’ailleurs que la bêtise est statistiquement la plus redoutable des deux.

La dérive

Un oscillateur à quartz d’ordinateur n’est pas un chronomètre de marine. Il dérive avec la température et l’âge, comme nous tous. Sans synchronisation, une machine gagne ou perd des secondes par jour. Il suffit d’une règle de pare-feu modifiée, d’un service arrêté lors d’une mise à jour, d’un conteneur déployé sans accès à la source, pour que la dérive reprenne ses droits, lentement, sans alarme, jusqu’au jour où elle franchit un seuil et où tout casse d’un coup, à une heure dont personne ne saura dire laquelle.

Le réveil sans montre

Beaucoup de machines démarrent sans connaître l’heure : cartes sans horloge temps réel sauvegardée par pile, équipements embarqués, et surtout machines virtuelles restaurées depuis un instantané. Ces dernières méritent qu’on s’y arrête. Elles reprennent exactement là où l’instantané les avait laissées, horloge, jetons en cache, tickets Kerberos et compteurs compris. Pendant les premières secondes, elles vivent dans le passé avec une assurance de revenant, et tout ce qui s’exécute avant la resynchronisation s’exécute sur des certitudes périmées.

L’œuf, la poule et le certificat

Le réveil sans montre révèle une circularité qui est, à mon sens, le point le plus élégant du sujet. Pour obtenir l’heure de façon sûre, il faut authentifier la source. Pour authentifier la source, on utilise TLS, donc des certificats. Pour valider un certificat, il faut l’heure. Même boucle avec le DNS : pour joindre un serveur de temps par son nom, il faut résoudre ce nom ; si le résolveur valide le DNSSEC, il vérifie des signatures datées ; et pour vérifier une date, il faut savoir quel jour on est.

Les logiciels sortent de la boucle comme on sort d’un dîner ennuyeux, par une porte dérobée : accepter une première synchronisation non authentifiée, ignorer les dates de validité pendant l’amorçage, partir d’une heure minimale plausible (la date de compilation, la dernière heure connue écrite sur disque), désigner les serveurs par adresse plutôt que par nom. Chacune de ces sorties est une fenêtre pendant laquelle la machine fait confiance sans vérifier. Elle est courte, et c’est souvent acceptable. Encore faut-il savoir laquelle a choisi le logiciel qu’on déploie, ce que la documentation dit parfois, en bas de page, en petits caractères, dans une langue étrangère.

Le mensonge délibéré

Reste l’attaquant. Le protocole NTP tel qu’il est déployé presque partout n’est pas authentifié : les paquets circulent en clair sur UDP, et quiconque se trouve sur le chemin peut répondre à la place du serveur légitime. Les mécanismes d’authentification historiques du protocole, à clés symétriques, existent ; ils sont peu déployés hors des environnements maîtrisés, la distribution de clés à l’échelle d’internet étant un sport que peu de gens pratiquent pour le plaisir.

Faire reculer une horloge rapporte beaucoup : un certificat expiré redevient acceptable, une réponse de révocation ancienne redevient crédible, un jeton périmé redevient rejouable. La faire avancer permet d’expirer prématurément des secrets, des caches ou des sessions. Et dans les deux cas, on brouille les journaux de la victime au moment précis où l’on agit, ce qui est d’une courtoisie rare envers les enquêteurs.

Le scénario suppose une position sur le chemin réseau, c’est-à-dire exactement la position qu’on prête à l’attaquant contre lequel on a déployé TLS partout. Un système qui chiffre tout mais laisse l’heure non authentifiée a verrouillé le coffre en laissant à l’adversaire le soin de régler la minuterie.

Ce qu’apporte NTS, et ce qu’il n’apporte pas

La réponse moderne au mensonge délibéré s’appelle NTS, pour Network Time Security. Normalisée à l’IETF en 2020, elle est prise en charge par plusieurs implémentations libres, dont chrony et NTPsec.

Elle fonctionne en deux temps. Une phase d’établissement de clés se déroule sur une connexion TLS, où le serveur s’authentifie par un certificat ordinaire ; le client en repart avec des clés et des « cookies » opaques. Les échanges de temps restent ensuite en NTP sur UDP, mais chaque paquet porte une authentification cryptographique, et le serveur n’a pas à mémoriser d’état par client, puisque les cookies le transportent pour lui. C’est ingénieux, et c’est assez rare dans ce métier pour qu’on le salue.

L’apport est net : un attaquant sur le chemin ne peut plus forger ni modifier une réponse de temps sans être détecté.

Les limites le sont tout autant, et on les lit moins souvent dans les présentations enthousiastes.

NTS n’empêche pas le retard. Un attaquant peut toujours retenir les paquets, ou retarder l’aller et pas le retour. NTP suppose des trajets symétriques ; une asymétrie fabriquée devient une erreur sur l’heure calculée. Cette erreur est bornée par la moitié du temps d’aller-retour mesuré, ce qui rend l’attaque bien moins puissante que la falsification pure, mais un client qui accepte des allers-retours interminables accepte d’autant plus d’erreur.

NTS n’empêche pas le silence. Bloquer les paquets reste possible. Le client ne recevra pas d’heure fausse ; il ne recevra pas d’heure du tout, et retournera à sa dérive comme on retourne à ses mauvaises habitudes.

NTS hérite de l’œuf et de la poule. La phase d’établissement passe par TLS, donc par un certificat, donc par l’heure. Une machine qui s’éveille avec une heure très fausse ne peut pas valider le serveur. Chaque implémentation a sa stratégie d’amorçage ; c’est le paragraphe de la documentation à lire en premier, et le dernier qu’on lit d’habitude.

NTS authentifie la source, pas l’exactitude. Il garantit que la réponse vient bien du serveur choisi. Si ce serveur a lui-même une heure fausse, NTS vous la transmettra avec une authentification irréprochable. Un menteur dont on a vérifié l’identité reste un menteur ; il est simplement mieux identifié.

C’est ce dernier point qui mène à la mesure suivante, laquelle n’a rien de cryptographique.

Plusieurs sources, et un vote

Les algorithmes de NTP ont été conçus dès l’origine pour interroger plusieurs serveurs et écarter ceux qui divergent. Avec une seule source, le client n’a aucun moyen de savoir qu’elle ment. Avec deux, il sait que l’une ment mais pas laquelle, situation qui rappelle certains débats télévisés. Il en faut au moins trois pour qu’un vote soit possible, et quatre pour survivre à la perte de l’une sans perdre le droit de vote.

La redondance ne vaut que si les sources sont indépendantes. Quatre serveurs derrière le même équilibreur, quatre noms qui aboutissent chez le même opérateur, quatre serveurs qui se synchronisent sur la même référence amont : c’est un chœur, pas un jury. L’indépendance se juge sur l’opérateur, sur le chemin réseau et sur la référence ultime.

NTS et le vote se complètent exactement. NTS empêche un tiers de se faire passer pour une source. Le vote empêche une source unique, même authentique, d’imposer son heure. Aucun des deux ne suffit seul.

Une configuration de départ

Voici, pour chrony, une configuration de principe. Les serveurs cités sont des exemples de fournisseurs publics qui annonçaient la prise en charge de NTS au moment de la rédaction ; vérifiez leur disponibilité, et préférez dans une organisation vos propres serveurs internes, eux-mêmes adossés à plusieurs références.

# /etc/chrony/chrony.conf (ou /etc/chrony.conf selon la distribution)
# Sources authentifiées par NTS, d'opérateurs distincts
server time.cloudflare.com iburst nts
server nts.netnod.se       iburst nts
server ptbtime1.ptb.de     iburst nts

# Refuser de se synchroniser sur moins de deux sources concordantes
minsources 2

# Saut autorisé au démarrage seulement : écart > 1 s, 3 premières mises à jour
makestep 1 3

# Conserver les cookies NTS entre deux redémarrages
ntsdumpdir /var/lib/chrony

# Recopier l'heure système dans l'horloge matérielle
rtcsync

minsources est un choix, pas une évidence : il rend la machine plus difficile à tromper et plus facile à priver d’heure. makestep limité au démarrage traduit la règle énoncée plus haut : pas de saut en fonctionnement, pas de chronologie en accordéon.

Ce qu’il faut regarder

Ces commandes sont en lecture seule.

# État de la synchronisation, écart estimé, strate
chronyc tracking

# Sources connues : retenue (*), candidates (+), rejetées (x, ?)
chronyc sources -v

# État de l'authentification NTS de chaque source
chronyc -N authdata

# Vue synthétique côté systemd
timedatectl status

Sous Windows, dans un domaine :

w32tm /query /status
w32tm /query /source
w32tm /stripchart /computer:<controleur-de-domaine> /samples:5 /dataonly

Mesurer la dérive plutôt que la supposer

Une horloge synchronisée hier ne garantit rien aujourd’hui, pas plus qu’un contrôle technique ne garantit l’absence d’accident. Le service peut s’être arrêté, le port peut être filtré, une source peut avoir disparu. La seule façon de savoir que l’heure est juste est de la mesurer en continu, et de préférence depuis l’extérieur de la machine, qui n’est pas le témoin le plus impartial de sa propre exactitude.

Trois indicateurs suffisent. L’état de synchronisation : un booléen exposé par tous les démons de temps, qui détecte la plupart des pannes ; une alerte sur « non synchronisé depuis plus d’une heure » couvre l’essentiel. L’écart estimé : il n’a pas à être nul, il a à être borné, et la borne dépend de ce que fait la machine. Le nombre de sources retenues : une machine qui n’en retient plus qu’une a perdu la faculté de détecter un mensonge. Elle reste synchronisée, son écart peut être superbe, et elle est devenue crédule. C’est l’indicateur que tout le monde oublie, et le plus instructif des trois.

À ces mesures internes s’ajoute la vérification croisée. Le collecteur de journaux reçoit des événements horodatés par la source et peut les comparer à son heure de réception ; un écart supérieur au délai habituel de transmission signale une horloge fausse sans rien demander à l’intéressée. Pour un constat ponctuel :

# Interroger une source sans toucher à l'horloge locale (chrony installé)
chronyd -Q 'server time.cloudflare.com iburst'

# Comparer grossièrement l'heure de plusieurs machines
for h in srv1 srv2 srv3; do printf '%s ' "$h"; ssh "$h" date -u +%s.%N; done

La seconde mesure inclut le délai de connexion ; elle suffit à repérer la machine qui a plusieurs secondes d’avance, ce qui est déjà trop pour corréler proprement.

Dernière règle, qui conditionne les autres : horodater les journaux en temps universel, dans un format ISO 8601 qui porte explicitement le décalage, à la milliseconde au moins. Les fuseaux horaires et le changement d’heure saisonnier, cette cérémonie biannuelle où une civilisation entière décide de se tromper d’une heure par décret, sont une source d’erreurs de corrélation aussi réelle que la dérive, et bien plus facile à éliminer. La page sur les services DNS, DHCP et NTP détaille les bases côté réseau.

Le serveur de temps, cible et arme

On a parlé de l’heure que reçoivent les clients. Reste celle que distribuent les serveurs.

Un serveur de temps interne est un actif critique. Toutes les machines qui s’y synchronisent héritent de son heure. Le compromettre, c’est pouvoir faire dériver tout le parc de concert, en bon ordre, sans qu’aucune comparaison interne ne s’en aperçoive. Il mérite le régime des actifs critiques : durcissement, administration restreinte, journalisation, et plusieurs références amont indépendantes, faute de quoi il n’est que le haut-parleur d’une source unique.

Un serveur de temps mal réglé est un amplificateur. NTP comportait des requêtes de supervision dont la réponse était bien plus volumineuse que la question ; associées à l’usurpation d’adresse source, elles ont nourri des attaques par amplification massives au cours des années 2010. Les implémentations actuelles les désactivent par défaut, mais un équipement ancien ou une configuration héritée peut encore les exposer. Un serveur de temps qui ne sert que le réseau interne n’a aucune raison de répondre à internet, et encore moins de lui raconter sa vie.

# chrony : ne servir l'heure qu'au réseau interne (exemple)
allow 192.0.2.0/24
# n'accepter les commandes de supervision que localement
cmdallow 127.0.0.1

Le chemin vers la source est un chemin de confiance. Centraliser la sortie vers quelques serveurs internes réduit la surface, permet d’authentifier le lien amont par NTS et rend la surveillance possible en un seul point. C’est l’architecture classique, et elle est classique pour de bonnes raisons, ce qui n’arrive pas à toutes les architectures classiques.

Pour ceux qui ne veulent dépendre d’aucune source réseau, il existe des récepteurs de temps par satellite ou par radio. Ils ne sont pas des oracles : le signal satellite civil n’est généralement pas authentifié, il se brouille, et il s’usurpe avec un émetteur local assez proche. Un tel récepteur est une source parmi d’autres, à faire voter avec des sources réseau authentifiées. La position connaît le même dilemme et la même parade : faire voter le GNSS avec une centrale inertielle, qui ment aussi, mais pas de la même façon. Certains systèmes de navigation déploient ou prévoient une authentification des messages pour le service civil ; leur état est à vérifier auprès des opérateurs.

Le meilleur argument contraire : on dramatise un risque de laboratoire

La position inverse est sérieuse, et elle mérite mieux qu’un haussement d’épaules.

Elle dit ceci. Les attaques sur l’heure sont rares. Les incidents réels liés au temps sont presque tous des pannes : une dérive, un service arrêté, une seconde intercalaire mal digérée (celle de 2012 a mis en difficulté bon nombre de serveurs Linux, dans une atmosphère de fin du monde miniature), une machine virtuelle restaurée. Presque aucun ne vient d’un adversaire qui aurait falsifié l’heure. Déployer NTS, multiplier les sources, monter une surveillance : c’est s’équiper contre les voleurs de montres dans un quartier où l’on meurt surtout de chutes dans l’escalier.

Elle ajoute que l’attaquant capable de falsifier l’heure a généralement mieux à faire. Sur le chemin réseau avec la capacité de modifier des paquets, il dispose d’attaques plus directes. Maître de la machine, il n’a plus besoin de l’heure.

Elle rappelle enfin que la complexité a un coût de sécurité propre. minsources 2 rend une machine incapable de se synchroniser si une source tombe ; NTS ajoute des certificats et une phase d’amorçage ; la surveillance ajoute des alertes que quelqu’un devra lire, ce qui n’est jamais garanti.

Je crois que cet argument a raison sur son premier point : la menace dominante sur l’heure est la panne, pas l’attaque. Mais j’en tire la conclusion inverse. Si la panne domine, la surveillance de la dérive et la redondance des sources sont justifiées par la panne seule, sans invoquer le moindre adversaire. Ce sont précisément les mesures qui détectent un service arrêté ou une source disparue. NTS vient en supplément, pour un coût marginal faible sur un client moderne, et il ferme un vecteur dont la principale qualité, du point de vue de l’attaquant, est de corrompre l’outil même qui sert à établir la preuve.

Sur le deuxième point : un vecteur de second ordre reste un vecteur, et le défenseur qui a fermé ceux de premier ordre doit s’attendre à voir emprunter les autres. C’est même à cela qu’on reconnaît qu’il a bien travaillé.

Sur le troisième, l’argument a raison, et c’est pourquoi je ne recommande pas le même régime partout. Un poste de travail vit très bien avec un client simple et une source fiable. Un contrôleur de domaine, un fournisseur d’identité, une autorité de certification, un collecteur de journaux ne le peuvent pas : ce sont les machines dont l’heure décide pour toutes les autres.

Ce que je ne sais pas

Je ne sais pas mesurer la fréquence réelle des attaques sur l’heure. Une attaque réussie sur l’horloge brouille, par construction, la preuve qu’on en aurait gardée. Elles sont peut-être aussi rares que le soutient l’argument contraire, ou simplement invisibles. Je n’ai aucun moyen honnête de trancher, et je me méfie de quiconque avance un chiffre.

Je ne connais pas l’état exact de la prise en charge de NTS dans chaque système. Les implémentations libres de référence la proposent ; les systèmes grand public et les équipements réseau suivent à leur rythme, lequel n’est pas toujours celui d’une espèce pressée. Avant de bâtir sur NTS, vérifiez ce que chaque composant du parc sait réellement faire.

Je ne sais pas ce que deviendront les secondes intercalaires. Les instances internationales de métrologie ont décidé d’en cesser l’insertion à un horizon d’environ une décennie, au profit d’un autre mode d’ajustement encore à préciser. Comment les logiciels traverseront la transition, je l’ignore, et j’ai l’âge de me souvenir que les transitions annoncées comme sans douleur sont celles dont on parle le plus longtemps après.

Je ne sais pas si les protocoles de temps vérifiable s’imposeront. Des propositions existent pour obtenir une heure approximative mais signée, vérifiable a posteriori par recoupement de plusieurs serveurs, précisément pour traiter l’amorçage. Certaines sont en cours de normalisation depuis des années. Je me garde d’en recommander une.

Je n’ai pas de seuil universel. Quelques millisecondes, une seconde, cinq minutes : la bonne tolérance dépend de ce que la machine décide. Je peux donner des ordres de grandeur. Quiconque donne une valeur sans connaître le système d’en face vend quelque chose.

Ce qui reste

L’heure est une dépendance de sécurité pour une raison d’une platitude désarmante : des mécanismes de sécurité la consultent pour décider. C’est rarement écrit, sans doute parce que c’est trop simple pour faire l’objet d’une offre commerciale.

Trois choses me semblent acquises. Que l’erreur d’horloge a une direction, et que la direction dangereuse est la plus discrète : une horloge en retard ne casse rien de visible, elle ressuscite ce qui aurait dû rester mort. Que chaque tolérance au décalage est un paramètre de sécurité, et qu’on ne l’élargit pas pour faire taire une panne sans ouvrir, du même geste, une fenêtre de rejeu. Et que l’authentification ne suffit pas sans la redondance, ni la redondance sans la mesure : NTS garantit qui parle, le vote garantit qu’on ne croit pas un orateur unique, la mesure garantit qu’on s’aperçoit du moment où tout le monde s’est tu.

Le reste est un inventaire ordinaire. Savoir quelles machines décident pour les autres. Savoir sur quoi elles se synchronisent, et combien de sources elles retiennent réellement ce matin. Savoir ce que fait chaque composant quand il s’éveille sans heure. Et inscrire enfin, au registre des dépendances critiques, la ligne qui y manquait : « le temps, fourni par… ».

Si vous ne savez pas comment la compléter, rassurez-vous : vos machines non plus.

🐝 Ce qui arrive si on s’en passe

Sans source authentifiée ni vote, un seul paquet de temps forgé suffit à faire reculer l’horloge d’un serveur de référence, et tout ce qui s’y synchronise recule avec lui, dans une parfaite concorde. Les certificats expirés redeviennent acceptables sur l’ensemble du parc au même instant. Le collecteur central, s’il puise son heure à la même source, perd du même coup sa capacité à repérer l’écart : l’heure de réception, censée servir de témoin indépendant, ment exactement comme celle des machines qu’elle devait contrôler. L’enquête s’appuie alors sur une chronologie cohérente, unanime et fausse, ce qui est la forme la plus convaincante de l’erreur.

🦫 Explication de la marmotte 🍫

De nombreux contrôles de sécurité consultent l’horloge de la machine pour décider d’accepter ou de refuser. Un certificat porte une date de début et une date de fin, et la machine vérifie que l’instant présent tombe entre les deux. Kerberos, le système d’authentification des domaines Windows, refuse les échanges dont l’heure s’écarte de plus de quelques minutes. Les jetons de connexion ont une date d’expiration, les codes à six chiffres changent toutes les trente secondes, et les protections contre la réutilisation d’un message reposent sur une fenêtre de temps. Les journaux, enfin, ne permettent de reconstituer un incident que si toutes les machines partagent la même heure.

Une horloge en retard fait accepter ce qui est expiré, sans bruit. Une horloge en avance fait refuser ce qui est valide, ce qui bloque le service. Chaque tolérance ajoutée pour absorber un décalage allonge aussi la période pendant laquelle un élément intercepté peut être réutilisé.

L’horloge peut se tromper pour plusieurs raisons : elle dérive si la synchronisation s’arrête, elle démarre fausse après la restauration d’une machine virtuelle, ou un attaquant placé sur le réseau falsifie les messages du protocole de temps, qui ne sont en général pas authentifiés. La défense combine trois mesures. Un protocole récent, NTS, pour sécurité du temps en réseau, authentifie le serveur de temps. Plusieurs sources indépendantes, au moins trois, votent pour écarter celle qui ment. Une surveillance continue mesure l’écart, l’état de synchronisation et le nombre de sources retenues.

Pages voisines

La citent

L'heure comme dépendance de sécurité

Elle cite

: les deux pages se citent l’une l’autre.

L'heure comme dépendance de sécurité

La dépendance qu’on oublie parce qu’elle ne se plaint jamais

Ce que l’heure décide, mécanisme par mécanisme

Les certificats

Kerberos

Les jetons à durée de vie

Les codes à usage unique

Les journaux

Comment une horloge se met à mentir

La dérive

Le réveil sans montre

L’œuf, la poule et le certificat

Le mensonge délibéré

Ce qu’apporte NTS, et ce qu’il n’apporte pas

Plusieurs sources, et un vote

Une configuration de départ

Ce qu’il faut regarder

Mesurer la dérive plutôt que la supposer

Le serveur de temps, cible et arme

Le meilleur argument contraire : on dramatise un risque de laboratoire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines