Mutual Authentication · 2010. 2. 9. · Network Security (N. Dulay & M. Huth) Mutual...

Network Security (N. Dulay & M.Huth)

Mutual Authentication (5.1)

Mutual AuthenticationMutual Authentication

Michael [email protected]

www.doc.ic.ac.uk/~mrh/430/



Introduction AUTHENTICATION =

Identification: A claims to have a certain identity +Verification: claim checked by B

ONE-WAY AUTHENTICATIONOne party wants to authenticateanother, e.g. host wants toauthenticate user, receiver wantssome assurance that sender is who itclaims to be

MUTUAL AUTHENTICATIONA communicates with B and no oneelse (i.e. not with an intruder), andvice versa; usually for a session, sooften combined with and needed forSession Key ExchangeOne Correctness Criterion:Mutual Authentication achieved ifthere is a Session Key K such that Abelieves (knows?) that K is a sharedsecret key for communication with B.Similar for BStronger Correctness Criterion:Mutual Authentication achieved if Abelieves that B believes that K is ashared secret key for communicationwith A. Similar for B



Introduction Contd.Many authentication protocols Different cryptosystems,

different applications. How to compare them? What guarantees do they offer?

Protocol Weaknesses History of “weaknesses” in

published security protocols Weaknesses often subtle Need for formal methods

Common Modeling Assumptions Good cryptography. Correct

implementation No failures/exceptions Trustworthy parties No unauthorized release of

secrets Messages adhere to specified

structure Traffic Analysis & Denial of

Service often ignored



Replay Attacks Simple Replay

Copy message, replay it later Suppressed Replay

Remove message, replay it later Timed Replay

Copy message, replay it withinexpiry time

Replay to SenderReplay message back to sender(Reflection Attack, e.g. forchallenge-response protocols)

INTERLEAVED RUNS Combine messages from

different (sometimesconcurrent) runs of sameprotocol

FRESHNESS/TIMELINESS Sequence Numbers

Need to be maintained for everychannel (e.g. guessing InitialSequence Numbers for TCP/IPspoofing attacks)

TimestampsAccept message if timestamp recentenough. May need synchronisedclocks. Expiry times sometimes usedfor synchronization up to t > 0(milli)seconds.

NoncesTypically randomly generatednumbers, sent in a request,returned in a reply (e.g. in challenge-response protocols).



Authentication Protocols: our notation Communicants

Alice (1st Party - Initiator)Bob (2nd Party)Trent (Trusted 3rd Party)

Only: AliceTrentMessage is encrypted with sharedsymmetric key known only to Alice &Trent. Encrypted messages will becoloured.Note: TrentAlice = AliceTrent

Only: –1Message is encrypted with a secretsession key

EKUb public key of b EKRb private key of b

Only: BobMessage is encrypted with Bob’sPublic Key. Public Key fields endwith PK.

Signed: AliceMessage is signed with Alice’sPrivate Signature Key.

NoncesEnd with N (e.g. AliceN). Typically arandom number

TimestampsEnd with T (e.g. ExpiryT). Typicallytime will go down to seconds or evenmilliseconds).



Standard Notation

CommunicantsA,a - Alice (1st Party - Initiator)B,b - Bob (2nd Party)T,t - Trent (Trusted 3rd Party)

Only: AliceBobE Kab (M) or {M} Kab

Only: –1 E K (M) or {M} K

Only: Bob EKUb(M) or {M} Kb

Signed: AliceEKRa(M) or {M} Ka

-1

NoncesNa (Alice's Nonce)

TimestampsTa (generated by Alice)

A→B: IDa, E Kab [ IDa, K, Ta, EKRa (M) ]



Only: Bob

Text: Buy 100Signed: Alice

Example: One-Way Message (Public-Key)

From: AliceText: Buy 100Signed: Alice

Only: Bob


Who: AliceAlicePK: 666ExpiresT: 31 Dec 09Signed: Trent

EKRa(IDa, M)

Version 3

EKUb (EKRa(M))Version 1 Version 2

EKUb (EKRa(M)), EKRt (IDa, KUa, Tt)



Example: One-way authenticated message,using symmetric-key crypto

From: AliceTalkTo: BobAliceN: 66

Only: AliceTrentAliceN: 66Key: –1

Only: BobTrentFrom: AliceKey: –1

Only: BobTrentFrom: AliceKey: –1

Only: –1Text: Buy 100

1

2

3



From: AliceTrentT: 11/1/02 12:45

Signed: Trent

Arbitrated Digital Signature (Encrypted)

From: AliceTo: Bob

Signed: Alice

Only: Bob


Only: Bob


21



Mutual Authentication (with Public Key)

AlicePK: 666 BobPK: 999

Only: BobText: Hi Bob

Only: AliceText: Hi Alice



Man-in-the-Middle Attack

AlicePK:666

MaxPK:888

BobPK:999

MaxPK:888

Only: ?Bob?Text: Hi Bob


Only: ?Alice?Text: Hi Alice

Only: AliceText: Hi Alice



Interlock Protocol: “some” protectionagainst man-in-middle-attack

Only:?Bob?Signature (“Hi Bob”)

Only:Bob????


Only: ?Bob?Text: “Hi Bob”

Only:?Alice?Signature (“Hi Alice”)

Only: ?Alice?Text: “Hi Alice”

Only:Alice????

AlicePK:666

MaxPK:888

BobPK:999

MaxPK:888



Andrew Secure RPC Handshake:exchange of fresh shared key

From: Alice

Only:BobAliceAliceN: 66

Only:AliceBobAliceN+1: 66 + 1BobN: 99

Only:BobAliceBobN+1: 99 + 1

Only:AliceBobKey: –1

From: AliceAliceN: 66

Only: AliceBobAliceN: 66Key: –1

Only: –1AliceN: 66

May also generate andtransmit fresh nonceto be used as AliceN in future rounds as below

↑



Only: AliceTrentTalkTo: BobAliceN: 66Key: –1

Needham-Schroeder: nonce-basedmutual authentication (1978)

From: AliceTalkTo: BobAliceN: 66

Only: BobTrentTalkTo: AliceKey: –1

Only: –1BobN: 99

12

43

Only: –1BobN–1: 99 – 1


5



Only: AliceTrentTalkTo: BobAliceN: 66Key: –1

NS (Denning-Sacco Flaw)From: AliceTalkTo: BobAliceN: 66


Only: –1BobN: 88

43

Only: –1BobN–1: 88 - 1

Only: BobTrentTalkTo: AliceKey: –1 (Cracked,e.g. compromised oldSession key)

5



Denning-Sacco Timestamp Fix (1981)Only: AliceTrentTalkTo: BobCurrT: 16/1/02,14:59Key: –1

From: AliceTalkTo: Bob

Only: BobTrentTalkTo: AliceKey: –1CurrT: 16/1/02,14:59

Only: –1BobN: 99

12

43

Only: –1BobN–1: 99 – 1

Only: BobTrentTalkTo: AliceKey: –1CurrT: 16/1/02,14:59

5



Wide-Mouthed Frog: distribution offresh shared key

From: Alice

Only: TrentAliceTalkTo: BobKey: –1AliceT: 16/1/02 8:39

Only: BobTrentTalkTo: AliceKey: –1TrentT: 16/1/02 8:40

21



Wide-Mouthed Frog: FlawsFrom: Alice

Only: TrentAliceTalkTo: BobKey: –1 AliceT: 15/1/02 8:39


From: BobOnly: BobTrentTalkTo: AliceKey: –1TrentT: 15/1/02 8:40

Only: AliceTrentTalkTo: BobKey: –1TrentT: 15/1/02 8:41

From: AliceOnly: AliceTrentTalkTo: BobKey: –1TrentT: 15/1/02 8:41




Wide-Mouthed Frog: Flaws Contd

Only: AliceTrentTalkTo: BobKey: –1TrentT: 15/1/02 8:41




Neuman-Stubblebine: fresh symm. key bytrusted server, mutual authentication


From: BobBobN: 99

Only: TrentBobTalkTo: AliceAliceN: 66ExpiryT: 8:34

Only: AliceTrentAliceN: 66TalkTo: BobExpiryT: 8:34Key: –1

Only: BobTrent

TalkTo: AliceExpiryT: 8:34Key: –1

BobN: 99

Only: BobTrent


Only: –1BobN: 99

23

1 4



Neuman-Stubblebine Re-Authentication

AliceN2: 77

Only: –1AliceN2: 77

BobN2: 111

Only: –1BobN2: 111

Only: BobTrent


1 3

2



Woo-Lam (Public-Key): one-wayauthentication of initiator of protocol


Who: BobBobPK: 999Signed: Trent

Only: BobFrom: AliceAliceN: 66


Only: TrentAliceN: 66

Only: Bob

Who: AliceAlicePK: 666Signed: Trent

Only: Alice

BobN: 99Only: –1BobN: 99

From: AliceTalkTo: BobAliceN: 66Key: –1Signed: Trent

From: AliceTalkTo: BobAliceN: 66Key: –1Signed: Trent



Woo-Lam (Message Exchanges)

12

3

45

67



Yahalom: distribution of fresh symm. Keyby trusted server, mutual authentication

1


ALICE

From: Bob

Only: TrentBobTalkTo: AliceAliceN: 66BobN: 99

BOB

TRENT

Only: AliceTrentAliceN: 66TalkTo: BobBobN: 99Key: –1


ALICE

ALICE


Only: –1BobN: 99

BOB

4

3 2



How to Verify Timeliness of a Timestamp?

Given a time T received in a message, how do we check it fortimeliness?



Summary

Cryptographic Protocols are veryhard to get right. Subtle errorsabound

If you modify a protocol toshield against known attack, howdo you know the modificationdoes not introduce new attacks?

Important to state assumptions& goals explicitly

Keep protocol as simple aspossible

Know why you are encrypting

Know when to sign and when toencrypt and which to do first

Take care about freshness andtime management

Don't assume a message has aparticular format unless you canverify it

Avoid binary messages withmultiple interpretations, e.g.paradox attack of Neuman-Stubblebine protocol

Don't sign or decrypt data forsomeone else.



Summary Continued

Scalability. Will the protocol scaleto many parties?

Known Key attack: Future runs ofprotocol should not fail if oldsession key is cracked (e.g.Denning-Sacco attack of NS)

Timestamps: ideally, should beverified by generator only

Global clock services need to besecure

What assurances do we have at the endof the authentication step?

Do not send critical data under thesession key before both parties areassured

Is the re-authentication processsimple?

Watch out for parts of message beingused for different messages

Man-in-the-Middle

Others: Cut-and-Paste, Reflection,Interleaved Runs

Mutual Authentication · 2010. 2. 9. · Network Security (N. Dulay & M. Huth) Mutual...

Documents

Transcript of Mutual Authentication · 2010. 2. 9. · Network Security (N. Dulay & M. Huth) Mutual...