# Any problems with this secure time synchronization scheme?

I have a time authority and I want to securely set a client's time to this authority's time/date within a precision of $\delta$ seconds. The authority's public key is known to the client. This was my idea:

1. A client sends a request with a 128-bit randomly generated nonce to the authority, and starts a timer.
2. The server replies with $time\_data$ and $sign(time\_data || nonce)$. $time\_data$ is some representation of time with a high precision and constant length (for example 16 bytes).
3. The client waits until a response is received or until $2\delta$ seconds have passed.
4. The client stops the timer, having measured $\Delta t$ since it started, and verifies that ${\Delta t \over 2} < \delta$. Then it verifies the signature using the given time data and the latest sent nonce. If everything passes then it sets the time to $time\_data + {\Delta t \over 2}$. If not go back to step 1.

As far as I can see there is no attack on this scheme that allows any adversary to let the client accept a time that is not within $\delta$ seconds of the actual time of the authority. Am I missing something?

I'm also wondering if there's any way to improve precision above the minimum delay $\Delta t$ of the network without losing security of the synchronized time, similar to what NTP does with estimating network latency.

-
Why not simply use NTP over TLS? – Stephen Touset Aug 7 '13 at 21:21
@StephenTouset I don't know (and haven't found accesible modern literature) how secure NTP is against active attackers. And it kind of blows my technology stack out of the water in terms of complexity, both server-side and client-side. And doesn't NTP use UDP? – orlp Aug 7 '13 at 21:29
@StephenTouset Also I just realized TLS will likely be too expensive considering the budget and the expected workload of the server infrastructure. – orlp Aug 7 '13 at 21:53
@Thomas Why? 1) Then nonce serves as a challenge, else an attacker could simply return an old signed time. The nonce is an essential part of this scheme. 2) A signature scheme may or may not be randomized. I don't see how that matters here. – CodesInChaos Aug 7 '13 at 23:14
@B-Con: 1) Read: "The authority's public key is known to the client.". Also, what's the point of a signature if an adversary is assumed to be able to forge one? 2) Yes, the client should only accept the latest sent nonce - let me edit the question clearing that up a bit more. – orlp Aug 7 '13 at 23:19

The principle drawback is that the precision available is limited by the round-trip time to the trusted time server. If the trusted time server is 50ms away (i.e., 100ms round-trip time), which is a plausible situation that might arise in real life, then you cannot synchronize the client's time to within a guaranteed precision of better than $\pm$ 50ms (or so). If this is adequate for your purposes, then yes, this is a fine solution. If this is not enough precision, then you have a harder problem, and I'm not sure whether there's anything you can do in the presence of an active adversary.
Thanks, that confirms my idea. I know Crypto.SE disapproves of literature recommendations, but do you know any literature on securely (that is with a provable precision bound $\delta$) synchronizing time beyond the latency of the connection, possibly affected by an active adversary? – orlp Aug 8 '13 at 21:37