Modeling Insider Attacks on Group Key Exchange Protocols

1. 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 U1 and impersonate U2 to U3 • Agreement: • Parties U1, U2 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

10. 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 environmentZ 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. Environment Z write inputs/ read outputs Protocol execution Real Model

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

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 withS (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…

18. 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)

22. 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 Fk(0)  Fk’(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?