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:


A client sends a request with a 128-bit randomly generated nonce to the authority, and starts a timer.
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).
The client waits until a response is received or until $2\delta$ seconds have passed.
The client stops the timer, having measured $\Delta t$ since it started, and verifies that ${\Delta t \over 2} &lt; \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.
Yes, this is a perfectly secure solution.

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.

Despite what has been claimed in the comments, the nonce is essential to security (otherwise a man-in-the-middle could trivially break the protocol).  Keep the nonce.  Do not remove it.  I think you know all that already, just re-emphasizing it for clarity.