240 likes | 419 Views
Scalable Secure Bidirectional Group Communication. Yitao Duan and John Canny http://www.cs.berkeley.edu/~duan Berkeley Institute of Design Computer Science Division University of California, Berkeley. Outline. Secure bidirection group communication Model, security definitions, etc.
E N D
Scalable Secure Bidirectional Group Communication Yitao Duan and John Canny http://www.cs.berkeley.edu/~duan Berkeley Institute of Design Computer Science Division University of California, Berkeley
Outline • Secure bidirection group communication • Model, security definitions, etc. • The Duan-Canny (DC) multicast encryption construction • Extension of DC and the new SBGC scheme • Construction, complexity, security, GDI, etc.
Group Communication n members, up to t < n may need to be evicted Center Members
Multicast Center Members
Aggregation Center Members
Security Challenges • Confidentiality and authenticity • Different challenges for the two modes • Multicast: single sender, authenticity easy • Aggregation: single receiver, confidentiality easy • So we will focus on confidentiality for multicast and authenticity for aggregation
Security Properties: Multicast • Non-group Confidentiality: non-group members can’t access • Forward Confidentiality: deleted members can’t have access after deletion • Collusion Freedom: no subset of deleted users should be able to decrypt future group communication • Backward Confidentiality: new members can’t access old data
Security Properties: Aggregation • Non-group Authenticity: non-group members can’t generate group messages • Forward Authenticity: deleted member can’t generate group messages • Collusion Freedom: no subset of t or less active members, nor any subset of deleted members, should be able to forge messages that the center accepts as originated from another member not in the colluding subset • Backward Authenticity: a user added at time τ should not have the ability to forge messages that the center accepts as coming from a member who was in the group before τ .
M7 M3 M2 M1 M4 M8 M6 M5 Secure Multicast • Asymmetric key based schemes • Traitor tracing [CFN94] • Broadcast encryption [FN93, BGW05, etc] • Duan-Canny: construstion O(1) member key, O(t) center key, O(t) message • Members don’t have to participate in every re-key operation • LKH:[Wallner et al., Wong et al.] Keys Assigned to M1 K0 Root Node K1.1 K1.2 K2.1 K2.2 K2.3 K2.4 Leaf Node K3.1 K3.2 K3.3 K3.4 K3.5 K3.6 K3.7 K3.8 Member + Use symmetric key crypto + O(logn)storage, message - Members stateful
Aggregation Authentication: What don’t Work Well • Pair-wise secret between center and each of the members • Works but not scalable • Using the traffic encryption key (TEK) • Global • Authenticate using PRGN(IDi) • IDs are public information • Identity Based Signature • Complex setting: trusted KGC • Message authentication separate from membership authentication: Center has to store list of legitimate users. O(n) storage overhead
Our Results • Extended a new multicast enc. to support temporal security in both multicast and aggregation • Membership authentication is embedded in message authentication. Aggregation message authentication also serves as membership authentication. Center doesn’t need keep a list of legal members • O(t) center storage, O(t) message, O(1) member storage • The scheme can be made to protect group dynamics information (GDI)
Duan-Canny Construction [DC06] x1 (y, x) y,x1, …, xn, xn+1, …, xn+t x2 xn+1,xn+2, …, xn+t x3 . . . xn Center Members
Duan-Canny Construction Encryption: Decrypting t times using revoked users keys c = Ey(m) φ = {c, D(xn+1, c), D(xn+2, c), …, D(xn+t, c)} Decryption: m = η(D(xi, c), D(xn+1, c), D(xn+2, c), …, D(xn+t, c)) DC construction preserves or improves the security of the underlying threshold cryptosystem (e.g. IND-CCA)
Extensions • Alternating Bit DC (ABDC) to evict more than t members • In-place update for backward confidentiality • Novel use of its key structure for authenticating aggregation messages • Protecting GDI
In-place Update f(ξ) x n 1 2 3 ξ
In-place Update f(ξ) δ x n 1 2 3 n+1 ξ
DC Construction: Key Structure x1 x2 xn+1,xn+2, …, xn+t x3 . . . xn Center Members
DC Construction: Key Structure x1 x2 xn+1,xn+2, …, xn+t, xn+t+1 x3 . . . xn Center Members
DC Construction: Key Structure x1 x2 xn+1,xn+2, …, xn+t, xn+t+1 x3 . . . xn Center Members
Protecting Group Dynamics Information (GDI) • An issue raised by [Sun et al 04] • Info about group size, join, departure rate, etc., leaked by multicast rekey messages – a problem for almost all existing multicast schemes • Batch rekeying and phantom users to fix – don’t really work well
Protecting GDI • Why is it hard? • Size of rekey message dependent on group size • Insider can separate rekey messages for member join from those for member departure • Our scheme • Message size O(t) • So we only need to mix join and departure • Members are given random indexes. Use a mixing pool to mix join and departure • Center storage becomes O(n) – all other schemes same even w/o protecting GDI
Summary • Defined models and security for bidirectional group communication • Extended the DC multicast cryptosystem for backward and authentication security • O(t) center storage, message size, O(1) member storage • Protecting GDI
More Info • duan@cs.berkeley.edu • http://www.cs.berkeley.edu/~duan • Thank You!