- ...Protocol
- Most of this work was
done at UC Berkeley and IBM Research. The authors can be reached
at
adrian+@cs.cmu.edu, canetti@watson.ibm.com,
tygar@cs.berkeley.edu, skyxd@cs.cmu.edu.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...sender.
- The security of this time synchronization protocol relies on
the unpredictability of the nonce - if an attacker could predict the
receiver's nonce, it could send a time synchronization request to the sender
with that nonce, and replay the response later to the receiver.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...nonce.
- Interestingly, the processing and propagation delay of the
response message does not change (assuming that the sender
immediately records and replies with the arrival time of the request packet),
since the receiver is only interested in an upper bound on the sender's clock.
If the receiver were interested in the lower bound on the sender's clock, the
processing delay and delay of the response message would matter. For more
details on this refer to the more detailed time synchronization
description [30].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...created.
- For details on how to handle broadcast
streams of unbounded duration by switching one-way key chains,
see [27]. For this article we assume that chains are
sufficiently long for the duration of communication.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...resistance.
- See our earlier paper for a formal
security proof [28].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.