Traceable Signatures

1
Traceable Signatures

• Aggelos Kiayias
• University of Connecticut
• joint work with
• Moti Yung Yiannis Tsiounis
• Columbia University Etolian

2
ThemeBalancing Privacy and Identification

• The state of things in multi-user environments

CRYPTO can it be used to reconciliate the two
sides?
3
Goals

• Users 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 tracing
  mechanisms.

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 groups
  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
Anonymity System
Users
Accumulation of transactions anonymously
Users
Users
Users
8
Scenario 1 Suspicious Transactions
Group Signature does exactly this!!!
9
But
10
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
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
Our Security Model
Different subsets of queries classify possible
attacks

• Abstract Attack

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 GMs 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 lti,mgt Interface returns returns a signature
on m generated by the i-th user
Given ltigt 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 Membersh
ip 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 Cax
• TTP checks that Cax
• 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 gt 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
• GMs 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
• Users 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 computedT1, 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 users tracing trapdoor x.
• Tracegiven x and a signature T1, T2, T3, T4,
  T5, T6, T7 we return T4 ? T5x

32
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 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)