R. ANNESSI, J. FABINI, F.IGLESIAS, AND T. ZSEBY: ENCRYPTION IS FUTILE: DELAY … · 2018-11-22 ·...

R. ANNESSI, J. FABINI, F.IGLESIAS, AND T. ZSEBY: ENCRYPTION IS FUTILE: DELAY ATTACKS ON HIGH-PRECISION CLOCK SYNCHRONIZATION 1

Encryption is Futile: Delay Attacks onHigh-Precision Clock Synchronization

Robert Annessi, Joachim Fabini, Felix Iglesias, and Tanja ZsebyInstitute of Telecommunications

TU Wien, AustriaEmail: [email protected]

Abstract—Clock synchronization has become essential to mod-ern societies since many critical infrastructures depend on aprecise notion of time. This paper analyzes security aspectsof high-precision clock synchronization protocols, particularlytheir alleged protection against delay attacks when clock syn-chronization traffic is encrypted using standard network securityprotocols such as IPsec, MACsec, or TLS. We use the PrecisionTime Protocol (PTP), the most widely used protocol for high-precision clock synchronization, to demonstrate that statisticaltraffic analysis can identify properties that support selectivemessage delay attacks even for encrypted traffic. We furthermoreidentify a fundamental conflict in secure clock synchronizationbetween the need of deterministic traffic to improve precision andthe need to obfuscate traffic in order to mitigate delay attacks.

A theoretical analysis of clock synchronization protocols iso-lates the characteristics that make these protocols vulnerable todelay attacks and argues that such attacks cannot be preventedentirely but only be mitigated. Knowledge of the underlying com-munication network in terms of one-way delays and knowledgeon physical constraints of these networks can help to computeguaranteed maximum bounds for slave clock offsets. Thesebounds are essential for detecting delay attacks and minimizingtheir impact. In the general case, however, the precision thatcan be guaranteed in adversarial settings is orders of magnitudelower than required for high-precision clock synchronization incritical infrastructures, which, therefore, must not rely on aprecise notion of time when using untrusted networks.

I. INTRODUCTION

CLOCK synchronization protocols have become an es-sential building block of numerous applications that

rely on a precise notion of time. The deployment of clocksynchronization for controlling system clocks of critical appli-cations in telecommunication, industrial automation, financialmarkets, avionics, or energy distribution has increased thedependency of critical infrastructures on clocks synchronizedwith increasingly high precision. Many processes, especiallyin measurement, control, telecommunications, industrial andfinancial applications are not only sensitive to errors in the valuedomain but also to errors in the time domain. Examples for strictdependencies on precise time are safety-critical applicationsin the Smart Grid, which require an accuracy of 1 to 100 µs(10 µs in case of current differential line protection with highfault current sensitivity [1, 2]) or MiFID II in the financialsector, requiring an accuracy of up to 100 µs [3, 4, 5]. Cellularnetworks also have strong requirements for synchronized clocks(≤ 1 µs) [6]. Errors in clock synchronization can lead to wrongtimings and may therefore originate faulty sensor reports,

endanger control decisions, and adversely affect the overallfunctionality of a wide range of (critical) services that dependon accurate time.

In recent years, security of clock synchronization receivedincreased attention as various attacks on clock synchronizationprotocols (and countermeasures) were proposed. For thisreason, clock synchronization protocols need to be securedwhenever used outside of fully trusted network environments.Clock synchronization protocols are specifically susceptible todelay attacks since the times when messages are sent andreceived have an actual effect on the receiver’s notion oftime. Delay attacks specifically can degrade the precision ofclock synchronization such that applications depending on itmay malfunction. Such malfunctioning is endangering criticalinfrastructures that increasingly depend on a precise notion oftime.

Encrypting and signing clock synchronization messages(with IPsec [7], MACsec [8], or TLS [9]) is commonlyrecommended in order to provide security against a wealth ofnetwork-based attacks. In this paper, we show that encryptionalone cannot provide sufficient security against delay attackson high-precision clock synchronization, which highlightsthe insecurity of numerous applications (including criticalinfrastructures) that depend on a precise notion of time. Wepresent a fundamental limitation of clock synchronization overuntrusted networks that is independent of the actual clocksynchronization protocol and communication network and evenholds when the communication is (supposedly) secured.

A. Contributions

The main contributions of this paper are the following:• Precision Time Protocol (PTP) traffic detection by

statistical analysis: We present a method for statisticaltraffic analysis of PTP’s 2-step mode that allows to identifyPTP traffic even if it is encrypted and transmitted togetherwith other traffic. We show that some statistical properties(length, timing, and direction) are sufficient to identifyPTP traffic and the particular PTP message types with veryhigh probability — even when the traffic is encrypted.

• Selective message delay attacks on encrypted traffic:Using the properties identified in the traffic analysis, wedesign and implement selective message delay attacks onencrypted traffic. This shows that delay attacks can beconducted on PTP even when it is (supposedly) secured

arX

iv:1

811.

0856

9v1

[cs

.CR

] 2

1 N

ov 2

018


with state-of-the-art network encryption schemes such asIPsec, MACsec, or TLS.

• Countermeasures: We discuss countermeasures againsttraffic analysis (length padding, timing randomization),selective message delay attacks (strict replay protection),and asymmetric link delay attacks (One-Way Delay(OWD) limits).

• General clock synchronization limitations in adversar-ial settings: We analyze the theoretical foundations thatmake clock synchronization protocols susceptible to delayattacks and identify the main vulnerability to be the delaycompensation mechanism, which is necessary to achievehigh precision. This leads us to asymmetric link delayattacks that cannot be prevented by encryption. Whileadditional knowledge of the underlying communicationnetwork can bound the maximum impact of delay attacks,we argue that clock synchronization protocols cannot bedesigned in a way that prevents asymmetric link delayattacks entirely.

The resulting bounds, which we found based on our analysis,do not satisfy requirements with respect to high-precisionclock synchronization. Therefore, high precision can only beguaranteed on trusted networks.

II. BACKGROUND

Each clock has a natural drift caused by the non-ideality ofphysical oscillators such an oscillator’s frequency affected bytemperature. The aim of clock synchronization is to keep clockswithin acceptable boundaries. Currently, there are two widelyused technologies for high-precision clock synchronization:(1) the satellite-based Global Positioning System (GPS) forPulses per Second (PPS) synchronization to global UniversalTime Coordinated (UTC), and PTP targeted for network-basedclock synchronization to a local clock. The main disadvantagesof GPS PPS are that it is operated by a single entity (theUS Air Force) and that it requires free view on at least foursatellites1, which might be difficult to get (in data centers forexample). Moreover, the (public) GPS signal is not securedso that it may be spoofed with reasonable effort [10]. Due tothe missing backchannel to satellites, GPS is conceptionallydifferent to the Network Time Protocol (NTP) and PTP. Inthis paper, we focus on PTP because it can achieve extremelyhigh precision, is widely used, and is more similar to otherclock synchronization protocols such as NTP. Most of thefindings in this paper, however, are applicable to other clocksynchronization protocols as well.

PTP [11] (or IEEE 1588) is designed to provide high-precision clock synchronization in the order of microsecondsor even sub-microseconds. PTP achieves such high precisionmainly by reducing the impact of delay variation in to the hosts’operating systems. For this purpose, Network Interface Cards(NICs) with dedicated PTP hardware support can preciselytimestamp PTP messages at send and receive times in order

1View to four GPS satellites is the requirement for GPS-PPS signalgeneration in the general case. However, from a theoretical point of view, onesingle satellite in view is sufficient whenever the exact GPS antenna positionis known

to eliminate software uncertainty. PTP assumes trustworthyand somewhat deterministic networks with low latency thatare entirely under control of the operator. It can be run over aLocal Area Network (LAN) via Ethernet or over a Wide AreaNetwork (WAN) via UDP.

New applications that require increasingly precise clocksynchronization lead to PTP being deployed also in criticalinfrastructures and other areas that PTP has not been designedfor specifically. Base stations in mobile networks that dependon highly accurate time are a prominent example. Originally,manufacturers used GPS PPS to synchronize clocks. Nowadaysmanufacturers also offer PTP as an alternative that is widelyused. Given the fact that base stations typically use WANsto connect to their core network, employing PTP contradictsthe original assumptions of being used within LANs. In thisway, new attack vectors are created such as the delay attackspresented in this paper. More examples include but are notlimited to areas such as Smart Grids or financial applications.

A. The Two Phases in Clock SynchronizationClock synchronization algorithms aim at synchronizing a

slave clock to a master clock by exchanging timestampedmessages over packet-switched networks. In this paper weassume that the master’s clock is accurate and reliable. Detailson how the master implements and accesses such a reliableclock are out of scope of this paper. Network-based clocksynchronization protocols depend on two distinct phases thatwill be discussed below: (a) clock offset measurement and (b)delay measurement.

a) Clock Offset Measurement Phase: The goal of theclock offset measurement phase is to calculate the relativedifference between the slave and master clocks. Clock offsetcan either be measured in a single message (1-step mode)supported by both NTP and PTP or in two messages (2-stepmode) supported by PTP. In any case, the master sends a SYNCmessage to the slaves, and the slave records the transmittingtime tM1. In 1-step mode the SYNC message contains thetransmitting timestamp (tM1), in two-step mode the SYNCmessage is just used as a marker, and the FOLLOW UP messagecontains the exact point in time when the SYNC message leftthe master (tM1). This way, higher precision may be achieved.Fig. 1 depicts the 2-step clock offset measurement and delaymeasurement.

b) Delay Measurement Phase: The SYNC andFOLLOW UP messages are subject to various delay. Thesedelays are added to (and therefore negatively affect) themeasured clock offset. The overall delay consists oftransmission delays, queuing delays, processing delays, andpropagation delays, which themselves consist of constant andstochastic parts2. The goal of the delay measurement phaseis to measure the overall delay and to subtract it from themeasured clock offset in order to derive the actual clock offsetas precisely as possible.

In PTP a delay measurement consists of two messages, onesent from the slave to the master (DELAY REQUEST) where

2There is some constant delay for a given route and message size andstochastic delay that mainly depends on other traffic and states of networkdevices.


Fig. 1. 2-step clock synchronization with deterministic and symmetric delaysand initial clock offset of 10 time units.

the slave records the transmitting time tS3 and a subsequentmessage from the master to the slave (DELAY RESPONSE)that includes the time instant when the DELAY REQUEST wasreceived at the master (tM4). Eventually, the slave knows fourtimestamps: tM1, tS2, tS3, and tM4. The slave calculates thenetwork Round-Trip Delay (RTD) by measuring the OWDs inboth directions (see Eq. 1). The RTD is calculated as the sumof the delay from master to slave (tS2 − tM1) and the delayfrom slave to master (tM4− tS3). The OWD are approximatedas RTD

2 , assuming symmetric OWDs.

RTD = tS2 − tM1 + tM4 − tS3 (1)

B. Clock Offset Calculation

For simplicity reasons, in the following example we assumethat master and slave clocks do not drift. The initial clockoffset is 10 time units such that the local timestamp tM1 = 0on the master corresponds to the local timestamp tS0 = 10on the slave (from an external observer’s point of view). TheOWDs are 2 time units in each direction. The slave calculatesits clock offset to the master according to Eq. (2).

offset = tS2 − tM1 −RTD

2(2)

Eq. (2) consists of the uncorrected clock offset (tS2 − tM1)corrected with the OWD that is approximated by halving theRTD (Eq. 1). In this specific example, the slave calculates theOWD as 2 and the clock offset as 10. Now the slave knowsthat its clock is 10 time units ahead of the master and canadjust accordingly. In real-world scenario, all physical clocksare subject to drift so that the process of offset correction needsto be run repeatedly in order to achieve a common notion oftime.

III. THREAT MODEL

The goal of the adversary is to make slaves adhere tofalse clock values or to degrade the precision of the clocksynchronization to such an extent that it cannot be consideredhigh-precision anymore. We define high-precision that for everytime instant i : |tSi − tMi|≤ 10 µs holds, and the goal of the

adversary is to disturb this synchronicity of the master andslave clocks at some instant.

We assume that the adversary is in a privileged Man in theMiddle (MITM) position in the network, by having gainedaccess to a network node or a link of the communicationpath, or by conducting an ARP poisoning attack for example.The adversary can, therefore, selectively manipulate, capture,and delay any packet on the communication network, inparticular any clock synchronization packet that master andslave exchange. We assume the communication between masterand slaves to be confidential and integrity-protected such thatthe adversary can neither read nor modify the communicationin the value domain but can only modify the time domain.The computational power of the adversary is limited but notnecessarily bound to that of the master or the slaves. I.e., theadversary can use more powerful devices and larger storage.

IV. DELAY ATTACKS

Whenever clock synchronization messages are neither en-crypted nor integrity-protected, an adversary can attack clocksynchronization protocols in the value domain, i.e., the adver-sary modifies the timestamp values included in the messages.This is a well-studied field and various countermeasures havebeen proposed to secure clock synchronization against attacksin the value domain such as encrypting the communication(with MACsec, IPsec, or TLS) or employing digital signaturesto ensure the integrity and authenticity of the communication.

To conduct an attack in the time domain an adversaryintercepts clock synchronization messages and delays themartificially for some time before forwarding3. The maliciouslyintroduced delay can be constant, variable, or even random,and the slave clock can be manipulated this way [12]. Sincethe clock synchronization protocol has no information aboutthe underlying communication network, one fundamentalprerequisite and assumption of PTP is symmetric network delaybetween master and slave. I.e., the OWD from master to slaveis identical to the OWD from slave to master. Delay attacksexploit this assumption of symmetric delay by maliciouslyintroducing asymmetry such that the slave synchronizes to aninaccurate time.

The goal of delay attacks is to maliciously manipulate one ofthe two messages that are crucial to clock offset measurementand delay measurement: SYNC and DELAY REQUEST. Whileother network-based attacks are important as well, delay attacksand especially countermeasures against delay attacks on clocksynchronization have not been studied in required depth yet.This paper focuses on this gap in research — delay attacksand their impact on clock synchronization’s precision.

As we will show in Section VI and VIII, delay attacksare feasible despite security measures in place (i.e., trafficbeing encrypted and integrity-protected). Encrypting trafficis not sufficient, mainly because successful verification of a

3Theoretically delay attacks can also be conducted by accelerating messages(instead of delaying them). To conduct such acceleration attack, the adversaryneeds to delay all messages by default and selectively forward some messageswith less delay in order to achieve an acceleration effect. Another option toaccelerate messages would be to route them through faster paths if the attackerhas this option.


Fig. 2. PTP clock synchronization with delayed DELAY REQUEST message.

message’s integrity only certifies the correctness of the (sendingtime reported in the) message but not of its effective propagationtime through the network [13]. For this reason, the delay attackscan also be conducted on encrypted and integrity-protectedtraffic. The assumption of symmetric OWDs is essential tothe delay attacks presented in this paper as those exploit non-deterministic delays in communication networks.

Asymmetric OWDs have a direct effect on the precision ofclock synchronization. The effect of asymmetric OWDs onclock synchronization is depicted in Fig. 2 and 3. In Fig. 2, themessages from master to slave take 2 time units while thosefrom slave to master take 8. The slave therefore calculates theclock offset according to Eq. 2 as 7, which is off from the actualoffset (10). In this example, the slave clock remains 3 time unitsahead of the master’s because of the asymmetric delay in theDELAY REQUEST message. If the SYNC message, on the otherhand, takes longer than the DELAY REQUEST message (Fig. 3),the slave miscalculates the clock offset (again according toEq. 2) as 13 so that the slave corrects its clock too muchand its clock is then behind the master’s. Such asymmetricdelays are an inherent part of packet-switched communicationnetworks as transmission delays, propagation delays, queuingdelays, and processing delays are never entirely symmetric4.

V. RELATED WORK

Tsang and Beznosov where the first to analyze the security ofPTP in 2005 [15, 16]. They describe delay attacks briefly andpropose to average delay measurements as a countermeasure.We argue that averaging delay measurements also averages themalicious delay such that the attack is only barely mitigated.The attack has even full effect as soon as the durationof the attack is longer than the averaging interval5. The

4Sometimes, asymmetry is even intentional like with Ethernet where cablesare asymmetric by design to reduce far end crosstalk [14].

5And if the averaging interval is too long, the clock synchronization precisionmay be negatively affected (since reacting on changes in the RTD would taketoo long).

Fig. 3. PTP clock synchronization with delayed SYNC message.

authors furthermore propose to check for abnormal values.But abnormal values (i.e., spikes in the measured clock offset)only occur for simple delay attacks but not for incrementaldelay attacks (as to be shown in Section VI-C).

PTP version 2 includes an experimental security extension,Annex K [11], which provides message integrity and replayprotection. In Annex K, however, several flaws were discoveredand it was never properly formalized [17, 18]. In any case,Annex K does not cover attacks in the time domain at all.Interestingly, the PTP standard [11] mentions link asymmetry(although in a single sentence only) but does not cover delayattacks any further. We analyze asymmetric link delay attacksin Section VIII and countermeasures against such attacks inSection IX.

Network Time Security (NTS) [19, 20, 21] consist of aset of Internet Engineering Task Force (IETF) drafts thataim at providing authenticity and integrity for unicast clocksynchronization protocols. Until now, NTS is only specifiedfor NTP and covers delay attacks briefly. A recently proposedsecurity extension to PTP [22, 23] aims to secure the 2-stepmode in PTP. The authors mention delay attacks in the extendedversion of their paper but refer to related work when it comesto countermeasures.

Ellegaard as well as Koskiahde, Kujala, and Norolampirecommend MACsec to secure clock synchronization [24, 25].Mizrahi analyzes IPsec and MACsec as means to secure clocksynchronization [26]. Delay attacks are very briefly mentionedbut the paper neither has details on how delay attacks can beconducted or mitigated nor how IPsec and MACsec relate todelay attacks. Treytl and Hirschler discuss the usage of IPsecto protect PTP [27] but do not mention delay attacks at all.Mizrahi states that encrypting clock synchronization trafficmakes it more difficult to conduct delay attacks [28]. We willshow that this holds true to some extent for selective messagesattacks only (Section VI), but asymmetric link delay attacks(Section VIII) are not obstructed by encryption at all.

In [14], Yang, An, and Yu simulated delay attacks and


propose a countermeasure based on hypothesis testing. Moreiraet al. discuss delay attacks briefly [18]. Ullmann and Vogelerexamined delay attacks on PTP and NTP [29] and proposewhat we call bound clock offset by limiting the RTD asmitigation. Lisova et al. provide a good analysis of theconsequences of delay attacks and discusses RTD limits ascountermeasure [30]. Other countermeasures discussed, suchas monitoring interarrival times, are unreasonable in a generalsetting because those times will be equally affected by a delayattack and cannot be used therefore as a countermeasure againstdelay attacks. Mizrahi also briefly discusses RTD limits as apotential countermeasure against delay attack [28], and so doAnnessi, Fabini, and Zseby [31].

Mizrahi proposes to use multiple paths between master andslave to mitigate delay attacks [28]. The assumptions are quitestrong, however, as all paths need to be entirely (i.e., alsophysically) independent and the adversary may only attack aminority of paths successfully. From a practical perspective itseems unrealistic to provide multiple low-latency paths withlow delay variation that are entirely independent. It is implicitlyassumed that the various networking components such as NICs,routers, and switches are from distinct vendors and that pathsare symmetric. Furthermore, the countermeasure does not scalewell as it is more costly to establish new independent pathsthan to compromise any majority of paths.

In recent work Narula and Humphreys developed a mathe-matical model that defines necessary and sufficient conditionsfor secure clock synchronization [32]. Focusing on conditionsthat must be met in wireless networks to detect MITM attackson clock synchronization, the paper builds on earlier work [31]to conclude that round-trip message exchange is a prerequisitefor secure clock synchronization and that one-way clocksynchronization can not be secured against delay attacks.However, Narula and Humphreys rely on uniquely identifiableclock synchronization messages in an isolated context andmaximum round-trip delays, whereas our work analyses themuch broader context of clock synchronization as part of real,encrypted traffic.

Summarizing related work, research on secure clock syn-chronization often either excludes delay attacks or refersto related work for discussion on this issue. None of therelated work discusses delay attacks on encrypted clocksynchronization traffic in a realistic context, including detectionof clock synchronization traffic. Furthermore, related workdoes not recognize the ability of clock synchronization slavesto determine guaranteed bounds on their clock offset at aspecific point in time, nor does it identify the fundamentallimitation inherent to network-based clock synchronization:clock synchronization can either be high-precision or secureagainst delay attacks.

VI. SELECTIVE MESSAGE DELAY ATTACKS

To secure communications over untrusted networks the entirecommunication is commonly encrypted and authenticated, forinstance with IPsec. For this reason, we tested delay attacks

with IPsec in tunnel mode6. In such scenario, the attacker hasaccess only to encrypted traffic, which means that there is noinformation available about protocols, source and destinationports, nor the IP addresses of the real endpoints.

In this section, we show that clock synchronization messagescan be reliably identified in an encrypted traffic stream withreasonable effort. This identification of (encrypted) clocksynchronization messages builds the foundation for selectivemessage delay attacks. For this purpose, we aim to answer thefollowing questions:

• Are there any (statistical) properties of PTP traffic thatcan be used to identify PTP messages within encryptedtraffic?

• Can PTP traffic be modified such that delay attacks canbe prevented or at least mitigated?

• Can encryption schemes provide reasonable securityagainst selective message delay attacks?

To answer whether it is possible to identify both PTP trafficin general and specific types of PTP messages in encryptedtraffic, we conduct statistical traffic analysis of PTP traffic.From this analysis, we identify several properties of PTP trafficthat build the foundations for selective message delay attacks.We furthermore implement selective message delay attacks onactual devices to show the feasibility of our proof of conceptin practice.

A. PTP Traffic Analysis

In order to make a slave adhere to a false time, either theSYNC or the DELAY REQUEST message need to be delayed bythe adversary (as pointed out in Section IV). Depending onthe delaying of either SYNC or DELAY REQUEST, the slave’snotion of time is going to be behind or ahead of the master’s,respectively. When traffic is encrypted, traffic analysis is limitedto a restricted set of features: time, packet length, source, anddestination. In our specific case, each of these features can beused to identify the particular type of PTP message in encryptedtraffic. The statistical properties identified in PTP in both phases,i.e., clock offset measurement and delay measurement, areclosely related to timing, packet length, and packet direction.

One PTP clock synchronization cycle consists of a series offour messages as highlighted in Section II. (1) A SYNC messagefrom the master to the slave. (2) Another message (FOLLOW UP)from the master to the slave. (3) A message DELAY REQUESTin the reverse direction from the slave to the master, and (4)a message from the master to the slave (DELAY RESPONSE).This series repeats at a fixed interval. Every two seconds weobserve another PTP message (ANNOUNCE) from the masterto the slave. The ANNOUNCE message is used for the Best-Master-Clock algorithm, which we do not focus on in thispaper.

Our traffic analysis revealed some specific properties ofPTP traffic. These properties are the length of packets, thetiming, and the direction of messages. The lengths of the

6We have tested selective message delay attacks successfully againstcommercially available systems like routers or protections switches that tunnelPTP using security protocols different than IPsec, too. Methods and conclusionsare identical to the ones presented for IPsec tunnels for all tested systems.


Fig. 4. PTP traffic patterns in timing, length, and direction.

packets are appealing as they are highly deterministic andmostly constant. The reason for this is that the designers ofPTP wanted to avoid variation in the transmission delaysbecause of differences in packet lengths. Fig. 4 sketchesthe results of our PTP traffic analysis. Firstly, all messagesfrom the master to a slave are of the same length and theDELAY REQUEST message in the reverse direction is either ofequal length or slightly longer, which means that the length ofa PTP message is related to its direction. The specific lengthsof the messages depend on the underlying communicationprotocols and on which layer the messages are observed. Inour setup, the lengths of (unencrypted) PTP messages were86B and 96B for SYNC, FOLLOW UP, and DELAY RESPONSEand DELAY REQUEST respectively (and 106B for ANNOUNCEmessages). In encrypted traffic, additional information is addedto the packet by the encryption scheme, increasing the packet’slength. The packet lengths observed were 138B and 154Bin a test with IPsec encryption. Other encryption schemesresult in different lengths but the observed pattern persists.Messages of length 154B occur every 2 s, which correspondsto ANNOUNCE messages. The remaining packets with a lengthof 138B occur every 250ms and in sets of 4 (which corre-sponds to the SYNC, FOLLOW UP, and DELAY REQUEST andDELAY RESPONSE messages). The length of encrypted PTPmessages are deterministic, as well, and therefore identifiable.

Secondly, we observe that PTP messages follow a specifictiming pattern. The FOLLOW UP message is sent from themaster with minimal delay (t0) after the SYNC message; theDELAY REQUEST message is sent with a small delay (t1)after the FOLLOW UP message was received by the slave;and the DELAY RESPONSE is also sent immediately after theDELAY REQUEST was received (t2) by the master. From theadversary’s point of view t1 and t2 are roughly similar, whichis about the OWD between master and slave7. Because of theirperiodicity, the observed timings are also visible in encrypted

traffic, as we will see later in this section.Thirdly, the direction of the messages is fixed as long as

the master and slave roles persist. And this pattern repeatsperiodically at a fixed interval (t3) for as long as the clocksynchronization service is running. This clock synchronizationinterval can be configured and was left to the default setting of250ms during our tests. Table I summarizes the results of ourtraffic analysis. In Section VI-B we show how these propertiescan be used to identify PTP traffic in a stream of encryptedtraffic.

B. Identification of PTP messages in Encrypted Traffic

In order to conduct a selective message delay attack onan encrypted traffic stream, we first need to identify thespecific PTP messages within the encrypted traffic withoutprior knowledge of the communications within that stream. Tothis end, we setup a proof of concept to verify that specific PTPmessages can be identified within encrypted traffic. In a real-world scenario, the specific setup will always be different, andattackers may not have the plaintext communication available tofigure out the specific parameters of the setup (i.e., the specificpacket sizes, the PTP session interval, etc). Also, packet lengthsdiffer in encrypted traffic (as there is additional data addedby the encryption scheme) but the basic properties (frequency,direction, timing and the relation of the lengths) persist.

Using the results of our PTP traffic analysis, we wantedto know whether identifying PTP messages in encryptedtraffic is possible. For this purpose, we conducted someexperiments in which PTP communications were simulated.The communication under test selects random timings t0, t1,t2, t3, and random lengths x and y. The simulation takestwo parameters, the noise level and the time to observe thetraffic. Noise is added to the simulated PTP communication,which is the probability to obtain a non-PTP packet of randomlength every millisecond. Eventually, the script tries to estimatet0, t1, t2, t3, and the lengths x and y just by observing thecommunication.

This proof of concept relies on four assumptions:1) Time is discretized with a sampling time of 1ms.2) There is only one packet per time bin.3) The pattern repeats all over the observation period.4) t0, t1, t2, and t3 are constant from the perspective of

the sampling time.Such assumptions draw some limitations for simulating

communications, but they are assumable since experimentsare intended to be proofs of concept and not fully-fledged im-plementations. Real-world communications comprise additionalcomplexities that might defy the proof of concept detector, butsuch situation can usually be faced by refining the detector (forexample, by using recurrence analysis, granger causality, ormarkov models). Our goal is to show that the detection of thepursued time parameters and lengths is theoretically possibleand feasible by the application of methods based on statistics.

7t1 and t2 are roughly similar if the attacker is positioned equidistant interms of time between master and slave. If the attacker is closer to eithermaster or slave, the difference between t1 and t2 increases — visible byshifting the observation point to the left or to the right, respectively, in Fig. 4.


TABLE IIDENTIFIED PROPERTIES OF PTP TRAFFIC.

Message type Direction(master-slave)

Length Timing

SYNC → 86B / 138B t3FOLLOW UP → 86B / 138B t0DELAY REQUEST ← 96B / 138B t1 ≈ t2 ≈ one-way delayDELAY RESPONSE → 86B / 138B t2 ≈ t1 ≈ one-way delayANNOUNCE → 106B / 154B fixed interval (ignored)

t3 with regard to the last DELAY RESPONSE message, i.e., the clock synchronization interval.

Fig. 5. Experimental setup used to examine the effect of delay attacks onPTP over an untrusted network.

Our simulations show that packet lengths, directions, andtiming are sufficient to separate PTP from other traffic andeven to identify the particular type of PTP message so that theselective message delay attack can be conducted. If the noiselevel is increased, the observation time needs to be increasedas well (as expected). Under our simulation conditions, at anoise level of 99.9%, we need to observe the communicationsfor 1000 seconds to reliably determine the particular times andlengths.

A challenging scenario for the detection would be theoccurrence of periodic signals with similar properties (timing,lengths, and direction) within the same flow. We argue thatthe properties of PTP are very particular and the chancesto encounter communications with similar properties in thesame traffic are very low. In the light of our experimentalresults, we conclude that PTP traffic can be identified withhigh probability within encrypted network traffic. For thisreason, selective message delay attacks can be conducted onPTP even when it is (supposedly) secured with state of the artnetwork encryption schemes such as IPsec.

C. Experimental Results

Based on the statistical properties we identified in the trafficanalysis (Section VI-A) and the theoretical confirmation thatthese properties can be used to identify PTP messages withinencrypted traffic (Section VI-B), we implemented a PTP trafficdetection and PTP message type identification on a real clocksynchronization system. We furthermore implemented selectivemessage delay attacks on actual devices to show the feasibilityof our proof of concept in a practical setting. Fig. 5 depictsthe experimental setup we used to evaluate the feasibility ofour proof of concept and to examine the effect of delay attacks

on real PTP systems over untrusted networks. We used threeLinux systems: one that runs as PTP master, another as PTPslave, and the third acts as network bridge. Master and slavewere connected through an IPsec tunnel such that the bridgecould only observe encrypted traffic. PTP master and slaveboth run PTPd version 2.3.1. Master and slave receive a GPSPPS signal but only the master clock is synchronized to it.With this setup, we can synchronize the master clock ±10 µsto UTC, which is not overly precise but enough to highlightthe effect of selective message delay attacks. The slave clockis synchronized to the master via PTP. To compare the slaveclock to the PPS signal, the “ppstest” tool8 was used.

Both systems are connected through an Ethernet bridge.On the bridge, we implemented a MITM application that candelay specific packets. The bridge is implemented with libnetfil-ter queue9 so that packets are not only available in kernelspacebut also in userspace, which facilitates easier classification andattack implementation. Since traffic is encrypted, a delay attackin the value domain does not work because the timestampswithin the packets cannot be modified. Instead, the attack onlyworks in the time domain. In general, the adversarial applicationon the bridge aims to identify PTP messages and delay specificmessages as soon as the selective message delay attack isstarted. We expect that the slave clock is then desynchronizedfrom the master clock after a short time (due to an averagingalgorithm employed in PTPd).

1) Experiment 1: Delayed SYNC messages: In the firstexperiment, we programmed our malicious application to delayall SYNC (and FOLLOW UP) messages by 50ms. We chosesuch large delay to stress that during such an attack the clocksynchronization cannot be considered high-precision any more.Fig. 6 shows the results, i.e., the offset of the master and ofthe slave clock to UTC during normal operation and during theattack. The master clock is quite stable throughout the run of theexperiment, as expected. The slave clock spikes10 shortly afterthe attack is started (at time 4122) and ended (at time 6632)and settles around −25ms to UTC after a couple of secondsthroughout the attack. The master clock is not affected at allby the selective SYNC-message delay attack, as expected. The

8https://github.com/redlab-i/pps-tools9https://netfilter.org/projects/libnetfilter queue/10Presumably, the overshooting in those spikes at the begin and at the end

of the attack is caused by the specific control algorithm implementation inPTPd.

https://github.com/redlab-i/pps-tools

https://netfilter.org/projects/libnetfilter_queue/


Fig. 6. Offset to UTC during an selective SYNC message delay attack.

Fig. 7. Offet to UTC during a selective DELAY REQUEST message delay attack.

slave clock is affected, however, since the clock synchronizationmessages of the master are delayed maliciously. The delayattack operates as intended since the slave clock is around 25msbehind the master’s during the attack.

2) Experiment 2: Delayed DELAY REQUEST messages:The same setup was used in a second experiment. Thistime, DELAY REQUEST messages were delayed 50ms by ouradversarial application on the bridge (instead of SYNC andFOLLOW UP messages). For this reason the slave clock is(roughly 25ms) ahead of the master’s clock during the attackas shown in Fig. 7.

3) Experiment 3: Incremental delay attack: One may arguethat the spikes in clock offset at the start and end of the attacksmay raise a suspicion in security-critical environments. For thisreason, we also implemented selective message delay attacksthat incrementally add malicious delay. In that case (shown inFig. 8), the attacker does not apply the full malicious delayfrom the moment the attack is started but instead incrementallyincreases the malicious delay with each message. In this way,there is no more spike in the slave’s time offset when the attackstarts. At time 3119 the incremental delay attack was startedas DELAY REQUEST messages were (increasingly) delayed by1 ppm.

Fig. 8. Offset to UTC during a incremental selective DELAY REQUEST messagedelay attack.

This incremental delay was deliberately chosen small (with1 ppm) to highlight that such small delay is indistinguishablefrom delay variation while still having a significant effecton the clock’s precision. Despite the small incremental delay,the slave clock is off more than 7ms to UTC after two hours,which is completely unacceptable for most time critical systemsthat rely on a precise notion of time. The slave cannot noticethe drift of its clock relative to the master’s because of theincremental delay attack and is therefore convinced to beperfectly synchronized.

4) Discussion: While the first two attacks might be de-tectable due to the spikes in the clock offset at the start andend of the attacks, the incremental attack cannot be detectedeasily. Moreover, we argue later in Section IX that suchincremental delay attack cannot be prevented at all (onlybe mitigated to some extent under specific circumstances).Although the attacker can neither see the packets’ contents, northe real endpoints, nor ports, selective message delay attackscan be conducted successfully. This indicates that encryptionalone cannot prevent selective message delay attacks on clocksynchronization.

VII. COUNTERMEASURES AGAINST SELECTIVE MESSAGEDELAY ATTACKS

In order to secure PTP from selective message delay attacks,encryption of the communication is not sufficient. But thereexist two options to counter selective message delay attacks:(1) prevent traffic analysis, and (2) mitigate the actual attack.Both options will be discussed in this section.

A. Traffic Analysis Mitigation

Direction, timing, and packet length are sufficient to reliablyidentify PTP traffic and the specific types of PTP messages. Intraffic analysis mitigation, the goal is to disturb traffic analysis.For this purpose, we need to make sure that the observablefeatures entail no information that can be used to conduct anattack. Those features are packet length, time, and direction.

While packet lengths are usually highly deterministic andconstant, they can be hidden by padding to a fixed length.


Such padding can even be implemented without changing theclock synchronization protocol. Encapsulating Security Payload(ESP) mode in IPsec, for example, supports payload paddingup to 255 padding bytes [33], and the Extension Header couldbe used in IPv6 [34]. Alternatively or additionally TrafficFlow Confidentiality (TFC) [35] could be employed to ensurethat all PTP messages have the same length. Alternatively,random lengths could be used, but this would increase variationof transmission delays (in addition to increasing bandwidthrequirements), which is detrimental to the goal of achievinghigh-precision clock synchronization.

Nevertheless, padding alone is not sufficient for trafficanalysis mitigation since information about the time and thedirection are still sufficient to identify PTP packets (andtherefore to conduct selective message delay attacks). Thenext feature that needs to be changed is the timing. Becauseof the periodicity of PTP messages discovered in our PTPtraffic analysis, the specific messages can be identified reliablyeven in encrypted traffic. Changing the timing, however, canonly be done from within the clock synchronization protocoland not by external mechanisms. The offset measurement anddelay measurement could be separated, the offset correction notexecuted periodically but in random intervals, and there couldbe a random interval as well between SYNC and FOLLOW UPmessages. In this way, the timing properties of PTP couldhardly be used anymore to identify PTP packets reliably underthe assumption that sufficient cover traffic exists with similartiming properties. The major downside of this method is thatit depends on the continuous existence of suitable cover trafficover the entire path from master to slave, nevertheless. Thisprerequisite of suitable cover traffic shifts the discussion to thewell-researched area of traffic obfuscation in order to protectPTP from selective message delay attacks (even when trafficis encrypted). Traffic obfuscation is known to be very complexand its security highly depends on the specific threat model11.

The last feature that is used to prepare selective messagedelay attacks is the direction of messages. As we have seenfrom the traffic analysis (Section VI-A), the packets’ directionsare highly deterministic in PTP. There is no straight-forwardway to remove this feature.

B. Mitigation of Delay Attacks

In this section, we highlight two techniques to mitigatedelay attacks. The first technique relies on knowledge of theunderlying communication network and requires changes to theclock synchronization protocol. The second technique buildsupon the replay protection of the encryption scheme. It needsto be stressed, however, that both techniques are mitigationonly and cannot prevent the attacks. Table II summarizes theresults.

As the name suggests, the replay protection of a networksecurity protocol is supposed to prevent or mitigate replayattacks (and has not been specifically designed to prevent delayattacks). At the same time, however, the replay protectionalso limits the maximum impact of selective message delay

11A special case here is that other periodic signals (that show similarproperties to those identified in PTP) could be used to mitigate traffic analysis.

attacks since packets cannot be delayed arbitrarily. The impactof selective message delay attacks may be limited by maxingthe encryption scheme’s replay protection and assuring that asufficient number of packets per clock synchronization intervalare sent through the network as cover traffic. Replay protectionusually works as follows: a sequence number is added to thepacket, and the receiver accepts packets with strictly increasingsequence numbers only or with sequence numbers from acertain window to allow packets to overtake other packets inthe network. While not specifically designed for this purpose,such replay protection also limits the impact of delay attackssince packets will not be accepted by the receiver if too manyother packets have been received meanwhile. For this reason,the maximum impact of the selective packet delay attack isdirectly related to the replay protection and to the numberof packets per clock synchronization interval at the networklocation the attacker has access to.

Therefore, replay protection should be configured strictly(when possible) such that overtaking of packets is not allowedat all. Packets may still be delayed maliciously, however, untilthe subsequent packets arrive. Also, the attacker may drop ordelay the subsequent packets as well in order to increase themalicious delay for the PTP packets. If there are no additionalsecurity measures in place such delay or drop of packets willnot raise any suspicion. In any case, the strict replay protectionin conjunction with sufficient packets per clock synchronizationinterval may limit the impact of selective message delays. Itneeds to be stressed that this mitigation depends on additionalcover traffic within the entire network path from master toslave (and vice versa) which may not be under the defender’scontrol. Furthermore, strict replay protection is not feasible inall scenarios because reducing packet loss rate may be moreimportant in some scenarios than stricter replay protection.

Countermeasures asymmetric link delay attacks (i.e., limitingOWDs - to be introduced in Section IX) are also applicable ascountermeasures against selective message delay attacks (butcountermeasures against selective message delay attacks arenot applicable to asymmetric link delay attacks).

VIII. ASYMMETRIC LINK DELAY ATTACKS

In Section VI we introduced selective packet delay attacks,in which the attacker aims to identify PTP messages (in anencrypted traffic stream) in order to delay specific PTP packetsselectively. In this section, we present an additional delayattack, which we denote in the following as asymmetric linkdelay attack. In such asymmetric link delay attack, the attackerdelays all packets in one direction of the link but not in theother (e.g., all packets from the master to the slave are delayedmaliciously but those from slave to master are not).

In order to analyze how delaying all packets in one directionaffects clock synchronization we use the example discussedin Section IV. This time, however, we delay all packets sentby the master to the slave without delaying the messagessent by the slave to the master as illustrated in Fig. ??. Theslave eventually calculates the offset according to Eq. (2) as 3(again we assume for simplicity reasons that clocks are neitherdesynchronized nor drifting). The miscalculated clock offset


TABLE IILIST OF COUNTERMEASURES AGAINST SELECTIVE MESSAGE DELAY ATTACKS.

Countermeasure Benefit Drawbacks Preventsattack

Random send and reply times Confuses traffic analysis based on timings Requires protocol changes and dependson cover traffic.

No

Equal (or variable) message lengths Confuses traffic analysis based on lengths Variable lenghts reduce precision anddepends on cover traffic.

No

Strict replay protection Limits max. impact of the attack Not feasible in all scenarios NoLimiting OWDs Limits max. impact of the attack Requires knowledge of the underlying

communication network.No

Fig. 9. Asymmetric link delay attack where the master→slave link is delayed.

Fig. 10. Asymmetric link delay attack where the slave→master link is delayed.

(3) is half of the delay asymmetry while the real clock offset is0. For this reason, the slave sets its clock backwards by 3 timeunits. If the attacker conducts the attack in reverse direction(i.e., the packets from slave to master are maliciously delayedbut the packets from master to slave are not, see Fig. 10),the slave miscalculates the offset as −3 (according to Eq. (2))when it is actually 0. For this reason, the slave will set itsclock ahead by 3 time units.

Fig. 11. One-way delays in clock synchronization.

An attacker who conducts an asymmetric link delay attack bydelaying all packets in one direction can, therefore, manipulatethe clock offset by half of the asymmetric delay. The attackercan also influence the sign of the malicious offset correction bychoosing which direction of packets are delayed maliciously.Link asymmetry being closely related to clock offset correction,two questions arise: (1) what is the exact relation between clockoffset correction and link asymmetry, and (2) can asymmetriclink delay attacks be prevented? These two questions will beexamined in the remainder of this section.

When analyzing clock synchronization messages in detail,the first message is sent at tM1 by the master and receivedat tS2 by the slave. In the case of a hypothetical zero-delaylink, the difference tS2 − tM1 would represent the exact offsetof the slave clock relative to the master. As pointed out inSection II, clock synchronization messages in real systemsexperience various (constant and stochastic) delays along theirpath from master to slave and vice-versa. The receiving timetS2 as well as the slave-computed clock offset incorporate thesum of all of those delays.

In practice, transmission and propagation delays account formain part of the clock synchronization message end-to-enddelay. This is why clock synchronization protocols comprisedelay measurement methods to infer on applicable delays inorder to compensate for them. On top of these measurements,high-precision clock synchronization protocols such as PTPpropose dedicated functionality in intermediate devices (so-called transparent clocks in routers and switches) to compensatefor queuing and processing delays within intermediate systems,even though those delays typically amount to a minor part ofthe overall delay.


To facilitate the compensation of delays, two assumptions arerequired: (1) the relative clock drift within one measurementinterval is negligible, and (2) the OWDs are symmetric, i.e.,the sum of delays from master to slave equals the sum ofthe delays from slave to master. Fig. 11 shows the OWDsd1 and d2 in the general case. The offset of the slave attime tS2 is offset(tS2) = tS2 − tM1 − d1 and at time tM4

is offset(tM4) = −tM4 + tS2 + d2. The offset is alwayscalculated from the perspective of the slave so that the masterinverts its offset calculation (as the offset of the slave clockrelative to the master is the inverse of the offset of themaster clock relative to the slave). The fact that always theslave’s offset is calculated can be exploited by an attackerthat maliciously alters delay asymmetry, even if the attackerdoes neither know the content of a message (because it isencrypted) nor its type (because traffic is perfectly obfuscated).The direction alone is sufficient to manipulate the measuredclock offset.

The assumptions mentioned above are essential to compen-sate the delays as the OWDs are approximated as half ofthe measured RTD. If those assumptions do not hold true,the system of two equations and four unknown variables inEq. 3 cannot be solved. The first assumption (relative clockdrift is negligible during one measurement interval) impliesthat the clock offset at time tS2 should be almost identicalto the offset at time tM4. For this reason, one variable iseliminated as offset = offset(tS2) = offset(tM4). Thesecond assumption (symmetric delays) helps to eliminateanother variable as d = d1 = d2, where d1 is the delay frommaster to slave and d2 is the delay from slave to master asshown in Fig. 11. This way, we end up having two equationswith two variables that can be solved.

In an asymmetric link delay attack an attacker exploits theassumption on symmetric delays. Assuming that there is acommon part d in OWDs and additional two distinct delaysδ1 and δ2 for both directions (as shown in Fig. 11), the twooffset equations are as follows:

offset(tS2) = tS2 − tM1 − d− δ1offset(tM4) = −tM4 + tS3 + d+ δ2

(3)

such that the offset can be calculated as

offset =tS2 − tM1 − tM4 + tS3 − δ1 + δ2

2(4)

as long as offset(tS2) ≈ offset(tM4) holds true. Thesymmetric delay component d is completely eliminated fromthe equation but δ1 and δ2 remain. If the delay is symmetric,then they cancel each other (as δ1 = δ2) so that the offset canbe calculated precisely. But if the delays are not symmetric,offset calculation will be off by δ2−δ1

2 , which is in the interval[−δ12 , δ22

]given that an attacker will eventually minimize either

δ1 and keep δ2 close to zero or keep δ1 close to zero andmaximize δ2.

IX. COUNTERMEASURES AGAINST ASYMMETRIC LINKDELAY ATTACKS

In this section, we propose a method that facilitates definingmaximum guaranteed bounds for the clock offset of the

Fig. 12. Theoretical (worst case) offset uncertainty bound calculation.

slave relative to the master. For the following discussionwe assume that master and slave clocks are synchronousat time tS0 = TM1 = 0 and that there is no clock driftduring one clock synchronization interval. All PTP messagesare cryptographically signed and encrypted, so the MITMcan not modify timestamp values within these messages. TheFOLLOW UP message is omitted, and we assume that the slaveimmediately sends the DELAY REQUEST after reception ofthe SYNC message, i.e., tS3 = tS2, for sake of simplicity.However, it is important to stress that neither the initial clocksynchronization nor the immediate sending of DELAY REQUESTare a prerequisite for the proposed method. This is essential foravoiding DELAY REQUEST message collisions from multipleslaves following SYNC multicasts by the master, which couldcause link-layer collisions in the network. However, the(in)equations below consider already separate timestamps tS2and tS3, so slaves can use random delays after receiving SYNCto avoid potential collisions.

In Fig. 12, the master sends the SYNC message at timetM1 = 0 and receives the slave’s DELAY REQUEST at timetM4 = 14. The slave receives the master’s timestamp tM4 = 14in the DELAY RESPONSE message and computes the RTD as14 (according to Eq. 1). The default assumption of PTP isthat communication paths are symmetrical and, therefore, thetimestamps tS2 = tS3 must be mapped to the center of themaster’s interval, i.e. tS2 = tS3 = 7 as shown in Fig. 12.

Unless there is specific information available on physicaldelays for the forward and reverse communication path, itmust be assumed that the delay of one or both of thesepaths can be (close to) zero. This gives an adversary theopportunity to arbitrarily delay the master’s SYNC messageon the forward path or the slave’s DELAY REQUEST messageon the reverse path within the given window of 14 timeunits (as shown in Fig. 12). The MITM adversary canforward the master’s SYNC message without additional delay(SYNC EARLY) and delay the slave’s DELAY REQUEST EARLYmessage by 14 time units, resulting in slave timestampstS2-early = tS3-early = 0. Alternatively, the adversary candelay the master’s SYNC message (SYNC LATE) and forwardthe slave’s DELAY REQUEST LATE message without additionaldelay, resulting in slave timestamps tS2-late = tS3-late = 14.Therefore, depending on which scenario the adversary MITM


Fig. 13. Offset uncertainty bound calculation using one-way delay limits andunsynchronized clocks.

adopts, it can shift the slave’s offset within [−7, 7] timeunits (according to Eq. (2)). Whenever the slave depends onmaximum guaranteed bounds of its clock offset, this uncertaintymust be considered.

Bound Clock Offset With Knowledge on OWDs

In order to reduce the uncertainty and guarantee boundson the clock offset, we present a method that builds uponknowledge on physical parameters and constraints of theclock synchronization’s communication path. In this way, theattacker’s ability to conduct delay attacks is reduced, and theslave is supported in determining stricter guaranteed boundsfor its clock offset. It is worth noting that the method can onlymitigate delay attacks but not prevent them entirely.

We assume that the communication path is asymmetricand its minimum OWD is known for both directions. Wedenote the minimum OWD from master → slave as dMS

min andthe minimum OWD for slave → master as dSMmin. The exactmeasurement of OWDs depends on precisely synchronizedclocks, which is why in real-world scenarios dmin may beapproximated using topology and physical parameters likepropagation-, transmission- and processing delays of the net-work path’s links and components. A mandatory preconditionfor guaranteed clock offset bounds is that the approximatedOWD must be less or equal to the minimum real packet delayon the path. Conservative approximations on dMS

min and dSMmin,i.e., lower minimum OWD values are detrimental to the offsetbounds but are essential to guarantee the bounds in adversarialsettings.

For computing guaranteed offset bounds using dMSmin and

dSMmin, the slave first measures the RTD according to Eq. (1). InFig. 13 the forward communication path from master to slavehas a known minimum OWD of dMS

min = 2 and the reversepath a minimum OWD of dMS

min = 6 time units. Relying onthe minimum delay constraints, whenever the slave receivesthe master’s SYNC message it knows that the master assignedtimestamp tM1 at least dMS

min = 2 time units earlier thenthe slave’s reception timestamp tS2. The slaves also knowswhen sending its DELAY REQUEST message that the master willreceive it and assign timestamp tM4 at least dMS

min = 6 timeunits later then slave time tS3. Using this knowledge and the

timestamp tM4 it received in the master’s DELAY RESPONSEmessage, the slave can rely on the inequalities (5a) and (5b)to hold true.

Assuming an (unknown) clock offset offset between theslave and master clocks, the slave can define the causal orderingof timestamps using the inequalities Eq. (5a) and Eq. (5b).All terms except the offset being known, by reordering theinequalities the slave can bound its clock offset after a clocksynchronization interval by Eq. (5c).

tM1 + dMSmin + offset ≤ tS2 (5a)

tM4 ≥ tS3 + dSMmin − offset (5b)tS3 − tM4 + dSMmin ≤ offset ≤ tS2 − tM1 − dMS

min (5c)

Applying Eq. (5c) to the scenario in Fig. 13 yields bounds of[−6, 0] for the early case tS2 = tS3 = 2 and [0, 6] for the latecase tS2 = tS3 = 8, which maps to the uncertainty windowdepicted in the figure. In order to obtain a clock offset boundthat centers around 0 (despite asymmetric communicationpath and delay attacks), we suggest replacing clock offsetcalculation from Eq. (2) by Eq. (6), which basically averages theminimum and maximum offset, assuming that the uncertainty(i.e., difference between the measured RTD and the sum ofthe minimum OWDs dMS

min and dSMmin) affects the forward orreverse link with equal probability. In Fig. 13 the average offsetis mapped to the center of the marked uncertainty window.This yields a symmetrical interval for guaranteed clock offsetbounds that formally satisfy Eq. (7) with RTD = tM4 − tM1.For the scenario in Fig. 13, the new offset calculation resultsin the same size of the uncertainty window (i.e., 6) but theoffset within [−3, 3] centered around 0 (according to Eq. (7)).The knowledge of the physical delay therefore allows a stricterbound of the guaranteed clock offset compared to the casewithout knowledge on the OWDs presented in Fig. 12. In thisway, the adversary’s degree of freedom in manipulating clocksynchronization is effectively decreased and the guaranteedbounds on the clock offset are improved.

offset =offsetlow + offsethigh

2

=tS2 − tM1 − dMS

min + tS3 − tM4 + dSMmin2

(6)

−RTD − dMSmin − dSMmin2

≤ offset ≤ RTD − dMSmin − dSMmin2

(7)While the clock offset can be guaranteed after a clock

synchronization interval (Eq. (7)), the question about the clockoffset that can be guaranteed for a particular system remainsopen as an attacker could still increase the RTD arbitrarily(and therefore manipulate the clock offset). To prevent suchclock offset manipulation, the RTD that is accepted needsto be restricted. Intuitively, the lower the maximum RTDthat is accepted (RTDmax), the tighter the bound on theclock offset that can be guaranteed, but also the higher theprobability of clock synchronization intervals to be discardedduring unfavorable network conditions.


In order to derive clock offset bounds for a system, a timeTI needs to be defined that represents the maximum timeinterval between any two consecutive clock synchronizationintervals with RTD ≤ RTDmax. Between two consecutiveclock synchronization intervals, the slave clock drifts at mostTI ·|ρ|, with ρ being the maximum relative clock drift of slaveand master clocks. Generally one can say that the smaller thenetwork the smaller RTDmax, the better the network operationsthe smaller TI , and the better the clocks the smaller ρ. Eq. (8)shows the guaranteed clock offset bounds for a system.

−RTDmax − dMSmin − dSMmin

2− TI ·|ρ| ≤ offset

offset ≤ RTDmax − dMSmin − dSMmin

2+ TI ·|ρ|

(8)

While the relative clock offset can be bounded, it needs tobe stressed that high-precision clock synchronization requiressignificantly tighter clock synchronization guarantees than canbe provided by the bounds in Eq. (7) and (8). Deterministicnetworks might help as they provide guarantees on themaximum RTD and delay variation, but they depend on aprecise notion of time themselves in the first place.

It is worth noting that slaves can apply the algorithm that hasbeen described above for the SYNC and DELAY REQUEST mes-sage round-trip for the DELAY REQUEST DELAY RESPONSEmessage exchange, too. The PTP protocol does not eval-uate the DELAY RESPONSE message’s delay as part of itsoperation, which is why the SYNC and DELAY REQUESTmessage exchange is the preferred one for clock bounding.However, the slave could acquire the DELAY RESPONSE re-ceiving timestamp and use it to compute clock bounds forDELAY REQUEST DELAY RESPONSE. One possible applicationis, for instance, the detection of selective SYNC message delaysconducted by a resource-limited adversary. The clock offsetbounds of the SYNC DELAY REQUEST round-trip being sub-stantially larger (inaccurate) than the one of DELAY REQUESTDELAY RESPONSE could be a strong indication of an ongoingselective delay attack. Still, the general observation holds true:none of these methods can protect against an asymmetricallink delay attack that an adversary with unlimited resourcescan conduct.

X. CLOCK SYNCHRONIZATION: EITHER PRECISE ORSECURE

The outcome of Section VIII that an attacker can manipulateoffset correction by

[−δ12 , δ22

]through link asymmetry raises

the question whether a clock synchronization protocol canbe designed that handles link asymmetry such that its offsetcalculation remains unaffected in an adversarial setting. Weargue that constructing such protocol is impossible as delaycannot be distinguished from clock offset. Main reason isthat link asymmetry can only be measured with synchronizedclocks, and it can not be guaranteed that the link asymmetryis constant (especially in an adversarial setting). Synchronizedclocks would be required in the first place to measure linkasymmetry in order to have secure clock synchronization afterall, which is circular reasoning.

If we suppose an oracle to exist that can instantaneously readthe clocks of master and slave, the oracle has knowledge of thereal clock offset (according to Eq. (2)) and is not influencedby link asymmetry. The clock offset measured by the slavealso includes the link asymmetry (Eq. (9)), however.

offsetmeasured = offsetreal +δ2 − δ1

2(9)

If the oracle analyzes two consecutive offset measurements(at time i and i+1) during which clock offset was not corrected,it would observe that the difference between the offsetsmeasured at time i and at time i+1 consists of two distinct parts:(1) the change in the real offset (offsetreali+1

−offsetreali ) thatis a result of the relative clock drift between slave and master,and (2) the change in the link asymmetry that is determined bydelay variation (

δ2i+1−δ1i+1

2 − δ2i−δ1i2 ) such as network jitter

for example.The relative clock drift, which determines the change of the

real offset, depends on the quality of the physical oscillatorsused and typically ranges from 101 to 10−6 ppm. The delayvariation is highly indeterministic and depends on variousfactors such as the current network load as well as thequality of the network and its components. Delay variationtypically ranges from 105 to 102 ppm. Important to note isthat delay variation is by several orders of magnitudes largerthan the relative clock drift, and that only an oracle coulddistinguish the change of the real clock offset from the changeof the link asymmetry. For master and slave, however, theyare indistinguishable as only the sum of the change can beobserved in terms of measured clock offset. This means thatan attacker can exploit this indistinguishability to conduct andhide an asymmetric link delay attack. As soon as a clocksynchronization protocol aims to achieve high precision, itneeds to entail delay measurements in order to compensate fordelays. And this delay compensation mechanism is susceptibleto asymmetric links because link delay variation cannot beseparated from clock drift.

The other issue is the direction of messages. To conduct anasymmetric link delay attack, the attacker only needs to knowthe direction of messages, which is tied to the master and slaveroles because it is always the clock offset of the slave relative tothe master that is calculated. Delaying messages in one directionhas the inverse effect on clock synchronization than delayingmessages in the reverse direction (as the slave clock shouldbe synchronized to the master and not the other way around).For this reason we conclude that no clock synchronizationprotocol can be designed that is precise and prevents delayattacks entirely (even when messages are obfuscated in termsof length and timing and cover traffic exists).

If clock synchronization protocols can be either high-precision or secure against delay attacks, then applicationsmust not rely on a precise notion of time when employinguntrusted communication networks — if applications rely ona precise notion of time, then they must only be executed intrusted environments. This conclusion is (not limited to but)especially important to critical infrastructures.

REFERENCES 14

XI. CONCLUSION

In this paper, we focused on attacks against clock syn-chronization protocols in the time domain, which means thatprotocol message content is not altered and only the timingof messages is changed. One assumption is that the attackeris in a privileged network position12. We first conducted astatistical traffic analysis of PTP and identified properties ofPTP traffic with regard to timing, packet length, and packetdirections. We showed that these properties can be used toidentify PTP messages in encrypted traffic in order to conductselective message delay attacks.

We explored various countermeasures to mitigate selectivemessage delay attacks. The first set of countermeasures aimsto obstruct traffic analysis. To this end, PTP can be modifiedin a way that randomizes the timings and the use of packetlength padding, although such modification may have a negativeimpact on the clock synchronization’s precision. Security,nevertheless, depends on the existence of suitable cover traffic,which leads to the field of traffic obfuscation. Furthermore, strictreplay protection should be activated if possible to minimizethe impact of the attack (and to make the attack easier to detectas the packet loss rate increases).

Then we introduced asymmetric link delay attacks. Whileasymmetric link delay attacks have potentially lower impacton clock synchronization’s precision, we found that they arefundamentally tied to the goal of high-precision. Bounding theuncertainties of the clock offset by applying knowledge of thephysical parameters of the communication path (i.e., limitingOWDs) ensures that individual messages cannot be delayedarbitrarily. Until now, network-based clock synchronizationprotocols asked for deterministic delays, and delays couldbe either symmetric or have a known asymmetry to becompensated by the PTP configuration. The results showthat knowledge of the underlying communication networks isessential to mitigate delay attacks and to safeguard maximumguaranteed bounds on clock offset. Nevertheless, asymmetriclink delay attacks can only be mitigated but not be preventedentirely.

We argue that no high-precision clock synchronizationprotocol can exist that prevents asymmetrical link delay attacksentirely because of the delay compensation mechanism thatis required to achieve high-precision. In adversarial settings,an attacker can manipulate the delay variation in such a waythat links become asymmetric and clock offset calculation isimpaired maliciously since clock drift and delay variation can-not be distinguished. This implies that clocks synchronizationcannot be arbitrarily precise while maintaining security againstdelay attacks. This finding contradicts the common belief thatclocks synchronization over untrusted networks can be securedby encryption and authentication methods, while improvingprecision. Given the results from this paper, we argue the

12While we assume the difficulty of gaining such privileged network positionis within the power of an attacker who attacks critical infrastructures, wethink that asymmetric link delay attacks specifically might be conducted evenfrom non-privileged network positions by influencing the queues of networkdevices in a particular direction (for example by sending an excessive numberof packets).

contrary: clock synchronization can either be precise or secureagainst delay attacks (but not both!).

Delay attacks are an inherent threat for high-precisionclock synchronization since the times when messages are sentand received have an actual effect on the precision of clocksynchronization and even small differences can have a largeimpact. The impact of those delay attacks can only be boundedbut those attacks limit the precision of clock synchronization,nevertheless. Practically achievable limits are certainly stricterthan some critical infrastructure applications assume today.Those infrastructures are supposed to improve specific areasbut also introduce a new attack vector by their strict dependencyon a precise notion of time.

REFERENCES

[1] IEC/TR 61850-90-1:2010. Communication networks and sys-tems for power utility automation – Part 90-1: Use ofIEC 61850 for the communication between substations. IEC,Geneva, Switzerland, Mar. 2010.

[2] “IEEE Standard for Synchrophasor Measurements for PowerSystems”. In: IEEE Std C37.118.1-2011 (Revision of IEEE StdC37.118-2005) (Dec. 2011), pp. 1–61. DOI: 10.1109/IEEESTD.2011.6111219.

[3] Council of European Union. Directive 2014/65/EU of theeuropean parliament and of the council of 15 May 2014on markets in financial instruments and amending Directive2002/92/EC and Directive 2011/61/EU. https://eur-lex.europa.eu/eli/dir/2014/65/oj. 2014.

[4] European Commision. Commission delegated regulation (EU)of 7.6.2016 supplementing Directive 2014/65/EU of the Euro-pean Parliament and of the Council with regard to regulatorytechnical standards for the level of accuracy of business clocks.http : / / ec . europa .eu /finance / securities /docs / isd /mifid / rts /160607-rts-25 en.pdf. 2016.

[5] European Commision. Annex to the Commission delegatedregulation supplementing Directive 2014/65/EU of the Euro-pean Parliament and of the Council with regard to regulatorytechnical standards for the level of accuracy of business clocks.http : / / ec . europa .eu /finance / securities /docs / isd /mifid / rts /160607-rts-25-annex en.pdf. 2016.

[6] Telecommunication standardization sector of ITU. Time andphase synchronization aspects of telecommunication networks.https://www.itu.int/rec/T-REC-G.8271-201708-I. 2017.

[7] S. Frankel and S. Krishnan. IP Security (IPsec) and InternetKey Exchange (IKE) Document Roadmap. RFC 6071 (Infor-mational). RFC. Fremont, CA, USA: RFC Editor, Feb. 2011.DOI: 10.17487/RFC6071. URL: https://www.rfc-editor.org/rfc/rfc6071.txt.

[8] “IEEE Standard for Local and metropolitan area networks–Port-Based Network Access Control”. In: IEEE Std 802.1X-2010(Revision of IEEE Std 802.1X-2004) (Feb. 2010), pp. 1–205.DOI: 10.1109/IEEESTD.2010.5409813.

[9] E. Rescorla. The Transport Layer Security (TLS) ProtocolVersion 1.3. RFC 8446 (Proposed Standard). RFC. Fremont,CA, USA: RFC Editor, Aug. 2018. DOI: 10.17487/RFC8446.URL: https://www.rfc-editor.org/rfc/rfc8446.txt.

[10] Mark L. Psiaki and Todd E. Humphreys. Protecting GPSFrom Spoofers Is Critical to the Future of Navigation. https://spectrum.ieee.org/telecom/security/protecting- gps- from-spoofers-is-critical-to-the-future-of-navigation. 2016.

[11] “IEEE Standard for a Precision Clock Synchronization Protocolfor Networked Measurement and Control Systems”. In: IEEEStd 1588-2008 (July 2008), pp. 1–269. DOI: 10.1109/IEEESTD.2008.4579760.

http://dx.doi.org/10.1109/IEEESTD.2011.6111219


https://eur-lex.europa.eu/eli/dir/2014/65/oj

https://eur-lex.europa.eu/eli/dir/2014/65/oj

http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25_en.pdf

http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25_en.pdf

http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf

http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf

https://www.itu.int/rec/T-REC-G.8271-201708-I

http://dx.doi.org/10.17487/RFC6071

https://www.rfc-editor.org/rfc/rfc6071.txt





https://spectrum.ieee.org/telecom/security/protecting-gps-from-spoofers-is-critical-to-the-future-of-navigation






[12] T. Mizrahi. Security Requirements of Time Protocols in PacketSwitched Networks. RFC 7384 (Informational). RFC. Fremont,CA, USA: RFC Editor, Oct. 2014. DOI: 10.17487/RFC7384.URL: https://www.rfc-editor.org/rfc/rfc7384.txt.

[13] Jonathan Katz. Digital Signatures. Boston, MA: Springer US,2010. ISBN: 978-0-387-27711-0 978-0-387-27712-7.

[14] Qingyu Yang, Dou An, and Wei Yu. “On time desynchro-nization attack against IEEE 1588 protocol in power gridsystems”. In: IEEE Energytech. May 2013, pp. 1–5. DOI:10.1109/EnergyTech.2013.6645332.

[15] Jeanette Tsang and Konstantin Beznosov. A Security Analysisof the Precise Time Protocol. LERSSE technical report,Electrical and Computer Engineering, University of BritishColumbia, Vancouver, Canada, LERSSE-TR-2006-02, 2005.

[16] Jeanette Tsang and Konstantin Beznosov. “A Security Analysisof the Precise Time Protocol (Short Paper)”. In: Springer, 2006,pp. 50–59.

[17] A. Treytl and B. Hirschler. “Security flaws and workaroundsfor IEEE 1588 (transparent) clocks”. In: IEEE InternationalSymposium on Precision Clock Synchronization for Measure-ment Control and Communication (ISPCS). Oct. 2009, pp. 1–6.DOI: 10.1109/ISPCS.2009.5340204.

[18] N. Moreira et al. “Security mechanisms to protect IEEE1588 synchronization: State of the art and trends”. In: IEEEInternational Symposium on Precision Clock Synchronizationfor Measurement, Control, and Communication (ISPCS). Oct.2015, pp. 115–120. DOI: 10.1109/ISPCS.2015.7324694.

[19] Dieter Sibold, Stephen Roettger, and Kristof Teichel. Net-work Time Security. Internet-Draft draft-ietf-ntp-network-time-security-15. https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-15. IETF Secretariat, Sept. 2016. (Visited on10/06/2018).

[20] Dieter Sibold, Stephen Roettger, and Kristof Teichel. Usingthe Network Time Security Specification to Secure the NetworkTime Protocol. Internet-Draft draft-ietf-ntp-using-nts-for-ntp-06.https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-13.IETF Secretariat, Sept. 2016. (Visited on 10/06/2018).

[21] Dieter Sibold et al. Protecting Network Time Security Messageswith the Cryptographic Message Syntax (CMS). Internet-Draftdraft-ietf-ntp-cms-for-nts-message-06. https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-message-06. IETF Secretariat,Feb. 2016. (Visited on 10/06/2018).

[22] E. Itkin and A. Wool. “A security analysis and revisedsecurity extension for the precision time protocol”. In: IEEEInternational Symposium on Precision Clock Synchronizationfor Measurement, Control, and Communication (ISPCS). Sept.2016, pp. 1–6. DOI: 10.1109/ISPCS.2016.7579501.

[23] Eyal Itkin and Avishai Wool. “A Security Analysis and RevisedSecurity Extension for the Precision Time Protocol”. In: CoRRabs/1603.00707 (May 28, 2016). URL: http://arxiv.org/abs/1603.00707.

[24] L. Ellegaard. PTP Security using MACsec. Tech. rep. https:/ / ieee- sa .centraldesktop .com/1588/file /33390811/. P1588Working Group, Aug. 2014.

[25] T. Koskiahde, J. Kujala, and T. Norolampi. “A sensor networkarchitecture for military and crisis management”. In: IEEEInternational Symposium on Precision Clock Synchronizationfor Measurement, Control and Communication. Sept. 2008,pp. 110–114. DOI: 10.1109/ISPCS.2008.4659223.

[26] T. Mizrahi. “Time synchronization security using IPsec andMACsec”. In: International IEEE Symposium on PrecisionClock Synchronization for Measurement Control and Com-munication (ISPCS). 2011 International IEEE Symposium onPrecision Clock Synchronization for Measurement Controland Communication (ISPCS). Sept. 2011, pp. 38–43. DOI:10.1109/ISPCS.2011.6070153.

[27] A. Treytl and B. Hirschler. “Securing IEEE 1588 by IPsectunnels - An analysis”. In: International IEEE Symposium onPrecision Clock Synchronization for Measurement Control and

Communication (ISPCS). 2010 International IEEE Symposiumon Precision Clock Synchronization for Measurement Controland Communication (ISPCS). Sept. 2010, pp. 83–90. DOI:10.1109/ISPCS.2010.5609765.

[28] Tal Mizrahi. “A game theoretic analysis of delay attacksagainst time synchronization protocols”. In: InternationalIEEE Symposium on Precision Clock Synchronization forMeasurement Control and Communication (ISPCS). IEEE,2012, pp. 1–6.

[29] M. Ullmann and M. Vogeler. “Delay attacks - Implicationon NTP and PTP time synchronization”. In: InternationalSymposium on Precision Clock Synchronization for Measure-ment, Control and Communication. Oct. 2009, pp. 1–6. DOI:10.1109/ISPCS.2009.5340224.

[30] Elena Lisova et al. “Protecting Clock Synchronization: Adver-sary Detection through Network Monitoring”. In: Journal ofElectrical and Computer Engineering 2016 (2016), pp. 1–13.ISSN: 2090-0147, 2090-0155. DOI: 10.1155/2016/6297476.URL: http://www.hindawi.com/journals/jece/2016/6297476/(visited on 02/08/2017).

[31] Robert Annessi, Joachim Fabini, and Tanja Zseby. SecureTime:Secure Multicast Time Synchronization. May 2017. eprint:arXiv:1705.10669.

[32] L. Narula and T. E. Humphreys. “Requirements for SecureClock Synchronization”. In: IEEE Journal of Selected Topicsin Signal Processing 12.4 (Aug. 2018), pp. 749–762. ISSN:1932-4553. DOI: 10.1109/JSTSP.2018.2835772.

[33] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303(Proposed Standard). RFC. Fremont, CA, USA: RFC Editor,Dec. 2005. DOI: 10.17487/RFC4303. URL: https://www.rfc-editor.org/rfc/rfc4303.txt.

[34] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)Specification. RFC 2460 (Draft Standard). RFC. Obsoleted byRFC 8200, updated by RFCs 5095, 5722, 5871, 6437, 6564,6935, 6946, 7045, 7112. Fremont, CA, USA: RFC Editor,Dec. 1998. DOI: 10.17487/RFC2460. URL: https://www.rfc-editor.org/rfc/rfc2460.txt.

[35] P. Carlen. “Traffic Flow Confidentiality mechanisms and theirimpact on traffic”. In: 2013 Military Communications andInformation Systems Conference. Oct. 2013, pp. 1–6.



http://dx.doi.org/10.1109/EnergyTech.2013.6645332

http://dx.doi.org/10.1109/ISPCS.2009.5340204


https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-15

https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-15

https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-13

https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-message-06

https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-message-06


http://arxiv.org/abs/1603.00707

http://arxiv.org/abs/1603.00707

https://ieee-sa.centraldesktop.com/1588/file/33390811/

https://ieee-sa.centraldesktop.com/1588/file/33390811/





http://dx.doi.org/10.1155/2016/6297476

http://www.hindawi.com/journals/jece/2016/6297476/

arXiv:1705.10669

http://dx.doi.org/10.1109/JSTSP.2018.2835772







Date post:	13-Jul-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

R. ANNESSI, J. FABINI, F.IGLESIAS, AND T. ZSEBY: ENCRYPTION IS FUTILE: DELAY … · 2018-11-22 ·...

Documents