Modeling Insider Attacks on Group Key Exchange Protocols Jonathan Katz Ji Sun Shin University of Maryland

2 Auth. Key Exchange (AKE) Goal:  Enable parties in an insecure network to establish a common (secret) session key …  … and be assured that they share this key with their intended partner(s) Settings:  Two-party AKE well-studied/understood  What about group AKE?

3 Group AKE? Less well-understood than 2-party case  Fewer known protocols  Formal definitions/proofs only recently [BCPQ 01]  New concerns: insider attacks Need to model such attacks Need methods for preventing such attacks

4 Our Motivation There are too many papers on insider attacks!  (Yes, this is odd motivation for writing another one … )  Each paper suggests its own “ ad-hoc ” list of security requirements  Insider attacks on protocols that never claimed security against such attacks  Countermeasures w/o proofs of security

5 Our Contributions Comprehensive model for group AKE which automatically encompasses insider attacks  Security definition in the UC model [C01, CK02] As a “ bonus ”, we get all the benefits of the UC model:  Concurrency, composability, strong corruption model, … Simple, generic mechanism for achieving UC security based on known protocols

6 The Rest of the Talk “ AKE-security ”  Insider attacks on AKE-secure protocols The UC framework UC-secure group AKE  Implies AKE security, security against (previously-suggested) insider attacks Constructing UC-secure protocols

7 AKE Security [BCPQ 01, … ] Basic idea (modulo many details … ):  Adversary interacts with oracles modeling different adversarial capabilities Send, Reveal, Corrupt, …  A protocol is AKE-secure if no poly-time adversary can distinguish the session key of a “ fresh ” instance from a random key

8 Limitations of AKE Security? There are certain attacks not covered by the definition; e.g.:  Outsider impersonation attacks (i.e., there is no explicit authentication)  Insider impersonation attacks: Corrupt U 1 and impersonate U 2 to U 3  Agreement: Parties U 1, U 2 believe they are partnered, but hold different session keys

9 A Fix(?) Why not just add the appropriate definitions “ on top of ” AKE security?  Number of definitions becomes unwieldy  How do we know when we have thought of all possible attacks? Better: (simple) specification of what we want to achieve, rather than a list of everything we want to prevent

The UC Framework (overview)

11 The UC Framework [C01] General-purpose framework for defining/designing secure protocols  Key feature: guarantees security of protocols under arbitrary composition (with arbitrary sets of parties) Note: there are other frameworks with similar guarantees [PW]

12 Real/Ideal Paradigm Two models:  In the ideal world, parties send their inputs to an ideal functionality that computes and sends appropriate outputs  In the real world, parties execute some protocol (without any trusted party)  securely realizes some functionality if the actions of any real-world adversary can be “ simulated ” in the ideal world  Since the ideal-world functionality is secure (by definition),  is secure

13 More Formally … There is an environment Z which provides inputs to all parties, reads their outputs, and interacts with a “ dummy ” adversary Z is an on-line, interactive distinguisher  In particular, Z cannot be rewound

14 Real Model write inputs/ read outputs Environment Z Protocol execution

15 Ideal Model Ideal functionality write inputs/ read outputs Environment Z

16 Definition of UC Security  securely realizes functionality F if: (for the “ dummy ” real-world adversary A) there exists an ideal-model adversary S such that no Z can distinguish whether it is interacting with A (in the real world running  ) or interacting with S (in the ideal world with F)

17 Caveats A UC-secure protocol is only as “ good ” as the ideal functionality it realizes  As usual, a poorly-specified functionality will not provide any security …

Group AKE in the UC Framework

19 UC-Secure Group AKE To define a secure group AKE protocol, all we need to do is define an appropriate ideal functionality

20 Ideal Functionality (overview) Parties begin with input (pid, sid) When F receives (pid, sid) from all parties in pid, enters “ ready ” state F waits for “ ok ” from adversary  Allows player corruption mid-protocol F chooses a key k  If no parties in pid corrupted, k is random  Else, adversary chooses k Adversary schedules delivery of k to each player in pid, via F

21 Sanity Check Any UC-secure protocol satisfies:  AKE security (since k chosen at random)  Security against insider/outsider impersonation (since all parties in pid must communicate with F)  Agreement (since F sends the same key to all parties)

Constructing UC-Secure Protocols

23 Key Result We show a simple, efficient method for “ compiling ” any AKE-secure protocol into a UC-secure protocol Basically, each party signs an “ ack ” message and send it to all other parties  Using MACs will not work (insiders know k)  Ensures the “ ACK ” property [CK02]; needed for security against adaptive corruptions  Some technical subtleties …

24 Details To ensure agreement, need the “ ack ” to correspond to a unique key …  … yet the “ ack ” should not leak information about the key Use “ seed-committing PRFs ” :  PRF F such that F k (0)  F k ’ (0) if k  k ’  Can be constructed in RO model or based on one-way permutations

25 Summary We propose to simplify definitions and constructions of group AKE by working in the UC framework  Esp. useful for modeling insider attacks Simple, generic method for obtaining UC-secure protocols Can we all agree to write fewer papers on group AKE?