Announcements All Labs and Their Demo All HWs and Their Grading Lab 1-2 Deadline: Extended to May 21, Monday. Lab 3: Deadline is May 21, Monday. Lab Demos: All demos will occur on May 21. TA will collect the names of students in the groups (or an individual), and sort them according to surname. A demo schedule will be determined in this way. The demo for each group for Lab 1-2-3 should be completed no later than 20 mins, and the reports for the labs will also be handed in this time. Demos will start at the class at 10:00 AM and continues until 11:50 AM. The demos then will continue at Johnson Hall during the TA’s office hours. In addition to that, TA will also book additional office hours, if needed. For very exceptional situations, extra demo hours could happen on May 23. All HWs and Their Grading HW3, HW4 deadline: May 23, Wednesday. TA will have a dedicated solution session on May 23, Wednesday, for all HWs. Therefore, after solutions are announced, late HW solutions cannot be accepted. Both HW3 and HW4 have plenty of extra credit questions. Note that these are completely optional, and therefore you can skip them if you have other priorities.

CS/ECE 478 Introduction to Network Security ADVANCED KEY ESTABLISHMENT AND GROUP KEY MANAGEMENT METHODS Credits: Dr. Peng Ning, Dr. Wensheng Zhang Dr. Attila A. Yavuz CS/ECE 419/478 – Introduction to Network Security

Outline Tree-based Group Diffie-Hellman Key Exchanged Member Join-Leave, Partition, Merges Group Key Distribution Methods Forward and backward security Iolus Logical Key Hierarchy Key Graphs

GROUP KEY MANAGEMENT (I) Group Diffie-Hellman Key Exchange Schemes Dr. Attila A. Yavuz

Group Communication A group consists of multiple members Messages sent by one sender are received by all the other group members

Secure Group Communication Messages sent by a valid group member can only be understood by the other valid members Others may receive the messages, but are unable to understand them Typical approach: Encrypt the group messages with a key only known to the valid group members

Group Key Management Group key management Ensure only valid group members have access to the group key The REAL problem for secure group communication

Desired Properties of Group Key Management Group key secrecy It is at least computationally infeasible for an adversary to discover any group key Forward secrecy A passive adversary who knows a contiguous subset of old group keys cannot discover subsequent group keys Do not confuse with PFS Backward secrecy A passive adversary who knows a contiguous subset of group keys cannot discover preceding group keys Group key independence The combination of forward and backward secrecy.

Stateful v.s. Stateless Stateful Stateless Decryption of new key depends on previous keys Group member should keep track of all rekeying messages Members should be online Stateless Decryption of new key depends on establishment key set that is assigned when member join Group members don’t need to keep track of rekeying messages Members can be offline

Types of Group Key Management Group key agreement Group keys are determined collectively by all group members Usually extended from D-H key exchange Group key distribution Group keys are determined and distributed by a group key manager

Notations n: number of participants in the protocol : exponentiation base q: order of the algebraic group Mi: i-th group member, i is the index Ni: random exponent generated by group member Mi S: subsets of {N1, …, Nn} (S): product of all elements in subset S Kn: group key shared among n members

Generic n-Party D-H Key Agreement Setup All n participants agree on a cyclic group G, of order q and the base  Each member Mi chooses a random value Ni  G

Generic n-Party D-H Key Agreement (Cont’d) Generic Protocol: Distributively revealing and computing a subset of {(S)|S {N1, …, Nn}} From these subsets, member Mi computes N1…Ni-1Ni+1…Nn mod q Finally, Mi computes the shared key K = N1…Nn mod q

Generic n-Party D-H Key Agreement (Cont’d) Security The generic n-party D-H protocol is secure if the 2-party D-H protocol is secure Proof: by induction on n Remaining problem Consider {(S)|S {N1, …, Nn}} What (S) to distribute, and how?

GROUP KEY MANAGEMENT (I) Tree-based Group Diffie-Hellman Key Exchange Schemes Dr. Attila A. Yavuz

Membership Operations Formation Group partition Member add Member leave Group merge

Membership Operations Join: a prospective member wants to join Leave: a member wants to (or is forced to) leave Partition: a group is split into smaller groups Network failure: network event causes disconnectivity Explicit partition: application decides to split the group Merge: two or more groups merge to form one group Network fault heal: previously disconnected partitions reconnect Explicit merge: application decides to merge multiple pre-existing groups into a single group

Tree-Based Group Diffie Hellman Simple: One function is enough to implement it Fault-tolerant: Robust against cascade faults Secure Contributory Provable security Key independence Efficient d is the height of key tree ( < O(log2 N)), and N is the number of users Maximum number of exponentiations per node 3d

Key Tree (General) ggn1gn2n3 gn6gn4n5 gn1gn2n3 gn6gn4n5 n1 gn2n3 gn4n5

Key Tree (n3’s view) = ggn1gn2n3 gn6gn4n5 ggn6gn4n5 ggn6gn4n5 n3 gn2n3 GROUP KEY Key-path: Set of nodes on the path from member node to root node GROUP KEY = ggn1gn2n3 gn6gn4n5 gn1 gn2 ggn6gn4n5 Co-path: Set of siblings of nodes on the key-path gn1gn2n3 ggn6gn4n5 gn1 gn2n3 ggn4n5 gn6 gn2 n3 gn4 gn5 Any member who knows blinded keys on every nodes and its session random can compute the group key. Member knows all keys on the key-path and all blinded keys

Join (n3’s view) n3 gn1 gn2 ggn1n2 gn3gn1n2 n3 Tree(n4) gn4

Join (n3’s view) n3 ggn1n2gn3n4 gn3gn1n2 ggn1n2 gn3n4 n3 gn4 gn1 gn2

Leave (n2’s view) ggn1n2gn3n4 gn1n2 ggn3n4 gn1 n2 gn3 gn4 gn1 n2

Leave (n2’s view) ggn1n2gn3n4 gn1n2 ggn3n4 n2 gn3 gn4 n2

Leave (n2’s view) gn2’gn3n4 n2’ ggn3n4 gn3 gn4

Partition (n5’s view) ggn1gn2n3 gn6gn4n5 ggn1gn2n3 gn6gn4n5 gn1 gn6 ggn2n3 gn4n5 gn3 gn4 n5 n5

Partition (n5’s view) gn1 gn2n3 gn4n5 gn3 gn4 n5

Partition (n5’s view) ggn1n3gn4n5’ ggn1n3 gn4n5 gn4n5’ gn1 gn3 n5 gn3 Change share

Partition: Both Sides gn1 gn6 gn2 gn3 gn4 n5

Partition: Both sides (N5 and N6) ggn1n3gn4n5’ gn2n6’ ggn1n3 gn4n5’ gn2 n6’ n6 gn1 gn3 gn4 n2 n5’

Merge (N2’s view) ggn1n2gn5gn3n4 gn7 gn6 gn1 gn1n2 gn1n2 ggn5gn3n4 gn1

Merge (to intermediate node) gggn1n2gn6n7gn5gn3n4 ggn1n2gn6n7 ggn5gn3n4 gn1n2 n1 ggn6n7 gn7 gn6 ggn3n4 gn5 gn1 n2 n2 gn3 gn4

Tree Management: do one’s best Join or Merge Policy Join to leaf or intermediate node, if height of the tree will not increase. Leave or Partition policy No one can expect who will leave or be partitioned out. No policy for leave or partition event Successful Still maintaining logarithmic (height < 2 log2 N)

Discussion Efficiency Average number of mod exp: 2 log2 n Maximum number of round: log2 n Robustness is easily provided due to self-stabilization property

GROUP KEY MANAGEMENT (II) Group Key Distribution Iolus LKH, Key Graphs Dr. Attila A. Yavuz

Outline Overview of group key distribution A naïve solution Iolus: A Framework for Scalable Secure Multicasting Logical key hierarchy (LKH)

Group Key Distribution manager Group members Group session keys are determined by the group manager Usually used for large groups.

A Naïve Solution Use a separate secure unicast connection from the group manager to EACH group member. Requirement Each client shares a unique key with the controller. Poor scalability: n secure unicast connections n secret keys

Problems Specific to Group Communication “1 affects n” problem The actions of one member affects the entire group Group key manager Old members New member joins

Iolus Divide a large group into smaller groups Introduce entities that manage and connect the subgroups Group security controllers (GSC) Control the entire group Group security intermediaries (GSI) Control the subgroups on behalf of GSC GSC and GSI are both referred to as group security agent (GSA) With GSC as the root, GSAs form a hierarchy of subgroups A lower-level GSA is a member of the group headed by the higher-level GSA

Iolus (Cont’d)

Iolus (Cont’d) Joins GSA generates KGSA-MBR Store this key along with other information Send KGSA-MBR to the new member in a secure channel Generate a new group key K’G Send {K’G}KG to the group Send K’G to the new member in a secure channel

Iolus (Cont’d) Leaves Generate a new group key K’G Send K’G to each member MBR individually in the secure channel encrypted with KGSA-MBR

Iolus (Cont’d) Data transmission Data retransmitted within each subgroup

Iolus (Cont’d) Iolus for group key management Replace the data with the group key in data transmission

Key Tree Approaches Two types of keys SEKs (Session Encryption Key) KEKs (Key Encryption Key) A Group Controller constructs a tree based hierarchy of KEKs members Group Controller Group key Logical entities

Logical Key Hierarchy (LKH) Keys are organized in a (logical) hierarchical tree Group key is located at the root Key encryption keys are the non-root, non-leave nodes Each member corresponds to one leave node Updates the group key and the key encryption key by means of the encryption of key-nodes Rekey with only O(logN) messages

LKH (Cont’d) Initialization N secure channels GKCs K32 K31 K33 K34 K35 M1 M2 M4 M6 M5 M3 M7 M8 N secure channels

LKH (Cont’d) Member leave Log2(N) Rekeying Messages GKCs K32 K31 K34

LKH (Cont’d) Member join GKCs K32 K31 K33 K34 K35 K36 K37 K38 K22 K21

User, Key, or Group Oriented Rekeying Different performance/reliability trade-offs User-oriented re-keying Grouping re-keying messages by users Key-oriented re-keying Grouping re-keying messages by keys Group-oriented re-keying Putting all re-keying messages together to generate a big, fat message

Example User oriented Key oriented Group oriented