* Based mainly on a chapter on group signatures by Gene Tsudik, David Chaum s original paper on group signatures, Jan Camenisch s PhD Thesis and Mihir Bellare s papers on foundations of group signatures. See reference slide in the end for more details. Karim El Defrawy keldefra@uci.edu Donald Bren School of Information and Computer Science University of California, Irvine
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
Fundamental feature: Escrowed (or Conditional) Anonymity. Definition: Any member of an arbitrary sized group can sign a message either to assert its membership or to act on behalf of the group. Introduced in 1991 by Chaum and Van Heyst. A lot of schemes varying in assumptions, characteristics and performance developed.
Corporate/Government/Military Communication: Multiple individuals authorized to issue authenticated information to be released in the public, but identity of issuing individual must remain secret. Electronic Prescriptions: Physicians form a large and dynamic group issuing electronic prescriptions using group signatures. Network Anycast: Multiple servers sending authenticated replies to client requests, while remaining anonymous.
E-Cash: Each issuing bank can be treated as a group member and signs the issued cash anonymously (to prevent prejudicial treatment). E-Voting: A voter is a group member with signing ability. Identity of voter must remain secret, unless investigation is needed*. * A caveat is that we need to verify that each vote is unique, which is not usually offered by GSig schemes and requires some tweaking (self distinction).
Anonymous Attestation: GSig used as a building block for anonymous attestation systems. Secret Handshakes: Protocols allowing members of the same group to attain mutual authentication in an untraceable and unobservable manner (privacy preserving authentication). Identity Escrow: Interactive dual of GSig. Almost any GSig scheme can be turned into an identity escrow scheme by replacing the message to be signed with a challenge.
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
Multisignatures Threshold Signatures Proxy Signatures Ring Signatures Identity Escrow Schemes
Also group signatures, but in a different sense A multisignature represents a certain number of signers signing a given message. Number of signers is not fixed and signers identities are evident from a given multi-signature. A multisignature is much shorter (sometimes constant) than the simple collection of individual signatures. Example: Okamoto, T. 1988. A digital multisignature scheme using bijective public-key cryptosystems. ACM Trans. Comput. Syst. 6, 4 (Nov. 1988), 432-441.
Involve a fixed-size quorum (threshold) of signers. Each signer must be a genuine group member with a share of a group secret signing key. A (t,n) threshold signature scheme supports n potential signers, any t of which can on behalf of the group. Threshold signatures reveal nothing about the t signers; no one can trace the identity of the signers (not even a trusted center who have set up the system). Example: Desmedt, Y. 1988. Society and Group Oriented Cryptography: A New Concept. In A Conference on the theory and Applications of Cryptographic Techniques on Advances in Cryptology (August 16-20, 1987).
Essentially delegated signatures Allow a delegator to give partial signing rights to other parties called proxy signers. Do not offer Anonymity Example: Mambo, M., Usuda, K., and Okamoto, E. 1996. Proxy signatures for delegating signing operation. In Proceedings of the 3rd ACM Conference on Computer and Communications Security (New Delhi, India, March 14-15, 1996). CCS '96.
Closest concept to GSig Involved ad hoc groups with no central authority (such as group ( manager Signers cannot be identified A valid ring signature can be verified as being produced by a specific group of potential signers with no hint as to the actual signer. Example: Rivest, R. L., Shamir, A., and Tauman, Y. 2001. How to Leak a Secret. In Proceedings of the 7th international Conference on the theory and Application of Cryptology and information Security: Advances in Cryptology (December 09-13, 2001).
Interactive dual of group signatures Instead of off-line generation, a signature is directly generated by a signer based on a challenge provided by the verifier. Example: Kilian, J. and Petrank, E. 1998. Identity Escrow. In Proceedings of the 18th Annual international Cryptology Conference on Advances in Cryptology (August 23-27, 1998).
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
Group Manager (GM): entity responsible for administering the group. Has private key (skgm) and the group public key (pkgm). Group Members: users/entities that represent the current set of authorized signers. Each has a public/private key pair (pkui,skui) and the group public key (pkgm). Outsiders: any other user/entity external to group. Has group public key (pkgm).. 5/25/2009 15
Groups can be: Static: formed with pre-determined fixed membership (e.g., conference, short term events) Growing: membership that can grow (e.g. in environments where revocation is rare) Shrinking: formed with pre-determined members and can only shrink over time (e.g. WSN) Elastic: membership can grow and shrink.
Group members must have a long-term persistent identity, e.g.: Hostanme Network address Email account X.500 name Member long term identity must be unique and strongly associated with a long-term public key (i.e. PKI is assumed) There must exist a secure (provable/verifiable) binding between a long-term identity and a unique group identity (alias) In practice a binding may be represented by an agreement between the member and a GM (signed by both) that includes the group parameters, a long-term identity and a group identity.
No notion of time in static groups In a growing group, a member should not produce signatures predating its membership. If this is required or not depends on many factors: The need for signature causality The availability for a secure time stamping service If members are trusted to evolve their keys, forward security is an option.
In a shrinking group a revoked former member must be prevented from producing a valid signature. Clearly impossible without a revocation mechanism In elastic groups, both issues come up.
SETUP: an algorithm run by GM: input: security parameter k output: cryptographic specification of group, GM public (pkgm) and private keys (skgm) JOIN: a protocol between GM and user resulting in user becoming a member (Ui) and having a public/private key (pkui,skui). SIGN: an algorithm executed by a group member: input: message (m), group public key (pkgm), member public/private key (pkui,skui) output: GSIG= δ of m 5/25/2009 20
VERIFY: an algorithm run by anyone: input: message (m), GSIG (δ), group public key (pkgm) output: binary flag indicating validity of GSIG OPEN: an algorithm run by the GM: input: message (m), GSIG (δ), group public key (pkgm), GM secret key (skgm) output: validity of signature, identity of signer (pku), a proof that allows anyone to verify identity of signer REVOKE: an algorithm run by GM to remove/revoke a user from the group (some schemes don t have it). 5/25/2009 21
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
Early schemes suffered from: Linear complexity of group public key size Linear complexity of group signature size GM has to interact with each member to OPEN a signature Inability to add new members Miss-attribution of group signatures by GM
Correctness: Any signature produced by a group member using SIGN must be accepted using VERIFY. Any signature produced by a group member using SIGN can be used as input to OPEN to yield the identity of the signer. Signature Compactness: Signature size must be at most logarithmic in terms of maximal size of the group. Public Key Compactness: Group public key size must be at most logarithmic in terms of maximal size of the group.
Anonymity: Given a valid GSig, identifying the actual signer is computationally hard (except for the GM). Unlinkability: Deciding whether two GSig were (or were not) computed by the same group member is computationally hard (except for the GM). Unforgeability: Only group members are able to sign on behalf of the group.
Traceability: Any valid (verifiable) GSig produced by a group member can be de-anonymized (via OPEN) by the GM to produce the identity of that same member (signer). No-Framing: A coalition of group members cannot produce GSig on behalf of any other group member (who is not in the coalition). Exculpability: No coalition of malicious members (potentially including GM) can produce signatures on behalf of other group members. Coalition-resistance: No colluding subset of members (even the entire group) can generate a valid Gsig that GM cannot link to one of the colluding group members.
Unlinkability Anonymity Exculpability No Framing Traceability Unforgeability Coalition-Resistance
Security properties untangled by Bellare et. al. and consolidated in two (Bellare 05): Full-traceability: No subset of colluding members (even the entire group and GM) can create valid GSig that cannot be opened, or cannot be traced back to some member of the coalition. Full-anonymity: It is computationally infeasible for an adversary (without the GM s secret key) to recover the identity of the signer from a valid GSig, even if it has access to the secret keys of all group members. In addition Ateniese et. al. added (Ateniese 99): No-misattribution: It is computationally infeasible for a GM to provably attribute a GSig to a member who is not the actual signer.
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
p: prime, g: generator of Zp, a: secret exponent, A = g a mod p. public key=p,g,a, secret key=a, h: {0,1}* -> {1,2,.., p-1} hash function M: message in {0,1}* Signing: (1) Generate a random number k in {1,2,..,p-2} (2) r = g k mod p, s = k -1 (h(m) ar) mod p-1). (3) Signature is: (r,s) Verification:(1) Check 0 < r < p (2) Check A r r s = g h(m) mod p. Correctness of the verification: A r r s = g ar g kk-1 (h(m)-ar) = g h(m) mod p
p: prime, g: generator of Zp, a: secret exponent, A = g a mod p. public key=p,g,a, secret key=a, h: {0,1}* -> {1,2,.., p-1} hash function M: message in {0,1}* Signing: (1) Generate a random number k in {1,2,..,p-2} (2) r = g k mod p, e=h(m r), s = (k-a*e ) mod p (3) Signature is: (e,s) Verification: Check if h(m A e g s ) =? e e=h(m r)=h(m g k mod p) Correctness of the verification: A e g s = g a*e g (k-a*e) = g k mod p
Let's all share a secret Generate a public/private key for the whole group (g x,x). All members share the same key. JOIN: GM sends x to Ui SIGN: Ui generates a GSig by signing a message via any discrete-log signature scheme and secret x. VERIFY: Verification using the procedure of the discrete-log based signature scheme with public key g x. ( accountability OPEN:???? (no
Anonymous (but linear) public key GM generates n key pairs (pk i,sk i ), one for each member. The list of public keys (pk 1,pk 2,...pk n ) is then published as the group public key. Ui signs a message using his private key (sk i ) which can be verified using (pk i ), which is part of the group public key.
JOIN: GM sends (pk i,sk i ) to group member Ui, who replies with a signed statement that (pk i,sk i ) is part of his group membership. SIGN: Ui generates a group signature by signing a message with the secret sk i. VERIFY: Apply verification procedure of the signature scheme with public key pk i OPEN: GM reveals statement signed by Ui during the JOIN process.
Drawbacks: 1. Group public key is linear in group size 2. Each member can sign once only (otherwise ( linked signatures under same key will be 3. GM knows all signing secrets and could frame any ( behalf member (i.e. produce a signature on his
GSig with blinded public keys (Chaum 91) To avoid framing have to allow Ui to generate their own secret key. Let g be a generator of Z * p for a large prime p. Ui generates a secret key (pk i =g ski modp,sk ) i and sends pk i to the GM The group public key is the authenticated list {g sk1,...,g skn } As long as sk i is secret GM can not frame any user
JOIN: Ui sends (pk i =g ski modp, sk i ) to group member Ui alongside a signed statement that (pk i ) is part of his group membership. GM verifies the statement and ads pk i to group public key. SIGN: Ui generates a group signature by signing a message with the secret sk i (e.g., DSA). VERIFY: Apply verification procedure of the signature scheme with public key pk i OPEN: GM reveals statement signed by Ui during the JOIN process.
Multiple signature by Ui can be linked, so (pk i =g ski modp,sk i ) should be randomized by an r i produced by GM to be: (pk i =g ski*ri modp,sk i *r i ) Drawback: A new r i has to be provided by GM each time Ui wants to sign. An option is to consider weaker unlinkability and allow signatures to be linkable for a short period of time (until a new r i is obtained from GM)
GSig with an accumulator (Chaum 91) RSA ring with N=p*q Define as the interval [ N,...2 N 1] Let f(.) be a one-way function GM provides Ui with a secret prime si and publishes ( N, v s i ) as the group public key v can be seen as an accumulator since it combines all the secrets
c Prover s (P) secret: * Public: N, x, y, ; x, y N, {,..., } c Prove to Verifier (V): x y(mod N) c r 1. P chooses r {0,..., } and computes commitments on z1 x mod N and r z2 x mod N, sends the unordered pair { C( z1), C( z2)} to V 2. V chooses randomly b{0,1} and sends it to P 3. P sends to V the following in these cases: b=0: r and opens both commitments b=1: rmod ( c r) or rmod ( c r ) whichever is in the set Ω, and opens respectively the commitment on z1 or z2 (called z*) 4. V verifies the following in the following cases: b=0: that r {0,..., } and the commitments are for z and z 1 2 b=1: that mod and that one of the commitments is for z* and r that it satisfies x mod * z y
If protocol iterated k times, V will be convinced (with probability 1 2 k ) that, but V will receive no knowledge other than that fact If c then the distribution of mod will be uniform over Ω and thus independent of c. Thus V can simulate the whole protocol without interacting with P hence ZK. r c {,..., }
s T m mod N V wants to prove to P that s divides v. 1. V chooses random r{1,..., N} and sends a to V / 2. P calculates b a vs and commits to b by sending Commit(b) to V 3. V sends r to P and P verifies that it is the right r 4. P opens Commit(b) (decommits b) and V v/ s rv/ s svr / s vr verifies the opening that b a T m m T r
Ui signs a message (m) by releasing Three proofs are also released with S: s i 1. That the exponent is known 2. That si 3. That s divides v i s S f ( m) i mod N All proofs are done in ZK and ensure that only group members can sign on behalf of the group. No opening phase originally. Members can disprove that the signature was NOT produced by them (disavowal).
JOIN: GM sends a unique secret prime s to Ui. i SIGN: Ui generates a group signature on a message m s by releasing S f ( m) i mod N and a proof that is known, that it resides in and that it divides v without revealing itself. s i VERIFY: Verify the proofs generated at signing. OPEN: Open a signature S by finding the such that s S f ( m) i mod N.* * There is no OPEN phase in original proposed scheme, only a disavowal procedure. s i
GSig with the subset approach (Chaum 91) A group member (Ui ) selects and releases a subset of group members (public keys), which includes himself, along with a signature on the message. Ui also releases a proof that the secret used to compute the signature corresponds to one of the public keys in without revealing which one. No OPEN phase, each member has to prove that a certain group signature was not produced under his own secret.
Given ( g, h1, h2,..., h n ) where g is a generator of a x prime-order (q) group and h i i g for1 i n, a prover (P ) can show to a verifier (V ) that it knows at least one of the x i without revealing which one.
* 1. P chooses si, di q at random for i=1,2,n and s1 si di j=2,3,n. P computes a1 g, ai g h i for i=2,3, n and sends to V.* (,,..., ) a1 a2 a n * 2. V chooses a challenge c q at random and sends it to V. 3. P first computes d1 c d i and then 2 and sends ( d,..., d, r,..., r ) to the V. 1 n 1 4. V verifies that di c and that i1 for i=1,2,,n. n n s x d 1 1 1, i 1 n ri di g aihi * Assuming that P s secret is x1 r i s,2i n i
GSig with the double signing technique (Chen 94) Relies on proof of knowledge of one out of many witnesses The group public key is set to the list: h... 1 hn x where h i i g Ui uses its own secret x i to sign a message then proves that the secret corresponds to one of h... 1 hn To OPEN GM needs to know all secrets, so framing will be possible.
Double signing used to prevent framing GM has two public keys and each Ui has two signing secret keys, only one of which is shared with GM. GSig is generated by releasing two signatures, each corresponding to one of the two group public keys of Ui. GM can t frame because he only knows one key, but can identify the memebr in OPEN. Caveat: GM can still lie when opening a signature, not proof that GM performed OPEN correctly.
JOIN: GM keeps two lists of public keys: L1, L2. L1 has public keys with respect to base g and L2 with respect to x base h. Ui generates two public keys: 1 x2 ( g, h ) and sends them to GM along with secret x2. GM ads them to L1 and L2 and releases a signed statement attesting that Ui is associated to both public keys. SIGN: Ui generates a group signature by constructing a proof that it knows two secrets which correspond to a public key in L1 and in L2 respectively. VERIFY: Verify the proof generated at signing. OPEN: GM knows x2, it can pinpoint the public key in L2 used for the proof generated at signing.
GSig with encryption first (Camenisch 98) First GSig with a verifiable OPEN (GM provides evidence of correct OPEN) GM has public key: z ( g, y g ) Group public key is a list of public keys of the group members under a certain base, i.e., ( ) g 1 2 ( g, h, h,..., h n ) x Ui (with public key h i i g ) encrypts it using ElGamal (i.e. generate random k and releases (A,B) such that k k A h y, B g ) i
Ui signs a message by proving that it knows the DL of the encryption public key with respect to base g and that such a key is in the list: ( h1, h2,..., h n ) (via a similar proof like the Chen Pederson scheme) GM recovers hi by decrypting (A,B) GM proves that OPEN was correct by proving equality of the DL in (A/hi) and B with respect to bases y and g
JOIN: GM keeps a list L of public keys. Ui generates its x public key h i i g and sends it to GM which ads it to L. GM releases a signed statement attesting the Ui is associated to the public key hi. SIGN: Ui generates a GSig by releasing an Elgamal encryption (A,B), of hi under the GM public key and providing the proofs: That Ui knows the DL of hi with respect to g That Ui correctly encrypted one of the public keys in L VERIFY: Verify the proofs generated at signing. OPEN: GM verifies the GSig and decrypts the encryption (A,B) to reveal hi. GM then generates a proof of equality of the DL in (A/hi) and (B ) with respect to bases (y) and (g)
Short Gsig based on bilinear maps (BBS04) Very short signatures < 200 bytes (order of magnitude shorter than previous schemes) Based on discrete-log-type assumptions Security relies on: the (SDH) Strong Diffie-Hellman assumption and a new assumption in bilinear groups called the Decision Linear assumption
Bilinear map: G1, G2, GT are cyclic groups of order prime p that admit a bilinear map*. We say a map e: G is a bilinear map if: 1G2 GT 1. G1, G2, GT are multiplicative cyclic groups of the same prime order p 2. For all a, bz then q, g1 G1, g2 G e( g 2 1, g2 ) e( g1, g2) is efficiently computable 3. The map is non-degenerate (i.e., if g 1 generates and g 2 generates G 2 then e( g1, g2) generates G T ) 4. There exists a computable isomorphism from to G 2 a b ab *Elements in 1and G have very short representations (e.g., 171 bits) hence the short signatures G 2 G 1 G 1
( g1, g2, h, u, v, w) and are generators of and The group key is h g1 2 g G1 2 where: is generated randomly in and ( uv, ) are such that e 1 e2 u v h for randomly generated e1, e2 Zq G 1 G w g y 2 for a randomly generated yz q the secret key ( sk GM ) of the GM is: sk ( e, e, y) GM 1 2
JOIN: GM sends to U i a pair: ( Ai, xi) where for randomly chosen by GM in x i Z q Ai g 1/( yx i ) 1 SIGN: generates a group signature on a message m by generating random, q and releasing T1 u, T2 v, T3 Ah i along with a signature of knowledge on m that U knows i ( Ai, xi) such that: 1. A in is correctly encrypted under GM s public key i T 3 2. x e( A, wg i ) e( g, g ) U i i 2 1 2 VERIFY: Verify the signature of knowledge. OPEN: GM decrypts as i e A 1 e2 A T / ( T T ) i 3 1 2
This is the basic scheme which does not provide exculpability (GM knows the secret xi and can thus impersonate Ui ) OPEN is not verifiable (i.e. no-misattribution is not offered) so GM can lie during opening and falsly accuse a member. Basic scheme can be easily extended to prevent this as shown in the paper.
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
Most GSig schemes don t have the self distinction capability. Efficient schemes with self distinction needed. Only one (due to Camenisch) threshold GSig scheme, where t out of the n members need to collaborate to generate a signature. Even t-1 members can not generate a signature.
Aggregation of GSig is not possible at this point Efficient member deletion/revocation needed Limited experience with GSig on constrained devices (e.g. WSN and Smartcards)
Introduction Related Concepts Group Signatures (GSig) in Details Basic Elements of GSig Properties of GSig Relevant GSig Schemes New Trends and Issues in GSig Conclusion
GSigs are a powerful tool in designing privacy preserving protocols and applications Several schemes with different characteristics and assumptions Need to know what we want to choose the right scheme Some open issues and problems in the schemes are still to be solved
Bellare 05: M. Bellare, H. Shi and C. Zhang. Foundations of Group Signatures: The Case of Dynamic Groups. Topics in Cryptology - CT-RSA 2005 Proceedings, Lecture Notes in Computer Science Vol. 3376, A. Menezes ed, Springer-Verlag, 2005. Ateniese 99: Ateniese, G. and Tsudik, G. 1999. Some Open Issues and New Directions in Group Signatures. In Proceedings of the Third international Conference on Financial Cryptography M. K. Franklin, Ed. Lecture Notes In Computer Science, vol. 1648. Springer-Verlag, London, 196-211. Chaum 91: D. Chaum & E van Heyst, "Group Signatures," Advances in CryptologyEUROCRYPT '91, D.W. Davies (Ed.), Springer-Verlag, pp. 257-265. Chen 94: L.Chen, T.Pedersen, New Group Signature Schemes, Lecture Notes in Computer Science 950, Advances in Cryptology: Proc. Eurocrypt'94, Springer, (1995), pp. 163 173. Camenisch 98: Jan Camenisch, Group Signature Schemes and Payment Systems Based on the Discrete Logarithm Problem. 174 pages, Vol. 2 of ETH-Series in Information Security an Cryptography, ISBN 3-89649-286-1, Hartung-Gorre Verlag, Konstanz, 1998. BBS 04: D. Boneh, X. Boyen, H. Schacham, Short Group Signatures, In proceedings of Crypto '04, LNCS 3152, pp. 41-55, 2004