Clocks and Security
Posted in: Security
I keep running into this.
People want to design protocols where replay attacks are prevented. To prevent replay attacks, you have to keep track of what’s already been said. But you don’t want to do this forever, so the smart thing to do is include time in the protocol. That is, the message is accepted if both the timestamp is recent and the nonce (or whatever) has not previously been used. This means that the server can discard nonces after a while and not worry about allowing replays of very old packets.
But then the problem is that clients don’t have the right time.
And so people jump through hoops to take account of this fact – extra round trips, time offsets, all sorts of nonsense.
Can we stop dancing around the problem and just fix the damn client’s clock? If the user wants the clock set wrong, fine – all we need is a correct clock for protocols. The machine can continue to show the user whatever wrong time he wants to see.
So how do we get this correct clock? Well, that doesn’t seem hard – we have NTP already, and it works pretty well. If we have mutually distrusting parties that don’t want to rely on each other’s clocks, then it doesn’t seem hard to have clocks with signatures (NTP already supports this) so each distrusting group can nominate its trusted time servers and multiple clocks can be maintained for them.
This seems like an entirely soluble problem, yet every time I review a protocol that needs it, it is thrown up as completely insoluble. It really seems like it’s time to bite that bullet – it’s not even hard (a rubber bullet?)!
Note: this does not solve any problems to do with untrusted clients. You still need to design your protocols to resist clients that want to mess with you. But at least you could stop worrying about time skew.
Return to: Clocks and Security