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…
…and be assured that they share this key
with their intended partner(s)
Settings:


Two-party AKE well-studied/understood
What about group AKE?
2
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
3
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
4
Our Contributions

Comprehensive model for group AKE which
automatically encompasses insider attacks


As a “bonus”, we get all the benefits of the
UC model:


Security definition in the UC model [C01, CK02]
Concurrency, composability, strong corruption
model, …
Simple, generic mechanism for achieving
UC security based on known protocols
5
The Rest of the Talk

“AKE-security”



The UC framework
UC-secure group AKE


Insider attacks on AKE-secure protocols
Implies AKE security, security against
(previously-suggested) insider attacks
Constructing UC-secure protocols
6
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
7
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
8
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
9
The UC Framework (overview)
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]
11
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
12
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
13
Real Model
Environment Z
write inputs/
read outputs
Protocol
execution
14
Ideal Model
Environment Z
write inputs/
read outputs
Ideal functionality
15
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)
16
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…
17
Group AKE in
the UC Framework
UC-Secure Group AKE

To define a secure group AKE protocol,
all we need to do is define an
appropriate ideal functionality
19
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


F chooses a key k



Allows player corruption mid-protocol
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
20
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)
21
Constructing UC-Secure
Protocols
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…
23
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
24
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?
25