Upload
vamsi
View
60
Download
2
Embed Size (px)
Citation preview
SECURING THE NETWORK USING AUTHENTICATION KEY EXCHAGE PROTOCOLS
Table of contents Page no
Chapter 1: Introduction 1-16
1.1 Introduction 4
1.2 Motivation 10
1.3 Problem Statement 11
1.4 Related work 13
1.5 Outline of Dissertation 16
Chapter 2: A Survey of Earlier Literature 17-29
2.1 Introduction 18
2.2 Entity Authentication and key distribution 18
2.3 Practical Authenticated Key Agreement using passwords 20
2.4 Layering Public Key Distribution over secure DNS 22
using Authenticated Delegation
2.5 A modular approach to the design and analysis of 25
authentication and key exchange protocols
Chapter 3: Theoretical Details 30-51
3.1 Introduction 31
3.2 Problem Description 32
3.3 Proposed Approach 46
Chapter 4: Implementation Issues 53-73
4.1 Technology to be used 54
4.2 S/w and H/w requirements 56
4.3 Unified Modeling Language Design 57
Chapter 5: Implementation 75-107
5.1 DH algorithm 76
5.2 KDC 86
5.3 Message Encryption 99
5.4 Interpretation of Results 102
Chapter 6: Conclusion 109-115
6.1 Extensions of Project 110
6.2 Conclusion 113
References 115
2
3
INTRODUCTION
1.1 Introduction
A network has been defined as any set of interlinking lines resembling a
net, a network of roads or an interconnected system, a network of alliances. This
definition suits our purpose well. A computer network is simply a system of
interconnected computers. How they are connected is irrelevant, there are a number of
ways to do this.
Hence, a basic understanding of computer networks is requisite in order to
understand the principles of network security.
1.1.1. Types of Models
1.1.1.1. The ISOOSI reference model
The International Standards Organization (ISO) Open Systems
Interconnect (OSI) Reference Model defines seven layers of communications types, and
the interfaces among them. Each layer depends on the services provided by the layer
below it, all the way down to the physical network hardware, such as the computer's
network interface card, and the wires that connect the cards together.
1.1.1.2. UUCP
UUCP (Unix-to-Unix Copy) was originally developed to connect UNIX
hosts together. UUCP and similar systems are batch-oriented systems: everything that
they have to do is added to a queue, and then at some specified time, everything in the
4
queue is processed. UUCP networks are commonly built using dial-up (modem)
connections. This doesn't have to be the case though: UUCP can be used over any sort of
connection between two computers, including an Internet connection. Building a UUCP
network is a simple matter of configuring two hosts to recognize each other, and know
how to get in touch with each other.
1.1.1.3. The Internet
This is a word that we have heard way too often in the last few years. The
Internet is the world's largest network of networks . When you want to access the
resources offered by the Internet, you don't really connect to the Internet; you connect to
a network that is eventually connected to the Internet backbone, a network of extremely
fast (and incredibly overloaded!) network components. This is an important point: the
Internet is a network of networks not network of hosts.
All these communication systems demand everyday security, both at home
and work. While email, online shopping, and pervasive computing allow increased
information sharing, they also provide an avenue for malicious attackers to negate our
privacy and alter our information
“SECURITY” in this contemporary scenario has become a more sensible
issue either it may be in the “REAL WORLD” or in the “CYBER WORLD”. In the real
world as opposed to the cyber world information gathering often precedes an attack.
Movie gangsters “case the joint”, soldiers “scout the area”. This is also true in fiber world
Here “bad guys” are referred to as intruders, eavesdroppers, hackers, hijackers, etc...
The intruders first have a panoramic view of the victim’s network and then start digging
the holes. Today, the illicit activities of the hackers are growing by leaps and bounds,
viz., “THE RECENT ATTACK ON THE DNS SERVERS HAS CAUSED A LOT OF
HULLABALOO ALL OVER THE WORLD”. However, fortunately the antagonists
reacted promptly an resurrected the internet world from the brink of prostration.
Security is key in the information age. When firms are using private
networks they are not thought that much about a security, only few who required privacy
they thought about security. But, Internet changed the scenario of the entire world.
5
Specifically, who ever dealing their business on Internet required security about their
transactions.
So, there is a need of proper mechanism, which will ensure the security of
data during its transmission over the network. There must be some authentication
mechanism, which will take care that only the authorized party gets the access to the
service.
Computer security means collection of tools designed to protect data and avoids
using data from others.
Network security means securing the transactions that are made on networks.
Here network refers from simple network like two interconnected computers to complex
network like Internet.
1.1.2. Importance of Security
Organization and individuals are increasingly depends on networks of all
kinds for their daily routine transaction. E-mail is a common routine in a modern person
culture. In E-commerce applications if may be business to business or customer to
business security is major criteria. Super market to jet flight operations people are
depending on Internet. Mobile applications are also rapidly increasing throughout the
world and multimedia message services usage is also increasing.
While transmitting data many people are thinking about security like
1. Is my data is secure.
2. If a send sensitive data over my internal network then any body can watch it?
3. Any body can alter my web site display.
4. How can customers by business on Internet?
5. Can any body misuse the credit card details that are sent by customer?
So, there must be some security to safeguard the confidentiality, Integrity and availability
of data carried on network.
1.1.3. Security life cycle
A general model for security life cycle for providing security is as follows
6
Define security
1.1.4. Security serviceSecurity service is a service that provides security for data that transferring
from source to destination system. There re different security services that one needed for
transferring data.
One useful classification of security services is the following:
Confidentiality: Ensures that the information in a computer system and
transmitted information are accessible only for reading by authorized parties.
Authentication: Ensures that the origin of a message or electronic document is
correctly identified, with an assurance that the identity is not false.
Integrity: Ensures that only authorized parties are able to modify computer
systems assets and transmitted information.
Non repudiation: Requires that neither the sender nor the receiver of a message
be able to deny the transmission.
Access control: Requires that access to information resources may be controlled
by or for the target system.
Availability: Requires that computer system assets be available to authorized
parties when needed.
1.1.5. Security attacks
A specific threat is a possible means by which secured information may be
breached and security attacks is a realization of threat. There are two kinds of attacks one
is passive attack and other one is active attack. Security attacks or threat are comes under
four major categories
Those are:
1. Interruption.
2. Interception.
3. Modification
7
Verify security Analyze threats & risks
Define security mechanism Define security
services
4. Fabrication
Normal flow: The data is passed between source and destination without any disturbance
is called as normal flow of operation.
S: source
D: destination
1. Interruption:
If the data on the transmission link is destroyed or made not available to
the destination means it is called as interruption.
Good morning
2. Interception:
Interception means accessing data by an unauthorized party i.e. data is
read by others.
Good morning
Good morning
3. Modification:
When an unauthorized party changes data it is called modification attack.
Good morning
Bad morning
4. Fabrication:
Some times intruders create a message and sent to the destination party
pretend as the source is sending message.
8
S
S
S
D
D
D
x
x
SD
SD
x
Bad morning
In this interruption and interception are passive attacks in which the
content of the messages are not modified. In these types just the intruders in middle will
not take any action but just sees the contents. (Eavesdroppers)
And the Modification and Fabrication are Active attacks in which the message
contents are modified there by misleading the receiver.
1.1.6. Security mechanisms
To provide security services for data transmission the following are the
mechanisms.
Encipherment mechanism: The text message can transmit into another form and then
start transmission. So, that data flow and traffic flow confidentiality.
Digital signature mechanism: A signing and verifying procedure for data, so that
authentication ensured with digital signature mechanism.
Access control mechanism: By using privilege concepts we can control the accessing of
data.
Data integrity mechanism: By using hash function or message authentication functions
we can provide data integrity.
1.1.7. Security in Layers
The following are the general security methods that follow in the layers of
the ISOOSI model.
Physical layer – Wire tapping can be foiled by enclosing some transmission lines in
sealed tubes which contains gas at high pressure. Drilling into the tube reduces the
pressure and releases gas there by triggering the alarm.
Data link layer - In this packets on the point-to-point line are encrypted while
sending from one system to another(link encryption).
Network layer – Fire walls can be installed to judge the packets.
Transport layer – End to end connections are encrypted.
Application layer – In this rather than encryption the messages are authenticated
9
Except, the physical layer all the other layers include the cryptographical
techniques for their securing purposes.
Here, we mainly focus on providing security in application layer which
includes DNS, Web pages, HTTP, CGI scripts, content delivery networks, Web caching.
1.2 Motivation
Network security is a complicated subject, historically only tackled by
well-trained and experienced experts. However, as more and more people become wired,
an increasing number of people need to understand the basics of security in a networked
world. This document was written with the basic computer user and information systems
manager in mind, explaining the concepts needed to read through the hype in the
marketplace and understand risks and how to deal with them.
Security is a broad topic and covers a multitude of sins. In its simplest
form, it is concerned with making sure that nosy people cannot read, or worse yet,
secretly modify messages intended for other recipients. It is concerned with people trying
to access remote services that they are not authorized to use. It also deals with ways to
tell whether that message is from correct source or not.
Most security problems are intentionally caused by malicious people
trying to some benefit, get attention, or to harm someone. These problems include
students of getting fun from snooping on peoples e-mail, spy, to learn an enemy’s
military or industrial secrets, stockbrokers, to deny a promise made to a customer by e-
mail. Hence, it should be clear that making a network secure involves a lot more than just
keeping it free from programming errors. It involve out smarting often intelligent,
dedicated, and sometimes well-funded adversaries. It should also be clear that measures
that will thwart casual adversaries will have little impact on the serious ones.
People authenticate other people by recognizing their faces, voices and
handwriting. Proof of signing is handled by signatures on letter head paper, raised seals
and so on. Tampering can usually be detected by hand writing, ink and paper experts.
None of these options are available electronically. Clearly other solutions are needed.
We would like to mention a quote which is be fitting in the context of security –
“The art of war teaches us on the likelihood of not to rely upon the
chances of enemy’s not coming but to prepare ourselves to counter all the threats
10
posed by the enemy if he comes and attacks.”
So in this fast growing world where everything is based on networks we
need to have a strong and invincible security measures which will allow us to tackle any
sort of problems.
However, new developments are plentiful. To make these developments
successful definitely there should be an effective tool that provides security. We are here
with providing the tool for this purpose so as to make new technologies not going down
to ground level as soon as they arise.
1.3 Problem Statement:
Authenticated key establishment protocols are designed to provide two or
more specified entities communicating over an open network with a shared secret key
which may subsequently be used to achieve some cryptographic goal such as
confidentiality or data integrity. Secure authenticated key establishment protocols are
important as effective replacements for traditional key establishment achieved using
expensive and inefficient couriers.
1.3.1. Existing System:
The approach we deal here is not an encryption mechanism as we
normally think of, indeed that do not typically use it to encrypt data. Instead, it is a
method to securely exchange the keys that encrypt data. Diffie-Hellman is an algorithm
that accomplishes this secure exchange by creating a “shared secret” (sometimes called a
“key encryption key”) between two devices. The shared secret then encrypts the
symmetric key (or “data encryption key” i.e. DES, Triple DES, CAST, IDEA, Blowfish,
etc.) for secure transmittal.
This algorithm works on the basis of only proper secret keys agreed
between honest conferees. If any malicious user, who may destruct the conference or
delay the operation, is found or suspected, then the malicious user’s port is blocked for
further operations. The process begins when each side of the communication generates a
private key. Each side then generates a public key, which is a derivative of the private
key. The two systems then exchange their public keys. Each side of the communication
11
now has their own private key and the other systems public key. Noting that the public
key is a derivative of the private key is important – the two keys are mathematically
linked.
Because the public key is indeed public and ends up on other systems, the
ability to figure out the private key from it would render the system useless. This is one
area requiring trust in the mathematical experts. The fact that the very best in the world
have tried for years to defeat this and failed bolsters my confidence a great deal.
1.3.1.1. Communicating with the Diffie-Hellman algorithm
In this Diffie-Hellman algorithm the basic assumption is sharing the secret
key. The key must be agreed upon the telephone or in person but in any event not an in-
secured network. If the communication partners have previously and recently used a key,
one party can transmit the new key to other using the old key.
One party throws a challenge to other in the form of sending
a message and encrypts that message using their shared key. The authentication is
achieved by responding to the challenges.
In simple this is known as
“Challenge-response protocol”
1.3.1.2. Draw back of algorithm
A man-in-the-middle attack (MITM) is an attack in which can attacker
is able to read, insert and modify at will, messages between two parties without either
party knowing that the link between them has been compromised. The attacker must be
able to observe and intercept messages going between the two victims. The MITM attack
is particularly applicable to the original Diffie-Hellman key exchange protocol, when
used without authentication.
The possibility of a man-in-the-middle attack remains a
serious security potential problem, even for many public-key based cryptosystems
because in these days there are several ways of breaking into the networks.
Man-in-the-Middle Attack was Successful Against Citibank’s 2-Factor Token Authentication
12
1.4 Related work
In cryptography, a key-agreement protocol is a protocol whereby two
or more parties can agree on a key in such a way that both influence the outcome. If
properly done, this precludes undesired third-parties from forcing a key choice on the
agreeing parties. Protocols which are useful in practice also do not reveal to any
eavesdropping party what key has been agreed upon.
However, Diffie hellman exponential key exchange protocol in and of
itself does not specify any prior agreement or subsequent authentication between the
participants. It has thus been described as an anonymous key agreement protocol.
Anonymous key exchange, like Diffie-Hellman, does not provide
authentication of the parties, and is thus vulnerable to man in the middle (MITM) attack.
Hence, we thus should make our selves guarenteed that there must be a
compulsion in including the third parties for the effective communication between the
partners.
A wide variety of third party schmes were emerged in the sequence.KDC
which is an effective mechanism which drives out the problem ie.man-in-the-middle
attack.The other works that are relating KDC are
1.4.1. Kerberos
Kerberos is a computer network authentication protocol which allows
individuals communicating over an insecure network to prove their identity to one
another in a secure manner. Kerberos prevents mitm attacks, and ensures the integrity of
the data. Its designers aimed primarily at a client-server model, and it provides mutual
authentication — both the user and the server verify each other's identity.Kerberos builds
on symmetric key cryptography and requires a trusted third party.
13
Kerberos uses as its basis the Needham-Schroeder protocol. It consists of
two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server
(TGS). Kerberos works on the basis of "tickets" which serve to prove the identity of
users.
1.4.1.1. Kerberos Opeartion
1. A user enters a username and password on the client.
2. The client performs a one-way hash on the entered password, and this becomes the
secret key of the client.
3. The client sends a clear-text message to the AS requesting services on behalf of the
user.Neither the secret key nor the password is sent to the AS.
4. The AS checks to see if the client is in its database. If it is, the AS sends back the
following two messages to the client:
Message A: Client/TGS session key encrypted using the secret key of the
user.
Message B: Ticket-Granting Ticket (which includes the client ID, client
network address, ticket validity period, and the client/TGS session key)
encrypted using the secret key of the TGS.
5. Once the client receives messages A and B, it decrypts message A to obtain the
client/TGS session key. This session key is used for further communications with
TGS. (Note: The client cannot decrypt the Message B, as it is encrypted using TGS's
secret key.) At this point, the client has enough information to authenticate itself to
the TGS.
6. When requesting services, the client sends the following two messages to the TGS:
Message C: Composed of the Ticket-Granting Ticket from message B and
the ID of the requested service.
Message D: Authenticator (which is composed of the client ID and the
timestamp), encrypted using the client/TGS session key.
14
7. Upon receiving messages C and D, the TGS decrypts message D (Authenticator)
using the client/TGS session key and sends the following two messages to the client:
Message E: Client-to-server ticket (which includes the client ID, client
network address, validity period and Client/server session key) encrypted
using the service's secret key.
Message F: Client/server session key encrypted with the client/TGS
session key.
8. Upon receiving messages E and F from TGS, the client has enough information to
authenticate itself to the SS. The client connects to the SS and sends the following
two messages:
Message E from the previous step (the client-to-server ticket, encrypted
using service's secret key).
Message G: a new Authenticator, which includes the client ID, timestamp
and is encrypted using client/server session key.
9. The server decrypts the ticket using its own secret key and sends the following
message to the client to confirm its true identity and willingness to serve the client:
Message H: the timestamp found in client's recent Authenticator plus 1,
encrypted using the client/server session key.
10. The client decrypts the confirmation using its shared key with the server and checks
whether the timestamp is correctly updated. If so, then the client can trust the server
and can start issuing service requests to the server.
11. The server provides the requested services to the client.
1.4.1.2 Kerberos drawbacks
15
Single point of failure: It requires continuous availability of a central server.
When Kerberos server is down, no one can log in. This can be mitigated by using
multiple Kerberos servers.
Kerberos requires the clocks of the involved hosts to be synchronized. The tickets
have time availability period and, if the host clock is not synchronized with the
clock of Kerberos server, the authentication will fail. The default configuration
requires that clock times are no more than 10 minutes apart. Password changing is
not standardized, and differs between server implementations.
1.5. Out line of Dissertation:
For securing purpose, we use the mechanisms of encryption and
decryption with a parameterized function called key. Anyone can encrypt using the
public key, but only the private key can decrypt.The amount of secrecy depends on how
secretly we are maintaining the private key.
First, we wish to design an algorithm (Diffie-Hellman) for the establishing
a shared key between the partners used for their communication. This algorithm lacks in
condition that the partners who are sharing the key with right one or Trudy.
Hence, we are going to introduce a Key Distribution center (KDC) as
interface between the partners.
This KDC supplies each partner with a key that is unique to the partner.
With this key they are going to communicate.
First, the communication partners establish a session with which they are
going to communicate.
This key will be sent by one partner to KDC in which the key is encrypted
with the key that the partner shares with KDC
This, KDC in turn decrypts this message and extracts the other partner
identity and the session key from the previous message.
16
It then constructs a new message containing the sender’s identity and the
session key.
It encrypts this message using the key it shares with the receiver and then
sends to it.
When the receiver decrypts he now knows that the other partner wants to
communicate with him.
Thus, the shared secret key is transferred.
17
2.1. Introduction:
The provable security approach to the notoriously tough problems of
authentication and session key exchange / distribution. We provide definitions and
proven secure protocols for a variety of problems. The first paper in this line was Entity
authentication and key distribution which looked at a two party setting and introduced
a model for sessions. The three party case was addressed in the paper Layering Public
Key Distribution over Secure DNS using Authenticated Delegation. A simulation
based approach is developed in A modular approach to the design and analysis of
authentication and key exchange protocols. The paper Practical Authenticated key
agreement using passwords includes updated versions of the basic definitions of the
first two papers above for the two party setting.
2.2. Entity Authentication and key distribution
The paper was proposed by the authors Bellare and Rogway in which the
two way authentication is done i.e. mutual authentication and authentication key
exchange were described.
For centuries, cryptographic protocols were designed by trial and error. A
scheme was proposed, to be adequate. History has shown that the success rate of this
method is not too impressive: proposed protocols were often broken, sometimes years
after they were first put forward.
2.2.1. Introduction:
Entity authentication is the process by which an agent in a distributed
system gains confidence in the identity of a communication partner. More often than not,
the entity authentication process is coupled with the distribution of a session key which
18
the partners can later use for message confidentiality, integrity, or whatever else. These
are central problems in computing practice, for without their resolution distributed
computing cannot realistically get off the ground. This importance is reected in the
enormous amount of attention that these problems have received in the Literature;
literally hundreds of papers have been written and protocols proposed and implemented.
This paper focuses on two versions of the the two-party, mutual, symmetric case.
In the mutual authentication problem the parties engage in a conversation
in which each gains confidence that it is the other with whom he speaks. In the
authenticated key exchange problem the parties also want to distribute a fresh and secret
session key.
2.2.2. Model:
One difficulty in laying foundations for entity authentication has been the
lack of an appropriate model for authentication in the distributed environment. This paper
specifies an appropriate model. Here they assumed that all communication among
interacting parties is under the adversary's control. In particular, the adversary can read
the messages produced by the parties, provide messages of her own to them, modify
messages before they reach their destination, and delay messages or replay them. Most
importantly, the adversary can start up entirely new instances of any of the parties,
modeling the ability of communicating agents to simultaneously engage in many sessions
at once
2.2.3. Definitions:
In the presence of an adversary, it is unclear what it could possibly mean
to be convinced that one has engaged in a conversation with a specified partner after all,
every bit communicated has really been communicated to the adversary, instead. We deal
with this problem as follows. As has often been observed, an adversary in our setting can
always make the parties accept by faithfully relaying messages among the
communication partners. But this behavior does not constitute a damaging attack; indeed,
the adversary has functioned just like a wire, and may as well not have been there.
The idea of definition of a mutual authentication is then simple but
strong the author said that a protocol is secure if the only way that an adversary can get a
party to accept is by faithfully relaying messages in this manner. In other words, any
19
adversary effectively behaves as a trusted wire, if not a broken one. Formalizing this
simple idea is not so simple, the main tool will be a notion of matching conversations.
To define authenticated key exchange it is necessary to capture a
protocol's robustness against the loss of a session key: even if the adversary gets hold of
one, this should not compromise anything but the session which that key protects. This is
done by allowing the adversary to obtain session keys just by asking for them. When this
inquiry is made, the key is no longer fresh, and any partner's key is declared unfresh, too.
Fresh keys must remain protected. This paper formalized adversary's inability to gain any
helpful information about them with the formalizations of security for probabilistic
encryption.
2.2.4. Draw back:
Despite their significance and long histories, both problems lack any
modern, complexity-theoretic treatment. In particular, the primitives and tools formalized
and understood in the theoretical community today (e.g. encryption, signatures, zero-
knowledge, proofs of knowledge, identification) don't seem adequate to treat these
problems.
2.3. Practical Authenticated Key Agreement using Passwords
The paper was proposed by Taekyoung Kwon in Security services 56
National computing Symposium 2001.In this, the authors had given the password based
authentication over a reliable channel.
Due to the low entropy of human-memorable passwords, it is not easy to
conduct password authenticated key agreement in a secure manner. Though there are
many protocols achieving this goal, they may require a large amount of computation
specifically in the augmented model which was contrived to resist server compromise.
They proposed a new practical password authenticated key agreement
protocol that is efficient and generic in the augmented model. The scheme here is
considered from the practical perspective (in terms of efficiency) and is provably secure
under the Diffie-Hellman intractability assumptions in the random-oracle model.
20
They also contributed more realistic and generic; a conceptually simple
but novel password guessing attack which can be mounted on every three-pass password-
based protocol unless care is taken in both the design and implementation phases.
2.3.1. Introduction:
User authentication is necessary for the typical case that a human being
resides as a client and tries to log on to a remote server machine. The server must be able
to determine the user's identity reliably over a public or private channel. Password
authentication is one of such methods, in which simply the user memorizes a (short)
password while the server maintains a user profile that associates the user name and the
password verifying information. The intrinsic problem with this method is the memorable
password, associated with each user, has low entropy, so that it is not easy to protect the
password information against the notorious password guessing attacks by which attackers
could search the relatively small space of human-memorable passwords.
Since a pioneering method that resists the password guessing attacks was
introduced to cryptographic protocol developers, there has been a great deal of work for
password authenticated key agreement.
2.3.2. Model:
A password-based protocol designed in the augmented model can resist
server compromise.In other words, an adversary who compromised a password profile
from a server cannot impersonate a user without launching dictionary attacks. For this
additional property, the related protocols (for example, A-EKE, AMP, AuthA, B-SPEKE,
PAK-Z, and SRP) are more expensive than those are not (for instance, EKE, EKE-2,
SPEKE, and PAK) in the augmented model. It is observed that the existing provably-
secure schemes are still expensive in the augmented model in terms of the amount of
computation, and that it is desirable to minimize the number of message passes and the
size of message blocks for practice on expensive communication channels. So the paper
designed a new three-pass password-based protocol in the augmented model with both
security and efficiency in mind. They achieved this goal interestingly by a composition
21
under the careful observation of the existing schemes discussed by the IEEE P1363
Standard Working Group, say without losing the presumed level of security. They called
the protocol TP-AMP and proved its security in the random oracle model.
2.3.3. Drawback:
On developing the new three-pass password-based protocol, they find a
conceptually simple but novel password guessing attack which can be mounted on every
three-pass password-based protocol by exploiting a small window of vulnerability
resulting from a standard technique to resist on-line guessing attacks, say from counting
the number of failed requests. The attack is due to the server's failure to synchronize
multiple simultaneous requests, and is unavoidable in three-pass protocols unless special
care is taken in both the design and implementation phases. They called this attack a
many-to-many (or parallel ) guessing attack because an active attacker can validate as
many password guesses as (s)he makes server instances invoked concurrently, regardless
of its upper limit of on-line guessing.
2.3.4. The proposal to drawback:
For this purpose, a small hash table may be maintained by the server to
track the currently served or blocked clients. The blocking policy should be considered
carefully but flexibly. This resolution method may reduce the window of vulnerability
notably but still leaves an issue about DoS (Denial of Service). Aside from the danger of
DoS attacks, a race condition and some bottleneck to the hash table are now only
concerns while they could be negligible by careful consideration. The possible prevention
methods might be considered both in the design and implementation phases of PAK.
2.4. Layering Public Key Distribution over Secure DNS using Authenticated Delegation
The paper was proposed by John P. Jones, Daniel F. Berger, Chinya V.
Ravishankar in the Defense Advanced Projects Research Agency under contract F30602-01-
2-0536. In this paper they proposed the secured communication through DNS and
Internet key service servers.
22
Digital communication has become pervasive, but there are few
guarantees that such communications are secure and private. Indeed, security and privacy
threats, long seen as hypothetical, are already real; in 2004, for the first time ever, an
arrest was publicly acknowledged as having resulted from passive email monitoring.
Internet Key Service (IKS), a distributed the Internet architecture for
authenticated distribution of public keys, layered on Secure DNS (DNSSEC).
2.4.1. Introduction:
The DNS namespace is the Internet-wide standard for defining who has
control over which names. IKS is loosely coupled to DNS, so that it can provide
specialized key distribution protocols without requiring changes to or imposing
significant overhead on DNS.
2.4.2. Model: key authentication
The most widely used approaches for solving the key authentication
problem is the certifying authority model, exemplified by SSL (Secure Sockets Layer)
which builds secure communication between the sockets, and the web-of-trust model,
exemplified by Pretty Good Privacy (PGP), a complete e-mail security package.
2.4.2.1. Certifying Authorities: The certifying authority (CA) model assumes a small
number of highly trusted individuals or organizations. Each key-identity binding must be
certified by one of these trusted entities. Certificate verification requires the certifier’s
public key to first be authenticated. In practice, a small set of root certificates, which are
public keys for various recognized certifying authorities, are typically preloaded into the
cryptographic application.
2.4.2.2. Webs-of-Trust: The web-of-trust model relies on peers to vouch for the validity
and trustworthiness of other peers. An unfamiliar key is accompanied by affirmations
(digital signatures) from a set of community members who assert that the provided key is
associated with the claimed identity. A recipient accepts the key only upon receiving
enough verifiable affirmations from individuals that they trust.
IKS follows the certifying authority model; the IKS server for a domain
acts as a CA for that domain and its public key can be authenticated by its key
commitment published via DNSSEC (DNS Security).
23
2.4.2.3. Zone Signing: A DNSSEC-enabled DNS server responsible for a given domain
(called a zone) signs the resource records comprising the zone with a public/private key
pair bound to that zone, and delivers those signatures to querying clients. These Resource
Record Signatures are stored in a new DNS record type, RRSIG, which contains a
signature that authenticates a specific named set of resource records (RRSet). Each
named resource in a secured DNS zone will have at least one associated RRSIG record.
A DNSSEC responds to a query from a DNSSEC-enabled client with
the DNS record for the name specified, along with the associated RRSIG record. The
client obtains the public key associated with the zone and verifies the provided signature.
If the signature is valid, the client can trust that the response was provided by the
authoritative source.
2.4.3. Key Distribution in DNSSEC:
To verify signatures, the client must be either statically configured with
the public key for the queried zone (the zone key), or be able to obtain and authenticate it.
To facilitate distribution of zone keys, DNSSEC defines a DNSKEY resource record
type. A DNS client queries for a zone key in the same way it queries for any other DNS
record type. To authenticate the retrieved key, the DNSKEY record must be signed by a
key which the client has previously authenticated, typically the key of the parent domain.
By recursively requesting keys and moving up the DNS hierarchy, the client will either
find a trusted key, or exhaust the name space without doing so, causing the key
authentication attempt to fail.
Key domain
Key registration Signing keys
IKS location IKS location Signing key Signing key
24
IKS server
DNSSEC server
Client application Domain Admin
Commitments Commitments
Figure: 2.1Figure 2.1 shows IKS Architecture: Naming and authentication authority is
placed in DNS and IKS, which clients use to resolve names securely.
2.4.3.1. IKS Overview: IKS allows public keys to be registered to any entity that can be assigned a
DNS name, such as a host, user, or service port. These keys are stored in and managed by
IKS servers, which may be discovered securely through DNSSEC. In turn, IKS servers
handle key registration and lookup requests for names belonging to a specific DNS
domain in
an authenticated manner.
2.4.4. Drawback:
IKS offers no guarantees about how verification was performed during
key registration. IKS is decoupled from any standards or protocols for identity
verification within domains. Clients receiving validated query responses from domain D
decide for themselves what trust to place in D. IKS insulates the end-user from the
complexities of key distribution, but does not pretend to make guarantees about the
trustworthiness of domains. In all contexts, including IKS, one must not confuse
authentication with trustworthiness.
2.5 A modular approach to the design and analysis of authentication and key exchange protocols
The paper was presented by M. Bellare, R. Canetti and H. Krawczyk in
Proc. 30th Annual Symposium on the Theory of Computing, ACM, 1998. In this the
author proposed the Message Authentication code and cryptography.
The problem of secure communications is very broad, and encompasses a
variety of sub-problems and goals. The focus of this paper is authentication in
communications, with special emphasis on the related problem of key exchange.
25
2.5.1. Introduction:
The authentication problem has received less attention than secrecy and
privacy issues, especially in the context of cryptographic protocols. Many of the
fundamental works and techniques for the design of cryptographic protocols were
developed under the idealized assumption of authenticated links between the
communicating parties. Prime examples are the Diffie-Hellman key exchange protocol
[DH] as well as much of the work on secure distributed function evaluation (e.g., [Y,
GMW, BGW, CCD]). This abstraction of the authentication problem is of great value
when developing higher level protocols. However, implementing these authenticated
links in realistic environments is far less trivial than one would have initially imagined. In
particular, networks are often asynchronous in nature, and protocols are often message-
driven. Here authentication cannot be achieved by simply applying signatures or message
authentication codes to the transmitted data (although these primitives are useful tools in
the design of complete solutions).
Generally authenticators treated each message separately. Such
authenticators are not suited for authentication of a large number of messages exchanged
between two parties since they involve a costly public-key operation (i.e., encryption,
decryption, signature or verification) per message. When transmitting many messages
between two parties the following approach is usually taken: first have the parties engage
in a key exchange protocol, where they obtain a common key known only to the two
parties. Next, authenticate each message between the parties using a standard symmetric
key message authentication (MAC) algorithm under the exchanged key. MAC
performance is usually several orders of magnitude faster than the public key related
operations. (In addition, some extra measure is needed in order to avoid replay of
messages. This can be done through a shared state between the parties).
2.5.2. Model:
This authentication technique involves the use of secret key to generate a
small fixed size block of data. This assumes that two communicating parties say A and B,
share a common secret key K. When A has a message to send to B, it calculates the MAC
as a function of the message and the key: MAC=Ck (M).
26
The message plus MAC are transmitted to the intended recipient. The
recipient performs the same calculation on the received message, using the same secret
key, to generate a new MAC. The received Mac is compared to the calculated MAC. If
we assume only the sender and the receiver know the identity of secret key, and if the
received MAC matches the calculated MAC, then
1. The receiver is assured that the message has not been altered .If an
attacker alters the message but does not alter the MAC, then the receiver’s
calculation of the MAC will differ from the received MAC. Because the
attacker is assumed not to the alterations in the message.
2. The receiver is assured that the message is from the alleged sender.
Because no one else knows the secret key, no one else could prepare a
message with a proper MAC.
3. If the message includes a sequence number, then the receiver can be
assured of the proper sequence because an attacker cannot successfully
alter the sequence number.
2.5.2.1. MAC algorithm:
Let M be the message .It is the concatenation of some 64-bit blocks of
data. And the key in it is arranged as 56-bit data and the remaining bits of total 64-bits are
MAC bits.
Then we define
∆(M)=X1 X2 ………. Xm.
Ck(M)=E k (M).
where is the exclusive OR(XOR) operation. Thus, the key length is 56 bits and the
MAC length is 64 bits. If the opponent observes [M || CK(M)], a brute force attempt to
derive K will require at least 256 encryptions .
The algorithm is as follows,
The data to be authenticated is grouped into contiguous 64-bit blocks:
D1,D2,………,DN. If necessary, the final block is padded on the right with zeroes to form
a full 64-bit block. Using the standard DES algorithm in which encryption involves 5
stages ,an initial permutation, a complex function(involves permutation and substitution
27
operations depends on key input), a simple permutation that switches two halves of data,
the complex function again, the inverse of initial permutation , we define this as follows.
Let us take this encryption algorithm as E, and a secret key K, a data authentication
code(DAC) is calculated as follows:
O1=EK (D1)
O2=EK (D2 O1)
O3=EK (D3 O2)
.
.
.
ON=EK (DN ON-1)
The DAC consists of either the entire block ON or the left most M bits of the block with
16 <= M <= 64.
2.5.3. Draw back:
But the opponent can attack the system by replacing X 1 through Xm-1 with
any desired values Y1 through Ym-1 and replacing Xm with Ym where Ym is calculated as
follows.
Ym=Y1 Y2 …….. Ym
The opponent can now concatenate the new message, which consists of Y1 through Ym,
with the original MAC to form a message that will be accepted as authentic by receiver.
With this tactic, any message of length 64*(m-1) bits can be fraudently inserted.
2.5.4. Approach to this drawback:
Thus, in assessing the security of a MAC function, we need to consider the
types of attacks that may be mounted against it. With that in mind, let us state the
requirements for MAC function. Assume that opponent knows the MAC function C but
does not know K. Then, the MAC function should have following properties.
1. If an opponent observes M and CK(M), it should be computationally infeasible for
the opponent to construct a message M1 such that Ck(M1) = Ck(M).
28
2. Ck(M) should be uniformly distributed in the sense that for randomly chosen
messages, M and M1, the probability that Ck(M)=Ck(M1) is 2-n, where n is the
number of bits in the MAC.
3. Let M1 be equal to some known transformation on M.That is, M1=f(M). For
example, f may involve inverting one or more specific bits. In that case, no.of
permutations in CK(M) and CK(M1) are equal and is 2-n .
Property 1 specifies to this example that an opponent is able to construct a new message
to match a given MAC, even though the opponent does not know and does not learn the
Key.
Property 2 deals with the need to thwart a brute-force attack based on chosen plain text.
That is, if we assume that the opponent does not know K but have to access to the MAC
function and can present messages for MAC generation, then the opponent could try
various messages until finding one that matches the given MAC. If the MAC function
exhibits uniform distribution, then a brute-force method would require, on average, 2 (n-1)
attempts before finding a message that fits a given MAC.
Property 3 specifies that the authentication algorithm should not be weaker with respect
to certain parts or bits of the message than others. If this were not the case, then an
opponent who had made M and CK (M) could attempt variations on M at the known
weak spots with the likelihood of early success at producing new message that matched
the old MAC.
Hence, messages are transmitted authenticatedly by MAC.
Hence, the papers on the authentication and key agreement and the
research works before this is shown and in the upcoming chapter we come with an
approach based on these ideas.
29
30
3.1 Introduction:
Secure group communication is an increasingly popular research area
which has been receiving much attention in recent years. As a rapid growth of the
internet, the group communication has become an important feature of the internet
technology. Computer network group communication is a group of people who
communicate (or) make a conference in an interactive procedure through the computers
connected by networks at distance or discrete location. In order to establish a secured,
fault-tolerant communication among groups in an open network, the current internet
protocols do not come into needy.
Conferencing in IP network, through group communication, is actually
transmitting data as broadcast through multiple channels. Group communication is more
complicated with regard to the concept of security .As the group starts to mutate
(members leave and join at any interval of time), the members of group are not a well
defined entity. Hence, security services in group communication or multicast groups are
complicated issues to be dealt.
Here we proposes a session based security model SSGCP (Secured
Session based Group Communication Protocol), which provides security from
establishing a session to the closure (end) of session. Secured session is established for
variable time slot dynamically among all conference members, implemented by Common
Conference Agreement (CCA) methods. The conference member here after called as
“Conferee”. Secured group communication among multiple conferees can be established
only if a conferee handles the secured key for each session.
Security communication needs to have a conference key agreement for the
group communication. Conference key arrangement is a mechanism in which a shared
conference key is derived by “conference key engine” which is exchanged among
conferee group members who participate in conference. Each conferee member will
acknowledge all other conferees, while the conferee “registry” in member system will
either accept the key or reject the key. SSGCP protocol follows distributed service
31
architecture, which is designed to be one of the components for secured publish /
subscribe and exchange communication infrastructure.
This work is suitable only for honest group of users but not for malicious
users or who intentionally attempt to delay or destruct the conference. An active attack
(malicious participant) tries to disturb establishment of a common conference key among
the group of honest participants. Passive attacks are carried out on gathering the
conference key by listening to the communication of participants.
This protocol works on the basis of only proper secret keys agreed
between honest conferees. Here we are identifying an efficient security key by group key
agreement method. The model and design, that have been developed using simple key
exchange “Diffie-Hellman” algorithm. This work suggests a simple scheme of 2-way
Diffie-Hellman (2DH) method and against n-party Decisional Diffie-Hellman (nDH)
problem.
32
3.2. Problem Description
3.2.1. Diffie-Hellman Key Exchange - A Non-Mathematician's
Explanation:
The Diffie-Hellman algorithm, introduced by Whitfield Diffie and Martin
Hellman in 1976, was the first system to utilize “public-key” or “asymmetric”
cryptographic keys. The systems overcome the difficulties of “private-key” or
“symmetric” key systems because key management is much easier. In a symmetric key
system, both sides of the communication must have identical keys. Securely exchanging
those keys has always been an enormous issue.
Asymmetric key systems alleviate that issue because they use two keys –
one called the “private key” that the user keeps secret and one called the “public key” that
can be shared with the world. Unfortunately, the advantages of asymmetric key systems
are overshadowed by speed – they are extremely slow for any sort of bulk encryption.
Today, it is typical practice to use a symmetric system to encrypt the data and an
asymmetric system to encrypt the symmetric keys. That is precisely what Diffie-Hellman
is capable of doing – and does do when used for key exchange as described here.
3.2.1.1. Exchanging their public keys:
Diffie-Hellman accomplishes this secure exchange by creating a “shared
secret” (sometimes called a “key encryption key”) between two devices. The shared
secret then encrypts the symmetric key for secure transmittal. The process begins when
each side of the communication partner generates a private key .Each side then generates
a public key which is a derivative of the private key. The two systems then exchange their
public keys. Each side of the communication partner now has their own private key and
the other systems public .
33
figure: 3.1
Noting that the public key is a derivative of the private key is important –
the two keys are mathematically linked. However, in order to trust this system, you must
accept that you cannot discern the private key from the public key. Because the public
key is indeed public and ends up on other systems, the ability to figure out the private key
from it would render the system useless. This is one area requiring trust in the
mathematical experts. The fact that the very best in the world have tried for years to
defeat this and failed bolsters my confidence a great deal.
Here we should also explain the box labeled “Optional: CA Certifies
Public Key”in the figure 3.1. It is not common, but the ability does exist with the Diffie-
Hellman protocol to have a Certificate Authority certify that the public key is indeed
coming from the source you think it is. The purpose of this certification is to prevent Man
in the Middle (MIM) attacks. The attack consists of someone intercepting both public
keys and forwarding bogus public keys of their own. The “man in the middle” potentially
intercepts encrypted traffic, decrypts it, copies or modifies it, re-encrypts it with the
bogus key, and forwards it on to its destination. If successful, the parties on each end
would have no idea that there is an unauthorized intermediary. It is an extremely difficult
34
attack to pull off outside the laboratory, but it is indeed possible. Properly implemented
Certificate Authority systems have the potential to disable the attack.
3.2.1.2. Generation of identical cryptographic key:
Once the key exchange is complete, the process continues. An important feature
of the Diffie-Hellman protocol is its ability to generate “shared secrets” – an identical
cryptographic key shared by each side of the communication. Below figure depicts this
operation with the “DH Math” box (trust me, the actual mathematical equation is a good
deal longer and more complex). By running the mathematical operation against our own
private key and the other side’s public key, we generate a value. When the distant end
runs the same operation against your public key and their own private key, they also
generate a value. The important point is that the two values generated are identical.
35
figure: 3.2
At this point, the Diffie-Hellman operation could be considered complete.
The shared secret is, after all, a cryptographic key that could encrypt traffic. That is very
rare however. The reason being that the shared secret is, by its mathematical nature, an
asymmetric key. As with all asymmetric key systems, it is inherently slow. If the two
sides are passing very little traffic, the shared secret may encrypt actual data. Any attempt
at bulk traffic encryption requires a symmetric key system such as DES, Triple DES,
IDEA, CAS T, Blowfish, etc.
3.2.1.3. Encrypting, Passing, and Decrypting the Symmetric Key:
In most real applications of the Diffie-Hellman protocol (IPSec in
particular), the shared secret encrypts a symmetric key for one of the symmetric
algorithms, transmits it securely, and the distant end decrypts it with the shared secret.
Below figure depicts this operation. Because the symmetric key is a relatively short value
as compared to bulk data, the shared secret can encrypt and decrypt it very quickly.
Speed is not so much of an issue with short.
Which side of the communication partner actually transmits the symmetric
key varies. However, it is most common for the initiator of the communication partner to
be the one that transmits the key.It is an obviously important task since both sides of
communication partner must support the same schemes for encryption to function.
36
Figure: 3.3
3.2.1.4. Encrypted Data Transmission:
Once secure exchange of the symmetric key is complete (and note that passing that
key is the whole point of the Diffie-Hellman operation), data encryption and secure
communication partner can occur. Below figure depicts data encrypted and decrypted on
each end of the communication partner by the symmetric key. Note that changing the
symmetric key for increased security is simple at this point. The longer a symmetric key
is in use, the easier it is to perform a successful cryptanalytic attack against it. Therefore,
changing keys frequently is important. Both sides of the communication partner still have
the shared secret and it can be used to encrypt future keys at any time and any frequency
desired.
The use of Diffie-Hellman greatly reduces the headache of using symmetric key
systems. These systems have astounding speed benefits, but managing their keys has
always been difficult to say the very least.
37
Figure: 3.4
3.2.2. A Brief Introduction of Diffie-Hellman Mathematician’s
Approach:
Here we will see how to communicate with shared key. Let us assume the
communication partners are Alice and Bob systems. The Diffie-Hellman algorithm
depends for its effectiveness on the difficulty of computing discrete logarithms.
For our authentication protocol, we will assume that Alice and Bob already share
a secret key, KAB.
This protocol is based on a principle found in many authentication protocols:
One party sends a random number to other,who then transforms it in a special way and
then returns the result.Such protocols are called challenge-response protocols.In this
protocol the following notation will be used:
A, B are identities of Alice and Bob systems.
Ri’s are challenges,where subscript identifies the challenger.
Ki are keys,where I indicates owner.
Ks is the session key.
38
Figure: 3.5
In above figure 3.5 initially Alice sends her identitity A to Bob in a way
that Bob understands. Bob of course, has no way of knowing whether this message came
from Alice or from Trudy,so he chooses a challenge,a large random number RB and sends
It back to “Alice” as in plaintext.Random numbers used just once in challenge-response
protocols like this one are called nonces. Alice then encrypts the message with the key
she shares with Bob and sends the cipher text, KAB(RB), back to Bob. When Bob sees this
message, he immediately knows that it came from Alice because Trudy does not know
KAB and thus could not have generated it.Furthermore,since RB was chosen randomly
from a large space,it is very unlikely that Trudy would have seen RB and its response
from an earlier session.It is equally unlikely that she could guess the correct response to
any challenge.
At this point, Bob is sure that he is talking to Alice, but Alice is not sure of
anything. For all Alice knows, Trudy might have intercepted identity of Alice A and sent
back RB in response.May be Bob died last night. To find out to whom she is talking,
Alice picks a random number, RA and sends it to Bob as plaintext. When Bob responds
with KAB (RA), Alice knows she is talking to Bob. If they wish to establish a key
now,Alice can pick one, KS ,and send it to Bob encrypted with KAB.
3.2.2.1. Working principle of Diffie-Hellman algorithm:
39
A
RB
KAB (RB)
RA
KAB (RA)
ALICE SYSTEM BOB SYSTEM
Alice and Bob have two large numbers, p and g ,where n is prime ,(p-1)/2
is also a prime and certain conditions apply to g. These numbers may be public, so either
one of them can just pick p and g or tell the other openly. Now Alice picks a large
number, a and keeps it secret. Similarly Bob picks a large number, b and keeps it secret.
Alice initiates the key exchange protocol by sending a message
containing (p, g, ga mod p)to Bob. Bob responds to Alice by sending a message
containing gb mod p .Now Alice calculates (gb mod p)a mod p by raising the number sent
by the Bob to ath power modulo p. Bob performs similar operation to get (ga mod n )b
mod p. By the laws of modular arithmetic, both calculations yield gab mod p. So now
Alice and Bob suddenly share a secret key, gab mod p.
The simplest, and original, implementation of the protocol uses the
multiplicative group of integers modulo p, where p is prime and g is primitive mod p.
Modulo (or mod) means that the integers between 0 and p − 1 are used with normal
addition, subtraction, multiplication, and exponentiation, except that after each operation
the result keeps only the remainder after dividing by p. Here is an example of the
protocol:
Alice
Sec Calc
p, g
a
ga
mod p
…
(gb
mod p)a
mod p =
Bob
Calc Sec
p, g
b
…
gb
mod p
(ga
mod p)b
mod p
1. Alice and Bob agree to use a prime number p=23 and base g=5.
2. Alice chooses a secret integer a=6, then sends Bob (ga mod p)
o 56 mod 23 = 8. 3. Bob chooses a secret integer
b=15, then sends Alice (gb mod p)
o 515 mod 23 = 19. 4. Alice computes (gb mod p)a mod
p o 196 mod 23 = 2.
5. Bob computes (ga mod p)b mod p
o 815 mod 23 = 2.
Both Alice and Bob have arrived at the same value, because gab and gba are
equal. Note that only a, b and gab = gba are kept secret. All the other values are sent in the
clear. Once Alice and Bob compute the shared secret they can use it as an encryption key,
40
known only to them, for sending messages across the same open communications
channel. Of course, much larger values of a,b, and p would be needed to make this
example secure, since it is easy to try all the possible values of gab mod 23 (there will be,
at most, 22 such values, even if a and b are large). If p was a prime of at least 300 digits,
and a and b were at least 100 digits long, then even the best known algorithms today
could not find a given only g, p, and ga mod p, even using all of mankind's computing
power. The problem is known as the discrete logarithm problem. Note that g need not be
large at all, and in practice is usually either 2 or 5.
Here's a more general description of the protocol:
1. Alice and Bob agree on a finite cyclic group G and a generating element g in G.
(This is usually done long before the rest of the protocol; g is assumed to be
known by all attackers.) We will write the group G multiplicatively.
2. Alice picks a random natural number a and sends ga to Bob.
3. Bob picks a random natural number b and sends gb to Alice.
4. Alice computes (gb)a.
5. Bob computes (ga)b.
Both Alice and Bob are now in possession of the group element gab which can serve as
the shared secret key. The values of (gb)a and (ga)b are the same because groups are power
associative.
3.2.2.2. Efficiency:
Here is a chart to help simplify who knows what. (Eve is an eavesdropper
- she watches what is sent between Alice and Bob, but she does not alter the contents of
their communications.)
Let s = shared secret key. s = 2
let a = Alice's private key. a = 6
let b = Bob's private key. b = 15
41
let g = public base. g=5
let p = public (prime) number. p = 23
Hence in the diagram even for very fast compuers like super computers it
will become years together to find out the key.
Alice
knowsdoesn't know
p = 23 b = 15
base g = 5
a = 6
56 mod 23 = 8
5b mod 23 = 19
196 mod 23 = 2
8b mod 23 = 2
196 mod 23 = 8b
mod 23
s = 2
Bob
knowsdoesn't know
p = 23 a = 6
base g = 5
b = 15
515 mod 23 = 19
5a mod 23 = 8
815 mod 23 = 2
19a mod 23 = 2
815 mod 23 = 19a
mod 23
s = 2
Eve
knowsdoesn't know
p = 23 a = 6
base g = 5 b = 15
s = 2
5a mod 23 = 8
5b mod 23 = 19
19a mod 23 = s
8b mod 23 = s
19a mod 23 = 8b
mod 23
It should be difficult for Alice to solve for Bob's private key or for Bob to
solve for Alice's private key. If it isn't difficult for Alice to solve for Bob's private key (or
vice versa), Eve may simply substitute her own private / public key pair, plug Bob's
public key into her private key, produce a fake shared secret key, and solve for Bob's
private key (and use that to solve for the shared secret key. Eve may attempt to choose a
public / private key pair that will make it easy for her to solve for Bob's private key).
3.2.2.3. Drawback in Diffie-Hellman:
42
Trudy of course, an eve has seen both messages .She knows g and p from
message containing g, a, ga mod p. If she could compute a and b, she could figure out the
secret key. But here the trouble is given only ga mod p ,she cannot find a. Because there
is no algorithm for computing large prime number (modulo) is known.
Here, while Alice and Bob are choosing a and b respectively, Trudy picks
her own random number, z. Alice sends message (p, g, ga mod p) intended for Bob. Trudy
intercepts it and sends message (p, g, gz mod p)to Bob, using the correct g and p with
her own z instead of a she also sends message (gz mod p) back to Alice. Later Bob sends
message gb mod p to Alice which Trudy again intercepts and keeps.
Alice computes secret key as g az mod p, similarly Bob computes gbz mod
p Alice thinks she is talking to Bob so she establishes a session key with Trudy. Every
message that Alice sends on the encrypted session is captured by Trudy. Trudy stored,
modified that message and then passed to Bob. Similarly in other direction Trudy sees
everything and can modify all messages while both Alice and Bob are under the illusion
that they have a secure channel to one another. This attack is known as Man-in-the-
middle attack
Picks a Picks z Picks b
Figure 3.6
In cryptography, a man-in-the-middle attack (MITM) is an attack in
which an attacker is able to read, insert and modify at will, messages between two parties
without either party knowing that the link between them has been compromised. The
43
A L I C E
T R U D Y
B O B
p,g, ga mod pp,g, gz mod p
gz mod pgb mod p
Key btw Alice & trudygaz mod p
Key btw Trudy & Bobgbz mod p
attacker must be able to observe and intercept messages going between the two victims.
The MITM attack is particularly applicable to the original Diffie-Hellman key exchange
protocol, when used without authentication.
MITM should be seen as a general problem resulting from the presence of
intermediate parties acting as proxy for clients on either side. If they are trustworthy and
competent, all may be well; if they are not, nothing will be. How can one distinguish the
cases? By acting as proxy and appearing as the trusted client to each side, the
intermediate attacker can carry out much mischief, including various attacks against the
sconfidentiality or integrity of the data passing through it.
3.2.2.3.1.The MITM attack may include one or more of:
Eavesdropping : Suppose Alice wishes to communicate with Bob, and that
Mallory wishes to eavesdrop (just make an eye) on the conversation.(e.g. In
reavealing some confidential information to militants etc…)
Chosen ciphertext attack : depending on what the receiver does with a message
that it decrypts. If Bob sends his public key to Alice, but Mallory is able to
intercept it, a man-in-the-middle attack can begin. Mallory can simply send Alice
a public key for which she has the private, matching, key. Alice, believing this
public key to be Bob's, then encrypts her message with Mallory's key and sends
the enciphered message back to Bob. Mallory again intercepts, deciphers the
message, keeps a copy, and reenciphers it (after alteration if desired) using the
public key Bob originally sent to Alice. When Bob receives the newly enciphered
message, he will believe it came from Alice.
Substitution attack : Man in the middle May arise and subsitute one information
with other inorderto mislead the partner.
Replay attacks : Trudy can reply the same message to the sender.
Denial of service attack . The attacker may for instance jam all communications
before attacking one of the parties. The defense is for both parties to periodically
send authenticated status messages and to treat their disappearance with paranoia.
Phishing : attacks, where victims are duped into entering their details into a proxy
website that imitates a genuine site (e.g., an online bank). By acting as a go-
44
between to the genuine website, the proxy website allows the victims to log in and
conduct business as usual without raising suspicion.
MITM is typically used to refer to active manipulation of the messages, rather than
passively eavesdropping.
All cryptographic systems that are secure against MITM attacks require
an additional exchange or transmission of information over some kind of secure channel.
Here the Replay attack is important one:
3.2.2.3.2. Replay attack:
A replay attack is a form of network attack in which a valid data
transmission is maliciously or fraudulently repeated or delayed. This is carried out either
by the originator or by an adversary who intercepts the data and retransmits it, possibly as
part of a masquerade attack by IP packet substitution (such as stream cipher attack).
Suppose Alice wants to prove her identity to Bob. Bob requests her
password as proof of identity, which Alice dutifully provides (possibly after some
transformation like a hash function); meanwhile, Mallory is eavesdropping the
conversation and keeps the password. After the interchange is over, Mallory connects to
Bob posing as Alice; when asked for a proof of identity, Mallory sends Alice's password
read from the last session, which Bob must accept.
3.2.2.3.3. Reflection attack: Under certain circumstances, Trudy can defeat this
protocol by using reflection attack. In particular Trudy can break it if it is possible to
open multiple sessions with Bob at once. This situation would be true if Bob is prepared
to accept many simultaneous connections from teller machines at once.
The reflection attack is shown in figure 3.7
45
A, RT
RB, KAB (RT)
A, RB
RB2, KAB (RB) KAB (RB)
T R U D Y
B O B
Session 1
Session 2Session 1
Figure 3.7
The reflection attack starts out with Trudy claiming she is Alice and
sending RT Bob responds, as usual, with his own challenge RB. Now Trudy is stuck
because she doesn’t know KAB (RB). Trudy is supplying the RB taken from challenge RB,
KAB (RT) as a message in session 2. Bob calmly encrypts it and send back KAB (RB) as a
response to challenge in session 2.
Again Trudy sends may smash the session 2 and takes KAB (RB) and
responds to the message in session 1.
The attacker initiates a connection to a target.
The target attempts to authenticate the attacker by sending it a challenge.
The attacker opens another connection to the target, and sends the target this
challenge as its own.
The target responds to that challenge.
The attacker sends that response back to the target ("reflects" it) on the first
connection.
A way to avoid replay attacks is using session tokens. Bob sends a one-
time token to Alice, which Alice uses to transform the password and send the result to
Bob (e.g. computing a hash function of the session token appended to the password). On
his side Bob performs the same computation; if and only if both values match, the login
is successful. Now suppose Mallory has captured this value and tries to use it on another
session; Bob sends a different session token, and when Mallory replies with the captured
value it will be different from Bob's computation.
46
Session tokens should be chosen by a (pseudo-) random process.
Otherwise Mallory may be able to guess some future token and convince Alice to use that
token in her transformation. Mallory can then replay her reply at a later time, which Bob
will accept.
Bob can also send nonces but should then include a Message
authentication code (MAC), which Alice should check.
Timestamping is another way of preventing a replay attack.
Synchronization should be achieved using a secure protocol. For example Bob
periodically broadcasts the time on his clock together with a MAC. When Alice wants to
send Bob a message, she includes her best estimate of the time on his clock in her
message, which is also authenticated. Bob only accepts messages for which the
timestamp is within a reasonable tolerance. The advantage of this scheme is that Bob
does not need to generate (pseudo-) random numbers.
3.3 PROPOSED APPROACH:
In order to use different approaches for each and every drawback, we
proposed an approach which gives a single solution to all the problems described above.
In cryptography, a key distribution center (KDC) is part of a cryptosystem
intended to reduce the risks inherent in exchanging keys. KDCs often operate in systems
within which some users may have permission to use certain services at some times and
not at others.
The Key Distribution Center (KDC) is a trusted third party with whom
every entity shares a secret key. This key is called the entity’s master key. All entities
trust the KDC to mediate in their mutual authentication. The KDC also maintains a
centralized authentication database containing a copy of every user’s master key.
A typical operation with a KDC involves a request from a user to use
some service. The KDC will use cryptographic techniques to authenticate requesting
users as themselves. It will also check whether an individual user has the right to access
47
to the service requested. If the authenticated user meets all prescribed conditions, the
KDC can issue permitting access.
KDCs mostly operate with symmetric encryption.
In most (but not all) cases the KDC shares a key with each of all the other
parties.
The key agreement may be given to individual party selection or the KDC itself
may select the key.
Here we are giving acess to selct the key based on individual parties. Hence the selction
is given to communicating parties only. To describe this one party can legally select the
key and deliver to other. This precludes the undesired assymmetric key for exchange. The
selction may be given to KDC togenerate a key. The key on encryption lines is passed to
the parties. There by without the intervention of KDC the parties can continue their
communication confidentially. There by providing effective tool for key sharing.
Figure: 3.8
As, shown in the figure this KDC acts as interface between the sending
and recieiveing partners.
KDC
Receiving mail server
48
Sending mail server
The authentication happens here for free.The KDC knows that the
messages are from right person since its members only know what are the secret keys that
with the KDC and the members. Hence there is no problem for thinking the way the
messages are from right person. If the key is distributed successfully without any break in
the link Authentication is complete.
How the key distribution will be done and how the authentication is achieved is
shown below:
Request grant
for of Ks sent Sending Ks
access request to B encrypted with encrypted Kb
with Ka
Ks(message)
Figure: 3.9
Where
Ks is the session which is created by Alice and send it to KDC.
Ka is the key that is exchanged between KDC and Alice.
Kb is the key shared between KDC and Bob.
49
INITIATOR A (Alice) Responder
B (Bob)
KDC (KEY DISTRIBUTI-ON CENTER)
3.3.1. Steps described in figure is as follows:
Initially Alice system requests that KDC To verify whether KDC is free or
else it is serving the other paries. And it requests to access
After KDC sees the request from Alice, He responds and asks to send the
message
Now Alice will sent the already generated key for the communication with
Bob system. The message is sent encrypted using the key that it distributes
with KDC.
Now, KDC decrypts this message and then it reencrypts the Session key
Ks with the key that it shares with Bob.
Bob after receiving this message decrypts the message
Now both Alice and Bob know the Key and now Bob as an
acknowledgement sends the message to sender with the key he received
from KDC i.e. the so called session key.
3.3.2. Benefits
This KDC will enable the easier session key distribution securely between
the partners. The system also provides scalability that is the system is capable of
supporting large numbers of clients and servers and this also supports a modular
distributed architecture.
3.3.3. Drawbacks
The first drawback with key distribution center is that every body must
trust on KDC that it is not an intruder but the right one. Another one is that KDC can
become the single point of failure. i.e. if the intermediate system is lost there is no way of
sending and receving of session key between the parties.
However, there is a great approach to this drawbacks. It is not necessary to
limit this key distribution function to a single KDC. To increase the reliability let us
50
increase the availability.Keep the replication KDC if atall the system is creas we can
connect the communicating systems to just that replicating KDC.
Indeed, for very large networks, it may not be practical to do so. As an
alternative a hierarchy of KDCs can be established. For example, there can be local
KDCs, eah responsible for small domain of the overall internetwork, such as single LAN
or a single building. For communication among the entities within the same local domain,
the local KDC is responsible for key distribution. If two entities in different domains
desire a sherd key, then the corresponding local KDCs can communicate through global
KDC. In this case, any one of three KDCs involved can actually select the key. This
hirerarchical concept can be extended to the three or even more layers, depending on the
size of the user population and the geographic scope of internetwork.
A hierarchical scheme minimizes the effort involved in master key
distribution, because most master keys are those shared by a local KDC with its local
entities. Furthermore, such a scheme limits the damage of a faulty or subverted KDC to
its local area only.
The more frequently the session keys are exchanged, the more secure they
are, because the opponent has less ciphertext to work with for any given session key. On
the other hand, the distribution of session keys delays the start of any exchange and
places a burden on network capacity. A security manager nmust try to balance these
competing considerations in detrmining the lifetime of a particular session key.
For connection-oriented protocols, one obvious choice is to use the same
session key for length of time that the connection is open, using a new session key for
each new session. If a logical connection has very long lifetime, then it would be prudent
to change the session key periodically, perhaps every time the PDU (Protocol data unit)
sequence number cycles.
For a connectionless protocol, such as a transaction-oriented protocol,
there is no explicit connection iniitation or termination. Thus, it is not obvious how often
one needs to change the session key. The most secure approach is to use a new session
51
key for exchange. However, this negates one of the principal benefits of the
connectionless protocols, which is minimum overhead and delay for each transaction. A
better stategy is to use a given session key for a certain fixed period only or certain
number of transactions.
3.3.4 KDC with RSA
As KDC is a symmetric key encryption algorithm, here we go for public key encryption
of symmetric key. RSA algorithm was proposed by Rivet, Shamir, Adleman. The RSA
message or key encryption provides good security even with small bit key sizes.
Steps in RSA:
1. Choose two Prime numbers say p, q
2. We have to compute n=(p*q) and z=n-p-q+1.
3. We have to choose a number ‘d’ such that z and d should have no factors in
common
4. Find number ‘e’ such that e*d=1 mod z (or) (e*d) mod z=1.
Encryption with RSA:
1. Let the plain text be P and it is encrypted with RSA as C=Pe mod n where C is
the cipher text.
2. And the decryption will be P=Cd mod n where P is our normal plain text.
3. Here in KDC we are using that the partners share with KDC as ka and kb.
4. These ka and kb are not actually the single keys, but are key pairs.
5. One can indicate its key with KDC as p, q in RSA.
Encrypting messages after receiving key ks either from DH algorithm or from KDC:
1. Here we use one of the Caesar cipher called substitution cipher.
2. That is substituting one set of letters with i.e. symbol-by-symbol substitution.
3. This substitution takes an order and this order is based on our session key ks.
52
4. Hence, trudy by brute force can have 36! i.e. 4*1036 Possibilities(26 for alphabets
& 10 for digits).
Applications:
1. Banking applications, Airlines, Business applications
2. E-mail security, Military applications, mobile code security but with hardware
equipped chip, etc----.
53
54
4.1 Technology to be used:
Communication between the computers in a network or a different
network requires certain set of protocols. These protocols are very much and very
efficient in java. Java applets can be downloaded from website and this is one of the
main attractions of java.
4.1.1. Why networking in java?
Java is the first language to provide such a powerful platform network
library that handles all the diverse tasks such as
Browsing pages on web
Parsing and rendering HTML
Sending e-mail with SMTP
Receiving E-mail with POP and IMAP
Writing multithreaded servers
Installing a new protocol and content into browsers
Encrypting communications for confidentiality, Authentication, and
guaranteed message integrity
Designing GUI clients for network services
Posting data to CGI programs
Looking up hosts using DNS
Downloading files with anonymous FTP
Connecting Sockets for low-level network communication
Distributing applications across multiple systems with Remote Method invocation
Java Network Programming exposes the power and sophistication of these
class libraries. Together these features the other java features allow web surfaces to
quickly download and execute untrusted programs from a website without worrying that
55
the program may spread virus, steal the other data, or crash their systems. Indeed, the
intrinsic safety of java applet is far greater than that of a shrink-wrapped software.
What makes java a good language for networking are the classes that
defined in the java.net package.
Every computer connected to the network has a unique IP address. It is
similar to every student of a batch having a unique id. An IP address is a 32-bit number
which has four numbers separated by periods.
InetAddress is one of the classes in java.net package and this is used to
encapsulate the IP address and DNS.
Obtaining InetAddress of system:
import java.net.*;
class InetAddressTest{
Public static void main(String args[])
{
try
{
InetAddress add=InetAddress.getLocalHost();
System.out.println(“address of local Host is:” +add);
}catch(unknownHostException u){}
}
}
After running this will give the output which is the IP address of the
system in which this program is executed.
For e.g. it gives as: grd-32/80.0.0.32.
After obtaining the InetAddress of a machine, a DatagramPacket, which is
a data container, will specify the data and the DatagramSocket class which contain the
send and receive methods will take the data on the network.
DatagramPacket(byte data[], int size, InetAddress I, int port) -The above
constructor specifies the the data to be sent or receive in byte array, its size i.e.
56
data size , InetAddress of the system and the port specifying whether it is
client or server port.
DatagramSocket class contains send and receive methods
DatagramSocket s=new DatagramSocket(int port)
Methods in this class are handled by object(s).method name
1. send (DatagramPacket d) –Dispatches the given DatagramPacket
object.
2. receive (DtagramPacket p)-Receives the given DatagramPacket
object.
3. close()-closes the socket connection)
We also wish to use HTML pages as the front end for the part for just
taking the input and giving the output.
4.2 Hardware and software requirements:
4.2.1. H/w Requirements:
In our project the system requires Pentium IV processor with 2.66 GHz ,
5GB Hard Disk and 256 MB RAM. Like this we wish three systems to send and
receiving of messages. Additionally we want a typical LAN for connecting all these
systems.
4.2.2. S/w Requirements:
The Operating System required for our project is WINDOWS 9X/ XP and
the languages we use are Java and Html. The version of java required is JSDK,
Networking packages
4.3 Unified Modelling Language Design:
As the complexity of systems increases, so does the importance of good
specification and modeling techniques. Many factors contribute to the success of a
project, and certainly one we cannot do without is a rigorous modeling language
standard. Introduced in recent years, the Unified Modeling Language (UML) is now
57
widely used, basically for requirements specification and for the design of complex
software systems and also embedded systems. A few months ago, a new community was
created, called UML-SoC. In the present paper we describe the use of UML for
specification and modeling of the security and communication aspects of network system,
Through UML we describe security issues such as data integrity, data confidentiality, and
authentication
UML design USE case diagram for the whole system
(User View of the System)
<<Communicates>>
Transmitting the key
Receiver
KDC
58
Send key
information Collect the data
Sender
Sender
Use case diagram for sending key:
Explanation: Generally the actors specified are not actually the external actors to the
system but they are typically the backup systems that included in the whole project.
Hence, Sender, Receiver and KDC are back up systems. First the sender will select a
random number and based on the random number the key will be generated and this is
passed to KDC which is encrypted with the key that it shares with KDC. Hence, as shown
in the figure above sender will perform these set of actions. The rectangle enclosing the
use cases will specify the boundary of the system.
Select a Random number
Generate key based on number
Send to KDC by encrypting the key, source, destination with the key it
shares with KDC
KDC
59
Use case diagram for Collecting key:
Receiver
Explanation:
In the above diagram the actor is the back up system which collects the
data. The use cases specify the list of actions that are receiving the information,
decrypting the message and acknowledging the sender. These are the sequential actions
that are carried out by the collector.
60
Receive the information
Decrypt the information by using the key it shares with KDC
Acknowledge the sender
KDC
Use case diagram for Transmitting key:
Explanation:In this the actor is again the backup system which is referred as KDC in
the above diagram. Hence the sequence of actions carried out by this actor is specified in
the use cases as receiving the information from sender, decrypting the information again
encrypting the information to send to receiver, and sending it to receiver. Hence, the
system is connected with the other actors of sender and receiver.
61
KDC
Receive information
Decrypt information
Encrypt it with the key that shares with receiver
Send this to receiver
SenderReceiver
Detailed project Class Diagram:
(Structural View of the System)
Acknowledges
1 ..1
..1 1
62
Initiate
- skey, akey : Integer
+ generate();(skey:integer)
+encrypta();(akey:integer)
+send();(skey,akey :integer) (predefined func)
Respond
- skey, bkey : Integer
+receive();(skey,bkey :integer)
(predefined func)+decryptb();(bkey:integer)
+acknowledge(skey:integer)
Transmit
- skey, akey, bkey: Integer
+ receive(); (skey, akey : integer) (predefined func)+ decrypta(); (akey : integer)
+ encryptb(); (bkey : integer)
+ send(); (skey, bkey : integer) (predefined func)
Explanation: This diagram gives the Structural view of the system. It contains classes to
define the main modules of the system. The classes defined here are the Initiate, Respond
and Transmit and they defines
Initiate class:
Declares data members (skey, akey)
skey – specifies the session key with which the communication is possible
between the sender and receiver.
akey - specifies the key which is shared between KDC and Sender.
These are preferably integer variables.
And Defines Methods
generate()- which generates the skey from random number
encrypta()- which defines procedure for encrypting skey with the akey.
send()-A predefined function in the language.
Respond class:
Declares data members(skey, bkey)
bkey- specifies the key which is shared between KDC and Receiver. Which is an
integer
and defines methods
decryptb()- which defines the procedure for decrypting skey from bkey.
acknowledge()- which defines the procedure for sending acknowledgement to
sender with skey.
receive()-A predefined function in the language.
Transmit class:
Declares data members (skey, akey, bkey)
Defines the methods
decrypta()- which defines the procedure for decrypting skey from akey.
63
encryptb()-which defines procedure for encrypting skey with the bkey.
send(), receive()- predefined functions of language.
In addition there exists 1-1 relation among classes
Sequence diagram for Sending key:(Behavioral View of the System)
s: Sender
:
: : : : : : Select a random number : : Number given : : : Generate : : skey : : : : : : : :
Request (Ready to send)
If not granted
: Waiting : Again make request
If not granted
If granted
Encrypt with akey
64
: Task Random selector
Sender win k: KDC Interface
: : : :
: :
Sequence diagram for collecting key:(Behavioral view of system)
r: Receiver
: : : : : : Message from KDC : :
::
: Decrypt : : bkey : :
: : : : Analyze :
skey ::
: : : :
Acknowledge skey
: : : :
65
Receiver win k: KDC interface
Receiver win s: Sender Interface
Sequence diagram for Transmitting key:(Behavioral view of the System)
k: KDC
:
: : : : : Message from Sender : :
::
: Decrypt : : akey : :
: : : : Analyze :
skey ::
: : : : : Encrypt :
bkey ::
: : : Message with bkey :
: : : : : : :
66
KDC win s : Sender interface
KDC win r : Receiver Interface
Explanation:
For sending Key:
There is an object “s” for sender and this describes the sequence of
messages and the task of sender.
First the Random selector class will select the Random number and generate the
session key based on the number.
The one headed arrow indicates one flow of statement. Then the sender requests
the KDC. If the request is not granted it waits.
Again the sender makes the request, and the cycle is repeated until the request is
granted
After granting the sender will send the key which contains the sender, receiver’s
identification which is encrypted with akey.
For collecting Key:
Here “r” is the instance of the receiver and it includes both sender and
KDC interfaces. The sequence of actions here here are:
After receiving the message with the arrow mark indicated, the message is
decrypted with bkey at receiver station itself. Hence it is denoted as the arrow
pointing to itself.
Then analyze the skey from the resultant message.
Acknowledge the sender with the skey shown as pointing arrow to sender
interface.
For transmitting Key:
Here “k” is the instance of KDC and it also includes both sender and
receiver interface objects.
After receiving the message with the arrow mark indicated, the message is
decrypted with akey at KDC station itself. Hence it is denoted as the arrow
pointing to itself.
67
Then analyze the skey from the resultant message.
Send the skey taken, to the receiver encrypted with the akey shown as pointing
arrow to receiver interface.
Detailed project Deployment Diagram:(Environmental View of the System)
68
A typical LAN
KDC asServer OrDesktopClient
Receive key (Executable)
Send key (Executable)
SenderAsDesktopClient
Send Key (Executable)
ReceiverAsDesktopClient
Receive Key (Executable)
Explanation:
In this there are three hardware devices that are to be connected.
Machine 1: (Sender): A computer system (Node) which acts as sender.
The sender is the client. This is represented as a cuboid box. The main
module in this is given as the component enclosed in a rectangle embedded other two
small rectangles. The main function of sender is given in that rectangle box i.e. send key
which is an executable function.
Machine 2: (Receiver): A computer system (Node) which acts as Receiver.
The Receiver is also client. This is represented as a cuboid box. Here also
the main module in this is given as the component enclosed in a rectangle embedded
other two small rectangles. The main function of Receiver is given in that rectangle box
i.e. receive key which is an executable function.
Machine 3: (KDC): A computer system (Node) which acts as KDC.
The KDC is a two way machine. This is represented as a cuboid box. It
may act as either client or server. It takes the Server role when it grants for the request of
sender and the same machine will act as client when it asks request for receiver. Here
also the main modules in this are given as the components enclosed in two rectangles
embedded other two small rectangles. The main function of KDC are given in that
rectangle boxes i.e. receive key from sender where it acts as serve which is an executable
function and the other is send key to receiver where it acts as client which is also an
executable function.
In addition to the above the other hardware requirement is:
LAN – A Local Area Network, This is used for interconnection of all these
Nodes. This establishes the connection and is used for passage of messages
between the nodes.
69
Detailed project Activity diagram:(Behavioral View of the system)
Initial state
Sender state of action
No
Yes
70
Select random number
Generate key based on random number
Request to KDC
Granting
request
Send encrypted message akey to KDC
A
KDCaction state
Receiver action state
71
A
Receive message from sender
Decrypt akey
Analyze skey
Encrypt with bkey of Responder
Send message to Receiver
Receive message from KDC
Decrypt bkey
Acknowledge sender (skey)
Final state
Explanation: Activity diagram represents the behavioral View of the system. This is
similar to the flow chart since it represents the sequence of actions that are represented in
the vowel shapes. It also contains an initial state which is represented as a darken circle in
the figure. Here also the whole system is divided into 3 phases
1. Sender state of action : This includes selection of number, generating key,
encrypting it with key of KDC and sending to KDC. All these are the actions that
are performed by the sender. Hence, the system upto this case is represented as
sender side function i.e. talking in the name of sender.
2. Transmitter state of action : This includes receiving message from sender,
decrypting the message, analyzing the key, again encrypting the message it shares
with receiver and sending to receiver. Hence, the system upto this case is
represented as Transmitter side function i.e. talking in the name of KDC.
3. Receiver state of action : This includes receiving message from KDC, decrypting
the message, analyzing the key, acknowledging the sender by encrypting the
message with the key it received from KDC. Hence, the system upto this case is
represented as Responder side function i.e. talking in the name of Receiver.
Then the sender and receiver can continue the messages with this key.
And then a final state is evaluated which is represented as darken circle enclosed within a
ring and this state tells there is no further message communication between the systems.
72
Detailed project State chart diagram: (Behavioral view of the system)
Select Random Generate Number skey (Event 1) (Event 2)
Initial State
Decrypt Encrypt bkey (Event 4)
akey (Event 3)
Acknowledge (Transition)(Event 6)(Transition)
Encrypt bkey (Event 5) (Transition)
Final state
Explanation: This also gives the behavioral view of the system. In this there are states
and events or transitions. State represent the current location of the system i.e. at this time
73
Intermediate state (Transmitter)
Target state (Responder)
Source state (Initiator)
at what position the system is at ? And Event or transition represents, upon the
occurrence of which event the system changes from one state to the other.
Initially the system starts at initial state and moves to source state. The system at this
state performs 2 transitions i.e. selection of random number and generation these events
do not cause a change of state and the system is in source state itself. Upon the
occurrence of Encryption with akey the system moves to Intermediate state. In this on the
occurrence of events decryption and analyzing key the system will have no transition to
next state, it still stays in the intermediate state itself. In this after occurring the event
encryption it moves to the target state and then to finish state.
In this the states are represented by rounded rectangles and events are by
arrows.
Detailed project Collaboration diagram: (Behavioral view of the system)
1. Sender, Receiver identification 2. Acknowledgement encrypted with ks
<<global>>
1: Sender, Receiver Identification 2: Session key encrypted with key ka
<<global>> <<global>>
1. Sender, Receiver Identification 2. Session key encrypted with key kb
74
S : Sender
K : KDC R : Receiver
Explanation: This represents the behavior of the system in a way that flow control can
be specified in the context of structural organization of objects that collaborate. Here path
is specified to show how the one object is linked to other. At the end the path has
stereotype to the far end of the link <<global>> indicating that the designated object is
globally accessible to sender. The diagram also includes the sequence numbers to specify
the time ordering of messages which prefix the message with a number.
75
76
5.1 Calculating Prime numbers between 10000 and 30000:
import java.io.*;
public class sw{
public static void main(String args[])throws Exception{
int x[]=new int[30000];
int i,j,l,flag,k;
for(i=10001,k=0;i<29997;i=i+2){
flag=1;for(j=2;j<i;j++){
if(i%j==0){
flag=0;break;
}}if(flag==1){
x[k]=i;k++;
}}for(i=0;i<k;i++){
System.out.print(x[i]+"\t");}System.out.println("\n\n\nNo. of numbers:"+k);
}}
77
5.1.1 Implementing Diffie Hellman on side A:
import java.io.*;import java.net.*;
public class skey{
public static void main(String args[])throws IOException{
int i,q,j=0,k,l,g,a,u=0;int p;
int y[]=new int[800];int b[] =new int[800];int x1[]=new int[800];int b1[] =new int[800];char ch;String s1="",s2="",s3="";int port = 800,clientPort=900;byte[] buffer = new byte[10240];
// Taking Input g and n:
DataInputStream d=new DataInputStream(System.in);System.out.println("enter g");String msg=d.readLine();System.out.println("enter n:");String msg1=d.readLine();int x=Integer.parseInt(msg1);int z=msg.length();
//Converting into individual bits:
for(i=z-1,k=0;i>=0;i--,k++){
y[k]=msg.charAt(i)-48;
}int n=Integer.parseInt(msg);k=0;
//Caluculation for g x :
for(i=0;i<n;i++)
78
{for(j=0;j<z;j++){
l=b[j]+y[j]+k;k=0;if(l>=10){
b[j]=l-10;k=1;
}else
b[j]=l;}if(k==1){
b[j]=1;z++;k=0;
}
}a=b[j-1];
//Caluculation for g x mod n:
for(i=j-2;i>=0;i--){
a*=10; a+=b[i]; u=a; if(a>=x) {
u=a%x;a=u;
}}System.out.println(u);while(u!=0){
switch(u%10){
case 0: s1+='0';break;
case 1: s1+='1';break;
79
case 2: s1+='2';break;
case 3: s1+='3';break;
case 4: s1+='4';break;
case 5: s1+='5';break;
case 6: s1+='6';break;
case 7: s1+='7';break;
case 8: s1+='8';break;
case 9: s1+='9';break;
}u=u/10;
}
System.out.println(s1);
for(i=s1.length()-1,k=0;i>=0;i--,k++){
s2+=s1.charAt(i);}s2+='\0';
//Sending to B :
System.out.println(s2);InetAddress ia = InetAddress.getByName("131.200.3.68");System.out.println(ia);DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);
String send = "g="+msg+",n="+msg1+",gXmodn="+s2;System.out.println(send);buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,clientPort);ds.send(dp);
System.out.println("message sent");
//Receiving g y mod n from B:
80
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);
String msg2 = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " +msg2);
String str="";
for(i=0;i<msg2.length();i++){
if(msg2.charAt(i)=='='){
for(j=i+1;j<msg2.length();j++){
str+=msg2.charAt(j);}a=Integer.parseInt(str);break;
}}
z=str.length();for(i=z-1,k=0;i>=0;i--,k++){
x1[k]=str.charAt(i)-48;
}
p=k-1;k=0;int y1=3;
//Caluculation for (g y mod n ) x mod n:
for(i=0;i<a;i++){
for(j=0;j<=p;j++){
l=b1[j]+x1[j]+k;k=0;if(l>=10){
81
b1[j]=l-10;k=1;
}else
b1[j]=l;}if(k==1){
b1[j]=1;p++;k=0;
}
}
p=b1[j-1];
for(i=j-2;i>=0;i--){
p*=10; p+=b1[i]; if(p>=x) {
u=p%x;p=u;
}}System.out.println("\nShared key must be:"+u);
}}
5.1.2 Implementing Diffie Hellman on side b:
import java.io.*;import java.util.regex.*;import java.lang.*;import java.util.*;import java.net.*;class sd{
public static void main(String args[])throws IOException{
//Receiving n, g, g x mod n from A
82
int port = 900,serverPort = 800;byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));InetAddress ia = InetAddress.getByName("131.200.3.69");DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);
int i,k,g,n,z,p,j,l,u,q,y,n1;j=0;l=0;u=0;int a[]=new int[40];int x[]=new int[800]; int b[] =new int[800];int c[]=new int[800];
sd m=new sd();
//Splitting the string received from A:
Pattern pat=Pattern.compile("[,]");String strs[]=pat.split(msg);
for(i=0;i<strs.length;i++){
for(j=0;j<strs[i].length();j++){
String str="";if(strs[i].charAt(j)=='='){
for(k=j+1;k<strs[i].length();k++){
str+=strs[i].charAt(k);
}System.out.println(str);a[l]=m.thro(str);System.out.println(a[l]);
83
l++;break;
}}
}
g=a[0];n=a[1];n1=a[2];z=strs[0].length();for(i=z-1,k=0;i>=2;i--,k++){
x[k]=strs[0].charAt(i)-48;
}p=k-1;k=0;y=3;
//Calculation of g y mod n :
for(q=0;q<n;q++){for(i=0;i<n;i++){
for(j=0;j<=p;j++){
l=b[j]+x[j]+k;k=0;if(l>=10){
b[j]=l-10;k=1;
}else
b[j]=l;}if(k==1){
b[j]=1;p++;k=0;
}
}
84
}
p=b[j-1];for(i=j-2;i>=0;i--){
p*=10; p+=b[i]; if(p>=n) {
u=p%n;p=u;
}}System.out.println("\ngY mod n="+u);String s1="",s2="";
while(u!=0){
switch(u%10){
case 0: s1+='0';break;
case 1: s1+='1';break;
case 2: s1+='2';break;
case 3: s1+='3';break;
case 4: s1+='4';break;
case 5: s1+='5';break;
case 6: s1+='6';break;
case 7: s1+='7';break;
case 8: s1+='8';break;
case 9: s1+='9';break;
}u=u/10;
}
System.out.println(s1);
85
for(i=s1.length()-1,k=0;i>=0;i--,k++){
s2+=s1.charAt(i);}s2+='\0';System.out.println(s2);
//Sending g y mod n to A
String send = "gY mod n="+s2;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);
n1=a[2];z=strs[2].length();for(i=z-1,k=0;i>=7;i--,k++){
x[k]=strs[2].charAt(i)-48;
}
p=k-1;k=0;y=3;
//Calcualtion for (g x mod n ) y mod n:
for(q=0;q<n1;q++){for(i=0;i<n1;i++){
for(j=0;j<=p;j++){
l=c[j]+x[j]+k;k=0;if(l>=10){
c[j]=l-10;k=1;
}else
c[j]=l;}
86
if(k==1){
c[j]=1;p++;k=0;
}
}}
p=c[j-1];for(i=j-2;i>=0;i--){
p*=10; p+=c[i]; u=p; if(p>=n) {
u=p%n;p=u;
}}System.out.println("\nshared key must be:"+u);
}int thro(String sen)throws NumberFormatException{
return(Integer.parseInt(sen));}
}
5.2.1 Implementing KDC at A:
import java.io.*;import java.net.*;//import java.math.*;
public class encrypta{
public static void main(String args[])throws IOException{
char pt[]=new char[40];int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0;long v;
87
int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";
System.out.println("enter message");
DataInputStream f=new DataInputStream(System.in);
String s=f.readLine();
encrypta m=new encrypta();
for(i=0;i<s.length();i++){
a[i]=m.convert(s.charAt(i));
}System.out.println("enter p q");p=Integer.parseInt(f.readLine());q=Integer.parseInt(f.readLine());n=p*q;z=(p-1)*(q-1);
for(i=2,k=0;i<z;i++){
if(z%i==0){
b[k]=i;k++;
}}fz=k-1;for(i=2;i<z;i++){
flag=0;for(j=2,k=0;j<=i;j++){
if(i%j==0){
c[k]=j;k++;
}
88
}fi=k;for(j=0;j<fz;j++){
for(k=0;k<fi;k++){
if(b[j]==c[k]){
flag=1;break;
}}
}if(flag==0 && i!=p && i!=q){
d=i;break;
}}
for(i=0;i<1000;i++){
if((i*d)%z==1){
e=i;break;
}}//Cipher text encrypted with ka:for(i=0;i<s.length();i++){
v=(long)Math.pow(a[i],e);cp[i]=v%n;System.out.print(cp[i]+" ");str+=cp[i];str+=" ";
}System.out.println("\n"+str);for(i=0;i<s.length();i++){
v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);
pt[i]=m.convert1(pl[i]);
}
89
System.out.println(pt);
int port = 900,serverPort = 800;//Sending Cipher text:
byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));
InetAddress ia = InetAddress.getByName("131.200.3.68");DatagramSocket ds;DatagramPacket dp;
ds = new DatagramSocket(port);String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);System.out.println("message sent:");
}
int convert(char a){
switch(a){
case 'a':case 'A':return 1;case 'b':case 'B':return 2;case 'c':case 'C':return 3;case 'd':case 'D':return 4;case 'e':case 'E':return 5;case 'f':case 'F':return 6;case 'g':case 'G':return 7;case 'h':case 'H':return 8;case 'i':case 'I':return 9;case 'j':case 'J':return 10;
90
case 'k':case 'K':return 11;case 'l':case 'L':return 12;case 'm':case 'M':return 13;case 'n':case 'N':return 14;case 'o':case 'O':return 15;case 'p':case 'P':return 16;case 'q':case 'Q':return 17;case 'r':case 'R':return 18;case 's':case 'S':return 19;case 't':case 'T':return 20;case 'u':case 'U':return 21;case 'v':case 'V':return 22;case 'w':case 'W':return 23;case 'x':case 'X':return 24;case 'y':case 'Y':return 25;case 'z':case 'Z':return 26;
case '0': return 27;case '1': return 28;case '2': return 29;case '3': return 30;case '4': return 31;case '5': return 32;case '6': return 33;case '7': return 34;case '8': return 35;case '9': return 36;
}return 0;
91
}
char convert1(int vl){switch(vl){
case 1:return 'a';case 2:return 'b';case 3:return 'c';case 4:return 'd';case 5:return 'e';case 6:return 'f';case 7:return 'g';case 8:return 'h';case 9:return 'i';case 10:return 'j';case 11:return 'k';case 12:return 'l';case 13:return 'm';case 14:return 'n';case 15:return 'o';case 16:return 'p';case 17:return 'q';case 18:return 'r';case 19:return 's';case 20:return 't';case 21:return 'u';case 22:return 'v';case 23:return 'w';case 24:return 'x';case 25:return 'y';case 26:return 'z';
case 27:return '0';case 28:return '1';case 29:return '2';case 30:return '3';case 31:return '4';case 32:return '5';case 33:return '6';case 34:return '7';case 35:return '8';case 36:return '9';
92
}return 0;}
}5.2.2 Code at KDC:import java.util.regex.*;
public class decypta{
public static void main(String args[])throws IOException{
int port = 800,clientPort=900;byte[] buffer = new byte[1024];
//Receiving Cipher text:
InetAddress ia = InetAddress.getByName("131.200.3.69");System.out.println(ia);BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);
String pt="";String pt1="";int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0,p1,q1,n1,z1;long v;int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";
Pattern pat=Pattern.compile("[ ]");String strs[]=pat.split(msg);
for(i=0;i<strs.length;i++){
cp[i]=Integer.parseInt(strs[i]);
93
System.out.println(cp[i]);
}DataInputStream f=new DataInputStream(System.in);System.out.println("enter p q");p=Integer.parseInt(f.readLine());q=Integer.parseInt(f.readLine());n=p*q;z=(p-1)*(q-1);
decrypta m=new decrypta();for(i=2,k=0;i<z;i++){
if(z%i==0){
b[k]=i;k++;
}}fz=k-1;for(i=2;i<z;i++){
flag=0;for(j=2,k=0;j<=i;j++){
if(i%j==0){
c[k]=j;k++;
}}fi=k;for(j=0;j<fz;j++){
for(k=0;k<fi;k++){
if(b[j]==c[k]){
flag=1;break;
}}
}if(flag==0 && i!=p && i!=q){
d=i;
94
break;}
}
for(i=0;i<1000;i++){
if((i*d)%z==1){
e=i;break;
}}//Decrypting with ka
for(i=0;i<strs.length;i++){
v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);
pt+=m.convert1(pl[i]);}System.out.println(pt);
System.out.println("enter p1 & q1");p1=Integer.parseInt(f.readLine());q1=Integer.parseInt(f.readLine());n1=p1*q1;z1=(p1-1)*(q1-1);
for(i=0;i<pt.length();i++){
a[i]=m.convert(pt.charAt(i));
}
for(i=2,k=0;i<z1;i++){
if(z1%i==0){
b[k]=i;k++;
}}fz=k-1;for(i=2;i<z1;i++){
flag=0;
95
for(j=2,k=0;j<=i;j++){
if(i%j==0){
c[k]=j;k++;
}}fi=k;for(j=0;j<fz;j++){
for(k=0;k<fi;k++){
if(b[j]==c[k]){
flag=1;break;
}}
}if(flag==0 && i!=p1 && i!=q1){
d=i;break;
}}
for(i=0;i<1000;i++){
if((i*d)%z==1){
e=i;break;
}}
//Encrypting with ka
for(i=0;i<pt.length();i++){
v=(long)Math.pow(a[i],e);cp[i]=v%n1;System.out.print(cp[i]+" ");str+=cp[i];str+=" ";
}
96
System.out.println("\n"+str);for(i=0;i<pt.length();i++){
v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n1);
pt1+=m.convert1(pl[i]);
}System.out.println(pt1);
System.out.println(str);
//Sending to B:
String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,clientPort);ds.send(dp);System.out.println("message sent:");
}}5.2.3 Code at B:
import java.io.*;import java.net.*;//import java.math.*;import java.util.regex.*;
public class decryptb{
public static void main(String args[])throws IOException{
int port = 900,serverPort=800;byte[] buffer = new byte[1024];
//Receiving Cipher text from KDC:
InetAddress ia = InetAddress.getByName("131.200.3.68");System.out.println(ia);BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);
97
ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);
String pt="";String pt1="";int i,k,p,q,n,z,e=0,d=0,j,fz,fi,flag=0,p1,q1,n1,z1;long v;int x;long cp[]=new long[40];int pl[]=new int[40];int a[]=new int[40];int b[]=new int[40];int c[]=new int[40];String str="";
Pattern pat=Pattern.compile("[ ]");String strs[]=pat.split(msg);
for(i=0;i<strs.length;i++){
cp[i]=Integer.parseInt(strs[i]);System.out.println(cp[i]);
}decyyptb m=new decryptb();DataInputStream f=new DataInputStream(System.in);System.out.println("enter p q");String str1=f.readLine();String str2=f.readLine();p=m.thro(str1);q=m.thro(str2);n=p*q;z=(p-1)*(q-1);
for(i=2,k=0;i<z;i++){
if(z%i==0){
b[k]=i;k++;
}}fz=k-1;for(i=2;i<z;i++)
98
{flag=0;for(j=2,k=0;j<=i;j++){
if(i%j==0){
c[k]=j;k++;
}}fi=k;for(j=0;j<fz;j++){
for(k=0;k<fi;k++){
if(b[j]==c[k]){
flag=1;break;
}}
}if(flag==0 && i!=p && i!=q){
d=i;break;
}}
for(i=0;i<1000;i++){
if((i*d)%z==1){
e=i;break;
}}//Decryption with kb:
for(i=0;i<strs.length;i++){
v=(long)Math.pow(cp[i],d);pl[i]=(int)(v%n);
pt+=m.convert1(pl[i]);}
99
System.out.println(pt);
}int thro(String s1){
return(Integer.parseInt(s1));}
}
5.3.1 Message Encryption with Diffie Hellman and KDC:
import java.io.*;import java.net.*;public class diffie1{
public static void main(String args[])throws IOException{
int a[]=new int[100];int b[]=new int[100];char cp[]=new char[100];char p[]=new char[100];
int i;DataInputStream d=new DataInputStream(System.in);System.out.println("enter message:");diffie1 m=new diffie1();String msg=d.readLine();String str="";for(i=0;i<msg.length();i++){
a[i]=m.convert(msg.charAt(i));
}System.out.println("enter ur secret key:");int key=Integer.parseInt(d.readLine());
//Double modulo operations:
int key1=key%36;System.out.println("key1"+key1);for(i=0;i<msg.length();i++){
b[i]=(a[i]+key1)%36;cp[i]=m.convert1(b[i]);str+=cp[i];
100
System.out.println(cp[i]);}for(i=0;i<msg.length();i++){
a[i]=m.convert(cp[i]);}
for(i=0;i<msg.length();i++){
if(a[i]<key1)a[i]=a[i]+36;
b[i]=(a[i]-key1)%36;p[i]=m.convert1(b[i]);System.out.println(p[i]+" ");
}
int port = 900,serverPort = 800;byte[] buffer = new byte[1024];BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));InetAddress ia = InetAddress.getByName("131.200.3.68");DatagramSocket ds;DatagramPacket dp;
ds = new DatagramSocket(port);String send = str;buffer = send.getBytes();dp = new DatagramPacket(buffer,buffer.length,ia,serverPort);ds.send(dp);System.out.println("message sent:");}
5.3.2 Message Encryption with Diffie Hellman and KDC:
import java.io.*;import java.net.*;//import java.math.*;import java.util.regex.*;
public class diffie2{
public static void main(String args[])throws IOException{
int port = 800,clientPort=900;byte[] buffer = new byte[1024];
101
InetAddress ia = InetAddress.getByName("131.200.3.69");System.out.println(ia);BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));DatagramSocket ds;DatagramPacket dp;ds = new DatagramSocket(port);dp = new DatagramPacket(buffer,buffer.length);ds.receive(dp);String msg = new String(dp.getData(),0,dp.getLength());System.out.println("Received: " + msg);
int a[]=new int[100];int b[]=new int[100];char cp[]=new char[100];char p[]=new char[100];
int i;DataInputStream d=new DataInputStream(System.in);diffie2 m=new diffie2();
System.out.println("enter ur secret key:");int key=Integer.parseInt(d.readLine());int key1=key%36;System.out.println("key1"+key1);
for(i=0;i<msg.length();i++){
a[i]=m.convert(msg.charAt(i));}
for(i=0;i<msg.length();i++){
if(a[i]<key1)a[i]=a[i]+36;
b[i]=(a[i]-key1)%36;p[i]=m.convert1(b[i]);System.out.println(p[i]+" ");
}}
102
5.4 Interpretation of Results:5.4.1 Output at Sender station of DH algorithm:
103
5.4.2 Output at Receiver station of DH algo:
104
5.4.3 Output at A of KDC:
5.4.4 Output at KDC station:
105
106
5.4.5 Output at B of KDC:
5.4.6 Output for Sending of messages from either DH algo or KDC:
107
5.4.7 Output for Receiving of messages from either DH algo or KDC:
108
109
Modern cryptography uses the same basic ideas as traditional
cryptography (transposition and substitution) but its emphasis is different. Traditionally,
cryptographers have used simple algorithms. Now a days the reverse is true: the object is
110
to make the encryption algorithm so complex and involuted that even if the cryptanalyst
acquires vast mounts of enciphered text of his own choosing, he will not be able to make
any sense of it at all without the key.
Distributing the keys have always been the weakest link in most
cryptosystems. No matter how strong the cryptosystem was, if an intruder could steal the
key, the system is worthless.
Hence, as a first attempt at distributing the public keys the two parties
again use encryptions based on the modulo operation on some powers of some very large
prime natural numbers. The approach we proposed was that a third party distribution of a
key to the communicating parties. The main assumption of approach is that the third
party we have taken for distribution of the session key was trustworthy.
6.1. The possibilities for the extension of the project are:
6.1.1. KDC using KERBEROS:
The Kerberos protocol always deals with three entities: two entities that
want to authenticate to one another and one entity that mediates between these two
entities for authentication: the Key Distribution Center (KDC).
Suppose that Alice is part of a workgroup consisting of five entities, which
all want to authenticate to one another using symmetric key cryptography. Since every
entity needs to share a secret key with every other entity, we’ll need ten keys. The
mathematical formula behind this is n (n — 1)/2. Similarly, in a 50,000-employee
company we would need about 1,500,000,000 keys. Not only would we have to deal with
an enormous amount of keys, there would also be an enormous amount of small
authentication databases: There would be one on every client, containing all the secret
keys of the entities the client wants to authenticate. This solution is clearly not scalable at
the level of a large company.
In chapter 1 we already discussed the Kerberos protocol. And to make this
Kerberos more scalable the Kerberos developers included the concept of a Key
Distribution Center (KDC). The Key Distribution Center (KDC) is a trusted third party
with whom every entity shares a secret key. This key is called the entity’s master key. All
111
entities trust the KDC to mediate in their mutual authentication. The KDC also maintains
a centralized authentication database containing a copy of every user’s master key.
Kerberos maintains a database of secret keys; each entity on the network
— whether a client or a server — shares a secret key known only to itself and to
Kerberos. Knowledge of this key serves to prove an entity's identity. For
communication between two entities, Kerberos generates a session key which they
can use to secure their interactions.
6.1.2 KDC with PUBLIC KEY CRYPTOGRAPHY
Mutual authentication can also be done using public key cryptography for
the purpose of session key distribution. This protocol assumes that each of two parties is
in possession of the current public key of the other. It may not be practical to require this
assumption.
The tickets in Kerberos that are provided to clients are encrypted twice,
once with the secret key of the target server and then again with the secret key known to
the client. The second encryption is not necessary and is computationally wasteful.
Each ticket includes a session key that is used by the client to encrypt the
authenticator sent to the service associated with that ticket. In addition, the session key
may subsequently be used by the client and the server to protect messages passed during
that session. However, because the same ticket may be used repeatedly to gain service
from particular server, there is the risk that an opponent will replay messages from an old
session to the client or the server.
The message from authentication server to client includes material
encrypted with a key based on client password. An opponent can capture this message
and attempt to decrypt it by trying various passwords. If the result of a test decryption is
one of the proper form, then the opponent has discovered the client’s password and may
subsequently use it to gain authentication credentials from Kerberos.
6.1.3 KDC with NONCES:
In the chapter 3 of our proposed approach we have stated the number of
ways sending the secret key between the parties with key distribution center.
The one way in that uses this NONCES
112
The method defines that KDC itself has to select the key and it should
supply the key to both the communication parties. There by, they both communicate by
using that key. A brief approach to the communication among KDC, and the partners of
session key say A, B is shown below.
1. A issues a request to protect a logical connection to B. The message includes the
identity of A and B and a unique identifier, N1, for this transaction, which we
refer to NONCE. The Nonce may be a random number. It should very clear that
this NONCE we are keeping must be different for every message send.
2. Then KDC responds to this message by KA. Thus, A is the only one who can
successfully receive the message, and A knows that it originated at KDC. This
message includes two items intended for A.
The one time session key, Ks, to be used for the session.
The original request message, including the NONCE, to enable A to match
this reception by the KDC and, because of nonce, that this is not a replay
of some previous request.
In addition, the message includes two items intended for B.
The one time session key, Ks, to be used for the session.
An identifier to A (e.g.: its network address), IDA .
These messages that are intended for B are encrypted with KB ( the key that
KDC shares with B). They are sent to B to establish the connection and prove
A’s identity.
3. A stores the session key for use in upcoming session and forwards to B the
information that originated at KDC for B. Because this information is encrypted
with KB, it is protected from eaves dropping. B now knows the session key Ks,
and also knows the other party i.e. A also knows the session key Ks.
At this point session key has been securely exchanged between the parties and
hence now they can exchange the messages using this key without any fear.
However, two additional steps are desirable.
4. Using the newly minted session key for encryption, B sends a Nonce, N2, to A.
113
5. Also using Ks, A responds with f (N2), where f is a function that performs some
transformation on N2 (e.g., adding one).
These steps assure B that the original message it received was not replay.
Timestamps described above can be combined with these nonces to limit
how long nonces have to be remembered, but clearly the protocol is going to get a lot
more complicated.
6.1.4 KDC as CERTIFIED AUTHORITY:
This method assumes a global hierarchy of certifying authorities at least
one of which is trusted by each party. It uses digital signatures that consist of a token
encrypted in the private key of the signing entity and that are validated using the
appropriate public key. The public keys are believed to be correct as they are obtained
under the signature of the trusted certification authority. Critical parts of the
authentication exchange are encrypted in the public keys of the receivers, thus preventing
a replay attack.
Digital signatures are public key signature schemes the private-key signs
(creates) signatures, and the public-key verifies signatures. Only the owner (of the
private-key) can create the digital signature, hence it can be used to verify who created a
message. Anyone knowing the public key can verify the signature (provided they are
confident of the identity of the owner of the public key - the key distribution problem).
Usually they don't sign the whole message (doubling the size of information exchanged),
but just a hash of the message. Digital signatures can provide non-repudiation of message
origin, since an asymmetric algorithm is used in their creation, provided suitable
timestamps and redundancies are incorporated in the signature.
Here KDC acts as CERTIFIED AUTHORITY which signs the key
assuring from correct one ensuring the digital signature mechanism. Thus method is
mostly used for web traffic applications.
6.2 Conclusion:
Hence the KDC is a system that is authorized to transmit temporary
session keys to principals. Each session key is transmitted in encrypted form, using a
master key that the KDC shares with target principal. The overall work that we
114
implement is generating of key, sending to KDC and KDC in turn sending to receiver
their by the so called authentication will be completed.
The best way to stop any type of hacking is to think like hacker. Our
approach shows how hackers see a network, and argues that security should be a function
of the entire network’s design, not an afterthought based on specific technology. It covers
almost all common attacks that take advantage of users who are not always with security
measures.
115
References:
http://www.cs.ucsd.edu/users/mihir/papers/key-distribution.html
McCarthy's bibliography on key distribution
www.acsac.org/2005/papers/49.pdf
www.searchsecurity.com
www.advanedsecurityreserch.com
www.google.com
www.wikipedia.com
Computer networks –Andrew s. Tanenbaum
Network security and cryptography- William Stallings
116
117
118
119
120
121