Key Exchange

Classical Cryptographic Key Exchange and Authentication

Suppose Alice and Bob wish to communicate. If they share a common key it is classical cryptosystem If Alice sends the key to Bob, eavesdropper will see it and be able to read the traffic To avoid this bootstrapping problem, they need to rely on third party, Cathy

Classical Cryptographic Key Exchange and Authentication

Alice and Cathy share a secret key and Bob & Cathy share a different secret key The following is a simple protocol: 1. Alice Cathy : { request for session key to Bob } kAlice 2. Cathy Alice : {kSession} kAlice {kSession} kBob 3. Alice Bob : {kSession} kBob

Classical Cryptographic Key Exchange and Authentication

Suppose Alice sends Bob a message to deposit $500 in Dan s account Eve may try to replay this message as session key doesnot give Source Authetication. To avoid Replay Attack, one of the best known protocol is Needham-Schroeder Protocol

Needham-Schroeder Protocol
1. Alice Cathy : { Alice || Bob || rand1} 2. Cathy Alice : {Alice || Bob || rand1||ksession , {Alice || ksession} kBob } kAlice 3. Alice Bob : {Alice || ksession} kBob 4. Bob Alice : {rand2} ksession 5. Alice Bob : {rand2 - 1} ksession

Needham-Schroeder Protocol
In this protocol, rand1 and rand2 are two numbers generated at random and are called Nonces When Bob receives 3rd message and deciphers it he sees that the message names Alice. He deciphers with the key he shares only with Cathy This assures that Cathy is vouching that she generated ksession so that Bob can communicate with Alice.

Needham-Schroeder Protocol
Bob trusts that Cathy sent the message to Alice and Alice forwarded it to him Now, Alice need to convince that she is talking with Bob. This is done in the following way: When Alice receives second message from Cathy, she deciphers it and checks { Alice || Bob || rand1} are present. This assures that Cathy have sent the message and it was response to first message (as rand1 is present)

NS Protocol Replay Attack

If Eve tries to replay message, Bob will message back with his random key and Eve may not be able to respond to it But if Alice gets the message, she deciphers it and apply some fixed function to random data (here decrement by 1) and return it to Bob

NS Protocol - Drawback
NS Protocol assumes that all cryptographic keys are secure In practice session keys are generated pseudorandomly Depending on the algorithm used, it may be possible to predict such keys.

NS Protocol - Drawback
Assuming NS protocol is used with insecure session key and random function, the scenario will be: 1. Eve Bob : {Alice || ksession} kBob (replay) 2. Bob Alice : {rand3} ksession (intercepted by Eve) 3. Eve Bob : {rand3 - 1} ksession

NS Protocol
This leads to a new protocol named Denning and Sacco Protocol using timestamps enabling Bob to detect this replay

Kerboros Protocol
Uses Needham Schroeder Protocol as modified by Denning and Sacco If Alice wants to use server S, Kerboros needs her to use two servers to obtain a credential that will authenticate her to S Two Servers are 1. Authentication Server 2. Ticket Granting Server

Kerboros Protocol - Ticket

It contains TAlice, Barnum = Barnum || {Alice || Alice s address || valid time || kAlice, Barnum } kBarnum where kBarnum = Key Barnum shares with Authentication Server kAlice, Barnum = Session Key that Alice and Barnum shares Valid time = Time interval for which ticket is valid (several hours)

Kerboros Protocol - Authenticator

Contains identity of the sender of the ticket With this Alice shows Barnum that the party sending the ticket is same as the party to whom ticket was issued

Kerboros Protocol - Authenticator

It contains AAlice, Barnum = {Alice || generation time || kt } kAlice,
Barnum

kAlice, Barnum = Session Key that Alice and Barnum shares kt = alternative session key generation time = time in which authenticator was created

Kerboros Protocol
Alice generates an authenticator whenever she sends a ticket She sends both ticket and authenticator in the same message

Kerboros (Version 5) Protocol

Alice s goal is to print a file using Guttenberg s service Authentication server Cerberus Ticket granting server Barnum The protocol is as follows:

Kerboros (Version 5) Protocol

1. Alice Cerberus : Alice|| Barnum 2. Cerberus Alice : { kAlice,Barnum } kAlice || TAlice,Barnum Alice deciphers first part to obtain key to communicate with Barnum These steps occur only at login: Once Alice has the ticket for ticket granting server (Barnum) , she caches and uses it.

Kerboros (Version 5) Protocol

3. Alice Barnum : Guttenberg || kAlice,Barnum || TAlice,Barnum Alice first constructs an authenticator and sends it with the ticket and the name of server to Barnum

Kerboros (Version 5) Protocol

4. Barnum Alice : Alice || { kAlice,Guttenberg } kAlice,Barnum ||
Guttenberg

TAlice,

Barnum validates the request by comparing data in authenticator with data in the ticket

Kerboros (Version 5) Protocol

5. Alice Guttenberg : AAlice, Guttenberg || TAlice, Guttenberg 6. Guttenberg Alice : { t+1} kAlice, Guttenberg

Kerboros Protocol-Drawbacks
Kerboros relies on clocks being synchronized In Kerboros 5, authenticators are valid for 5 minutes, so tickets and authenticators can be replayed Because the tickets have some fixed fields a dictionary attack can be used to determine keys shared by services or users and the ticket granting service or authentication service