Direct Time Synchronization

In direct time synchronization, the receiver performs an explicit time synchronization with the sender. This approach has the advantage that no extra infrastructure is needed to perform the time synchronization. We design a simple two-phase protocol that satisfies the TESLA requirements.

In the protocol, the receiver first records its local sending time $t$_R and sends a time synchronization request containing a nonce to the sender. Upon receiving the time synchronization request, the sender records its local receiving time $t$_S and sends the receiver a signed response packet containing $t$_S and the nonce.

Figure 4 shows a sample time synchronization between the receiver and the sender. Upon receiving the signed response, the receiver checks the validity of the signature and the matching of the nonce and computes $\Delta \; =\; t$_S - t_R. It is easy to see that the $\Delta$ computed this way satisfies the requirement that $\Delta \delta$. Because $\Delta =\; t$_S - t_R = (t_S - t₃) + (t₃ - t_R), $t$_S - t₃ = δ, and $t$₃ - t_R is the network delay for sending the request from the receiver to the sender which is greater or equal to $0$, hence $\Delta \delta$. An interesting point is that the network delay of the response packet and the delay caused by the computation of the digital signature do not influence $\Delta$ at all. Since only the initial timestamp matters, it is important that the sender immediately stores the arrival time $t$_S of the time synchronization request packet. The subsequent processing and propagation delay does not matter.

Because the digital signature operation is computationally expensive, we need to be careful about denial-of-service attacks where an attacker floods the sender with time synchronization requests. Section 4.1 addresses this issue.

t1$t$₁ t2$t$₂ t3$t$₃ tS$t$_S tR$t$_R

 
Figure 4: The receiver synchronizes its time with the sender.