Scalable Secure Bidirectional Group Communication Yitao Duan and John Canny duan Berkeley Institute of Design Computer Science.

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

More Info

[email protected] http://www.cs.berkeley.edu/~duan

Thank You!