Cryptography Protocols

Anita JonesCS451 Information Security

Copyright(C) Anita Jones

September, 2006

Applications for protocols

Key distributionConfidentialitySign message with digital signatureAuthenticationNon-repudiation…..

September, 2006

Protocol

protocol – an agreed upon sequence of actions to accomplish some task Numbered sequence of message transmissions Exchanged by 2 or more parties

Named, but NOT guaranteed to be who they say they are

Example format1 A B: <message1>2 B A: <message2>……..

September, 2006

Illustrate protocol notation

1 A->KDC: IDA, IDB, ‘need Certificate’

2 KDC->A: EKa [‘need Certificate’, IDB, CAB]

3 . . .

4 . . .

5 . . .

Objective: distribute digital certificate for B …………..

Sequence (strict sequence) of numbered steps

A -> B denotes that A sends message to B

Message follows the colon

September, 2006

Notation for Keys

Shared secret session key – Ks

A’s public or private key – Ka

B’s public or private key – Kb

EKa[M] – encrypt with A’s key

DKa[M] – A “decrypts” with its key

Since “E” and “D” are the same, I use E, almost always.Public and private keys – obvious in context.

Key Distribution

Distribute public keys

Distribute secret (session) keys

September, 2006

Back to key distribution

each user generates public/private keysdistributes via:

individual gives out his public key, e.g. append key to email automatically

insert into public directory (maintained by reputable party) readable by all

public key authority that requires a request before returning public key (or certificate)

September, 2006

Key distribution via KDC

Version 1 situation: A wants to talk to B A & B need the public key of the other A & B trust the key distribution center KDC Users want to be assured that the key came

from KDC (authentication)

September, 2006

Get Public Key from Key Authority

… KDC (Key Distribution Center) knows public key for A,B Everyone knows KDC’s public key

1 A->KDC: “need key”, IDB

2 KDC->A: EKR-KDC [KUB ,“need key”, IDB]

3 B->KDC: “need key”, IDA

4 KDC->B: EKR-KDC [KUA ,“need key”, IDA]

Authentication: A,B know that keys came from KDC

September, 2006

Key distribution via KDC

Version 2 situation: A wants to talk to B A & B need the public key of the other A & B trust the key distribution center KDC

A already shares a secret key with KDC, Ka

B already shares a secret key with KDC, Kb

September, 2006

Get Public Key from Key Authority

… Exchanges use a shared (secret) key

1 A->KDC: EKa[“need key”, IDB]2 KDC->A: EKa [KUB ,“need key”, IDB]

3 B->KDC: EKb[“need key”, IDA]4 KDC->B: EKb[KUA ,“need key”, IDA]

September, 2006

Secret Session Key from KDC

Version 3 situation: A wants to talk to B (a session) A & B need a secret key -- shared A & B trust KDC to create that session key Protocol:

A asks for session key (to talk to B)KDC creates the key and sends it to AKDC sends the same key to BB receives a key from KDC, associated with A’s name, so B

knows that A wants a session with B

September, 2006

Get Session Key from Key Authority

… KDC (Key Distribution Center) knows public keys of A,B Everyone knows KDC’s public key

1 A->KDC: EKR-a[“key”, IDB]

2 KDC->A: EKU-a[EKR-KDC [KS ,“key”, IDB]]

3 KDC->B: EKU-b[EKR-KDC [KS ,“key”, IDA]]

One key “authenticates”; other key keeps the session key confidential

September, 2006

A&B Generate their own Secret Session Key

Version 4 situation: A wants to talk to B (a session) They want to use a shared, secret session key

… for efficiency

A & B already know each other’s public keys They talk directly – no KDC involvement

September, 2006

Create a secret shared session key

… given a public key mechanism, users can directly exchange a secret session key

1 A->B: EKU-B [IDA, “start session 88”] …A says “I want to talk”

2 B->A: EKU-A[Ks, “session 88”] …ok A, here’s our session key

B creates KS, the shared session key

September, 2006

Introducing the notion of a NONCE

Nonce word is invented or used just for a particular occasion

used in security protocols to ensure “sequence” of a set of messages ensure “freshness” of a message

can be a time stamp, a random number or a counter value

should be difficult to guesscreators must remember their nonces

September, 2006

Needham Schroeder protocolUse a trusted third party

KDC - key distribution center is trusted each user shares secret key with KDC

KDC generates keys to be used for a sessionKDC distributes those session keys

Session uses secret key, not public/private key

September, 2006

Needham Schroeder protocol

1 A->KDC: A asks for secret key for A & B

2 KDC->A: here is key & envelope for B

3 A->B: A sends the envelope (key inside)

4 B->A: I got particular key k

5 A->B: I saw that you received key k

Objective: distribute session key securely to A and B

September, 2006

Needham Schroeder protocol

1 A->KDC: IDA, IDB, N1

2 KDC->A: EKa [Ks, IDB, N1, EKb [Ks, IDA ]]

3 A->B: EKb[Ks, IDA]

4 B->A: EKs[ N2 ]

5 A->B: EKs[ f(N2) ]Objective: distribute session key securely to A and B

September, 2006

Issues

step 1 was not encrypted? Any problem?alternative values of the nonce, f(nonce)could any intervention in the sequence

allow a masquerade?replay of step 2KDC sent message to A, but who

“authenticated” B to A?

September, 2006

Why do we need steps 4 & 5

Stop replay attack where adversary captures message in step 3 and replays it, in order to disrupt operations at B

September, 2006

Still a problem …...

Assume that adversary X compromised an old session key.

OK, not likely but …Z impersonates A and tricks B into using the old key by simply replaying step 3

And if Z can intercept the message in step 4, then it can impersonate A’s response and from then on can impersonate A

September, 2006

Denning’s solution - add timestamps

1 A->KDC: IDA, IDB

2 KDC->A: EKa [Ks, IDB, T, EKb [Ks, IDA, T]]

3 A->B: EKb [Ks, IDA, T]

4 B->A: EKs[ N ]

5 A->B: EKs[ f(N) ](Clock - T) cannot exceed clock skew plus network delay

September, 2006

Controlling timing

keeping clocks in synch theoretically hard to do in practice, under normal situations, & with no

sabotage, not difficult require synching with KDC’s clock, or GPS

controlling network overhead is more difficultsuppress relay attack - sender clock ahead of

receiver’s - replay when receiver catches up

September, 2006

Digital Signature

September, 2006

Digital signature

Unforgeable: msg M signed by person P:

[M, EKp[P,M]]

Authentic: if person R receives [M, EKp[P,M]], R must be able to check that the signature could only have been created by P, and that it is attached to message M

September, 2006

Distribution protocol -- using certificates

Key authority creates certificate that specifies public key

users exchange certificates

can verify that certificate originated from the certificate authority

September, 2006

Distribution protocol -- using certificates

1 A->KDC: KUa 2 KDC->A: EKRkdc [KUa, IDA, time1] = CA

3 B->KDC: KUb 4 KDC->B: EKRkdc [KUb, IDB, time2] = CB

5 users exchange certificates

6 given CB,, A decrypts it to get KUb, IDB, time2 by computing EKUkdc[ EKRkdc [KUb, IDB, time2] ]

September, 2006

Key distribution with certificates

… users simply exchange certificates

1 A->B: CA

2 B->A: CB

September, 2006

Create a secret shared session key

… given certificates, users can directly exchange a secret session key

1 A->B: “let’s talk”, CA

2 B->A: “ok”, CB

3 A->B: EKU-B[Ks] …ok, here’s our session key KS

September, 2006

Backups

September, 2006

Avoids the suppress-replay attacks

1 A->B: IDA, Na

2 B->KDC: IDB, Nb, IDA, EKb [IDA, Na, Tb]

3 KDC->A: EKa [IDB,Na,Ks,Tb], EKb[IDA,Ks,Tb], Nb

4 A->B: EKb[IDA,Ks,Tb], EKs [Nb]

Assume that A & B share a secret key with KDC.

Tb is a limit on session key usage; only relies on B’s clock