Our previous schemes used a fixed or predictable sender schedule, with each recipient knowing the exact sending time of each packet. Since this severely restricts the flexibility of senders, we design a scheme which allows senders to send at dynamic transmission rates, without the requirement that every receiver needs to know about the exact sending schedule of each packet. The solution to this problem is to pick the MAC key and the disclosed key in each packet only on a time interval basis instead of on a packet index basis. The sender uses the same key to compute the MAC for all packets which are sent in the same interval . All packets sent in interval disclose the key .
At session set-up the sender announces values and , where the former is the starting time of the first interval and the latter is the duration of each interval. In addition the delay parameter is announced. These announcements are signed by the sender. The interval index at any time period is determined as . A key is associated with each interval . The keys are chained in the same way as in Scheme II. The sender uses the same key to compute the MAC for each packet which is sent in interval . Every packet also carries the interval index and discloses the key of a previous interval . We refer to as disclosure lag. The format of packet is . Figure 3 shows an example of this scheme, where .
pj pjp1 pjp2 pjp3 pjp4 pjp5 pjp6 kip2 kip3 kip4 kip5 kip6 kip7
Figure 3: Scheme IV.
The MAC key and disclosed key are only
dependent on the time interval. The authentication key of is
which is disclosed by packets sent during interval . In this
case, packet discloses key which allows the receiver
to compute and to authenticate packet . We would like to point
out that packets and are both authenticated with the
same MAC key , because they were sent in the same time interval.
In this scheme, the receiver verifies the security condition as follows. Each receiver knows the values of , , and . ( is the value obtained from the initial synchronization protocol.) Assume that the receiver gets packet at its local time , and the packet was apparently sent in interval . The sender can be at most in interval . The security condition in this case is simply , which ensures that no packet which discloses the value of the key could have been sent yet. Figure 4 illustrates the verification of the security condition.
It remains to describe how the values and are picked. (We stress that the choice of these values does not affect the security of the scheme, only its usability.) Before the sender can pick values for and , it needs to determine the maximum tolerable synchronization uncertainty , and the maximum tolerable network delay . The sender defines
The sender's choice for and both present a tradeoff. First, a large value for will allow slow receivers to verify the security condition correctly, but requires a long delay for packet authentication. Conversely, a short will cause slow receivers to drop packets because the security condition is not satisfied. The second tradeoff is that a long interval duration saves on the computation and storage overhead of the key chain, but a short more closely achieves the desired .
After determining , , and , the disclosure lag is .
This scheme provides numerous advantages. First, the sender can predict how long a pre-computed key chain lasts, since the number of necessary keys is only time dependent and not on the number of packets sent. Second, the receiver can conveniently verify the security condition and the sender does not need to send its packets at specific intervals (we will discuss the details of this in Section 2.9). Another advantage is that new receivers can easily join the group at any moment. A new group member only needs to synchronize its time with the sender and receive the interval parameters and a commitment to the key chain.
mdt pdt
Figure 4: The security condition visualized.
The packet is sent in the interval where key is active.
The receiver receives the packet when the sender is in interval ,
but due to the the sender might already be in interval ,
which discloses key . This is not a problem for the current packet,
so key was not disclosed yet, hence the security condition is
satisfied and the packet is safe.