During our consulting and audit missions, we very often find that securing one of the foundations of any information system is neglected: the provision of reliable time.
The importance of time in computing
Without a reliable time, most computer systems will fail: password expiration, invalid SSL certificates (making Internet browsing almost impossible), desynchronization of computing and storage clusters, scheduled tasks launched at the wrong time or not at all, non-true management of backup and log retention...
The ANSSI's recommendations concerning computer time
In 2013, the ANSSI published safety recommendations for the implementation of a logging system [1] which obviously apply to Vital Importance Operators (VIOs) and Essential Service Operators (ESOs).
Recommendation No. 3 should be noted:
Equipment clocks must be synchronized to several internal time sources that are consistent with each other. These sources may themselves be synchronized on several reliable external sources, except for isolated networks. ...] it is important to adopt an adequate configuration logic in order to ensure temporal consistency of the logs at the level of the collection servers".
The NTP protocol is cited and it is thus noted that the notion of consistency is central, and that absolute precision is absent. On the other hand, the emphasis is placed on the reliability of external sources.
Weaknesses of NTP in its current use
Many operating systems rely on "pools" of NTP servers (e.g. pool.ntp.org or time.windows.com) published on the Internet. These are sources that are freely and conveniently available (often preconfigured at the operating system level) but whose reliability at transmission and reception is difficult to assess.
Indeed, as the system is often community-based [V], the identity of some owners of these sources is unknown or not established.
However, suppose there is a trusted source available on the Internet, is it possible to secure the transport of time? Actually, not really...
NTP is a protocol whose specifications are more than 10 years old: version n°4 was published in RFC 5905 in 2010 [Z]. Its security is very difficult to ensure: RFC 7634 [X] exhaustively details the attacks (packet manipulation and/or interception, spoofing, replay, denial of service attacks, distributed denial of service attacks, attacks on resources by useless cryptographic calculations, "rogue" grandmaster server, etc.). ), their prerequisites (attacker positioned internally, externally, or on the path) and their possible impacts: inaccuracy or time drift, denial of service.
For current implementations, good practices for securing the NTP flow are described in RFC 8633 [X] dated July 2019. The main security measure used is the authentication of messages through the use of a shared secret: a symmetric encryption key (MD5 traditionally, AES-128-CMAC more recently) to sign messages. This key is static and should be renewed periodically.
Unfortunately, there is no mechanism to manage the life cycle of this key (distribution, expiration). More precisely, the security extension to the NTP protocol named AutoKey [Y], which was designed to automate the renewal of authentication keys, has critical vulnerabilities and must be disabled [W].
NTS, a new extension that will better secure NTP
To overcome these flaws, a new additional mechanism is being approved by the IETF: "Network Time Security (NTS) extension for NTPv4" [U], in an RFC under revision n°28 at the time of writing these lines. As a first approximation, it is TLS 1.2+ which enables authentication and key exchanges to be carried out, then the "classic" NTPv4 flow is set up.
Experimental software implementations are being finalised and interoperability tests are carried out regularly. On Linux, for example, the NTPSec project [E] has "forked" the historical software component "ntpd" under the name "ntpsec" and offers packages [D] for most recent distributions (v1.1.8+ is required to use NTS). There is also the "chrony" software component [L] which supports NTS from its unstable version 4.0 [K]. If the binaries are to be updated, few modifications will be required to the existing NTP configuration files.
NTS time is available on publicly and freely accessible servers on the Internet, the best known being the American CDN Cloudflare service (nts.cloudflare.com:1234) and the Swedish Postal Service (operated by NetNod [F], which aims to comply with the European NIS Directive, nts.ntp.se:4443). Note the addition of the use of TCP and separate ports for TLS negotiation, whereas historically only UDP:123 was universally used.
Blue Trusty - Expert advice - Computer Time Security Vulnerabilities will remain
However, NTS will not solve all the problems in the case of partitioned networks -so without access to the Internet- or of criticality of the availability and authentication of the time service, a context well known by the OIV and OSE.
In this case, the best alternative remains to equip oneself with NTP "boxes" which recover time via radio waves (ideally via the "time signal" [G]) or by GPS (extra-European system, unless GALILEO [H] is explicitly used) and then distribute it locally over IP networks via NTP (possibly using the NTS extension). Radio waves and satellite signals are of course vulnerable, but require more substantial resources than a simple DDoS on an Internet access.
In the current context of the search for sovereignty, there are French companies [I] that design and manufacture solutions that combine hardware and software to achieve the highest level of security in the distribution of computer time.
Stéphane REYTAN
Managing Director - ITS Eugena - BlueTrusty
BlueTrusty is ITS Eugena's commercial brand dedicated to Cybersecurity.
References
[1] https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Journalisation_NoteTech.pdf
[V] https://manage.ntppool.org/manage
[Z] https://tools.ietf.org/html/rfc5905
[X] https://tools.ietf.org/html/rfc7384
[Y] https://tools.ietf.org/html/rfc5906
[W] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[J] https://tools.ietf.org/html/rfc8633
[U] https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-20
[D] https://repology.org/project/ntpsec/versions
[E] https://docs.ntpsec.org/latest/NTS-QuickStart.html
[F] https://www.netnod.se/about-netnod/netnod-history
[G]https://www.anfr.fr/gestion-des-frequences-sites/signal-horaire/quest-ce-que-le-signal-horaire/
[H] https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS#Galileo_System_Time_.28GST.29
[K] https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS
[L] https://chrony.tuxfamily.org/
[I] https://www.bodet-time.com/fr/renforcez-la-securite-de-votre-reseau.html
