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 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
15
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 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

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?