Modeling Insider Attacks

on Group Key Exchange Protocols

Jonathan Katz Ji Sun ShinUniversity 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

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

Protocolexecution

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 thatno 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 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?