SECURING THE NETWORK USING AUTHENTICATION KEY EXCHAGE PROTOCOLS

Table of contents Page no

Chapter 1: Introduction 1-16

1.1 Introduction 4

1.2 Motivation 10

1.3 Problem Statement 11

1.4 Related work 13

1.5 Outline of Dissertation 16

Chapter 2: A Survey of Earlier Literature 17-29

2.1 Introduction 18

2.2 Entity Authentication and key distribution 18

2.3 Practical Authenticated Key Agreement using passwords 20

2.4 Layering Public Key Distribution over secure DNS 22

using Authenticated Delegation

2.5 A modular approach to the design and analysis of 25

authentication and key exchange protocols

Chapter 3: Theoretical Details 30-51

3.1 Introduction 31

3.2 Problem Description 32

3.3 Proposed Approach 46

Chapter 4: Implementation Issues 53-73

4.1 Technology to be used 54

4.2 S/w and H/w requirements 56

4.3 Unified Modeling Language Design 57

Chapter 5: Implementation 75-107

5.1 DH algorithm 76

5.2 KDC 86

5.3 Message Encryption 99

5.4 Interpretation of Results 102

Chapter 6: Conclusion 109-115

6.1 Extensions of Project 110

6.2 Conclusion 113

References 115

2

3

INTRODUCTION

1.1 Introduction

A network has been defined as any set of interlinking lines resembling a

net, a network of roads or an interconnected system, a network of alliances. This

definition suits our purpose well. A computer network is simply a system of

interconnected computers. How they are connected is irrelevant, there are a number of

ways to do this.

Hence, a basic understanding of computer networks is requisite in order to

understand the principles of network security.

1.1.1. Types of Models

1.1.1.1. The ISOOSI reference model

The International Standards Organization (ISO) Open Systems

Interconnect (OSI) Reference Model defines seven layers of communications types, and

the interfaces among them. Each layer depends on the services provided by the layer

below it, all the way down to the physical network hardware, such as the computer's

network interface card, and the wires that connect the cards together.

1.1.1.2. UUCP

UUCP (Unix-to-Unix Copy) was originally developed to connect UNIX

hosts together. UUCP and similar systems are batch-oriented systems: everything that

they have to do is added to a queue, and then at some specified time, everything in the

4

queue is processed. UUCP networks are commonly built using dial-up (modem)

connections. This doesn't have to be the case though: UUCP can be used over any sort of

connection between two computers, including an Internet connection. Building a UUCP

network is a simple matter of configuring two hosts to recognize each other, and know

how to get in touch with each other.

1.1.1.3. The Internet

This is a word that we have heard way too often in the last few years. The

Internet is the world's largest network of networks . When you want to access the

resources offered by the Internet, you don't really connect to the Internet; you connect to

a network that is eventually connected to the Internet backbone, a network of extremely

fast (and incredibly overloaded!) network components. This is an important point: the

Internet is a network of networks not network of hosts.

All these communication systems demand everyday security, both at home

and work. While email, online shopping, and pervasive computing allow increased

information sharing, they also provide an avenue for malicious attackers to negate our

privacy and alter our information

“SECURITY” in this contemporary scenario has become a more sensible

issue either it may be in the “REAL WORLD” or in the “CYBER WORLD”. In the real

world as opposed to the cyber world information gathering often precedes an attack.

Movie gangsters “case the joint”, soldiers “scout the area”. This is also true in fiber world

Here “bad guys” are referred to as intruders, eavesdroppers, hackers, hijackers, etc...

The intruders first have a panoramic view of the victim’s network and then start digging

the holes. Today, the illicit activities of the hackers are growing by leaps and bounds,

viz., “THE RECENT ATTACK ON THE DNS SERVERS HAS CAUSED A LOT OF

HULLABALOO ALL OVER THE WORLD”. However, fortunately the antagonists

reacted promptly an resurrected the internet world from the brink of prostration.

Security is key in the information age. When firms are using private

networks they are not thought that much about a security, only few who required privacy

they thought about security. But, Internet changed the scenario of the entire world.

5

Specifically, who ever dealing their business on Internet required security about their

transactions.

So, there is a need of proper mechanism, which will ensure the security of

data during its transmission over the network. There must be some authentication

mechanism, which will take care that only the authorized party gets the access to the

service.

Computer security means collection of tools designed to protect data and avoids

using data from others.

Network security means securing the transactions that are made on networks.

Here network refers from simple network like two interconnected computers to complex

network like Internet.

1.1.2. Importance of Security

Organization and individuals are increasingly depends on networks of all

kinds for their daily routine transaction. E-mail is a common routine in a modern person

culture. In E-commerce applications if may be business to business or customer to

business security is major criteria. Super market to jet flight operations people are

depending on Internet. Mobile applications are also rapidly increasing throughout the

world and multimedia message services usage is also increasing.

While transmitting data many people are thinking about security like

1. Is my data is secure.

2. If a send sensitive data over my internal network then any body can watch it?

3. Any body can alter my web site display.

4. How can customers by business on Internet?

5. Can any body misuse the credit card details that are sent by customer?

So, there must be some security to safeguard the confidentiality, Integrity and availability

of data carried on network.

1.1.3. Security life cycle

A general model for security life cycle for providing security is as follows

6

Define security

1.1.4. Security serviceSecurity service is a service that provides security for data that transferring

from source to destination system. There re different security services that one needed for

transferring data.

One useful classification of security services is the following:

Confidentiality: Ensures that the information in a computer system and

transmitted information are accessible only for reading by authorized parties.

Authentication: Ensures that the origin of a message or electronic document is

correctly identified, with an assurance that the identity is not false.

Integrity: Ensures that only authorized parties are able to modify computer

systems assets and transmitted information.

Non repudiation: Requires that neither the sender nor the receiver of a message

be able to deny the transmission.

Access control: Requires that access to information resources may be controlled

by or for the target system.

Availability: Requires that computer system assets be available to authorized

parties when needed.

1.1.5. Security attacks

A specific threat is a possible means by which secured information may be

breached and security attacks is a realization of threat. There are two kinds of attacks one

is passive attack and other one is active attack. Security attacks or threat are comes under

four major categories

Those are:

1. Interruption.

2. Interception.

3. Modification

7

Verify security Analyze threats & risks

Define security mechanism Define security

services

4. Fabrication

Normal flow: The data is passed between source and destination without any disturbance

is called as normal flow of operation.

S: source

D: destination

1. Interruption:

If the data on the transmission link is destroyed or made not available to

the destination means it is called as interruption.

Good morning

2. Interception:

Interception means accessing data by an unauthorized party i.e. data is

read by others.

Good morning

Good morning

3. Modification:

When an unauthorized party changes data it is called modification attack.

Good morning

Bad morning

4. Fabrication:

Some times intruders create a message and sent to the destination party

pretend as the source is sending message.

8

S

S

S

D

D

D

x

x

SD

SD

x

Bad morning

In this interruption and interception are passive attacks in which the

content of the messages are not modified. In these types just the intruders in middle will

not take any action but just sees the contents. (Eavesdroppers)

And the Modification and Fabrication are Active attacks in which the message

contents are modified there by misleading the receiver.

1.1.6. Security mechanisms

To provide security services for data transmission the following are the

mechanisms.

Encipherment mechanism: The text message can transmit into another form and then

start transmission. So, that data flow and traffic flow confidentiality.

Digital signature mechanism: A signing and verifying procedure for data, so that

authentication ensured with digital signature mechanism.

Access control mechanism: By using privilege concepts we can control the accessing of

data.

Data integrity mechanism: By using hash function or message authentication functions

we can provide data integrity.

1.1.7. Security in Layers

The following are the general security methods that follow in the layers of

the ISOOSI model.

Physical layer – Wire tapping can be foiled by enclosing some transmission lines in

sealed tubes which contains gas at high pressure. Drilling into the tube reduces the

pressure and releases gas there by triggering the alarm.

Data link layer - In this packets on the point-to-point line are encrypted while

sending from one system to another(link encryption).

Network layer – Fire walls can be installed to judge the packets.

Transport layer – End to end connections are encrypted.

Application layer – In this rather than encryption the messages are authenticated

9

Except, the physical layer all the other layers include the cryptographical

techniques for their securing purposes.

Here, we mainly focus on providing security in application layer which

includes DNS, Web pages, HTTP, CGI scripts, content delivery networks, Web caching.

1.2 Motivation

Network security is a complicated subject, historically only tackled by

well-trained and experienced experts. However, as more and more people become wired,

an increasing number of people need to understand the basics of security in a networked

world. This document was written with the basic computer user and information systems

manager in mind, explaining the concepts needed to read through the hype in the

marketplace and understand risks and how to deal with them.

Security is a broad topic and covers a multitude of sins. In its simplest

form, it is concerned with making sure that nosy people cannot read, or worse yet,

secretly modify messages intended for other recipients. It is concerned with people trying

to access remote services that they are not authorized to use. It also deals with ways to

tell whether that message is from correct source or not.

Most security problems are intentionally caused by malicious people

trying to some benefit, get attention, or to harm someone. These problems include

students of getting fun from snooping on peoples e-mail, spy, to learn an enemy’s

military or industrial secrets, stockbrokers, to deny a promise made to a customer by e-

mail. Hence, it should be clear that making a network secure involves a lot more than just

keeping it free from programming errors. It involve out smarting often intelligent,

dedicated, and sometimes well-funded adversaries. It should also be clear that measures

that will thwart casual adversaries will have little impact on the serious ones.

People authenticate other people by recognizing their faces, voices and

handwriting. Proof of signing is handled by signatures on letter head paper, raised seals

and so on. Tampering can usually be detected by hand writing, ink and paper experts.

None of these options are available electronically. Clearly other solutions are needed.

We would like to mention a quote which is be fitting in the context of security –

“The art of war teaches us on the likelihood of not to rely upon the

chances of enemy’s not coming but to prepare ourselves to counter all the threats

10

posed by the enemy if he comes and attacks.”

So in this fast growing world where everything is based on networks we

need to have a strong and invincible security measures which will allow us to tackle any

sort of problems.

However, new developments are plentiful. To make these developments

successful definitely there should be an effective tool that provides security. We are here

with providing the tool for this purpose so as to make new technologies not going down

to ground level as soon as they arise.

1.3 Problem Statement:

Authenticated key establishment protocols are designed to provide two or

more specified entities communicating over an open network with a shared secret key

which may subsequently be used to achieve some cryptographic goal such as

confidentiality or data integrity. Secure authenticated key establishment protocols are

important as effective replacements for traditional key establishment achieved using

expensive and inefficient couriers.

1.3.1. Existing System:

The approach we deal here is not an encryption mechanism as we

normally think of, indeed that do not typically use it to encrypt data. Instead, it is a

method to securely exchange the keys that encrypt data. Diffie-Hellman is an algorithm

that accomplishes this secure exchange by creating a “shared secret” (sometimes called a

“key encryption key”) between two devices. The shared secret then encrypts the

symmetric key (or “data encryption key” i.e. DES, Triple DES, CAST, IDEA, Blowfish,

etc.) for secure transmittal.

This algorithm works on the basis of only proper secret keys agreed

between honest conferees. If any malicious user, who may destruct the conference or

delay the operation, is found or suspected, then the malicious user’s port is blocked for

further operations. The process begins when each side of the communication generates a

private key. Each side then generates a public key, which is a derivative of the private

key. The two systems then exchange their public keys. Each side of the communication

11

now has their own private key and the other systems public key. Noting that the public

key is a derivative of the private key is important – the two keys are mathematically

linked.

Because the public key is indeed public and ends up on other systems, the

ability to figure out the private key from it would render the system useless. This is one

area requiring trust in the mathematical experts. The fact that the very best in the world

have tried for years to defeat this and failed bolsters my confidence a great deal.

1.3.1.1. Communicating with the Diffie-Hellman algorithm

In this Diffie-Hellman algorithm the basic assumption is sharing the secret

key. The key must be agreed upon the telephone or in person but in any event not an in-

secured network. If the communication partners have previously and recently used a key,

one party can transmit the new key to other using the old key.

One party throws a challenge to other in the form of sending

a message and encrypts that message using their shared key. The authentication is

achieved by responding to the challenges.

In simple this is known as

“Challenge-response protocol”

1.3.1.2. Draw back of algorithm

A man-in-the-middle attack (MITM) is an attack in which can attacker

is able to read, insert and modify at will, messages between two parties without either

party knowing that the link between them has been compromised. The attacker must be

able to observe and intercept messages going between the two victims. The MITM attack

is particularly applicable to the original Diffie-Hellman key exchange protocol, when

used without authentication.

The possibility of a man-in-the-middle attack remains a

serious security potential problem, even for many public-key based cryptosystems

because in these days there are several ways of breaking into the networks.

Man-in-the-Middle Attack was Successful Against Citibank’s 2-Factor Token Authentication

12

1.4 Related work

In cryptography, a key-agreement protocol is a protocol whereby two

or more parties can agree on a key in such a way that both influence the outcome. If

properly done, this precludes undesired third-parties from forcing a key choice on the

agreeing parties. Protocols which are useful in practice also do not reveal to any

eavesdropping party what key has been agreed upon.

However, Diffie hellman exponential key exchange protocol in and of

itself does not specify any prior agreement or subsequent authentication between the

participants. It has thus been described as an anonymous key agreement protocol.

Anonymous key exchange, like Diffie-Hellman, does not provide

authentication of the parties, and is thus vulnerable to man in the middle (MITM) attack.

Hence, we thus should make our selves guarenteed that there must be a

compulsion in including the third parties for the effective communication between the

partners.

A wide variety of third party schmes were emerged in the sequence.KDC

which is an effective mechanism which drives out the problem ie.man-in-the-middle

attack.The other works that are relating KDC are

1.4.1. Kerberos

Kerberos is a computer network authentication protocol which allows

individuals communicating over an insecure network to prove their identity to one

another in a secure manner. Kerberos prevents mitm attacks, and ensures the integrity of

the data. Its designers aimed primarily at a client-server model, and it provides mutual

authentication — both the user and the server verify each other's identity.Kerberos builds

on symmetric key cryptography and requires a trusted third party.

13

Kerberos uses as its basis the Needham-Schroeder protocol. It consists of

two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server

(TGS). Kerberos works on the basis of "tickets" which serve to prove the identity of

users.

1.4.1.1. Kerberos Opeartion

1. A user enters a username and password on the client.

2. The client performs a one-way hash on the entered password, and this becomes the

secret key of the client.

3. The client sends a clear-text message to the AS requesting services on behalf of the

user.Neither the secret key nor the password is sent to the AS.

4. The AS checks to see if the client is in its database. If it is, the AS sends back the

following two messages to the client:

Message A: Client/TGS session key encrypted using the secret key of the

user.

Message B: Ticket-Granting Ticket (which includes the client ID, client

network address, ticket validity period, and the client/TGS session key)

encrypted using the secret key of the TGS.

5. Once the client receives messages A and B, it decrypts message A to obtain the

client/TGS session key. This session key is used for further communications with

TGS. (Note: The client cannot decrypt the Message B, as it is encrypted using TGS's

secret key.) At this point, the client has enough information to authenticate itself to

the TGS.

6. When requesting services, the client sends the following two messages to the TGS:

Message C: Composed of the Ticket-Granting Ticket from message B and

the ID of the requested service.

Message D: Authenticator (which is composed of the client ID and the

timestamp), encrypted using the client/TGS session key.

14

7. Upon receiving messages C and D, the TGS decrypts message D (Authenticator)

using the client/TGS session key and sends the following two messages to the client:

Message E: Client-to-server ticket (which includes the client ID, client

network address, validity period and Client/server session key) encrypted

using the service's secret key.

Message F: Client/server session key encrypted with the client/TGS

session key.

8. Upon receiving messages E and F from TGS, the client has enough information to

authenticate itself to the SS. The client connects to the SS and sends the following

two messages:

Message E from the previous step (the client-to-server ticket, encrypted

using service's secret key).

Message G: a new Authenticator, which includes the client ID, timestamp

and is encrypted using client/server session key.

9. The server decrypts the ticket using its own secret key and sends the following

message to the client to confirm its true identity and willingness to serve the client:

Message H: the timestamp found in client's recent Authenticator plus 1,

encrypted using the client/server session key.

10. The client decrypts the confirmation using its shared key with the server and checks

whether the timestamp is correctly updated. If so, then the client can trust the server

and can start issuing service requests to the server.

11. The server provides the requested services to the client.

1.4.1.2 Kerberos drawbacks

15

Single point of failure: It requires continuous availability of a central server.

When Kerberos server is down, no one can log in. This can be mitigated by using

multiple Kerberos servers.

Kerberos requires the clocks of the involved hosts to be synchronized. The tickets

have time availability period and, if the host clock is not synchronized with the

clock of Kerberos server, the authentication will fail. The default configuration

requires that clock times are no more than 10 minutes apart. Password changing is

not standardized, and differs between server implementations.

1.5. Out line of Dissertation:

For securing purpose, we use the mechanisms of encryption and

decryption with a parameterized function called key. Anyone can encrypt using the

public key, but only the private key can decrypt.The amount of secrecy depends on how

secretly we are maintaining the private key.

First, we wish to design an algorithm (Diffie-Hellman) for the establishing

a shared key between the partners used for their communication. This algorithm lacks in

condition that the partners who are sharing the key with right one or Trudy.

Hence, we are going to introduce a Key Distribution center (KDC) as

interface between the partners.

This KDC supplies each partner with a key that is unique to the partner.

With this key they are going to communicate.

First, the communication partners establish a session with which they are

going to communicate.

This key will be sent by one partner to KDC in which the key is encrypted

with the key that the partner shares with KDC

This, KDC in turn decrypts this message and extracts the other partner

identity and the session key from the previous message.

16

It then constructs a new message containing the sender’s identity and the

session key.

It encrypts this message using the key it shares with the receiver and then

sends to it.

When the receiver decrypts he now knows that the other partner wants to

communicate with him.

Thus, the shared secret key is transferred.

17

2.1. Introduction:

The provable security approach to the notoriously tough problems of

authentication and session key exchange / distribution. We provide definitions and

proven secure protocols for a variety of problems. The first paper in this line was Entity

authentication and key distribution which looked at a two party setting and introduced

a model for sessions. The three party case was addressed in the paper Layering Public

Key Distribution over Secure DNS using Authenticated Delegation. A simulation

based approach is developed in A modular approach to the design and analysis of

authentication and key exchange protocols. The paper Practical Authenticated key

agreement using passwords includes updated versions of the basic definitions of the

first two papers above for the two party setting.

2.2. Entity Authentication and key distribution

The paper was proposed by the authors Bellare and Rogway in which the

two way authentication is done i.e. mutual authentication and authentication key

exchange were described.

For centuries, cryptographic protocols were designed by trial and error. A

scheme was proposed, to be adequate. History has shown that the success rate of this

method is not too impressive: proposed protocols were often broken, sometimes years

after they were first put forward.

2.2.1. Introduction:

Entity authentication is the process by which an agent in a distributed

system gains confidence in the identity of a communication partner. More often than not,

the entity authentication process is coupled with the distribution of a session key which

18

the partners can later use for message confidentiality, integrity, or whatever else. These

are central problems in computing practice, for without their resolution distributed

computing cannot realistically get off the ground. This importance is reected in the

enormous amount of attention that these problems have received in the Literature;

literally hundreds of papers have been written and protocols proposed and implemented.

This paper focuses on two versions of the the two-party, mutual, symmetric case.

In the mutual authentication problem the parties engage in a conversation

in which each gains confidence that it is the other with whom he speaks. In the

authenticated key exchange problem the parties also want to distribute a fresh and secret

session key.

2.2.2. Model:

One difficulty in laying foundations for entity authentication has been the

lack of an appropriate model for authentication in the distributed environment. This paper

specifies an appropriate model. Here they assumed that all communication among

interacting parties is under the adversary's control. In particular, the adversary can read

the messages produced by the parties, provide messages of her own to them, modify

messages before they reach their destination, and delay messages or replay them. Most

importantly, the adversary can start up entirely new instances of any of the parties,

modeling the ability of communicating agents to simultaneously engage in many sessions

at once

2.2.3. Definitions:

In the presence of an adversary, it is unclear what it could possibly mean

to be convinced that one has engaged in a conversation with a specified partner after all,

every bit communicated has really been communicated to the adversary, instead. We deal

with this problem as follows. As has often been observed, an adversary in our setting can

always make the parties accept by faithfully relaying messages among the

communication partners. But this behavior does not constitute a damaging attack; indeed,

the adversary has functioned just like a wire, and may as well not have been there.

The idea of definition of a mutual authentication is then simple but

strong the author said that a protocol is secure if the only way that an adversary can get a

party to accept is by faithfully relaying messages in this manner. In other words, any

19

adversary effectively behaves as a trusted wire, if not a broken one. Formalizing this

simple idea is not so simple, the main tool will be a notion of matching conversations.

To define authenticated key exchange it is necessary to capture a

protocol's robustness against the loss of a session key: even if the adversary gets hold of

one, this should not compromise anything but the session which that key protects. This is

done by allowing the adversary to obtain session keys just by asking for them. When this

inquiry is made, the key is no longer fresh, and any partner's key is declared unfresh, too.

Fresh keys must remain protected. This paper formalized adversary's inability to gain any

helpful information about them with the formalizations of security for probabilistic

encryption.

2.2.4. Draw back:

Despite their significance and long histories, both problems lack any

modern, complexity-theoretic treatment. In particular, the primitives and tools formalized

and understood in the theoretical community today (e.g. encryption, signatures, zero-

knowledge, proofs of knowledge, identification) don't seem adequate to treat these

problems.

2.3. Practical Authenticated Key Agreement using Passwords

The paper was proposed by Taekyoung Kwon in Security services 56

National computing Symposium 2001.In this, the authors had given the password based

authentication over a reliable channel.

Due to the low entropy of human-memorable passwords, it is not easy to

conduct password authenticated key agreement in a secure manner. Though there are

many protocols achieving this goal, they may require a large amount of computation

specifically in the augmented model which was contrived to resist server compromise.

They proposed a new practical password authenticated key agreement

protocol that is efficient and generic in the augmented model. The scheme here is

considered from the practical perspective (in terms of efficiency) and is provably secure

under the Diffie-Hellman intractability assumptions in the random-oracle model.

20

They also contributed more realistic and generic; a conceptually simple

but novel password guessing attack which can be mounted on every three-pass password-

based protocol unless care is taken in both the design and implementation phases.

2.3.1. Introduction:

User authentication is necessary for the typical case that a human being

resides as a client and tries to log on to a remote server machine. The server must be able

to determine the user's identity reliably over a public or private channel. Password

authentication is one of such methods, in which simply the user memorizes a (short)

password while the server maintains a user profile that associates the user name and the

password verifying information. The intrinsic problem with this method is the memorable

password, associated with each user, has low entropy, so that it is not easy to protect the

password information against the notorious password guessing attacks by which attackers

could search the relatively small space of human-memorable passwords.

Since a pioneering method that resists the password guessing attacks was

introduced to cryptographic protocol developers, there has been a great deal of work for

password authenticated key agreement.

2.3.2. Model:

A password-based protocol designed in the augmented model can resist

server compromise.In other words, an adversary who compromised a password profile

from a server cannot impersonate a user without launching dictionary attacks. For this

additional property, the related protocols (for example, A-EKE, AMP, AuthA, B-SPEKE,

PAK-Z, and SRP) are more expensive than those are not (for instance, EKE, EKE-2,

SPEKE, and PAK) in the augmented model. It is observed that the existing provably-

secure schemes are still expensive in the augmented model in terms of the amount of

computation, and that it is desirable to minimize the number of message passes and the

size of message blocks for practice on expensive communication channels. So the paper

designed a new three-pass password-based protocol in the augmented model with both

security and efficiency in mind. They achieved this goal interestingly by a composition

21

under the careful observation of the existing schemes discussed by the IEEE P1363

Standard Working Group, say without losing the presumed level of security. They called

the protocol TP-AMP and proved its security in the random oracle model.

2.3.3. Drawback:

On developing the new three-pass password-based protocol, they find a

conceptually simple but novel password guessing attack which can be mounted on every

three-pass password-based protocol by exploiting a small window of vulnerability

resulting from a standard technique to resist on-line guessing attacks, say from counting

the number of failed requests. The attack is due to the server's failure to synchronize

multiple simultaneous requests, and is unavoidable in three-pass protocols unless special

care is taken in both the design and implementation phases. They called this attack a

many-to-many (or parallel ) guessing attack because an active attacker can validate as

many password guesses as (s)he makes server instances invoked concurrently, regardless

of its upper limit of on-line guessing.

2.3.4. The proposal to drawback:

For this purpose, a small hash table may be maintained by the server to

track the currently served or blocked clients. The blocking policy should be considered

carefully but flexibly. This resolution method may reduce the window of vulnerability

notably but still leaves an issue about DoS (Denial of Service). Aside from the danger of

DoS attacks, a race condition and some bottleneck to the hash table are now only

concerns while they could be negligible by careful consideration. The possible prevention

methods might be considered both in the design and implementation phases of PAK.

2.4. Layering Public Key Distribution over Secure DNS using Authenticated Delegation

The paper was proposed by John P. Jones, Daniel F. Berger, Chinya V.

Ravishankar in the Defense Advanced Projects Research Agency under contract F30602-01-

2-0536. In this paper they proposed the secured communication through DNS and

Internet key service servers.

22

Digital communication has become pervasive, but there are few

guarantees that such communications are secure and private. Indeed, security and privacy

threats, long seen as hypothetical, are already real; in 2004, for the first time ever, an

arrest was publicly acknowledged as having resulted from passive email monitoring.

Internet Key Service (IKS), a distributed the Internet architecture for

authenticated distribution of public keys, layered on Secure DNS (DNSSEC).

2.4.1. Introduction:

The DNS namespace is the Internet-wide standard for defining who has

control over which names. IKS is loosely coupled to DNS, so that it can provide

specialized key distribution protocols without requiring changes to or imposing

significant overhead on DNS.

2.4.2. Model: key authentication

The most widely used approaches for solving the key authentication

problem is the certifying authority model, exemplified by SSL (Secure Sockets Layer)

which builds secure communication between the sockets, and the web-of-trust model,

exemplified by Pretty Good Privacy (PGP), a complete e-mail security package.

2.4.2.1. Certifying Authorities: The certifying authority (CA) model assumes a small

number of highly trusted individuals or organizations. Each key-identity binding must be

certified by one of these trusted entities. Certificate verification requires the certifier’s

public key to first be authenticated. In practice, a small set of root certificates, which are

public keys for various recognized certifying authorities, are typically preloaded into the

cryptographic application.

2.4.2.2. Webs-of-Trust: The web-of-trust model relies on peers to vouch for the validity

and trustworthiness of other peers. An unfamiliar key is accompanied by affirmations

(digital signatures) from a set of community members who assert that the provided key is

associated with the claimed identity. A recipient accepts the key only upon receiving

enough verifiable affirmations from individuals that they trust.

IKS follows the certifying authority model; the IKS server for a domain

acts as a CA for that domain and its public key can be authenticated by its key

commitment published via DNSSEC (DNS Security).

23

2.4.2.3. Zone Signing: A DNSSEC-enabled DNS server responsible for a given domain

(called a zone) signs the resource records comprising the zone with a public/private key

pair bound to that zone, and delivers those signatures to querying clients. These Resource

Record Signatures are stored in a new DNS record type, RRSIG, which contains a

signature that authenticates a specific named set of resource records (RRSet). Each

named resource in a secured DNS zone will have at least one associated RRSIG record.

A DNSSEC responds to a query from a DNSSEC-enabled client with

the DNS record for the name specified, along with the associated RRSIG record. The

client obtains the public key associated with the zone and verifies the provided signature.

If the signature is valid, the client can trust that the response was provided by the

authoritative source.

2.4.3. Key Distribution in DNSSEC:

To verify signatures, the client must be either statically configured with

the public key for the queried zone (the zone key), or be able to obtain and authenticate it.

To facilitate distribution of zone keys, DNSSEC defines a DNSKEY resource record

type. A DNS client queries for a zone key in the same way it queries for any other DNS

record type. To authenticate the retrieved key, the DNSKEY record must be signed by a

key which the client has previously authenticated, typically the key of the parent domain.

By recursively requesting keys and moving up the DNS hierarchy, the client will either

find a trusted key, or exhaust the name space without doing so, causing the key

authentication attempt to fail.

Key domain

Key registration Signing keys

IKS location IKS location Signing key Signing key

24

IKS server

DNSSEC server

Client application Domain Admin

Commitments Commitments

Figure: 2.1Figure 2.1 shows IKS Architecture: Naming and authentication authority is

placed in DNS and IKS, which clients use to resolve names securely.

2.4.3.1. IKS Overview: IKS allows public keys to be registered to any entity that can be assigned a

DNS name, such as a host, user, or service port. These keys are stored in and managed by

IKS servers, which may be discovered securely through DNSSEC. In turn, IKS servers

handle key registration and lookup requests for names belonging to a specific DNS

domain in

an authenticated manner.

2.4.4. Drawback:

IKS offers no guarantees about how verification was performed during

key registration. IKS is decoupled from any standards or protocols for identity

verification within domains. Clients receiving validated query responses from domain D

decide for themselves what trust to place in D. IKS insulates the end-user from the

complexities of key distribution, but does not pretend to make guarantees about the

trustworthiness of domains. In all contexts, including IKS, one must not confuse

authentication with trustworthiness.

2.5 A modular approach to the design and analysis of authentication and key exchange protocols

The paper was presented by M. Bellare, R. Canetti and H. Krawczyk in

Proc. 30th Annual Symposium on the Theory of Computing, ACM, 1998. In this the

author proposed the Message Authentication code and cryptography.

The problem of secure communications is very broad, and encompasses a

variety of sub-problems and goals. The focus of this paper is authentication in

communications, with special emphasis on the related problem of key exchange.

25

2.5.1. Introduction:

The authentication problem has received less attention than secrecy and

privacy issues, especially in the context of cryptographic protocols. Many of the

fundamental works and techniques for the design of cryptographic protocols were

developed under the idealized assumption of authenticated links between the

communicating parties. Prime examples are the Diffie-Hellman key exchange protocol

[DH] as well as much of the work on secure distributed function evaluation (e.g., [Y,

GMW, BGW, CCD]). This abstraction of the authentication problem is of great value

when developing higher level protocols. However, implementing these authenticated

links in realistic environments is far less trivial than one would have initially imagined. In

particular, networks are often asynchronous in nature, and protocols are often message-

driven. Here authentication cannot be achieved by simply applying signatures or message

authentication codes to the transmitted data (although these primitives are useful tools in

the design of complete solutions).

Generally authenticators treated each message separately. Such

authenticators are not suited for authentication of a large number of messages exchanged

between two parties since they involve a costly public-key operation (i.e., encryption,

decryption, signature or verification) per message. When transmitting many messages

between two parties the following approach is usually taken: first have the parties engage

in a key exchange protocol, where they obtain a common key known only to the two

parties. Next, authenticate each message between the parties using a standard symmetric

key message authentication (MAC) algorithm under the exchanged key. MAC

performance is usually several orders of magnitude faster than the public key related

operations. (In addition, some extra measure is needed in order to avoid replay of

messages. This can be done through a shared state between the parties).

2.5.2. Model:

This authentication technique involves the use of secret key to generate a

small fixed size block of data. This assumes that two communicating parties say A and B,

share a common secret key K. When A has a message to send to B, it calculates the MAC

as a function of the message and the key: MAC=Ck (M).

26

The message plus MAC are transmitted to the intended recipient. The

recipient performs the same calculation on the received message, using the same secret

key, to generate a new MAC. The received Mac is compared to the calculated MAC. If

we assume only the sender and the receiver know the identity of secret key, and if the

received MAC matches the calculated MAC, then

1. The receiver is assured that the message has not been altered .If an

attacker alters the message but does not alter the MAC, then the receiver’s

calculation of the MAC will differ from the received MAC. Because the

attacker is assumed not to the alterations in the message.

2. The receiver is assured that the message is from the alleged sender.

Because no one else knows the secret key, no one else could prepare a

message with a proper MAC.

3. If the message includes a sequence number, then the receiver can be

assured of the proper sequence because an attacker cannot successfully

alter the sequence number.

2.5.2.1. MAC algorithm:

Let M be the message .It is the concatenation of some 64-bit blocks of

data. And the key in it is arranged as 56-bit data and the remaining bits of total 64-bits are

MAC bits.

Then we define

∆(M)=X1 X2 ………. Xm.

Ck(M)=E k (M).

where is the exclusive OR(XOR) operation. Thus, the key length is 56 bits and the

MAC length is 64 bits. If the opponent observes [M || CK(M)], a brute force attempt to

derive K will require at least 256 encryptions .

The algorithm is as follows,

The data to be authenticated is grouped into contiguous 64-bit blocks:

D1,D2,………,DN. If necessary, the final block is padded on the right with zeroes to form

a full 64-bit block. Using the standard DES algorithm in which encryption involves 5

stages ,an initial permutation, a complex function(involves permutation and substitution

27

operations depends on key input), a simple permutation that switches two halves of data,

the complex function again, the inverse of initial permutation , we define this as follows.

Let us take this encryption algorithm as E, and a secret key K, a data authentication

code(DAC) is calculated as follows:

O1=EK (D1)

O2=EK (D2 O1)

O3=EK (D3 O2)

.

.

.

ON=EK (DN ON-1)

The DAC consists of either the entire block ON or the left most M bits of the block with

16 <= M <= 64.

2.5.3. Draw back:

But the opponent can attack the system by replacing X 1 through Xm-1 with

any desired values Y1 through Ym-1 and replacing Xm with Ym where Ym is calculated as

follows.

Ym=Y1 Y2 …….. Ym

The opponent can now concatenate the new message, which consists of Y1 through Ym,

with the original MAC to form a message that will be accepted as authentic by receiver.

With this tactic, any message of length 64*(m-1) bits can be fraudently inserted.

2.5.4. Approach to this drawback:

Thus, in assessing the security of a MAC function, we need to consider the

types of attacks that may be mounted against it. With that in mind, let us state the

requirements for MAC function. Assume that opponent knows the MAC function C but

does not know K. Then, the MAC function should have following properties.

1. If an opponent observes M and CK(M), it should be computationally infeasible for

the opponent to construct a message M1 such that Ck(M1) = Ck(M).

28

2. Ck(M) should be uniformly distributed in the sense that for randomly chosen

messages, M and M1, the probability that Ck(M)=Ck(M1) is 2-n, where n is the

number of bits in the MAC.

3. Let M1 be equal to some known transformation on M.That is, M1=f(M). For

example, f may involve inverting one or more specific bits. In that case, no.of

permutations in CK(M) and CK(M1) are equal and is 2-n .

Property 1 specifies to this example that an opponent is able to construct a new message

to match a given MAC, even though the opponent does not know and does not learn the

Key.

Property 2 deals with the need to thwart a brute-force attack based on chosen plain text.

That is, if we assume that the opponent does not know K but have to access to the MAC

function and can present messages for MAC generation, then the opponent could try

various messages until finding one that matches the given MAC. If the MAC function

exhibits uniform distribution, then a brute-force method would require, on average, 2 (n-1)

attempts before finding a message that fits a given MAC.

Property 3 specifies that the authentication algorithm should not be weaker with respect

to certain parts or bits of the message than others. If this were not the case, then an

opponent who had made M and CK (M) could attempt variations on M at the known

weak spots with the likelihood of early success at producing new message that matched

the old MAC.

Hence, messages are transmitted authenticatedly by MAC.

Hence, the papers on the authentication and key agreement and the

research works before this is shown and in the upcoming chapter we come with an

approach based on these ideas.

29

30

3.1 Introduction:

Secure group communication is an increasingly popular research area

which has been receiving much attention in recent years. As a rapid growth of the

internet, the group communication has become an important feature of the internet

technology. Computer network group communication is a group of people who

communicate (or) make a conference in an interactive procedure through the computers

connected by networks at distance or discrete location. In order to establish a secured,

fault-tolerant communication among groups in an open network, the current internet

protocols do not come into needy. 

Conferencing in IP network, through group communication, is actually

transmitting data as broadcast through multiple channels. Group communication is more

complicated with regard to the concept of security .As the group starts to mutate

(members leave and join at any interval of time), the members of group are not a well

defined entity. Hence, security services in group communication or multicast groups are

complicated issues to be dealt. 

Here we proposes a session based security model SSGCP (Secured

Session based Group Communication Protocol), which provides security from

establishing a session to the closure (end) of session. Secured session is established for

variable time slot dynamically among all conference members, implemented by Common

Conference Agreement (CCA) methods. The conference member here after called as

“Conferee”. Secured group communication among multiple conferees can be established

only if a conferee handles the secured key for each session.

Security communication needs to have a conference key agreement for the

group communication. Conference key arrangement is a mechanism in which a shared

conference key is derived by “conference key engine” which is exchanged among

conferee group members who participate in conference. Each conferee member will

acknowledge all other conferees, while the conferee “registry” in member system will

either accept the key or reject the key. SSGCP protocol follows distributed service

31

architecture, which is designed to be one of the components for secured publish /

subscribe and exchange communication infrastructure.

This work is suitable only for honest group of users but not for malicious

users or who intentionally attempt to delay or destruct the conference. An active attack

(malicious participant) tries to disturb establishment of a common conference key among

the group of honest participants. Passive attacks are carried out on gathering the

conference key by listening to the communication of participants.

This protocol works on the basis of only proper secret keys agreed

between honest conferees. Here we are identifying an efficient security key by group key

agreement method. The model and design, that have been developed using simple key

exchange “Diffie-Hellman” algorithm. This work suggests a simple scheme of 2-way

Diffie-Hellman (2DH) method and against n-party Decisional Diffie-Hellman (nDH)

problem.

32

3.2. Problem Description

3.2.1. Diffie-Hellman Key Exchange - A Non-Mathematician's

Explanation:

The Diffie-Hellman algorithm, introduced by Whitfield Diffie and Martin

Hellman in 1976, was the first system to utilize “public-key” or “asymmetric”

cryptographic keys. The systems overcome the difficulties of “private-key” or

“symmetric” key systems because key management is much easier. In a symmetric key

system, both sides of the communication must have identical keys. Securely exchanging

those keys has always been an enormous issue.

Asymmetric key systems alleviate that issue because they use two keys –

one called the “private key” that the user keeps secret and one called the “public key” that

can be shared with the world. Unfortunately, the advantages of asymmetric key systems

are overshadowed by speed – they are extremely slow for any sort of bulk encryption.

Today, it is typical practice to use a symmetric system to encrypt the data and an

asymmetric system to encrypt the symmetric keys. That is precisely what Diffie-Hellman

is capable of doing – and does do when used for key exchange as described here.

3.2.1.1. Exchanging their public keys:

Diffie-Hellman accomplishes this secure exchange by creating a “shared

secret” (sometimes called a “key encryption key”) between two devices. The shared

secret then encrypts the symmetric key for secure transmittal. The process begins when

each side of the communication partner generates a private key .Each side then generates

a public key which is a derivative of the private key. The two systems then exchange their

public keys. Each side of the communication partner now has their own private key and

the other systems public .

33

figure: 3.1

Noting that the public key is a derivative of the private key is important –

the two keys are mathematically linked. However, in order to trust this system, you must

accept that you cannot discern the private key from the public key. Because the public

key is indeed public and ends up on other systems, the ability to figure out the private key

from it would render the system useless. This is one area requiring trust in the

mathematical experts. The fact that the very best in the world have tried for years to

defeat this and failed bolsters my confidence a great deal.

Here we should also explain the box labeled “Optional: CA Certifies

Public Key”in the figure 3.1. It is not common, but the ability does exist with the Diffie-

Hellman protocol to have a Certificate Authority certify that the public key is indeed

coming from the source you think it is. The purpose of this certification is to prevent Man

in the Middle (MIM) attacks. The attack consists of someone intercepting both public

keys and forwarding bogus public keys of their own. The “man in the middle” potentially

intercepts encrypted traffic, decrypts it, copies or modifies it, re-encrypts it with the

bogus key, and forwards it on to its destination. If successful, the parties on each end

would have no idea that there is an unauthorized intermediary. It is an extremely difficult

34

attack to pull off outside the laboratory, but it is indeed possible. Properly implemented

Certificate Authority systems have the potential to disable the attack.

3.2.1.2. Generation of identical cryptographic key:

Once the key exchange is complete, the process continues. An important feature

of the Diffie-Hellman protocol is its ability to generate “shared secrets” – an identical

cryptographic key shared by each side of the communication. Below figure depicts this

operation with the “DH Math” box (trust me, the actual mathematical equation is a good

deal longer and more complex). By running the mathematical operation against our own

private key and the other side’s public key, we generate a value. When the distant end

runs the same operation against your public key and their own private key, they also

generate a value. The important point is that the two values generated are identical.

35

figure: 3.2

At this point, the Diffie-Hellman operation could be considered complete.

The shared secret is, after all, a cryptographic key that could encrypt traffic. That is very

rare however. The reason being that the shared secret is, by its mathematical nature, an

asymmetric key. As with all asymmetric key systems, it is inherently slow. If the two

sides are passing very little traffic, the shared secret may encrypt actual data. Any attempt

at bulk traffic encryption requires a symmetric key system such as DES, Triple DES,

IDEA, CAS T, Blowfish, etc.

3.2.1.3. Encrypting, Passing, and Decrypting the Symmetric Key:

In most real applications of the Diffie-Hellman protocol (IPSec in

particular), the shared secret encrypts a symmetric key for one of the symmetric

algorithms, transmits it securely, and the distant end decrypts it with the shared secret.

Below figure depicts this operation. Because the symmetric key is a relatively short value

as compared to bulk data, the shared secret can encrypt and decrypt it very quickly.

Speed is not so much of an issue with short.

Which side of the communication partner actually transmits the symmetric

key varies. However, it is most common for the initiator of the communication partner to

be the one that transmits the key.It is an obviously important task since both sides of

communication partner must support the same schemes for encryption to function.

36

Figure: 3.3

3.2.1.4. Encrypted Data Transmission:

Once secure exchange of the symmetric key is complete (and note that passing that

key is the whole point of the Diffie-Hellman operation), data encryption and secure

communication partner can occur. Below figure depicts data encrypted and decrypted on

each end of the communication partner by the symmetric key. Note that changing the

symmetric key for increased security is simple at this point. The longer a symmetric key

is in use, the easier it is to perform a successful cryptanalytic attack against it. Therefore,

changing keys frequently is important. Both sides of the communication partner still have

the shared secret and it can be used to encrypt future keys at any time and any frequency

desired.

The use of Diffie-Hellman greatly reduces the headache of using symmetric key

systems. These systems have astounding speed benefits, but managing their keys has

always been difficult to say the very least.

37

Figure: 3.4

3.2.2. A Brief Introduction of Diffie-Hellman Mathematician’s

Approach:

Here we will see how to communicate with shared key. Let us assume the

communication partners are Alice and Bob systems. The Diffie-Hellman algorithm

depends for its effectiveness on the difficulty of computing discrete logarithms.

For our authentication protocol, we will assume that Alice and Bob already share

a secret key, KAB.

This protocol is based on a principle found in many authentication protocols:

One party sends a random number to other,who then transforms it in a special way and

then returns the result.Such protocols are called challenge-response protocols.In this

protocol the following notation will be used:

A, B are identities of Alice and Bob systems.

Ri’s are challenges,where subscript identifies the challenger.

Ki are keys,where I indicates owner.

Ks is the session key.

38

Figure: 3.5

In above figure 3.5 initially Alice sends her identitity A to Bob in a way

that Bob understands. Bob of course, has no way of knowing whether this message came

from Alice or from Trudy,so he chooses a challenge,a large random number RB and sends

It back to “Alice” as in plaintext.Random numbers used just once in challenge-response

protocols like this one are called nonces. Alice then encrypts the message with the key

she shares with Bob and sends the cipher text, KAB(RB), back to Bob. When Bob sees this

message, he immediately knows that it came from Alice because Trudy does not know

KAB and thus could not have generated it.Furthermore,since RB was chosen randomly

from a large space,it is very unlikely that Trudy would have seen RB and its response

from an earlier session.It is equally unlikely that she could guess the correct response to

any challenge.

At this point, Bob is sure that he is talking to Alice, but Alice is not sure of

anything. For all Alice knows, Trudy might have intercepted identity of Alice A and sent

back RB in response.May be Bob died last night. To find out to whom she is talking,

Alice picks a random number, RA and sends it to Bob as plaintext. When Bob responds

with KAB (RA), Alice knows she is talking to Bob. If they wish to establish a key

now,Alice can pick one, KS ,and send it to Bob encrypted with KAB.

3.2.2.1. Working principle of Diffie-Hellman algorithm:

39

A

RB

KAB (RB)

RA

KAB (RA)

ALICE SYSTEM BOB SYSTEM

Alice and Bob have two large numbers, p and g ,where n is prime ,(p-1)/2

is also a prime and certain conditions apply to g. These numbers may be public, so either

one of them can just pick p and g or tell the other openly. Now Alice picks a large

number, a and keeps it secret. Similarly Bob picks a large number, b and keeps it secret.

Alice initiates the key exchange protocol by sending a message

containing (p, g, ga mod p)to Bob. Bob responds to Alice by sending a message

containing gb mod p .Now Alice calculates (gb mod p)a mod p by raising the number sent

by the Bob to ath power modulo p. Bob performs similar operation to get (ga mod n )b

mod p. By the laws of modular arithmetic, both calculations yield gab mod p. So now

Alice and Bob suddenly share a secret key, gab mod p.

The simplest, and original, implementation of the protocol uses the

multiplicative group of integers modulo p, where p is prime and g is primitive mod p.

Modulo (or mod) means that the integers between 0 and p − 1 are used with normal

addition, subtraction, multiplication, and exponentiation, except that after each operation

the result keeps only the remainder after dividing by p. Here is an example of the

protocol:

Alice

Sec Calc

p, g

a

ga

mod p

…

(gb

mod p)a

mod p =

Bob

Calc Sec

p, g

b

…

gb

mod p

(ga

mod p)b

mod p

1. Alice and Bob agree to use a prime number p=23 and base g=5.

2. Alice chooses a secret integer a=6, then sends Bob (ga mod p)

o 56 mod 23 = 8. 3. Bob chooses a secret integer

b=15, then sends Alice (gb mod p)

o 515 mod 23 = 19. 4. Alice computes (gb mod p)a mod

p o 196 mod 23 = 2.

5. Bob computes (ga mod p)b mod p

o 815 mod 23 = 2.

Both Alice and Bob have arrived at the same value, because gab and gba are

equal. Note that only a, b and gab = gba are kept secret. All the other values are sent in the

clear. Once Alice and Bob compute the shared secret they can use it as an encryption key,

40

known only to them, for sending messages across the same open communications

channel. Of course, much larger values of a,b, and p would be needed to make this

example secure, since it is easy to try all the possible values of gab mod 23 (there will be,

at most, 22 such values, even if a and b are large). If p was a prime of at least 300 digits,

and a and b were at least 100 digits long, then even the best known algorithms today

could not find a given only g, p, and ga mod p, even using all of mankind's computing

power. The problem is known as the discrete logarithm problem. Note that g need not be

large at all, and in practice is usually either 2 or 5.

Here's a more general description of the protocol:

1. Alice and Bob agree on a finite cyclic group G and a generating element g in G.

(This is usually done long before the rest of the protocol; g is assumed to be

known by all attackers.) We will write the group G multiplicatively.

2. Alice picks a random natural number a and sends ga to Bob.

3. Bob picks a random natural number b and sends gb to Alice.

4. Alice computes (gb)a.

5. Bob computes (ga)b.

Both Alice and Bob are now in possession of the group element gab which can serve as

the shared secret key. The values of (gb)a and (ga)b are the same because groups are power

associative.

3.2.2.2. Efficiency:

Here is a chart to help simplify who knows what. (Eve is an eavesdropper

- she watches what is sent between Alice and Bob, but she does not alter the contents of

their communications.)

Let s = shared secret key. s = 2

let a = Alice's private key. a = 6

let b = Bob's private key. b = 15

41

let g = public base. g=5

let p = public (prime) number. p = 23

Hence in the diagram even for very fast compuers like super computers it

will become years together to find out the key.

Alice

knowsdoesn't know

p = 23 b = 15

base g = 5

a = 6

56 mod 23 = 8

5b mod 23 = 19

196 mod 23 = 2

8b mod 23 = 2

196 mod 23 = 8b

mod 23

s = 2

Bob

knowsdoesn't know

p = 23 a = 6

base g = 5

b = 15

515 mod 23 = 19

5a mod 23 = 8

815 mod 23 = 2

19a mod 23 = 2

815 mod 23 = 19a

mod 23

s = 2

Eve

knowsdoesn't know

p = 23 a = 6

base g = 5 b = 15

s = 2

5a mod 23 = 8

5b mod 23 = 19

19a mod 23 = s

8b mod 23 = s

19a mod 23 = 8b

mod 23

It should be difficult for Alice to solve for Bob's private key or for Bob to

solve for Alice's private key. If it isn't difficult for Alice to solve for Bob's private key (or

vice versa), Eve may simply substitute her own private / public key pair, plug Bob's

public key into her private key, produce a fake shared secret key, and solve for Bob's

private key (and use that to solve for the shared secret key. Eve may attempt to choose a

public / private key pair that will make it easy for her to solve for Bob's private key).

3.2.2.3. Drawback in Diffie-Hellman:

42

Trudy of course, an eve has seen both messages .She knows g and p from

message containing g, a, ga mod p. If she could compute a and b, she could figure out the

secret key. But here the trouble is given only ga mod p ,she cannot find a. Because there

is no algorithm for computing large prime number (modulo) is known.

Here, while Alice and Bob are choosing a and b respectively, Trudy picks

her own random number, z. Alice sends message (p, g, ga mod p) intended for Bob. Trudy

intercepts it and sends message (p, g, gz mod p)to Bob, using the correct g and p with

her own z instead of a she also sends message (gz mod p) back to Alice. Later Bob sends

message gb mod p to Alice which Trudy again intercepts and keeps.

Alice computes secret key as g az mod p, similarly Bob computes gbz mod

p Alice thinks she is talking to Bob so she establishes a session key with Trudy. Every

message that Alice sends on the encrypted session is captured by Trudy. Trudy stored,

modified that message and then passed to Bob. Similarly in other direction Trudy sees

everything and can modify all messages while both Alice and Bob are under the illusion

that they have a secure channel to one another. This attack is known as Man-in-the-

middle attack

Picks a Picks z Picks b

Figure 3.6

In cryptography, a man-in-the-middle attack (MITM) is an attack in

which an attacker is able to read, insert and modify at will, messages between two parties

without either party knowing that the link between them has been compromised. The

43

A L I C E

T R U D Y

B O B

p,g, ga mod pp,g, gz mod p

gz mod pgb mod p

Key btw Alice & trudygaz mod p

Key btw Trudy & Bobgbz mod p

attacker must be able to observe and intercept messages going between the two victims.

The MITM attack is particularly applicable to the original Diffie-Hellman key exchange

protocol, when used without authentication.

MITM should be seen as a general problem resulting from the presence of

intermediate parties acting as proxy for clients on either side. If they are trustworthy and

competent, all may be well; if they are not, nothing will be. How can one distinguish the

cases? By acting as proxy and appearing as the trusted client to each side, the

intermediate attacker can carry out much mischief, including various attacks against the

sconfidentiality or integrity of the data passing through it.

3.2.2.3.1.The MITM attack may include one or more of:

Eavesdropping : Suppose Alice wishes to communicate with Bob, and that

Mallory wishes to eavesdrop (just make an eye) on the conversation.(e.g. In

reavealing some confidential information to militants etc…)

Chosen ciphertext attack : depending on what the receiver does with a message

that it decrypts. If Bob sends his public key to Alice, but Mallory is able to

intercept it, a man-in-the-middle attack can begin. Mallory can simply send Alice

a public key for which she has the private, matching, key. Alice, believing this

public key to be Bob's, then encrypts her message with Mallory's key and sends

the enciphered message back to Bob. Mallory again intercepts, deciphers the

message, keeps a copy, and reenciphers it (after alteration if desired) using the

public key Bob originally sent to Alice. When Bob receives the newly enciphered

message, he will believe it came from Alice.

Substitution attack : Man in the middle May arise and subsitute one information

with other inorderto mislead the partner.

Replay attacks : Trudy can reply the same message to the sender.

Denial of service attack . The attacker may for instance jam all communications

before attacking one of the parties. The defense is for both parties to periodically

send authenticated status messages and to treat their disappearance with paranoia.

Phishing : attacks, where victims are duped into entering their details into a proxy

website that imitates a genuine site (e.g., an online bank). By acting as a go-

44

between to the genuine website, the proxy website allows the victims to log in and

conduct business as usual without raising suspicion.

MITM is typically used to refer to active manipulation of the messages, rather than

passively eavesdropping.

All cryptographic systems that are secure against MITM attacks require

an additional exchange or transmission of information over some kind of secure channel.

Here the Replay attack is important one:

3.2.2.3.2. Replay attack:

A replay attack is a form of network attack in which a valid data

transmission is maliciously or fraudulently repeated or delayed. This is carried out either

by the originator or by an adversary who intercepts the data and retransmits it, possibly as

part of a masquerade attack by IP packet substitution (such as stream cipher attack).

Suppose Alice wants to prove her identity to Bob. Bob requests her

password as proof of identity, which Alice dutifully provides (possibly after some

transformation like a hash function); meanwhile, Mallory is eavesdropping the

conversation and keeps the password. After the interchange is over, Mallory connects to

Bob posing as Alice; when asked for a proof of identity, Mallory sends Alice's password

read from the last session, which Bob must accept.

3.2.2.3.3. Reflection attack: Under certain circumstances, Trudy can defeat this

protocol by using reflection attack. In particular Trudy can break it if it is possible to

open multiple sessions with Bob at once. This situation would be true if Bob is prepared

to accept many simultaneous connections from teller machines at once.

The reflection attack is shown in figure 3.7

45

A, RT

RB, KAB (RT)

A, RB

RB2, KAB (RB) KAB (RB)

T R U D Y

B O B

Session 1

Session 2Session 1

Figure 3.7

The reflection attack starts out with Trudy claiming she is Alice and

sending RT Bob responds, as usual, with his own challenge RB. Now Trudy is stuck

because she doesn’t know KAB (RB). Trudy is supplying the RB taken from challenge RB,

KAB (RT) as a message in session 2. Bob calmly encrypts it and send back KAB (RB) as a

response to challenge in session 2.

Again Trudy sends may smash the session 2 and takes KAB (RB) and

responds to the message in session 1.

The attacker initiates a connection to a target.

The target attempts to authenticate the attacker by sending it a challenge.

The attacker opens another connection to the target, and sends the target this

challenge as its own.

The target responds to that challenge.

The attacker sends that response back to the target ("reflects" it) on the first

connection.

A way to avoid replay attacks is using session tokens. Bob sends a one-

time token to Alice, which Alice uses to transform the password and send the result to

Bob (e.g. computing a hash function of the session token appended to the password). On

his side Bob performs the same computation; if and only if both values match, the login

is successful. Now suppose Mallory has captured this value and tries to use it on another

session; Bob sends a different session token, and when Mallory replies with the captured

value it will be different from Bob's computation.

46

Session tokens should be chosen by a (pseudo-) random process.

Otherwise Mallory may be able to guess some future token and convince Alice to use that

token in her transformation. Mallory can then replay her reply at a later time, which Bob

will accept.

Bob can also send nonces but should then include a Message

authentication code (MAC), which Alice should check.

Timestamping is another way of preventing a replay attack.

Synchronization should be achieved using a secure protocol. For example Bob

periodically broadcasts the time on his clock together with a MAC. When Alice wants to

send Bob a message, she includes her best estimate of the time on his clock in her

message, which is also authenticated. Bob only accepts messages for which the

timestamp is within a reasonable tolerance. The advantage of this scheme is that Bob

does not need to generate (pseudo-) random numbers.

3.3 PROPOSED APPROACH:

In order to use different approaches for each and every drawback, we

proposed an approach which gives a single solution to all the problems described above.

In cryptography, a key distribution center (KDC) is part of a cryptosystem

intended to reduce the risks inherent in exchanging keys. KDCs often operate in systems

within which some users may have permission to use certain services at some times and

not at others.

The Key Distribution Center (KDC) is a trusted third party with whom

every entity shares a secret key. This key is called the entity’s master key. All entities

trust the KDC to mediate in their mutual authentication. The KDC also maintains a

centralized authentication database containing a copy of every user’s master key.

A typical operation with a KDC involves a request from a user to use

some service. The KDC will use cryptographic techniques to authenticate requesting

users as themselves. It will also check whether an individual user has the right to access

47

to the service requested. If the authenticated user meets all prescribed conditions, the

KDC can issue permitting access.

KDCs mostly operate with symmetric encryption.

In most (but not all) cases the KDC shares a key with each of all the other

parties.

The key agreement may be given to individual party selection or the KDC itself

may select the key.

Here we are giving acess to selct the key based on individual parties. Hence the selction

is given to communicating parties only. To describe this one party can legally select the

key and deliver to other. This precludes the undesired assymmetric key for exchange. The

selction may be given to KDC togenerate a key. The key on encryption lines is passed to

the parties. There by without the intervention of KDC the parties can continue their

communication confidentially. There by providing effective tool for key sharing.

Figure: 3.8

As, shown in the figure this KDC acts as interface between the sending

and recieiveing partners.

KDC

Receiving mail server

48

Sending mail server

The authentication happens here for free.The KDC knows that the

messages are from right person since its members only know what are the secret keys that

with the KDC and the members. Hence there is no problem for thinking the way the

messages are from right person. If the key is distributed successfully without any break in

the link Authentication is complete.

How the key distribution will be done and how the authentication is achieved is

shown below:

Request grant

for of Ks sent Sending Ks

access request to B encrypted with encrypted Kb

with Ka

Ks(message)

Figure: 3.9

Where

Ks is the session which is created by Alice and send it to KDC.

Ka is the key that is exchanged between KDC and Alice.

Kb is the key shared between KDC and Bob.

49

INITIATOR A (Alice) Responder

B (Bob)

KDC (KEY DISTRIBUTI-ON CENTER)

3.3.1. Steps described in figure is as follows:

Initially Alice system requests that KDC To verify whether KDC is free or

else it is serving the other paries. And it requests to access

After KDC sees the request from Alice, He responds and asks to send the

message

Now Alice will sent the already generated key for the communication with

Bob system. The message is sent encrypted using the key that it distributes

with KDC.

Now, KDC decrypts this message and then it reencrypts the Session key

Ks with the key that it shares with Bob.

Bob after receiving this message decrypts the message

Now both Alice and Bob know the Key and now Bob as an

acknowledgement sends the message to sender with the key he received

from KDC i.e. the so called session key.

3.3.2. Benefits

This KDC will enable the easier session key distribution securely between

the partners. The system also provides scalability that is the system is capable of

supporting large numbers of clients and servers and this also supports a modular

distributed architecture.

3.3.3. Drawbacks

The first drawback with key distribution center is that every body must

trust on KDC that it is not an intruder but the right one. Another one is that KDC can

become the single point of failure. i.e. if the intermediate system is lost there is no way of

sending and receving of session key between the parties.

However, there is a great approach to this drawbacks. It is not necessary to

limit this key distribution function to a single KDC. To increase the reliability let us

50

increase the availability.Keep the replication KDC if atall the system is creas we can

connect the communicating systems to just that replicating KDC.

Indeed, for very large networks, it may not be practical to do so. As an

alternative a hierarchy of KDCs can be established. For example, there can be local

KDCs, eah responsible for small domain of the overall internetwork, such as single LAN

or a single building. For communication among the entities within the same local domain,

the local KDC is responsible for key distribution. If two entities in different domains

desire a sherd key, then the corresponding local KDCs can communicate through global

KDC. In this case, any one of three KDCs involved can actually select the key. This

hirerarchical concept can be extended to the three or even more layers, depending on the

size of the user population and the geographic scope of internetwork.

A hierarchical scheme minimizes the effort involved in master key

distribution, because most master keys are those shared by a local KDC with its local

entities. Furthermore, such a scheme limits the damage of a faulty or subverted KDC to

its local area only.

The more frequently the session keys are exchanged, the more secure they

are, because the opponent has less ciphertext to work with for any given session key. On

the other hand, the distribution of session keys delays the start of any exchange and

places a burden on network capacity. A security manager nmust try to balance these

competing considerations in detrmining the lifetime of a particular session key.

For connection-oriented protocols, one obvious choice is to use the same

session key for length of time that the connection is open, using a new session key for

each new session. If a logical connection has very long lifetime, then it would be prudent

to change the session key periodically, perhaps every time the PDU (Protocol data unit)

sequence number cycles.

For a connectionless protocol, such as a transaction-oriented protocol,

there is no explicit connection iniitation or termination. Thus, it is not obvious how often

one needs to change the session key. The most secure approach is to use a new session

51

key for exchange. However, this negates one of the principal benefits of the

connectionless protocols, which is minimum overhead and delay for each transaction. A

better stategy is to use a given session key for a certain fixed period only or certain

number of transactions.

3.3.4 KDC with RSA

As KDC is a symmetric key encryption algorithm, here we go for public key encryption

of symmetric key. RSA algorithm was proposed by Rivet, Shamir, Adleman. The RSA

message or key encryption provides good security even with small bit key sizes.

Steps in RSA:

1. Choose two Prime numbers say p, q

2. We have to compute n=(p*q) and z=n-p-q+1.

3. We have to choose a number ‘d’ such that z and d should have no factors in

common

4. Find number ‘e’ such that e*d=1 mod z (or) (e*d) mod z=1.

Encryption with RSA:

1. Let the plain text be P and it is encrypted with RSA as C=Pe mod n where C is

the cipher text.

2. And the decryption will be P=Cd mod n where P is our normal plain text.

3. Here in KDC we are using that the partners share with KDC as ka and kb.

4. These ka and kb are not actually the single keys, but are key pairs.

5. One can indicate its key with KDC as p, q in RSA.

Encrypting messages after receiving key ks either from DH algorithm or from KDC:

1. Here we use one of the Caesar cipher called substitution cipher.

2. That is substituting one set of letters with i.e. symbol-by-symbol substitution.

3. This substitution takes an order and this order is based on our session key ks.

52

4. Hence, trudy by brute force can have 36! i.e. 4*1036 Possibilities(26 for alphabets

& 10 for digits).

Applications:

1. Banking applications, Airlines, Business applications

2. E-mail security, Military applications, mobile code security but with hardware

equipped chip, etc----.

53

54

4.1 Technology to be used:

Communication between the computers in a network or a different

network requires certain set of protocols. These protocols are very much and very

efficient in java. Java applets can be downloaded from website and this is one of the

main attractions of java.

4.1.1. Why networking in java?

Java is the first language to provide such a powerful platform network

library that handles all the diverse tasks such as

Browsing pages on web

Parsing and rendering HTML

Sending e-mail with SMTP

Receiving E-mail with POP and IMAP

Writing multithreaded servers

Installing a new protocol and content into browsers

Encrypting communications for confidentiality, Authentication, and

guaranteed message integrity

Designing GUI clients for network services

Posting data to CGI programs

Looking up hosts using DNS

Downloading files with anonymous FTP

Connecting Sockets for low-level network communication

Distributing applications across multiple systems with Remote Method invocation

Java Network Programming exposes the power and sophistication of these

class libraries. Together these features the other java features allow web surfaces to

quickly download and execute untrusted programs from a website without worrying that

55

the program may spread virus, steal the other data, or crash their systems. Indeed, the

intrinsic safety of java applet is far greater than that of a shrink-wrapped software.

What makes java a good language for networking are the classes that

defined in the java.net package.

Every computer connected to the network has a unique IP address. It is

similar to every student of a batch having a unique id. An IP address is a 32-bit number

which has four numbers separated by periods.

InetAddress is one of the classes in java.net package and this is used to

encapsulate the IP address and DNS.

Obtaining InetAddress of system:

import java.net.*;

class InetAddressTest{

Public static void main(String args[])

{

try

{

InetAddress add=InetAddress.getLocalHost();

System.out.println(“address of local Host is:” +add);

}catch(unknownHostException u){}

}

}

After running this will give the output which is the IP address of the

system in which this program is executed.

For e.g. it gives as: grd-32/80.0.0.32.

After obtaining the InetAddress of a machine, a DatagramPacket, which is

a data container, will specify the data and the DatagramSocket class which contain the

send and receive methods will take the data on the network.

DatagramPacket(byte data[], int size, InetAddress I, int port) -The above

constructor specifies the the data to be sent or receive in byte array, its size i.e.

56

data size , InetAddress of the system and the port specifying whether it is

client or server port.

DatagramSocket class contains send and receive methods

DatagramSocket s=new DatagramSocket(int port)

Methods in this class are handled by object(s).method name

1. send (DatagramPacket d) –Dispatches the given DatagramPacket

object.

2. receive (DtagramPacket p)-Receives the given DatagramPacket

object.

3. close()-closes the socket connection)

We also wish to use HTML pages as the front end for the part for just

taking the input and giving the output.

4.2 Hardware and software requirements:

4.2.1. H/w Requirements:

In our project the system requires Pentium IV processor with 2.66 GHz ,

5GB Hard Disk and 256 MB RAM. Like this we wish three systems to send and

receiving of messages. Additionally we want a typical LAN for connecting all these

systems.

4.2.2. S/w Requirements:

The Operating System required for our project is WINDOWS 9X/ XP and

the languages we use are Java and Html. The version of java required is JSDK,

Networking packages

4.3 Unified Modelling Language Design:

As the complexity of systems increases, so does the importance of good

specification and modeling techniques. Many factors contribute to the success of a

project, and certainly one we cannot do without is a rigorous modeling language

standard. Introduced in recent years, the Unified Modeling Language (UML) is now

57

widely used, basically for requirements specification and for the design of complex

software systems and also embedded systems. A few months ago, a new community was

created, called UML-SoC. In the present paper we describe the use of UML for

specification and modeling of the security and communication aspects of network system,

Through UML we describe security issues such as data integrity, data confidentiality, and

authentication

UML design USE case diagram for the whole system

(User View of the System)

<<Communicates>>

Transmitting the key

Receiver

KDC

58

Send key

information Collect the data

Sender

Sender

Use case diagram for sending key:

Explanation: Generally the actors specified are not actually the external actors to the

system but they are typically the backup systems that included in the whole project.

Hence, Sender, Receiver and KDC are back up systems. First the sender will select a

random number and based on the random number the key will be generated and this is

passed to KDC which is encrypted with the key that it shares with KDC. Hence, as shown

in the figure above sender will perform these set of actions. The rectangle enclosing the

use cases will specify the boundary of the system.

Select a Random number

Generate key based on number

Send to KDC by encrypting the key, source, destination with the key it

shares with KDC

KDC

59

Use case diagram for Collecting key:

Receiver

Explanation:

In the above diagram the actor is the back up system which collects the

data. The use cases specify the list of actions that are receiving the information,

decrypting the message and acknowledging the sender. These are the sequential actions

that are carried out by the collector.

60

Receive the information

Decrypt the information by using the key it shares with KDC

Acknowledge the sender

KDC

Use case diagram for Transmitting key:

Explanation:In this the actor is again the backup system which is referred as KDC in

the above diagram. Hence the sequence of actions carried out by this actor is specified in

the use cases as receiving the information from sender, decrypting the information again

encrypting the information to send to receiver, and sending it to receiver. Hence, the

system is connected with the other actors of sender and receiver.

61

KDC

Receive information

Decrypt information

Encrypt it with the key that shares with receiver

Send this to receiver

SenderReceiver

Detailed project Class Diagram:

(Structural View of the System)

Acknowledges

1 ..1

..1 1

62

Initiate

- skey, akey : Integer

+ generate();(skey:integer)

+encrypta();(akey:integer)

+send();(skey,akey :integer) (predefined func)

Respond

- skey, bkey : Integer

+receive();(skey,bkey :integer)

(predefined func)+decryptb();(bkey:integer)

+acknowledge(skey:integer)

Transmit

- skey, akey, bkey: Integer

+ receive(); (skey, akey : integer) (predefined func)+ decrypta(); (akey : integer)

+ encryptb(); (bkey : integer)

+ send(); (skey, bkey : integer) (predefined func)

Explanation: This diagram gives the Structural view of the system. It contains classes to

define the main modules of the system. The classes defined here are the Initiate, Respond

and Transmit and they defines

Initiate class:

Declares data members (skey, akey)

skey – specifies the session key with which the communication is possible

between the sender and receiver.

akey - specifies the key which is shared between KDC and Sender.

These are preferably integer variables.

And Defines Methods

generate()- which generates the skey from random number

encrypta()- which defines procedure for encrypting skey with the akey.

send()-A predefined function in the language.

Respond class:

Declares data members(skey, bkey)

bkey- specifies the key which is shared between KDC and Receiver. Which is an

integer

and defines methods

decryptb()- which defines the procedure for decrypting skey from bkey.

acknowledge()- which defines the procedure for sending acknowledgement to

sender with skey.

receive()-A predefined function in the language.

Transmit class:

Declares data members (skey, akey, bkey)

Defines the methods

decrypta()- which defines the procedure for decrypting skey from akey.

63

encryptb()-which defines procedure for encrypting skey with the bkey.

send(), receive()- predefined functions of language.

In addition there exists 1-1 relation among classes

Sequence diagram for Sending key:(Behavioral View of the System)

s: Sender

:

: : : : : : Select a random number : : Number given : : : Generate : : skey : : : : : : : :

Request (Ready to send)

If not granted

: Waiting : Again make request

If not granted

If granted

Encrypt with akey

64

: Task Random selector

Sender win k: KDC Interface

: : : :

: :

Sequence diagram for collecting key:(Behavioral view of system)

r: Receiver

: : : : : : Message from KDC : :

::

: Decrypt : : bkey : :

: : : : Analyze :

skey ::

: : : :

Acknowledge skey

: : : :

65

Receiver win k: KDC interface

Receiver win s: Sender Interface

Sequence diagram for Transmitting key:(Behavioral view of the System)

k: KDC

:

: : : : : Message from Sender : :

::

: Decrypt : : akey : :

: : : : Analyze :

skey ::

: : : : : Encrypt :

bkey ::

: : : Message with bkey :

: : : : : : :

66

KDC win s : Sender interface

KDC win r : Receiver Interface

Explanation:

For sending Key:

There is an object “s” for sender and this describes the sequence of

messages and the task of sender.

First the Random selector class will select the Random number and generate the

session key based on the number.

The one headed arrow indicates one flow of statement. Then the sender requests

the KDC. If the request is not granted it waits.

Again the sender makes the request, and the cycle is repeated until the request is

granted

After granting the sender will send the key which contains the sender, receiver’s

identification which is encrypted with akey.

For collecting Key:

Here “r” is the instance of the receiver and it includes both sender and

KDC interfaces. The sequence of actions here here are:

After receiving the message with the arrow mark indicated, the message is

decrypted with bkey at receiver station itself. Hence it is denoted as the arrow

pointing to itself.

Then analyze the skey from the resultant message.

Acknowledge the sender with the skey shown as pointing arrow to sender

interface.

For transmitting Key:

Here “k” is the instance of KDC and it also includes both sender and

receiver interface objects.

After receiving the message with the arrow mark indicated, the message is

decrypted with akey at KDC station itself. Hence it is denoted as the arrow

pointing to itself.

67

Then analyze the skey from the resultant message.

Send the skey taken, to the receiver encrypted with the akey shown as pointing

arrow to receiver interface.

Detailed project Deployment Diagram:(Environmental View of the System)

68

A typical LAN

KDC asServer OrDesktopClient

Receive key (Executable)

Send key (Executable)

SenderAsDesktopClient

Send Key (Executable)

ReceiverAsDesktopClient

Receive Key (Executable)

Explanation:

In this there are three hardware devices that are to be connected.

Machine 1: (Sender): A computer system (Node) which acts as sender.

The sender is the client. This is represented as a cuboid box. The main

module in this is given as the component enclosed in a rectangle embedded other two

small rectangles. The main function of sender is given in that rectangle box i.e. send key

which is an executable function.

Machine 2: (Receiver): A computer system (Node) which acts as Receiver.

The Receiver is also client. This is represented as a cuboid box. Here also

the main module in this is given as the component enclosed in a rectangle embedded

other two small rectangles. The main function of Receiver is given in that rectangle box

i.e. receive key which is an executable function.

Machine 3: (KDC): A computer system (Node) which acts as KDC.

The KDC is a two way machine. This is represented as a cuboid box. It

may act as either client or server. It takes the Server role when it grants for the request of

sender and the same machine will act as client when it asks request for receiver. Here

also the main modules in this are given as the components enclosed in two rectangles

embedded other two small rectangles. The main function of KDC are given in that

rectangle boxes i.e. receive key from sender where it acts as serve which is an executable

function and the other is send key to receiver where it acts as client which is also an

executable function.

In addition to the above the other hardware requirement is:

LAN – A Local Area Network, This is used for interconnection of all these

Nodes. This establishes the connection and is used for passage of messages

between the nodes.

69

Detailed project Activity diagram:(Behavioral View of the system)

Initial state

Sender state of action

No

Yes

70

Select random number

Generate key based on random number

Request to KDC

Granting

request

Send encrypted message akey to KDC

A

KDCaction state

Receiver action state

71

A

Receive message from sender

Decrypt akey

Analyze skey

Encrypt with bkey of Responder

Send message to Receiver

Receive message from KDC

Decrypt bkey

Acknowledge sender (skey)

Final state

Explanation: Activity diagram represents the behavioral View of the system. This is

similar to the flow chart since it represents the sequence of actions that are represented in

the vowel shapes. It also contains an initial state which is represented as a darken circle in

the figure. Here also the whole system is divided into 3 phases

1. Sender state of action : This includes selection of number, generating key,

encrypting it with key of KDC and sending to KDC. All these are the actions that

are performed by the sender. Hence, the system upto this case is represented as

sender side function i.e. talking in the name of sender.

2. Transmitter state of action : This includes receiving message from sender,

decrypting the message, analyzing the key, again encrypting the message it shares

with receiver and sending to receiver. Hence, the system upto this case is

represented as Transmitter side function i.e. talking in the name of KDC.

3. Receiver state of action : This includes receiving message from KDC, decrypting

the message, analyzing the key, acknowledging the sender by encrypting the

message with the key it received from KDC. Hence, the system upto this case is

represented as Responder side function i.e. talking in the name of Receiver.

Then the sender and receiver can continue the messages with this key.

And then a final state is evaluated which is represented as darken circle enclosed within a

ring and this state tells there is no further message communication between the systems.

72

Detailed project State chart diagram: (Behavioral view of the system)

Select Random Generate Number skey (Event 1) (Event 2)

Initial State

Decrypt Encrypt bkey (Event 4)

akey (Event 3)

Acknowledge (Transition)(Event 6)(Transition)

Encrypt bkey (Event 5) (Transition)

Final state

Explanation: This also gives the behavioral view of the system. In this there are states

and events or transitions. State represent the current location of the system i.e. at this time

73

Intermediate state (Transmitter)

Target state (Responder)

Source state (Initiator)

at what position the system is at ? And Event or transition represents, upon the

occurrence of which event the system changes from one state to the other.

Initially the system starts at initial state and moves to source state. The system at this

state performs 2 transitions i.e. selection of random number and generation these events

do not cause a change of state and the system is in source state itself. Upon the

occurrence of Encryption with akey the system moves to Intermediate state. In this on the

occurrence of events decryption and analyzing key the system will have no transition to

next state, it still stays in the intermediate state itself. In this after occurring the event

encryption it moves to the target state and then to finish state.

In this the states are represented by rounded rectangles and events are by

arrows.

Detailed project Collaboration diagram: (Behavioral view of the system)

1. Sender, Receiver identification 2. Acknowledgement encrypted with ks

<<global>>

1: Sender, Receiver Identification 2: Session key encrypted with key ka

<<global>> <<global>>

1. Sender, Receiver Identification 2. Session key encrypted with key kb

74

S : Sender

K : KDC R : Receiver

Explanation: This represents the behavior of the system in a way that flow control can

be specified in the context of structural organization of objects that collaborate. Here path

is specified to show how the one object is linked to other. At the end the path has

stereotype to the far end of the link <<global>> indicating that the designated object is

globally accessible to sender. The diagram also includes the sequence numbers to specify

the time ordering of messages which prefix the message with a number.

75

76

5.1 Calculating Prime numbers between 10000 and 30000:

import java.io.*;

public class sw{

public static void main(String args[])throws Exception{

int x[]=new int[30000];

int i,j,l,flag,k;

for(i=10001,k=0;i<29997;i=i+2){

flag=1;for(j=2;j<i;j++){

if(i%j==0){

flag=0;break;

}}if(flag==1){

x[k]=i;k++;

}}for(i=0;i<k;i++){

System.out.print(x[i]+"\t");}System.out.println("\n\n\nNo. of numbers:"+k);

}}

77

5.1.1 Implementing Diffie Hellman on side A:

import java.io.*;import java.net.*;

public class skey{

public static void main(String args[])throws IOException{

int i,q,j=0,k,l,g,a,u=0;int p;

int y[]=new int[800];int b[] =new int[800];int x1[]=new int[800];int b1[] =new int[800];char ch;String s1="",s2="",s3="";int port = 800,clientPort=900;byte[] buffer = new byte[10240];

// Taking Input g and n:

DataInputStream d=new DataInputStream(System.in);System.out.println("enter g");String msg=d.readLine();System.out.println("enter n:");String msg1=d.readLine();int x=Integer.parseInt(msg1);int z=msg.length();

//Converting into individual bits:

for(i=z-1,k=0;i>=0;i--,k++){

y[k]=msg.charAt(i)-48;

}int n=Integer.parseInt(msg);k=0;

//Caluculation for g x :

for(i=0;i<n;i++)

78

{for(j=0;j<z;j++){

l=b[j]+y[j]+k;k=0;if(l>=10){

b[j]=l-10;k=1;

}else

b[j]=l;}if(k==1){

b[j]=1;z++;k=0;

}

}a=b[j-1];

//Caluculation for g x mod n:

for(i=j-2;i>=0;i--){

a*=10; a+=b[i]; u=a; if(a>=x) {

u=a%x;a=u;

}}System.out.println(u);while(u!=0){

switch(u%10){

case 0: s1+='0';break;

case 1: s1+='1';break;

79

case 2: s1+='2';break;

case 3: s1+='3';break;

case 4: s1+='4';break;

case 5: s1+='5';break;

case 6: s1+='6';break;

case 7: s1+='7';break;

case 8: s1+='8';break;

case 9: s1+='9';break;

}u=u/10;

}

System.out.println(s1);

for(i=s1.length()-1,k=0;i>=0;i--,k++){

s2+=s1.charAt(i);}s2+='\0';

//Sending to B :

System.out.println(s2);InetAddress ia = InetAddress.getByName("131.200.3.68");System.out.println(ia);DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);

String send = "g="+msg+",n="+msg1+",gXmodn="+s2;System.out.println(send);buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,clientPort);ds.send(dp);

System.out.println("message sent");

//Receiving g y mod n from B:

80

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);

String msg2 = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " +msg2);

String str="";

for(i=0;i<msg2.length();i++){

if(msg2.charAt(i)=='='){

for(j=i+1;j<msg2.length();j++){

str+=msg2.charAt(j);}a=Integer.parseInt(str);break;

}}

z=str.length();for(i=z-1,k=0;i>=0;i--,k++){

x1[k]=str.charAt(i)-48;

}

p=k-1;k=0;int y1=3;

//Caluculation for (g y mod n ) x mod n:

for(i=0;i<a;i++){

for(j=0;j<=p;j++){

l=b1[j]+x1[j]+k;k=0;if(l>=10){

81

b1[j]=l-10;k=1;

}else

b1[j]=l;}if(k==1){

b1[j]=1;p++;k=0;

}

}

p=b1[j-1];

for(i=j-2;i>=0;i--){

p*=10; p+=b1[i]; if(p>=x) {

u=p%x;p=u;

}}System.out.println("\nShared key must be:"+u);

}}

5.1.2 Implementing Diffie Hellman on side b:

import java.io.*;import java.util.regex.*;import java.lang.*;import java.util.*;import java.net.*;class sd{

public static void main(String args[])throws IOException{

//Receiving n, g, g x mod n from A

82

int port = 900,serverPort = 800;byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));InetAddress ia = InetAddress.getByName("131.200.3.69");DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);

int i,k,g,n,z,p,j,l,u,q,y,n1;j=0;l=0;u=0;int a[]=new int[40];int x[]=new int[800]; int b[] =new int[800];int c[]=new int[800];

sd m=new sd();

//Splitting the string received from A:

Pattern pat=Pattern.compile("[,]");String strs[]=pat.split(msg);

for(i=0;i<strs.length;i++){

for(j=0;j<strs[i].length();j++){

String str="";if(strs[i].charAt(j)=='='){

for(k=j+1;k<strs[i].length();k++){

str+=strs[i].charAt(k);

}System.out.println(str);a[l]=m.thro(str);System.out.println(a[l]);

83

l++;break;

}}

}

g=a[0];n=a[1];n1=a[2];z=strs[0].length();for(i=z-1,k=0;i>=2;i--,k++){

x[k]=strs[0].charAt(i)-48;

}p=k-1;k=0;y=3;

//Calculation of g y mod n :

for(q=0;q<n;q++){for(i=0;i<n;i++){

for(j=0;j<=p;j++){

l=b[j]+x[j]+k;k=0;if(l>=10){

b[j]=l-10;k=1;

}else

b[j]=l;}if(k==1){

b[j]=1;p++;k=0;

}

}

84

}

p=b[j-1];for(i=j-2;i>=0;i--){

p*=10; p+=b[i]; if(p>=n) {

u=p%n;p=u;

}}System.out.println("\ngY mod n="+u);String s1="",s2="";

while(u!=0){

switch(u%10){

case 0: s1+='0';break;

case 1: s1+='1';break;

case 2: s1+='2';break;

case 3: s1+='3';break;

case 4: s1+='4';break;

case 5: s1+='5';break;

case 6: s1+='6';break;

case 7: s1+='7';break;

case 8: s1+='8';break;

case 9: s1+='9';break;

}u=u/10;

}

System.out.println(s1);

85

for(i=s1.length()-1,k=0;i>=0;i--,k++){

s2+=s1.charAt(i);}s2+='\0';System.out.println(s2);

//Sending g y mod n to A

String send = "gY mod n="+s2;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);

n1=a[2];z=strs[2].length();for(i=z-1,k=0;i>=7;i--,k++){

x[k]=strs[2].charAt(i)-48;

}

p=k-1;k=0;y=3;

//Calcualtion for (g x mod n ) y mod n:

for(q=0;q<n1;q++){for(i=0;i<n1;i++){

for(j=0;j<=p;j++){

l=c[j]+x[j]+k;k=0;if(l>=10){

c[j]=l-10;k=1;

}else

c[j]=l;}

86

if(k==1){

c[j]=1;p++;k=0;

}

}}

p=c[j-1];for(i=j-2;i>=0;i--){

p*=10; p+=c[i]; u=p; if(p>=n) {

u=p%n;p=u;

}}System.out.println("\nshared key must be:"+u);

}int thro(String sen)throws NumberFormatException{

return(Integer.parseInt(sen));}

}

5.2.1 Implementing KDC at A:

import java.io.*;import java.net.*;//import java.math.*;

public class encrypta{

public static void main(String args[])throws IOException{

char pt[]=new char[40];int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0;long v;

87

int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";

System.out.println("enter message");

DataInputStream f=new DataInputStream(System.in);

String s=f.readLine();

encrypta m=new encrypta();

for(i=0;i<s.length();i++){

a[i]=m.convert(s.charAt(i));

}System.out.println("enter p q");p=Integer.parseInt(f.readLine());q=Integer.parseInt(f.readLine());n=p*q;z=(p-1)*(q-1);

for(i=2,k=0;i<z;i++){

if(z%i==0){

b[k]=i;k++;

}}fz=k-1;for(i=2;i<z;i++){

flag=0;for(j=2,k=0;j<=i;j++){

if(i%j==0){

c[k]=j;k++;

}

88

}fi=k;for(j=0;j<fz;j++){

for(k=0;k<fi;k++){

if(b[j]==c[k]){

flag=1;break;

}}

}if(flag==0 && i!=p && i!=q){

d=i;break;

}}

for(i=0;i<1000;i++){

if((i*d)%z==1){

e=i;break;

}}//Cipher text encrypted with ka:for(i=0;i<s.length();i++){

v=(long)Math.pow(a[i],e);cp[i]=v%n;System.out.print(cp[i]+" ");str+=cp[i];str+=" ";

}System.out.println("\n"+str);for(i=0;i<s.length();i++){

v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);

pt[i]=m.convert1(pl[i]);

}

89

System.out.println(pt);

int port = 900,serverPort = 800;//Sending Cipher text:

byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));

InetAddress ia = InetAddress.getByName("131.200.3.68");DatagramSocket ds;DatagramPacket dp;

ds = new DatagramSocket(port);String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);System.out.println("message sent:");

}

int convert(char a){

switch(a){

case 'a':case 'A':return 1;case 'b':case 'B':return 2;case 'c':case 'C':return 3;case 'd':case 'D':return 4;case 'e':case 'E':return 5;case 'f':case 'F':return 6;case 'g':case 'G':return 7;case 'h':case 'H':return 8;case 'i':case 'I':return 9;case 'j':case 'J':return 10;

90

case 'k':case 'K':return 11;case 'l':case 'L':return 12;case 'm':case 'M':return 13;case 'n':case 'N':return 14;case 'o':case 'O':return 15;case 'p':case 'P':return 16;case 'q':case 'Q':return 17;case 'r':case 'R':return 18;case 's':case 'S':return 19;case 't':case 'T':return 20;case 'u':case 'U':return 21;case 'v':case 'V':return 22;case 'w':case 'W':return 23;case 'x':case 'X':return 24;case 'y':case 'Y':return 25;case 'z':case 'Z':return 26;

case '0': return 27;case '1': return 28;case '2': return 29;case '3': return 30;case '4': return 31;case '5': return 32;case '6': return 33;case '7': return 34;case '8': return 35;case '9': return 36;

}return 0;

91

}

char convert1(int vl){switch(vl){

case 1:return 'a';case 2:return 'b';case 3:return 'c';case 4:return 'd';case 5:return 'e';case 6:return 'f';case 7:return 'g';case 8:return 'h';case 9:return 'i';case 10:return 'j';case 11:return 'k';case 12:return 'l';case 13:return 'm';case 14:return 'n';case 15:return 'o';case 16:return 'p';case 17:return 'q';case 18:return 'r';case 19:return 's';case 20:return 't';case 21:return 'u';case 22:return 'v';case 23:return 'w';case 24:return 'x';case 25:return 'y';case 26:return 'z';

case 27:return '0';case 28:return '1';case 29:return '2';case 30:return '3';case 31:return '4';case 32:return '5';case 33:return '6';case 34:return '7';case 35:return '8';case 36:return '9';

92

}return 0;}

}5.2.2 Code at KDC:import java.util.regex.*;

public class decypta{

public static void main(String args[])throws IOException{

int port = 800,clientPort=900;byte[] buffer = new byte[1024];

//Receiving Cipher text:

InetAddress ia = InetAddress.getByName("131.200.3.69");System.out.println(ia);BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);

String pt="";String pt1="";int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0,p1,q1,n1,z1;long v;int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";

Pattern pat=Pattern.compile("[ ]");String strs[]=pat.split(msg);

for(i=0;i<strs.length;i++){

cp[i]=Integer.parseInt(strs[i]);

93

System.out.println(cp[i]);

}DataInputStream f=new DataInputStream(System.in);System.out.println("enter p q");p=Integer.parseInt(f.readLine());q=Integer.parseInt(f.readLine());n=p*q;z=(p-1)*(q-1);

decrypta m=new decrypta();for(i=2,k=0;i<z;i++){

if(z%i==0){

b[k]=i;k++;

}}fz=k-1;for(i=2;i<z;i++){

flag=0;for(j=2,k=0;j<=i;j++){

if(i%j==0){

c[k]=j;k++;

}}fi=k;for(j=0;j<fz;j++){

for(k=0;k<fi;k++){

if(b[j]==c[k]){

flag=1;break;

}}

}if(flag==0 && i!=p && i!=q){

d=i;

94

break;}

}

for(i=0;i<1000;i++){

if((i*d)%z==1){

e=i;break;

}}//Decrypting with ka

for(i=0;i<strs.length;i++){

v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);

pt+=m.convert1(pl[i]);}System.out.println(pt);

System.out.println("enter p1 & q1");p1=Integer.parseInt(f.readLine());q1=Integer.parseInt(f.readLine());n1=p1*q1;z1=(p1-1)*(q1-1);

for(i=0;i<pt.length();i++){

a[i]=m.convert(pt.charAt(i));

}

for(i=2,k=0;i<z1;i++){

if(z1%i==0){

b[k]=i;k++;

}}fz=k-1;for(i=2;i<z1;i++){

flag=0;

95

for(j=2,k=0;j<=i;j++){

if(i%j==0){

c[k]=j;k++;

}}fi=k;for(j=0;j<fz;j++){

for(k=0;k<fi;k++){

if(b[j]==c[k]){

flag=1;break;

}}

}if(flag==0 && i!=p1 && i!=q1){

d=i;break;

}}

for(i=0;i<1000;i++){

if((i*d)%z==1){

e=i;break;

}}

//Encrypting with ka

for(i=0;i<pt.length();i++){

v=(long)Math.pow(a[i],e);cp[i]=v%n1;System.out.print(cp[i]+" ");str+=cp[i];str+=" ";

}

96

System.out.println("\n"+str);for(i=0;i<pt.length();i++){

v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n1);

pt1+=m.convert1(pl[i]);

}System.out.println(pt1);

System.out.println(str);

//Sending to B:

String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,clientPort);ds.send(dp);System.out.println("message sent:");

}}5.2.3 Code at B:

import java.io.*;import java.net.*;//import java.math.*;import java.util.regex.*;

public class decryptb{

public static void main(String args[])throws IOException{

int port = 900,serverPort=800;byte[] buffer = new byte[1024];

//Receiving Cipher text from KDC:

InetAddress ia = InetAddress.getByName("131.200.3.68");System.out.println(ia);BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);

97

ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);

String pt="";String pt1="";int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0,p1,q1,n1,z1;long v;int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";

Pattern pat=Pattern.compile("[ ]");String strs[]=pat.split(msg);

for(i=0;i<strs.length;i++){

cp[i]=Integer.parseInt(strs[i]);System.out.println(cp[i]);

}decyyptb m=new decryptb();DataInputStream f=new DataInputStream(System.in);System.out.println("enter p q");String str1=f.readLine();String str2=f.readLine();p=m.thro(str1);q=m.thro(str2);n=p*q;z=(p-1)*(q-1);

for(i=2,k=0;i<z;i++){

if(z%i==0){

b[k]=i;k++;

}}fz=k-1;for(i=2;i<z;i++)

98

{flag=0;for(j=2,k=0;j<=i;j++){

if(i%j==0){

c[k]=j;k++;

}}fi=k;for(j=0;j<fz;j++){

for(k=0;k<fi;k++){

if(b[j]==c[k]){

flag=1;break;

}}

}if(flag==0 && i!=p && i!=q){

d=i;break;

}}

for(i=0;i<1000;i++){

if((i*d)%z==1){

e=i;break;

}}//Decryption with kb:

for(i=0;i<strs.length;i++){

v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);

pt+=m.convert1(pl[i]);}

99

System.out.println(pt);

}int thro(String s1){

return(Integer.parseInt(s1));}

}

5.3.1 Message Encryption with Diffie Hellman and KDC:

import java.io.*;import java.net.*;public class diffie1{

public static void main(String args[])throws IOException{

int a[]=new int[100];int b[]=new int[100];char cp[]=new char[100];char p[]=new char[100];

int i;DataInputStream d=new DataInputStream(System.in);System.out.println("enter message:");diffie1 m=new diffie1();String msg=d.readLine();String str="";for(i=0;i<msg.length();i++){

a[i]=m.convert(msg.charAt(i));

}System.out.println("enter ur secret key:");int key=Integer.parseInt(d.readLine());

//Double modulo operations:

int key1=key%36;System.out.println("key1"+key1);for(i=0;i<msg.length();i++){

b[i]=(a[i]+key1)%36;cp[i]=m.convert1(b[i]);str+=cp[i];

100

System.out.println(cp[i]);}for(i=0;i<msg.length();i++){

a[i]=m.convert(cp[i]);}

for(i=0;i<msg.length();i++){

if(a[i]<key1)a[i]=a[i]+36;

b[i]=(a[i]-key1)%36;p[i]=m.convert1(b[i]);System.out.println(p[i]+" ");

}

int port = 900,serverPort = 800;byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));InetAddress ia = InetAddress.getByName("131.200.3.68");DatagramSocket ds;DatagramPacket dp;

ds = new DatagramSocket(port);String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);System.out.println("message sent:");}

5.3.2 Message Encryption with Diffie Hellman and KDC:

import java.io.*;import java.net.*;//import java.math.*;import java.util.regex.*;

public class diffie2{

public static void main(String args[])throws IOException{

int port = 800,clientPort=900;byte[] buffer = new byte[1024];

101

InetAddress ia = InetAddress.getByName("131.200.3.69");System.out.println(ia);BufferedReader br = new BufferedReader(new

InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);

int a[]=new int[100];int b[]=new int[100];char cp[]=new char[100];char p[]=new char[100];

int i;DataInputStream d=new DataInputStream(System.in);diffie2 m=new diffie2();

System.out.println("enter ur secret key:");int key=Integer.parseInt(d.readLine());int key1=key%36;System.out.println("key1"+key1);

for(i=0;i<msg.length();i++){

a[i]=m.convert(msg.charAt(i));}

for(i=0;i<msg.length();i++){

if(a[i]<key1)a[i]=a[i]+36;

b[i]=(a[i]-key1)%36;p[i]=m.convert1(b[i]);System.out.println(p[i]+" ");

}}

102

5.4 Interpretation of Results:5.4.1 Output at Sender station of DH algorithm:

103

5.4.2 Output at Receiver station of DH algo:

104

5.4.3 Output at A of KDC:

5.4.4 Output at KDC station:

105

106

5.4.5 Output at B of KDC:

5.4.6 Output for Sending of messages from either DH algo or KDC:

107

5.4.7 Output for Receiving of messages from either DH algo or KDC:

108

109

Modern cryptography uses the same basic ideas as traditional

cryptography (transposition and substitution) but its emphasis is different. Traditionally,

cryptographers have used simple algorithms. Now a days the reverse is true: the object is

110

to make the encryption algorithm so complex and involuted that even if the cryptanalyst

acquires vast mounts of enciphered text of his own choosing, he will not be able to make

any sense of it at all without the key.

Distributing the keys have always been the weakest link in most

cryptosystems. No matter how strong the cryptosystem was, if an intruder could steal the

key, the system is worthless.

Hence, as a first attempt at distributing the public keys the two parties

again use encryptions based on the modulo operation on some powers of some very large

prime natural numbers. The approach we proposed was that a third party distribution of a

key to the communicating parties. The main assumption of approach is that the third

party we have taken for distribution of the session key was trustworthy.

6.1. The possibilities for the extension of the project are:

6.1.1. KDC using KERBEROS:

The Kerberos protocol always deals with three entities: two entities that

want to authenticate to one another and one entity that mediates between these two

entities for authentication: the Key Distribution Center (KDC).

Suppose that Alice is part of a workgroup consisting of five entities, which

all want to authenticate to one another using symmetric key cryptography. Since every

entity needs to share a secret key with every other entity, we’ll need ten keys. The

mathematical formula behind this is n (n — 1)/2. Similarly, in a 50,000-employee

company we would need about 1,500,000,000 keys. Not only would we have to deal with

an enormous amount of keys, there would also be an enormous amount of small

authentication databases: There would be one on every client, containing all the secret

keys of the entities the client wants to authenticate. This solution is clearly not scalable at

the level of a large company.

In chapter 1 we already discussed the Kerberos protocol. And to make this

Kerberos more scalable the Kerberos developers included the concept of a Key

Distribution Center (KDC). The Key Distribution Center (KDC) is a trusted third party

with whom every entity shares a secret key. This key is called the entity’s master key. All

111

entities trust the KDC to mediate in their mutual authentication. The KDC also maintains

a centralized authentication database containing a copy of every user’s master key.

Kerberos maintains a database of secret keys; each entity on the network

— whether a client or a server — shares a secret key known only to itself and to

Kerberos. Knowledge of this key serves to prove an entity's identity. For

communication between two entities, Kerberos generates a session key which they

can use to secure their interactions.

6.1.2 KDC with PUBLIC KEY CRYPTOGRAPHY

Mutual authentication can also be done using public key cryptography for

the purpose of session key distribution. This protocol assumes that each of two parties is

in possession of the current public key of the other. It may not be practical to require this

assumption.

The tickets in Kerberos that are provided to clients are encrypted twice,

once with the secret key of the target server and then again with the secret key known to

the client. The second encryption is not necessary and is computationally wasteful.

Each ticket includes a session key that is used by the client to encrypt the

authenticator sent to the service associated with that ticket. In addition, the session key

may subsequently be used by the client and the server to protect messages passed during

that session. However, because the same ticket may be used repeatedly to gain service

from particular server, there is the risk that an opponent will replay messages from an old

session to the client or the server.

The message from authentication server to client includes material

encrypted with a key based on client password. An opponent can capture this message

and attempt to decrypt it by trying various passwords. If the result of a test decryption is

one of the proper form, then the opponent has discovered the client’s password and may

subsequently use it to gain authentication credentials from Kerberos.

6.1.3 KDC with NONCES:

In the chapter 3 of our proposed approach we have stated the number of

ways sending the secret key between the parties with key distribution center.

The one way in that uses this NONCES

112

The method defines that KDC itself has to select the key and it should

supply the key to both the communication parties. There by, they both communicate by

using that key. A brief approach to the communication among KDC, and the partners of

session key say A, B is shown below.

1. A issues a request to protect a logical connection to B. The message includes the

identity of A and B and a unique identifier, N1, for this transaction, which we

refer to NONCE. The Nonce may be a random number. It should very clear that

this NONCE we are keeping must be different for every message send.

2. Then KDC responds to this message by KA. Thus, A is the only one who can

successfully receive the message, and A knows that it originated at KDC. This

message includes two items intended for A.

The one time session key, Ks, to be used for the session.

The original request message, including the NONCE, to enable A to match

this reception by the KDC and, because of nonce, that this is not a replay

of some previous request.

In addition, the message includes two items intended for B.

The one time session key, Ks, to be used for the session.

An identifier to A (e.g.: its network address), IDA .

These messages that are intended for B are encrypted with KB ( the key that

KDC shares with B). They are sent to B to establish the connection and prove

A’s identity.

3. A stores the session key for use in upcoming session and forwards to B the

information that originated at KDC for B. Because this information is encrypted

with KB, it is protected from eaves dropping. B now knows the session key Ks,

and also knows the other party i.e. A also knows the session key Ks.

At this point session key has been securely exchanged between the parties and

hence now they can exchange the messages using this key without any fear.

However, two additional steps are desirable.

4. Using the newly minted session key for encryption, B sends a Nonce, N2, to A.

113

5. Also using Ks, A responds with f (N2), where f is a function that performs some

transformation on N2 (e.g., adding one).

These steps assure B that the original message it received was not replay.

Timestamps described above can be combined with these nonces to limit

how long nonces have to be remembered, but clearly the protocol is going to get a lot

more complicated.

6.1.4 KDC as CERTIFIED AUTHORITY:

This method assumes a global hierarchy of certifying authorities at least

one of which is trusted by each party. It uses digital signatures that consist of a token

encrypted in the private key of the signing entity and that are validated using the

appropriate public key. The public keys are believed to be correct as they are obtained

under the signature of the trusted certification authority. Critical parts of the

authentication exchange are encrypted in the public keys of the receivers, thus preventing

a replay attack.

Digital signatures are public key signature schemes the private-key signs

(creates) signatures, and the public-key verifies signatures. Only the owner (of the

private-key) can create the digital signature, hence it can be used to verify who created a

message. Anyone knowing the public key can verify the signature (provided they are

confident of the identity of the owner of the public key - the key distribution problem).

Usually they don't sign the whole message (doubling the size of information exchanged),

but just a hash of the message. Digital signatures can provide non-repudiation of message

origin, since an asymmetric algorithm is used in their creation, provided suitable

timestamps and redundancies are incorporated in the signature.

Here KDC acts as CERTIFIED AUTHORITY which signs the key

assuring from correct one ensuring the digital signature mechanism. Thus method is

mostly used for web traffic applications.

6.2 Conclusion:

Hence the KDC is a system that is authorized to transmit temporary

session keys to principals. Each session key is transmitted in encrypted form, using a

master key that the KDC shares with target principal. The overall work that we

114

implement is generating of key, sending to KDC and KDC in turn sending to receiver

their by the so called authentication will be completed.

The best way to stop any type of hacking is to think like hacker. Our

approach shows how hackers see a network, and argues that security should be a function

of the entire network’s design, not an afterthought based on specific technology. It covers

almost all common attacks that take advantage of users who are not always with security

measures.

115

References:

http://www.cs.ucsd.edu/users/mihir/papers/key-distribution.html

McCarthy's bibliography on key distribution

www.acsac.org/2005/papers/49.pdf

www.searchsecurity.com

www.advanedsecurityreserch.com

www.google.com

www.wikipedia.com

Computer networks –Andrew s. Tanenbaum

Network security and cryptography- William Stallings

116

117

118

119

120

121