1 / 34

Traceable Signatures

Traceable Signatures. Aggelos Kiayias University of Connecticut joint work with Moti Yung Yiannis Tsiounis Columbia University Etolian. Privacy advocates are vocal about loss of privacy in the electronic society. Authorities are worried about the

dillan
Download Presentation

Traceable Signatures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Traceable Signatures Aggelos Kiayias University of Connecticut joint work with Moti Yung Yiannis Tsiounis Columbia University Etolian

  2. Privacy advocates are vocal about loss of privacy in the electronic society. Authorities are worried about the potential abuse of anonymity systems. Theme:Balancing Privacy and Identification The state of things in multi-user environments: CRYPTO: can it be used to reconciliate the two sides?

  3. 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.

  4. 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 tracingmechanisms.

  5. 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 public-key. • Opening is an anonymity revocation mechanism. • Is it sufficient?

  6. 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.

  7. Distributed Verification Points Users Anonymity System Accumulation of transactions anonymously Users Users Users

  8. Input: This trans- action is suspicious!! OPEN! Distributed Verification Points Scenario #1: Suspicious Transactions Group Signature does exactly this!!!

  9. But…

  10. I WILL OPEN ALL OF THEM!!!!!!!!! INPUT: User X is engaging in illegal activity Distributed Verification Points NO!!!!!!!!!!!!!! Scenario #2: Suspicious USER

  11. 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.

  12. YOU HAVE BEEN NEGLECTING YOUR DUTIES!! Distributed Verification Points Scenario #3: Who owns your privacy? 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.

  13. 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.

  14. 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.

  15. 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.

  16. Traceable Signatures • Participants • Users. • Group Manager (responsible for group administration and tracing functions.

  17. Operations • 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

  18. Abstract Attack: Our Security Model Different subsets of queries classify possible attacks Interface Adversary Represents a perspective of the system In the real world Adversarial Goal.

  19. Queries Causes the interface to execute a JOIN dialog with the adversary, playing the role of the GM Returns the Public-key Returns the GM’s secret key Causes the Interface to Execute a JOIN dialog and return the transcript to the adversary Causes the interface to execute a JOIN dialog with the adversary, playing the role of a User Given <i,m> Interface returns returns a signature on m generated by the i-th user Given <i> interface returns the tracing trapdoor of i.

  20. The MISIDENTIFICATION attack Interface Adversary Represents the system Collectively: good users and GM • Forges a traceable signature that • EITHER • Does not open with the controlled group. • OR • Does not trace to at least one of the membersof the controlled group. Captures: Unforgeability, Coalition Resistance

  21. The FRAMING attack Interface Adversary Represents A handful Of good users In a hostile Environment. • 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. Captures: Exculpability

  22. The ANONYMITY attack The adversary operates in two stages. Reminiscent of a CCA2 attack on the “Reveal Function” Interface Represents The GM Adversary Selects two users i0 i1 (by name) Returns a Signature using One-of-the-two Membership secrets Guesses which of the Two users signed. Captures: Anonymity/ Unlinkability (even against tracing agents)

  23. 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.

  24. Discrete-Log Relation Sets over QR(n) Definition. Let G = QR(n) Objects A1, …, Am of G. Set of relations defined as tuples: Each tuple element is an integer or selected among a set of free-variables. Relation is defined based on each tuple: 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. 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.

  25. 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.

  26. Discrete-Log Representations of Arbitrary Powers A discrete-log representation of an arbitrary power inside G is a tuple over the base: That satisfies the condition 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.

  27. Our Construction: The Basic Setup • Basic Ideas: • GM’s public-key: n RSA-modulus, • Also : • Every user will possess a discrete-log representation of an arbitrary power inside QR(n). • Known to the GM except • User’s tracing trapdoor • Employ drawing random powers to implement the Join protocol where

  28. Anatomy of a Signature: the header For a signature or identification the following values are computed:T1, T2, T3, T4, T5, T6, T7 Opening Tracing ElGamal Encryption of A Claiming Commitment of x value Control Element Commitment to x value

  29. Anatomy of a Signature: the rest The user needs to prove in ZK that the header is well-formed. Employ discrete-log relation set. Signature: Fiat-Shamir Transform.

  30. 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.

  31. 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

  32. Claiming a Signature • Given a signatureT1, T2, T3, T4, T5, T6, T7 • the signer computes a claim certificate as a NIZK proof of knowledge of the discrete-logarithm of T6 base T7. • proof can be “designated verifier” to avoid claim adoption by the receiver.

  33. Security • Both interactive / non-interactive ROM Theorem. • Security against Misidentification (Strong-RSA,DDH) • Anonymity (DDH) • Security against Framing (DLog over a prime-order subgroup of QR(n)). • Random Oracle Model for the Signature Version.

  34. Conclusion • New Primitive: • Traceable Signatures and Identification. • Technical Tools: • 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)

More Related