Extracting Group Signatures from Traitor Tracing Schemes

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 T21 T5 T7 y T11 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)