SECURING THE NETWORK USING AUTHENTICATION KEY EXCHAGE PROTOCOLS

Table of contents Chapter 1: Introduction

1.1 1.2 1.3 1.4 1.5

Page no 1-16 4 10 11 13 16 17-29 18 18 20 22 25 30-51 31 32 46 53-73 54

Introduction Motivation Problem Statement Related work Outline of Dissertation Introduction Entity Authentication and key distribution Practical Authenticated Key Agreement using passwords Layering Public Key Distribution over secure DNS using Authenticated Delegation A modular approach to the design and analysis of authentication and key exchange protocols

Chapter 2: A Survey of Earlier Literature 2.1 2.2 2.3 2.4 2.5

Chapter 3: Theoretical Details

3.1 3.2 3.3

Introduction Problem Description Proposed Approach Technology to be used

Chapter 4: Implementation Issues

4.1

4.2 4.3

S/w and H/w requirements Unified Modeling Language Design

56 57 75-107 76 86 99 102 109-115 110 113 115

Chapter 5: Implementation
5.1 5.2 5.3 5.4

DH algorithm KDC Message Encryption Interpretation of Results Extensions of Project Conclusion

Chapter 6: Conclusion 6.1 6.2

References

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 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 victims 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.

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 Define security

Verify security

Analyze threats & risks

Define security services 1.1.4. Security service Security 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.

Define security mechanism

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

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. S Good morning 2. Interception: Interception means accessing data by an unauthorized party i.e. data is read by others. S Good morning D D S D

x
3. Modification:

Good morning

When an unauthorized party changes data it is called modification attack. Good morning S D Bad morning

x
4. Fabrication:

Some times intruders create a message and sent to the destination party pretend as the source is sending message.

x
8

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 contents are modified there by misleading the receiver. in which the message

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

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 enemys military or industrial secrets, stockbrokers, to deny a promise made to a customer by email. 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 enemys 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 users 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 insecured 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 Citibanks 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. It then constructs a new message containing the senders identity and the session key.

16

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:

18

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 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. 19

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 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, zeroknowledge, 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.

20

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. They also contributed more realistic and generic; a conceptually simple but novel password guessing attack which can be mounted on every three-pass passwordbased 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 provablysecure schemes are still expensive in the augmented model in terms of the amount of

21

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 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

22

The paper was proposed by John P. Jones, Daniel F. Berger, Chinya V. Ravishankar in the Defense Advanced Projects Research Agency under contract F30602-012-0536. In this paper they proposed the secured communication through DNS and Internet key service servers. 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 certifiers 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

23

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). 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.

Client application

Key domain Key registration IKS location

IKS server

Signing keys IKS location

Domain Admin

DNSSEC server 24

Signing key Commitments Figure: 2.1

Signing key Commitments

Figure 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 messagedriven. 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 receivers 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 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 || C K(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 . Xm.

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 O3=EK (D3 O1) O2)

. . .
ON=EK (DN 16 <= M <= 64. ON-1) The DAC consists of either the entire block ON or the left most M bits of the block with

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 Y 1 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

31

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 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 Keyin the figure 3.1. It is not common, but the ability does exist with the DiffieHellman 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 sides 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 Mathematicians 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. Ris are challenges,where subscript identifies the challenger. Ki are keys,where I indicates owner. Ks is the session key.

38

ALICE SYSTEM A RB KAB (RB) RA KAB (RA)

BOB SYSTEM

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.

39

3.2.2.1. Working principle of Diffie-Hellman algorithm: 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

Bob
Calc Sec

p, g a ga mod p (gb mod p)a mod p

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 40

clear. Once Alice and Bob compute the shared secret they can use it as an encryption key, 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

41

let b = Bob's private key. b = 15 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
knows doesn't know

Bob
knows doesn't know

Eve
knows doesn't know

p = 23 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

b = 15

p = 23 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

a=6

p = 23 base g = 5

a=6 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).

42

3.2.2.3. Drawback in Diffie-Hellman: 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-themiddle attack Picks a Picks z Picks b

A L I C E

p,g, ga mod p

gz mod p

T R U D Y

p,g, gz mod p

B O B

gb mod p
Key btw Trudy & Bob gbz mod p

Key btw Alice & trudy gaz mod p

Figure 3.6

43

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 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.

44

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 gobetween 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. 45

The reflection attack is shown in figure 3.7 A, RT Session 1

T R U D Y

RB, KAB (RT) A, RB RB2, KAB (RB) KAB (RB) Figure 3.7 The reflection attack starts out with Trudy claiming she is Alice and

B O B

Session 2

Session 1

sending RT

Bob responds, as usual, with his own challenge R B. Now Trudy is stuck

because she doesnt 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 K AB (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 onetime 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

46

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. 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 entitys 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 users master key.

47

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 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.

Sending mail server

KDC

Receiving mail server

48

Figure: 3.8 As, shown in the figure this KDC acts as interface between the sending and recieiveing partners. 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 for access

grant of request

KDC (KEY DISTRIBUTI -ON CENTER) Ks sent to B encrypted with Ka Sending Ks encrypted with

Kb

INITIATOR A (Alice)

Ks(message) Figure: 3.9

Responder B (Bob)

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

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

50

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 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

51

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 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.

52

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. 4. Hence, trudy by brute force can have 36! i.e. 4*10 36 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

55

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 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.

56

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. 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

57

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 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>> Send key information Collect the data

58

Sender Receiver Transmitting the key

KDC

Use case diagram for sending key:

59

Select a Random number Sender

Generate key based on number

KDC

Send to KDC by encrypting the key, source, destination with the key it shares with KDC

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.

Use case diagram for Collecting key:

60

Receive the information

Receiver

Decrypt the information by using the key it shares with KDC Acknowledge the sender

KDC

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.

Use case diagram for Transmitting key: KDC 61

Receive information

Sender

Decrypt information

Receiver

Encrypt it with the key that shares with receiver Send this to receiver

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.

Detailed project Class Diagram:

(Structural View of the System)

62

Initiate - skey, akey : Integer + generate();(skey:integer) +encrypta();(akey:integer) +send();(skey,akey :integer) (predefined func) 1 -

Respond skey, bkey : Integer

Acknowledges

+receive();(skey,bkey :integer) (predefined func) +decryptb();(bkey:integer) +acknowledge(skey:integer)

..1

..1 Transmit -

skey, akey, bkey : Integer

+ receive(); (skey, akey : integer) (predefined func) + decrypta(); (akey : integer) + encryptb(); (bkey : integer) + send(); (skey, bkey : integer) (predefined func)

Explanation:

63

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. 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. Declares data members (skey, akey, bkey) Defines the methods decrypta()- which defines the procedure for decrypting skey from akey. 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 Transmit class:

Respond class:

64

Sequence diagram for Sending key:

(Behavioral View of the System) s: Sender

: : : : : Task Random selector : 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 : : : : : : Sender win k: KDC Interface : : : : : : : : : : :

65

Sequence diagram for collecting key:

(Behavioral view of system) r: Receiver

: : :

Receiver win k: KDC interface :

Receiver win s: Sender Interface : : : : : : : : : : : : : : : :

Message from KDC

: : : : : :

Decrypt bkey

Analyze skey

Acknowledge skey

: :

: :

66

Sequence diagram for Transmitting key:

(Behavioral view of the System) k: KDC

: : :

KDC win s : Sender interface :

KDC win r : Receiver Interface : : : : : : : : : : : : : : : : : : : : : : : : :

Message from Sender

: : : : : : :

Decrypt akey

Analyze skey

Encrypt bkey

: Message with bkey : : : :

67

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, receivers 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. 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.

68

Detailed project Deployment Diagram:

(Environmental View of the System)

A typical LAN

KDC as Server Or Desktop Client

Receive key (Executable) Send key (Executable)

Sender As Desktop Client

Send Key (Executable)

Receiver As Desktop Client

Receive Key (Executable)

69

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.

70

Detailed project Activity diagram:

(Behavioral View of the system)

Initial state

Select random number

Sender state of action

Generate key based random number

on

Request to KDC

Grantin g request Yes

No

Send encrypted message akey to KDC

71

Receive message from sender KDC action state Decrypt akey

Analyze skey

Encrypt with bkey of Responder

Send message to Receiver

Receiver action state Receive message from KDC

Decrypt bkey

Acknowledge sender (skey)

Final state

72

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.

73

Detailed project State chart diagram:

(Behavioral view of the system) Select Random Number (Event 1)

Generate skey (Event 2)

Initial State Source state (Initiator)

Acknowledge (Event 6) (Transition)

Encrypt akey (Event 3) (Transition)

Decrypt bkey (Event 4)

Intermediate state (Transmitter) Encrypt bkey (Event 5) (Transition) Target state (Responder)

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 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.

74

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)

S : Sender

1. Sender, Receiver identification 2. Acknowledgement encrypted with ks <<global>>

1: Sender, Receiver Identification 2: Session key encrypted with key ka

<<global>>

K : KDC

<<global>>

R : Receiver

1. Sender, Receiver Identification 2. Session key encrypted with key kb

75

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.

76

5.1 Calculating Prime numbers between 10000 and 30000:

77

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); } }

5.1.1 Implementing Diffie Hellman on side A:

78

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 gx : for(i=0;i<n;i++) { for(j=0;j<z;j++) { l=b[j]+y[j]+k; k=0;

79

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 gx 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; case 2: s1+='2'; break; case 3: s1+='3'; break; case 4: s1+='4';

80

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 gy mod n from B: BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); dp = new DatagramPacket(buffer,buffer.length); ds.receive(dp);

81

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 (gy 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) { b1[j]=l-10; k=1; } else b1[j]=l;

82

} 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, gx mod n from A 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");

83

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]); l++; break; } }

84

} 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 gy 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; } } } p=b[j-1]; for(i=j-2;i>=0;i--) {

85

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); for(i=s1.length()-1,k=0;i>=0;i--,k++) { s2+=s1.charAt(i); }

86

s2+='\0'; System.out.println(s2); //Sending gy 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 (gx 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; } if(k==1) { c[j]=1; p++;

87

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; int x; long cp[]=new long[40]; int pl[]=new int[40]; int a[]=new int[40]; int b[]=new int[40];

88

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++; } } fi=k; for(j=0;j<fz;j++) { for(k=0;k<fi;k++)

89

{ 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]); } System.out.println(pt); int port = 900,serverPort = 800; //Sending Cipher text:

90

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; case 'k': case 'K':return 11; case 'l': case 'L':return 12; case 'm':

91

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; } char convert1(int vl) {

92

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'; } return 0; } }

5.2.2 Code at KDC:

93

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]); System.out.println(cp[i]); } DataInputStream f=new DataInputStream(System.in); System.out.println("enter p q");

94

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; break; } } for(i=0;i<1000;i++)

95

{ 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; for(j=2,k=0;j<=i;j++) { if(i%j==0) { c[k]=j;

96

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+=" "; } System.out.println("\n"+str); for(i=0;i<pt.length();i++) { v=(long)Math.pow(cp[i],d); pl[i]=(int)(v%n1);

97

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); ds.receive(dp); String msg = new String(dp.getData(),0,dp.getLength()); System.out.println("Received: " + msg); String pt="";

98

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++) { flag=0; for(j=2,k=0;j<=i;j++) { if(i%j==0)

99

{ 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]); } System.out.println(pt); } int thro(String s1)

100

{ 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]; System.out.println(cp[i]); } for(i=0;i<msg.length();i++) { a[i]=m.convert(cp[i]);

101

} 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]; InetAddress ia = InetAddress.getByName("131.200.3.69"); System.out.println(ia); BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

102

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]+" "); } }

5.4 Interpretation of Results:

103

5.4.1 Output at Sender station of DH algorithm:

104

5.4.3 Output at A of KDC:

105

5.4.4 Output at KDC station:

106

107

5.4.5 Output at B of KDC:

5.4.6 Output for Sending of messages from either DH algo or KDC:

108

5.4.7 Output for Receiving of messages from either DH algo or KDC:

109

110

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

111

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, well 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 entitys master key. All

112

entities trust the KDC to mediate in their mutual authentication. The KDC also maintains a centralized authentication database containing a copy of every users 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 clients 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

113

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 As 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.

114

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 115

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 networks 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.

116

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

117

118

119

120

121

122