Int. J. Inf. Secur. (2015) 14:335–345 DOI 10.1007/s10207-014-0259-4
REGULAR CONTRIBUTION
On the practicability of using group signatures on mobile devices: implementation and performance analysis on the android platform Andreu Pere Isern-Deyà · Llorenç Huguet-Rotger · M. Magdalena Payeras-Capellà · Macià Mut-Puigserver
Published online: 15 August 2014 © Springer-Verlag Berlin Heidelberg 2014
Abstract A group signature is a convenient cryptographic primitive to tackle with authentication and privacy problems. In the literature, it is used as an underlying black box by several theoretical proposals of secure applications and services, such as e-cash schemes, automatic fare collection systems and so on. However, there is a lack of implementations of group signature proposals to test their applied efficiency instead of purely show their mathematical complexity analysis. In this paper, we present, to the best of our knowledge, the first complete implementation and performance analysis of two group signature schemes on mobile devices: the pairing-based group signature due to Boneh et al. (referenced as BBS scheme) and the state-of-the-art non-pairing group signature by Ateniese et al. (called ACJT scheme). We test both implementations and we analyze their performance on a conventional laptop and two Android smartphones, comparing the gathered results to provide some interesting insights about which security parameter configurations perform better. This implementation expects to be useful so as to gain practice to know which is the real impact of using group signatures to the performance of applications, especially those used on mobile devices. A. P. Isern-Deyà (B) · L. Huguet-Rotger · M. M. Payeras-Capellà · M. Mut-Puigserver Department of Mathematics and Computer Science, University of Balearic Islands, Ctra. de Valldemossa km.7.5, 07122 Palma de Mallorca, Illes Balears, Spain e-mail:
[email protected] L. Huguet-Rotger e-mail:
[email protected] M. M. Payeras-Capellà e-mail:
[email protected] M. Mut-Puigserver e-mail:
[email protected]
Keywords Group signatures · Implementation · Performance analysis · Mobile devices · Pairing-friendly elliptic curves
1 Introduction Finding authentication methods has been a central problem in cryptography. A great number of authentication protocols and cryptographic tools have been created to establish authenticated channels. One of them is the group signature scheme which is a useful anonymous non-repudiable multiuse credential primitive that was introduced by Chaum and Van Heyst [14] that can be used to provide authenticity and anonymity to users at the same time. Group signatures provide anonymity for signers. It involves a group of users, each holding a membership certificate. Any member of this group can sign messages that are publicly verifiable while hiding the identity of the actual signer within the group. Thus, the resulting signature keeps the signer’s identity secret because the verification procedure employs only the public key of the group. In case of any dispute or abuse, only the group manager can trace the signature, undoing its anonymity with a special trapdoor. So, only the group manager can open an individual signature revealing the identity of its originator. Formulating an efficient group signature scheme has been a research target. Ateniese et al. [2] presented the ACJT group signature based on the Strong-RSA assumption. However, this scheme generates very long signatures, so new proposals had been presented in the literature to reduce them [8,10,23,28]. Boneh et al. [8] presented the first practical pairing-based group signature scheme (BBS scheme) using the SDH assumption [7]. Using selected security parameters, the specified scheme has approximately the same
123
336
level of security as a regular RSA signature of the same length. In spite of this supposed efficiency related to other schemes, there is high computational complexity with a combination of different kinds of mathematical computations. Sometimes the computational overload of group signatures has been considered so heavy to be used in portable devices in a real environment so as to ensure users’ privacy using some applications and services (like remote attestation [22,37,40], access to subscription services [21], e-cash [12,20,32] or automatic fare collection systems [24]). Contribution. In this paper, we present a complete software implementation of two group signature schemes: the BBS and the ACJT schemes. Armed with a successful implementation, we analyze the performance results taking into account both computing and storage measurements. Testing of our implementation has been performed on a conventional laptop and on two different smartphones equipped with the Android operating system [26]. We not only provide a simple comparison between these schemes, but also supply a valuable comparative analysis using different types of pairings to instantiate the BBS pairing-based group signature with a common level of security strength. As a result, we provide interesting insights about which pairings and security configurations are better to use by the BBS scheme, depending on the scenario in which they have to be applied. Therefore, we hope this paper helps to clarify the real computing workload due to the use of group signatures in secure applications and services, specially on those used on mobile devices, contributing to increase their use as a nice cryptographic primitive to give privacy to users. Organization. First, we give an overview about group signatures and some related works in Sect. 2. Section 3 explains how we have implemented these group signature schemes while in Sect. 4 we provide the performance measures and their analysis. Finally, we summarize the achieved results in Sects. 5 and 6 concludes the paper.
2 Group signatures: overview and previous works 2.1 Group signatures Finding authentication methods has been a central problem in cryptography. A great number of authentication protocols and cryptographic tools have been created to establish authenticated channels. The group signature schemes are a useful anonymous non-repudiable multiuse credential primitive that were introduced in [14] that can be used to provide authenticity and anonymity to signers at the same time. So, a group signature is a basic privacy mechanism. Bellare et al. [5,6] proposed a formal security model of group signature schemes defining the involved entities and
123
A. P. Isern-Deyà et al.
algorithms. Thus, three types of parties are considered: the group manager, the signer and the verifier. First, the group manager is the entity in charge of managing and deploying the parameters of the group signature scheme, generating keys (through the KeyGenG algorithm) and adding new members to the group ([6] formally introduces the interactive JoinG protocol to define the joining process). It can be also responsible of opening signatures and revealing the identity of the signer who had computed a group signature (OpenG algorithm). However, in the literature on group signatures [6], it is common to assume that the latter task is assumed by an opening manager different from the group manager. Secondly, the signer is a user who acquires a group key pair (therefore, she is a member of a group of users) and she uses the scheme to group sign a message of arbitrary length, hiding her identity within the group (calling to the SignG algorithm). Finally, the verifier is another user who belongs to (or does not belong to) the same group as the signer and he is in charge of verifying whether the signature is valid and made by a user belonging to the claimed group (the VerifyG algorithm covers this task). Among proposals found in the literature, we analyze and compare the performance of two well-known group signature schemes that follow completely different mathematical problems and complexity assumptions, to evaluate how is their efficiency when they are deployed under the same conditions on mobile devices. On one hand, the BBS scheme [8] is a pairing-based group signature whose security relies on the Strong Diffie-Hellman (SDH) and the Linear assumptions [7] in groups with a bilinear map, such as special groups from elliptic curves. On the other hand, the ACJT group signature [2] is the state-of-the-art non-pairing group signature proven secure under the Strong-RSA and the DDH assumptions in cyclic groups of prime order. We address the reader to the main references [2,8] to get more theoretical information about both schemes. 2.2 Group signature applications Some examples of group signature applications fall in the field of anonymous remote attestation [22,37,40]. In these applications, during attestation process to a remote party (e.g., a bank), the group signatures are sent to this party without showing the machine which it comes from. In [21] authors proposed a protocol for subscription services to achieve anonymity using a group signature. Some other papers [27,29] present public auctions’ schemes based on group signature systems where the privacy of bidders is protected. Other examples enhance users’ privacy even when the user is not a signer. For example, car drivers can hide in which country he or she obtained the drivers license if this document has a group signature. Regarding e-cash, some proposals [12,20,32] make use of group signatures to provide anonymity to the customers but allowing the revocation of
On the practicability of using group signatures on mobile devices
their anonymity if they misbehave. Isern et al. in [24] propose an automated fare collection scheme, which can be applied to transport services and parkings, where the group signatures are used to prevent the system from disclosing the identity of the users and from linking different journeys of the same user. The above examples illustrate the need for efficient group signature implementations to bring these proposals to the real world. Most of them do not present a complete performance evaluation due to the lack of group signature implementations, overtaking the associated overhead. This fact is even worse if practicability using commercial mobile devices has to be evaluated.
337
graphic primitives. However, Bouncy Castle does not provide support for pairing-based computation. PBC [31]. The pairing-based cryptography is a C library which implements mathematical methods related to elliptic curve generation, arithmetic and pairing computation. We use PBC to create elliptic curves for each pairing type. jPBC [16]. The Java pairing-based cryptography is a Java library that performs the mathematical operations underlying pairing-based cryptosystems. According to the source code and the documentation, jPBC uses the Tate pairing [17] to perform pairing computations. Thus, our BBS implementation rely on the Tate pairing. 3.1 Picking out a common security level
2.3 Previous group signature implementations There are few papers in the literature dealing with group signature implementation and performance evaluation and most of them offer results using smart cards. Canard et al. [11] present a performance evaluation of a group signature scheme in smart cards, but outsource complex computation to an untrusted powerful intermediary to release smart card from doing heavyweight computation. Apart from smart cards, Potzmader et al. [35] present an interesting efficiency comparison among three different group signatures on mobile devices. However, they do not evaluate performance depending on the type of pairing to fill the input to the group signature scheme. Similar practical experiences have been performed for constrained devices [1,39]. Spreitzer and Schmidt [39] try to fill the gap between theory and practice in resource-constrained environments. They use four different group signature schemes and evaluates their performance on a microcontroller. Vehicular communications is another field in which the group signatures can be used to obtain privacy. Agrawal [1] implements and compares different group signature schemes in terms of the overhead introduced due to processing cost, and analytically evaluates their suitability for vehicular communication scenarios.
3 Implementation of group signature schemes The code has been developed using the Java programming language due to its platform independence and because Java is the developing language in the Android platform. A number of libraries have been used along the development, among which we briefly point out the following: Java Bouncy Castle [13]. It is a very complete Java library that implements cryptographic algorithms and serves as a provider for the Java Cryptographic Extension (JCE) framework. Bouncy Castle library is useful to use it as a common framework, methodology and provider to use some crypto-
With the objective of comparing and analyzing the performance measures, we have to create a common security framework choosing a well-known and industrially accepted security strength. Guidelines published by NIST [34] are an excellent framework to know the minimum recommended security strength. According to NIST, the security strength of an algorithm with a particular key length is measured in bits and it is defined as the difficulty to discover the key being used [3, Section 1.2.1]. According to the last report released by the NIST [3] the minimum security strength currently considered secure for applications without strict secure storage requirements for a long time, such as most of the presented in Sect. 2.2, is 80 bits. This way, cryptographic algorithms relying their security on integer factorization (like RSA) can continue to use a module of 1,024 bits, while those based on elliptic curve and finite fields can use a subgroup of prime order of 160 bits. Opposed to that affirmations, other works [9] claim that this level of security would be enough until the end of 2020. At the time of writing this paper, the last and biggest known RSA modulus factorized is the RSA 768-bit size. The approximate time to factorize it was close to 200 years of computing on a single-core 2.2 GHz AMD Opteron [25]. Authors also stated that unless something dramatic happens in factoring, a factorization of 1,024-bit RSA modulus will not be possible at least until 2015. So, we support the performance analysis selecting appropriate parameters to meet a security strength of 80 bits of security. 3.2 Selecting pairing-friendly elliptic curves for the BBS group signature scheme Using the guidelines exposed in Sect. 3.1, we have to generate some pairing-friendly elliptic curves to be used for the BBS group signature computation. All of them have to be carefully selected to achieve the same security strength to properly compare performance results. At this point, it may be useful to bring a brief overview on elliptic curves [15,17]
123
338
and why pairing-based cryptosystems need pairing-friendly elliptic curves [19], but without going into detail about the underlying mathematics. 3.2.1 Elliptic curves overview Let q be a prime number, and with Fq we denote the finite field of integers’ modulo q (with q elements). An elliptic curve E over the finite field Fq , denoted as E/Fq , has its arithmetic in terms of the underlying finite field. Moreover, let E(Fq ) as the group of Fq -rational points of E and #E(Fq ) be the order of this group. Let Q be a point in E(Fq ) with prime order r ; then a cyclic subgroup of E(Fq ) generated by Q is denoted as: Q = {O, Q, 2Q, 3Q, ..., (r − 1)Q} where r is the number of elements in the subgroup. If Fq is a finite field and r |#E(Fq ) is relatively prime to q, then the embedding degree of E/Fq is the smallest integer k that r | (q k − 1). Sometimes, the embedding degree k is also referred as the security multiplier of the curve and it is in fact an important parameter of any elliptic curve. 3.2.2 Pairing-friendly elliptic curves for pairing-based cryptosystems Whereas standard elliptic curve cryptographic systems can be implemented using randomly generated elliptic curves, the elliptic curves needed by pairing-based systems, that are commonly called pairing-friendly elliptic curves, must have specific properties. Finding groups with a bilinear map, such as the most common Weil and Tate pairings, is a challenging task and an important research field in pairing-based cryptography [17]. Basically, the problem is to find elliptic curves with a small embedding degree and a large prime-order subgroup. Given an elliptic curve E/Fq , these pairings take as inputs points on E that are defined over Fq or over an extension field Fq k , and give as output an element belonging Fq×k . To be secure, a pairing-based cryptosystem must assure that the discrete logarithm problem in the group E(Fq ) and in the multiplicative group Fq×k are both computationally unfeasible. As a consequence, to achieve the same level of security in both groups, the size q k of the extension field must be significantly larger than r . So, the pairing-based cryptography is the use of a pairing function to map elements of two input groups (G1 , G2 ) to a third group (GT ) to construct cryptographic systems. If G1 and G2 are the same group, the pairing is called symmetric, otherwise it is called asymmetric. There are several pairing-friendly elliptic curves with different features to be used to perform pairing operations
123
A. P. Isern-Deyà et al.
[17,19,30]. Not all pairings are provided by PBC and jPBC pairing-based computation libraries, so based on [19,30] we have selected six elliptic curves to analyze the performance of the BBS group signature scheme. These elliptic curves receive different names depending on authors, thus we follow the nomenclature of [30]. Table 1 shows a comparison among selected pairing types. The pairing construction is a trade-off between security and complexity. On one hand, for security reasons, Fq must be large enough so that E(Fq ) can resist generic discrete logarithm attacks, while Fq k must be large enough to resist finite field discrete logarithm attacks. On the other hand, due to computation time and storage requirements, Fq and Fq k should be as small as possible. Thus, it is commonly accepted that the size of the input subgroup needs to be at least 160 bits long and more than 1,024 bits for the extension field. In addition, the order of E(Fq ) is currently acceptable to be at least 160-bit r , as pointed out in Sect. 3.1. 3.2.3 Selection of pairing-friendly elliptic curves To compare the BBS scheme performance using these six types of pairings, we need to define another common security level. Thus, taking as a starting point the theoretical values presented in the Table 1 and explained above, we have tried to compute six elliptic curves for each considered pairing type. Curves have been generated by the PBC library using as inputs the order of the subgroup (for A and F pairing types), the number of bits of q (for A and E pairing types) and finally the discriminant D (for D and G pairing types). Then, these curves have been submitted to an application developed using the jPBC library to collect both the order and the length of a random element (in bits) picked up from groups for each selected pairing type. Table 2 shows the results and also exposes the length of q and q k . The order of each group is around 160 bits, except for types A1 and G. Type A1 pairing uses a curve of composite order, but PBC library does not allow to control group order parameter. Without the ability to change it, the A1 pairing cannot be configured properly to accomplish the required input and output lengths. However, this type of pairing remains in the comparison because it accomplishes the requirements about q and q k , even though it is commonly known to consider composite orders’ results in significant performance degradation. Unfortunately, we cannot find any curve for type G pairing with a similar level of security as the other ones. We have tested more than 16.000 discriminants up to D = 1.000.000 that accomplish the condition D = 43, 67 mod 120, finding only one curve with q longer than 160 bits. However, this curve presents an order of 279 bits and q is 301-bit long, so it cannot be compared with the other curves. Note that the bit-length of each element randomly picked out from the corresponding group is always multiple of 8 and
On the practicability of using group signatures on mobile devices Table 1 Summary of elliptic curve parameters for each considered type of pairing to obtain a security strength equivalent to 80 bits
339
Type References Class
Embedding degree k
Minimum input Minimum subgroup size output log2 q (bits) extension field size log2 q k (bits)
Main features
A
–
Supersingular
2
512
1,024
Good trade-off between efficiency and storage
A1
–
Supersingular
2
512
1,024
More complex than type A due to composite order
D
[33,38]
Ordinary
6
171
1,026
Short group elements
E
[38]
Ordinary
1
1,024
1,024
Large group elements, easy computation
F
[4]
Ordinary
12
160
1,920
Short group elements, complex computation
G
[18]
Ordinary
10
160
1,600
Short group elements
Table 2 Group order and length of a random element within each group collected using the jPBC and curves generated by PBC (all in bits) Type
Order G1
Element length G2
Zr
GT
G1
Minimum size
G2
Zr
GT
In the input (log2 q)
In the output (log2 q k )
A
161
161
161
161
1, 040
1,040
168
1,040
513
1,025
A1
512
512
512
512
1, 040
1,040
512
1,040
520
1,040 1,048
D
161
161
161
161
352
1,056
168
1,056
175
E
161
161
161
161
2, 064
2,064
168
1,032
1,025
1,025
F
162
162
162
162
336
672
168
2,016
162
1,935
G
279
279
279
279
608
3,040
280
3,040
301
3,006
higher than theoretical values from Table 1. It is due to how jPBC works, because the library gives results in bytes. 3.3 Selecting parameters for the ACJT scheme ACJT group signature requires choosing several security parameters and lengths satisfying some conditions. The first parameter that should be defined is l p , which determines the composite modulus n. According to Sect. 3.1, if we want to obtain a security strength of 80 bits, we must compute a RSA modulus with 1,024 bits. Because of this, we should fill l p = 512 bits. Moreover, k is selected to be 160-bit long due to the fact we want to use the SHA-1 hash algorithm in the implementation. Note that each length specified by λ1 , λ2 , γ1 and γ2 has been selected ceiling the result to the nearest byte instead of strictly add one bit according to the
greater than condition. So, in some parameters, the considered value (third column from Table 3) could be greater than the theoretical minimum required by the ACJT specification (second column from Table 3). Along the software implementation task, we have found some challenging problems such as the search of a value for the second part of the membership certificate (ei ), defined R
as a random prime number within the range (ei ← ). According to the lengths defined before, ei should be a prime number of 9,224 bits. We have tried to find a prime number with this length using the OpenSSL library, but unfortunately without results after a very long time computation. As an alternative, we have decided to search for an already computed prime number whose length would be as near as possible to the aforementioned requirements. So, we have selected a primer number of 9,212 bits [36], which is very
123
340
A. P. Isern-Deyà et al.
4.2 Group manager computation analysis
Table 3 ACJT parameter selection Parameter
Theoretical minimum value (bits)
Considered value (bits)
2
Figure 1 shows the measured time to compute on the laptop a number of key pairs during the KeyGenG algorithm considering only the BBS scheme. Note that, since ACJT defines an interactive JoinG algorithm between the group manager and the candidate to become a group member, it does not compute all the user secret signing keys during the KeyGenG phase. Instead, ACJT creates a single secret signing key every time a user requests the JoinG . Analyzing Fig. 1, type D and type F pairings are the fastest pairings to complete the process. Instead, type E and A1 pairings are the slowest because the former only uses modular arithmetic and the latter uses elements that are larger than those provided by the other curves. It is also interesting to observe that as the size of the group increases (i.e., the number of user private keys to be built grows), the computational cost needed for type D and type F pairings to finish the algorithm is increasing slowly. Instead, it does not happens with other types of pairings in which the cost grows quickly. So, it is clear that from the point of view of computational cost in the server side (group manager), type D and type F pairings are the best choice in terms of scalability and performance, even this algorithm can be performed offline. Concerning the OpenG algorithm, Fig. 2 reflects the time needed to trace a signature to the corresponding signer considering both schemes. Type D is the best pairing obtaining roughly the same performance than type F pairing. However, ACJT seems to be a bit more efficient than BBS, but only around 2 ms faster on average.
2
lp
512
512
k
160
160
λ1
4,419
4,440
λ2
2,049
2,056
γ1
9,167
9,224
γ2
4,422
4,448
n
1,024
1,024
Table 4 Considered testing devices Device
CPU
RAM
OS
Laptop
2.4 GHz
4 GB
Debian Linux 6.0
HTC Desire
1 GHz
512 MB
Android 2.2 (API 8)
HTC Wildfire
528 MHz
512 MB
Android 2.3.5 (API 10)
close to the target length of 9,224 bits. It is a clear example of a kind of challenge that appears when theoretical algorithms should be implemented and brought to the practice. In this cases, developers should give engineering solutions as close as possible to the theory. 4 Discussion of performance results 4.1 Test scenario
4.3 Group member computation analysis
We consider two Android smartphones (HTC Desire and Wildfire) and a conventional laptop performing local computation, so we do not consider communications among them. Table 4 summarizes all features of these testing devices. To obtain average measures, we have repeated each test up to 100 times for each device. 36 32
With regard to the SignG and the VerifyG algorithms executed by a user, we analyze the performance of both considered schemes on the laptop and on two different smartphones, to see how the behavior of the implementation in different
A A1 D E F
31.80 27.49
28
Time (seconds)
25.49
24
22.24 19.22
20
16.97
16 12.94 11.68
12
8.18
8 4
6.65
6.39 4.22
2.23 0.73
0
6.20
100
0.56
1.28
200
1.06
1.83
300
1.57
2.39
2.09
2.93 1.02
400
Fig. 1 Performance results related to the BBS group manager who performs the KeyGenG algorithm on the laptop
123
500
2.60
On the practicability of using group signatures on mobile devices 160
Time (miliseconds)
A A1 D 140 E F ACJT
129.64
120
111.59
100 80 60 41.30
40 20 0
11.03
10.30
8.25
Open
Fig. 2 Time to trace a signature to the corresponding signer
hardware and operating systems is. Results are depicted in Fig. 3. Figure 3a exposes the results gathered using the testing laptop. Regarding the BBS scheme, type A and type D pairings are the best ones, beating the other types of pairings. Type D is slightly better for signing while type A is narrowly faster for verification. The other types of pairings have similar performance, excepting the type F for the verification process, which is slightly slower. Curiously, if we analyze the results obtained by the Desire (Fig. 3b) and the Wildfire (Fig. 3c), we can see that the results follow a different trend than those produced by tests performed on the Laptop. Type A pairing remains the best pairing type both for signing and verifying. Instead, type D pairing is affected by a lower performance, becoming this way one of the worst pairings, just ahead of type F pairing, which is proven not usable in a current smartphone device. If we compare the BBS scheme with the ACJT scheme, we observe two types of results depending on whether the schemes are tested on the laptop or on the smartphones. On one hand, BBS performance on the laptop is very similar to the performance obtained using the ACJT group signature. Actually, types A and D pairings seem to be faster than ACJT for signing and verifying. On the other hand, when tests are performed on the smartphones, it is clear that the BBS pairing-based group signature tends to be slower than the ACJT. This way, carefully analyzing the results presented in Fig. 3, we can prove that there are some operations that could be more difficult to compute by a smartphone, probably due to its architecture, i.e., CPU, memory access, operating system, etc. It implies that the performance of the BBS scheme falls down if it is used by a smartphone. We want to know whether or not it is possible to improve the performance, specially on the smartphones, applying
341
some kind of precomputation. Table 5 shows the number of operations that should be executed by the signing and the verifying algorithms, and how many of them can be precomputed by the signer and the verifier, respectively. In fact, in the case of the BBS scheme, during the SignG algorithm, most of the operations can be precomputed, allowing the signer to compute only 5 of 7 multiplications in Zr and one hash computation. Regarding ACJT, the signer has to compute no modular operations until he decides the message to group sign if precomputation is enabled. By contrast, during the VerifyG algorithm using the BBS scheme, only 3 of 5 pairing evaluations and 1 inverse in GT can be precomputed, and only 4 of 13 modular exponentiations in the case of the ACJT scheme. So the improvement is better during the signature generation rather than in the verification. Table 6 resumes the improvement that reports precomputation if it is enabled using both the laptop and the Desire (the same pattern applies to the Wildfire). The percentage of time that can be precomputed during SignG algorithm is almost the same in both devices, reaching up to the 99 %. Surprisingly, precomputable time during the VerifyG algorithm is higher on the smartphone than on the laptop (in general, it is a 20 % of improvement on the laptop and up to 60 % on the smartphone). So, the improvement on the performance due to the precomputation during the VerifyG algorithm on smartphones could be better than the benefit obtained on the laptop. If we take into account that only 3 of 5 pairings and one inverse in BBS are precomputed before to receive and verify the group signature, we can point out that one of these operations tends to be more difficult to execute by a mobile device. In fact, Fig. 4 reflects a selection of costlier operations used by the BBS scheme in each testing device: the exponentiation in G1 , the exponentiation in GT and the pairing evaluation. Then, pairing evaluation (especially for type F pairing) tends to be the most expensive operation on smartphones. Therefore, this is the reason why type F pairing is the worst pairing if it is tested on a smartphone. Since all pairing operations during the BBS signature generation can be precomputed and due to the fact that they are the most costly operations on smartphones, the percentage of improvement stands about of 99 %. Even though the improvement is surprising, we have to note that this is not free of charge, because precomputed values must be stored just after being computed. In the next section, we give some insights about the storage requirements of different elements from group signatures depending on the selected parameters. 4.4 Storage requirements analysis Related to the storage requirements, Table 7 summarizes the length of the elements generated by the BBS and the ACJT schemes, and the corresponding storage to be reserved for
123
342
A. P. Isern-Deyà et al. 1.2 A A1 D E F 0.8 ACJT
1.01
Time (seconds)
1
0.70
0.73
0.73
0.69
0.66
0.59
0.6 0.4 0.2
0.23
0.32
0.28
0.25
0.20
0 Sign
Verify
(a)
Results obtained through the laptop.
160 146.73
A A1 D E 120 F ACJT
Time (seconds)
140
100
92.35
80 60 40 25.17
20 0
4.47
12.84
16.53
15.16
8.18
2.90
9.17
5.21
Sign
1.74
Verify
(b)
Results obtained through HTC Desire.
900 A A1 D 700 E F 600 ACJT
797.78
Time (seconds)
800
517.09
500 400 300 200
149.38
100 0
23.32
66.17
100.37
79.69
35.32
12.43
27.52
Sign
41.72
7.02
Verify
(c)
Results obtained through HTC Wildfire.
Fig. 3 Performance results related to a user who performs the SignG and the VerifyG algorithms from BBS (using types A, A1, D, E and F pairings) and ACJT schemes
group members and group manager. Concerning the BBS scheme, using type F pairing, shorter elements are generated, so it could be the pairing type suitable for applications where the storage and the amount of data transferred are critical. Elements generated using type D pairings are also short and they are only a bit longer than type F elements. Instead, type E pairing generates longer signatures and keys, because elements from group G1 are six times longer than the same elements produced by the type D pairing. It is due to the very low embedding degree (k = 1) of type E curves. ACJT scheme, due to the fact it relies its security on the StrongRSA assumption, outputs longer signatures and keys than the BBS scheme. Considering the same security strength, a signature made by ACJT could be up to 20 times longer than
123
a signature generated by BBS using a type D pairing. This result is the evidence that a pairing-based group signature, such as the BBS scheme, could be better than a Strong-RSA group signature, as ACJT scheme, in terms of storage and bandwidth requirements. As pointed out in Sect. 4.3, precomputation also requires additional storage to save data before computing signatures and validating them. In line with signatures and keys’ storage, the bit-length of precomputed elements is also related to the selected pairing type as well as the required security strength. This way, before to compute a group signature by the BBS scheme, the signer has to precompute 9 elements from Zr , 7 elements from G1 and 1 more element from GT , while to validate this signature, the signer has to store 3 pre-
On the practicability of using group signatures on mobile devices Table 5 Number of precomputable operations along the signature and verification algorithms
Scheme
Operation
BBS
ACJT
Table 6 Percentage of improvement if precomputation is enabled during the signature generation and verification on both laptop and HTC Desire
Time (miliseconds)
200
Type
Signature Precomputable
%
Number
Precomputable
%
Random (Zr )
4
4
100
–
–
–
Multiplication (Zr )
7
2
28.6
–
–
–
Multiplication (G1 )
3
3
100
4
0
0
Exponentiation (G1 )
9
9
100
8
0
0
Inverse (G1 )
–
–
–
4
0
0
Multiplication (GT )
2
2
100
4
0
0
Exponentiation (GT )
3
3
100
4
0
0
Inverse (GT )
–
–
–
1
1
100
Pairing
3
3
100
5
3
60
Random
5
5
100
–
–
–
Modular multiplication
6
6
100
10
0
0
Modular exponentiation
12
12
100
13
4
30.8
Modular inverse
2
2
100
2
0
0
Modular additions
–
–
–
4
0
0
Computing time on laptop
Computing time on HTC Desire
Signing
Verification
Signing
% improved
ms
% improved
s
% improved
A
0.84
99.64
198.27
19.17
0.14
96.96
3.76
A1
0.62
99.91
609.43
16.52
0.13
98.99
10.97
58.02
D
0.29
99.85
166.43
43.50
0.05
99.70
14.14
64.03 57.24
1.31
99.80
547.74
24.52
0.39
95.45
6.85
99.94
551.55
45.10
0.15
99.84
73.92
66.50
ACJT
1.3
99.78
320
3.03
0.01
99.63
1.40
19.54
120
67
24000
67 48
43
A A1 D E F
23325
20000 16000 12000 8000
54
5776
40
3661
4000
23 6
5
(a)
58.08
0.42
195
Exponentiation (G1)
% improved
F
160
0
s
E
28000
68
Verification
ms
A A1 D E F
80
Verification
Number
Time (miliseconds)
240
343
2
6
18
14 1
Exponentiation (GT)
0
Pairing
294
945
148 585 144
Exponentiation (G1)
(b)
Results obtained through the laptop.
1283 65 219 5
Exponentiation (GT)
1487 557
768
Pairing
Results obtained through HTC Desire.
Fig. 4 Elapsed time to perform costlier pairing operations on testing devices
computed elements from GT . It means that the signer has to store 5,032 bits before signing in the best case scenario (type D pairing) and up to 16,992 bits in the worst case (type E
pairing). Instead, storage requirements to save precomputed elements before signature validation are less expensive. In the worst-case scenario, the signer has to store only 6,048 bits
123
344 Table 7 Storage requirements for users and group manager (all in bits)
A. P. Isern-Deyà et al.
Type
σ
gpk
gmsk
User
Group manager
A
4,128
6,240
1,208
336
7,448
1,208 ·n u + 6,576
A1
6,192
6,240
1,552
1,024
7,792
1,552 ·n u + 7,264
D
2,064
3,520
520
336
4,040
E
7,200
12,384
2,232
336
14,616
2,016
2,688
504
336
3,192
40,400
4,104
10,240
2,048
14, 344
F ACJT
(type F) while the other pairings have similar requirements of about 3,100 bits. With regard to the ACJT scheme, storage requirements are more strict, considering that the signer has to store more than 38,000 bits before signing and about 17,700 bits before signature validation.
5 Summarizing performance results Summarizing all performance results, we can conclude that from the point of view of the group manager scalability, the use of type F pairings would be preferable. It is because type F curves generate the shortest elements as well as it is also the fastest pairing producing all the required private keys for group members no matter the size of the group. However, since this process could be performed offline by the group manager (typically a powerful server), we should prioritize performance for users. Thus, for group members, it is better the usage of the type D pairing in case those members only use devices such as laptops, while the type A pairing is recommended if members also use smartphones. It is important to note that precomputation is mandatory to use efficiently the BBS group signature on mobile devices. If storage requirements are a bottleneck, type D pairing is the most suitable pairing since it generates only slightly larger elements than type F curves, so users are not affected so much. But the use of the type F pairing could be better to protect the system from improvements of discrete log attacks to the base fields, as pointed out in Sect. 3.2, due to its larger embedding degree (k = 12). However, currently it cannot be used by smartphones, as performance results prove. Finally, even ACJT computes and verifies signatures as fast as the BBS scheme, ACJT presents the also proved drawback that outputs longer elements than BBS.
6 Conclusions We have presented, to the best of our knowledge, the first successful implementation of the pairing-based BBS group signature scheme in mobile devices. The implementation allows us to provide many performance benchmarks obtaining a
123
gsk[i]
520 ·n u + 3,856 2,232 ·n u + 12,720 504 ·n u + 3,024 2,048 ·n u + 6,152
series of interesting results about the scheme. These results have been analyzed and compared with the implementation of the ACJT group signature, the state-of-the-art non-pairing group signature. The comparison has been conducted using a common security level of 80 bits. First, pairings A, D and F seem to be the most interesting options, but the choice among them depends on the requirements of the application and the existence of group members using the algorithm by means of mobile devices, such as smartphones. In addition, a good choice on the type of pairing and its underlying curve parameters could be fundamental to achieve a good performance, making the use of group signatures feasible in real scenarios and applications. Moreover, we prove by practice that the BBS scheme generates shorter elements than ACJT, as expected. Besides, we have also detected some interesting facts about which are the pairing operations with larger computational cost on mobile devices. Finally, we hope that our effort in implementing and giving performance results about these group signatures will be very useful for further works for all kinds of applications that use group signatures and, in general, to the cryptographic use of pairings on both computers and mobile devices. Acknowledgments This work was partially funded by the European Social Fund and the CONSOLIDER-ARES research project with reference CSD2007-00004.
References 1. Agrawal, V.: Performance evaluation of group signature schemes in vehicular communication: a feasibility study for vehicular communication. PhD thesis, KTH, Skolan för elektro- och systemteknik (EES), Kommunikationsnät (2012) 2. Ateniese, G., Camenisch, J., Joye, M., Tsudik, G.: A practical and provably secure coalition-resistant group signature scheme. In: Advances in Cryptology—CRYPTO 2000. Lecture Notes in Computer Science, vol. 1880, pp. 255–270. Springer, Berlin (2000) 3. Barker, E., Roginsky, A.: NIST Special Publication 800–131A. Transitions: recommendation for transitioning the use of cryptographic algorithms and key lengths. Technical report, U.S. Department of Commerce and National Institute of Standards and Technology (NIST) (2011) 4. Barreto, P., Naehrig, M.: Pairing-friendly elliptic curves of prime order. In: Selected Areas in Cryptography. Lecture Notes in Computer Science, vol. 3897, pp. 319–331. Springer, Berlin (2006)
On the practicability of using group signatures on mobile devices 5. Bellare, M., Micciancio, D., Warinschi, B.: Foundations of group signatures: formal definitions, simplified requirements, and a construction based on general assumptions. In: Advances in Cryptology—EUROCRYPT 2003. Lecture Notes in Computer Science, vol. 2656, pp. 644–644. Springer, Berlin (2003) 6. Bellare, M., Shi, H., Zhang, C.: Foundations of group signatures: the case of dynamic groups. In: Topics in Cryptology—CT-RSA 2005. Lecture Notes in Computer Science, vol. 3376, pp. 136–153. Springer, Berlin (2005) 7. Boneh, D., Boyen, X.: Short signatures without random oracles. In: Advances in Cryptology—EUROCRYPT 2004. Lecture Notes in Computer Science, vol. 3027, pp. 56–73. Springer, Berlin (2004) 8. Boneh, D., Boyen, X., Shacham, H.: Short group signatures. In: Advances in Cryptology—CRYPTO 2004. Lecture Notes in Computer Science, vol. 3152, pp. 227–242. Springer, Berlin (2004) 9. Bos, J.W., Kaihara, M.E., Kleinjung, T., Lenstra, A.K., Montgomery, P.L.: On the security of 1024-bit rsa and 160-bit elliptic curve cryptography. Cryptology ePrint Archive, Report 2009/389. http://eprint.iacr.org/ (2009) 10. Camenisch, J., Groth, J.: Group signatures: better efficiency and new theoretical aspects. In: Security in Communication Networks. Lecture Notes in Computer Science, vol. 3352, pp. 120–133. Springer, Berlin (2005) 11. Canard, S., Coisel, I., Meulenaer, G., Pereira, O.: Group signatures are suitable for constrained devices. In: Rhee, K.-H., Nyang, D. (eds.) Information Security and Cryptology—ICISC 2010. Lecture Notes in Computer Science, vol. 6829, pp. 133–150. Springer, Berlin (2011) 12. Canard, S., Traoré, J.: On fair e-cash systems based on group signature schemes. In: Information Security and Privacy. Lecture Notes in Computer Science, vol. 2727, pp. 237–248. Springer, Berlin (2003) 13. Bouncy Castle: Bouncy Castle Library. http://www.bouncycastle. org/java.html (2012) 14. Chaum, D., Van Heyst, E.: Group signatures. In: Proceedings of the 10th Annual International Conference on Theory and Application of Cryptographic Techniques, EUROCRYPT’91, pp. 257–265. Springer, Berlin (1991) 15. Cohen, H., Frey, G.: Hanbook of Elliptic and Hyperelliptic Curve Cryptography. Chapman & Hall/CRC, London/Boca Raton (2006) 16. Caro, Angelo de.: jPBC Library. http://gas.dia.unisa.it/projects/ jpbc/index.html (2012) 17. Dominguez Perez, L.J.: Developing an automatic generation tool for cryptographic pairing functions. PhD thesis, Dublin City University (2011) 18. Freeman, D.: Constructing pairing-friendly elliptic curves with embedding degree 10. In: Algorithmic Number Theory. Lecture Notes in Computer Science, vol. 4076, pp. 452–465. Springer, Berlin (2006) 19. Freeman, D., Scott, M., Teske, E.: A taxonomy of pairing-friendly elliptic curves. J. Cryptol. 23(2), 224–280 (2010) 20. Fuchsbauer, G., Pointcheval, D., Vergnaud, D.: Transferable constant-size fair e-cash. In: Cryptology and Network Security. Lecture Notes in Computer Science, vol. 5888, pp. 226–247. Springer, Berlin (2009) 21. Fujii, A., Ohtake, G., Hanaoka, G., Ogawa, K.: Anonymous authentication scheme for subscription services. In: Knowledge-Based Intelligent Information and Engineering Systems. Lecture Notes in Computer Science, vol. 4694, pp. 975–983. Springer, Berlin (2007) 22. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: a virtual machine-based platform for trusted computing. SIGOPS Oper. Syst. Rev. 37(5), 193–206 (2003)
345 23. Groth, J.: Fully anonymous group signatures without random oracles. In: Advances in Cryptology—ASIACRYPT 2007. Lecture Notes in Computer Science, vol. 4833, pp. 164–180. Springer, Berlin (2007) 24. Isern-Deyà, A.P., Vives-Guasch, A., Mut-Puigserver, M., PayerasCapellà, M., Castellà-Roca, J.: A secure automatic fare collection system for time-based or distance-based services with revocable anonymity for users. Comput. J. 56(10), 1198–1215 (2013). doi:10. 1093/comjnl/bxs033 25. Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé, E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., Arne Osvik, D., te Riele, H., Timofeev, A., Zimmermann, P.: Factorization of a 768-bit rsa modulus. Cryptology ePrint Archive, Report 2010/006. http:// eprint.iacr.org/ (2010) 26. Open Handset Alliance Led by Google Inc.: Android Operating System. http://www.android.com (2012) 27. Lee, C.-C., Ho, P.-F., Hwang, M.-S.: A secure e-auction scheme based on group signatures. Inf. Syst. Front. 11, 335–343 (2009) 28. Libert, B., Peters, T., Yung, M.: Scalable group signatures with revocation. In: Advances in Cryptology—EUROCRYPT 2012. Lecture Notes in Computer Science, vol. 7237, pp. 609–627. Springer, Berlin (2012) 29. Liu, X., Xu, Q.-L., Shang, J.-Q.: A public auction scheme based on group signature. In: Proceedings of the 3rd International Conference on Information Security, InfoSecu ’04, pp. 136–142. ACM (2004) 30. Lynn, B.: On the implementation of pairing-based cryptosystems. PhD thesis, Stanford University (2007) 31. Lynn, B.: PBC Library. http://crypto.stanford.edu/pbc/l (2012) 32. Maitland, G., Boyd, C.: Fair electronic cash based on a group signature scheme. In: Information and Communications Security. Lecture Notes in Computer Science, vol. 2229, pp. 461–465. Springer, Berlin (2001) 33. Miyaji, A., Nakabayashi, M., Takano, S.: New explicit conditions of elliptic curve traces for FR-reduction. In: IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences (2001) 34. NIST.: http://www.nist.gov/ (2013) 35. Potzmader, K., Winter, J., Hein, D., Hanser, C., Teufl, P., Chen, L.: Group signatures on mobile devices: practical experiences. In: ˇ Huth, M., Asokan, N., Capkun, S., Flechais, I., Coles-Kemp, L. (eds.) Trust and Trustworthy Computing. Lecture Notes in Computer Science, vol. 7904, pp. 47–64. Springer, Berlin (2013) 36. PrimB (49785): Prime number of 2774 decimal numbers. http:// primes.utm.edu/primes/page.php?id=65151 (2003) 37. Rong-wei, Y., Li-na, W., Xiao-yan, M., Bo, K.: A direct anonymous attestation protocol based on hierarchical group signature. In: International Conference on Computational Science and Engineering, 2009. CSE ’09, vol. 2, pp. 721–726 (2009) 38. Scott, M., Barreto, P.: Generating more MNT elliptic curves. Des. Codes Cryptogr. 38, 209–217 (2006) 39. Spreitzer, R., Schmidt, J.-M.: Group-signature schemes on constrained devices: the gap between theory and practice. In: Proceedings of the First Workshop on Cryptography and Security in Computing Systems, CS2 ’14, pp. 31–36. ACM (2014) 40. Wang, C.-H., Tsai, W.-Y.: An anonymous roaming protocol based on group signature without communication with home server. In: Proceedings of the Joint Workshop on Information Security (2009)
123
