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


Today’s talk is about…

Authenticated Key Exchange (AKE) protocols.

I R

Long-Term Key (LTK)

Session key (sk)

Initiator Responder


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, …


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

…


Topics



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)


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.


DH flows

A Bga

gb

Pick a randomly from

ℤq.

Pick b randomly from

ℤq.

G, g

sk = gab


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.


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


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


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.


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.


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)


Topics



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!


Example usage of KES


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


Topics



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).


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.


𝒞 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).


𝒞 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.


Algorithmic flavor

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

automatic verification of security protocols.


Topics



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


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.


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.


Algorithmic approach…


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.


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.


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,.


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.


Topics



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.


FORSAKES: The 10,000-foot view


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}.∈


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.


Topics



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.


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).


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.


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 mohammad sadeq dousti weekly seminars on discrete...

Documents

forwardsecure ake8

forwardsecure ake7

forwardsecure ake3

forwardsecure ake2

forwardsecure ake6

forwardsecure ake12

forwardsecure akepfs

forwardsecure ake4