INTRODUCTION TO PROJECT

IMPLEMENTATION OF AUTHENTICATION SYSTEM USING

KERBEROS IN CHAT APPLICATION
A. Kerberos
The Internet is an insecure place. Many of the protocols used in the Internet do not provide any
security. Tools to "sniff" passwords off of the network are in common use by malicious hackers.
Thus, applications which send an unencrypted password over the network are extremely
vulnerable. Worse yet, other client/server applications rely on the client program to be "honest"
about the identity of the user who is using it. Other applications rely on the client to restrict its
activities to those which it is allowed to do, with no other enforcement by the server.

Some sites attempt to use firewalls to solve their network security problems. Unfortunately,
firewalls assume that "the bad guys" are on the outside, which is often a very bad assumption.
Most of the really damaging incidents of computer crime are carried out by insiders. Firewalls also
have a significant disadvantage in that they restrict how your users can use the Internet. (After all,
firewalls are simply a less extreme example of the dictum that there is nothing more secure than a
computer which is not connected to the network --- and powered off!) In many places, these
restrictions are simply unrealistic and unacceptable.

KERBEROS MECHANISM

UE133010, UE133042 Page 1

Kerberos is a network authentication protocol. It is designed to provide strong authentication for
client/server applications by using secret-key cryptography. Kerberos is available in many
commercial products.

Kerberos was created by MIT as a solution to these network security problems. The Kerberos
protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa)
across an insecure network connection. After a client and server has used Kerberos to prove their
identity, they can also encrypt all of their communications to assure privacy and data integrity as
they go about their business.

B. Advanced Encryption Standard (AES)

The Advanced Encryption Standard (AES), also known as Rijndael (its original name), is a
specification for the encryption of electronic data established by the U.S. National Institute of
Standards and Technology (NIST) in 2001. AES is a subset of the Rijndael cipher developed by
two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal to NIST
during the AES selection process.Rijndael is a family of ciphers with different key and block sizes.

For AES, NIST selected three members of the Rijndael family, each with a block size of 128 bits,
but three different key lengths: 128, 192 and 256 bits.

AES has been adopted by the U.S. government and is now used worldwide. It supersedes the Data
Encryption Standard (DES), which was published in 1977. The algorithm described by AES is a
symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the
data.

C. CHAT APPLICATION
A chat application facilitates communication between two or more clients over a network. The
communication may be in the form of text messages, images, audio or video. A chat application
uses the basic concept of socket programming of the TCP layer to transfer data. A chat application
does not inherently provide any security mechanism to ensure integrity of communication between
clients, unless an external encryption mechanism for messages is employed. A chat application
uses the traditional client-server architecture to facilitate transmission of messages among several
clients. There are several commercial chat applications available on various platforms for free like:

 Whatsapp

 Hike

 Google allo

 Yahoo messenger

 Facebook messenger

UE133010, UE133042 Page 2

  Google hangouts

CLIENT-SERVER ARCHITECTURE

UE133010, UE133042 Page 3

 REQUIREMENT AND FEASIBILITY STUDY
A. SOFTWARE REQUIREMENTS
1) JAVA
Java  is a general-purpose computer programming language that is concurrent, class-based, object-
oriented and specifically designed to have as few implementation dependencies as possible. It is
intended to let application developers "write once, run anywhere" (WORA), meaning
that compiled Java code can run on all platforms that support Java without the need for
recompilation.  Java applications are typically compiled to byte code that can run on any Java
virtual machine (JVM) regardless of computer architecture. As of 2015, Java is one of the most
popular programming languages in use, particularly for client-server web applications, with a
reported 9 million developers. Java was originally developed by James Gosling at Sun
Microsystems (which has since been acquired by Oracle Corporation) and released in 1995 as a
core component of Sun Microsystems' Java platform. The language derives much of
its syntax from C and C++, but it has fewer low-level facilities than either of them.

The original and reference implementation Java compilers, virtual machines, and class

libraries were originally released by Sun under proprietary licences. As of May 2007, in
compliance with the specifications of the Java Community Process, Sun relicensed most of its Java
technologies under the GNU General Public License. Others have also developed alternative
implementations of these Sun technologies, such as the GNU Compiler for Java (byte code
compiler), GNU Class path (standard libraries), and Iced Tea-Web (browser plugin for applets).
The latest version is Java 8, which is the only version currently supported for free by Oracle,
although earlier versions are supported both by Oracle and other companies on a commercial basis.

Principles

There were five primary goals in the creation of the Java language:

1. It must be "simple, object-oriented, and familiar".

2. It must be "robust and secure".
3. It must be "architecture-neutral and portable".
4. It must execute with "high performance".
5. It must be "interpreted, threaded, and dynamic".

UE133010, UE133042 Page 4

Java platform

One design goal of Java is portability, which means that programs written for the Java platform
must run similarly on any combination of hardware and operating system with adequate runtime
support. This is achieved by compiling the Java language code to an intermediate representation
called Java byte code, instead of directly to architecture-specific machine code. Java byte code
instructions are analogous to machine code, but they are intended to be executed by a virtual
machine (VM) written specifically for the host hardware. End users commonly use a Java Runtime
Environment (JRE) installed on their own machine for standalone Java applications, or in a web
browser for Java applets.
Standard libraries provide a generic way to access host-specific features such as
graphics, threading, and networking.
The use of universal byte code makes porting simple. However, the overhead of interpreting byte
code into machine instructions makes interpreted programs almost always run more slowly than
native executables. However, just-in-time (JIT) compilers that compile byte codes to machine code
during runtime were introduced from an early stage. Java itself is platform-independent, and is
adapted to the particular platform it is to run on by a Java virtual machine for it, which translates
the Java byte code into the platform's machine language.
Java uses an automatic garbage collector to manage memory in the object lifecycle. The
programmer determines when objects are created, and the Java runtime is responsible for
recovering the memory once objects are no longer in use. Once no references to an object remain,
the unreachable memory becomes eligible to be freed automatically by the garbage collector.
Something similar to a memory leak may still occur if a programmer's code holds a reference to an
object that is no longer needed, typically when objects that are no longer needed are stored in
containers that are still in use. If methods for a nonexistent object are called, a "null pointer
exception" is thrown.

UE133010, UE133042 Page 5

2) MYSQL
MySQL  is an open-source relational database management system (RDBMS); in July 2013, it was
the world's second most widely used RDBMS, and the most widely used open source client–
server model RDBMS. It is named after co-founder Michael Widenius's daughter, My.
The SQL acronym stands for Structured Query Language. The MySQL development project has
made its source code available under the terms of the GNU General Public License, as well as
under a variety of proprietary agreements. MySQL was owned and sponsored by a single for-
profit firm, the Swedish company MySQL AB, now owned by Oracle Corporation. For proprietary
use, several paid editions are available, and offer additional functionality.
MySQL is a popular choice of database for use in web applications, and is a central component of
the widely used LAMP open source web application software stack (and other "AMP" stacks).
LAMP is an acronym for "Linux, Apache, MySQL, Perl/PHP/Python." Free-software-open source
projects that require a full-featured database management system often use MySQL. Applications
that use the MySQL database
include: TYPO3, MODx, Joomla, WordPress, phpBB, MyBB, Drupal and other software. MySQL is
also used in many high-profile, large-scale websites, including Google (though not for
searches),Facebook, Twitter, Flickr, and YouTube.
On all platforms except Windows, MySQL ships with no GUI tools to administer MySQL databases
or manage data contained within the databases. Users may use the included command
line tools, or install MySQL Workbench via a separate download. Many third party GUI tools are
also available.

DATABASE

A database is a separate application that stores a collection of data. Each database has one or
more distinct APIs for creating, accessing, managing, searching and replicating the data it holds.

Other kinds of data stores can be used, such as files on the file system or large hash tables in
memory but data fetching and writing would not be so fast and easy with those types of systems.

So nowadays, we use relational database management systems (RDBMS) to store and manage
huge volume of data. This is called relational database because all the data is stored into different
tables and relations are established using primary keys or other keys known as foreign keys.

A Relational Data Base Management System (RDBMS) is software that:

 Enables you to implement a database with tables, columns and indexes.

 Guarantees the Referential Integrity between rows of various tables.

UE133010, UE133042 Page 6

  Updates the indexes automatically.

 Interprets an SQL query and combines information from various tables.

3) PLATFORM

The platform used for development as well as operation of this chat application is Microsoft
Windows 8. Windows 8 is a personal computer operating system developed by Microsoft as part of
the Windows NT family of operating systems. Development of Windows 8 started before the
release of its predecessor, Windows 7, in 2009. Windows 8 introduced major changes to the
operating system's platform and user interface to improve its user experience on tablets, where
Windows was now competing with mobile operating systems, including Android and iOS. In
particular, these changes included a touch-optimized Windows shell based on Microsoft's "Metro"
design language, the Start screen (which displays programs and dynamically updated content on a
grid of tiles), a new platform for developing "apps" with an emphasis on touchscreen input and
integration with online services (including the ability to synchronize apps and settings between
devices). Windows 8 added support for USB 3.0, Advanced Format hard drives, near field
communications, and cloud computing.

The chat application is also compatible with other versions of Windows:

 Windows XP

 Windows 7

 Windows 8.1

 Windows 10

UE133010, UE133042 Page 7

 Windows Command Prompt used for application control

B. HARDWARE REQUIREMENTS
 RAM (RANDOM ACCESS MEMORY)
Random-access memory (RAM ) is a form of computer data storage. A random-access
memory device allows data items to be read or written in almost the same amount of time
irrespective of the physical location of data inside the memory.
RAM used for development was 4GB but the application is compatible with RAM greater
than or equal to 512 MB.
 INTEL i3 PROCESSOR
The Intel i3-3110 processor with 2.40 GHz processing clock speed was used. The Intel
Core i3-3110M is a dual-core processor for laptops based on the Ivy Bridge architecture.
Due to Hyperthreading, the two cores can handle up to four threads in parallel leading to
better utilization of the CPU. Each core offers a base speed of 2.4 GHz, Turbo Boost is not
supported. As its Sandy-Bridge-based predecessors, it offers a 3 MB L3-Cache.
 NIC (Network Interface Card)
Ralink RT3290 NIC was utilized in development and testing of the project. A network
interface controller is a computer hardware component that connects a computer to a computer
network. Early network interface controllers were commonly implemented on expansion cards that
plugged into a computer bus. The low cost and ubiquity of the Ethernet standard means that most
newer computers have a network interface built into the motherboard.
 HP NOTEBOOK LAPTOP
HP laptop was used to perform development of the project. The laptop carried above
mentioned hardware and software specifications to aid the process of development. The
project can operate on any system with necessary minimum specifications.

UE133010, UE133042 Page 8

C. FEASIBILITY STUDY
This project utilizes following resources:

-> Java Development Kit

-> Kerberos ticket granting service

-> Java Network Packages

-> Sun Microsystem Encoder and Decoder Libraries for AES

->AWT library

->Ralink rt3290 adapter

-> Intel i3 processor

The hardware and software requirements for this project are economical and easily available. This
helps to develop efficient and economically viable application.

This project is being developed to study and analyse secure authentication protocol. Kerberos is
one of the most secure and most used protocol used in file sharing like NFS and other resource
sharing.

This will give an insight to how the authentication protocol is implemented and secure
communication is based on it.

UE133010, UE133042 Page 9

The chat application being implemented using Kerberos and AES authentication system provides
double security layer to ensure privacy and integrity to user data transfer. This also provides end to
end encryption to users. These facilities of security have not been implemented in large scale
commercial chat applications widely in use. Hence, this is a step towards enhancing user security
and privacy in digital sphere.

PRODUCT DESIGN
A) TECHNOLOGIES USED
I) KERBEROS
In the real world, identification is something we, as human beings, do naturally: through physical
appearance, voice patterns, or even scent. It is based on the assumption that those attributes are
unique, and that they can be trusted. This ability provides us with the possibility to distinguish one
person from another.
However, when put in a situation where we're not able to use those attributes to identify someone,
as in a phone call for example, we're left with finding some other means to prove our identitys. We
sometimes identify ourselves with what is called a "shared secret", where one party asks the other
party to prove his identity through information that is only known by both, like a password.
When we add a computer to this mechanism, with an identification that needs to be provided over
a network, things are going a little more complex. Sending this "shared secret", or password, over
an unsecured network can be compared to shouting your password in a crowded room.
Many authentication mechanisms were developped during the last decade to solve those problems;
Kerberos is one of them. Often seen as an advanced system that offers many more advantages over
commonly used setups, such as distributed authentication based on Network Information Server
(NIS).
As Kerberos is only dealing with Authentication, it does neither Authorization (the step of granting
or denying access to a service based on the user wishing to use it), nor Accounting (account and
session management, as well as logging): it delegates those to the services requesting Kerberos'
help for user's identification. Anyway, Kerberos being a "service" by itself, it can partially provide
such functionalities, but in a very limited range.

UE133010, UE133042 Page 10

Kerberos, being a protocol, has many implementations, developed for different purposes:
 MIT Kerberos. The original one; comes from the Project Athena in early 90s. Due to
exportation restrictions on cryptography technology, another implementation of Kerberos
was developped, in Sweden: Heimdal.
 Heimdal Kerberos. Is MIT Kerberos’ Swedish counterpart. Heimdal is not restricted by
exportation rules. Originally developed in Sweden, it aims to be fully compatible with MIT
Kerberos. Since MIT export restrictions were lifted in 2000, both implementations tends to
coexist on a wider scale.
 Active Directory. Not a Kerberos implementation by itself, but kind of. It’s the
Microsoft's directory, that consist of a loose Kerberos implementation with some other
services (LDAP). It's not directly compatible with MIT and Heimdal.
 TrustBroker. A commercial implementation of Kerberos protocol, developped by
CyberSafe. Supports a wide range of Operating Systems (Windows, Unix, Linux, ...), and
offers full interoperability with many existing Kerberos implementations, from MIT to
Microsoft's AD.
 Shishi. A GNU implementation of Kerberos 5.

Ticket Exchange Service

Kerberos' communication is built around the Needham- Shroeder protocol (NS protocol).
Described in a paper published in 1978 by Roger Needham and Michael Shroeder, it is designed to
provide a distributed secure authentication service, through secret key cryptography. All
those keys are secrets shared by the two ends of a Kerberos connection. It differs from
asymmetric systems, like SSL or IPsec, where a public key is known by virtually everybody,
while the private key remains secret, and stored on the server.
For a user, the secret key is his "hashed password" (the password is reworked through a oneway
hash function and the resulted string is used as a key), usually stored in the Key Distribution
Center. For a service, the key is a random generated sequence, acting like a password; it is also
stored in Key Distribution Center, and in a file called a keytab on the machine's service side.

For this schema to work, clients and services have to trust a third party service (the Kerberos
server), that is capable of issuing the required keys on demand.

The Kerberos communication is based around tickets. Tickets are a kind of encrypted data
scheme that is transmitted over the network, and stored on the client's side. The type of storage

UE133010, UE133042 Page 11

depends on the client's operating system and configuration. Traditionally, it's stored as a small file
in /tmp, for compatibility reasons: each OS has some kind of filesystem, able to save data.

The main central part of a Kerberos network is the the Key Distribution Center (KDC). It consists
of three parts:

1. an Authentication Server, which answers requests for Authentication issued by clients.

Here, we're in the AS_REQUEST and AS_REPLY challenging part (see below for
details),where the client gets a Ticket Granting Ticket (TGT).
2. a Ticket Granting Server, which issues Ticket Granting Service (TGS) to a client. This is
the TGS_REQUEST and TGS_REPLY part, where a client gets a TGS that allows him to
authenticate to a service accessible on the network.
3. a database, that stores all the secret keys (clients' and services' ones), as well as some
information relating to Kerberos accounts (creation date, policies, ...).
Usually, the KDC is a distinguished machine on the network, dedicated only to serve Kerberos
services. This is mainly for security purposes: since the KDC stores the database containing all the
secret keys, a compromised KDC allows the attacker to impersonate any service and client stored
in KDC's database. Kerberos accounts are named through principals, the equivalent of the
username for a Unix account.

Authentication mechanism—Ticket Granting Tickets

Authentication mechanism is the first step to be done in a Kerberos environment. It provides the
user with a Ticket Granting Ticket (TGT), that serves post-authentication for later access to
specific services.

Pre-authentication

Originally, Kerberos 4 protocol implementation was subject to off line attacks and brute force
cracking on tickets. This was due to the fact that the KDC issued a TGT with a principal's secret
key on each request for an authentication. A malicious guy could recursively ask for TGTs using
different principals, get the tickets, and try to brute force the user's long term key off line. To solve
this security flaw, Kerberos 5 introduced pre-authentication methods. The principle lies in the
necessity that the client identifies himself to the KDC first before getting a TGT. This way, an
attacker must contact the KDC each time he tries a new password.

1st step: Authentication Service Request—AS_REQUEST

This is the first message sent to the KDC, in plain text. It contains:
 the client's principal name,
 the Ticket Granting Server's principal (termed "krbtgt principal", needed to obtain further
TGS),
 the client timestamp,
 the requested ticket lifetime (usually, 8 to 10 hours long).
The KDC receives this message, check if the client's principal has a match in the database, and if
the timestamp between client's machine and KDC are close enough (typically, 3 to 5 min). This

UE133010, UE133042 Page 12

timestamp's check does not prevent replay; it's only used as way to early warn the user from an
incorrect time synchronization, before going any further into authentication.

If pre-authentication is mandatory, KDC won't return a TGT. Instead, it will send a

NEEDED_PREAUTH message, and ask the client to provide some pre-authentication data before
delivering the TGT. traditionally, the method used is PA-ENC-TIMESTAMP, where the current
timestamp is encrypted using the user's key, known on the client's side through password.

In this case, the client re-send an AS_REQUEST message, this time with the encrypted timestamp
included. Given a successful pre-authentication, KDC will return a TGT; this is the AS_REPLY
step.

2nd step: Authentication Service Reply—AS_REPLY

Upon checking, the Authentication Server generates a random session key ("short term" key). The
KDC makes two copies of it: one is for the client, and is added to the AS_REPLY message, the
second copy remains available for the Ticket Granting Server. This key is mainly used for later
negotiations for other tickets concerning kerberized services. Provided the client succeeded in his
authentication, the KDC will return an AS_REPLY message, containing the Ticket Granting
Ticket. It will be stored in some kind of credential cache, for future use. The message is encrypted
with the user's key, thus preventing any impersonator from decoding it.

The AS_REPLY message is formed of two layers; the first one is encrypted with the user's key,
while the second layer is the TGT itself, first encrypted with the Ticket Granting Server's key, then
re-encrypted with the user's key. This way, only the trusted user is able to decipher the message
and get the TGT.
The content of the AS_REPLY message is as follows:
 encrypted with user's key:
 copy of session key for user
 Ticket lifetime
 krbtgt principal name
 first encrypted with Ticket Granting Server's key, then user's key. This is the TGT:
 copy of session key
 effective ticket lifetime
 KDC timestamp
 client principal
 client IP address

Note: Although the TGT is decrypted and cached onto the client, its content cannot be read on the
client's side. It is effectively encrypted with the Ticket Granting Server's key, which is only known
by Ticket Granting Server.

UE133010, UE133042 Page 13

Service's use mechanism—Ticket Granting Service

We suppose that the client has already gone through the authentication mechanism, and has a
Ticket Granting Ticket (TGT). Now he's requesting access to a particular service on the network
(web server, file sharing...), and for this, he requires a Ticket Granting Service (TGS). Again, this
request is separated into two steps, TGS_REQUEST and TGS_REPLY. Both messages are
encrypted, for security reasons.

1st step: Ticket Granting Service Request—TGS_REQUEST

When the user wishes to access to a kerberized service, he must first authenticate himself to it.
This pre-requisite needs a separate connection to the Ticket Granting Server: the TGS_REQUEST.
The message sent by the client is composed of several elements:
 the TGS request itself, containing the service principal and the requested lifetime,
 the TGT acquired earlier (on a successful authentication),
 an authenticator.
The authenticator is here to thwart replay. It's a message encrypted with the session key acquired
during the AS process, and contains the user's principal and a timestamp. This way, the KDC
ensures that this unique message is coming from the right person: first by checking the temporary
session key negotiated earlier, and second, through timestamp, which detects fraudulent attempt of
replay.
Upon successful request (a valid TGT and correct authenticator), the Ticket Granting Server will
return the TGS.

2nd step: Ticket Granting Service Reply—TGS_REPLY

At this stage, the server generates a new set of session keys.
The reply message from the server is encrypted with the session key acquired through AS process.
As such, only the client that effectively identified himself some time ago to KDC is able to read its
content, and extract the TGS from it.
The message forms the TGS_REPLY part issued by KDC. It contains:
UE133010, UE133042 Page 14
  encrypted with session's key acquired through AS process:
 copy of new session key, for user
 effective ticket lifetime
 service's principal name
 first encrypted with service's long term key, then with the actual session's key. This is
the TGS:
 copy of new session key, for service
 effective ticket lifetime
 KDC timestamp
 client principal
 client IP address

3rd step: Contacting service

Once the client obtained its TGS, he will use it to authenticate himself to the requested service
directly. Since this step depends largely on the service that required Kerberos' help, we won't go
into details here.
The service has access to its keytab, a file that stores its long term key. This key will allow the
service to decrypt the TGS sent by the client, and get all the information needed to identify user
and create security context.
Like for the TGT process, the timestamp encoded in the TGS is here to thwart replay.
Traditionally, the session key is used to sign or crypt messages between client and service. It
provides both endpoints with a way of checking the integrity of traded messages (if messages are
signed), and eventually the creation of a security context, making eavesdropping very difficult.

UE133010, UE133042 Page 15

Conclusion

We can divide the Kerberos protocol into three main steps:

1. Authentication process, where the user (and host) obtain a Ticket Granting Ticket (TGT) as
authentication token,
2. Service request process, where the user obtain a Ticket Granting Service (TGS) to access a
service,
3. Service access, where the user (and host) use TGS to authenticate and access a specific service.
The service access step is not really Kerberos related, but merely depends on the service we are
authenticating to.

II) AES (Advanced Encryption Service)

The Advanced Encryption Standard (AES), also known as Rijndael (its original name), is a
specification for the encryption of electronic data established by the U.S. National Institute of
Standards and Technology (NIST) in 2001. AES is a subset of the Rijndael cipher developed by
two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal to NIST
during the AES selection process. Rijndael is a family of ciphers with different key and block
sizes.
UE133010, UE133042 Page 16
For AES, NIST selected three members of the Rijndael family, each with a block size of 128 bits,
but three different key lengths: 128, 192 and 256 bits.

AES has been adopted by the U.S. government and is now used worldwide. It supersedes the Data
Encryption Standard (DES), which was published in 1977. The algorithm described by AES is a
symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the
data. AES became effective as a federal government standard on May 26, 2002 after approval by
the Secretary of Commerce. AES is included in the ISO/IEC 18033-3 standard. AES is available in
many different encryption packages, and is the first (and only) publicly accessible cipher approved
by the National Security Agency (NSA) for top secret information when used in an NSA approved
cryptographic module.

AES is an iterative rather than Feistel cipher. It is based on ‘substitution–permutation network’. It

comprises of a series of linked operations, some of which involve replacing inputs by specific
outputs (substitutions) and others involve shuffling bits around (permutations). Interestingly, AES
performs all its computations on bytes rather than bits. Hence, AES treats the 128 bits of a
plaintext block as 16 bytes. These 16 bytes are arranged in four columns and four rows for
processing as a matrix.

Unlike DES, the number of rounds in AES is variable and depends on the length of the key. AES
uses 10 rounds for 128-bit keys, 12 rounds for 192-bit keys and 14 rounds for 256-bit keys. Each
of these rounds uses a different 128-bit round key, which is calculated from the original AES key.

The following diagram shows the schematic diagram for AES encryption with processing for each
round of the key used in process.

UE133010, UE133042 Page 17

 SCHEMATIC DIAGRAM OF AES

Process

SCHEMATIC DIAGRAM FOR AES ROUND PROCESS

i) SUBSTITUTE BYTES

The 16 input bytes are substituted by looking up a fixed table (S-box) given in design. The result is
in a matrix of four rows and four columns.

UE133010, UE133042 Page 18

ii) SHIFTROWS

Each of the four rows of the matrix is shifted to the left. Any entries that ‘fall off’ are re-inserted
on the right side of row. Shift is carried out as follows −

 First row is not shifted.

 Second row is shifted one (byte) position to the left.

 Third row is shifted two positions to the left.

 Fourth row is shifted three positions to the left.

 The result is a new matrix consisting of the same 16 bytes but shifted with respect to each
other.

iii)MIXCOLUMNS

Each column of four bytes is now transformed using a special mathematical function. This
function takes as input the four bytes of one column and outputs four completely new bytes, which
replace the original column. The result is another new matrix consisting of 16 new bytes. It should
be noted that this step is not performed in the last round.

iv) ADDROUNDKEY

The 16 bytes of the matrix are now considered as 128 bits and are XORed to the 128 bits of the
round key. If this is the last round then the output is the ciphertext. Otherwise, the resulting 128
bits are interpreted as 16 bytes and we begin another similar round.

DECRYPTION PROCESS
The process of decryption of an AES ciphertext is similar to the encryption process in the reverse
order. Each round consists of the four processes conducted in the reverse order −

 Add round key

 Mix columns
 Shift rows
 Byte substitution

Since sub-processes in each round are in reverse manner, unlike for a Feistel Cipher, the
encryption and decryption algorithms needs to be separately implemented, although they are very
closely related.

SECURITY ISSUES

UE133010, UE133042 Page 19

For cryptographers, a cryptographic "break" is anything faster than a brute force attack — i.e.,
performing one trial decryption for each possible key in sequence (see Cryptanalysis). A break can
thus include results that are infeasible with current technology; however, theoretical though
impractical breaks can illuminate vulnerability patterns in some cases. The largest successful
publicly known brute force attack against any block-cipher encryption was against a 64-bit RC5
key by distributed.net in 2006.

The key space to be searched by brute force increases by a factor of 2 for each additional bit of key
length (assuming, importantly, random choice of keys) which alone increases the degree of
difficulty for a brute force search very rapidly. Mere key length is not, however, regarded as
sufficient for security against attack, for there are ciphers with very long keys which have been
found vulnerable. AES has a fairly simple algebraic description. In 2002, a theoretical attack,
termed the "XSL attack", was announced by Nicolas Courtois and Josef Pieprzyk, purporting to
show a weakness in the AES algorithm due to its simple description. Since then, other papers have
shown that the attack as originally presented is unworkable; see XSL attack on block ciphers.

On 2009, a new attack was discovered which exploits AES's somewhat simple key schedule and
has a complexity of 2119. In December 2009 it was improved to 299.5. This is a follow-up to an
attack discovered earlier in 2009 by Alex Biryukov, Dmitry Khovratovich, and Ivica Nikolić, with
a complexity of 296 for one out of every 235 keys. However, related-key attacks are not of concern
in any properly designed cryptographic protocol, as a properly designed protocol (i.e.,
implementational software) will take care not to allow related-keys, forcing key choice to be as
random as possible.

Side-channel attacks do not attack the underlying cipher, and thus are not related to cipher security
in the usually discussed context, though they may be important in practice. They attack
implementations of the cipher on hardware or software systems which inadvertently leak data.
There are several such known attacks on certain implementations of AES.

III) SPECIAL PACKAGES USED FOR IMPLEMENTATION

i) SOCKET PROGRAMMING

Sockets provide the communication mechanism between two computers using TCP. A client
program creates a socket on its end of the communication and attempts to connect that socket to a
server. When the connection is made, the server creates a socket object on its end of the
communication. The client and the server can now communicate by writing to and reading from
the socket. The java.net.Socket class represents a socket, and the java.net.ServerSocket class
provides a mechanism for the server program to listen for clients and establish connections with
them.

The following steps occur when establishing a TCP connection between two computers using
sockets −

UE133010, UE133042 Page 20

  The server instantiates a ServerSocket object, denoting which port number communication
is to occur on.

 The server invokes the accept() method of the ServerSocket class. This method waits until
a client connects to the server on the given port.

 After the server is waiting, a client instantiates a Socket object, specifying the server name
and the port number to connect to.

 The constructor of the Socket class attempts to connect the client to the specified server and
the port number. If communication is established, the client now has a Socket object
capable of communicating with the server.

 On the server side, the accept() method returns a reference to a new socket on the server
that is connected to the client's socket.

After the connections are established, communication can occur using I/O streams. Each socket
has both an OutputStream and an InputStream. The client's OutputStream is connected to the
server's InputStream, and the client's InputStream is connected to the server's OutputStream.

The java.net package provides support for the two common network protocols :

 TCP − TCP stands for Transmission Control Protocol, which allows for reliable
communication between two applications. TCP is typically used over the Internet Protocol,
which is referred to as TCP/IP.

 UDP − UDP stands for User Datagram Protocol, a connection-less protocol that allows for
packets of data to be transmitted between applications.

TCP is a two-way communication protocol, hence data can be sent across both streams at the same
time. Following are the useful classes providing complete set of methods to implement sockets.

ii) THREAD AND RUNNABLE CLASS

Thread and Runnable class was used for multithreaded server and client development. Following
is the life cycle diagram of a thread in JAVA:

UE133010, UE133042 Page 21

 LIFE CYCLE OF THREAD

 New − A new thread begins its life cycle in the new state. It remains in this state until the
program starts the thread. It is also referred to as a born thread.

 Runnable − After a newly born thread is started, the thread becomes runnable. A thread in
this state is considered to be executing its task.

 Waiting − Sometimes, a thread transitions to the waiting state while the thread waits for
another thread to perform a task. A thread transitions back to the runnable state only when
another thread signals the waiting thread to continue executing.

 Timed Waiting − A runnable thread can enter the timed waiting state for a specified
interval of time. A thread in this state transitions back to the runnable state when that time
interval expires or when the event it is waiting for occurs.

 Terminated (Dead) − A runnable thread enters the terminated state when it completes its
task or otherwise terminates.

iii) Input Output Streams

Input Output Streams are implemented in chat application to transfer messages using java.io class.
BufferedReader stream is utilized for reading input messages in the chat application. PrintWriter
was utilized to transfer output to other clients involved in the chat session.

iv) Security Packages

java.security and java.crypto packages were used to integrate security features in the chat
application.

UE133010, UE133042 Page 22

Java.security provides the classes and interfaces for the security framework. This includes classes
that implement an easily configurable, fine-grained access control security architecture. This
package also supports the generation and storage of cryptographic public key pairs, as well as a
number of exportable cryptographic operations including those for message digest and signature
generation. Finally, this package provides classes that support signed/guarded objects and secure
random number generation. Many of the classes provided in this package (the cryptographic and
secure random number generator classes in particular) are provider-based. The class itself defines a
programming interface to which applications may write. The implementations themselves may
then be written by independent third-party vendors and plugged in seamlessly as needed. Therefore
application developers may take advantage of any number of provider-based implementations
without having to add or rewrite code.

Java.crypto provides the classes and interfaces for cryptographic operations. The cryptographic
operations defined in this package include encryption, key generation and key agreement, and
Message Authentication Code (MAC) generation. Support for encryption includes symmetric,
asymmetric, block, and stream ciphers. This package also supports secure streams and sealed
objects. Many of the classes provided in this package are provider-based. The class itself defines a
programming interface to which applications may write. The implementations themselves may
then be written by independent third-party vendors and plugged in seamlessly as needed. Therefore
application developers may take advantage of any number of provider-based implementations
without having to add or rewrite code.
v) GUI

Chat application consists of basic GUI for ease of operation. GUI is implemented using java.awt
and java.swing packages.

Java.awt contains all of the classes for creating user interfaces and for painting graphics and
images. A user interface object such as a button or a scrollbar is called, in AWT terminology, a
component. The Component class is the root of all AWT components. See Component for a
detailed description of properties that all AWT components share. Some components fire events
when a user interacts with the components. The AWTEvent class and its subclasses are used to
represent the events that AWT components can fire.

A container is a component that can contain components and other containers. A con tainer can
also have a layout manager that controls the visual placement of components in the container. The
AWT package contains several layout manager classes and an interface for building your own
layout manager. Each Component object is limited in its maximum size and its location because
the values are stored as an integer. Also, a platform may further restrict maximum size and location
coordinates. The exact maximum values are dependent on the platform. There is no way to change
these maximum values, either in Java code or in native code. These limitations also impose
restrictions on component layout. If the bounds of a Component object exceed a platform limit,
there is no way to properly arrange them within a Container object. The object's bounds are
defined by any object's coordinate in combination with its size on a respective axis.

UE133010, UE133042 Page 23

Java.swing is a GUI widget toolkit for Java. It is part of Oracle's Java Foundation Classes (JFC) –
an API for providing a graphical user interface (GUI) for Java programs. Swing was developed to
provide a more sophisticated set of GUI components than the earlier Abstract Window Toolkit
(AWT). Swing provides a native look and feel that emulates the look and feel of several platforms,
and also supports a pluggable look and feel that allows applications to have a look and feel
unrelated to the underlying platform. It has more powerful and flexible components than AWT. In
addition to familiar components such as buttons, check boxes and labels, Swing provides several
advanced components such as tabbed panel, scroll panes, trees, tables, and lists.

Unlike AWT components, Swing components are not implemented by platform-specific code.
Instead, they are written entirely in Java and therefore are platform-independent. The term
"lightweight" is used to describe such an element.

B) FLOW OF PROJECT
i) ABSTRACT IMPLEMENTATION OF PROJECT

UE133010, UE133042 Page 24

ii) PRE-AUTHENTICATION OF CLIENT TO AUTHENTICATION SERVER

UE133010, UE133042 Page 25

iii) AUTHENTICATION SERVER REPLY

UE133010, UE133042 Page 26

iv) NEGOTIATION WITH TGS

UE133010, UE133042 Page 27

 PRODUCT DEVELOPMENT
The chat application consists of several files distributed in two domains.

i) KEY DISTRIBUTION CENTER

 Authentication Server: This has been implemented in AServer.java file. Its main function is
to facilitate pre-authentication of user with the KDC and grant the user with the ticket
granting ticket(TGT).
 Ticket Granting Server: This has been implemented in Tgt.java file. Its main function is to
grant the user with the service key after successful exchange of tgt.

ii) CHAT SERVER

 Client: This has been implemented in MClient.java file. It is a multithreaded client enabled
with GUI, that initiates the contact with KDC in order to authenticate itself and set up a
security context for a successful chat with another client.
 Server: This has been implemented in Mserver.java file. It is a multithreaded server which
has ability to broadcast messages to more than one client simultaneously.

The chat initiation process includes the following steps:

1. Compile the AServer.java.

UE133010, UE133042 Page 28

2. Run Aserver.java

3. Compile Tgs.java file.

UE133010, UE133042 Page 29

4. Run Tgs.java file.

5. Compile Mserver.java file.

6. Run Mserver file.

UE133010, UE133042 Page 30

7.Compile Mclient.java and run the file’s different instances.

8. Database entry for pre authentication in Aserver.java

UE133010, UE133042 Page 31

 TESTING OF APPLICATION
Bob sending message to Alice

Alice receiving message from Bob

UE133010, UE133042 Page 32

Alice Sending message to Bob

Bob receiving message from Alice

UE133010, UE133042 Page 33

RESULTS
After conducting the required tests and implementations, the following results were derived:
 The valid clients were successfully authenticated at the authentication server.
 The valid clients were successfully authenticated at the ticket granting server.
 The security context was successfully established between clients and chat server.
 End to end encryption using Kerberos and AES was ensured.
 Modularity in project design was ensured.

CONCLUSION
The authentication system using Kerberos to set up a security context using the AES encryption
provides a safe medium for two or more parties to exchange sensitive information among
themselves. If implemented in a commercial way, it can be a very useful tool to handle
communication between people. This project added to our learning curve as we learnt about
several new technologies including Kerberos, AES etc. it also helped us getting a grip of java and
we learnt to implement various concepts like secure communication, end-to-end encryption, socket
programming, multithreading etc. in java.
This project is a step towards enhancing privacy and security of users in digital sphere when digital
communication and messaging is of paramount importance. It helps in maintaining robustness and
integrity of the communication architecture.

UE133010, UE133042 Page 34

 BIBLIOGRAPHY
1) www.redhat.com

2) RedHat Course Material

3) www.oracle.com

4) www.wikipedia.com

5) www.linuxfoundation.org

6) www.sourceforge.net

7) www.javatpoint.com

8) www.tutorialspoint.com

9) www.aes.net

10) The MIT Kerberos Administrator’s How-to Guide, By Jean-Yves Migeon

UE133010, UE133042 Page 35