m.s. dousti forsakes: a forward-secure ake mohammad sadeq dousti weekly seminars on discrete...

M.S. Dousti FORSAKES: A Forward-Secure AKE

Mohammad Sadeq Dousti

http://dnsl.ce.sharif.edu

Weekly Seminars on Discrete Mathematicsand Computer Science

FORSAKES: A Forward-Secure AKE Based on Symmetric KES

1 / 45

M.S. Dousti FORSAKES: A Forward-Secure AKE 2 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 3 / 45

Today’s talk is about…

Authenticated Key Exchange (AKE) protocols.

I R

Long-Term Key (LTK)

Session key (sk)

Initiator Responder

M.S. Dousti FORSAKES: A Forward-Secure AKE 4 / 45

Security expectations from AKE

Informally:

I and R must agree on the same session key.

No one, without the knowledge of LTK, should

be able to participate in the protocol.

The session key must be “random looking.”

Other properties:

PFS, KCI resilience, UKS resilience, …

M.S. Dousti FORSAKES: A Forward-Secure AKE 5 / 45

Security model

The so-called “security expectations” constitute a

security definition.

Security definitions make sense within a security

model, designating:

The model of computation

The model of communication

Attack model

…

M.S. Dousti FORSAKES: A Forward-Secure AKE 6 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 7 / 45

Diffie–Hellman (DH) protocol

The earliest attempt at asymmetric crypto.

Notation:

G: a (multiplicative) group of prime order q.

g: a generator of G.

Consider the following tuples, where a, b, and c

are picked randomly from ℤq:

Type 1: (g, ga, gb, gab)

Type 2: (g, ga, gb, gc)

M.S. Dousti FORSAKES: A Forward-Secure AKE 8 / 45

Decisional Diffie–Hellman (DDH) problem DDH problem: Distinguishing between Type 1

and Type 2 tuples.

DDH problem seems to be hard in some groups.

Let G be a group for which DDH is assumed to

hold.

M.S. Dousti FORSAKES: A Forward-Secure AKE 9 / 45

DH flows

A Bga

gb

Pick a randomly from

ℤq.

Pick b randomly from

ℤq.

G, g

sk = gab

M.S. Dousti FORSAKES: A Forward-Secure AKE 10 / 45

Authenticated DH (ADH-1)

DH is a key exchange (KE) protocol.

No authentication.

Prone to active attacks.

A and B can share some LTK K prior to DH

flows.

Each flow of DH can be authenticated by K.

M.S. Dousti FORSAKES: A Forward-Secure AKE 11 / 45

ADH-1 flows

A Bga, authK

(ga)

gb, authK

(gb)

Pick a randomly from

ℤq.

Pick b randomly from

ℤq.

G, g, K

sk = gab

M.S. Dousti FORSAKES: A Forward-Secure AKE 12 / 45

Perfect Forward Secrecy (PFS)

Also called “forward security.”

PFS: If LTK is revealed at time T, all session

keys established prior to this time remain secure.

ADH-1 satisfies the PFS property.

Ttime

LTK is revealedsession keys remain secure

M.S. Dousti FORSAKES: A Forward-Secure AKE 13 / 45

ADH-1 deficiency

In ADH-1, neither party is assured that the other

gets hold of sk.

Bad Solution:

B uses sk to authenticate 0 || ga || gb.

Add a 3rd flow, where A uses sk to authenticate

1 || ga || gb.

M.S. Dousti FORSAKES: A Forward-Secure AKE 14 / 45

Why bad?!

If sk is used to authenticate flows,

sk can be distinguished from random!

Solution:

Use a Key Derivation Function (KDF).

Extract two keys from gab:

• Integrity key (ik), to authenticate flows.• Session key (sk), to use for sessions.

M.S. Dousti FORSAKES: A Forward-Secure AKE 15 / 45

ADH-2 flows

A Bga, authK (ga)

gb, authik (0 || ga || gb)

G, g, K

sk = KDF(0, gab)

ik = KDF(1, gab)

authik (1 || ga || gb)

M.S. Dousti FORSAKES: A Forward-Secure AKE 16 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 17 / 45

Efficiency of DH

Best of our knowledge: All provably-secure

PFS AKE’s are based on DH. DH is very slow.

How to get a fast AKE which satisfies PFS?

Key Evolving Schemes (KES): A cryptographic

protocol whose LTK’s evolve over time.

Idea: R. Canetti, S. Halevi, J. Katz. A Forward-

Secure Public-Key Encryption Scheme,

J. Cryptology, 2007.

• Ironically, based on DH!

M.S. Dousti FORSAKES: A Forward-Secure AKE 18 / 45

Example usage of KES

M.S. Dousti FORSAKES: A Forward-Secure AKE 19 / 45

Milder form of PFS

Lifetime of the system is divided into many time

stages. Each stage is τ seconds.

Mild PFS: If LTK is revealed in time stage T, all

session keys established in time stages 0,…, T1

remain secure.

LTK is revealedsession keys remain secure

Ttime

T 1 T 10

M.S. Dousti FORSAKES: A Forward-Secure AKE 20 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 21 / 45

Computation & complexity model

All parties (including adversary) is modeled as

an interactive Turing machine (ITM).

Turing machine, equipped with communication

tapes.

All parties (including adversary) is probabilistic

polynomial time (PPT).

M.S. Dousti FORSAKES: A Forward-Secure AKE 22 / 45

Adversarial model

Interaction of adversary and parties is modeled

by a game between:

Adversary ( )𝒜 , and

A hypothetical entity called the Challenger ( )𝒞 .

𝒞 has an interface (like API!), allowing 𝒜 to

query it.

𝒞 also has a TimeEvent() interface, which is

called every τ seconds by a universal clock.

M.S. Dousti FORSAKES: A Forward-Secure AKE 23 / 45

𝒞 interface for 𝒜 Register(): Introduce a new party into the

system.

ShareLTK(x,y): Share an LTK between the

party x and party y.

Send(x,s,y,m): Send message m to session s

of party x, claiming this message comes from

party y.

If session (x, s) does not exist, it will be created.

The result includes the response of (x, s).

M.S. Dousti FORSAKES: A Forward-Secure AKE 24 / 45

𝒞 interface for – Cont’d𝒜 ExposeSS(x,s): Leaks the state of session

(x, s) to (including 𝒜 sk).

The session (x, s) is marked as “exposed.”

RevealLTK(x,y): Reveals the LTK between

party x and party y to .𝒜Both parties are marked as “corrupt” for each

other.

M.S. Dousti FORSAKES: A Forward-Secure AKE 25 / 45

Algorithmic flavor

The interface of is algorithmically defined.𝒞 The algorithms can be incorporated into tools for

automatic verification of security protocols.

M.S. Dousti FORSAKES: A Forward-Secure AKE 26 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 27 / 45

Definition roadmap

We now have a security model.

Notice that the model says nothing about the

AKE security.

It’s the role of the security definition!

To put forward the definition, we need two

central notions:

Session partnership

Session freshness

M.S. Dousti FORSAKES: A Forward-Secure AKE 28 / 45

Why we need those “central notions”?

𝒜 obviously knows the sk of an exposed session.

If 𝒜 corrupts a party, he obviously knows the sk

of any session established thereafter.

Similar results holds if 𝒜 exposes or corrupts the

“partner” of a session/party.

We need to define “partner.”

We need to define “unfresh” sessions, which are

obviously insecure.

M.S. Dousti FORSAKES: A Forward-Secure AKE 29 / 45

Session partnership

Two sessions are called partners if:

1. Both sessions output the same non-empty

session keys and session identifiers (sid).

2. Sessions have different roles (I and R).

3. Sessions recognize the other party as the

partner.

4. No other session outputs the same sid.

Very hard to satisfy, can be relaxed.

M.S. Dousti FORSAKES: A Forward-Secure AKE 30 / 45

Algorithmic approach…

M.S. Dousti FORSAKES: A Forward-Secure AKE 31 / 45

Session freshness

A session is fresh if the following holds:

1. PFS: If the LTK is revealed, it is revealed in a

time stage after the time stage when session key

is established.

2. Session is not exposed.

3. If partner session exists, conditions 1 & 2 hold

for it as well.

M.S. Dousti FORSAKES: A Forward-Secure AKE 32 / 45

Security definition: Idea

𝒜 picks a fresh session of its choice.

𝒞 tosses a coin b:

Heads: returns the session key (ℓ bits).𝒞Tails: returns a random ℓ-bit string.𝒞

𝒜 continues querying interface.𝒞 𝒜 announces its guess of b.

𝒞 announces as the 𝒜 winner IFF its guess is

correct, and the session is still fresh.

M.S. Dousti FORSAKES: A Forward-Secure AKE 33 / 45

Endowing with new interface𝒞 Test(x,s): Adversary specifies that (x,s) is

the target session of choice.

If (x,s) is fresh, returns an ℓ-bit string.𝒞 Guess(b’): Adversary announces its guess as

b.

𝒜 wins IFF b=b and (x,s) is still fresh,.

M.S. Dousti FORSAKES: A Forward-Secure AKE 34 / 45

Security definition

Define the advantage of as “the 𝒜 probability of

winning the game, 𝒜 minus ½.”

An AKE protocol is called secure if:

For all c , ∈ ℕ any PPT adversary , 𝒜 and all sufficiently large n :∈ ℕ

The advantage of is less than 𝒜 nc.

M.S. Dousti FORSAKES: A Forward-Secure AKE 35 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 36 / 45

About FORSAKES

FORSAKES: Forward-Secure AKE based on

KES

FORSAKES is described in the Random Oracle

(RO) model.

Consider RO, denoted 𝒪, as an ideal (totally

random) hash function.

In FORSAKES case, RO only simplifies the

proofs, and can be replaced by PRFs.

M.S. Dousti FORSAKES: A Forward-Secure AKE 37 / 45

FORSAKES: The 10,000-foot view

M.S. Dousti FORSAKES: A Forward-Secure AKE 38 / 45

Main properties of FORSAKES

Updating LTK: Knew = (𝒪 Kold).

“I” uses a nonce nI as part of Msg1.

“R” uses a nonce nR as part of Msg2.

Session ID: sid = nI || nR.

Session key: sk = (0 || 𝒪 sid || K).

Integrity key: ik = (1 || 𝒪 sid || K).

Authj = (Msg𝒪 j || ik) for j {2, 3}.∈

M.S. Dousti FORSAKES: A Forward-Secure AKE 39 / 45

FORSAKES messages

Msg1 = 1 || IDI || IDR || T || nI.

Msg2 = 2 || IDR || IDI || T || nI || nR.

Msg3 = 3 || IDI || IDR || T || nI || nR.

FORSAKES parties perform quite a few

“syntactical” checks on incoming messages

before responding to them.

M.S. Dousti FORSAKES: A Forward-Secure AKE 40 / 45

Topics

IntroductionDiffie–Hellman & PFSKey-Evolving Schemes (KES)Our Security ModelOur AKE DefinitionFORSAKES ProtocolEpilogue

M.S. Dousti FORSAKES: A Forward-Secure AKE 41 / 45

FORSAKES is a secure AKE

We proved that according to the mentioned

model/definition, FORSAKES is a secure AKE.

The full proof is 15 pages.

It gives a relationship between the advantage of

any (even infinitely powerful) and the 𝒜number of queries it makes.

The advantage is negligible when the number of

queries is sub-exponential.

M.S. Dousti FORSAKES: A Forward-Secure AKE 42 / 45

FORSAKES in practice

Theoretically, RO should be replaced with PRFs.

In practice, simple hash functions would suffice.

In particular, we suggest HMAC.

Depending on the environment, the stage

lifespan can be between tens of seconds to many

days (less secure).

M.S. Dousti FORSAKES: A Forward-Secure AKE 43 / 45

Future directions

Consider a model where the adversary can issue

a Desync(x,y) query.

De-synchronize the LTK between two parties.

Protocol should provide a re-synchronization

mechanism.

Consider another model, where LTK’s are one-

time: Once used, they can never be used again.

M.S. Dousti FORSAKES: A Forward-Secure AKE 44 / 45

References

See the following paper and references therein:

M.S. Dousti and R. Jalili. FORSAKES: A

Forward-Secure Authenticated Key Exchange

Protocol based on Symmetric Key-Evolving

Schemes, Advances in Mathematics of

Communications, 2015.

M.S. Dousti FORSAKES: A Forward-Secure AKE 45 / 45