Embed Size (px)
Citation preview
Scalable Secure Bidirectional Group
Communication
Yitao Duan and John Cannyhttp://www.cs.berkeley.edu/~duan
Berkeley Institute of DesignComputer 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
Center
Members
n members, up to t < n may need to be evicted
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 τ .
Secure Multicast LKH:[Wallner et al., Wong et
al.]
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
K3.8K3.1 K3.2 K3.3 K3.4 K3.5 K3.6 K3.7
K2.1 K2.2 K2.3 K2.4
K1.1 K1.2
K0
M1 M2 M5M4M3 M6 M7 M8
Keys Assigned to M1
Member
Leaf Node
Root Node
+ 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]
Center
Members
x1
x2
x3
xn
.
..
xn+1, xn+2, …, xn+t
(y, x) y, x1, …, xn, xn+1, …, xn+t
Duan-Canny Construction
c = Ey(m)
φ = {c, D(xn+1, c), D(xn+2, c), …, D(xn+t, c)}
m = η(D(xi, c), D(xn+1, c), D(xn+2, c), …, D(xn+t, c))
Encryption:
Decryption:
DC construction preserves or improves the security of the underlying threshold cryptosystem (e.g. IND-CCA)
Decrypting t times using revoked users keys
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
ξ
x
f(ξ)
1 2 3 n
In-place Update
ξ
x
f(ξ)
1 2 3 n
δ
n+1
DC Construction: Key Structure
Center
Members
x1
x2
x3
xn
.
..
xn+1, xn+2, …, xn+t
DC Construction: Key Structure
Center
Members
x1
x2
x3
xn
.
..
xn+1, xn+2, …, xn+t, xn+t+1
DC Construction: Key Structure
Center
Members
x1
x2
x3
xn
.
..
xn+1, xn+2, …, xn+t, xn+t+1
Authenticating Aggregation Messages and Group Membership
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
