190 likes | 401 Views
Key Distribution and Update for Secure Inter-group Multicast Communication. The Third ACM Workshop on Security of Ad Hoc and Sensor Networks. Ki-Woong Park Computer Engineering Research Laboratory Korea Advanced Institute Science & Technology Dec 11, 2007. 1 /17. Prologue.
E N D
Key Distribution and Update for Secure Inter-group Multicast Communication The Third ACM Workshop on Security of Ad Hoc and Sensor Networks Ki-Woong Park Computer Engineering Research Laboratory Korea Advanced Institute Science & Technology Dec 11, 2007 1/17
Prologue Location Free Conference • In this paper, • Focus on the problem for secure intergroup communication • key distribution • Key update UFC2007 UFC2006 UFC2005 Location Based Services • Secure Group Communication • To accelerate the improve propagation speed • To improve the energy efficiency • Location based services • Location information according to the security level 2/17
Contents 1 Introduction to Group Communication 2 Related Works 3 Secure Group Communication 4 Key Update during Group Changes 5 Conclusion & Discussion • Performance Evaluation • In terms of Communication / Operation Efficiency 3/17
Introduction • Challenge of asymmetric key based group communication • 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 4/17
Related Works • Re-Keying Mechanism • Cipher Sequences • Time-Synchronized group key distribution protocol • periodically rekeying of the group • 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 Today’s Paper • Scalability Problem • Logical Key Hierarchy Tree, flat table • Broadcast traffic during key refreshment • Backward and forward secrecy • Considering • - Node mobility • - Frequent link changes • - Limited resources • Group Key Management Protocol (GKMP) • Key Encryption Key (KEK) • Traffic Encryption Key (TEK) • One-to-One Distribution do not scale to large network 5/17
Notations GM G1 G2 G3 • 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 r = 5 ID : (6)10 6/17
Secure Group Communication (1/2) K2 : used to encrypt/decrypt the multicast traffic within the group h21(v) EK2(h21(x)) GM G1 G2 G3 v ( v,G2,Eh21(v)(msg,H(msg)) ) i h21(v) • 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 7/17
Secure Group Communication (2/2) h21(x) GM G1 G2 ( v,G2,Eh21(v)(msg,H(msg)) ) h21(v) v z h21(z) ( x,G2,Eh21(x)(msg,H(msg)) ) • 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 8/17
Refresh of the keys 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 • Using flat tables • One flat table per a group • r: required bits to represent a node ID • Flat table : consists of 2r keys 9/17
Key Update during Group Changes (1/4) GM i G1 • 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. 10/17
Key Update during Group Changes (2/4) G1 Eh12(x) (Msg) Eh13(x) (Msg) G1 G2 request h’12(v) v w • 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 releasenew 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 11/17
Key Update during Group Changes (3/4) G2 Eh21(x) (Msg) Eh23(x) (Msg) • 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) 12/17
Key Update during Group Changes (4/4) G2 G1 request h’21(v) v w • 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. 13/17
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 14/17
Conclusion & Discussion (2/3) [1,2] [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) • 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
: Server : Client Conclusion & Discussion (3/3) PKIX(RSA) Kerberos M-PKINIT PKASSO This Paper 76% 24% • 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 16/17
Thank you for attention! 17/17
Discussion • 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. 18/18
Additional Experiment • Security Aspect • Computation Efficiency