Cillian O'Driscoll, Independent Consultant, Ireland; Shane Keating, Independent Consultant, Ireland; Gianluca Caparra, European Space Agency, Netherlands

View Abstract Sign in for premium content

Abstract:

A GNSS is fundamentally a time transfer system, with each satellite transferring its local time reference to the receiver. As interest grows in securing GNSS against malicious attacks it has become apparent that one-way time transfer is fundamentally insecure, and that secure clock synchronization requires a two-way time transfer mechanism [1]. Several proposals have been made for protecting GNSS from spoofing attacks, including the definition of ad-hoc protocols and signals. In this work, we focus on Chimera [2], which aims at protecting GPS L1C by means of replacing a fraction of the spreading code with an unpredictable sequence derived from a stream cypher. The key used for generating the modified spreading code is disclosed a posteriori. The receivers while tracking L1C also buffer digital samples of the RF signal and when the key is released, it can verify the presence of the correct spreading code. A disclosed key can be used not only for the verification, but also for the forging of a spoofing signal that will pass the verification check. For this reason, it is important that the receiver have a rough knowledge of the time, in order to process only signals where the applicable key have not been disclosed yet. Chimera set this rough time synchronization requirement as 1.5 minutes for the slow channel and within about 0.75 seconds or 3 seconds for the fast channel depending on the configuration. To achieve this goal we can consider either updating the GNSS systems to include a two-way communications component (a return link to the system from the user) or try to take advantage of existing wireless communications networks and protocols. In this work we investigate the current state of the art for the latter approach. Two candidate secure two-way time transfer protocols proposed within the framework of the IETF are considered, and their performance in real wireless communications environments is assessed. The wireless communications networks used are standard commercial 3G and 4G networks, accessed via a simple commercially available dongle. Test results in a mixture of urban and rural dynamic vehicular environments with typical 4G coverage, occasionally degrading to 3G, are shown. Results indicate that worst case round-trip times are of the order of 100-500 ms, depending of the protocol employed. Secure Two-Way Time Transfer ---------------------------- Clock synchronization, or time transfer, in packet networks has a long history, the most notable protocol being the NTP [3], which dates back to the early 1980's. NTP is currently used by millions of users world-wide to achieve time synchronization of the order of milliseconds globally. The IEEE standard IEEE-1588, also known as PTP, is an alternative protocol for precise time transfer over local networks [4]. Both NTP and PTP are two-way protocols, but neither are secure (at least in their original versions). A number of attempts have been made over the years to add security to NTP, but with limited success. NTP v3 introduced a symmetric key system to sign NTP messages. The use of a purely symmetrical scheme means that this is not a very scalable solution (e.g. the NIST operate a NTP v3 compatible system in which the secret keys are physically mailed to authorized users). NTP v4 introduced an asymmetric scheme called AutoKey, which turned out to have a number of design flaws which rendered it much less secure than initially expected. These experiences led to the IETF establishing a set of security requirements for time transfer protocols, published as RFC7384 [5] and on-going effort to develop a standard for securing NTP [6]. These efforts resulted in a systematic analysis of the threats facing a networked two-way time transfer protocol. Each threat identified can be mitigated against in the implementation of the protocol, with the exception of: Delay manipulation, Spoofing of the master clock In a one-way protocol, delay manipulation is essentially unbounded, but in two-way communications the maximum delay that can be introduced can be easily determined by the client node from the round trip time. Thus, while the delay manipulation attack cannot be prevented, it can be bounded. If the observed two-way round trip time is greater than the bound then the protocol stipulates that the time synchronization process has failed. The final attack, spoofing of the master clock, is considered outside the scope of this work. This paper investigates the ability of secure two-way time transfer protocols to bound the uncertainty in the transferred time in typical vehicular wireless environments. Protocols Considered -------------------------- Based on a survey of the current literature the following candidate secure two-way time transfer protocols have been identified: 1) NTS over NTP [6] 2) Roughtime from Google [7,8] NTS over NTP =========== The NTS extensions over NTP define a two stage protocol for achieving secure two-way time transfer: A key exchange stage (NTS-KE) in which the client connects to a key exchange server via TLS and is given a list of ``cookies'' and NTS-enabled NTP servers that it can connect to. An authenticated time syncrhonization phase, in which the client connects to one or more of the NTS-enabled servers, exchanges the cookies obtained in the first stage and performs authenticated time synchronization using the NTP authentication extension fields. As previously mentioned NTS is a draft standard and as such in constantly evolving. At present the NTPsec project [9] has an implementation that is compliant with draft 17 of the proposed standard (as of September 2019 the latest version is draft 20). In addition, Cloudflare [10] provide an NTPsec compatible NTS-enabled NTP server at time.cloudflare.com:1234 [11]. The source code for the NTPsec implementation is freely available online [12]. Roughtime ========= The Google Roughtime protocol is designed to meet a completely different need: that of ensuring an authenticated time estimate, sufficient to ensure that trusted certificates are still valid ( have not expired). This protocol was designed by Google and is currently undergoing consideration for standardisation under the IETF [8]. One of the driving motivations behind the development of Roughtime is the requirement to be able to detect a ``rogue'' authenticated server. To achieve this, Roughtime employs a distributed authentication mechanism, in some ways similar to blockchain, to ensure that any parties that attempt to introduce false timing information can be detected and proven to be false. In addition, the impact of a MitM delay attack is limited by restricting the acceptable RTT to a certain maximum. Any server for which the RTT is greater than this maximum will be rejected from the set of timestamp estimates. The protocol itself is relatively simple: A client generates a cryptographically random nonce and sends it to a Roughtime server The server responds with a message containing: The server's time estimate The client's nonce A cryptographic signature of both The client creates a new nonce from another random value and a hash of the reply from the server and sends this to another Rougtime server The process repeats for as many servers as the client wishes to use This chaining of nonces and client requests ensures a strict ordering (the first request provably came before the second, etc.), and a ``misbehaving'' server can be provably identified by out-of-order responses. Because every client/server interaction requires an asymmetric key signature to be generated, the potential computational load is very high. To circumvent this, the protocol allows the server to sign batches of client requests using a Merkle tree, greatly improving the computational efficiency on the server side. At present (February 2020) both Google and Cloudflare have working implementations of both client and server sides of the Roughtime protocol, and a number of public Roughtime servers are now online. One potential issue with Roughtime is that the true time is defined with respect to UTC, but with a clock ``smearing'' on the days that leap seconds are introduced. This means that on each leap second day the Roughtime clock runs fast or slow by about 1 part in 86400. As the service does not aim for a high degree of precision this should be acceptable, but it is worth noting. Experimental Setup ------------------ A simple hardware setup has been configured for the purposes of testing, consisting of: A Raspberry Pi 3+ SBC [13] An Uputronics Raspberry Pi+ GPS expansion board [14] A Huawei E8372 [15], a USB dongle providing 2G, 3G and 4G/LTE wireless network access The Raspberry Pi 3 is mounted with both the Uputronics GPS expansion board and the E8372 WiFi dongle. A custom version of the NTP daemon, including the NTS implementation runs on the Raspberry Pi, which uses the GPS PPS to drive the local time estimate. A custom version of the Cloudflare implementation of the Roughtime protocol also runs on the Raspberry Pi. The NTP daemon logs both roundtrip and offset information for each server to which it connects, and the Roughtime daemon logs similar information for each Roughtime server. The Roughtime client is configured to poll all the servers every 30 s. Three experiments of approximately one hour were conducted: 1) A static baseline bench-top experiment in which the Raspberry Pi was connected to the network via Ethernet 2) A static bench-top experiment in which the E8372 was used for network access 3) A dynamic vehicular test, involving both urban a rural environments. The first two tests were conducted in order to establish a baseline, and to evaluate the contribution of the use of wireless rather than wired networks. The final test was designed to cover typical vehicular use cases in an environment with good to fair network coverage. Results and Conclusions ------------------------ In general the following observations can be made: o both secure NTP and Roughtime can fulfill the Chimera's requirement in term of time synchronization, enabling the secure processing of both the fast and the slow channel. o NTP provides a higher degree of accuracy (smaller offsets, with less variability) across all the tests o For the servers considered in these tests, the RTT is similar for both protocols, with the exception that the Roughtime protocol exhibited an unusual ``outage'' during the dynamic test when the RTT increased dramatically across all servers for a period of a couple of minutes. o Across all tests, both NTP and Roughtime were capable of providing a time transfer service with an uncertainty of less than +/- 280 ms (+/- 0.5 RTT), and typically significantly better than that. o Across all tests, occasional outliers were common, though rarely experienced on multiple servers simultaneously, emphasising the need to use multiple servers whichever protocol is used. REFERENCES: ============= [1] L. Narula and T. E. Humphreys, ``Requirements for secure clock synchronization,'' IEEE Journal of Selected Topics in Signal Processing, vol. 12, no. 4, pp. 749--762, 2018. [2] Air Force Reseach Laboratory, ``IS-AGT-100 Chips Message Robust Authentication (Chimera) Enhancement for the L1C Signal: Space Segment / User Segment Interface,'' 2019. [3] D. Mills, J. Martin, J. Burbank, and W. Kasch, ``Network time protocol version 4: Protocol and algorithms specification,'' Internet Requests for Comments, RFC Editor, RFC 5905, Jun. 2010, http://www.rfc-editor.org/rfc/rfc5905.txt. [Online]. Available: http://www.rfc-editor.org/rfc/rfc5905.txt [4] ``IEEE standard for a precision clock synchronization protocol for networked measurement and control systems,'' IEEE Std 1588-2008 (Revision of IEEE Std 1588-2002), pp. 1--300, Jul. 2008. [5] T. Mizrahi, ``Security requirements of time protocols in packet switched networks,'' Internet Requests for Comments, RFC Editor, RFC 7384, Oct. 2014, http://www.rfc-editor.org/rfc/rfc7384.txt. [Online]. Available: http://www.rfc-editor.org/rfc/rfc7384.txt [6] D. Franke, D. Sibold, K. Teichel, M. Dansarie, and R. Sundblad, ``Network time security for the network time protocol,'' Working Draft, IETF Secretariat, Internet-Draft draft-ietf-ntp-using-nts-for-ntp-20, Jul. 2019, http://www.ietf.org/internet-drafts/draft-ietf-ntp-using-nts-for-ntp-20.txt. [Online]. Available: http://www.ietf.org/internet-drafts/draft-ietf-ntp-using-nts-for-ntp-20.txt [7] ``Google roughtime,'' roughtime.googlesource.com/roughtime. [8] A. Malhotra, A. Langley, and W. Ladd, ``Roughtime,'' Working Draft, IETF Secretariat, Internet-Draft draft-roughtime-aanchal-03, Jul. 2019, http://www.ietf.org/internet-drafts/draft-roughtime-aanchal-03.txt. [9] ``NTPsec website.'' [Online]. Available: https://ntpsec.org [10] ``Cloudflare website.'' [Online]. Available: https://cloudflare.com [11] A. Malhotra, ``Introducing time.cloudflare.com,'' Jun. 2019. [Online]. Available: https://blog.cloudflare.com/secure-time/ [12] ``NTPsec source code repository.'' [Online]. Available: https://gitlab.com/NTPsec/ntpsec [13] ``Raspberry pi website.'' [Online]. Available: https://www.raspberrypi.org [14] ``Uputronics GPS HAT product page.'' [Online]. Available: https://store.uputronics.com/index.php?route=product/product&product_id=81 [15] ``Huawei e8372 product page.'' [Online]. Available: https://consumer.huawei.com/en/mobile-broadband/e8372/