GROUP N Charles Barrasso Carter May Chih-Yu (Joey) Tang

A Survey of Key Management for Secure Group Communication Sandro Rafaeli David Hutchison

Goals and Metrics Storage requirements Overhead traffic minimization Backward and forward secrecy –Messages should remain secure outside of membership changes Scalability Collusion

Approaches 1.Centralized group key management protocols –A single entity (node) is responsible for directing key management 2.Decentralized architectures –Multiple entities divide the responsibility 3.Distributed key management protocols –Each of the individual members contribute fairly equally

Decentralized Key Mgmt. Archs. More entities may fail before the whole group is affected There should not be a central manager that controls the submanagers Keys should be independent, but minimize overhead –Usually key changes limited to a single group –Sometimes leads to intercommunication problems

Distributed Key Mgmt. Protocols Each member may contribute, or any single member may generate all keys Usually not scalable –Communication time –Each member may have to have complete member list

Conclusion No perfect solution Centralized schemes are easy to implement but not scalable Hierarchical schemes hinder intercommunication between groups Distributed solutions are even less scalable

Generic Implementations of Elliptic Curve Cryptography using Partial Reduction Nils Gura Hans Eberle Sheueling Chang Shantz

Elliptic Curve Cryptography Uses points where the curve exactly crosses integer (x,y) coordinates to generate group of points. These points are ideal for SPEKE, Diffie- Hellman, and other methods and are actually much smaller and faster than those used in traditionally, while providing an equivalent level of security.

Reduction Problem: “The fundamental and most expensive operation underlying ECC is point multiplication” Expensive = Not Good for small devices with limited battery, CPU, etc. One step in point multiplication is Reduction

Partial Reduction They describe a method to short-cut Reduction and how it can be implemented in both Software and Hardware -> Partial Reduction. Partial Reduction allows for smaller operands and smaller number of expensive (clock cycles) multiplication and division operations -> Faster and less “Expensive” Partial Reduction allows ECC to be used on small, handheld devices.

Simple and Fault-tolerant Key Agreement For Dynamic Collaborative Groups Yongdae Kim Adrian Perrig Gene Tsudik

Group Key Management In Ad-Hoc networks no centralized servers or key servers Could “Elect” a server, but stresses (CPU, Battery, etc) that device too much -> want to distribute load People who whish to communicate must then agree on a key and distribute the load on managing the key amongst the devices

Key Trees Developed a Protocol that Arranges the group into a Hierarchy (Binary Tree) Each node has its own key, which it contributes to the group to form a group key Each node knows the keys of a specialized subset of the group from which it can easily generate the group key

Group Key Management Protocol As nodes enter/leave the group, the tree is split, merged, etc and computations associated with the structure change are isolated to the affected area Result: Simple, secure, fault-tolerant protocol for group key agreement that is more efficient than existing protocols of the same type

Self-Organized Network- Layer Security in Mobile Ad Hoc Networks Hao Yang Xiaoqiao Meng Songwu Lu

Ad-Hoc Network-Layer No centralized servers to impose network topology, members must self-organize Need to prevent, discover, and isolate attackers on the Network- layer only. Can’t trust anyone.

Self-organized Network Protocol Each node needs a token to participate in the network Neighbors monitor each other to detect misbehavior How long a token is valid depends on how long it has existed in the network and behaved well -> decreasing overhead over time Exploits collaboration among local nodes to protect the network without completely trusting any individual node.

A Pairwise Key Pre- distribution Scheme for Wireless Sensor Networks Wenliang Du Jing Deng Yunghsiang S. Han Pramod K. Varshney

Key Distribution Centralized, Key Agreement, Pre- distributed Sensors: Small, Little Memory and CPU; Deployed w/o Centralized server. Don’t have resources to agree upon a key. Pre-distribute keys, but must be careful of node keys being compromised -> network communication compromised

Pair-Wise Key Pre- distribution Each Node gets a Subset of shared secret keys -> Low memory requirement Any two nodes can find at least one common secret key from their set with which to compute a new pair- wise key -> Low CPU requirements

Key Pre-distribution Method Developed an improved way to breakdown key space among nodes When the number of compromised nodes is less than a given threshold, the probability that any nodes other than those compromised are affected is close to zero Requires a significant portion of the network to be compromised -> harder

SPINS: Security Protocols for Sensor Networks Department of Electrical Engineering and Computer Sciences, UC Berkeley

Sensor Hardware What are the issues? Power: Battery Computation: 4MHz Storage: 8 Kbytes instruction flash, 512 bytes of RAM and ROM Bandwidth: 10 kbps The characteristics of the Sensor Network restrict its ability to adapt the existing security technologies. Communication is the big chuck on energy consumption, therefore when developing a security structure for Sensor Network, minimizing the communication overhead is the focus. Compromised security is inevitable for current Sensor Network.

SPINS: SNEP & μTESLA SNEP: one to one agreement Data confidentiality: who receive msg (encrypted data) Data authentication: who can do what (MAC) Data Integrity: not receiving an altered data Freshness: message must be fresh (counter) μTESLA: for broadcasting (original TESLA is not for Sensor Networks) Authenticated broadcast  Code size:  The crypto routines occupies about 20% (2K) of the available code space.  Communication overhead:  About 20% more communication Conclusion

Mobility Helps Security in AdHoc Networks Laboratory for Computer Communications and Applications (LAC) School of Information and Communication Sciences (I&C) Swiss Federal Institute of Technology Lausanne (EPFL)

Security is usually enforced by a static, central authority. Ex: Communication Network, Operating System, and the access system to the vault of a bank. Static, Central Control  Exchange certificates that contain their public keys and establish a security association  Communicate using a Secure Side Channel Ex: Physical contact (wire) or Infrared communication  Adversary cannot modify messages transmitted over the secure side channel Establishing Security Association: purely mutual agreement between users Authors’ approach Friends help establishing security associations faster  Friends can help distributing the public-keys (certificate)  Direct friends only

Two Models Fully self-organized ad hoc networks : no central authority Ad hoc networks with a central authority: a (off-line) central authority  One-way security association  Ex: i trusts j (i can relate j’s public key) but j doesn’t trust i  Two-way security association  Ex: i trusts j and j trusts i i can ask a friend to issue a fresh certificate to j Ex: If a node i possesses a certificate signed by the central authority that binds j with j’s public key, then there exists a one- way security association from i to j.  Authority gives certificates to bind nodes together

Mobility Helps Security Simulation shows the higher mobility leads to a faster creation of the security associations Random walk mobility: nodes move randomly  90% of the desired security associations are established in approximately half of the convergence time. Experiment result shows  Restricted does reduce the time to establish security associations  The faster the node’s moving speed the shorter the time it needed to establish security associations (this is why this paper titled mobility helps security) (Restricted) Random waypoint mobility: choice a destination to move to  Destination  Speed of movement  The amount of time it pauses at the destination Factors: Restricted because users normally choose a destination to go to. Ex: meeting rooms, lounges, and so on.