Key Distribution and Update for Secure Inter-group Multicast Communication

Ki-Woong ParkComputer Engineering Research Laboratory

Korea Advanced Institute Science & TechnologyDec 11, 2007

The Third ACM Workshop on Security of Ad Hoc and Sensor Networks

1/17

COMPANY LOGO

Prologue

Secure Group Communication To accelerate the improve propagation speed To improve the energy efficiency

Location based services Location information according to the security level

Location Based Services

Location Free ConferenceIn this paper, Focus on the problem for secure intergroup communication

key distribution Key update

UFC 2005 UFC 2006 UFC 2007

2/17

COMPANY LOGO

1

2

3

4

Introduction to Group Communication

Related Works

Secure Group Communication

Key Update during Group Changes

Contents

3/20

5 Conclusion & Discussion

Performance Evaluation In terms of Communication / Operation

Efficiency 3/17

COMPANY LOGO

Introduction

Computation overhead Key update (overhead for generating secure key pairs frequently)

• Operation Complexity – AES : 1, RSA-Private Key : 1000, Public/Private Key Generation : 3000

Identity of sender

Contribution Switching from asymmetric symmetric key operation

• Avoids heavy computation Distributed update of the personal key Flat table

• Reduce the key storage overhead

Challenge of asymmetric key based group communication

4/17

COMPANY LOGO

Related Works

Group Key Management Protocol (GKMP) Key Encryption Key (KEK) Traffic Encryption Key (TEK)

• One-to-One Distribution do not scale to large network

Scalability Problem Logical Key Hierarchy Tree, flat table

• Broadcast traffic during key refreshment• Backward and forward secrecy

Avoid single point of failure Divide the nodes into multiple subgroups

– inter-subgroup traffic must be translated by the agents

Dual Encryption protocol• To deal with the trust of the third parties

Re-Keying Mechanism Cipher Sequences

• Time-Synchronized group key distribution protocol• periodically rekeying of the group

Today’s Paper

• Considering - Node mobility - Frequent link changes - Limited resources

5/17

COMPANY LOGO

Notations

G1

Fq : Finite Field: EK(msg) /DK(msg) : Encryption / Decryption of the message with K H(msg) : Hash Function h(x) : t-degree polynomial in Fq[x] GM : Group Manager SGM(msg) : digital signature of the group manager r : the number of bits required to record a node ID i1, i2, …, ir : node i’s ID

G2 G3

GM

i1 i2 i3 i4 i5

0 0 1 1 0

r = 5

ID : (6)10

6/17

COMPANY LOGO

Secure Group Communication (1/2)

Network Initiation Procedure Every node will get a set of secret keys from the centralized manager through

secure channel such as the physical contact• TEK (Traffic encryption keys) : protect the group communication packets• KEK (Key Encryption Keys) : support secret refreshment

t-degree polynomial : to determine the personal key shares (inter group traffic) h21(x) : determine the personal key shares of the members in G1 to G2

To recover the multicast packets sent by the nodes in G1 and G3 h21(x) , h23(x)

Ex) Node v in G1 sends a packet to the nodes in G2

G1 G2 G3

GM

v

i

h21(v)

( v,G2,Eh21(v)(msg,H(msg)) )

EK2(h21(x))

h21(v)

K2 : used to encrypt/decrypt the multicast traffic within the group

7/17

COMPANY LOGO

Secure Group Communication (2/2)

Personal Key Shares For multicast packets to G2

• Different personal keys h21(v) , h21(w)

– Information Isolation

More difficult for attacker to impersonate another node in the same group

• Unless it can collect t+1 personal keys

G1 G2

v

( v,G2,Eh21(v)(msg,H(msg)) ) h21(v)

z

( x,G2,Eh21(x)(msg,H(msg)) )

h21(z)

GMh21(x)

8/17

COMPANY LOGO

Refresh of the keys

Using flat tables One flat table per a group

• r: required bits to represent a node ID

• Flat table : consists of 2r keys

z1 z2 z3 z4 z5

z1.0 z1.1 z2.0 z2.1 z3.0 z3.1 z4.0 z4.1 z5.0 z5.1

Position of the bit

Binary Value

Ex) Node ID = 10 (01010)2

Keys: z1.0, z2.1, z3.0, z4.1, z5.0

Every Node will have exactly a half of the bits in its node ID Transmission

Ez1.0Ez2.1Ez3.0Ez4.1Ez5.0(msg)

Only “Node 10” has all the keys to decrypt the packet Ez1.1(msg) ||Ez2.1(msg) ||Ez3.0(msg) ||Ez4.1(msg)||Ez5.0(msg)

Send a message to all the members but Node 10

9/17

COMPANY LOGO

Key Update during Group Changes (1/4)

Joining operations (1/2) Node i want to joining the group G1

K1’ should be established • For backward secrecy

To establish the new flat table • Node can get an entry in the new flat table only if it has the old key at the

same position.

G1i

GM

z1 z2 z3 z4

z’1.0 z’1.1 z’2.0 z'2.1 z'3.0 z'3.1 z'4.0 z'4.1

10/17

COMPANY LOGO

Key Update during Group Changes (2/4)

Joining operations (2/2) Update of h12(x), h13(x)

• GM choose 2 t-degree polynomials

With the h12(x), h13(x)

• Personal key shares of the nodes in G2 and G3 must be updated as well.

• Propose a distributed mechanism to release new polynomials– GM broadcast an authenticated message and notification for new personal key shares

– v acquire new personal key share from w

– Intersection of theh12(v) and h21(w) Secure Channel between two nodes

GM distribute the keys to node i using Ki-GM

G1

Eh12(x) (Msg)

Eh13(x) (Msg)

G1 G2

vw h’12(v)

request

11/17

COMPANY LOGO

Key Update during Group Changes (3/4)

Leaving Operations (1/2) Node i leaves group G2

Key replacement of K2

Broadcast generated the new flat table to the remaining nodes in G2

Replacement of h21(x), h23(x)

z1 z2 z3 z4

z’1.0 z’1.1 z’2.0 z'2.1 z'3.0 z'3.1 z'4.0 z'4.1

G2

Eh21(x) (Msg)

Eh23(x) (Msg)

12/17

COMPANY LOGO

Key Update during Group Changes (4/4)

Leaving Operations (2/2) Distributed broadcast of h21(x), h23(x)

• GM broadcast an authenticated message and notification for new personal key shares

• v : acquire new personal key share from w

To prevent usage of h12(i), h32(i)

• Maintain a list of the expelled nodes until the new h’12(i) and h’32(i) are established.

G2 G1

vw h’21(v)

request

13/17

COMPANY LOGO

Conclusion & Discussion (1/3)

Overhead Consideration

Reduce the data processing time at the wireless nodes• Improve the system efficiency

Switching to symmetric ciphers• Consumed energy by 100 times

Additional transmission and reception overhead for key refreshment is totally paid off

Scheme using public/private key

Proposed Mechanism

Key Storage overhead (r + 4) log q (r + 4 + 1 + 2t) log q

Broadcast traffic during join (2r + 2) log q (2r + 2 + 1 + 2t) log q

Broadcast traffic during leaving event (3r + 1) log q (3r + 1 + 1 + 2t) log q

Encryption/Decryption overhead Asymmetric key operations t-degree polynomial+ symmetric

14/17

COMPANY LOGO

A new key distribution and update for secure inter-group communication Polynomials to support the distribution of personal key shares Flat tables to achieve efficient key refreshment

Reduce the computation overhead Power usage

Discussion (1/2) Overhead by Group Manager (GM)

• Important role in the proposed mechanism– Generation of the polynomials and flat tables

• Who? ( Base Station / Election ) in Mobile Environment

Conclusion & Discussion (2/3)

KKPP AA33S S OOS S Since 2006Since 2006

PPublic ublic KKeyey--basedbased AA33--providingproviding SSingle ingle SSignign--OOnn

KAIST CORE Lab. Designed & Managed by KAIST CORE Lab. Designed & Managed by KiKi--WoongWoongParkPark

[1] “PKASSO: Towards Seamless Authentication providing Non-Repudiation on Resource-Constrained Devices," 21st IEEE Pervasive Computing and Ad Hoc Communications, May 2007.[2] "Computationally Efficient PKI-Based Single Sign-On Protocol, PKASSO, for Mobile Devices," IEEE Transactions on Computers (under minor revision)

[1,2]

COMPANY LOGO

Conclusion & Discussion (3/3)

Discussion (2/2) Ratio of client operation to server operation

Vulnerable to DoS Attacks

Defending against Collusive Attacks• Collusion by reconstructing the polynomials of other group

– t-degree polynomial is resistant to the coalition up to t compromised members

Multiple Changes Simultaneously

5%

95%

80%

20%

43%

57%

PKIX(RSA)

48%

52%

Kerberos M-PKINIT PKASSO

: Server

: Client

80%

20%

76%

24%

This Paper

16/17

COMPANY LOGO17/17

COMPANY LOGO18/23

  Symmetric Key Asymmetric Key

Key

One Key - One Key to encrypt the

data - One Key to decrypt the

data

Two keys - Public key to encrypt the data - Private key to decrypt the data

Confidentiality

Yes Yes

Digital Signature

No Yes

Non-repudiation

No Yes

Key Distribution

No Yes

Speed(ARM PXA270)

3ms 472ms

Usage T-money (300ms), SpeedPass (100ms) [1] Internet Banking, E-Commerce

Symmetric Key vs. Asymmetric Key

[1] F.Vieira, J.Bonnet, C.Lobo, R.Schmitz, and T.Wall “Security Requirements for Ubiquitous Computing,” EURESCOM. 2005[2] A.Pirzada and C.McDonald, “Kerberos Assisted Authentication in Mobile Ad-hoc Networks," in Proceedings of ACM International Conference Proceeding Series; Vol. 56, 2004.

Discussion

18/18

COMPANY LOGO

Security Aspect

Computation Efficiency

Additional Experiment

AuthenticationDigital

signatureNon-

repudiationSecure key distribution

Kerberos YES No No No

PKIX YES YES YES YES

M-PKINIT YES No No YES

ARSA YES No No YES

SystemMobile Service Device

Total Operation TimePu Pr S Pu Pr S

PKIX(RSA-1024bit) 2 2 1 2 0 0 3449 1035 ms

Kerberos 0 0 8 0 0 6 8.12 2.4 ms

M-PKINIT TGT 1 1 7 1 1 5 3305.1 991.53 ms

M-PKINIT SGT 0 0 8 0 0 4 8.08 2.42 ms

ARSA Inter-domain AKA 2 1 0 1 1 1 3373.02 1011.9 ms

ARSA Intra-domain AKA 2 0 0 1 1 0 1799 539.7 ms

ARSA Client-Client AKA 2 0 1 2 0 1 301.02 90.31 ms

19/19