Abstract: An aggregate signature is a single short string that convinces any verifier that, for all 1≤i≤n, signer S_i signed message M_i, where the n signers and n messages may all be distinct. The main motivation of aggregate signatures is compactness. However, while the aggregate signature itself may be compact, aggregate signature verification might require potentially lengthy additional information-namely, the (at most) n distinct signer public keys and the (at most) n distinct messages being signed. If the verifier must obtain and/or store this additional information, the primary benefit of aggregate signatures is largely negated.

This paper initiates a line of research whose ultimate objective is to find a signature scheme in which the total information needed to verify is minimized. In particular, the verification information should preferably be as close as possible to the theoretical minimum: the complexity of describing which signer(s) signed what message(s). We move toward this objictive by developing identity-based aggregate signature schemes. In our schemes, the verifier does not need to obtain and/or store various signer public keys to verify; instead, the verifier only needs a description of who signed what, along with two constant-length "tags": the short aggregate signature and the single public key of a Private Key Generator. Our scheme is secure in the random oracle model under the comptational Diffie-Hellman assumption over pairing-friendly groups against an adversary that chooses its messages and its target identities adaptively.

Introduction

Authentication is crucial for many cryptographic applications. Improving the performance of building blocks, like digital signatures, that provide a means for authentication is therefore an esentail goal. While time complexity is a well-known traditional measure for evaluating performance, communication complexity is becomming increasingly important for two reasons. First, consider wireless devices (e.g., PDAs, cell phones, RFID chips, and sensors). Here, battery life is often more a limiting bottleneck than processor speed. Communicating a signle bit of data consumes several orders of magnitude more power than executing a basic 32-bit arithemetic instruction. Second, consider wireless network scenarios (e.g., MANETS, cellular networks, tactical networks, and sensor nets). Here reliable bandwidth may be more of a limiting factor than computation. In these cases it would be preferable to limit the communication requirements (i.e., the size) of a digital signature. An aggregate signature is one technique towards achieving this aim.

Aggregate signatures. In an aggregate signature scheme, multiple signatures can be aggregate into a compact "aggregate signature," even if these signatures are on (many) different documents and were produced by (many) different signers. This useful in many real-world applications. For example, certificate chains in a hierarchical PKI of depth n consist of n signautres by n different CAs on n different public keys; by using an aggregate signature scheme, this chain can be compressed down to a single aggregate certificate. Another application is secure routing. In Secure BGP, each router surcessively signs its segment of a path in the network, and forwards the collection of signatures associated with the path to the next router; forwarding these signatures entails a high transmission overhead that could be reduced by using aggregate signatures. Aside from compactness, aggregate signatures have other advantages. For example, in scenarios such as database outsourcing and dynamic content distribution on may want to prevent a malicious party from removing a signature from a collection of signatures without being detected. An aggregate signature scheme makes this possible, since a signature that has been aggregated cannot (under certain conditions) be sparated.

Currently, two aggregate signature schemes exist. The first uses bilinear maps and supports flexible aggregation - i.e., given n individual signatures sigma_1, ..., sigma_n, anyone can aggregate them in any order into an aggregate signature sigma. The second uses a weaker assumption - namely, certified trapdoor permutations - but it permits only sequential aggregation - i.e., the n-th signer must aggregate its own signature into the aggregate signature formed by the first n-1 signers.

For both schemes above, the aggregate signature is compact (i.e., its size is independent of n). However, the total information V needed to verify the aggregate signature - namely, the aggregate signature itself, the public keys of the individual signers, and a description of the respective messages that they signed - is not necessarily compact at all. Of course, V must (information - theoretically) contain a description D of  what signer signed what message, since the verification information must convince the verifier that certain signers signed certain messages. But |D| can grow slowly with the number of individual signatures n; e.g., in a routing application, one can use IP addresseds as identities, and we can reduce communication further since the higher - order bits of the IP addresses of consecutive routers may be identical, so only need to be transmitted once.

Beyond this information - theoretic minimum, however, V in current aggregate signature schemes must also contain individual signer public keys, whose length is dictated by the security parameter of the signature scheme (not by basic information - theoretic considerations). Theoretically, this means that |V|-|D| grows linearly with n. Practically speaking, this means that current aggregate signature schemes may not perform significantly better than traditional signature schemes in situations where verifiers cannot be expected to already have the signer’ public keys - e.g., in a dynamic multi - hop network in which a node is unlikely to have a prior relationship with a neighboring node. Clearly, it would be preferable if V could specify the signers by their identities rather than by their individual public keys.

Identity - Based signatures. In identity - based cryptography (IBC), the central idea is to simplify public key and certificate management  by using a user’s "identity" (e.g., its email address) as its public key. For this to be possible, the IBC system requires a trusted third party, typically called a "Private Key Generator" (PKG), to generate user private keys from its "master - secret" and the user’s identity. Only the PKG has a traditional "random - looking" public key. In an identity - based encryption (IBE) scheme, the sender encrypts a message using the recipient’s identity and the PKG’s public key; it need not obtain the recipient’s public key and certificate before encrypting, since the recipient has no traditional public key and since the sender knows that the recipient (or an private attacker) will not be able to decrypt unless it has received an identity - based private key from the PKG (in effect, an implicit certificate) In an identity - based signature (IBS) scheme, the verifier verifies a signature by using the signer’s identity and PKG’s public key; the verification information does not include any certificate or any individual public key  for the signer.

Research on IBS has experienced a revival in the wake of the discovery - independently by Boneh and Franklin and by Cocks - of practical IBE schemes. (Early schemes include []; recent schemes and analyses include [].) unfortunately, IBS does not have the significant infrastructural advantages over traditional public - key signing that IBE has over traditional public - key encryption. In IBE, the fact that the sender does not  to obtain recipient’s public key and certificate before encrypting means that no infrastructure (i.e., public - key infrastructure (PKI)) needs to be deployed to distribute such information to third parties (include non - clients); rather, the authority (the PKG) only needs infrastructure to distribute private keys directly to its clients. On the other hand, IBS and public - key signing (PKS) are analogous infrastructurally: in IBS (resp. PKS), the PKG (resp. CA) sends a private key (resp. certificat) to each client. Thus, the main advantage of IBS over PKS, at least abstractly, turns out to be communication efficiency, since (unlike PKS) the signer does not need to send an individual public key and certificate with its signature.

 This advantage of IBS becomes more compelling when we consider multiple signers, all of which are clients of the same PKG. In this setting, the verifier needs only one traditional public key (the PKG’s) to verify multiple identity - based signatures on multiple documents. Unfortunately, current identity -  based signatures are not aggregable. Interestingly, multiple - signer IBS therefore has precisely the opposite problem of aggregate signing: for IBS, the public key is (in some sense) aggregable, while the individual signatures are not.

Goals and Challenges. Our goal is simple: a signature scheme (allowing distinct signers to sign distinct document) in which the total verification  infromation is minimized. We cannot do better than the information - theoretic lower bound of describing who signed what, but we would like to get as close to this lower bound as possible.

Based on the above discussion, one natural approach is to construct an "indentity - based aggregate signature" (IBAS) scheme -  i.e., a scheme in which the verification infromation (apart from the required description of who signed what) consists only of a single aggregate signature and single public key (of the PKG). In a sense, identity - based aggregate signatures would really address the motivating application considered first in the context of regular (non ID-based) aggregate signatures.

However, there certainly does not appear to be any generic way of combining an aggregate signature scheme with an IBS scheme to achieve this desideratum. To see the difficulty, note that each of the current aggregate signature schemes are deterministic, and with good reason; if each successive signer contributed randomness to the aggregate signature in a trivial way, this randomness would cause the size of the signature to grow linearly with n - hence the signature would not be compact. On the other hand, identity - based signature schemes tend to be randomized; typically, the signer uses the Fiat - Shamir heuristic (which involves choosing a random commitment and treating the output of a hash function as the challenge to which the signer responds.) to prove knowledge of the authority’s signature on its identity. In short, current approaches for constructing aggregate signatures appear to be fundamentally at odds with current approaches for constructing identity - based signatures. To construct an IBAS scheme, it seems we must some how find a way to "aggregate the randomness" provided by the multiple signers.

Results. Our first contribution is a formal definition of identity - based aggregate signatures and a corresponding formal security model. Second, we describe, as a stepping stone, an identity - based multi - signature scheme (which may be of independent interest). Third, we present a concrete IBAS scheme that meets our definition. As desired, our scheme allows multiple signers to sign multiple documents in such a way that the total verification information, apart from a description of who signed what, consists only of a short aggregate signature (which consists of only 2 group elements and a short (e.g.,  160 - bit) string) and the PKG’s public key (which is also short -  about the same size as the PKG’s public key in Boneh - Franklin). Our scheme is also very efficient computationally. In fact, it allows more efficient verification than the aggregate signature scheme of [], since verification requires only three pairing computations, regardless of the value of n, while [] uses O(0) pairing computations. (Note: verification in our scheme uses O(0) elliptic curve scalar multiplications, but these can be computed quite quickly.) Later we describe certain extensions and additional benefits of our scheme.

 Our shceme is provably secure in the random oracle model, assuming the hardness of computational Diffie - Hellman over groups with bilinear maps. In our security model, the adversary can make q_E adaptive key extraction queries (wherein he receives the singing key corresponding to any ID of his choice), q_S adaptive signature queries (wherein he receives the signature on any message of his choice), and q_H hash queries (wherein he receives the output of a hash function, modeled as random oracle, on inputs of his choice). The adversary succeeds if heconstructs a single non - trivial forgery. The concrete security loss in our scheme is roughly q_Eq_Hq_S. While one would prefer a smaller loss, it is worth noting tha typical ID-based signature schemes usually suffer from a concrete security loss of roughly q_Eq_S because the simulator usually has to guess the ID and message that will be used in the forgery. We further note that such a quadratic loss is also inherent in schemes where security is proved using the forking lemma.

We remark that in our scheme all signers must use the same (unique) random string w when siging - this step seems necessary to enable signature aggregation. Choosing such a w may be straightforward in certain settings. For example, if the signers have access to loosely synchronized clocks, then w could be chosen based on the current time. Further, if w is sufficiently long (i.e., accounting for birthday bounds), then it will be statistically unique. In order to alleviate any cost incurred in choosing w, we describe a simple extension of our scheme that allows a signer to securely re - use the same w a constant number of times.

Aside from requiring a common value of w, aggregation in our scheme is very flexible. Anybody can aggregate individual indentity - based signatures into an indentity - based aggregate signature, and aggregate smaller aggregates into larger aggregates. Moreover, our scheme permits aggregation across multiple trusted authorities; i.e., signers under different PKGs can aggregate their signatures. As a stepping stone to IBAS, we also describe an identity - based multisignature (in which all signers sign the same message) that may be of independent interest.

Other related work. Aggregate signatures are related to , but more flexible than, multisignatures. Although the term "multisignature" has been used in the literature to denote a variety of different types of schemes, we will use the term to denote an aggregate signature in which all users sign the message. Aggregate singatures are also tenuously related to threshold signatures. Recall that, in a threshold signature scheme, t signature components from any t signers cna be combined into a single signature, for some threshold t≤n, The signers must undergo a large setup cost, they all sign the same messgae, and the verifier cannot tell which signers contributed components to a complete threshold signature. Secure identity - based threshold signature schemes are known.

Subsequent to our work, a recent paper claimed an ID-based aggregate signature construction. However, "identity - based aggregate signatures" may not be the best term to describe this result since each signer S_i that participates in the creation of a signature must first generate a random scalar r_i and broadcast r_iP (for a certain elliptic curve point P) to all of the other signers so that they can each compute (sigma r_iP). Signer S_i then inputs (sigma r_iP) and its message m_i. in to a hash function to obtain a signature scheme via the Fiat-Shamir heuristic. Later, individual signatures can be aggregated. However, because of the large setup cost (in which the users essentially broadcast their key shares) and the fact that the signature cannot verified untill of all the signers contribute, this scheme actually bears some resemblance to an indentity - based threshold signature scheme. Also subsequent to our work,  Herranz describes a Schnorr - based IBAS scheme that permit "partial" aggregation - that is, signatures can only be aggregated if they all come from the same signer.

Abstract: With computer networks spreading into a variety of new environments, the need to authenticate and secure communication grows. Many of these new enviroments have particular requirements on the applicable cryptographic primitives. For instance, several applications require that communication overhead be small and that many messages be processed at the same time. In this paper we consider the suitability of public key signatures in the latter scenario. That is, we consider signatures that are 1) short and 2) where many signatures from (possibly) different signers on (possibly) different messages can be verified quickly. Prior work focused almost exclusively on batching signatures from the same signer.

Introduction

As the world moves towards pervasive(普通深入的) computing and communication, devices from vehicles to dog collars will soon be expected to communicate with their environments. For example, many governments and industry consortia(公会) are currently planning for the future of intelligent cars that constantly communicate with each other and transportation infrastructure to prevent accidents and to help alleviate traffic congestion. Raya and Hubaux suggest that vehicles will transmit safety messages every 300ms to all other vehicles within a minimum range of 110 meters, which in turn may retransmit these messages.

For such pervasive systems to work properly, there are many competing constraints. First, there are physical limitations, such as a limited spectrum allocation for specific types of communications and the potential roaming(漫游) nature of devices, that messages be dept very short and (security) overhead be minimal. Yet for messages to be trusted by their recipients, they need to be authenticated in some fashion, so that entities spreading false information can be held accountable. Thus, some short form of authentication must be added. Third, different messages from many different signers may need to be verified and processed quickly (e.g. every 300ms). A possible fourth constraint that these authentications remain anonymous or pseudonymous, we leave as an exciting open problem.

In this work, we consider the suitability of public key signatures to the needs of pervasive communication applications. Generating one signature every 300ms is not a problem for current systems, but transmitting and /or verifying 100+ messages per second might pose a problem. Using RSA signatures for example seems attractive as they are verified quickly, however, one would need approximately 3000 bits to represent a signature on a message plus the certificate (i.e., the public key and signature on that public key) which might be too much for some applications. While many new schemes based on bilinear maps can provide the same security with significantly smaller signatures, they take significantly more time to verify. Thus, it is not immediately clear what the proper tradeoff between message length and verification time is for many pervasive commuincation applications. However, in some applications, there is evidence that doing a small amount of additional computation is more advantageous than sending longer messages. For example, Landsiedel, Wehrle, and Gotz showed that for applications using Mica2 sensors transmitting data consumes significantly more battery power than keeping the CPU active.

Fast verification of many signatures are an interesting problem in other scenarios as well. Consider a scenario where a mail server receives a lot of signed e-mails. To handle a variety of different e-mail clients on the internal network, it is easier to let the server do signature verification and insert a message into the body of the e-mail about who signed it. Assuming the internal network and the mail server are secure, clients can rely on the signature being correct without having to verify it themselves. However, the actual digital signature can still be attached to the e-mail should a dispute about the authenticity of the message later arise. To keep resource usage on the server to a minimum, signature verification should be fast, but we can take advantage of the fact that the server can buffer messages for short period before verifying all of them.