INFORMATION NETWORK

SECURITY UNIT-2
BY: SAYMA NATEKAR
KEY MANAGEMENT
• Key management refers to managing cryptographic
keys within a cryptosystem. It deals with generating,
exchanging, storing, using and replacing keys as
needed at the user level.
A key management system will also include key
servers, user procedures and protocols, including
cryptographic protocol design. The security of
the cryptosystem is dependent upon successful key
management.
• This article introduces into key management from a
perspective of a CISO or any person in charge of
maintaining information security within an
organization.
What is a CKMS Policy?

• The term CKMS stands for Cryptographic Key

Management System. A CKMS Security Policy provides
the rules that are to be used to protect keys and
metadata that the CKMS supports. This Policy
establishes and specifies rules for this information that
will protect its:
• Confidentiality
• Integrity
• Availability
• Authentication of source
• This protection covers the complete key life-cycle from
the time the key becomes operational to its elimination.
• A CKMS Policy may also include selecting all the
cryptographic mechanisms and protocols that
may be utilized by the Key Management System.
The Policy must remain consistent with the
organization’s higher-level policies. For instance,
if an organization’s Information Security Policy
requires that electronically transmitted
information is to receive protection to maintain
its confidentiality for 30 years, both
the CKMS design and CKMS Security Policy
must be able to support that policy.
• When designing a Key Management System, a
system designer may be not necessarily be a member of
the organization that will be using the system. Therefore,
he may not have access to the policies of the
organization. Often the designer will create a set of
policies and features that are commonplace for the
organization’s market. The designer will normally then
provide documentation to explain how these policies and
features are used within the CKMS Security Policy. The
organization may choose to work with the design to
modify the Policy to better fit their needs. Overall, it is
the responsibility of the organization to ensure that
the Key Management System design is capable of
supporting their CKMS Security Policy.
• Often, organizations will use a hierarchy of policies to address their policy
requirements. Depending upon the organization’s needs, their hierarchy
may consist of multiple levels. A hierarchy may include:
• Top level – Information Management, which specifies the goals for
information security and the requirements and expected control actions for
lower levels, including:
▫ Industry standards
▫ Legal requirements
▫ Organizational goals
• Second level – Information Security, which provides more information on
the actual procedures that will be implemented and enforced to provide the
security as specified by the top level. This level includes:
▫ List of potential threats to keeping the organization’s information secure
▫ Associated risks
▫ Guidelines of Data Security Policy
▫ Outputs to the KMS Security Policy
Key Management Compliance

• Third level – KMS Security Policy, which

establishes and provides specifics on protecting
keys and metadata. This policy includes:
▫ Protections used for each key type and its
associated metadata
▫ Retention period for keys and metadata according
to the sensitivity of the data being protected
▫ Domain Security Policy
• Key management compliance refers to the oversight,
assurance and capability of being able to
demonstrate that keys are securely managed. This
includes the following individual compliance
domains:
• Physical security – the most visible form of
compliance, which may include locked doors to
secure system equipment and surveillance cameras.
These safeguards can prevent unauthorized access
to printed copies of key material and computer
systems that run key management software.
• Logical security – protects the organization against
the theft or unauthorized access of information. This
is where the use of cryptographic keys comes in by
encrypting data, which is then rendered useless to
those who do not have the key to decrypt it.
• Personnel security – this involves assigning specific
roles or privileges to personnel to access
information on a strict need-to-know basis.
Background checks should be performed on new
employees along with periodic role changes to
ensure security.
Facing Problems and Challenges of
Key Management
• Managing cryptographic keys can be a challenge,
especially for larger organizations that rely upon
cryptography for various applications. The primary
problems that are associated with managing
cryptographic keys include:
• Using the correct procedure to update system certificates
and keys
• Updating certificate and keys before they expire
• Dealing with proprietary issues when keeping track of
crypto updates with legacy systems
• Locating remote devices that need to be updated
• Lacking overview as to the purpose, location and why
various systems are used
Implementation of Diffie-Hellman
Algorithm
• Background
• Elliptic Curve Cryptography (ECC) is an approach to
public-key cryptography, based on the algebraic structure of
elliptic curves over finite fields. ECC requires a smaller key as
compared to non-ECC cryptography to provide equivalent
security (a 256-bit ECC security has equivalent security
attained by 3072-bit RSA cryptography).
• For a better understanding of Elliptic Curve Cryptography, it
is very important to understand the basics of the Elliptic
Curve. An elliptic curve is a planar algebraic curve defined by
an equation of the form
•
• Where ‘a’ is the co-efficient of x and ‘b’ is the constant of the
equation
• The curve is non-singular; that is, its graph has no
cusps or self-intersections (when the characteristic
of the Co-efficient field is equal to 2 or 3).
• In general, an elliptic curve looks like as shown
below. Elliptic curves can intersect almost 3 points
when a straight line is drawn intersecting the curve.
As we can see, the elliptic curve is symmetric about
the x-axis. This property plays a key role in the
algorithm.
•
• Diffie-Hellman algorithm
• The Diffie-Hellman algorithm is being used to establish a
shared secret that can be used for secret communications
while exchanging data over a public network using the elliptic
curve to generate points and get the secret key using the
parameters.
• For the sake of simplicity and practical implementation of the
algorithm, we will consider only 4 variables, one prime P and
G (a primitive root of P) and two private values a and b.
• P and G are both publicly available numbers. Users (say Alice
and Bob) pick private values a and b and they generate a key
and exchange it publicly. The opposite person receives the key
and that generates a secret key, after which they have the
same secret key to encrypt.
Alice Bob

Public Keys available = P, G Public Keys available = P, G

Private Key Selected = a Private Key Selected = b

Key generated =

Key generated =
Message Authentication

• In the last chapter, we discussed the data integrity

threats and the use of hashing technique to detect if
any modification attacks have taken place on the
data.
• Another type of threat that exist for data is the lack
of message authentication. In this threat, the
user is not sure about the originator of the message.
Message authentication can be provided using the
cryptographic techniques that use secret keys as
done in case of encryption.
Message Authentication Code (MAC)

• MAC algorithm is a symmetric key cryptographic

technique to provide message authentication.
For establishing MAC process, the sender and
receiver share a symmetric key K.
• Essentially, a MAC is an encrypted checksum
generated on the underlying message that is sent
along with a message to ensure message
authentication.
• The process of using MAC for authentication is
depicted in the following illustration
Let us now try to understand the
entire process in detail
• The sender uses some publicly known MAC algorithm,
inputs the message and the secret key K and produces a
MAC value.
• Similar to hash, MAC function also compresses an
arbitrary long input into a fixed length output. The major
difference between hash and MAC is that MAC uses
secret key during the compression.
• The sender forwards the message along with the MAC.
Here, we assume that the message is sent in the clear, as
we are concerned of providing message origin
authentication, not confidentiality. If confidentiality is
required then the message needs encryption.
• On receipt of the message and the MAC, the receiver
feeds the received message and the shared secret key K
into the MAC algorithm and re-computes the MAC value.
• The receiver now checks equality of freshly computed
MAC with the MAC received from the sender. If they
match, then the receiver accepts the message and
assures himself that the message has been sent by the
intended sender.
• If the computed MAC does not match the MAC sent by
the sender, the receiver cannot determine whether it is
the message that has been altered or it is the origin that
has been falsified. As a bottom-line, a receiver safely
assumes that the message is not the genuine.
Limitations of MAC

There are two major limitations of MAC, both due

to its symmetric nature of operation −
• Establishment of Shared Secret.
▫ It can provide message authentication among pre-
decided legitimate users who have shared key.
▫ This requires establishment of shared secret prior
to use of MAC.
• Inability to Provide Non-Repudiation
▫ Non-repudiation is the assurance that a message originator
cannot deny any previously sent messages and
commitments or actions.
▫ MAC technique does not provide a non-repudiation service.
If the sender and receiver get involved in a dispute over
message origination, MACs cannot provide a proof that a
message was indeed sent by the sender.
▫ Though no third party can compute the MAC, still sender
could deny having sent the message and claim that the
receiver forged it, as it is impossible to determine which of
the two parties computed the MAC.
Cryptography Digital signatures

• Both these limitations can be overcome by using

the public key based digital signatures discussed
in following section.
• Digital signatures are the public-key primitives of message
authentication. In the physical world, it is common to use
handwritten signatures on handwritten or typed messages.
They are used to bind signatory to the message.
• Similarly, a digital signature is a technique that binds a
person/entity to the digital data. This binding can be
independently verified by receiver as well as any third party.
• Digital signature is a cryptographic value that is calculated
from the data and a secret key known only by the signer.
• In real world, the receiver of message needs assurance that
the message belongs to the sender and he should not be able
to repudiate the origination of that message. This requirement
is very crucial in business applications, since likelihood of a
dispute over exchanged data is very high.
Model of Digital Signature

• As mentioned earlier, the digital signature

scheme is based on public key cryptography. The
model of digital signature scheme is depicted in
the following illustration −
•
The following points explain the entire
process in detail −
• Each person adopting this scheme has a public-private key
pair.
• Generally, the key pairs used for encryption/decryption and
signing/verifying are different. The private key used for
signing is referred to as the signature key and the public key
as the verification key.
• Signer feeds data to the hash function and generates hash of
data.
• Hash value and signature key are then fed to the signature
algorithm which produces the digital signature on given hash.
Signature is appended to the data and then both are sent to
the verifier.
• Verifier feeds the digital signature and the verification key
into the verification algorithm. The verification algorithm
gives some value as output.
• Verifier also runs same hash function on
received data to generate hash value.
• For verification, this hash value and output of
verification algorithm are compared. Based on
the comparison result, verifier decides whether
the digital signature is valid.
• Since digital signature is created by ‘private’ key
of signer and no one else can have this key; the
signer cannot repudiate signing the data in
future.
• It should be noticed that instead of signing data
directly by signing algorithm, usually a hash of
data is created. Since the hash of data is a unique
representation of data, it is sufficient to sign the
hash in place of data. The most important reason
of using hash instead of data directly for signing
is efficiency of the scheme.
• Let us assume RSA is used as the signing
algorithm. As discussed in public key encryption
chapter, the encryption/signing process using
RSA involves modular exponentiation.
• Signing large data through modular
exponentiation is computationally expensive and
time consuming. The hash of the data is a
relatively small digest of the data,
hence signing a hash is more efficient than
signing the entire data.
Importance of Digital Signature

• Out of all cryptographic primitives, the digital

signature using public key cryptography is
considered as very important and useful tool to
achieve information security.
• Apart from ability to provide non-repudiation of
message, the digital signature also provides
message authentication and data integrity. Let
us briefly see how this is achieved by the digital
signature −
• Message authentication − When the verifier
validates the digital signature using public key of a
sender, he is assured that signature has been created
only by sender who possess the corresponding secret
private key and no one else.
• Data Integrity − In case an attacker has access to
the data and modifies it, the digital signature
verification at receiver end fails. The hash of
modified data and the output provided by the
verification algorithm will not match. Hence,
receiver can safely deny the message assuming that
data integrity has been breached.
• Non-repudiation − Since it is assumed that only
the signer has the knowledge of the signature key, he
can only create unique signature on a given data.
Thus the receiver can present data and the digital
signature to a third party as evidence if any dispute
arises in the future.
• By adding public-key encryption to digital signature
scheme, we can create a cryptosystem that can
provide the four essential elements of security
namely − Privacy, Authentication, Integrity, and
Non-repudiation.
Encryption with Digital Signature

• In many digital communications, it is desirable to

exchange an encrypted messages than plaintext to
achieve confidentiality. In public key encryption scheme,
a public (encryption) key of sender is available in open
domain, and hence anyone can spoof his identity and
send any encrypted message to the receiver.
• This makes it essential for users employing PKC for
encryption to seek digital signatures along with
encrypted data to be assured of message authentication
and non-repudiation.
• This can archived by combining digital signatures with
encryption scheme. Let us briefly discuss how to achieve
this requirement. There are two possibilities, sign-
then-encrypt and encrypt-then-sign.
• However, the crypto system based on sign-then-
encrypt can be exploited by receiver to spoof
identity of sender and sent that data to third
party. Hence, this method is not preferred. The
process of encrypt-then-sign is more reliable and
widely adopted. This is depicted in the following
illustration −
• The receiver after receiving the encrypted data
and signature on it, first verifies the signature
using sender’s public key. After ensuring the
validity of the signature, he then retrieves the
data through decryption using his private key.
Authentication protocol
• An authentication protocol is a type of computer
communications protocol or cryptographic protocol
specifically designed for transfer of authentication
data between two entities. It allows the receiving
entity to authenticate the connecting entity (e.g.
Client connecting to a Server) as well as authenticate
itself to the connecting entity (Server to a client) by
declaring the type of information needed for
authentication as well as syntax.[1] It is the most
important layer of protection needed for secure
communication within computer networks.
• Purpose
• With the increasing amount of trustworthy
information being accessible over the network, the
need for keeping unauthorized persons from access
to this data emerged. Stealing someone's identity is
easy in the computing world - special verification
methods had to be invented to find out whether the
person/computer requesting data is really who he
says he is.[2] The task of the authentication protocol
is to specify the exact series of steps needed for
execution of the authentication. It has to comply
with the main protocol principles:
• A Protocol has to involve two or more parties
and everyone involved in the protocol must
know the protocol in advance.
• All the included parties have to follow the
protocol.
• A protocol has to be unambiguous - each step
must be defined precisely.
• A protocol must be complete - must include a
specified action for every possible situation.
• An illustration of password-based authentication using simple
authentication protocol:

• Alice (an entity wishing to be verified) and Bob (an entity verifying Alice's
identity) are both aware of the protocol they agreed on using. Bob has
Alice's password stored in a database for comparison.

• Alice sends Bob her password in a packet complying with the protocol rules.
• Bob checks the received password against the one stored in his database.
Then he sends a packet saying "Authentication successful" or
"Authentication failed" based on the result.[3]
• This is an example of a very basic authentication protocol vulnerable to
many threats such as eavesdropping, replay attack, man-in-the-middle
attacks, dictionary attacks or brute-force attacks. Most authentication
protocols are more complicated in order to be resilient against these
attacks.[4]
Types of Authentication Protocols

• User authentication is the first most priority

while responding to the request made by the
user to the software application. There are
several mechanisms made which are required to
authenticate the access while providing access to
the data.
1.Kerberos :
• Kerberos is a protocol that aids in network
authentication. This is used for validating
clients/servers during a network employing a
cryptographic key. It is designed for executing
strong authentication while reporting to
applications. The overall implementation of the
Kerberos protocol is openly available by MIT
and is used in many mass-produced products.
Some advantages of Kerberos :

• It supports various operating systems.

• The authentication key is shared much
efficiently than public sharing.
Some disadvantages of Kerberos :
• It is used only to authenticate clients and
services used by them.
• It shows vulnerability to soft or weak passwords.
2. Lightweight Directory Access
Protocol (LDAP) :
• LDAP refers to Lightweight Directory Access
Protocol. It is a protocol that is used for
determining any individuals, organizations, and
other devices during a network regardless of
being on public or corporate internet. It is
practiced as Directories-as-a-Service and is the
grounds for Microsoft building Activity
Directory.
Some advantages of LDAP :

• It is an automated protocol which makes it

modernizing easier.
• It supports existing technologies and allows multiple
directories.
Some disadvantages of LDAP :

• It requires the experience of deployment.

• The directory servers are required to be LDAP
obedient for deployment.
3. OAuth2 :
• OAuth as the name suggests it is an
authorization framework that promotes granting
limited access to the user on its account through
an HTTP service. When a user requests access to
resources an API call is made and after the
authentication token is passed.
Some advantages of OAuth2 :

• It is a simple protocol and is easy to implement.

• It provides server-side authorization of code.
Some disadvantages of OAuth2 :
• It is vulnerable to manage different sets of code.
• It shows serious effects on sites connected to
another affected system.
4. SAML :
• SAML stands for Security Assertion Markup
Language which is based on XML-based
authentication data format which provides the
authorization between an identity provider and
service provider. It serves as a product of the
OASIS Security Services Technical Committee.
Some advantages of SAML :

• It reduced the administrative costs for the end-

users.
• It provides a single sign-in for authenticating
across service providers.
• Some disadvantages of SAML :

• It is dependent on the identity provider.

• All the data is managed in a single XML format.
5. RADIUS :
• RADIUS stands for Remote Authentication Dial-
In User Service. It is a network protocol that
provides sufficient centralized Authentication,
Accounting, and Authorization for the users that
use and network services. The functioning of the
protocol occurs when the user requests access to
network resources, where the RADIUS server
encrypts the credentials which are entered by the
user. After this, the user credentials are mapped
through the local database and provide access.
Some advantages of RADIUS :
• It is a great mechanism for providing multiple
access for Admins.
• It provides a unique identity to each user in a
session.
• Some disadvantages of RADIUS :

• Initial implementation for this mechanism is

hard on hardware.
• It has a variety of models that may require a
special team which is cost consuming.
• Differentiating between the protocols will not
make justice to the protocols because it depends
on the use of the application and for what
purpose it is being used.
•
Digital Signature Standard (DSS)
• As we have studied, signature is a way of authenticating
the data coming from a trusted individual. Similarly,
digital signature is a way of authenticating a digital data
coming from a trusted source.

• Digital Signature Standard (DSS) is a Federal

Information Processing Standard(FIPS) which defines
algorithms that are used to generate digital signatures
with the help of Secure Hash Algorithm(SHA) for the
authentication of electronic documents. DSS only
provides us with the digital signature function and not
with any encryption or key exchanging strategies.
• Sender Side :
• In DSS Approach, a hash code is generated out of
the message and following inputs are given to the
signature function –

• The hash code.

• The random number ‘k’ generated for that particular
signature.
• The private key of the sender i.e., PR(a).
• A global public key(which is a set of parameters for
the communicating principles) i.e., PU(g).
• These input to the function will provide us with
the output signature containing two components
– ‘s’ and ‘r’. Therefore, the original message
concatenated with the signature is sent to the
receiver.
• Receiver Side :
• At the receiver end, verification of the sender is
done. The hash code of the sent message is
generated. There is a verification function which
takes the following inputs –

• The hash code generated by the receiver.

• Signature components ‘s’ and ‘r’.
• Public key of the sender.
• Global public key.
• The output of the verification function is compared
with the signature component ‘r’. Both the values
will match if the sent signature is valid because only
the sender with the help of it private key can
generate a valid signature.

• Attention reader! Don’t stop learning now. Get hold

of all the important CS Theory concepts for SDE
interviews with the CS Theory Course at a student-
friendly price and become industry ready.

•
Difference between MD5 and SHA1
• Prerequisite – SHA-1 Hash, MD5 and SHA1
• Both MD5 stands for Message Digest and SHA1
stands for Secure Hash Algorithm square measure
the hashing algorithms wherever The speed of MD5
is fast in comparison of SHA1’s speed.

• However, SHA1 provides more security than MD5.

The construct behind these hashing algorithms is
that these square measure accustomed generate a
novel digital fingerprint of knowledge or message
that is understood as a hash or digest.
Some features of hash algorithms are
given below:

• The has functions can’t be restrained.

• The size of the hash (or digest) is often fastened
and doesn’t rely upon the scale of the info.
• No 2 distinct information set square measure
able to manufacture the same hash.
Let’s see the difference between MD5
and SHA1 which are given below:
S.NO MD5 SHA1

MD5 stands for Message While SHA1 stands for

1.
Digest. Secure Hash Algorithm.

MD5 can have 128 bits Whereas SHA1 can have

2. length of message 160 bits length of
digest. message digest.

The speed of MD5 is fast While the speed of SHA1

3. in comparison of SHA1’s is slow in comparison of
speed. MD5’s speed.

To make out the initial

message the aggressor On the opposite hand, in
would want 2^128 SHA1 it’ll be 2^160 that
4.
operations whereas makes it quite
exploitation the MD5 troublesome to seek out.
algorithmic program.
 MD5 is simple than While SHA1 is more
5.
SHA1. complex than MD5.

While it provides
MD5 provides indigent
6. balanced or tolerable
or poor security.
security.

In MD5, if the assailant

needs to seek out the 2 Whereas in SHA1,
messages having assailant would need to
7. identical message digest perform 2^80
then assailant would operations which is
need to perform 2^64 greater than MD5.
operations.

While SHA1 was

MD5 was presented in
8. presented in the year
the year 1992.
1995.
Authentication Applications
• 1. KERBEROS:
Kerberos provides a centralized authentication
server whose function is to authenticate users to
servers and servers to users. Kerberos relies
exclusively on conventional encryption, making no
use of public-key encryption.
The following are the requirements for
Kerberos:
• Secure: A network eavesdropper should not be able to obtain
the necessary information to impersonate a user. More
generally, Kerberos should be strong enough that a potential
opponent does not find it to be the weak link.

• Reliable: For all services that rely on Kerberos for access

control, lack of availability of the Kerberos service means lack
of availability of the supported services. Hence, Kerberos
should be highly reliable and should employ a distributed
server architecture, with one system able to back up another.

•
• Transparent: Ideally, the user should not be
aware that authentication is taking place,
beyond the requirement to enter a password.
• Scalable: The system should be capable of
supporting large numbers of clients and servers.
This suggests a modular, distributed architecture.

• To support these requirements, the overall scheme

of Kerberos is that of a trusted third-party
authentication service that uses a protocol based on
that proposed by Needham and Schroeder
[NEED78] It is trusted in the sense that clients and
servers trust Kerberos to mediate their mutual
authentication. Assuming the Kerberos protocol is
well designed, then the authentication service is
secure if the Kerberos server itself is secure.
A Simple Authentication Dialogue

• In an unprotected network environment, any client can apply

to any server for service.

• The obvious security risk is that of impersonation. To counter

this threat, servers must be able to confirm the identities of
clients who request service. But in an open environment, this
places a substantial burden on each server.

• An alternative is to use an authentication server (AS) that

knows the passwords of all users and stores these in a
centralized database. In addition, the AS shares a unique
secret key with each server.
The simple authentication dialogue is
as follows:
• C >> AS: IDc||Pc||IDv

• AS >> C: Ticket

• C >> V: IDc||Ticket Ticket=

• EKv(IDc||ADc||IDv)

•
• C: Client,

• AS: Authentication Server, V: Server,

• IDv : ID of the server, IDc : ID of the client,

• Pc:Password of the client, ADc: Address of client,

• Kv: secret key shared by AS and V, ||: concatenation.

•
2. A More Secure Authentication
Dialogue

• There are two major problems associated with the

previous approach:

• Plaintext transmission of the password.

•
• Each time a user has to enter the password.

• To solve these problems, we introduce a scheme

for avoiding plaintext passwords, and anew
server, known as ticket granting server (TGS).
The hypothetical scenario is as follows: Once
• per user logon session:

• C >> AS: IDc||IDtgs

• AS >> C: Ekc (Tickettgs)

• Once per type of service:

•
•

• C >> TGS: IDc||IDv||Tickettgs

• TGS >> C: ticketv

• Once per service session:

• 5. C >> V: IDc||ticketv

• Tickettgs= Ektgs(IDc||ADc||IDtgs||TS1||Lifetime1) Ticketv=

• Ekv(IDc||ADc||IDv||TS2||Lifetime2)
• C: Client, AS: Authentication Server, V: Server, IDc : ID
of the client, Pc:Password of the client, ADc: Address of
client, IDv : ID of the server, Kv: secret key shared by AS
and V, ||: concatenation, IDtgs: ID of the TGS server,
TS1, TS2: time stamps, lifetime: lifetime of the ticket.

• The new service, TGS, issues tickets to users who have

been authenticated to AS. Thus, the user first requests a
ticket-granting ticket (Tickettgs) from the AS. The client
module in the user
• workstation saves this ticket. Each time the user
requires access to a new service, the client applies to
the TGS, using the ticket to authenticate itself. The
TGS then grants a ticket for the particular service.
The client saves each service-granting ticket and
uses it to authenticate its user to a server each time a
particular service is requested. Let us look at the
details of this scheme:

•
• The client requests a ticket-granting ticket on behalf
of the user by sending its user's ID and password to
the AS, together with the TGS ID, indicating a
request to use the TGS service.

• The AS responds with a ticket that is encrypted with

a key that is derived from the user's password.

•
• When this response arrives at the client, the client
prompts the user for his or her password, generates
the key, and attempts to decrypt the incoming
message.

• If the correct password is supplied, the ticket is

successfully recovered.

•
• Because only the correct user should know the password, only the correct
user can recover the ticket. Thus, we have used the password to obtain
credentials from Kerberos without having to transmit the password in
plaintext.

• Now that the client has a ticket-granting ticket, access to any server can be
obtained with steps 3 and 4:

• The client requests a service-granting ticket on behalf of the user. For this
purpose, the client transmits a message to the TGS containing the user's ID,
the ID of the desired service, and the ticket-granting ticket.

•
• The TGS decrypts the incoming ticket and verifies the success of the
decryption by the presence of its ID. It checks to make sure that the lifetime
has not expired. Then it compares the user ID and network address with the
incoming information to authenticate the user. If the user is permitted
access to the server V, the TGS issues a ticket to grant access to the
requested service.

• The service-granting ticket has the same structure as the ticket-granting

ticket. Indeed, because the TGS is a server, we would expect that the same
elements are needed to authenticate a client to the TGS and to authenticate
a client to an application server. Again, the ticket contains a timestamp and
lifetime. If the user wants access to the same service at a later time, the
client can simply use the previously acquired service-granting ticket and
need not bother the user for a password. Note that the ticket is encrypted
with a secret key (Kv) known only to the TGS and the server, preventing
alteration.
• Finally, with a particular service-granting ticket, the client can gain
access to the corresponding service with step 5:

• The client requests access to a service on behalf of the user. For this
purpose, the client transmits a message to the server containing the
user's ID and the service-granting ticket. The server authenticates
by using the contents of the ticket.

• This new scenario satisfies the two requirements of only one

password query per user session and protection of the user
password.
• Kerbero V4 Authentication Dialogue Message
Exchange
• Two additional problems remain in the more secure authentication
dialogue:

• Lifetime associated with the ticket granting ticket. If the lifetime is very
short, then the user will be repeatedly asked for a password. If the lifetime
is long, then the opponent has the greater opportunity for replay.

• hRequirement for the servers to authenticate themselves to users.

• have an Authentication Server (AS)

• users initially negotiate with AS to identify self

• AS provides a non-corruptible authentication credential ticket

granting ticket TGT)

• have a Ticket Granting server (TGS)

• users subsequently request access to other services from TGS

on basis of users TGT
• a basic third-party authentication scheme

•
• have an Authentication Server (AS)

• users initially negotiate with AS to identify self

•
• AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)

• have a Ticket Granting server (TGS)

• users subsequently request access to other services

from TGS on basis of users TGT
1 Kerberos Realms and Multiple Kerberi

• A full-service Kerberos environment consisting of a Kerberos

server, a number of clients, and a

• number of application servers requires the following:

• The Kerberos server must have the user ID and hashed

passwords of all participating users in its database. All users
are registered with the Kerberos server.
• The Kerberos server must share a secret key with
each server. All servers are registered with the
Kerberos server.

• Such an environment is referred to as a Kerberos

realm.
The concept of realm can be explained
as follows.
• A Kerberos realm is a set of managed nodes that share the same
Kerberos database. The Kerberos database resides on the Kerberos
master computer system, which should be kept in a physically
secure room.

• A read-only copy of the Kerberos database might also reside on

other Kerberos computer systems.

• However, all changes to the database must be made on the master

computer system. Changing or accessing the contents of a Kerberos
database requires the Kerberos master password.
• The Kerberos server in each interoperating realm shares
a secret key with the server in the other realm. The two
Kerberos servers are registered with each other.

• The scheme requires that the Kerberos server in one

realm trust the Kerberos server in the other realm to
authenticate its users. Furthermore, the participating
servers in the second realm must also be willing to trust
the Kerberos server in the first realm.
2 Kerberos version 5
• Version 5 of Kerberos provides a number of
improvements over version 4.

• developed in mid 1990‟s

• provides improvements over v4

•
• addresses environmental shortcomings

• and technical deficiencies

• specified as Internet standard RFC 151

• Differences between version 4 and 5

• Version 5 is intended to address the limitations of version 4 in two areas:

•
Environmental shortcomings
• encryption system dependence o internet
protocol dependence

• message byte ordering

• ticket lifetime

• authentication forwarding

• inter-realm authentication
Technical deficiencies
• double encryption

• PCBC encryption o Session keys

• Password attacks
The version 5 authentication dialogue
• First, consider the authentication service exchange.
Message (1) is a client request for a ticket-granting ticket.
As before, it includes the ID of the user and the TGS. The
following new elements are added:

• Realm: Indicates realm of user

• Options: Used to request that certain flags be set in the

returned ticket

•
• Times: Used by the client to request the following time
settings in the ticket: from: the desired start time for the
requested ticket

• till: the requested expiration time for the requested ticket

rtime: requested renew-till time

• Nonce: A random value to be repeated in message (2) to

assure that the response is fresh and has not been replayed by
an opponent
• Message (2) returns a ticket-granting ticket, identifying information for the client, and a
block encrypted using the encryption key based on the user's password.

• This block includes the session key to be used between the client and the TGS, times
specified in message (1), the nonce from message (1), and TGS identifying information.

• The ticket itself includes the session key, identifying information for the client, the
requested time values, and flags that reflect the status of this ticket and the requested
options.

• These flags introduce significant new functionality to version 5. For now, we defer a
discussion of these flags and concentrate on the overall structure of the version 5 protocol.

•
• Let us now compare the ticket-granting service exchange for versions 4 and 5. We see that
message (3) for both versions includes an authenticator, a ticket, and the name of the
requested service.

• In addition, version 5 includes requested times and options for the ticket and a nonce, all
with functions similar to those of message (1).

• The authenticator itself is essentially the same as the one used in version 4.

• Message (4) has the same structure as message (2), returning a ticket plus information
needed by the client, the latter encrypted with the session key now shared by the client and
the TGS.

•
• Finally, for the client/server authentication exchange, several new
features appear in version 5. In message (5), the client may request
as an option that mutual authentication is required. The
authenticator includes several new fields as follows:

• Subkey: The client's choice for an encryption key to be used to

protect this

• specific application session. If this field is omitted, the session key

from the ticket (Kc,v) is used.

•
• Sequence number: An optional field that specifies the starting
sequence number to be used by the server for messages sent to the
client during this session. Messages may be sequence numbered to
detect replays.

• If mutual authentication is required, the server responds with

message (6). This message includes the timestamp from the
authenticator. Note that in version 4, the timestamp was
incremented by one. This is not necessary in version 5 because the
nature of the format of messages is such that it is not possible for an
opponent to create message (6) without knowledge of the
appropriate encryption keys.

•
• Ticket Flags

• The flags field included in tickets in version 5

supports expanded functionality compared to
that available in version 4.
X.509 Certificates
• 1. Overview:
• issued by a Certification Authority (CA), containing:

• version (1, 2, or 3)

• serial number (unique within CA) identifying certificate

• signature algorithm identifier

• issuer X.500 name (CA)

• period of validity (from - to dates)

• subject X.500 name (name of owner)

• subject public-key info (algorithm, parameters, key)

• issuer unique identifier (v2+)

• subject unique identifier (v2+)

• extension fields (v3)

• signature (of hash of all fields in certificate)

notation CA<<A>> denotes certificate for A signed by CA

X.509 defines a framework for the provision of authentication services by the

X.500 directory to

its users. The directory may serve as a repository of public-key certificates.

Each certificate contains the public key of a user and is signed with the private
key of a trusted certification authority. In addition, X.509 defines alternative
authentication protocols based on the use of public-key certificates.
• X.509 is an important standard because the
certificate structure and authentication protocols

• defined in X.509 are used in a variety of contexts.

For example, the X.509 certificate format is

• used in S/MIME), IP Security and SSL/TLS and SET

2. Certificates
• The heart of the X.509 scheme is the public-key
certificate associated with each user.

• These user certificates are assumed to be created by

some trusted certification authority (CA) and

• placed in the directory by the CA or by the user.

•
• Version:

• Differentiates among successive versions of the certificate format; the

default is version 1. If the Issuer Unique Identifier or Subject Unique
Identifier are present, the value must be version 2. If one or more
extensions are present, the version must be version 3.

• Serial number:

• An integer value, unique within the issuing CA, that is unambiguously

associated with this certificate.
4. Signature algorithm identifier:
• The algorithm used to sign the certificate, together with any associated parameters.
Because this information is repeated in the Signature field at the end of the certificate, this
field has little, if any, utility.

• 4. Issuer name:

• X.500 name of the CA that created and signed this certificate.

• Period of validity:

• Consists of two dates: the first and last on which the certificate is valid.

•
• name:

• The name of the user to whom this certificate refers.

That is, this certificate certifies the public key of the
subject who holds the corresponding private key.

• Subject's public-key information:

• The public key of the subject, plus an identifier of the

algorithm for which this key is to be used, together with
any associated parameters.
• Issuer unique identifier:

• An optional bit string field used to identify uniquely the issuing CA

in the event the X.500 name has been reused for different entities.

• Subject unique identifier:

• An optional bit string field used to identify uniquely the subject in

the event the X.500 name has been reused for different entities.
• Extensions:
• A set of one or more extension fields. Extensions
were added in version 3 and are discussed later
in this section.

• Signature:

•
• Covers all of the other fields of the certificate; it contains the
hash code of the other fields, encrypted with the CA's private
key. This field includes the signature algorithm identifier.

• The standard uses the following notation to define a

certificate:

• CA<<A>> = CA {V, SN, AI, CA, TA, A, Ap}

•
• Where, Y <<X>> = the certificate of user X issued by
certification authority Y

• Y {I} = the signing of I by Y. It consists of I with an

encrypted hash code appended

• The CA signs the certificate with its private key. If the

corresponding public key is known to a user, then that
user can verify that a certificate signed by the CA is valid.
3. Obtaining a User's Certificate

• User certificates generated by a CA have the following

characteristics:

• o Any user with access to the public key of the CA can verify
the user public key that was certified.

• o No party other than the certification authority can modify

the certificate without this being detected.

•
• Because certificates are unforgeable, they can be
placed in a directory without the need for the
directory to make special efforts to protect them.

• If all users subscribe to the same CA, then there is a

common trust of that CA. All user certificates can be
placed in the directory for access by all users.

•
• If there is a large community of users, it may not be
practical for all users to subscribe to the same CA.
Because it is the CA that signs certificates, each
participating user must have a copy of the CA's own
public key to verify signatures. This public key must be
provided to each user in an absolutely secure (with
respect to integrity and authenticity) way so that the user
has confidence in the associated certificates. Thus, with
many users, it may be more practical for there to be a
number of CAs, each of which securely provides its
public key to some fraction of the users.

•
• Now suppose that A has obtained a certificate from certification authority
X1 and B has obtained a certificate from CA X2. If A does not securely know
the public key of X 2, then B's certificate, issued by X2, is useless to A.

• A can read B's certificate, but A cannot verify the signature. However, if the
two CAs have securely exchanged their own public keys, the following
procedure will enable A to obtain B's public key:

• o A obtains, from the directory, the certificate of X2 signed by X1. Because

A securely knows X1's public key, A can obtain X2's public key from its
certificate and verify it by means of X1's signature on the certificate.

•
• A then goes back to the directory and obtains the certificate of B signed by X2 Because A now has a trusted copy of X2's
public key, A can verify the signature and securely obtain B's public key.

• A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is

• expressed as

• X1<<X2>> X2 <<B>>

• In the same fashion, B can obtain A's public key with the reverse chain:

• X2<<X1>> X1 <<A>>
• X2<<X1>> X1 <<A>>

• This scheme need not be limited to a chain of two certificates. An arbitrarily long path of
CAs can be followed to produce a chain. A chain with N elements would be expressed as

• X1<<X2>> X2 <<X3>>... XN<<B>>

• In this case, each pair of CAs in the chain (Xi, Xi+1) must have created certificates for each
other.

•
• In this case, each pair of CAs in the chain (Xi, Xi+1)
must have created certificates for each other.

• All these certificates of CAs by CAs need to appear in

the directory, and the user needs to know how they
are linked to follow a path to another user's public-
key certificate. X.509 suggests that CAs be arranged
in a hierarchy so that navigation is straightforward.

•
• From X.509, is an example of such a hierarchy. The connected
circles indicate the hierarchical relationship among the CAs; the
associated boxes indicate certificates maintained in the directory for
each CA entry. The directory entry for each CA includes two types of
certificates:

• o Forward certificates: Certificates of X generated by other CAs

• o Reverse certificates: Certificates generated by X that are the

certificates of other CAs

•
4. CA Hierarchy Use
• In the example given below , user A can acquire the following
certificates from the directory to establish a certification path
to B:

• X<<W>> W <<V>> V <<Y>> <<Z>> Z <<B>>

• When A has obtained these certificates, it can unwrap the

certification path in sequence to recover a

•
• trusted copy of B's public key. Using this public key, A
can send encrypted messages to B. If A wishes to receive
encrypted messages back from B, or to sign messages
sent to B, then B will require A's public key, which can be
obtained from the following certification path:

Z<<Y>> Y <<V>> V <<W>> W <<X>>X <<A>>

• B can obtain this set of certificates from the directory, or
A can provide them as part of its initial message to B.

•
• Certificate Revocation

• o certificates have a period of validity

• o may need to revoke before expiry, for the following reasons eg:

• § user's private key is compromised

• § user is no longer certified by this CA

• § CA's certificate is compromised

• o CA‟s maintain list of revoked certificates

• § the Certificate Revocation List (CRL)

• o users should check certs with CA‟s CRL

Authentication Procedures
• X.509 includes three alternative authentication
procedures:

• o One-Way Authentication

• o Two-Way Authentication

• o Three-Way Authentication

• o all use public-key signatures

One-Way
• Authentication

• o 1 message ( A->B) used to establish

• o the identity of A and that message is from A

• o message was intended for B

• o integrity & originality of message

• o message must include timestamp, nonce, B's identity and is signed by A

•
Two-Way Authentication
• 2 messages (A->B, B->A) which also establishes in
addition:

• a. the identity of B and that reply is from B

• b. that reply is intended for A

• c. integrity & originality of reply

• 2. reply includes original nonce from A, also

timestamp and nonce from B
Three-Way Authentication
• o 3 messages (A->B, B->A, A->B) which enables above
authentication without synchronized clocks

• o has reply from A back to B containing signed copy of nonce

from B

• o means that timestamps need not be checked or relied upo