The Conventional Block Based Multicast Authentication Schemes

Published Date: 02 Nov 2017

Abstract - Conventional block-based multicast authentication schemes overlook the heterogeneity of receivers by letting the sender choose the block size, divide a multicast stream into blocks, associate each block with a signature, and spread the effect of the signature across all the packets in the block through hash graphs or coding algorithms. The correlation among packets makes them vulnerable to packet loss, which is inherent in the Internet and wireless networks. In this paper, we propose a novel multicast authentication protocol, namely MABBS which eliminates the correlation among packets and thus provides the perfect resilience to packet loss, and it is also efficient in terms of latency, computation, and communication overhead due to an efficient cryptographic primitive called batch signature, which supports the authentication of any number of packets simultaneously.

INTRODUCTION

Multicast is an efficient method to deliver multi-media content from a sender to a group of receivers and is gaining popular applications such as real time stock quotes, interactive games, video conference, live video broadcast, or video on demand. Authentication is one of the critical topics in securing multicast [1] in an environment attractive to malicious attacks. Basically, multicast authentication may provide the following security services:

1. Data integrity: Each receiver should be able to assure that received packets have not been modified during transmissions.

Data origin authentication: Each receiver should be able to assure that each received packet comes from the real sender as it claims.

Non repudiation: The sender of a packet should not be able to deny sending the packet to receivers in case there is a dispute between the sender and receivers.

All the three services can be supported by an asymmetric key technique called signature. In an ideal case, the sender generates a signature for each packet with its private key, which is called signing, and each receiver checks the validity of the signature with the sender’s public key, which is called verifying. If the verification succeeds, the receiver knows the packet is authentic.

Designing a multicast authentication protocol is not an easy task. Generally, there are following issues in real world challenging the design. First, efficiency needs to be considered, especially for receivers. Compared with the multicast sender, which could be a powerful server, receivers can have different capabilities and resources. The receiver heterogeneity requires that the multicast authentication protocol be able to execute on not only powerful desktop computers but also resource-constrained mobile handsets. In particular, latency, computation, and communication overhead are major issues to be considered. Second, packet loss is inevitable. In the Internet, congestion at routers is a major reason causing packet loss. An overloaded router drops buffered packets according to its preset control policy. Though TCP provides a certain retransmission capability, multicast content is mainly transmitted over UDP, which does not provide any loss recovery support. In mobile environments, the situation is even worse. The instability of wireless channel can cause packet loss very frequently. Moreover, the smaller data rate of wireless channel increases the congestion possibility. This is not desirable for applications like real-time online streaming or stock quotes delivering. End users of online streaming will start to complain if they experience constant service interruptions due to packet loss, and missing critical stock quotes can cause severe capital loss of service subscribers. Therefore, for applications where the quality of service is critical to end users, a multicast authentication protocol should provide a certain level of resilience to packet loss. Specifically, the impact of packet loss on the authenticity of the already-received packets should be as small as possible.

Efficiency and packet loss resilience can hardly be supported simultaneously by conventional multicast schemes. As is well known that existing digital signature algorithms are computationally expensive, the ideal approach of signing and verifying each packet independently raises a serious challenge to resource-constrained devices. In order to reduce computation overhead, conventional schemes use efficient signature algorithms or amortize one signature over a block of packets at the expense of increased communication overhead or vulnerability to packet loss.

In this paper, we present our comprehensive study on this approach and propose a novel multicast authentication protocol called MABBS (in short for Multicast Authentication using Batch BLS Signature). Multicast Authentication using Batch BLS Signature (called MABBS hereafter) utilizes an efficient asymmetric cryptographic primitive called batch signature which supports the authentication of any number of packets simultaneously with one signature verification, to address the efficiency and packet loss problems in general environments. MABBS provides data integrity, origin authentication, and non repudiation as previous asymmetric key based protocols. In addition, we make the following contributions:

Our MABBS can achieve perfect resilience to packet loss in lossy channels in the sense that no matter how many packets are lost the already-received packets can still be authenticated by receivers.

MABBS is efficient in terms of less latency, computation, and communication overhead.

We propose new batch signature schemes based on BLS and show it is more efficient than the batch RSA signature scheme.

The rest of the paper is organized as follows: We briefly review related work in Section 2. Then, we present a basic scheme for lossy channels in Section 3, Efficiency in Section 4, the paper is concluded in Section 5.

RELATED WORK

Schemes in [3], [4] follow the ideal approach of signing and verifying each packet individually, but reduce the computation overhead at the sender by using one-time signatures [3] or k-time signatures [4]. They are suitable for RSA, which is expensive on signing while cheap on verifying. For each packet, however, each receiver needs to perform one more verification on its one-time or k-time signature plus one ordinary signature verification. Moreover, the length of one-time signature is too long (on the order of 1,000 bytes).

Tree chaining was proposed in [10], [11] by constructing a tree for a block of packets. The root of the tree is signed by the sender. Each packet carries the signed root and multiple hashes. When each receiver receives one packet in the block, it uses the authentication information in the packet to authenticate it. The buffered authentication information is further used to authenticate other packets in the same block. Without the buffered authentication information, each packet is independently verifiable at a cost of per-packet signature verification.

Graph chaining was studied in [5]. A multicast stream is divided into blocks and each block is associated with a signature. In each block, the hash of each packet is embedded into several other packets in a deterministic or probabilistic way. The hashes form a graph, in which each path links a packet to the block signature. Each receiver verifies the block signature and authenticates all the packets through the paths in the graph.

Erasure codes were used in [7]. A signature is generated for the concatenation of the hashes of all the packets in one block and then is erasure-coded into many pieces. Erasure codes make each receiver be capable of recovering the block signature when receiving at least a certain number of pieces.

All these schemes [10], [5], [7] are indeed computationally efficient since each receiver needs to verify only one signature for a block of packets. However, they all increase packet overhead for hashes or erasure codes and the block design introduces latency when buffering many packets. Another major problem is that most schemes [5], [7] are vulnerable to packet loss even though they are designed to tolerate a certain level of packet loss. If too many packets are lost, other packets may not be authenticated. In particular, if a block signature is lost, the entire block cannot be authenticated.

BASIC SCHEME

Our target is to authenticate multicast streams from a sender to multiple receivers. Generally, the sender is a powerful multicast server managed by a central authority and can be trustful. The sender signs each packet with a signature and transmits it to multiple receivers through a multicast routing protocol. Each receiver is a less powerful device with resource constraints and may be managed by a nontrustworthy person. Each receiver needs to assure that the received packets are really from the sender (authenticity) and the sender cannot deny the signing operation (nonrepudiation) by verifying the corresponding signatures.

Ideally, authenticating a multicast stream can be achieved by signing and verifying each packet. However, the per-packet signature design has been criticized for its high computation cost, and therefore, most previous schemes [10], [5], [7], incorporate a block-based design as shown in Section 2. They do reduce the computation cost, but also introduce new problems. The block design builds up correlation among packets and makes them vulnerable to packet loss, which is inherent in the Internet and wireless networks. Received packets may not be authenticated because some correlated packets are lost.

Also, the heterogeneity of receivers means that the buffer resource at each receiver is different and can vary over the time depending on the overall load at the receiver. In the block design, the required block size, which is chosen by the sender, may not be satisfied by each receiver.

Third, the correlation among packets can incur additional latency. Consider the high layer application needs new data from the low layer authentication module in order to render a smooth video stream to the client user. It is desirable that the lower layer authentication module delivers authenticated packets to the high layer application at the time when the high layer application needs new data. In the per-packet signature design it is not a problem, since each packet can be independently verifiable at any time. In the block design, however, it is possible that the packets buffered at the low layer authentication module are not verifiable because the correlated packets, especially the block signatures, have not been received. Therefore, the high layer application has to either wait, which leads to additional latency, or return with a no-available-packets exception, which could be interpreted as that the buffered packets are "lost." This latency, which is incurred at the high layer when the high layer application waits for the buffered packets to become verifiable, is different from the buffering latency, which is required for the low layer authentication protocol to buffer received packets.

In view of the problems regarding the sender favored block-based approach, we conceive a receiver-oriented approach by taking into account the heterogeneity of the receivers. As receiving devices have different computation and communication capabilities, some could be powerful desktop computers, while the others could be cheap handsets with limited buffers and low-end CPUs. Mixed with various channel loss rates, this heterogeneity poses a demand on the capability of adjusting the buffer size and authenticating buffered packets any time when the high layer application requires at each receiver.

In order to fulfill the requirement, the basic scheme MABBS uses an efficient cryptographic primitive called batch signature [9] which supports simultaneously verifying the signatures of any number of packets. In particular, when a receiver collects n packets:

where mi is the data payload, σ i is the corresponding signature, and n can be any positive integer, it can input them into an algorithm

Batch Verify(p1,p2,….,pn) Є{ True,False}.

If the output is True, the receiver knows the n packets are authentic, and otherwise not.

To support authenticity and efficiency, the BatchVerify () algorithm should satisfy the following properties

Given a batch of packets that have been signed by, the sender, BatchVerify(), outputs True. In particular, each receiver can verify the authenticity

Given a batch of packets including some unauthentic of all the received packets in its buffer whenever the high packets, the probability that BatchVerify() outputs True is very low.

The computation complexity of BatchVerify() is comparable to that of verifying one signature and is increased only gradually when the batch size n is increased.

The computation complexity of BatchVerify() comes with the fact that there are some additional cost on processing multiple packets. As we will show later, those additional computations are mostly modular additions and multiplications, which are much faster than modular exponentiations required in final signature verifications. Theoretically, a concern comes when the cost grows higher than the final signature verification if the batch size is too large. However, it is not the case in reality. The merit of batch signature is that the batch size is chosen by each receiver, which can optimize its own batch size, so that the batch size will not be unmanageably large. Most important, we will show later that in the implementation of batch signature a technique called signature preaggregation can be used so that the additional processing of multiple packets is shifted from the time of final batch verification to the time of each packet reception and thus the cost of final batch signature verification is exactly the same as that of original signature verification.

MABBS uses per-packet signature instead of per-block signature and thus eliminates the correlation among packets. The packet independency makes MABBS perfect resilient to packet loss. The Internet and wireless channels tend to be lossy due to congestion or channel instability, where packets can be lost according to different loss models, such as random loss or burst loss. In MABBS, however, no matter how many packets are lost, the already received packets can still be authenticated by each receiver. This is a significant advantage over previous schemes. Mean-while, efficiency can also be achieved because a batch of packets can be authenticated simultaneously through one batch signature verification operation. The packet independency also brings other benefits in terms of smaller latency and communication overhead compared with previous schemes [10], [5], layer applications require, and there is no additional hash or code overhead in each packet.

3.1 Batch BLS Signature

Here, we propose a batch signature scheme based on the BLS signature in [12].

3.2.1 BLS

The BLS signature scheme uses a cryptographic primitive called pairing, which can be defined as a map over two cyclic groups G1 and G2, e:G1 X G1→G2, satisfying the following properties:

1. Bilinear: For all u, v Є G1 and a,b Є Z, we have e(ua, vb)=e(u,v)ab.

2. Nondegenerated: For the generator g1 of G1, i.e., gp1=1 Є G1 where p is the order of G1, we have e(g1,g1) ≠ 1 Є G2.

The BLS signature scheme consists of three phases:

1. In the key generation phase, a sender chooses a random integer x Є Zp and computes y = g1x Є G1. The private key is x and the public key is y.

2. Given a message m Є {0,1)* in the signing phase, the sender first computes h =h(m)ЄG1, where h() is a hash function, then computes σ=hx Є G1. The signature of m is σ.

3. In the verification phase, the receiver first computes h = h(m) ЄG1 and then check whether e(h,y)=e(σ,g1).

If the verification succeeds, then the message m is authentic because

One merit of the BLS signature is that it can generate a very short signature. It has been shown in [12] that an n-bit BLS signature can provide a security level equiv.-lent to solving a Discrete Log Problem (DLP) over a finite field of size approximately 26n. Therefore, a 171-bit BLS signature provides the same level of security as a 1,024-bit DLP-based signature scheme such as DSA [38]. This is a very nice choice in the scenario where communication overhead is an important issue

3.2.2 Batch BLS

Based on BLS, we propose our batch BLS scheme here. Given n packets {mi,σi},i=1,…,n, the receiver can verify the batch of BLS signatures by first computing hi=h(mi), i=1,…,n and then checking whether e(∏ni=1 hi,y)= e(∏ni=1 σi,g1). This is because if all the message are authentic , then

We can prove that our batch BLS is secure to signature forgery as long as BLS is secure to signature forgery.

Theorem 1. Suppose an attacker A can break the batch BLS by forging signatures. Then, another attacker B can break BLS under the chosen message attack by colluding with A.

Proof. Suppose B is given n-1 messages and their valid signatures {mi,σi}, i=1,…..,n-1, B can forge a signature σn for any chosen message mn such that {mn,σn} satisfies the BLS signature scheme, by colluding with A in the following steps:

B sends n messages mi,i=1,…..,n and n-1 signatures σi,i=1,…,n-1 to A.

Because A can break the batch BLS scheme, A generates n false signatures σi׳,i=1,…,n that pass the batch BLS verification, then returns to B a value V=∏ni=1 σi׳.

B computes σn=V/∏n-1i=1 σi as signature for mn, because

Since BLS is forgery-secure under the chosen message attack [12], our batch BLS scheme is also secure to forgery under the chosen message attack.

Also like batch RSA, an attacker may not forge signatures but manipulate authentic packets to produce invalid signatures. For instance, two packets {mi,σi } and {mj,σj} for i≠ j can be replaced with {mi,σiλ } and {mj,σj/λ}and still pass the batch verification. However, it does not affect the correctness and the authenticity of mi and mj because they have been correctly signed by the sender.

Requirements to the Sender

In our batch BLS, the sender needs to sign each packet. Because BLS can provide a security level equivalent to conventional RSA with much shorter signature, the signing operation is more efficient than the RSA signature generation. Moreover, BLS can be implemented over elliptic curves, which have been shown in the literature to be more efficient than finite integer fields on which RSA is implemented. Therefore, we can expect that our batch BLS is more affordable by the sender than batch RSA and also achieve computation efficiency at the receiver.

4. Efficiency

We consider latency, computation, and communication overhead for efficiency evaluation under lossy channels. The notations used here are defined in Table 1.

All the evaluations are carried out over n packets. The results are depicted in Table 2.

4.1 Comparisons over Lossy Channels

Table 2 shows the comparisons between MABBS and well-known loss-tolerant schemes tree chain (Tree), EMSS, PiggyBack, augmented chain (AugChain), and SAIDA.

Previous block-based schemes introduce latency either at the sender or at each receiver or both. The latency is inherent in the block design due to chaining or coding. At the sender side, the correlation among a block of packets has to be established before the sender starts sending the packets. At each receiver, the latency is incurred when the high layer application waits for

the buffered packets to be authenticated after the correlation is recovered. This receiver side latency is variable depending on whether the correlation among the underline buffered packets has been recovered or not when the high layer application needs new data, and its maximum value is the block size. MABBS eliminates the correlation among packets. Each packet is independently sent out at the sender. At each receiver, the high layer application does not need to wait because the low layer authentication module can deliver authenticated packets at any time when the high layer application needs new data. This makes MABBS pretty suitable for real-time multimedia applications.

Both the block-based schemes and MABBS require one signature verification operation on a block or a batch of n packets at each receiver. In addition, the schemes using chaining also require many hashes, and the ones using coding require multiple hashes and one or two decoding operations. MABBS is more efficient since there are no more hashing or decoding operations.

In MABBS, a trade-off for perfect resilience to packet loss is that the sender needs to sign each packet, which incurs more computation overhead than conventional block-based schemes. Therefore, efficient signature generation is desire-able at the sender. Compared with RSA , which is efficient in verifying but is expensive in signing, BLS [12] is pretty good candidates as we will show later. Moreover, in multimedia multicast, the sender is usually a powerful server and thus the per-packet signature generation can be affordable, and the advance of computing technology makes it easier in the long run.

For n packets, Tree requires an overhead of n signature and O(nlog2n) hashes, schemes in [6] require one or more signatures and up to O(n2) hashes. MABBS require n signatures. MABBS has more communication overhead than those in [6], which is the same case as Tree. However, BLS generates short signatures of 171 bits, which is comparable to most well-known hash algorithms MD5 [10] (128 bits) and SHA-1 [11] (160 bits). Therefore, MABBS can have the same level of communication efficiency as conventional schemes when BLS is used.

4.2 Comparisons of Signature Schemes

We compare the computation overhead of three batch signature schemes in Table 4. RSA and BLS [12] require one modular exponentiation at the sender. Usually one c-bit modular exponentiation is equivalent to 1:5c modular multiplications over the same field . Moreover, a c-bit modular exponentiation in DLP is equivalent to a (c/6) -bit modular exponentiation in

BLS for the same security level. Therefore, we can estimate that the computation overhead of one 1,024-bit RSA signing operation is roughly equivalent to that of 768 DSA signing operations (1,536 modular multiplications) and that of 6 BLS signing operations (each one is corresponding to 255 modular multiplications).

According to the report on the computational over-head of signature schemes on PIII 1 GHz CPU, the signing and verification time for 1,024-bit RSA with a 1,007-bit private key are 7.9 ms and 0.4 ms, for 157-bit BLS are 2.75 ms and 81 ms, and for 1,024-bit DSA with a 160-bit private key (without precomputing r value) are 4.09 ms and 4.87 ms. We can observe that for BLS and DSA the signing is efficient but the verification is expensive, and vice versa for RSA. Therefore, we can save more computation resource at the sender by using our batch BLS than batch RSA and batch DSA. It is also meaningful to use our batch BLS at the receiver to save computation resources.

We also compare the length of two popular hash algorithm MD5 [10] and SHA-1 [11] and the signature length of three

signature algorithms in Table 5. Given the same security level as 1,024-bit RSA, BLS generates a 171-bit signature and DSA generates a 320-bit signature. It is clear that by using BLS MABBS can achieve more bandwidth efficiency than using RSA, and could be even more efficient than conventional schemes using a large number of hashes.

5. CONCLUSIONS

To reduce the signature verification overheads in the secure multimedia multicasting, block-based authentication schemes have been proposed. Unfortunately, most previous schemes have many problems such as vulnerability to packet loss. To overcome these problems, we develop a novel authentication scheme MABBS. We have demonstrated that MABBS is perfectly resilient to packet loss due to the elimination of the correlation among packets. Moreover, we also show that the use of batch signature can achieve the efficiency less than or comparable with the conventional schemes. Finally, we further develop new batch signature schemes based on BLS which are more efficient than the batch RSA signature scheme.