Scalable trusted online dissemination of JPEG2000 ... - Springer Link

Multimedia Systems (2005) 11(1): 60–67 DOI 10.1007/s00530-005-0190-7

R E G U L A R PA P E R

Robert H. Deng · Di Ma · Weizhong Shao · Yongdong Wu

Scalable trusted online dissemination of JPEG2000 images

Published online: 12 July 2005 c Springer-Verlag 2005

Abstract An important aspect of JPEG2000 is its “compress once, decompress many ways” property [1], i.e., it allows users with different preferences, privileges or capabilities to extract various sub-images all from a single compressed image code-stream. In this paper, we present a flexible and scalable scheme to authenticate JPEG2000 images disseminated by a untrusted third-party server over open networks. The proposed scheme is fully compatible with JPEG2000 and possesses a “sign once, verify many ways” property, i.e., it allows users to verify the authenticity and integrity of different sub-images extracted from a single compressed code-stream protected with a single digital signature. Furthermore, the use of aggregated digital signatures reduces both computation and communication overhead on the user side for batch image authentication. Keywords Authentication · Digital signatures · JPEG2000 · Merkle hash tree

1 Introduction JPEG2000 [1–3], an emerging international standard for still image compression, is designed to address most of the limitations of the original JPEG standard and intends to cater to the widening of application areas for JPEG technology. In addition to excellent coding performance and good error resilience, a remarkable merit of JPEG2000 is its “compress once, decompress many ways” functionality, i.e., it supports extraction of transcoded images with different resolutions, R. H. Deng (B) School of Information Systems, Singapore Management University, Singapore E-mail: [email protected] D. Ma · Y. Wu Institute for Infocomm Research, Singapore E-mail: {madi, wydong}@i2r.a-star.edu.sg W. Shao Department of Computer Science and Technology, Peking University, P.R. China E-mail: [email protected]

quality layers and regions-of-interest (ROIs), all from the same compressed code-stream. This functionality allows applications to manipulate or disclose only the required image data of a code-stream for any target users based on their privileges or capabilities. 1.1 The third party dissemination problem This paper studies techniques for authenticating JPEG2000 image code-streams in the third party dissemination scenario shown in Fig. 1, where image producers prepare JPEG2000 code-streams for a third party publisher to disseminate to users on demand. The users request sub-images based on their privileges, computation and communication capabilities. In security-sensitive applications, it is highly desirable or even mandatory for users to verify the authenticity of a received response from the publisher, to make sure that the received sub-image is indeed originated from the producer as claimed and that the content of the sub-image has not been modified during the transmission. A straightforward solution is to let the publisher digitally sign each requested sub-image in real-time. This requires that the publisher be fully trusted by the users and does not tamper the original producer’s image code-streams. It also requires that the private signing key be made on-line. Generally speaking, maintaining private signing key on-line is vulnerable to both external hacking and insider attacks. Another naive approach is to have the producers pre-compute signatures for all possible sub-images and forward them together with the code-streams to the publisher for distribution to users. This approach is infeasible in practice, since there are too many sub-images for a code-stream. 1.2 Related work and our contributions Many data integrity and origin authentication techniques have been proposed in the literature (e.g., [4, 5]). However, these generic data authentication techniques completely ignore the internal data structure of the content under


Users

low bandwidth channel high bandwidth channel

internet

Producers

publisher Fig. 1 A third party publication model

protection and thus cannot work well with the scalability feature of JPEG2000 code-streams. A scheme using digital signature for authenticating JPEG2000 code-streams is proposed in [6]: it simply signs each code-block and attaches the digital signature to the end of the code-block bit stream. The scheme requires the generation and verification of many signatures since a code-stream may contain many code-blocks. It is also vulnerable to cut-and-paste attack. A semi-fragile JPEG image authentication scheme is presented in [7], which aims at authenticating images under lossy compression and other common image manipulations. For example, their scheme accepts JPEG lossy compression on the watermarked image to a pre-determined quality factor, and rejects malicious attacks. The contributions of this paper are as follows. First, we present an authentication scheme, which allows for “sign once, verify many ways.” That is, the scheme enables users to verify the authenticity and integrity of different subimages extracted from a single code-stream protected by a single signature from the original producer. No private signing key is maintained at the publisher. The publisher is only responsible for image dissemination, but is not trusted to authenticate code-streams from publishers. As a result, even if the publisher is compromised and tries to tamper with producer’s code-streams, the tampering will be detected by users. Second, our authentication scheme incurs minimum communication and computation overhead on the user side. This is important as most user devices are consumer electronic appliances, which are resource constrained and connected over bandwidth limited wireless access networks.

61

Our authentication scheme is designed by exploring the Merkle hash tree [8] on structured JPEG2000 image codestreams. The Merkle hash tree has been used for certifying answers to queries over XML documents [10], for proving the presence or absence of public key certificates on revocation lists [11, 12], and for certifying data published by untrusted publishers [13]. However, authenticating JPEG2000 image code-streams require more careful treatment, since these streams have more complex structures and are subject to various progression orders which further complicates the treatment. We optimize the Merkle hash trees based on progression orders and usage patterns so that the amount of auxiliary authentication information (AAI) being sent to the verifying users is minimum. Users may request batches of images in a single query. However, to verify many images one by one is computationally expensive. Another contribution of the paper is the application of aggregated signature schemes to efficiently authenticating multiple images simultaneously. The rest of the paper is arranged as follows. Section 2 presents the necessary cryptographic preliminaries. Section 3 illustrates the basic concepts and data structures of JPEG2000 code-streams. Section 4 introduces our authentication scheme. Section 5 shows our analysis and evaluation of the scheme. Section 6 concludes the paper. 2 Preliminaries 2.1 Cryptographic primitives 2.1.1 One-way hash function A hash function takes a variable-length input string and converts it to a fixed-length output string, called a hash value. A one-way hash function, denoted as h(·), is a hash function that works in one direction: it is easy to compute a hash value h(m) from a pre-image m; however, it is hard to find a pre-image that hashes to a particular hash value. There are many existing one-way hash functions, such as SHA1 [14]. 2.1.2 Digital signature A digital signature algorithm is a cryptographic tool for generating non-repudiation evidence, authenticating the integrity as well as the origin of a signed message. In a digital signature algorithm, a signer keeps a private key secret and publishes the corresponding public key. The private key is used by the signer to generate digital signatures on messages and the public key is used by anyone to verify signatures on messages. The digital signature algorithms mostly used are RSA [15] and DSA [16]. 2.1.3 Aggregated digital signature An aggregated signature scheme is a digital signature scheme, which allows aggregation of multiple individual

62

R. H. Deng et al.

being detected. This is because he can not find h a and h(n 4 ) such that h(h a | h(h(n 3 ) | h(n 4 ))) = h r , since h(·) is a oneway hash function. For the same reason, the integrity of the transferred data can be guaranteed by the Merkle hash tree, i.e, any tamper of the transferred data will be detected by the recipient.

Root hr A

B

ha

h(n1)

hb

h(n2)

h(n3)

h(n4)

Fig. 2 An example Merkle hash tree

signatures into one aggregated signature such that verification of the single aggregated signature is equivalent to verifying individual component signatures. The concept of aggregated signature is first introduced by Boneh et al. [9] (hereafter referred to as the BGLS scheme). Aggregation of n BGLS signatures amounts to compute the modular product of the individual signatures, while verification of the aggregated signature amounts to n − 1 modular multiplications and 2 bilinear mappings.

2.2 The Merkle hash tree We illustrate the construction and application of the Merkle hash tree [8], or simply the Merkle tree, through an example. To authenticate data values n 1 , n 2 , . . . , n w , the data source constructs the Merkle tree as depicted in Fig. 2 assuming that w = 4. The values of the four leaf nodes are the message hashes, h(n i ), i = 1, 2, 3, 4, respectively, of the data values under a one-way hash function h(·). The value of each internal node is derived from its child nodes. For example, the value of node A is h a = h(h(n 1 ) | h(n 2 )). The data source completes the levels of the tree recursively from the leaf nodes to the root node. The value of the root node is h r = h(h a | h b ) which is used to commit to the entire tree to authenticate any subset of the data values n 1 , n 2 , n 3 , and n 4 in conjunction with a small amount of AAI. For example, a user, who is assumed to have the authentic root value h r , requests for n 3 and requires the authentication of the received n 3 . Besides n 3 , the source sends the AAI h a and h(n 4 ) to the user. The user can then check the authenticity of the received n 3 by first computing h(n 3 ), h b = h(h(n 3 ) | h(n 4 )) and h r = h(h a | h b ), and then checking if the calculated h r is the same as the authentic root value h r . Only if when this check is positive, the user accepts n 3 . In general, to authenticate a subset of the data set, the AAI is the minimum set of node values needed to recompute the root value. For example, to authenticate data value n i , the AAI is the set of values of all the sibling nodes of those nodes on the path from the leaf node n i to the root. The Merkle hash tree can prevent an adversary, who impersonates as the source, from sending bogus data to the client. In the earlier example, an adversary impersonating as the source can not send a bogus n 3 to the client without

3 Overview of JPEG2000 code-streams In what follows, we provide a brief description of the JPEG2000 concepts, which are necessary for an understanding of our authentication scheme. – Tile: JPEG2000 allows an image to be divided into rectangular non-overlapping regions known as tiles, which are compressed independently, as though they were entirely distinct images. Without loss of generality, we will only consider single tile code-streams. – Component: An image is comprised of one or more components. For example, a RGB color image has three components with one component representing each of the red, green, and blue color planes. – Resolution-increment and resolution: Given a component, a (n R − 1)-level dyadic wavelet transform is performed. The first wavelet transform decomposes a component into four frequency subbases LL1 (horizontally lowpass and vertically lowpass), LH 1 (horizontally lowpass and vertically highpass), HL1 (horizontally highpass and vertically lowpass) and HH 1 (horizontally highpass and vertically highpass). The second wavelet transform further decomposes LL1 into another four subbases LL2 , LH 2 , HL2 , and HH 2 . Finally, the (n R − 1)th wavelet transform decomposes LLn R −2 into four subbases LLn R −1 , LH n R −1 , HLn R −1 , and HH n R −1 . Therefore, a (n R − 1)-level dyadic wavelet transform generates n R sets of subbases, denoted as R0 = LLn R −1 , R1 = {LH n R −1 , HLn R −1 , HH n R −1 }, . . . , Rn R −1 = {LH 1 , HL1 , HH 1 }. We refer Ri as resolution-increment i of a code-stream. The n R resolution-increments correspond to n R image sizes or resolutions. The resolution 0 image is constructed from resolution-increment 0, R0 . The resolution 1 image is constructed from resolutionincrements 0 and 1, R0 and R1 . In general, the resolution r image is constructed from resolution-increments 0 to r , {R0 , R1 , . . . , Rr }. Note that the resolution n R − 1 image is the original image. – Layer-increment and layer: Following the wavelet decomposition, wavelet coefficients are quantized and each quantized subband is partitioned into small rectangular blocks, referred to as code-blocks. Each code-block is independently entropy encoded to create a compressed bit-stream which is distributed across n L quality layers. Layers determine the quality or signal-to-noise ratio of the reconstructed image. Let L 0 denote the code-stream data needed to form a layer 0 image. Let L l be the additional code-stream data to form a layer l image given L 0 , L 1 , . . . , L l − 1, l = 1, 2, . . . , n L − 1. That is, a layer l


image is formed from {L 0 , L 1 , . . . , L l−1 , L l }. Note that the layer n L − 1 image is the original image. We refer L l as layer-increment l, l = 0, 1, 2, . . . , n L − 1. – Precinct: In order to provide locality for accessing certain portions (e.g., ROI) of an image, an intermediate space–frequency structure known as precinct is provided in JEPG2000. Unlike the tile and code-block partitions, the precinct partition does not affect the transformation or coding of sample data; it instead plays an important role in organizing compressed data within a code-stream. A precinct is a collection of spatially contiguous codeblocks from all subbases at a particular resolution. – Packet: Packet is the fundamental building block in a JPEG2000 code-stream. It comprises the compressed bit-stream from code blocks belonging to a specific component, resolution, layer, and precinct. – Progression orders: JPEG2000 supports progression in four dimensions: quality layer (L), resolution (R), spatial location (P) and component (C) [1–3]. These dimensions of progression can be “mixed and matched” within a single code-stream. The standard defines five progression orders: LRCP, RLCP, RPCL, PCRL, and CPRL.

63

Root

R0

We first show how to use a digital signature and the Merkle hash tree synergically to authenticate and verify sub-images from one code-stream. We then extend our approach to efficiently authenticate and verify sub-images from multiple code-streams based on the BGLS aggregated signature scheme. 4.1 The symmetric Merkel hash tree for JPEG2000 code-streams To keep our presentation compact and without the loss of generality, we assume that a code-stream has one tile and one component, each resolution has the same number of precincts and packets are arranged in RLCP order. Then a code-stream can be reviewed as a collection of precincts {Pp , p = 0, 1, . . . , n P − 1}, layer-increments {L l , l = 0, 1, . . . , n L − 1}, and resolution-increments {Rr , r = 0, 1, . . . , n R − 1}. The Merkle tree for this codestream, called symmetric Merkle tree, is shown in Fig. 3. In the tree of Fig. 3, a leaf corresponds to a packet and is assigned the hash of the packet under a one-way hash function. Since a packet in a JPEG2000 code-stream is uniquely identified by a resolution, layer, and precinct, the path from the root to a leaf node in Fig. 3 identifies a unique packet. For example, the path from the root to the leftmost leaf node is specified by R0 , L 0 , and P0 . Hence, the value of this leaf node is the hash of the packet which corresponds to resolution-increment 0, layer-increment 0, and precinct 0. Once the values of all the leaf nodes are assigned, the values of the other nodes, including that of the root, can be computed recursively.

Ln …

L0

L

P0

P

−1

…Ln

P0

L

−1

…

…

Pn

RnR −1

L0

−1

…

Pn

P

−1

P0

…

Pn

P

−1

P0

Pn

P

−1

Fig. 3 The symmetric Merkle tree for a code-stream Root

1

R0 L0

P0 y1

4 The authentication scheme

……

R1 L1

P1 y2

P0 y3

L0

P1 y4

P0 y5

L0

L1

P1 y6

2

R2

P0 y7

P1 y8

P0 y9

R3 L1

P1 y10

P0 y11

L0

P1 y12

P0 y13

L1

P1 y14

P0 y15

P1 y16

Fig. 4 The symmetric Merkle tree for an example code-stream

Let I denote the original code-stream and I denote a sub-image of I . Let σ denote the signature on the root value of the Merkle tree of I and denote the AAI for I . When a user requests I from the publisher, the publisher extracts the required sub-image I from I , calculates the AAI and sends back {I , , σ } to the user. We use an example to further illustrate our scheme. Consider a code-stream with four resolutions, two layers, and two precincts. Its symmetric Merkle hash tree is given in Fig. 4. There are 16 leaf nodes that correspond to the 16 packets in the code-stream, denoted as y1 , y2 , . . . , y16 . For example, the leftmost leaf node P0 corresponds to the packet specified by resolution-increment 0, layer-increment 0, and precinct 0. The producer of the code-stream assigns a value to each node in the tree according to the process described earlier. As examples, the leftmost P0 node has a value of h(y1 ), the next node P1 has a value of h(y2 ), and the leftmost L 0 node has a value of h(h(y1 ) | h(y2 )). The producer then generates a digital signature on the root value. The authenticated code-stream, which is forwarded to a publisher, consists of the code-stream and the digital signature. When a user sends a request for a transcoded sub-image of resolution 1, the publisher sends packets y1 , y2 , . . . , y8 , the digital signature and the AAI to the user. Here, the AAI consists of the values of the nodes labeled as (1) and (2) in Fig. 4. To authenticate the received packets, the user first re-computes the root value of the hash tree based on the received packets and the AAI. The user then verifies the digital signature using the producer’s public key and the computed root value and accepts the received packets as authentic only if the verification is successful.

64

R. H. Deng et al.

Root

4.2 The optimized Merkle hash tree for JPEG2000 code-streams A user request for only one of the parameters – resolution, layer, and precinct – is called a single-parameter request. They are resolution-request, layer-request, and precinctrequest. A request for more than one parameters is called a multiple-parameter request. In the following, we consider how to optimize single-parameter requests in terms of minimizing the amount of AAI. Discussion on optimizing multiple-parameter requests is treated in [17]. To minimize the amount of AAI for resolution-request, first we note that the nodes corresponding resolutionincrements should be placed as high as possible (i.e., right below the root) in the Merkle tree. Next, we remark that resolutions and resolution-increments are two different concepts (see Sect. 2). A resolution r sub-image is constructed from resolution-increments 0 to r , {R0 , R1 , . . . , Rr }. The resolution-increment Rr represents the additional packets needed to construct a resolution r sub-image from a resolution r − 1 sub-image. Therefore, a resolution-request will ask for the sets of continuous resolution-increments starting from resolution-increment 0. A similar discussion applies to layers and layer-increments. Based on the earlier observation, the symmetric Merkle tree in Fig. 3 is modified as shown in Fig. 5, where the nodes representing either resolution-increments or layer-increments are chained together to reflect their incremental relationships. As before, each leaf node here is assigned the message digest of a unique packet. However, there are multiple nodes of the same type on a path from the root to a leaf node. For example, nodes on the path from the root to the second left P0 node are R0 , L 0 , L 1 , and P0 . There are two nodes of type L. Hence, the method of mapping packets to leaf nodes as used for Fig. 3 need to be modified: We ignore the nodes of the same type except the one closest to the leaf node. In the earlier example, we ignore L 0 , so the nodes on the pruned path are R0 , L 1 and P0 , and the leaf node corresponds to the packet specified by resolution-increment 0, layer-increment 1, and precinct 0. Consider again the same code-stream in RLCP order with four resolutions, two layers, and two precincts. Its optimized Merkle hash tree is shown in Fig. 6. Here again we denote the 16 packets associated with the 16 leaf nodes, from left to right, as y1 , y2 , . . . , y16 . When a user requests for the sub-image of resolution 1, the publisher sends packets y1 , y2 , . . . , y8 , the digital signature and the value of the node labeled with (1) as the AAI. Note that to authenticate the same sub-image, the tree in Fig. 4 needs two message hashes (i.e., node values) as AAI, while the optimized tree requires only one message hash. This code-stream is just an over simplified example used to illustrate our concept. The JPEG2000 standard allows a code-stream to support up to 33 resolutions and 65,535 layers. As the numbers of resolutions and layers increase, the amount of reduction on the AAI becomes significant using the optimized Merkle tree.

R0

R1 RnR −1

L0

L0

L1

L1 …

P0

Ln

L

Pn

P −1

…

−1

P0

…

P0

Pn

P

−1

Ln P

−1

…

P0

…

P0

Pn

P

−1

L

Pn

Pn

P

−1

…

P0

−1

Pn

P

−1

Fig. 5 The optimized Merkle tree for a code-stream with order RLCP Root R0

R1

L0

L0

P0 P0

L0

L1

P1 P1

R3

L0

L1 P0

1

R2

L1 P0

P1 P0

P1

L1 P0

P1 P0

P1

P1

P0

P1

Fig. 6 The optimized Merkle tree for the example code-stream with order RLCP

As has been mentioned in Sect. 3, five types of packet progression orders are supported by JPEG2000 to cater to different application requirements. The Merkle tree in our scheme can be optimized to match the underlying progression orders or the user request patterns. 4.3 Batch verification using aggregated signatures A user may request for a batch of sub-images from multiple producers at the same time. To authenticate these subimages, a direct solution is that the publisher sends one signature per sub-image to the user and the user verifies these sub-images one by one on the basis of the corresponding signatures. This direct solution, however, is not efficient, since signature verifications are computationally expensive operations [18]. The BGLS scheme can be used in our authentication scheme to allow a user to authenticate a batch of subimages on the basis of just one aggregated signature, instead of multiple signatures. The use of aggregated signatures in our authentication scheme is as follows. Assuming that a user request for a batch of sub-images from multiple producers. Let Iij (i = 1, · · · , k; j = 1, · · · , ti ) denote the requested sub-image


65

of code-stream Ii j where k denotes the number of producers and ti denotes the number of sub-images from producer i the user requests. The publisher computes the aggregated signak ti ture σ from σ = i=1 j=1 σi j , where σi j is the BGLS signature on code-stream Ii j signed by producer i. The publisher then extracts each required sub-image Iij from the corresponding code-stream Ii j and generates the necessary AAI i j . Finally, the publisher sends the querying user all the extracted sub-images Iij , their corresponding AAI i j and the single aggregated signature σ . On receiving the response from the publisher, the user constructs an individual Merkle tree for each sub-image Iij with the data of the sub-image and its corresponding AAI i j and calculates the root value of the Merkle tree h i j . Then the user verifies the authenticity of all the sub-images using all the calculated root values and the aggregated signature σ k which amounts a computation cost of i=1 ti − 1 modular multiplications as well as (k + 1) bilinear mappings.

Table 1 The average amount of AAI when the Merkle tree is adapted to three different orders under three request frequency distributions

LRCP RLCP PCRL

L-requests (80%) R-requests (15%) P-requests (5%)



1.025 2.1125 3.475

1.675 1.3 1.85

6.6 7.35 1.35

We use the same code-stream as in Fig. 6 to further illustrate the performance of different ordered authentication Merkle trees. The results on the average amount of AAI under three different request frequency distributions are shown in Table 1. The first column indicates the progression order on which the construction of the Merkle tree is based. The table clearly indicates that in order to minimize the amount of AAI, the ordering of the Merkle tree should ideally match that of the request frequency distributions.

5 Analysis and evaluation In this section, we first analyze the AAI overhead in our authentication scheme using individual signatures. Then we evaluate the performance of the aggregated signature based authentication scheme and compare it with that of the individual signature based authentication scheme in terms of computation cost on the publisher side, and computation cost and communication cost on the user side. 5.1 AAI overhead using individual signatures Without the loss of generality, we analyze the AAI overhead for a single-tile code-stream with n L layers, n R resolutions, n C components, and n P precincts in each resolution. Define I Ni as 0 if i = N ; i IN = 1 if i = N . Assume that a user request a sub-image of layer l, resolution r , and p precincts. Then the overhead incurred by AAI, in terms of the number of hash values, is given by NLRCP = Inl L + l × Inr R + l × r × (n C − c) × IncC p

+ l × r × c × (n P − p) × In P

(1)

for a LRCP-ordered authentication Merkle tree, p

We now evaluate the performance of aggregated signature based authentication scheme from three aspects: (1) the computation cost incurred by aggregating multiple signatures on the publisher side; (2) the computation cost incurred by verifying the aggregated signature on the user side; and (3) the communication overhead incurred by transmitting the aggregated signature. We compare the aggregated signature based scheme with the individual signature based scheme. To make the comparison concrete, we assume that a publisher hosts code-streams originated from and signed by k producers, and a user wants to request and verify k × t sub-images with t sub-images from each producer. The comparison results are listed in Table 2. It should be noted that communication cost due to the AAI is the same in both the schemes and that computation cost due to processing of the AAI (i.e., computation of hash values) is negligible compared with that due to signature verification [18]. Therefore, only the cost due to signatures is shown in Table 2, where Multim ( p) denotes m modular p multiplications with p being a large prime number, BM(m) denotes m bilinear mappings and |S| denotes the size of an individual signature in bits. Table 2 Comparison of individual signature based scheme and aggregated signature based scheme in terms of computation communication costs

NRLCP = Inr R + r × Inl L + r × l × (n C − c) × IncC + r × l × c × (n P − p) × In P

5.2 Performance using aggregated signatures

(2)

Aggregated Individual signature signature

for a RLCP-ordered authentication Merkle tree, and p

NPCRL = (n P − p) × In P + p × (n C − c) × IncC + p × c × Inr R + p × c × r × Inl L

(3)

for a PCRL-ordered authentication Merkle tree, respectively.

Publisher computation User computation

0 BM(2 × k × t)

Communication overhead k × t × |S|

Multik∗t−1 ( p) Multik∗t−1 ( p) +BM(k + 1) |S|

600 500 400 300 200 100 0 1

2 3

4

5 6

7

8 9 10

usercompu.cost (in msecs)

700

user compu. cost (in msecs)

R. H. Deng et al. user compu. cost (in msecs)

66

3500 3000 2500 2000 1500 1000 500 0

7000 6000 5000 3000

aggregated signature

2000 1000

1 2 3 4 5 6 7 8 9 10

number of signers (a) t=1

individual signature

4000

number of signers (b) t=5

0 1 2 3 4 5

6 7 8 9 10

number of signers (c) t=10

Fig. 7 User computation cost using aggregated signatures

From Table 2 we can make the following observations: (1) the publisher needs to perform additional modular multiplication operations in the aggregated signature based authentication scheme; however, the computation overhead incurred by such operations is negligible for a server machine (see numerical results later); (2) the user saves k(2t − 1) − 1 bilinear mapping operations in the aggregated signature based scheme. This reduction on computation overhead is very significant for a typical client device, since a bilinear mapping is much more expensive than a modular multiplication; and (3) the communication overhead is kept at constant (i.e., the size of 1 signature |S|) in the aggregated signature based scheme, whereas the overhead in the individual signature based scheme is linear to the number of total sub-images being requested. Experiment results on the BGLS signature scheme with p = 512 bits were obtained in [19] using a P3-977 MHz Linux machine with the OpenSSL library for computing the individual operations. From the experiment results in [19], we can derive that Multi1 ( p) = 12 × 10−2 ms and BM(1) = 31 ms. Note that BM(1)/Multi1 ( p) > 2.5 × 102 , i.e., a bilinear mapping is much more computationally expensive than a modular multiplication. User computation costs with respect to the number of producers are plotted in Fig. 7, where t is the numbers of sub-images requested from each producer. Figure 7 clearly shows the aggregated signature based scheme outperforms the individual signature based scheme in all aspects. The cost discrepancy between the two schemes becomes extremely significant, as the number t × k of total requested sub-images gets larger. 6 Conclusion In this paper, we have introduced two schemes for authenticating JPEG2000 image code-streams disseminated by an untrusted server in a third-party publication scenario. The schemes are designed on the basis of the Merkle hash tree and digital signatures. Utilizing the hierarchical structure of a JPEG2000 code-stream, we first constructed the Merkle hash tree, which can be used to authenticate any sub-image from one code-stream signed with one digital signature. We then incorporated the recently proposed aggregated signature scheme in the literature with the Merkle hash tree based approach in order to reduce the computation cost on the

client side for verifying batch sub-images originated from multiple producers. A preliminary version of the paper was presented in [17]. We have implemented our schemes in a prototype, which demonstrated the practical feasibility and compatibility of the proposed schemes with the core part of the JPEG2000 standard. Finally, we remark that although our schemes are presented in the context of authenticating JPEG2000 codestreams, they can be applied for efficient and flexible authentication of any structured data sets, including other image code-streams such as MPEG4 code-streams.

References 1. Taubman, D.S., Marcellin, M.W.: JPEG2000 – Image Compression Fundamentals, Standards and Practice. Kluwer Academic Publishers, Drodrecht (2000) 2. Rabbani, M., Joshi, R.: An overview of the JPEG 2000 still image compression standard. Signal Process. Image Commun. 17(1), 3– 48 (2002) 3. ISO 154447ITU-T Recommendation T.800, http://www.jpeg.org 4. Schneier, B.: Applied Cryptography. Wiley, New York (1996) 5. Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC Press, Boca Raton (1996) 6. Grosbois, R., Gerbelot, P., Ebrahimi, T.: Authentication and access control in the JPEG 2000 compressed domain. In: Proceedings of the SPIE 46th Annual Meeting, Applications of Digital Image Processing XXIV, vol. 4472, pp. 95–104 (2001) 7. Lin, C.Y., Chang, S.F.: Semi-fragile watermarking for authenticating JPEG visual content. In: SPIE Security and Watermarking of Multimedia Contents II EI ’00 (2000) 8. Merkle, R.C.: A certified digital signature. In: Proceedings of Advances in Cryptology – Crypto ’89. Lecture Notes on Computer Science, vol. 0435, pp. 218–238. Spriner-Verlag, Berlin Heidelberg New York (1989) 9. Boneh, D., Gentry, C., Lynn, B., Shacham, H.: Aggregate and verifiably encrypted signatures from bilinear maps. In: Biham, E. (ed.) Advances in Cryptology – EUROCRYPT’2003, International Association for Cryptologic Research. Lecture Notes in Computer Science 2656, pp. 401–415. Springer-Verlag, Berlin, Germany (2003) 10. Devanbu, P., Gertz, M., Kwong, A., Martel, C., Nuckolls, G., Stubblebine, G.: Flexible authentication of XML documents. In: Proceedings of the 8th ACM conference on Computer and Communication Security, pp. 136–145 (2001) 11. Naor, M., Nissim, K.: Certificate revocation and certificate update. In: Proceedings of the 7th USENIX Security Symposium, pp. 217–230 (1999)


12. Goodrich, M.T., Tamassia, R., Schwerin, A.: Implementation of an authenticated dictionary with skip lists and commutative hashing. In: Proceedings of DISCEX II’01, vol. 2, pp. 1068–1083 (2001) 13. Devanbu, P., Gertz, M., Martel, C., Stubblebine, S.: Authentic third-party data publication. In: Proceedings of the 14th IFIP WG11.3 Working Conference in Database Security. IFIP Conference Proceedings, vol. 201, pp. 101–112. Kluwer Academic Publishers, Drodrecht (2001) 14. National Institure of Standards and Technology, Secure Hash Standard (SHS), FIPS Publication 180-1 (1995) 15. Rivest, R.L., Shamir, A., Adleman, L.M.: A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21(2), 120–126 (1978)

67

16. National Institure of Standards and Technology: Proposed Federal Information Processing Standard for Digital Signature Standard (DSS). Federal Register, vol. 56, no. 169, pp. 42980–42982 (1991) 17. Peng, C., Deng, R.H., Wu, Y., Shao, W.: A flexible and scalable authentication scheme for JPEG2000 image codestreams. In: Proceedings of the ACM Multimedia, pp. 433–441 (2003) 18. Rivest, R., Shamir, A.: Payword and Micromint: Two simple micropayment schemes. In: Proceedings of Security Protocols Workshop, pp. 69–87 (1996) 19. Mykletun, E., Narasimha, M., Tsudik, G.: Authentication and integrity in outsourced databases. NDSS 2004 (2004)