A hybrid scheme for multicast authentication over lossy ... - CiteSeerX

7 downloads 104422 Views 187KB Size Report
Digital signature amortization;. Efficient signature schemes. Abstract For multicast communication, authentication is a challenging problem, since it requires that ...
Computers & Security (2004) 23, 705e713

www.elsevier.com/locate/cose

A hybrid scheme for multicast authentication over lossy networks Heba K. Aslan The Electronics Research Institute, Cairo, Egypt Received 30 January 2004; revised 14 June 2004; accepted 18 June 2004

KEYWORDS Group key distribution protocols; Authentication protocols; Multicast communication; Digital signature amortization; Efficient signature schemes

Abstract For multicast communication, authentication is a challenging problem, since it requires that a large number of recipients must verify the data originator. Many of multicast applications are running over IP networks, in which several packet losses could occur. Therefore, multicast authentication protocols must resist packet loss. Other requirements of multicast authentication protocols are: to perform authentication in real-time and to have low communication and computation overheads. In the present paper, a hybrid scheme for authenticating real-time data applications, in which low delay at the sender is acceptable, is proposed. In order to provide authentication, the proposed scheme uses both public key signature and hash functions. It is based on the idea of dividing the stream into blocks of m packets. Then a chain of hashes is used to link each packet to the one preceding it. In order to resist packet loss, the hash of each packet is appended to another place in the stream. Finally, the first packet is signed. The proposed scheme resists packet loss and is joinable at any point. The proposed scheme is compared to other multicast authentication protocols. The comparison shows that the proposed scheme has the following advantages: first, it has low computation and communication overheads. Second, it has reasonable buffer requirements. Third, the proposed scheme has a low delay at the sender side and no delay at the receiver side, assuming no loss occurs. Finally, its latency equals to zero, assuming no loss occurs. ª 2004 Elsevier Ltd. All rights reserved.

Introduction In recent years, applications that are of multicast nature (such as teleconference, pay per view, financial stock quote distribution, ., etc) have E-mail address: [email protected].

increased considerably. A paramount requirement for multicast communication is to provide confidentiality and authenticity. Confidentiality means that only the group members could obtain group messages. In the literature, many solutions have been proposed to solve the confidentiality problem (Ateniese et al., 2000; Mittra, 1997; Perrig et al., 2001a). Authenticity means that the recipient

0167-4048/$ - see front matter ª 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.cose.2004.06.010

706 could verify the identity of the sender and ensures that the received message comes from the supposed originator. For multicast communication, authentication is a challenging problem, since it requires that a large number of recipients must verify the data originator. Assume a group containing n members. A naı¨ve solution is to use a shared symmetric key between the sender and each recipient to calculate different Message Authentication Codes (MACs). Then, the sender appends the calculated MACs to the group message. Upon receiving the message, each recipient ensures the authenticity of the message using the MAC calculated by the key shared between it and the sender. This solution has a high communication overhead since in order to ensure the authenticity of a message n MACs must be appended to it. Another solution is to use the private key of the sender to sign a hash of the entire message. This solution suffers from the high computation and communication overheads since the signature algorithms require large computation and produce large output signatures. The abovementioned solutions do not resist packet loss, since the loss of any packet of the message will cause the inability to authenticate the received packets. This is due to the fact that the MAC or the signature is calculated over the whole message. In order to resist packet loss, one solution is to calculate MAC or signature for every packet. This solution will suffer from a huge amount of communication and computation overheads. Two solutions for providing multicast authentication are proposed: the first is to design more efficient signature schemes (Rohatgi, 1999; Perrig, 2001; Reyzin and Reyzin, 2002; Wong and Lam, 1999). The latter is to amortize signature over several packets (Wong and Lam, 1999; Gennaro and Rohatgi, 1997; Golle and Modadugo, 2001). While designing more efficient signature schemes overcomes the computational overhead problem, it still suffers from the communication overhead problem. On the other hand, amortizing signature over several packets overcomes the communication overhead problem. In multicast communication, two types of communication exist: pre-recorded and real-time data. In pre-recorded data, the content is known in advance, such as films. On the other hand, for real-time data, the content is produced in realtime, such as financial stock quotes. In the present paper, a hybrid scheme for authenticating real-time data applications is proposed where a low delay at the sender is acceptable. In order to provide authentication, the proposed scheme uses both public key signature and hash functions.

H.K. Aslan The proposed scheme has low computation and communication overheads. It is based on the work done by Gennaro and Rohatgi (1997) and the enhancement to their work proposed by Golle and Modadugo (2001). The proposed scheme resists packet loss and has the ability to authenticate each packet as soon as it arrives assuming no loss occurs, which is a basic requirement for real-time applications as will be stated in the next section. The paper is organized as follows: in the next section, requirements for multicast authentication protocols are stated. Then, related work is detailed. In the following section, a description of the proposed scheme is given. Then, a comparison of GennaroeRohatgi, Wonge Lam, GolleeModadugu, TESLA and the proposed scheme is given. Finally, the paper is concluded in the last section.

Requirements for multicast authentication protocols According to Wong and Lam (1999) and Pannetrat and Molva (2003), multicast authentication protocols have several requirements that are summarized below: - Delay at sender and receiver: flows that are real-time in nature need fast processing at sender as well as at receiver. - Buffering resources: the number of packets that have to be stored in both the sender and the receiver in order to carry out the authentication process. - Robustness: the ability of the recipient to authenticate the received packet, even in case of losses in the network. - Joinability: the ability of the recipient to start authentication at any arbitrary point in the flow. - Latency: the maximum number of packets that need to be received before a packet can be authenticated. - Computational cost: the computational cost of the protocol. - Communication cost: the number of bytes per packet that need to be appended in order to provide multicast authentication. An ideal protocol is the one that has the lowest possible delay at both sender and receiver and its required buffering resources are as low as possible. Further, it must be able to authenticate

Hybrid scheme for multicast authentication over lossy networks the received packet despite losses over the network and it must be joinable at any point. Other requirements of the multicast authentication protocol are: it has no latency and its communication and computation costs are as low as possible. It is difficult to design such an ideal protocol and a compromise must be made to obtain an efficient authentication protocol. In the next section, some multicast authentication protocols are given.

Related work One solution to the multicast authentication problem is to use the private key of the sender to sign a hash of each packet of the message. This solution suffers from the high computation and communication overheads since signature algorithms require large computation and produce large output signatures about 1024 bits (Pannetrat and Molva, 2003). To solve the multicast authentication problem, two approaches have been proposed: design more efficient signature schemes and amortize the cost of signature over several packets. For the first approach, efficient digital signature schemes have been proposed by Rohatgi (1999) and Wong and Lam (1999). Although these schemes overcome the computational problem, they suffer from the communication overhead problem, which makes them impractical for real-time applications. Perrig (2001) proposed BIBA, a one-time signature and broadcast authentication protocol. BIBA has a low verification overhead and a relatively small signature size. Although BIBA enhances the computation overhead, its communication overhead is slightly smaller than a traditional public key signature. Reyzin and Reyzin (2002) proposed a one-time signature scheme, which is faster than BIBA and has a slightly lower communication overhead. This scheme has the same disadvantage which is the impractical communication overhead for real-time applications. Another solution is to amortize signature over several packets as proposed in Wong and Lam (1999), Gennaro and Rohatgi (1997), and Golle and Modadugo (2001). Early work was done by Gennaro and Rohatgi (1997). The stream is divided

H(P’1)

707

into blocks of m packets (P1, P2, P3, ., Pm2, Pm1, Pm) and a chain of hashes is used to link each packet to the one preceding it. The hash of P#m (H(P#m)) is appended to Pm1 to form a new packet (P#m1) containing both Pm1 and H(P#m). Then, the hash of P#m1 (H(P#m1)) is appended to Pm2 to form a new packet (P#m2), which contains both Pm2 and H(P#m1). The abovementioned procedure is repeated until forming P#1, which contains P1 and H(P#2) as depicted in Fig. 1. Finally, the hash of P#1 (H(P#1)) is signed. Then, the stream sent to the receivers contains: the signature on H(P#1), P#1, P#2, ., P#m1, P#m. Upon receiving the stream, each receiver checks the signature of the sender and uses the chain of hashes to authenticate subsequent packets. Although this approach solves the computation and communication overheads problem, it has a major drawback that, in case of any packet loss, the authentication chain is broken and subsequent packets cannot be authenticated. Many of multicast applications are running over IP networks where several packet losses could occur. Therefore, multicast authentication protocols must resist packet loss. Golle and Modadugo (2001) solve this problem by appending the hash of a packet into two places: the first is in the next packet and the second is in the packet succeeding by a places and only the final packet P#m is signed using the private key of the sender. Fig. 2 illustrates the basic scheme designed by Golle and Modadugu. Their solution is based on the property that loss over the Internet occurs in bursts as stated in Paxon (1999) and can resist several bursts of a certain number of packets. Other enhancements to the basic scheme were proposed in order to resist a larger burst. Although they solve the problem of loss over networks, their solution suffers from the fact that the communication overhead for some packets equals to five hashes (Golle and Modadugo, 2001). For an SHA hash, the hash output is of 20 bytes; therefore, the communication overhead will be equal to 100 bytes, which is comparable to a signature length. Wong and Lam (1999) proposed another solution to solve the problem of packet loss. In their

P’1

P’2

P’3

P’m-2

P’m-1

P’m

P1

P2

P3

Pm-2

Pm-1

Pm

H(P’2)

H(P’3)

H(P’4)

H(P’m-1)

H(P’m)

Figure 1

Gennaro and Rohatgi multicast authentication scheme.

708

H.K. Aslan P’1

P’2

P’3

P’a+1

P’a+2

P’m-2

P’m-1

P’m

P1

P2

P3

Pa+1

Pa+2

Pm-2

Pm-1

Pm

H(P’1)

H(P’2)

H(P’a)

H(P’a+1)

H(P’m-3)

H(P’m-2)

H(P’m-1)

H(P’1)

H(P’2)

H(P’m-2-a) H(P’m-1-a)

H(P’m-a)

Figure 2

GolleeModadugu basic multicast authentication scheme.

proposal, the stream is divided into blocks of m packets (P1, P2, P3, ., Pm2, Pm1, Pm) and a tree of hashes of degree 2 is constructed. The hashes of the m packets correspond to the leaves of the tree and only the root of the tree needs to be signed. Each parent corresponds to the hash of its children. For example, H1e2 Z hash of (H1 and H2). Fig. 3 shows the tree construction for a block containing eight packets. In order to authenticate any packet, the siblings of each node along its path to the root and the packet signature must be appended. For example, to authenticate P5, the following sequence must be received: P5, H6, H7e8, H1e4, H1e8, and signature on H1e8. The receiver calculates H#5e6 using H5 and H6. Then, it calculates H#5e8 using H#5e6 and H7e8. Finally, it calculates H#1e8 using H#5e8 and H1e4 and checks that H#1e8 equals H1e8 using the received signature. If the check is correct, the received packet will be authenticated. Since each packet carries the information required for its authentication, any packet loss will not affect the ability of the receiver to authenticate packets arrived after the loss. On the other hand, this solution suffers from a high communication overhead, since it requires the appending of log2(m) C 1 hashes to each packet. Finally, Perrig et al. (2000, 2001b, 2002) proposed efficient solutions for the authentication problem named Timed for Efficient Stream Loss-tolerant Authentication (TESLA) and Efficient Multi-chained Stream Signature (EMSS). TESLA is based on authenticating packets using MACs and revealing the MAC

keys after a certain time interval. First, the stream is divided into blocks of m packets. Then, the sender picks a random key Km and calculates m keys by applying a pseudo random function (F)m times. For example, Km1 Z F(Km) and Km2 Z F(Km1) and so on. These keys are used to calculate MACs to authenticate the received stream. Considering the transmitted packet P#i1, it consists of packet Pi1 itself, the calculated key Ki2, and a MAC calculated over Pi1 and Ki2 using Ki1. Packet P#i1 is authenticated after receiving P#i where Ki1 is revealed. Fig. 4 illustrates TESLA multicast authentication scheme. EMSS, the second solution proposed by Perrig et al. (2000), is based on the chain of hashes. The stream is divided into m packets. To achieve robustness against packet loss, each packet contains multiple hashes of previous packets. Only the final packet of the block is signed. Although these solutions have low communication and computational overhead, they have a major drawback that they require that the sender and the receivers maintain the synchronization of their clocks. In the next section, description of the hybrid scheme proposed for multicast authentication over lossy channels is illustrated.

Description of the hybrid scheme for multicast authentication over lossy networks In this section, a description of a scheme designed to solve the problem of authentication in multicast

H1-8 H5-8

H1-4

P’i-1

H1-2

H3-4

H5-6

H7-8

Pi-1 Ki-2

H1

H2

H3

H4

H5

H6

H7

H8

P1

P2

P3

P4

P5

P6

P7

P8

Figure 3

Tree chaining of the Wong and Lam scheme.

MAC(Pi-1, Ki-2, Ki-1)

P’i Pi Ki-1 MAC(Pi, Ki-1, Ki)

P’i+1 Pi+1 Ki MAC(Pi+1, Ki, Ki+1)

Figure 4 TESLA multicast authentication scheme (Perrig et al., 2000).

Hybrid scheme for multicast authentication over lossy networks communication is detailed. The proposed scheme, which uses a hybrid of public key signature and hash functions, is used for authenticating realtime data applications where low delay at the sender is acceptable. It is based on the work done by Gennaro and Rohatgi (1997) and the enhancement to their work proposed by Golle and Modadugo (2001). As mentioned in section ‘‘Requirements for multicast authentication protocols’’, the major drawback of GennaroeRohatgi scheme is that it is not tolerant to packet loss. GolleeModadugu scheme uses the fact that the loss over the Internet occurs in bursts. Although they overcome the problem of packet loss, their solution suffers from the fact that the communication overhead for some packets equals to five hashes, which is comparable to a signature length. Another disadvantage of the GolleeModadugu scheme is that authentication at the receiver is not performed on real-time basis. The aim of the proposed scheme is to achieve authentication with low computation and communication overheads and overcome the abovementioned problems of GennaroeRohatgi and GolleeModadugu schemes. The stream is divided into blocks of m packets (P1, P2, P3, ., Pm2, Pm1, Pm) and a chaining of hashes is used to link each packet to the one preceding it as in the GennaroeRohatgi scheme. In order to avoid the effect of packet loss, the hash of a packet is appended into two packets: the one preceding and the packet preceding it by a places. The procedure of authentication is given below for the sender and the receivers. At the sender side. The process of authentication is as follows: the hash of P#m (H(P#m)) is appended to two places: Pm1 and to Pma. Then, the hash of P#m1 (H(P#m1)) is appended to Pm2 and to Pm1a. The abovementioned procedure is repeated until forming P#1, which contains: P1, H(P#2) and H(P#aC1) as depicted in Fig. 5. Finally, the hash of P#1 (H(P#1)) is signed. Then, the stream sent to the receivers contains: the signature on H(P#1), P#1, P#2, ., P#m1, P#m.

709

Using Fig. 5, the output stream P#i can be expressed as follows: P#m Z Pm P#i Z Pi C H(P#iC1)

P#i Z Pi C H(P#iC1) C H(P#iCa)

for i Z m  1, m  2, . , maC1

for i Z m  a, m  a  1, . , 1

At the receiver side. The authentication process at the receiver contains two procedures: the first in case of no packet loss, and the second in case of packet loss. Upon receiving the stream, assuming no loss occurs, each receiver checks the signature on the first packet (H(P#1)) and uses the chain of hashes, of the second row of Fig. 5, to authenticate subsequent packets. The loss over the Internet is characterized by the fact that it occurs in burst as stated in Paxon (1999). A burst starts at any location and remains for a random number of packets. The proposed scheme resists bursts of length L, where L must be less than a. In case of packet loss, the hashes in the third row of Fig. 5 are used to continue the process of authentication. The receiver uses the hashes of the packet immediately before the burst. Assume the burst begins at P#i and lasts to packet P#iCL. The packet preceding P#i (P#i1) contains both H(P#i) and H(P#iCa1). Therefore, after receiving the packet (P#iCa1), the receiver can verify it and any received packet preceding it obtained after the burst, using the chain of hashes of the second row of Fig. 5. It has to be noted that in order to perform the proposed scheme, the receivers must obtain the first packet containing the signature. Consequently, this packet could be sent several times or upon request if one of the receivers does not get it. The following notations, for the buffer resources at sender and the receivers, are used: - Send_Packet: number of packets that need to be buffered at the sender before transmission.

P’1

P’2

P’3

P’m-a-1

P’m-a

P’m-2

P’m-1

P’m

P1

P2

P3

Pm-a-1

Pm-a

Pm-2

Pm-1

Pm

H(P’2)

H(P’3)

H(P’4)

H(P’a+2)

H(P’a+3)

H(P’1) H(P’a+1)

Figure 5

H(P’m-a) H(P’m-a+1) H(P’m-1)

H(P’m-1) H(P’m)

H(P’m)

The proposed multicast authentication scheme.

710 - Send_Hash: number of hashes that need to be buffered at the sender before transmission. - Rec_Packet: number of packets that need to be buffered at the receiver before authenticating the stream, in case of no loss. - Rec_Packet_Loss: number of packets that need to be buffered at the receiver before authenticating the stream, in case of loss. - Rec_Hash: number of hashes that need to be buffered at the receiver before authenticating the stream, in case of no loss. - Rec_Hash_Loss: number of hashes that need to be buffered at the receiver before authenticating the stream, in case of loss. According to Fig. 5, the following buffer resources are needed in order to accurately perform the proposed scheme: Send_Packet equals to m, Send_Hash equals to a, Rec_Packet equals to one, the maximum value of Rec_Packet_Loss equals to a  1, Rec_Hash equals to one, and Rec_Hash_Loss equals to a. The maximum number of hashes appended to a given packet equals to two. In order to resist packet loss, the burst of loss must be less than a. a must be chosen carefully, small values of a leads to the probability that L is larger than a. In contrast, large values of a leads to the need of larger buffer resources. Studies made by Paxon (1999) show that the average packet loss over the Internet given certain conditions is about 5% (the reader could refer to Paxon (1999) for more details of the study). Therefore, choosing a greater than 0.05 m, taking into consideration the buffering resources at the receivers, could be a reasonable selection. Network conditions must be examined periodically and according to changes in network statistics the value of a must be adjusted dynamically. In case of higher value of packet loss, the value of a must be increased. In contrary, lower value of packet loss could lead to the decrease of a. The proposed scheme is characterized by the following: first, in order to perform authentication, the proposed scheme has a delay equals to the processing of transmission of m packets at the sender side and no delay at the receiver side assuming no loss occurs. Second, the required buffer resources at the sender equals to m packets and a hashes. On the other hand, the required buffer resources at the receiver equals to a maximum of a  1 packets and a hashes. Third, it is able to authenticate the received packet despite losses over the network and it is joinable at any point. Fourth, in case of no loss over the network, the scheme latency equals to zero. On the other hand, the maximum value of latency in case of packet

H.K. Aslan loss equals to a  1. Finally, the communication overhead of the proposed scheme equals to two hashes. Its computation overhead equals to the calculation of one signature over m packets and the calculation of m hashes. In the next section, comparison of the hybrid scheme with Gennaroe Rohatgi, WongeLam, GolleeModadugu and TESLA schemes is detailed.

Comparison of the proposed scheme with GennaroeRohatgi, WongeLam, TESLA and GolleeModadugu schemes In order to conduct a comparison between the proposed scheme and the following schemes: GennaroeRohatgi, WongeLam, GolleeModadugu and TESLA, the following general assumptions are considered: - The stream to be authenticated is divided into blocks of m packets. - In order to provide authentication, one signature is needed for each block. - All the compared schemes are based on the amortization of signature over several packets. Therefore, in the following discussion, signature will not be included in the calculation of both the computation and communication overheads. - The calculations are specified for the authentication of one block. - For the proposed scheme, the hash of each packet is appended to the previous packet and to the packet preceding it by a places. On the other hand, for GolleeModadugu scheme, the hash of each packet is appended to the next packet and to the packet succeeding it by a places. Finally, for TESLA protocol, the key, which is used to examine authentication, is revealed after a packets. The comparison will be undertaken according to the following criteria: - The computation overhead: the total number of packets to be hashed at the sender or at the receiver for m packets. - The communication overhead: the average number of hashes appended to each packet in order to achieve authentication. - Buffering resources: the maximum expected number of packets or hashes to be stored in the following buffers: Send_Packet, Send_Hash, Rec_Packet, Rec_Packet_Loss, Rec_Hash, Rec_ Hash_Loss. In order to compare with TESLA

Hybrid scheme for multicast authentication over lossy networks scheme, two other buffers are added: the first is the Send_Key, which represents the number of keys needed to perform MAC operations and to be stored at the sender. The latter is the Rec_Key, which represents the number of keys to be stored at the receiver. - Delay at the sender and the receiver: delay at the sender (in number of hashes to be calculated) to set up the information required to achieve authentication and at the receiver (in number of hashes to be calculated) to authenticate a stream of packets assuming no loss occurs. - Latency: the maximum number of packets that need to be received before a packet can be authenticated. - Resistance to packet loss: the type of loss that the scheme resists. Table 1 shows the comparison between GennaroeRohatgi scheme, WongeLam scheme, GolleeModadugu, TESLA and the proposed schemes. Since GennaroeRohatgi scheme does not resist packet loss, the values of Rec_Packet_ loss, Rec_Hash_Loss, and the latency are not determined in the table. The following facts could be deduced from Table 1: - WongeLam scheme resists any type of packet loss, which is considered an essential requirement from the point of view of security. Table 1 schemes

711

However, it has the following disadvantages compared to the other schemes: - It has the highest communication and computation overheads as shown in Fig. 6. - It requires the highest buffer resources at the sender. - It has the longest delay at the sender. - GennaroeRohatgi scheme has the lowest computation and communication overheads as shown in Fig. 6. Further, it requires the lowest buffer resources at both the sender and the receivers. However, it has a major drawback that it cannot resist any type of packet loss. - Comparing TESLA protocol with the proposed scheme, TESLA has a lower communication overhead and can resist a length of packet loss greater than the proposed scheme. On the other hand, the proposed scheme has the following advantages over TESLA: - It has a lower computation overhead as shown in Fig. 6. This is due to the fact that for performing authentication the sender needs to calculate one MAC for every packet, as well as one key for every packet using one way functions. - It requires a lower buffering resources as shown in Table 1. - It does not depend on time synchronization as for TESLA. - GolleeModadugu and the proposed scheme have requirements that are comparable to

Comparison between GennaroeRohatgi, WongeLam, GolleeModadugu, TESLA and the proposed Gennaroe Rohatgi

WongeLam

Gollee Modadugu

TESLA

Proposed scheme

Computation overhead Communication overhead

m 1

2log2 ðmÞC1  1 log2(m) C 1

m 2

2m 1

m 2

Buffering resources Send_Packet Send_Hash Rec_Packet Rec_Packet_Loss Rec_Hash Rec_Hash_Loss Send_Key Rec_Key

m 1 1 e 1 e 0 0

m 2log2 ðmÞC1  1 1 0 log2(m) C 1 0 0 0

1 a m m 1 a 0 0

1 1 a a1 a a m 1

m a 1 a1 1 a 0 0

m 0

2log2 ðmÞC1  1 0

0 m

m 0

m 0

e No resistance to packet loss

0 Any

m Burst of specified length Z a

a1 Burst of specified length Z m

a1 Burst of specified length Z a

Delay At the sender At the receiver (assume no packet is lost) Latency (in case of loss) Resistance to packet loss

H.K. Aslan Gennaro-Rohatgi, Golle-Modadugu and the proposed scheme

Wong-Lam and Testla schemes

140 120 100 80 60 40 20 0 0

8

16

24

32

40

48

56

64

Number of packets per block

a.

Golle-Modadugu and the proposed scheme Gennaro-Rohatgi and Tesla

Wong-Lam Communication overhead number of hashes

Computation overhead number of hashes

712

10 8 6 4 2 0 0

8

16

24

32

40

48

56

64

Number of packets per block

b.

Figure 6 Comparison of the overheads of: GennaroeRohatgi, WongeLam, GolleeModadugu, TESLA and the proposed schemes: (a) for the computation overhead; (b) for the communication overhead.

those of the GennaroeRohatgi scheme. They have the same computation overhead and their communication overhead is two hashes instead of one hash in the GennaroeRohatgi scheme. Furthermore, their buffer resources are almost the same as those of the GennaroeRohatgi scheme. On the other hand, they can resist a burst of packet loss given that the length of the burst is less than a certain length a. - Comparing the proposed scheme with Gollee Modadugu scheme, GolleeModadugu scheme has a delay at the sender, which is less than that of the proposed scheme. On the other hand, the proposed scheme has the following advantages: first, its latency is less than that of GolleeModadugu scheme. Second, the delay at the receiver is less than that of Gollee Modadugu scheme and authentication can be performed on real-time basis. Third, for Gollee Modadugu scheme as stated in Golle and Modadugo (2001), the communication overhead for some packets equals to five hashes, which is comparable to a signature length. For the proposed scheme, the maximum number of hashes appended to any packet is two.

Conclusions In the present paper, the problem of securing multicast communication is discussed. Many solutions have been proposed to solve the multicast authentication problem. One solution is to design more efficient signature schemes. Although this solution overcomes the computational problem, it suffers from the communication overhead problem. In order to overcome the communication overhead problem, another solution is to amortize signature over several packets as proposed in GennaroeRohatgi, WongeLam, and Gollee Modadugu schemes. Many of multicast applications are running over IP networks where several packet

losses could occur. Therefore, multicast authentication protocols must resist packet loss and must be joinable at any point. Other requirements of multicast authentication protocols are to perform authentication in real-time and to have no latency. Furthermore, the required buffering resources must be as low as possible and have low communication and computation overheads. In the present paper, a hybrid scheme for authenticating real-time data applications where low delay is acceptable is proposed. It is based on work done by GennaroeRohatgi and Gollee Modadugu. In order to provide authentication, the proposed scheme uses both public key signature and hash functions. It is based on the idea of dividing the stream into blocks of m packets and a chain of hashes is used to link each packet to the one preceding it as proposed in GennaroeRohatgi. In order to resist the packet loss, the hash of each packet is appended to another place in the stream as in GolleeModadugu. Finally, the first packet is signed. The proposed scheme is compared to GennaroeRohatgi, WongeLam, GolleeModadugu and TESLA schemes. Comparison of the proposed scheme with GennaroeRohatgi scheme shows that the major advantage of the proposed scheme is that it resists packet loss and it is joinable at any point. On the other hand, comparison of the proposed scheme with WongeLam scheme shows that the proposed scheme has the following advantages: first, it has lower computation and communication overheads. Second, it has lower buffer requirements. Finally, the proposed scheme has a lower delay at the sender. While comparing TESLA with the proposed scheme, TESLA has a lower communication overhead and can resist a length of packet loss greater than the proposed scheme. On the other hand, the proposed scheme has the following advantages over TESLA: first, it has a lower computation overhead. Second, it requires lower buffering resources. Finally, it does not depend on time synchronization. Whilst

Hybrid scheme for multicast authentication over lossy networks comparing the proposed scheme with Gollee Modadugu scheme, GolleeModadugu scheme has a delay at the sender, which is less than that of the proposed scheme. On the other hand, the proposed scheme has the following advantages: first, its latency is less than that of GolleeModadugu scheme. Second, the delay at the receiver is less than that of GolleeModadugu scheme and authentication can be performed on real-time basis. Third, for the proposed scheme, the maximum number of hashes appended to any packet is two. While, the communication overhead of Gollee Modadugu scheme for some packets equals to five hashes, which is comparable to a signature length. In conclusion, the proposed scheme achieves the goal of multicast authentication and overcomes the problems of previous schemes.

References Ateniese G, Steiner M, Tsudik G. New multi-party authentication services and key agreement protocols. IEEE Journal on Selected Areas in Communications April 2000:628e39. Gennaro R, Rohatgi P. How to sign digital streams. In: Proceedings of CRYPTO’97. California, USA; August 1997. p. 180e97. Golle P, Modadugo N. Streamed authentication in the presence of random packet loss. In: Proceedings of the ISOC network and distributed system security symposium. California, USA; February 2001. p. 13e22. Mittra S. Iolus: a framework for scalable secure multicasting. In: Proceedings of the ACM SIGCOMM’97. France; September 1997. p. 277e88. Pannetrat A, Molva R. Efficient multicast packet authentication. In: Proceedings of the ISOC network and distributed system

713

security symposium. California, USA; February 2003. p. 251e62. Paxon V. End-to-end internet packet dynamics. IEEE/ACM Transactions on Networking June 1999;7(3):277e92. Perrig A. The BIBA one-time signature and broadcast authentication protocol. In: Proceedings of the 8th ACM conference on computer and communications security. Pennsylvania, USA; November 2001. p. 28e37. Perrig A, Canetti R, Tygar JD, Song D. Efficient authentication and signing of multicast streams over lossy channels. Proceedings of IEEE Symposium on Security and Privacy May 2000:56e73. Perrig A, Song D, Tygar JD. ELK, a new protocol for efficient large-group key distribution. Proceedings of IEEE Symposium on Security and Privacy May 2001a:247e62. Perrig A, Canneti R, Song D, Tygar JD. Efficient and secure source authentication for multicast. In: Proceedings of the ISOC network and distributed system security symposium. California, USA; February 2001b. p. 35e46. Perrig A, Canetti R, Tygar JD, Song D. The TESLA broadcast authentication protocol. RSA CryptoBytes 2002;5:2e13. Reyzin L, Reyzin R. Better than BIBA: short one-time signatures with fast signing and verifying. In: Proceedings of the 7th Australian Conference on Information Security and Privacy. Melbourne, Australia; July 2002. p. 144e53. Rohatgi R. A compact and fast hybrid signature scheme for multicast packet authentication. In: Proceedings of the 6th ACM Conference on Computer and Communications Security. Singapore; November 1999. p. 93e100. Wong CK, Lam SS. Digital signatures for flows and multicasts. IEEE/ACM Transactions on Networking 1999;7(4):502e13. Heba Aslan is an assistant professor at the Informatics Department in the Electronics Research Institute, Egypt. Her fields of interest include encryption protocols, key distribution protocols, group key distribution protocols and intrusion detection systems. She obtained a BSc, MSc and PhD from Electronics and Communications Department, Faculty of Engineering, Cairo University, Egypt, in 1990, 1994 and 1998, respectively.