Any problems with this secure time synchronization scheme?

Question

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} < \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.

@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 07 '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 07 '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 07 '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 07 '13 at 23:19
@B-Con Without the nonce a MITM adversary could've sent and received a request to the server $100\delta$ seconds ago and then send that as a response to the client's request, obviously violating the inaccuracy restraints. — orlp, Aug 07 '13 at 23:29
@nightcracker: True, that too. And I had missed your statement (of course forge-able signatures are worthless, was just stating the obvious due to (what I thought was) no info on key distribution). — B-Con, Aug 07 '13 at 23:35
The server should also send how long it took to perform the signature operation, so that can be taken into account when calculating the differential. — Richie Frame, Sep 03 '13 at 17:52
@RichieFrame But that data would need to be signed as well! How would you solve that? (it's signatures all the way down) — orlp, Sep 03 '13 at 18:02
A digital signature operation should take a fairly specific time depending on system resources. If the signing operation is high thread priority, the server can pre-benchmark and send the expected time as part of the signed message. — Richie Frame, Sep 04 '13 at 00:22

score 7 · Accepted Answer · answered Aug 08 '13 at 21:26

7

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.

answered Aug 08 '13 at 21:26

D.W.

36,365
13
102
187

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 08 '13 at 21:37
1

@nightcracker, alas, I don't know of any literature on it. On first glance, it hardly seems possible (though maybe I shouldn't say that, maybe someone has some clever way that hasn't occurred to me). I wasn't aware that there was any issue with literature recommendations; my impression is that there's an issue with open-ended questions that solicit many answers ("what's the best book on cryptography?"), but not focused questions ("what's the state of the art on X?"), particularly if you done some searching on your own first. – D.W. Aug 09 '13 at 08:52
This close reason made me think that: "Requests for reference recommendations are off-topic here." – orlp Aug 09 '13 at 08:56
3

@nightcracker: Our very first meta question was about literature recommendations (but see also this later question). Generally, I'd say the SE network frowns on 1) vague subjective questions with many equally valid answers and 2) answers that only link to external resources. Asking "What's a good book about X?" tends to fall into both categories, whereas "Is there any way to do X?" doesn't. – Ilmari Karonen Aug 09 '13 at 10:16

Any problems with this secure time synchronization scheme?

1 Answers1