key distribution and update for secure inter- group multicast communication ki-woong park computer...
TRANSCRIPT
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