1. Foundations of Fully Dynamic Group Signatures
Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi and Jens Groth
University College London

2. Contribution New model for fully dynamic group signatures:
Strong: minimal level of trust required
General: not restricted to a particular design approach
Realistic: satisfied by practical constructions
Relaxed model assuming trusted setup
Backward compatibility with existing models
Suitable for more efficient constructions
Identify minor issues in the security of some constructions and suggest possible fixes

3. Outline Overview of Group Signatures
A new model for Fully Dynamic Group Signatures
A relaxed model and how it relates with previous ones

4. Group Signatures
Group Manager
Group of Users
Tracing Manager

5. Group Signatures

6. Group Signatures
𝑖𝑑, 𝜋
𝑚, 𝜎

7. Group Signatures Static Groups Partially Dynamic Groups
Fully Dynamic Groups

8. Formal Security Models for Group Signatures
Static Groups: [BMW]
Partially Dynamic Groups: [BSZ], [KY]
Fully Dynamic Groups:
Lack of rigour / Informally stated
Design specific definitions
No unified formal model
Assume a completely trusted setup

9. Fully Dynamic Group Signatures
Two main approaches for revocation:
Cryptographic Accumulators
Revocation lists
𝑎𝑐𝑐
𝑎𝑐𝑐 0
𝑎𝑐𝑐 1
𝑎𝑐𝑐 2
𝑎𝑐𝑐 𝜏
● ● ●
𝐿 0 =∅
𝐿 1 =
𝐿 2 = , , ,
● ● ●

10. Fully Dynamic Group Signatures
Main idea behind revocation:
Need to introduce time intervals: epochs
GM periodically updates information about active members in the group
Updates might follow different format

11. Our Model - Features
Does not restrict the format of updates to the group
Keeps track of the active users in each epoch
Interactive key generation for GM, TM and the users
Minimise the level of trust in the authorities

12. Our Model – Algorithms and Protocols
Setup: trusted setup of public parameters
KeyGen:
Interactive protocol between GM and TM
Generates group public key and managers’ secret keys
Join/Issue:
Interactive protocol between a user and GM
User obtains a group secret key
GM registers user public key in the group

13. Our Model - Algorithms and Protocols
Update GroupInfo:
Run by GM to update active group members
Updates to the group trigger a new epoch
Sign: members sign messages with respect to an epoch
Verify: Checks validity of a signature on message and epoch

14. Our Model - Algorithms and Protocols
Trace:
Run by TM to identify authorship of a signature
Output proof linking signature and identity
Judge: Checks validity of tracing proofs

15. Our Model – Data Structures
Registration table:
GM has writing access
TM has reading access
Linear in number of join calls
Group Info:
Updated by GM
Publicly available
Linear in number of epochs

16. Our Model - Security Notions
Correctness
Anonymity
Non-Frameability
Traceability
Tracing Soundness

17. Security Definitions - Correctness
Honest and active users can produce valid signatures
KeyGen
● ● ●
𝑚𝑠𝑘
𝑚, 𝜎,𝜏

18. Security Definitions - Anonymity
Honest signatures do not reveal identity of signer
KeyGen
● ● ●
𝑚,𝜏 𝜎
𝐴𝑑𝑣
𝑔𝑠𝑘 0 , 𝑔𝑠𝑘 1

19. Security Definitions - Non-Frameability
Honest users cannot be linked to signatures they have not produced
KeyGen
● ● ●
𝑚,𝜎,𝜏 ,𝜋
𝐴𝑑𝑣

20. Security Definitions - Traceability
TM can always trace signatures to active members
KeyGen
● ● ●
𝑡𝑠𝑘
𝑚,𝜎,𝜏 ,𝜋

21. Security Definitions - Tracing Soundness
It is not possible to link one signature to two members
KeyGen
● ● ●
, 𝜋 1
𝑚,𝜎
, 𝜋 0
𝐴𝑑𝑣

22. A Very Strong Model! Lowest possible level of Trust in the Managers
Can be relaxed to accommodate honest setup
Construction from Accountable Ring Signatures
(w/o honest setup)
KeyGen
KeyGen
● ● ●
● ● ●
𝑚𝑠𝑘

23. Accountable Ring Signatures [Xu Yung]
Users include themselves in a “Ring”
Offer Accountability Mechanism
Signers decide preferred Opener
No trusted Setup required

24. Accountable Ring Signatures
Reg
Join/Issue
InfoG
● ● ●
● ● ●
𝑅 1
𝑅 2
𝑅 𝜏
𝑚,𝜎,𝜏

25. Relaxed Model – Backward compatibility
Covers weaker models (Static and Partially dynamic)
Satisfied by Accumulator based constructions
Subtle issues in Revocation list based constructions
Might not be a problem for practical applications
Can satisfy the model providing small modifications

26. Minor issue in Traceability
𝐿 𝜏+2 = , , ,
● ● ● 𝜏
𝜏+1
𝜏+2
𝑚,𝜎,𝜏

27. Recovering Revocation list Constructions
Relax further the model to accommodate past signatures
Trivial fixes:
Initialise users as revoked
Might be expensive
Need to know in advance maximum number of users
Ad-hoc modifications:
Inexpensive for state of the art constructions [LPY12], [NFHF09]

28. Thanks!