Group Key Establishment Protocols

Group Key Establishment Protocols Ruxandra F. Olimid EBSIS Summer School on Distributed Event Based Systems and Related Topics 2016 July 14, 2016 Sinaia, Romania

Outline 1. Context and Motivation 2. Classifications 3. Properties 4. Constructions 5. Attacks and Security 2

Scenarios Many-to-Many One-to-Many 3

Scenarios Many-to-Many One-to-Many Similar roles for all users Peer-to-peer communication E.g.: Virtual conference Different roles No communication between peers E.g.: Pay TV 4

Goals Many-to-Many One-to-Many General goals for group applications / services: Correctness Availability Performance Efficiency (computation, power consumptions, etc.) Security aspects: confidentiality, authentication, access control, anonymity 5

Authentication 1. Group Authentication e.g.: a message is authenticated as sent by someone from the group 2. User Authentication e.g.: a message is authenticated as sent by a specific user inside the group 6

Confidentiality We focus on confidentiality Question: How can we achieve confidentiality? Answer: by using encryption Question: What do we need to encrypt? Answer: a (set of) key(s) Question: What makes it different for groups? Answer:... 7

Group Key Solution 1: one single key for all users Question: What could go wrong? Answer: users might leave or join the group 8

Group Key Solution 2: distinct keys for all pairs of communication parties or public key crypto Question: What could go wrong? Answer: too many keys to store securely / slow communication 9

Group Key Establishment (GKE) GKE Protocols: protocols used for the establishment, distribution and management of keys in groups (i.e. more than 2 users) There is no single solution suitable for all scenarios! Criteria: Senders type: anyone can be a sender vs. privileged users send only Group size and group scalability: small (e.g.: small video group) vs. very large (e.g.: broadcast TV) Users availability: always online vs. sometimes offline Membership dynamics: static vs. dynamic groups Others: traffic volume, performance, power capabilities,... 10

GKE Classification GKA (Group Key Agreement) GKT (Group Key Transfer) 11

Scenarios GKA (Group Key Agreement) GKT (Group Key Transfer) All users participate to key generation Multiple points of trust A privileged user (group manager / KGC*) selects a key and securely distributes it to the users Single point of trust *KGC = Key Generation Center 12

GKE Requirements Scalability: accept group size changes (while maintaining efficiency), allowing users to leave and join the group (while maintaining security), etc. Independence: maintain independency from the underlying multicast routing protocol or technology Reliability: ensure timely delivery of the key to intended recipients Others... This talk focuses on security 13

Security Goals Key confidentiality Known key security Forward security Backward security Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency Key authentication Key confirmation Mutual authentication 14

Security Goals Key freshness Key independence Key confidentiality Key randomness Known key (also security called key privacy, key Key secrecy indistinguishability or non-disclosure) Forward guarantees security that is (computationally) Key unpredictability infeasible for an Backward adversary security to compute the Key group consistency key Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key authentication Key confirmation Mutual authentication 15

Security Goals Key freshness Key independence Key confidentiality Key randomness Known key security Key indistinguishability Forward security Key unpredictability Backward security Key consistency (stronger notions for key confidentiality) assure that key privacy holds regardless of the Entity authentication Key authentication adversary s knowledge on (session or long-term) Key compromise keys from other rounds of Key the confirmation protocol / the impersonation adversary s resilience actions in future Mutual or past authentication rounds of the Ephemeral protocol key leakage resilience 16

Security Goals Key confidentiality Known key security Forward security Backward security Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key freshness Key assures independence that the key is new, Key i.e. randomness it has not been used before Key indistinguishability Key unpredictability Key consistency Key authentication Key confirmation Mutual authentication 17

Security Goals Key confidentiality Known key security Forward security Backward security Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key freshness Key independence Key imposes randomness that no correlation Key exists indistinguishability between keys from Key different unpredictability sessions Key consistency Key authentication Key confirmation Mutual authentication 18

Security Goals Key confidentiality Known key security Forward security Backward security Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency key randomness warrants indistinguishability from a random number and hence Key authentication unpredictability Key confirmation Mutual authentication 19

Security Goals Key confidentiality Known key security Forward security Backward security Entity authentication Key compromise impersonation resilience Ephemeral key leakage resilience Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency prevents distinct users to accept different keys Key authentication Key confirmation Mutual authentication 20

Security Goals Key confidentiality Known key security Forward security Backward security Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency Entity authentication Key authentication Key compromise confirms the identity Key confirmation of a user impersonation resilience Mutual authentication Ephemeral key leakage resilience 21

Security Goals Key confidentiality Known key security Forward security Backward security Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency Entity authentication Key compromise impersonation resilience Key authentication Key confirmation Mutual authentication Ephemeral key prevents leakage an attacker who owns the long-term key resilience of a user to impersonate other parties to him (i.e. accepts honest parties as peers even if they are not) 22

Security Goals Key confidentiality Known key security Forward security Backward security Key freshness Key independence Key randomness Key indistinguishability Key unpredictability Key consistency avoids an adversary to recover the group key even Entity authentication if it discloses the Key long-term authentication keys and ephemeral Key compromise keys of parties involved Key confirmation except both these values impersonation resilience for the participants Mutual in the authentication test session Ephemeral key leakage resilience 23

Security Goals Key freshness Key independence Key confidentiality Key randomness Known key security Key indistinguishability Forward security Key unpredictability Backward security Key consistency (also... called explicit key authentication, it combines key confirmation and key authentication) ensures Entity that authentication all qualified users to the Key protocol authentication have actually computed the group key and no one else except them has Key compromise Key confirmation impersonation resilience Mutual authentication Ephemeral key leakage resilience 26

Adversaries Group membership: Insiders: users registered to the group but unauthorized for a given session; Outsiders: users not registered to the group Actions: Passive: eavesdrop on the communication channel Active: insert, delete, change messages on the communication channel Types of attacks: Man-in-the-middle, replay attack (we will see both later on), known key attack, DoS, etc. 27

GKE Question: How to design GKE? Answer: the natural approach is to start from 2 parties protocols and extend to 3, 4, 5,... So, let s start from the popular Diffie-Hellman key exchange 28

Diffie-Hellman Key Exchange Introduced by W.Diffie and M.Hellman ( New directions in Cryptography, 1976) Does not assure authentication Relies its security proof on the assumption that the mathematical underlying problem is hard 29

Diffie-Hellman Key Exchange Alice Bob 30

Man-in-the-Middle Attack Alice Oscar/Eve Bob 31

Joux 3-Party Key Exchange Introduced by A. Joux ( A One Round Protocol for Tripartite Diffie Hellman, 2000) Does not assure authentication, so it remains vulnerable to man-in-the-middle attacks Relies its security on the assumption that the mathematical underlying problem is hard, but works on bilinear pairs 32

33 Bilinear Pairs

Joux 3-Party Key Exchange Alice Bob Charlie 34

Joux 3-Party Key Exchange Secure under the bilinear Diffie-Hellman assumption: Constructions for bilinear maps: Weil pairing, Tate pairing 35

MultiParty Key Exchange Introduced by D.Boneh and A.Silverberg ( Applications of Multilinear Forms to Cryptography, 2002) Does not assume authentication, so it remains vulnerable to man-in-the-middle attacks Relies its security on the assumption that the mathematical underlying problem is hard, but works on multilinear maps 36

37 Multilinear Maps

MultiParty Key Exchange (broadcast msg) User i 38

MultiParty Key Exchange Secure under the multilinear Diffie-Hellman assumption: Secure constructions of multilinear maps is questionable 39

DH-Based Key Exchange Previous constructions are built on a generalization of the Diffie-Hellman assumption But GKA protocols can also use DH key exchange as building block 40

DH-Based Key Exchange Ring structure Tree structure 41

Ring-based DH (an example) I.Ingemarsson, D.T.Tang, and C. K. Wong ( A Conference Key Distribution System, 1982) Users are placed in a ring A user talks only to its neighbours 42

Ring-based DH (an example) Round 1 43

Ring-based DH (an example) Round 2 44

Ring-based DH (an example) Round 3 45

Ring-based DH (an example) Round 4 46

Tree-based DH (an example) Y.Kim, A.Perrig, G.Tsudik ( Tree-based Group Key Agreement, 2004) Users are leaves in a (balanced) tree A key is agreed between children of the same node up to the root, which becomes the final group key 47

48 Tree-based DH (an example)

Tree-based DH (an example) Round 1 49

Tree-based DH (an example) Round 2 Round 1 50

Tree-based DH (an example) Round 3 Round 2 Round 1 51

Tree-based DH (an example) The protocol includes support for dynamic groups: Join: a new member is added to the group Leave: a member is removed from the group Merge: 2 groups are merged together Partition: one group is split in 2 groups Key refresh: the group key is refreshed We next explain Leave, as an example 52

53 Tree-based DH (an example)

54 Tree-based DH (an example)

Tree-based DH (an example) Round 2: Each user refreshes its tree of keys 55

GKE Question: What kind of GKE were all these examples, GKA or GKT? Answer: GKA So, let s have a look at GKT and see some attacks! 56

GKT GKC 57

GKT GKC Registered users (insiders) Authorized users (registered) Unregistered users (outsiders) 58

GKT LLKey 1 LLKey 1 LLKey 5 LLKey 4 GKC LLKey 2 LLKey 5 LLKey 3 Registered users (insiders) Authorized users (registered) Unregistered users (outsiders) 59

Yuan et al. GKT Introduced by W. Yuan, L. Hu, H. Li, J. Chu ( An Efficient Password-based Group Key Exchange Protocol Using Secret Sharing, 2013) The long-term key is a password (split in two parts) Has no (real) security proof! 60

GKT pw 4x pw 4y pw 1x pw 1y pw 2x pw 2y GKC pw 1x pw 1y pw 5x pw 5y pw 5x pw 5y pw 3x pw 3y Registered users (insiders) Authorized users (registered) Unregistered users (outsiders) 61

62 Yuan et al. GKT

First Attack Insider attack & Replay attack 63

First Attack GKC Insider Attack 64

First Attack GKC GKC Replay Attack 65

First Attack Session s1 Session s2 66

The Modified Protocol *nonce = number used once 67

68 The Modified Protocol

Second Attack This does not make it secure against an insider attack! Both attacks were introduced by R.F.Olimid ( A Chain of Attacks and Countermeasures Applied to a Group Key Transfer Protocol, 2014) 69

Second Attack GKC Insider Attack 70

Second Attack Session s1 Session s2 71

Formal Security Models Security models formalize the security goals within a precise environment, specifying the trust assumptions, the relations between participants, the adversarial power, the communication medium Security proofs prove a protocol is secure under a specific model 72

Formal Security Models Year Name Info 2001 BCPQ [1] first security model (generalizes existing models for two or three party protocols) 2001 BCP [2] + dynamic groups 2002 BCP+ [3] + strong corruption (i.e. the attacker reveals the ephemeral internal state information of the users instances) 2005 KS [4] security against insider attacks (UC framework) 2009 GBG [5] + KCI (Key Compromise Impersonation) 2011 egbg [6] + EKL (Ephemeral Keys Leakage) 2013 g-eck [7] + EKL in test session (GKE version of eck) More info: [8], [9] Some of the proposed security models: 73

Formal Security Models [1] Bresson, E., Chevassut, O., Pointcheval, D. and Quisquater, J.J., 2001, November. Provably authenticated group Diffie-Hellman key exchange. InProceedings of the 8th ACM conference on Computer and Communications Security (pp. 255-264). [2] Bresson, E., Chevassut, O. and Pointcheval, D., 2001, December. Provably authenticated group Diffie-Hellman key exchange the dynamic case. In International Conference on the Theory and Application of Cryptology and Information Security (pp. 290-309). [3] Bresson, E., Chevassut, O. and Pointcheval, D., 2002, April. Dynamic group Diffie-Hellman key exchange under standard assumptions. In International Conference on the Theory and Applications of Cryptographic Techniques (pp. 321-336). [4] Katz, J. and Shin, J.S., 2005, November. Modeling insider attacks on group key-exchange protocols. In Proceedings of the 12th ACM conference on Computer and communications security (pp. 180-189). [5] Gorantla, M.C., Boyd, C. and Nieto, J.M.G., 2009, March. Modeling key compromise impersonation attacks on group key exchange protocols. In International Workshop on Public Key Cryptography (pp. 105-123). [6] Zhao, J., Gu, D. and Gorantla, M.C., 2011, March. Stronger security model of group key agreement. In Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security (pp. 435-440). [7] Manulis, M., Suzuki, K. and Ustaoglu, B., 2013. Modeling leakage of ephemeral secrets in tripartite/group key exchange. IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences,96(1), pp.101-110. [8] Manulis, M. "Survey on Security Requirements and Models for Group Key Exchange." IACR Cryptology eprint Archive 2006 (2006): 388. [9] Manulis, M., 2007. Provably secure group key exchange. Europ. Univ.-Verlag 74

Security Model (an example) M.C. Gorantla, C. Boyd, and J.M.G. Nieto ( Modeling key compromise impersonation attacks on group key exchange protocols, 1982) We talk about AKE (Authenticated Key Exchange) security only 75

Security Model (an example) upper bound for no. (concurrent) sessions ephemeral Correctness: information A GKE (for protocol the current is correct session) if: instance all instances OR of user U have in session accepted; s all instances AND are partnered; terminates long-term all instances key without (certified have a session by computed an key authority) the same session group session keyid (identifies session s) partner id (set of identities U wishes to establish a key with) 76 * index for user and session is distinct, but we have used the same notation i, respectively j

Security Model (an example) Stage 1 Stage 2 Adversary Adversary Adversary A protocol is AKE-secure if the winning probability is negligible close to 1/2. 77

Security Model (an example) Some informal security goals modeled by GBG: Key confidentiality: unauthorized parties cannot recover the key Forward secrecy: the adversary can learn the long-term private keys of the users, but this has no impact on the confidentiality of the keys established in previous sessions of the protocol Known key security: the adversary can learn keys from previous sessions, but this has no impact on the confidentiality of the current session key KCI resilience: the adversary can corrupt the user from the Test query, but it is not able to impersonate any of its partners to him; otherwise freshness fails. 78

Security Model (an example) Game based proofs: Game 0 Game 1 Game n the initial game (w.r.t crypto protocol that will be proven secure) infeasible to win (by a PPT adversary) 79

Thank you! Q&A 80