Authenticated Network Time Synchronization Benjamin Dowling, Queensland University of Technology; Douglas Stebila, McMaster University; Greg Zaverucha, Microsoft Research https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dowling This paper is included in the Proceedings of the 25th USENIX Security Symposium August 10–12, 2016 • Austin, TX ISBN 978-1-931971-32-4 Open access to the Proceedings of the 25th USENIX Security Symposium is sponsored by USENIX Authenticated Network Time Synchronization Benjamin Dowling Douglas Stebila Queensland University of Technology McMaster University [email protected] [email protected] Greg Zaverucha Microsoft Research [email protected] Abstract sends a single UDP packet to a server (the request), who responds with a single packet containing the time (the The Network Time Protocol (NTP) is used by many response). The response contains the time the request was network-connected devices to synchronize device time received by the server, as well as the time the response with remote servers. Many security features depend on the was sent, allowing the client to estimate the network delay device knowing the current time, for example in deciding and set their clock. If the network delay is symmetric, i.e., whether a certificate is still valid. Currently, most services the travel time of the request and response are equal, then implement NTP without authentication, and the authen- the protocol is perfectly accurate. Accuracy means that tication mechanisms available in the standard have not the client correctly synchronizes its clock with the server been formally analyzed, require a pre-shared key, or are (regardless of whether the server clock is accurate in the known to have cryptographic weaknesses. In this paper traditional sense, e.g., synchronized with UTC). we present an authenticated version of NTP, called ANTP, to protect against desynchronization attacks. To make The importance of accurate time for security. There ANTP suitable for large-scale deployments, it is designed are many examples of security mechanisms which (often to minimize server-side public key operations by infre- implicitly) rely on having an accurate clock: quently performing a key exchange using public key cryp- Certificate validation in TLS and other protocols. • tography, then relying solely on symmetric cryptography Validating a public key certificate requires confirm- for subsequent time synchronization requests; moreover, ing that the current time is within the certificate’s it does so without requiring server-side per-connection validity period. Performing validation with a slow state. Additionally, ANTP ensures that authentication or inaccurate clock may cause expired certificates to does not degrade accuracy of time synchronization. We be accepted as valid. A revoked certificate may also measured the performance of ANTP by implementing it validate if the clock is slow, since the relying party in OpenNTPD using OpenSSL. Compared to plain NTP, will not check for updated revocation information. ANTP’s symmetric crypto reduces the server throughput Ticket verification in Kerberos. In Kerberos, authen- • (connections/second) for time synchronization requests tication tickets have a validity period, and proper by a factor of only 1.6. We analyzed the security of ANTP verification requires an accurate clock to prevent using a novel provable security framework that involves authentication with an expired ticket. adversary control of time, and show that ANTP achieves HTTP Strict Transport Security (HSTS) policy du- secure time synchronization under standard cryptographic • ration. HSTS [10] allows website administrators to assumptions; our framework may also be used to analyze protect against downgrade attacks from HTTPS to other candidates for securing NTP. HTTP by sending a header to browsers indicating Keywords: time synchronization, Network Time Pro- that HTTPS must be used instead of HTTP. HSTS tocol (NTP), provable security, network security policies specify the duration of time that HTTPS must be used. If the browser’s clock jumps ahead, 1 Introduction the policy may expire re-allowing downgrade attacks. A related mechanism, HTTP Public Key Pinning [7] The Network Time Protocol (NTP) is one of the Internet’s also relies on accurate client time for security. oldest protocols, dating back to RFC 958 [15] published For clients who set their clocks using NTP, these se- in 1985. In the simplest NTP deployment, a client device curity mechanisms (and others) can be attacked by a USENIX Association 25th USENIX Security Symposium 823 network-level attacker who can intercept and modify NTP 1.1 Contributions traffic, such as a malicious wireless access point or an insider at an ISP. In practice, most NTP servers do not We present the ANTP protocol for authenticated network authenticate themselves to clients, so a network attacker time synchronization, along with results on its perfor- can intercept responses and set the timestamps arbitrarily. mance and security. ANTP protocol messages are trans- Even if the client sends requests to multiple servers, these ported in the extension fields of NTP messages. ANTP may all be intercepted by an upstream network device allows a server to authenticate itself to a client using pub- and modified to present a consistently incorrect time to lic key certificates and public key exchange, and provides a victim. Such an attack on HSTS was demonstrated by cryptographic assurance using symmetric cryptography Selvi [28], who provided a tool to advance the clock of that no modification of the packets has occurred in transit. victims in order to expire HSTS policies. Malhotra et Like other authenticated time synchronization protocols al. [12] present a variety of attacks that rely on NTP being using public keys [31], we assume an out-of-band method unauthenticated, further emphasizing the need for authen- for certificate validation exists, as certificate validation ticated time synchronization. (Confidentiality, however, requires an accurate clock. We follow the direction set is not a requirement for time synchronization, since all by the IETF Informational document “Security Require- time synchronization is public. Similarly, client-to-server ments of Time Protocols in Packet-Switched Networks” authentication is not a goal.) (RFC 7384) [20] to determine what cryptographic, com- putational, and storage properties ANTP should achieve. NTP security today. Early versions of NTP had no ANTP has three phases. In the negotiation phase, the standardized authentication method. NTPv3 added an client and server agree on which cryptographic algorithms authentication method using pre-shared key symmetric to use; this phase would be carried out quite infrequently, cryptography. An extension field in the NTP packet added on the order of monthly or less. In the key exchange a cryptographic checksum, computed over the packet. phase, the client and server use public key cryptography In NTPv3 negotiation of keys and algorithms must be to establish a symmetric key that the server will use to done out-of-band. For example, NIST offers a secure authenticate later time synchronization responses; this time server, and (symmetric) keys are transported from phase would also be carried out infrequently, say monthly. server to client by postal mail [21]. Establishing pre- In the time synchronization phase, the client sends a time shared symmetric keys with billions of client PCs and synchronization request, and the server replies with an other NTP-synchronizing devices would be impractical. NTP response that is symmetrically authenticated using NTPv4 introduced a public key authentication mechanism the key established in the key exchange phase; this may called Autokey which has not seen widespread adoption; be done frequently, perhaps daily or more often. No- and unfortunately, Autokey uses small 32-bit seeds that tably, the server need not keep per-client state: the server can be easily brute forced to then forge packets. A more offloads any such state to the client by encrypting and recent proposal is the Network Time Security (NTS) pro- authenticating it under a long-term symmetric key, and tocol [31], which we discuss in 2.3. § the client sends that ciphertext back to the server with Most NTP servers do not support NTP authentica- each subsequent request. tion, and NTP clients in desktop and laptop operating The time synchronization phase of ANTP can be run in systems will set their clocks based on unauthenticated a “no-cryptographic-latency” mode: here, the server sends NTP responses. On Linux and OS X, by default the two response packets, the first being the unauthenticated client either polls a server periodically, or creates an NTP NTP packet, and the second being the same NTP packet request when the network interface is established. In (with unchanged timestamps) along with the ANTP ex- both cases the system clock will be set to any time spec- tensions providing authentication. The client measures ified by the NTP response. On Windows, by default the roundtrip time based on the unauthenticated response, clients will synchronize their clock every nine hours (us- but does not update its clock until authenticating the re- ing time.microsoft.com), and ignore responses that sponse. In this way, no time synchronization inaccuracy is would change the clock by more than 15 hours. These two added by the time required to compute the authentication defaults reduce the opportunity for a man-in-the-middle