Traceable Signatures Aggelos Kiayias University of Connecticut joint work with Moti Yung Columbia University Yiannis Tsiounis Etolian Theme: Balancing Privacy and Identification The state of things in multi-user environments: Privacy advocates are vocal about loss of privacy in the electronic society. Authorities are worried about the potential abuse of anonymity systems. CRYPTO: can it be used to reconciliate the two sides? Goals User’s actions must remain anonymous. Nevertheless a primitive must offer various mechanisms that allow the conditional revocation of anonymity. Methodology: develop primitives allowing various tradeoffs between privacy and identification. A basic building block for anonymity systems: signatures and identification In a transaction-based environment: Digital Signatures and Identification Mechanisms. Goal #1: Provide Privacy Goal #2: Develop a sufficient set of tracing mechanisms. Related Primitives Related primitives: Group Signature / Identity Escrow: a user can sign/ get identified “on behalf” of the group. The Group Manager can open a signature / id transcript. anonymity-unlinkability. Verification is performed using the group’s publickey. Opening is an anonymity revocation mechanism. Is it sufficient? Motivation Consider the following setting Underlying network infrastructure provides sufficient anonymity. Typical Abstract Large System: Many users Many remote verification points. Users issue (anonymous/group) signatures that get aggregated and verified in various points. Users Anonymity System Distributed Verification Points Users Users Users Accumulation of transactions anonymously Scenario #1: Suspicious Transactions OPEN ! Input: This transaction is suspicious!! Distributed Verification Points Group Signature does exactly this!!! But… Scenario #2: Suspicious USER I WILL OPEN ALL OF THEM !!!!!!!!! INPUT: User X is engaging in illegal activity Distributed Verification Points NO!!!!!!!!!!!!!! Shortcomings Signatures from remote verification points must be aggregated. Load Balancing Concerns Authority must open all signatures thus severely (and unnecessarily) violating the privacy of many users. Privacy Concerns Authority is typically a distributed entity so that opening requires the collaboration of many agents. Efficiency Concerns Outcome: group signatures insufficient for dealing with the above tracing request / anonymity revocation functionality. Scenario #3: Who owns your privacy? YOU HAVE BEEN NEGLEC TING YOUR DUTIES!! Distributed Verification Points NO! !` Privacy is a personally managed good…. (in many cases it is very important that) User should be able to prove that he did something if he wishes. Possible Approach User can prove in ZK that he knows the randomness of his signature. User needs to remember the randomness for all his signatures: unreasonable storage requirement. A stateless technique must be provided. Our Solution: Traceable Signatures Anonymous Signature Scheme. deal efficiently Scenario #1: opening a signature. (as in group signatures) Scenario #2: tracing all signatures of a named user (with load balancing). Scenario #3: allowing a user to claim a signature. Our Results Formal Security Model of the notion of Traceable Signatures. Efficient Construction of a secure Traceable Signature Scheme. Traceable Signatures : an extension of Group Signatures bonus: our construction provides a secure group signature in the sense of ACJT 2000. First construction that is provably secure on a formal model. Traceable Signatures Participants Users. Group Manager (responsible for group administration and tracing functions. Operations 1. 2. 3. 4. 5. 6. 7. 8. 9. Setup Join (interactive protocol) Sign Verify Open (given a signature reveals identity) Reveal (reveals the tracing trapdoor of user i) Trace (given a tracing trapdoor tests whether a given signature matches the trapdoor) Claim (to claim a signature by owner) Claim_Verify Our Security Model Abstract Attack: Adversary Q pub Qkey Q p join Different subsets of queries classify possible attacks Interface Qa join Qb join Qcorr Qsign Adversarial Goal. Qreveal Represents a perspective of the system In the real world Queries Q Returns the pub Public-key Qkey Q Q Returns the GM’s secret key Causes the p join Interface to Execute a JOIN dialog and return the transcript to the adversary Qsign Causes the a join interface to execute a JOIN dialog with the adversary, playing the role of the GM the Qb join Causes interface to Given <i,m> Interface returns returns a signature on m generated by the i-th user execute a JOIN dialog with the adversary, playing the role of a User Qreveal Given <i> interface returns the tracing trapdoor of i. The MISIDENTIFICATION attack Adversary Q pub Q p join Interface Qa join Qsign Qreveal Forges a traceable signature that EITHER •Does not open with the controlled group. OR •Does not trace to at least one of the members of the controlled group. Represents the system Collectively: good users and GM Captures: Unforgeability, Coalition Resistance The FRAMING attack Adversary Q pub Interface Qkey Qb join Qsign Forges a traceable signature that EITHER •Does open to one of the good users. OR •Does trace to at least one of the good users. Represents A handful Of good users In a hostile Environment. Captures: Exculpability The ANONYMITY attack The adversary operates in two stages. Reminiscent of a CCA2 attack on the “Reveal Function” Q pub Q p join Adversary Interface Represents The GM Qa join Qsign Qreveal Selects two users i0 i1 (by name) Guesses which of the Two users signed. {i 0 ,i1 } Q p join Qa join Qsign Qreveal Returns a Signature using One-of-the-two Membership secrets Captures: Anonymity/ Unlinkability (even against tracing agents) Basic Tools Basic tools need to be developed and investigated: Discrete-Log Relation Sets : A useful notational tool for planning complex ZK proofs over groups of unknown order. Drawing Random Powers : how to select a random power in QR(n) in an ideal fashion. Discrete-Log Relation Sets over QR(n) Definition. Let G = QR(n) Objects A1, …, Am of G. i i i a , a ,..., a Set of relations defined as tuples: 1 2 m Each tuple element is an integer or selected among a set a ij of free-variables. Ai 1 a Relation is defined based on each tuple: j 1... m Each free variable assumed to belong to a specified integer interval. Discrete-log relation set is the logical-and of all relations PLUS the interval relations. i 2 Theorem. For a given discrete-log relation set there exists a 3-move ZK proof that allows proving the knowledge of a witness-tuple for the free variables. Drawing Random Powers Two-player Game. Ideal Implementation: Player A transmits request to TTP. TTP responds with a random x. Player A responds with C=ax TTP checks that C=ax TTP gives to player B the value C There exists an efficient implementation of the above game over QR(n) when x is selected from a specified integer range. Discrete-Log Representations of Arbitrary Powers A discrete-log representation of an arbitrary power inside G is a tuple A, e : x, x' over the base: a0 , a, b QR (n) That satisfies the condition Ae a0 a xb x ' Theorem. Strong-RSA => Any adversary that is given K discrete-log representations of arbitrary powers can find a new (different) discrete-log representation of arbitrary power only with negligible probability of success. Our Construction: The Basic Setup Basic Ideas: GM’s public-key: n RSA-modulus, a0 , a, b QR (n) Also : g , h QR (n) Every user will possess a discrete-log representation of an arbitrary power inside QR(n). Ai , ei : xi , xi ' where A a0 a b e x x' Known to the GM except xi ' User’s tracing trapdoor xi Employ drawing random powers to implement the Join protocol Anatomy of a Signature: the header For a signature or identification the following values are computed: T1 Ai y , T2 g , T3 g h w ei w T4 g , T5 g , T6 g xi k k xi 'k ' w , T7 g k' Opening Tracing T1, T2, T3, T4, T5, T6, T7 ElGamal Encryption of A Commitment Control Commitment of x value Element to x value Claiming Anatomy of a Signature: the rest The user needs to prove in ZK that the header is well-formed. Employ discrete-log relation set. . g h T21 T5 T7 y T11 a b a0 T3 T4 T6 T2 g w w 0 1 0 0 0 0 0 0 0 0 0 T3 g e h w e w 0 0 0 0 0 0 0 0 1 0 0 T2e g h ' h' 0 e 0 0 0 0 0 0 0 0 0 0 T5x T4 0 0 0 x 0 0 0 0 0 0 0 1 0 T7x ' T6 0 0 0 0 x' 0 0 0 0 0 0 0 1 a0 a xb x ' y h ' T1e 0 0 0 0 0 h' e x x' 1 0 0 0 Signature: Fiat-Shamir Transform. 0 Opening a Signature. Given a signature, T1, T2, T3, T4, T5, T6, T7 The GM employs his ElGamal secret-key to recover A from T1, T2. recall: A is part of the certificate of a user. A is matched to some Join protocol transcript signer is identified. Tracing a user Reveal: Given the identity of a certain user. The GM obtains his Join protocol transcript and recovers the user’s tracing trapdoor x. Trace: given x and a signature T1, T2, T3, T4, T5, T6, T7 we return T4 =? T5x Claiming a Signature Given a signature T1, T2, T3, T4, T5, T6, T7 the signer computes a claim certificate as a NIZK proof of knowledge of the discretelogarithm of T6 base T7. proof can be “designated verifier” to avoid claim adoption by the receiver. Security Both interactive / non-interactive ROM Theorem. Security against Misidentification (StrongRSA,DDH) Anonymity (DDH) Security against Framing (DLog over a prime-order subgroup of QR(n)). Random Oracle Model for the Signature Version. Conclusion New Primitive: Technical Tools: Traceable Signatures and Identification. Discrete-Log Relation Set Notation and ZK-proofs. Drawing Random Powers. Formal Model + Security Proof: subsumes Group Signatures. Main Applications: Traceable Identification and Signing. Fair anonymity in large systems. Traceability can be used directly to implement CRL-based member revocation coupled with the “Camenisch-Lysyaskanya revocation” it is possible to capture both types of revocation: forward (CL) and backwards (CRL)
© Copyright 2024 Paperzz