1 / 25

Modeling Insider Attacks on Group Key Exchange Protocols

Modeling Insider Attacks on Group Key Exchange Protocols. Jonathan Katz Ji Sun Shin University of Maryland. Auth. Key Exchange (AKE). Goal: Enable parties in an insecure network to establish a common (secret) session key …

milica
Download Presentation

Modeling Insider Attacks on Group Key Exchange Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related