Methodology Of Checking Cryptographic Protocols Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

In this dissertation, I have tried to present a new strong, extensible and proper methodology, in which cryptographic protocols are automatically checked. I have used a new approach by specifying a protocol, the necessary assumptions and the document supporting the protocol in regards to any error that might be faced. Lot is known about cryptography, which is not expressed here in detail but a general overview is given. Internet as the world knows is an important aspect of our daily activity, which has been the provided of communication for millions of people over the globe, one of the main issues to deal with has been security.

Secure communication has many features, one of them is Cryptography. The science of writing in secret code is generally known as Cryptography, firstly used in 1900 B.C. With the development of computer communications, different forms of cryptography have come out. Cryptography has been the most used for communication over any un-trusted medium, including networks and more prominently Internet, where again the serious issue being security to deal with. Authentication - able to identify a person's identity, in any form of communication is an important requirement of security, most affected on the Internet. Making sure that no one else except the particular intended person can read the message known as Confidentiality. No alteration of the message received has been done; notifying the receiver comes under Integrity. Three types of cryptographic methods exist, one is the Secret-key cryptography, second one is public-key cryptography and thirdly hash functions. Plaintext is the unencrypted data that is encrypted to cipher text, finally decrypted in to plaintext.

Secret- key encryption as far as known has existed in the domain, stressing the need for a efficient and secure mechanism, with the distribution of secret key. Although I have used the existing methods in this project, I have tried to implement it in a new approach. Kerberos, the most commonly known and used technique for key sharing and authentication. "Kerberos is a distributed authentication service that allows a process (a client) running on behalf of a principal (a user) to prove its identity to a verifier (an application server, or just server) without sending data across the network that might allow an attacker or the verifier to subsequently impersonate the principal, Kerberos optionally provides integrity and confidentiality for data sent between the client and server"- "- B. Clifford Neuman and Theodore. Kerberos makes use of cryptographic tickets to avoid the process of transmitting plaintext passwords over the wire. The Needham-Schroeder protocol is the base for Kerberos. Individually a person unfamiliar with Kerberos protocol may not understand the benefit of deploying in a particular network. The problems associated with Kerberos, designed to mitigate is familiar for the administrators. Password sniffing, password filename/ database stealing are the problems that are most faced. There is a requirement of high-level effort in order to maintain large number of account databases.

A cryptographic algorithm, whose general method is using asymmetric key algorithms instead of symmetric algorithms, is used by public-key cryptography. In secure communications, this is a very practical approach. In public-key cryptography, the most widely used technique, is using asymmetric key algorithm, where the key used in encrypting a message is different from the one used to decrypt it. Two keys are provided to the user, a public-key and a private key. The private key is to be known only to the user, and the public key is sent to all the other users of the server. With the help of these keys, a message can be encrypted and decrypted without much hassle. The practice of cryptography was revolutionized by the discovery of such algorithms. Whereas the Symmetric- key algorithms that have been in use for thousands of years use a single secret key, shared by both the sender and receiver, keeping it as a secret for encrypting and decrypting.

Both these techniques have given rise to a lot of uncertainties. In order to try and reduce some of them, in this project I have implemented a web service using the Kerberos technique. Using this service the users can send and receive files securely. There are some flaws, as most of the approaches have their focus on algorithms and lifecycle models.

The basic working of the web service, is allocating clients with a login key that is encrypted, to be able to access the server without any intervention of third-party. A user-manual is available on the web service, for any problems the existing users and new users may encounter. On registering with in the web service, the user will be given a secret key that is encrypted, with which the user can access the files from the server or any other person. The secret key provided to the user will be active and working, till the user is sure about the files security. There is an option of changing the secret key if the user wants to just by completing the steps necessary. As many have said, the web service I am implementing will be a user- friendly service.

With enough time to develop and implement this web service, I will try and solve any complications that might arise in the end result of the web service. Even after noticing some flaws, if there is any other, I will leave a complaint or suggestion box on the web service so as to let the users notify of any problem they encounter. There were a few minor problems identified in the primary implementation of the web service, which have been tried to reduce. Network applications and online social networks have been unaccountable over the years, with the explosion of information and communication technology. Evaluation of trust and authentication of keys are the two most security issues in most of the systems. An entity, which controls the public-key pair, is determined with the help of public-key authentication. Secure use of public-key cryptography is a compulsory requirement.

The following advantages, are given to us by practice of argumentation, when comparing the formal methods. Tackling any conflicts, which can eventually be evaluated quantitatively. Providing logical arguments for and against the conflicts is Qualitative evaluation.

Literature Review

E-commerce infrastructure has its base upon public-key cryptography and system SSL, based on the technical information of cryptographic systems.

Communicating to the intended recipient, the information is transformed, making it unreadable to everyone except the intended person commonly known as Encryption. Cipher and keys, are mathematical formulas known as cryptographic algorithms, used for encrypting and decrypting information. Cryptography is of 2 kinds, they are as follows,

Symmetric cryptography: For securing the information that is being shared on public networks, mainly this symmetric cryptography was used. The idea of a sharing a secret is the main goal of this system. A basic idea of the working of this system, when two parties are wishing to communicate with each other over a secure line, they dwell on the idea of a single secret key, which will allow both the parties in encrypting and decrypting the messages.

Symmetric cryptography has several drawbacks that are discussed here. Unmanageable exchange of secret keys is the first among the drawbacks. For sharing of secret keys, both the senders and receivers need to have trust, and also able to recognize everyone they communicate with.


Public key cryptography: Asymmetric-key cryptography or also known's as public-key cryptography basically works by dividing the keys in to two sub-keys namely, public key and private key, unlike the symmetric cryptography system. Comparing the public key cryptography systems with the traditional symmetric cryptography, today's public key systems have had a considerable improvement, where as in the traditional systems two parties were allowed to exchange data privately in the possible presence of eavesdroppers, not agreeing on a shared sheet.

Taking an example, where a user wants to receive encrypted information using the public-key cryptography, the system generates a key pair like discussed and the generated public key is displayed to all individuals, wanting to encrypt data. The major litigation maybe avoided, as public key is required only for encryption whereas for decryption of data private key is required.

Digital Signatures: Digital signatures are based on a combination of the traditional idea of data hashing with public key-based encryption. Most hash functions are similar to encryption functions. In fact, some hash functions are just slightly modified encryption functions. The digital signature process is central to the idea of a digital certificate.

Privacy: In cryptography, the most important issue is privacy, where the user ensures preventing any third party or any person leaving only the person intended to read the data. Privacy's likelihood is improved by cryptography. Before storing the messages they are encrypted. These techniques are used.

This is mainly done with the help of data encryption, transforming "plaintext" to "cipher text". Data can be in any form, like ASCII text, database file that can be encrypted.


The idea of secure communications is that the person sending a file is sure of the identity of the person he wishes to communicate. Authentication can be defined as the method of identifying the person by verification of his identity.

Giving an example, physical documentation, in daily life, is used to verify a person's identity. A person cashing a check might be asked to show his driver's license, increasing the merchant's confidence to identify the person.

WEP Shared Key Authentication:

WEP shared key authentication is a remarkable use of cryptography. The illustration of two devices using Shared Key authentication is shown in steps.

The station first sends an authentication request to the access point.

The access point sends a challenge text to the station.

The station uses its configured 64-bit or 128-bit default key to encrypt the challenge text, and sends the encrypted text to the access point.

The access point then decrypts the encrypted text using its default WEP key that is in accordance with the station's default key. The access point compares the decrypted text with the original challenge text, if match, then the access point and the station share the same WEP key, and thus the access point authenticates the station.

Finally, the station connects to the network.


For providing reliable authentication over an open and insecure networks, where communications happen between the host maybe intercepted, for which the Kerberos protocol was mainly designed. But one thing to remember is that there are no guarantees that the computers being used are vulnerable. Like the authentication servers, application servers (imap, pop, smtp, ftp, ssh, AFS etc) and the clients must be kept updated, so that the authenticity of the users requesting and service providers can be guaranteed. Justifying the above sentence is "Kerberos is an authentication protocol for trusted hosts on untrusted networks". Taking an example to better understand the concept, Kerberos' strategies are useless when someone obtains the privileged access to the server, can easily copy the file containing the secret key. After obtaining the key the intruder will use this key on another machine, and all he has to do is to obtain a simple spoof DNS or IP address for that particular sever to appear for clients as authentic server.


The core of Kerberos architecture is the KDC (Key Distribution Server). The KDC stores authentication information and uses it to securely authenticate users and services.

Authentication of this type is secure as,

It does not occur in plaintext

Doesn't rely on authentication by host operating system

It does not base trust on IP address

It doesn't require physical security of the network hosts.

The KDC acts as a trusted third party in performing these authentication services.

Due to the critical function of the KDC, multiple KDC's are normally utilized. Each KDC stores a database of users, servers, and secret keys. Kerberos clients are normal network applications which have been modified to use Kerberos for authentication. In Kerberos slang, they have been Kerberized.

Some of the goals the Kerberos protocol is to achieve are discussed below,

"1.The user's password must never travel over the network;

2.The user's password must never be stored in any form on the client machine: it must be immediately discarded after being used;

3.The user's password should never be stored in an unencrypted form even in the authentication server database;

4.The user is asked to enter a password only once per work session. Therefore users can transparently access all the services they are authorized for without having to re-enter the password during this session. This characteristic is known as Single Sign-On."


These are the steps essential for obtaining the following results:

1. Disabling the account of any user in a single location is done by the administrator not having to act on several servers.

2. A change of password by the user affects all services at the same time.

3. Safeguarding information is not required since there is no redundancy of authentication.

4. Mutual Authentication can be defined as, the users not only having to verify who they say they are, when requested, their authenticity must also be proved to the clients also by the application servers.

After the authentication is completed, both the client and server can able to establish an encrypted connection, when required. Kerberos supports the generating and exchanging of an encryption key, which can be used foe data encryption.

Entries associated with the users and the services are stored in the database, which is the container. Referring to an entry is done by the principal i.e. the name of the entry, even though the term principal is a synonym for entry. Every entry includes the below information;

The principal to which the entry is associated;

The encryption key and related kvno;

The maximum validity duration for a ticket associated to the principal;

The maximum time a ticket associated to the principal may be renewed (only Kerberos 5);

The attributes or flags characterizing the behavior of the tickets;

The password expiration date;

The expiration date of the principal, after which no tickets will be issued.

Keys in the database are made difficult to steal, as the implementations do the encrypting of the database with the help of Master key, associated with the [email protected] Database dumps mostly used for backups from the KDC master to the slave, can be encrypted using the above mentioned key, necessary to be known to reload them.

The Ticket Granting Server is the KDC component, which distributes service tickets to clients with a valid TGT, guaranteeing the authenticity of the identity for obtaining the requested resource on the application servers. The TGS can be considered as an application server (given that to access it it is necessary to present the TGT) which provides the issuing of service tickets as a service. It is important not to confuse the abbreviations TGT and TGS: the first indicates a ticket and the second a service.

It is possible to discuss how Kerberos operates, having acquired all the concepts in the above-discussed paragraphs. The messages to be discussed are as below, also shown in the figure:

AS_REQ is the initial user authentication request (i.e. made with kinit) This message is directed to the KDC component known as Authentication Server (AS);

AS_REP is the reply of the Authentication Server to the previous request. Basically it contains the TGT (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user);

TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a service ticket. This packet includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key;

TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS;

AP_REQ is the request that the client sends to an application server to access a service. The components are the service ticket obtained from TGS with the previous reply and an authenticator again generated by the client, but this time encrypted using the service session key (generated by TGS);

AP_REP is the reply that the application server gives to the client to prove it really is the server the client is expecting. This packet is not always requested. The client requests the server for it only when mutual authentication is necessary.

However, one thing not to be forgotten is that Kerberos protocol is a really complicated method and careful understanding is needed to use Kerberos.

The following figure and corresponding steps provide a detailed description of the Kerberos authentication process and the main components that is used when a computer running Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located in another domain.

1. User1 log on to Workstation1 with the use of credentials from the domain. The authenticating domain controller issues user1 a ticket-granting ticket (TGT). To be authenticated to resources this ticket is needed. The user then attempts to access a shared resource on a file server located in child2 domain.

2. Secondly, Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in ChildDC1 domain and request a service ticket for the FileServer1 service principal name (SPN).

3. Thirdly, ChildDC1 cannot find SPN in the domain database and question the global catalog to know if any domains contain this SPN. The global catalog then sends the requested information back to ChildDC1.

4. In turn the ChildDC1 send the referral to Workstation1.

5. A domain controller in ForestRootDC1 (parent domain) is contacted by Workstation1 for a referral to a domain controller ChildDC2 in the Child2 domain. Then, ForestRootDC1 sends the referral to Workstation1.

6. KDC on ChildDC2 is contacted by Workstation1 to negotiate the ticket for the user to gain access to FileServer1.

7. Finally the Workstation1 has got a service ticket, which it sends to FileServer1. FileServer1 reads the user's security credentials and constructs an access token consequently.

An important note to be taken is that the each domain has their own set of security policies, which do not cross from domain to domain.




Most of the users are unfamiliar with the Kerberos protocol, like the advantages of deploying it in their network. However, all administrators are familiar with the problems Kerberos was designed to mitigate. Password sniffing, password filename/database stealing are some of the problem that are included, with a high level of effort required to maintain a large database.

Kerberos infrastructure which is properly and perfectly deployed helps reduce problems and also to address them. Making any enterprise more secure and reliable. Plaintext passwords being transmitted over networks can be avoided, by the use of Kerberos. For easier maintenance and management of data of this kind, Kerberos system can be used to centralize an individual's username and password information. Kerberos will also help prevent us from storing password information locally on any machine, whether being a workstation or server. This will help result in additional compromises, by reducing the likelihood of a single machine.

Summing up, in a wide enterprise, Kerberos will benefit in a way by reducing administration costs through easier account and password management and also improved network security. In a smaller environment, scalable authentication infrastructure and improved network security are the clear benefits.

Strengths of Kerberos:

User's passwords are never sent across the network, encrypted or in plain text. Secret keys are only passed across the network in encrypted form. Hence, a miscreant snooping and logging conversations on a possibly insecure network cannot deduce from the contents of network conversations enough information to impersonate an authenticated user or an authenticated target service.

Client and server systems mutually authenticate -- at each step of the process, both the client and the server systems may be certain that they are communicating with their authentic counterparts.

Although the preceding discussion did not go into sufficient detail to elucidate the fact, the tickets passed between clients and servers in the Kerberos authentication model include timestamp and lifetime information. This allows Kerberos clients and Kerberized servers to limit the duration of their users' authentication. While the specific length of time for which a user's authentication remains valid after his initial ticket issued is implementation dependent, Kerberos systems typically use small enough ticket lifetimes to prevent brute-force and replay attacks. In general, no authentication ticket should have a lifetime longer than the expected time required to crack the encryption of the ticket.


There are a number of ways in which an attack can take place in Kerberos. The most common way of any attacker will be to attempt to compromise a Kerberos infrastructure, to attack the Kerberos servers. If and should the attacker gain access to a KDC, he will be able to access the database of encrypted passwords. The attacker will have the access to Kerberos software. The attacker can access the configuration files of both which can be modified to be able to make the system perform authentications that aren't successful.

Replay attacks and password- guessing attacks are other kind of attacks of attacking Kerberos infrastructure. Interception or acquiring a Kerberos ticket, once obtained deceitfully presenting the ticket to attempt and gain authentication, is a replay attack. By intercepting a Kerberos tickets from the network and attempting a brute force attack to decrypt the intercepted tickets, is known as password guessing in a Kerberos system.

From the description on how a Kerberos system can be compromised, one should realize that high priority should be given for the security of the Kerberos servers themselves, running up to date Kerberos software. One should remain vigilant in selecting good passwords, and setting a strong password policy.

Since Kerberos protocol is the default authentication protocol, any authentication problems with console logon, network logon, access to network resources, or remote access will indicate some sort of Kerberos error.

- Make sure that the network infrastructure is functioning properly and that all computers and services

can communicate.

- Make sure that a domain controller is accessible.

- Make sure that DNS is configured properly and resolving host names and services appropriately.

- Make sure that the clocks are synchronized across the domain.


Weaknesses of Kerberos:

Kerberos was designed for use with single-user client systems. In the more general case, where a client system may itself be a multi-user system, the Kerberos authentication scheme can fall prey to a variety of ticket-stealing and replay attacks. The overall security of multi-user Kerberos client systems (filesystem security, memory protection, etc.) is therefore a limiting factor in the security of Kerberos authentication. No amount of cleverness in the implementation of a Kerberos authentication system can replace good system administration practices on Kerberos client and server machines.

Because Kerberos uses a mutual authentication model, it is necessary for both client machines and service providers (servers) to be designed with Kerberos authentication in mind. Many proprietary applications already provide support for Kerberos or will be providing Kerberos support in the near future. Some legacy systems and many locally-written and maintained packages, however, were not designed with any third-party authentication mechanism in mind, and would have to be re-written (possibly extensively) to support Kerberos authentication.

The Kerberos authentication model is vulnerable to brute-force attacks against the KDC (the initial ticketing service and the ticket-granting service). The entire authentication system depends on the trustability of the KDC(s), so anyone who can compromise system security on a KDC system can theoretically compromise the authentication of all users of systems depending on the KDC. Again, no amount of cleverness in the design of the Kerberos system can take the place of solid system administration practices employed in managing the Kerberos KDC(s).


Research Methodology

All the above discussed tell us the general flaws and technical issues in Kerberos. Combining java and Asp to create a website wherein the details of every user will be stored in the central server but to use an individual's keys the administrator must send a request to the user asking him to grant permission to use his information for a particular action. The general outline of Kerberos will be considered for the development of this website with the help of secret key sharing procedures.

After the website has been created and tested, a survey would be conducted among users to gather feedback about the web service and any problems they may have faced or anything in particular they might want to change.

The presented solutions can be and should be evaluated from several points of view. The most important ones are implementability, administration, security, and usage. Implement ability is a function of the complexity of the system and checks how easily the existing computer system can be modified. Administrator's point of view on how easily the system is used is Administration. Security measures how vulnerable the system is to attacks. Usage is the end-user's viewpoint to the system.

The main problem with broker-based solutions, like Kerberos are the end applications, which need to be modified to accept the tickets. The system is vulnerable to password guessing, as the authentication of Kerberos is only based on passwords. The secret key used for encrypting the initial session key is a one-way has of the users password. Therefore guessing the password correctly would allow the attacker to obtain the session key and to continue to get the final credentials and access rights.

The current models can be improved and the efforts should be aimed towards a better interoperability. Designing common APIs can do this. In order to recognize multiple authentication methods and credentials, systems should be designed more accurately, for example an agent would accept Kerberos tickets.

One improvement is a higher level of integration into operating systems and actually there are rumors that operating system vendors such as Microsoft are interested in either supporting or implementing Kerberos or similar systems.

Providing a uniform and simplified procedure of strong user authentication in Java, using Kerberos V5 protocol, is discussed in this project. Implementation of this kind is used to present a improved interoperability within various user environments, memory cache support, and any other additional features. Making authentication slight to the users and easy and simple to the developers, is the ultimate goal of this project.

Using Java with Kerberos module, the following functions are supported:

An automated credential discovery on multiple operating systems.

Reading of memory credential caches.

Key tab authentication of service principals without TGT requests.

A simplified and uniform configuration procedure for applets, webstart table apllications, and server side components.

Simplified API for sharing credentials between two peers.

Web authentication framework.

Binaries and configuration files, everything is put in to a separate jar file, known as Kerberos-client. Jar. This kind of module will run on Java Jre 1.4 and 1.5. Additional libraries are not in question for this module. Customization of the Kerberos configuration file krb5.conf, which is listed in the public distribution, must be done. Once this is done, the project jar file must and should be rebuilt and sealed with a new signature. Gov.fnal.controls.kerberos is the project's root package required for any action. This file includes two main classes:

KerberosLoginContext- this is the main class in this package. This controls the action of authentication of a local principal and sharing of the credentials with a remote host. No hassles without public constructors in this class. GetInstance is a static method providing a shared instance. Using the command line operation this class can be initiated.

KerberosLoginApplet.- it is a graphical user interface for web authentication with a client side applet. This class contains other packages that include different classes, most cases, directly not used.

Some of them are as shown,

Catalina- A tomcat web server component.

Login- this is implementing of the reading of credentials, which might include native libraries, for memory cache accessing.

Util- useful gadgets and also miscellaneous.


KeberosLoginContext is the main class which is an extension of javax.securit.auth.login. Most of the general login and logout procedures, are defined by LoginContext. Login can be described as reading the present person's credential, which can be either a cached ticket, granting ticket. This credentialshould already be existing on the local system. This is required as the module does not request ticket-granting tickets from the server. Testing of this module on different data formats by client utilities has been done.


Operating System


Credential Location

Windows xp/2000

kinit, Leash32

(older versions)


• {}/krb5cc

• {user.home}/krb5cc_{}

kinit, Leash32

(newer versions)

operating system memory

WRQ Reflection

• {user.home}/My Documents/Reflection/{}.cch






• /tmp/krb5cc_{uid}

• {user.home}/krb5cc_{}

Mac OS X

Default client

Operating system memory

The Kerberos protocol must be able to work globally in java, which might require some initial configuration. Configuration files or variables, found on a person's computer, not relying on by the module. The Kerberos module's jar file must and should include all the configuration data, to be self-sufficient. Before the start of Kerberos Login Context class is initialized, the properties which maybe used should compulsorily set at the startup of a program.