Cryptography Protocols Anita Jones CS 451 Information Security

Cryptography Protocols Anita Jones CS 451 Information Security Copyright(C) Anita Jones

Applications for protocols z. Key distribution z. Confidentiality z. Sign message with digital signature z. Authentication z. Non-repudiation z…. . September, 2006

Protocol zprotocol – an agreed upon sequence of actions to accomplish some task y. Numbered sequence of message transmissions y. Exchanged by 2 or more parties x. Named, but NOT guaranteed to be who they say they are y. Example format x 1 A B: x 2 B A: x……. . September, 2006

Illustrate protocol notation 1 A->KDC: IDA, IDB, ‘need Certificate’ 2 KDC->A: EKa [‘need Certificate’, IDB, CAB] 3. . . Sequence (strict sequence) of numbered steps 4. . . A -> B denotes that A sends message to B 5. . . Message follows the colon Objective: distribute digital certificate for B …………. . September, 2006

Notation for Keys z. Shared secret session key – Ks z. A’s public or private key – Ka z. B’s public or private key – Kb z. EKa[M] – encrypt with A’s key z. 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. September, 2006

Key Distribution Distribute public keys Distribute secret (session) keys

Back to key distribution zeach user generates public/private keys zdistributes via: yindividual gives out his public key, e. g. append key to email automatically yinsert into public directory (maintained by reputable party) readable by all ypublic key authority that requires a request before returning public key (or certificate) September, 2006

Key distribution via KDC z. Version 1 situation: y. A wants to talk to B y. A & B need the public key of the other y. A & B trust the key distribution center KDC y. 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 z. Version 2 situation: y. A wants to talk to B y. A & B need the public key of the other y. A & B trust the key distribution center KDC x. A already shares a secret key with KDC, Ka x. 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 z. Version 3 situation: y. A wants to talk to B (a session) y. A & B need a secret key -- shared y. A & B trust KDC to create that session key y. Protocol: x. A asks for session key (to talk to B) x. KDC creates the key and sends it to A x. KDC sends the same key to B x. B 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 z. Version 4 situation: y. A wants to talk to B (a session) y. They want to use a shared, secret session key x… for efficiency y. A & B already know each other’s public keys y. 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 z. Nonce word is invented or used just for a particular occasion zused in security protocols to yensure “sequence” of a set of messages yensure “freshness” of a message zcan be a time stamp, a random number or a counter value zshould be difficult to guess zcreators must remember their nonces September, 2006

Needham Schroeder protocol Use a trusted third party z. KDC - key distribution center is trusted yeach user shares secret key with KDC z. KDC generates keys to be used for a session z. KDC 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, N 1 2 KDC->A: EKa [Ks, IDB, N 1, EKb [Ks, IDA ]] 3 A->B: EKb[Ks, IDA] 4 B->A: EKs[ N 2 ] 5 A->B: EKs[ f(N 2) ] Objective: distribute session key securely to A and B September, 2006

Issues zstep 1 was not encrypted? Any problem? zalternative values of the nonce, f(nonce) zcould any intervention in the sequence allow a masquerade? zreplay of step 2 z. KDC 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 z 1 A->KDC: IDA, IDB z 2 KDC->A: EKa [Ks, IDB, T, EKb [Ks, IDA, T]] z 3 A->B: EKb [Ks, IDA, T] z 4 B->A: z 5 A->B: EKs[ N ] EKs[ f(N) ] (Clock - T) cannot exceed clock skew plus network delay September, 2006

Controlling timing zkeeping clocks in synch ytheoretically hard to do yin practice, under normal situations, & with no sabotage, not difficult yrequire synching with KDC’s clock, or GPS zcontrolling network overhead is more difficult zsuppress relay attack - sender clock ahead of receiver’s - replay when receiver catches up September, 2006

Digital Signature September, 2006

Digital signature z. Unforgeable: msg M signed by person P: [M, EKp[P, M]] z. 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, time 1] = CA 3 B->KDC: KUb 4 KDC->B: EKRkdc [KUb, IDB, time 2] = CB 5 users exchange certificates 6 given CB, , A decrypts it to get KUb, IDB, time 2 by computing EKUkdc[ EKRkdc [KUb, IDB, time 2] ] 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] September, 2006 …ok, here’s our session key K S

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 September, 2006