Public Key Infrastructure by Muhedin Abdullahi Mohammed

1
Public key Infrastructure by Muhedin Abdullahi Mohammed

1.1 Introduction
Computers and use of the Internet have fostered new interest in

cryptography partly due to the new emphasis on personal privacy. Little is realized
that in our efforts to make it easy for computers to share stuff, it would make it
easy for other people to see all of our personal stuff, too. Perhaps you’ve
discovered for yourself that it is far too easy for unknown persons to read your e-
mail, private documents, love letters, financial information, and so on. The Internet
is truly the Global Village, a village where everyone can see what you do and hear
what you say. The good news is that you can use cryptography to protect yourself
from the eavesdroppers and Peeping Toms of the village.
Not only can cryptography scramble your files, but it can also be used to
prove who you are (and maybe who you aren’t!). Cryptography can be used to
alert you if the contents of a file have been changed, attest to the identity of the
person who sent you a message, keep online communications safe and secure, and,
of course, hide important data. And the best news of all is that not every
cryptographic solution is expensive, and you don’t need to be a rocket scientist to
incorporate crypto solutions into your network.
Because cryptography is usually associated with spies, secret messages, and

clandestine meetings, you might have thought that cryptography stopped being
used at the end of the Cold War. Believe it or not, its use is actually on the rise. We
think that’s partially due to more awareness of personal identity theft and also
because more is being written in the media about how data needs more protection
that a common PC gives you. [1]
1.2 What is Cryptography?
Everyone has secrets; some have more than others. When it becomes
necessary to transmit those secrets from one point to another, it's important to
protect the information while it's in transit. Cryptography, which is the art of
keeping messages secure, presents various methods for taking legible, readable
data, and transforming it into unreadable data for the purpose of secure
transmission, and then using a key to transform it back into readable data when it
reaches its destination. [2]
The best way to prevent the misuse of critical information is to convert into
a form that is unintelligible to a person who gains unauthorized access to it. The
Egyptians were among the first people to develop a technique that was used to
disguise important information. This technique is called cryptography.
Cryptography is an art of converting information into a secret code that can be
interpreted only by a person who knows how to decode
The process of distinguishing information into an unintelligible form is

known as encryption. The information that needs to be distinguished is called
plaintext. The encrypted information is called ciphertext. After the encrypted
information reaches its destination it has to be converted into a plaintext so that the
information is intelligible. The process of converting ciphertext into plaintext is
known as decryption. Encryption and decryption require the use of some secret
information, usually referred to as a key. Depending on the encryption mechanism
used, the same key might be used for both encryption and decryption; in such a
case the mechanism is known as secret key cryptography. While for other
International University of Africa Faculty of computer studies
mechanisms, the keys used for encryption and decryption might be different and
that is known as public key cryptography [3]
Fig 1.1: process of cryptography [4]
Predating computers by thousands of years, cryptography has its roots in

basic transposition ciphers, which assigns each letter of the alphabet a particular
value. A simple example is to assign each letter a progressively higher number,
where A=1, B=2, and so forth. Using this formula for example, the word "Islam",
once encrypted, would read "9 19 12 1 13".
The Secure Sockets Layer (SSL) is a common encryption protocol used in e-

commerce. When you make a purchase over the Internet, this is the technology the
merchant uses to make sure you can safely transmit your credit card information.
Using this protocol, your computer and the online merchant's computer agree to
create a type of private "tunnel" through the public Internet. This process is called
the "handshake." When you see a URL in your Web browser that starts with
"https" instead of "http", it is a secure connection that is using SSL.
The goal of cryptography extends beyond merely making data unreadable, it

also extends into user authentication that is, providing the recipient with assurance
that the encrypted message originated from a trusted source.

The study of cryptography is advancing steadily, and scientists are rapidly

creating mechanisms that are more difficult to break. The most secure type of
cryptography yet may be quantum cryptography, a method that has not yet been
perfected, which instead of using a key, relies on the basic laws of physics, and the
movement and orientation of photons to establish a connection that is absolutely
secure and unbreakable. . [2]
Cryptography is the art of secret writing.
1.3 Types of Cryptography
Cryptography has been implemented in many ways. During war

times, messages were encoded in a number of ways. The methods ranged
from writing hidden messages in musical score to the arrangement of the 52
cards in a pack so that their order of placement represents specific
information. Now cryptography is used in information technology, it is also
used in computations in different ways.
There are several ways of classifying cryptographic algorithms. For

purposes of this research, they will be categorized based on the number of
keys that are employed for encryption and decryption, and further defined
by their application and use. The three types of cryptography that will be
discussed are:-[3]
1. Private (secret) Key Cryptography (SKC).

2. Public Key Cryptography (PKC).

3. Hash functions.
1.3.1 Private Key Cryptography
Most cryptography techniques are key based. A key is a mathematical value

that is attached to plaintext. This key has a formula that encrypts or decrypts the
information. With private key cryptography also known as secret key cryptography
(SKC), a single key is used for both encryption and decryption. As shown in Figure
1.2, the sender uses the key to encrypt the plaintext and sends the ciphertext to the
receiver. The receiver applies the same key to decrypt the message and recover the
plaintext. Because a single key is used for both functions, secret key cryptography
is also called symmetric encryption.
With this form of cryptography, it is obvious that the key must be known to
both the sender and the receiver; that, in fact, is the secret. The biggest difficulty
with this approach, of course, is the distribution of the key.
Secret key cryptography schemes are generally categorized as being either

stream ciphers or block ciphers. Stream ciphers operate on a single bit at a time
and implement some form of feedback mechanism so that the key is constantly
changing. A block cipher is so-called because the scheme encrypts one block of
data at a time using the same key on each block. In general, the same plaintext
block will always encrypt to the same ciphertext when using the same key in a
block cipher whereas the same plaintext will encrypt to different ciphertext in a
stream cipher.
Stream ciphers come in several flavors but two are worth mentioning here.
Self-synchronizing stream ciphers calculate each bit in the keystream as a function
of the previous n bits in the keystream. It is termed "self-synchronizing" because the
decryption process can stay synchronized with the encryption process merely by
knowing how far into the n-bit keystream it is. One problem is error propagation; a
garbled bit in transmission will result in n garbled bits at the receiving side.
Synchronous stream ciphers generate the keystream in a fashion independent of the
message stream but by using the same keystream generation function at sender and
receiver. While stream ciphers do not propagate transmission errors, they are, by
their nature, periodic so that the keystream will eventually repeat.
Block ciphers can operate in one of several modes; the following four are
the most important:
 Electronic Codebook (ECB) mode is the simplest, most obvious

application: the secret key is used to encrypt the plaintext block to form a
ciphertext block. Two identical plaintext blocks, then, will always generate
the same ciphertext block. Although this is the most common mode of block
ciphers, it is susceptible to a variety of brute-force attacks.
 Cipher Block Chaining (CBC) mode adds a feedback mechanism to the
encryption scheme. In CBC, the plaintext is exclusively-ORed (XORed)
with the previous ciphertext block prior to encryption. In this mode, two
identical blocks of plaintext never encrypt to the same ciphertext.
 Cipher Feedback (CFB) mode is a block cipher implementation as a self-
synchronizing stream cipher. CFB mode allows data to be encrypted in units
smaller than the block size, which might be useful in some applications such
as encrypting interactive terminal input. If we were using 1-byte CFB mode,
7
for example, each incoming character is placed into a shift register the same
size as the block, encrypted, and the block transmitted. At the receiving side,
the ciphertext is decrypted and the extra bits in the block (i.e., everything
above and beyond the one byte) are discarded.
 Output Feedback (OFB) mode is a block cipher implementation
conceptually similar to a synchronous stream cipher. OFB prevents the same
plaintext block from generating the same ciphertext block by using an
internal feedback mechanism that is independent of both the plaintext and
ciphertext bitstreams.
Fig 1.2 Secret Key Cryptography
Secret key cryptography algorithms that are in use today include:
 Data Encryption Standard (DES): The most common SKC scheme used
today, DES was designed by IBM in the 1970s and adopted by the National
Bureau of Standards (NBS) [now the National Institute for Standards and
Technology (NIST)] in 1977 for commercial and unclassified government
applications. DES is a block-cipher employing a 56-bit key that operates on
64-bit blocks. DES has a complex set of rules and transformations that were
designed specifically to yield fast hardware implementations and slow
software implementations, although this latter point is becoming less

significant today since the speed of computer processors is several orders of
magnitude faster today than twenty years ago.
 Advanced Encryption Standard (AES): the Advanced Encryption Standard,
became the official successor to DES in December 2001. AES uses an SKC
scheme called Rijndael, a block cipher designed by Belgian cryptographers
Joan Daemen and Vincent Rijmen. The algorithm can use a variable block
length and key length; the latest specification allowed any combination of
keys lengths of 128, 192, or 256 bits and blocks of length 128, 192, or 256
bits. NIST initially selected Rijndael in October 2000 and formal adoption
as the AES standard came in December 2001.
 Blowfish: A symmetric 64-bit block cipher invented by Bruce Schneier;
optimized for 32-bit processors with large data caches, it is significantly
faster than DES on a Pentium/PowerPC-class machine. Key lengths can vary
from 32 to 448 bits in length. Blowfish, available freely and intended as a
substitute for DES or IDEA, is in use in over 80 products.[5]
Private Key cryptography is very efficient in terms of processing speed and using
minimal computing resources, but has two limiting security problems:-
o First, how can two individuals who are interacting for the first time over an
insecure network (such as the Internet) exchange a symmetric key securely?

If the individuals tried to transmit the symmetric key over the insecure
network, intending to encrypt information with it in subsequent
communications, an attacker could intercept it key while in transit and use it
to intercept and decrypt the later messages that the individuals hoped to keep
confidential. Alternatively, an attacker could perform processes of his own
with the symmetric key to make it appear as if a message written by the
attacker had actually originated from the one of the individuals trying to
communicate over the insecure network.
o Second, since both the ―sender‖ and the ―receiver‖ of a message share the
same symmetric key, the authentication and integrity is not provable to a

third party who does not also hold the key. Thus, while the authentication
and integrity of a message may be sufficient between two trusted
individuals, the sender could deny, or repudiate, the message. In general,
symmetric cryptography cannot provide the additional security sever called
non-repudiation. [3]
1.3.2 Public-Key Cryptography
Public-key cryptography has been said to be the most significant new

development in cryptography in the last 300-400 years. Modern PKC was first
described publicly by Stanford University professor Martin Hellman and graduate
student Whitfield Diffie in 1976. Their paper described a two-key crypto system in
which two parties could engage in a secure communication over a non-secure
communications channel without having to share a secret key.
PKC depends upon the existence of so-called one-way functions, or

mathematical functions that are easy to compute whereas their inverse function is
relatively difficult to compute. Let us give you two simple examples:
1. Multiplication vs. factorization: Suppose we tell you that we have two

numbers, 9 and 16, and that we want to calculate the product; it should take
almost no time to calculate the product, 144. Suppose instead that we tell
you that we have a number, 144, and we need you tell us which pair of
integers we multiplied together to obtain that number. You will eventually
10

come up with the solution but whereas calculating the product took
milliseconds, factoring will take longer because you first need to find the 8
pair of integer factors and then determine which one is the correct pair.
2. Exponentiation vs. logarithms: Suppose we tell you that we want to take
the number 3 to the 6th power; again, it is easy to calculate 3 6=729. But if
we tell you that we have the number 729 and want you to tell us the two
integers that we used, x and y so that logx 729 = y, it will take you longer to
find all possible solutions and select the pair that we used.
While the examples above are trivial, they do represent two of the functional
pairs that are used with PKC; namely, the ease of multiplication and
exponentiation versus the relative difficulty of factoring and calculating
logarithms, respectively. The mathematical "trick" in PKC is to find a trap door in
the one-way function so that the inverse calculation becomes easy given
knowledge of some item of information.
Generic PKC employs two keys that are mathematically related although
knowledge of one key does not allow someone to easily determine the other key.
One key is used to encrypt the plaintext and the other key is used to decrypt the
ciphertext. The important point here is that it does not matter which key is applied
first, but that both keys are required for the process to work (Figure 1.3). Because a
pair of keys is required, this approach is also called asymmetric cryptography.
In PKC, one of the keys is designated the public key and may be advertised
as widely as the owner wants. The other key is designated the private key and is
never revealed to another party. It is straight forward to send messages under this
scheme. Suppose Ali wants to send Mohamed a message. Ali encrypts some
information using Mohamed's public key; Mohamed decrypts the ciphertext using
11
his private key. This method could be also used to prove who sent a message; Ali,
for example, could encrypt some plaintext with his private key; when Mohamed
decrypts using Ali's public key, he knows that Ali sent the message and Ali cannot
deny having sent the message (non-repudiation).
Fig 1.3 Public Key Cryptography
Public-key cryptography algorithms that are in use today for key exchange or
digital signatures include:
 RSA: The first, and still most common, PKC implementation, named for the
three mathematicians who developed it — Ronald Rivest, Adi Shamir, and
Leonard Adleman. RSA today is used in hundreds of software products and
can be used for key exchange, digital signatures, or encryption of small
blocks of data. RSA uses a variable size encryption block and a variable size
key. The key-pair is derived from a very large number, n, that is the product
of two prime numbers chosen according to special rules; these primes may
be 100 or more digits in length each, yielding an n with roughly twice as
many digits as the prime factors. The public key information includes n and
a derivative of one of the factors of n; an attacker cannot determine the
prime factors of n (and, therefore, the private key) from this information
alone and that is what makes the RSA algorithm so secure. Some
descriptions of PKC erroneously state that RSA's safety is due to the
difficulty in factoring large prime numbers. In fact, large prime numbers,
12
like small prime numbers, only have two factors! The ability for computers
to factor large numbers, and therefore attack schemes such as RSA, is
rapidly improving and systems today can find the prime factors of numbers
with more than 200 digits. Nevertheless, if a large number is created from
two prime factors that are roughly the same size, there is no known
factorization algorithm that will solve the problem in a reasonable amount of
time. Regardless, one presumed protection of RSA is that users can easily
increase the key size to always stay ahead of the computer processing curve.
As an aside, the patent for RSA expired in September 2000 which does not
appear to have affected RSA's popularity one way or the other.
 Diffie-Hellman: After the RSA algorithm was published, Diffie and
Hellman came up with their own algorithm. D-H is used for secret-key key
exchange only, and not for authentication or digital signatures.
 ElGamal: Designed by Taher Elgamal, a PKC system similar to Diffie-
Hellman and used for key exchange.[5]
It is worth mentioning that there are some advantages and disadvantages For PKC
over SKC among which are the following:-
o Increased security is one the most important advantages of public key
cryptography over secret key cryptography. This is because public key

cryptography uses both public key and private key for encryption. The
private key is known only to the owner of the key and the public key is
shared with authorized users. In secret key cryptography only the public key
is used for encryption. This public key is sent over the network to be shared
with the other users. While being transferred any intruder can track and
misuse it.
13

o Another advantage of public key cryptography is that it ensures non-
repudiation. This is possible because the owners use their private keys,
which is only known to them, to encrypt information. Any information
signed by that key is safe because no one other than the intended recipient
knows about the private key therefore the sender can not deny sending the
information. In the case of secret key cryptography the public key is not
secret; therefore the sender can deny it sending the message. This is because
the public key can be hacked and used by intruders for transactions.
o One disadvantage of public key cryptography is that it is slower than the
secret key cryptography, this is because, in the public key cryptography the
sender has to first obtain the intended receiver’s public key to send
information .[3]
1.3.3 Hash functions

Hash function is mathematical algorithm. There is no concept of keys in the
hash functions. A hash function accepts information as data attaches a value to this
information and sends it. The most important advantage of the hash function is that
no one can tamper with the information that is transmitted this technique. This is
because the hash function is one-way cryptography technique. A hash function is
said to be one-way because even if the output of a hash function is known, it is
impossible to determine the input that constitutes the original information.
For example, if data X is encrypted using a hash function to generate a value, Y, it
is impossible to recover the value of X if Y is known. Hash functions are used to
create signatures. These signatures are used to authenticate users.
A hash function is also used to protect passwords; specially UNIX systems
apply the hash function to user’s password and store the hash value and not the
14

password itself. To authenticate the user a password is requested and the response
runs through a hash function to generate the hash value. If the user supplies the
correct password and is authenticated, the resulting hash value is the same as the
stored value. The hash function is irreversible, which implies that obtaining the
hash value doesn’t reveal the password to an attacker. Hash functions can be used
to generate signatures. Assume that both the sender and the recipient of some data
share a public key then by combining the data message with the public key, and
running it through hash function, a signature is generated in the form of a hash
value. The data message is transmitted with the signature.The recipient combines
the received message the public key to generate a hash value. If the hash value is
identical with the hash value that was sent with data message, it implies that the
data signatures are identical. In this way the authenticity of the message is verified.
[3]
Fig 1.4 hash function [5]
Hash algorithms that are in common use today include:
 Message Digest (MD) algorithms: A series of byte-oriented algorithms that

produce a 128-bit hash value from an arbitrary-length message.
o MD2: Designed for systems with limited memory, such as smart
cards.
15

o MD4: Developed by Rivest, similar to MD2 but designed specifically
for fast processing in software.
o MD5: Also developed by Rivest after potential weaknesses were
reported in MD4; this scheme is similar to MD4 but is slower because
more manipulation is made to the original data. MD5 has been
implemented in a large number of products although several
weaknesses in the algorithm were demonstrated by German
cryptographer Hans Dobbertin in 1996.
 Secure Hash Algorithm (SHA): Algorithm for NIST's Secure Hash
Standard (SHS). SHA-1 produces a 160-bit hash value and describes five
algorithms in the SHS: SHA-1 plus SHA-224, SHA-256, SHA-384, and
SHA-512 which can produce hash values that are 224, 256, 384, or 512 bits
in length, respectively
Hash functions are sometimes misunderstood and some sources claim that
no two files can have the same hash value. This is, in fact, not correct. Consider a
hash function that provides a 128-bit hash value. There are, obviously, 2 128 possible
hash values. But there are a lot more than 2 128 possible files. Therefore, there have
to be multiple files — in fact, there have to be an infinite number of files! — that
can have the same 128-bit hash value.
The difficulty is finding two files with the same hash! What is, indeed, very
hard to do is to try to create a file that has a given hash value so as to force a hash
value collision — which is the reason that hash functions are used extensively for
information security and computer forensics applications. Alas, researchers in
2004 found that practical collision attacks could be launched on MD5, SHA-1, and
other hash algorithms. At this time, there is no obvious successor to MD5 and
SHA-1 that could be put into use quickly; there are so many products using these
hash functions that it could take many years to flush out all use of 128- and 160-bit
hashes. . [5]
PGP uses a cryptographically strong hash function on the plaintext the user
is signing. This generates a fixed-length data item known as a message digest.
(Again, any change to the information results in a totally different digest.) Then
PGP uses the digest and the private key to create the ―signature.‖ PGP transmits
the signature and the plaintext together. Upon receipt of the
message, the recipient uses PGP to recompute the digest, thus verifying the
signature. PGP can encrypt the plaintext or not; signing plaintext is useful if some
of the recipients are not interested in or capable of verifying the signature.
As long as a secure hash function is used, there is no way to take someone's
signature from one document and attach it to another, or to alter a signed message
in any way. The slightest change in a signed document will cause the digital
signature verification process to fail. The figure below shows the process [4]
Fig 1.5 PGP uses Hash function [4]
1.4 Digital Cryptography Basics

This section introduces a number of basic building blocks of modern digital
cryptography, describes what they can do for you, and explains how to compose
them to produce useful and practical secure services. [6]
1.4.1 Message Digests
Message digest functions convert sequences of bits, possibly quite long,

called messages, into fixed-length binary "fingerprints" or message digests of the
original sequences. See Figure 1.6. A message digest function has two goals:
 It should be computationally infeasible to find another message whose

digest is the same as the digest of a given message.
18
 It should be computationally infeasible to find two arbitrary messages whose

digests are the same.
Fig 1.6 Message digest function
In the common case where an authentication method takes a large amount of

computational effort and that effort is proportional to the number of bits being
authenticated, you can secure a large document by authenticating its much smaller
fixed-size message digest.
A message digest function is not identical to a checksum. A checksum is
usually quite simple and is designed to detect transmission errors or accidental
changes. An adversary can deliberately circumvent the testing of a checksum by
adjusting the message to leave the checksum unchanged. By comparison, a
message digest is complex and is designed to defeat attempts by an adversary to
change the message.
First, consider a checksum calculated by simply adding all octets in a
message and discarding the bits of the sum above the least significant eight bits. In
most cases, an adversary could easily modify the message to become a different
message with the same checksum. For example, inserting an octet with value V
19

into the message will have no effect on the checksum if you can also insert a
second octet with value (256 - V) anywhere in the message.
Next, consider a more complex function in which you take the product of
the octets in the message, adding to each octet its position in the message, and the
check octet is the middle eight bits of this product. For example, if the message
consists of bytes with values
Then the check octet is the middle eight bits of
With this level of complexity, it is no longer quite so trivial for an adversary

to figure out how to change the message without changing the check byte,
although it can still be done. Cryptographically or computationally secure message
digest functions are substantially more complex than this example, producing
check quantities of at least 128 bits or 16 eight-bit bytes. They largely meet the
following goals.
Expressing the goals of message digests more formally, if the message

digest is N bits, then
1. To find a second message with the same message digest as a given message,
no method should require an expected effort significantly less than trying 2N-
1
possible other messages;
2. To find two arbitrary messages with the same message digest, no method
should require an expected effort significantly less than trying 2 N/2
messages, remembering all their digests, and looking for a match.
Like other modern digital cryptographic functions, message digest functions

are typically used and sometimes defined only for integer numbers of octets, rather
than arbitrary numbers of bits [6]
1.4.2 Message Authentication Codes
A message authentication code (MAC) function computes a MAC from a

message and a secret key. If the originator and the receiver share knowledge of that
secret key, the receiver can calculate the same function of the message and secret
key and see if it matches the MAC accompanying the message. See figure 1.7.If
the MAC matches, then you know, within the strength of the MAC function and
key, that some program with possession of the secret produced the MAC. Of
course, every program that can verify the MAC needs to know this secret. Thus all
of them can create valid MACs even if they should only receive and verify these
codes.
Fig 1.7 Message authentication codes
A simple MAC function might append the secret to the message, then
calculate a message digest of the result and use it as the MAC. The message
(without the secret) and MAC could then be sent to the recipient. The recipient
would also append the secret (which the receiver needs to know as well) to the
message and calculate the same message digest function. If the resulting digest
matches the MAC, it validates the message.
A difficulty with MAC authentication in a system with multiple originators

and receivers is that you must choose between two strategies, both of which have
problems:
1. Have a different secret for every pair of entities. This method is logistically
difficult because the number of keys increases with the square of the number
of entities and the keys must be securely distributed. If the system includes
E number of entities, you have E*(E – 1)/2 pairs. For example, for 100
entities, you have 4950 pairs. For 1000 entities, you have 499,500 pairs.
2. Share one secret among all the entities. This technique is relatively insecure.
The more entities that have a secret, the more likely the secret is to be
compromised due to loss, subversion, or betrayal. This technique also means
the same secret will be used many times; the more exposures of the uses of a
secret, the easier an adversary may find it to break that secret analytically. In
addition, with this strategy any of the entities can forge messages from any
of the other entities and a recipient will be unable to detect this fraud based
on the MAC.
As with message digest functions, if a strong MAC is N bits long, the

difficulty of finding two messages with the same MAC is proportional to 2N/2. You
should pick N large enough for your application and then, to avoid the secret
quantity being the weak point, use a secret quantity that is random and at least N/2
bits long. For example, if you need a 160-bit MAC, the secret key should be at
least 80 random bits. [6]
1.4.3 Digital Signatures
You can use public key authentication to produce "digital signatures"

These signatures have a very desirable characteristic—namely, it is
computationally infeasible for anyone without the private key to produce a
signature that will verify for a given message. Modern digital signatures consist of
(1) a message and (2) a message digest of that message asymmetrically
transformed under a private key of the signer. See Figure 1.8
Fig 1.8 Digital signature
A typical implementation of digital signature involves a message-digest, a

private key for encrypting the message digest, and a public-key for decrypting the
message digest. The digital signature procedure is as follows:
 The sender. The software used by the sender computes; using a standard
algorithm, a ―message digest‖ from the message. The message digest is
unique to the original message in that only the original, unmodified message
could have produced the message digest. The sender then encrypts the
message digest with his private key, yielding an encrypted message digest.
24
He sends the message and the encrypted message digest to a recipient. The
two parts together form the digitally signed message.
 The recipient. The recipient decrypts the received message digest with the
signer’s public key. The recipient then computes a message digest from the
received message using the same algorithm as the signer. He then compares
the decrypted received message digest to the computed message digest. If
the two are the same, he accepts the message.The recipient knows that the
signer has sent the message because only the sender’s public key will work.
However, it still remains that a particular public key be unquestionably
associated with a particular individual or organization.[6]
1.5 Cryptanalysis
Cryptanalysis is the study of methods for obtaining the meaning of
encrypted information, without access to the secret information which is normally
required to do so. Typically, this involves finding the secret key. In non-technical
language, this is the practice of code-breaking or cracking the code, although these
phrases also have a specialized technical meaning.
Even though the goal has been the same, the methods and techniques of
cryptanalysis have changed drastically through the history of cryptography,
adapting to increasing cryptographic complexity, ranging from the pen-and-paper
methods of the past, through machines like Enigma in World War II, to the
computer-based schemes of the present. The results of cryptanalysis have also
changed it is no longer possible to have unlimited success in code breaking, and
there is a hierarchical classification of what constitutes a rare practical attack. In
the mid-1970s, a new class of cryptography was introduced: asymmetric
cryptography. Methods for breaking these cryptosystems are typically radically
25

different from before, and usually involve solving carefully-constructed problems

in pure mathematics, the best-known being integer factorization. [7]
1.5.1 Classical cryptanalysis
Although the actual word "cryptanalysis" is relatively recent methods for

breaking codes and ciphers are much older. The first known recorded explanation
of cryptanalysis was given 9th century by Arabian polymath Abu Yusuf Yaqub ibn
Ishaq al-Sabbah Al-Kindi in A Manuscript on Deciphering Cryptographic
Messages. This treatise includes a description of the method of frequency analysis.
Frequency analysis is the basic tool for breaking most classical ciphers. In
natural languages, certain letters of the alphabet appear more frequently than
others; in English, "E" is likely to be the most common letter in any sample of
plaintext. Similarly, the digraph "TH" is the most likely pair of letters in English,
and so on. Frequency analysis relies on a cipher failing to hide these statistics. For
example, in a simple substitution cipher (where each letter is simply replaced with
another), the most frequent letter in the ciphertext would be a likely candidate for
"E".
In practice, frequency analysis relies as much on linguistic knowledge as it

does on statistics, but as ciphers became more complex, mathematics became more
important in cryptanalysis.[7]
1.5.2 Modern cryptanalysis
Even though computation was used to great effect in cryptanalysis in World

War II, it also made possible new methods of cryptography orders of magnitude
more complex than ever before. Taken as a whole, modern cryptography has
26
become much more impervious to cryptanalysis than the pen-and-paper systems of

the past, and now seems to have the upper hand against pure cryptanalysis.
In industry, ciphers are not free from flaws: for example, the A5/1, A5/2 and
CMEA algorithms, used in mobile phone technology, can all be broken in hours,
minutes or even in real-time using widely-available computing equipment. [7]
1.6 Key Concepts
A key is a value that works with a cryptographic algorithm to produce a

specific ciphertext. Keys are basically really, really, really big numbers. Key size is
measured in bits; the number representing a 1024-bit key is darn huge. In public
key cryptography, the bigger the key, the more secure the ciphertext. However,
public key size and conventional cryptography’s secret key size are totally
unrelated. A conventional 80-bit key has the equivalent strength of a 1024-bit
public key. A conventional 128-bit key is equivalent to a 3000-bit public key.
Again, the bigger the key, the more secure, but the algorithms used for each type of
cryptography are very different and thus comparison is like that of apples to
oranges. While the public and private keys are mathematically related, it’s very
difficult to derive the private key given only the public key; however, deriving the
private key is always possible given enough time and computing power. This
makes it very important to pick keys of the right size; large enough to be secure,
but small enough to be applied fairly quickly. Additionally, you need to consider
who might be trying to read your files, how determined they are, how much time
they have, and what their resources might be. Larger keys will be
cryptographically secure for a longer period of time. If what you want to encrypt
needs to be hidden for many years, you might want to use a very large key. Of
27

course, who knows how long it will take to determine your key using tomorrow’s
faster, more efficient computers? There was a time when a 56-bit symmetric key
was considered extremely safe. Keys are stored in encrypted form. PGP stores the
keys in two files on your hard disk; one for public keys and one for private keys.
These files are called keyrings. As you use PGP, you will typically add the public
keys of your recipients to your public keyring. Your private keys are stored on
your private keyring. If you lose your private keyring, you will be unable to
decrypt any information encrypted to keys on that ring. [4]
1.6.1 Key management
In cryptography, key management includes all of the provisions made in a

cryptosystem design, in cryptographic protocols in that design, in user procedures,
and so on, which are related to generation, exchange, storage, safeguarding, use,
vetting, and replacement of keys. There is a distinction between key management,
which concerns keys at the users' level (i.e., passed between systems or users or
both), and key scheduling which is usually taken to apply to the handling of key
material within the operation of a cipher.
Appropriate and successful key management is critical to the secure use of

every crypto system without exception. It is, in actual practice, the most difficult
aspect of cryptography generally, for it involves system policy, user training,
organizational and departmental interactions in many cases, coordination between
end users, etc.
Many of these concerns are not limited to cryptographic engineering and so

are outside a strictly cryptographic brief, though of critical importance. As a result,
some aspects of key management fall between two stools as the cryptographers
28
may assume this or that aspect is the responsibility of the using department or
upper management or some such, while said department or upper management
regard it all as being outside their concerns because 'technical', and so within the
purview of the cryptographers.[7]
1.6.2 Key Distribution
For symmetric encryption to work, the two parties to an exchange must

share the same key, and that key must be protected from access by others.
Furthermore, frequent key changes are usually desirable to limit the amount of data
compromised if an attacker learns the key. Therefore, the strength of any
cryptographic system rests with the key distribution technique, a term that refers to
the means of delivering a key to two parties who wish to exchange data, without
allowing others to see the key. For two parties A and B, key distribution can be
achieved in a number of ways, as follows:
1. A can select a key and physically deliver it to B.
2. A third party can select the key and physically deliver it to A and B.
3. If A and B have previously and recently used a key, one party can transmit
the new key to the other, encrypted using the old key.
4. If A and B each has an encrypted connection to a third party C, C can
deliver a key on the encrypted links to A and B.
Options 1 and 2 call for manual delivery of a key. For link encryption, this is
a reasonable requirement, because each link encryption device is going to be
exchanging data only with its partner on the other end of the link. However, for
end-to-end encryption, manual delivery is awkward. In a distributed system, any
given host or terminal may need to engage in exchanges with many other hosts and
29
terminals over time. Thus, each device needs a number of keys supplied
dynamically. The problem is especially difficult in a wide area distributed system.
Option 3 is a possibility for either link encryption or end-to-end encryption,

but if an attacker ever succeeds in gaining access to one key, then all subsequent
keys will be revealed. Furthermore, the initial distribution of potentially millions of
keys must still be made.
For end-to-end encryption, some variation on option 4 has been widely

adopted. In this scheme, a key distribution center is responsible for distributing
keys to pairs of users (hosts, processes, applications) as needed. Each user must
share a unique key with the key distribution center for purposes of key distribution.
For asymmetric key distribution or public key distribution several

techniques have been proposed for it. Virtually all these proposals can be grouped
into the following general schemes:
 Public announcement
 Publicly available directory
 Public-key authority
 Public- certificates
In public announcement of PKs, the point of public-key encryption is that

the public key is public. Thus, if there is some broadly accepted public-key
algorithm, such as RSA, any participant can send his or her public key to any other
participant or broadcast the key to the community at large. For example, because
of the growing popularity of PGP (pretty good privacy), which makes use of RSA,
many PGP users have adopted the practice of appending their public key to
messages that they send to public forums, such as USENET newsgroups and
30
Internet mailing lists. Although this approach is convenient, it has a major

weakness. Anyone can forge such a public announcement. That is, some user could
pretend to be user A and send a public key to another participant or broadcast such
a public key. Until such time as user A discovers the forgery and alerts other
participants, the forger is able to read all encrypted messages intended for A and
can use the forged keys for authentication.
A greater degree of security can be achieved by maintaining a publicly

available dynamic directory of public keys. Maintenance and distribution of the
public directory would have to be the responsibility of some trusted entity or
organization. The authority maintains a directory with a {name, public key} entry
for each participant.
Stronger security for public-key distribution can be achieved by providing

tighter control over the distribution of public keys from the directory. The scenario
of this is attractive, yet it has some drawbacks. The public-key authority could be
somewhat of a bottleneck in the system, for a user must appeal to the authority for
a public key for every other user that it wishes to contact. As before, the directory
of names and public keys maintained by the authority is vulnerable to tampering.
An alternative approach, first suggested by Kohnfelder is to use certificates

that can be used by participants to exchange keys without contacting a public-key
authority, in a way that is as reliable as if the keys were obtained directly from a
public-key authority. In essence, a certificate consists of a public key plus an
identifier of the key owner, with the whole block signed by a trusted third party.
Typically, the third party is a certificate authority, such as a government agency or
a financial institution that is trusted by the user community. A user can present his
or her public key to the authority in a secure manner, and obtain a certificate. The
31

user can then publish the certificate. Anyone needed this user's public key can
obtain the certificate and verify that it is valid by way of the attached trusted
signature. A participant can also convey its key information to another by
transmitting its certificate. Other participants can verify that the certificate was
created by the authority.[10]
1.6.3 Key Protection
A good passphrase is one method of protecting your keys, but almost as

important is the need to store your keys in a non-obvious location. If you are on a
network with a full PKI (Public Key Infrastructure) system, there’s probably not
much you can do about that as the system administrators will have set up key
servers, back-up keys, and recovery keys (if they’re good, that is!). But what do
you do if you’re using your own system? There are four good, safe methods of
keeping your keys safe:
1. Don’t save your keys on your desktop computer.
2. If you must store your keys on your desktop computer, see if you can change
the name of the folder or locate the keys in a different directory. Always
save copies of your keys to a removable drive such as a USB keychain drive,
CD, or floppy disk or even a flash.
3. Keep the USB drive, CD, floppy or the flash with your keys on your person.
4. If you cannot keep your key storage media on you, put it in a safe place such
as a safe, a bank safe-deposit box, or a locking cabinet.[1]
Chapter Two
2.1 Introduction
One of the big motivators behind public key cryptography is that there is
some hope for securely exchanging encryption keys in an insecure medium.
However, that is not as easy as it sounds. If used in a naïve manner, the basic
public key methods for communication are susceptible to a man-in-the-middle
attack, in which the two parties end up talking to an attacker who relays messages,
instead of to each other.
` Man-in-the-middle attacks are possible because public key cryptography in

and of itself provides no means of establishing trust. PKI provides the means to
establish trust by binding public keys and identities together in a way that gives
reasonable assurance that we are communicating securely with the expected entity.
Using public key cryptography, we can be sure that if we encrypt data with a
public key, only someone with the corresponding private key can decrypt it. If we
simply exchange public keys over an insecure medium, there is no easy way to be
sure that the public keys we receive belong to the people we think they do. In other
words, traditional public key cryptography does not establish trust between
entities. That is where PKI comes in.
The basic idea behind public key infrastructure is to introduce a trusted third
party to the mix. The idea is that we somehow acquire the public key of the trusted
third party over a secure medium. In addition, each entity registers its public key
with that trusted party, along with information about that entity. Basically, the
trusted party is expected to ensure that the public key really does belong to the
registrant and all of the associated data is accurate. If the authority approves,
certificate is certified, which is a piece of data containing our public key along
34
with other identifying information. Once our certificate has been signed, we can
hand that certificate to anyone, and as long as that person has securely obtained the
authority's public key, he can take our certificate and validate it by checking the
authority's signature. [13]
Complex business systems, e-commerce and automated business

transactions require robust and rigorous security measures. Companies using the
Internet environment as a platform to conduct business have a better probability of
success if they accommodate the needs of security-conscious clientele. Today’s
Internet clientele demand stringent security protocols to protect their interests,
privacy, communication, value exchange, and information assets.[9]
2.2 What does the e-commerce mean?
A company that performs any online activity is generally considered an e-

commerce company. Online activity means any business operation conducted over
a network 24 hours a day and 7 days a week all year round. Under this definition,
all kinds of business activities on the Web such as
 buying, selling, and trading

 service provision
 banking
 entertainment
are characterized as e-commerce or e-business. Although e-commerce is a

relatively new term even from our computer dictionary, it was widely used by
many big corporations decades ago. In particular, the banking industry used
Electronic Funds Transfer (EFT) to transfer money between accounts and/or banks
35
long before the creation of the Internet. Also, many big companies and government
organizations use the so-called Electronic Data Interchange (EDI) sharing
information among divisions and/or departments. Business over a small network
environment has become very active only since the easy availability of databases
and computers.
Before the advent of the Internet, e-commerce or any online business was
expensive. Usually some dedicated underground wiring or channels using
microwave technologies were involved to provide a direct link among the
dedicated organizations. The physical link and data transmission format were
usually proprietary and therefore established an essential secure environment for
the business activity. These kinds of business still exist and are active today. In
fact, many people consider this kind of e-commerce as business over a secure
channel or network.
The Internet opened the flood gates for affordable networking. Twenty-four
hours a day and 7 days a week, connecting people all over the globe is no longer a
problem. All of a sudden, we have a global economy reaching every corner of the
world. For example, a luxury home or house auction in South Africa can instantly
attract hundreds of buyers from Europe and North America. All buying, selling,
and other transactions can be completed within minutes. It is believed that total
Internet money transactions will be more than a trillion dollas by that time. This is
the power of bringing people and business together.
On the other hand, with the same network type and data transmission
protocol, e-commerce on the Internet operates in an insecure environment. In
general, from a security point of view, the Internet is a place where anybody can be
everybody. Again, all of a sudden, online fraud occurs everywhere.
36

For example, if someone has ordered some goods from your Web site on the
Internet, do you trust his or her identity? Do you trust his or her credit card
number? Even if you can get the money from the credit card company, how do you
know you are not charging someone else illegally? In fact, online security is a big
issue for us all, not just businesses.
In order to provide a secure business transaction in an insecure network or

environment, a number of technologies are introduced. In particular the Public-Key
Infrastructure (PKI) with digital keys, certificates, the Certification Authority
(CA), and the Secure Sockets Layer (SSL) are introduced in some detail. [8]
2.3 Certificates
Certificates contain a wealth of information that can be used to tie the public
key inside the certificate to an entity, either an individual or an organization.
Certificates have the name of the entity, called the distinguished name in the PKI
world. Server-side certificates also usually contain the fully qualified domain name
of the server. They have an expiration date, which means we will have to go back
and get a new certificate periodically.
A digital certificate contains information about the person or organization to

whom it was issued (the subject) as well as information about the organization that
issued the certificate (the issuer). The issuer signs the certificate with its private
key, and the certificate may contain all of the information necessary to validate
that signature, including its public key. However, such information should not
actually be used to validate the signature on the certificate. After all, anyone could
create a key pair to use in signing, place it in the certificate, and claim it is from
the issuer.

37

Certificates also have a serial number that is unique, at least across all certificates
from a given issuer. The serial number can be used to identify a certificate quickly.
The basic idea here is that the issuer signs the certificate with its private key, so
anyone who has securely obtained the issuer's public key will be able to validate
the authenticity of the entire certificate. The entity to whom the certificate was
issued cannot change data in it, such as the expiration date. If he or she tries, the
signature will not check out.
Clearly, the issuer is vouching that the information in the certificate is correct
when it signs. If we trust the issuer's validation of the core information, we should
be able to trust its signature.
Once a certificate has been issued, it is generally put into production. The
entity with the certificate gives it to parties that wish to communicate. Other
people can validate the certificate by checking the signature, assuming that they
have securely obtained the public key of the issuer. They can encrypt data to the
public key found in the certificate, and only the entity to which the certificate was
issued should have the corresponding private key needed to decrypt the data.
The issuer does not even have a copy of the private key. Generally, the subject
generates a key pair (a public key and an associated private key) and bundles the
public key along with a bunch of information into a certificate-signing request. The
certification authority (often called simply a CA) or its designate authenticates the
data, perhaps requiring interaction from the subject. Then, when it is confident
enough, the CA will create the final certificate, sign it, and give it back to the
subject. Each Digital Certificate contains the following information: the figure 2.1
below show an example of a certificate.
38

Fig 2.1 Digital Certificate [1]
Managing Digital Certificates and the associated keys requires policies and
procedures to deal with issuance, storage, recovery, modification, and so on. That,
in a nutshell, is really what the infrastructure in Public Key Infrastructure is all
about. Almost anyone can set up a server to issue Digital Certificates and keys, but
it takes a whole lot more to effectively build and manage a system that can handle
the complexities and the traffic load without completely falling apart. [13]
2.4 PKI Components
Different components comprise a PKI. A PKI is a framework of people,

processes, policies, protocols, hardware, and software used to generate, manage,
store, deploy, and revoke public key certificates. The following outlines the typical
components in a PKI used in an e-commerce environment. Note that although the
security and integrity of the physical infrastructure is important to the successful
implementation of a PKI, that subject is beyond the scope of this research [9]
2.4.1 Certificate Authority (CA)
A Certification Authority (CA) is an organization or company that issues

certificates. By its very nature, a CA has a huge responsibility to ensure that the
certificates it issues are legitimate. That is, the CA must ensure beyond all
reasonable doubt that every certificate it issues contains a public key that was
issued by the party that claims to have issued it. It must be able to produce
acceptable proof for any certificate that it issues on demand. Otherwise, how can
the CA itself be trusted?
A CA must be trusted, and so for that trust to be extended, its certificate
containing its public key must be widely distributed. For public CAs, their
certificates are generally published so that anyone can obtain them. More
commonly, the software that makes use of them, such as a web browser, is shipped
containing them.
There are two basic types of CAs. A private CA has the responsibility of
issuing certificates only for members of its own organization, and is likewise
trusted only by members of its own organization. A public CA, such as VeriSign
or Thawte, has the responsibility of issuing certificates for any member of the
40
public, and must be trusted by the public. The burden of proof varies depending on
the type of CA that has issued a certificate and the type of certificate that is issued.
A private CA is often ideal for use in a corporate setting. For example, a
company could set up its own CA for email, using S/MIME as the standard for
encrypting and authenticating email messages. The company's CA would issue
certificates to each employee, and each employee would configure their S/MIME-
capable email clients to recognize the company's CA as being trusted. For a private
CA, verifying the identity of a subject is often a reasonably simple and
straightforward matter. When used in a corporate environment, for example,
employees are known, and their identities can be easily identified using
information obtained from the company's human resources department. In such a
scenario, the human resources department is said to be acting as a Registration
Authority (RA).
A public CA commonly issues certificates for public web sites requiring
encryption and/or authentication, often for e-commerce in which customer
information must be transmitted securely to place an order. For such operations,
it's essential that the customers transmit their information to the site that is
supposed to be receiving it without worrying about someone else obtaining the
information. For a public CA, verifying the identity of a subject is considerably
more difficult than it is for a private CA. The information required from the subject
to prove its identity to the CA varies depending on whether the subject is an
individual or a business. For an individual, the proof required could be as simple as
a photocopy of a government-issued ID, such a driver's license or passport. For a
business or other organization, similar government documentation proving your
right to use the name will also likely be required.
It's important to note that most public CAs provide their services to make
money, and not to simply benefit the public. They still have a responsibility to
41

verify a subject's identity, but not actually guarantee anything—the liability is too
great to provide an absolute guarantee. Certainly, it is in the CA's best interests to
verify a subject's identity to the best of its ability, however. If a CA gains the
reputation of issuing certificates to anyone who asks (and pays them enough
money), they're not going to remain in business for very long because nobody will
trust them. [14]
We can think of a Certificate Authority (CA) as the king. He is the ultimate

authority and a figure of great trust. He is in charge of making identity papers for
all his subjects. He signs these papers and stamps them with the Royal Stamp.
Along with the identity papers he lists what responsibilities and privileges the
bearer has. Because the king has issued and signed these papers, all subjects of the
PKI kingdom trust these papers.
In order to set up a working PKI, we have to go to the king of the PKI

kingdom and ask for one of these identity papers. This identity paper identifies us
to the PKI kingdom and also spells out what tasks we are allowed to do. When the
king is satisfied that our identity has been verified, he signs that paper for us. By
magic, two keys have appeared in our pockets that are linked to the identity paper.
The king keeps a copy of the paper for future reference. This paper is our Digital
Certificate.
One more thing: The king doesn’t really give out Digital Certificates out of
the goodness of his heart. He doesn’t have this huge altruistic streak that makes
him want to make online transactions more secure. No, this is a business to him
and, like all businesses, he charges for his services. And he charges a lot. So, if we
need a lot of certificates from the king (CA), it could get very expensive! So in the
real world, this all translates as follows:
 Our request is sent to a Certificate Authority like Entrust, Verisign,

GeoTrust, Baltimore, Thawte, and so on. The request includes verifiable
personal information about us like a driver’s license number or a passport
number.
 The CA issues us a Digital Certificate after we have completed the
application. During the application process, our computer has generated both
the public and private keys that are linked to the Digital Certificate.
 In order to get our certificate signed by the CA, we send in notarized
paperwork to the CA’s office. After they verify our identity, they sign the
certificate. This is called a root signed certificate.
 Now we can use that certificate to encrypt and/or digitally sign e-mail and to
encrypt and/or digitally sign documents.[1]
2.4.2 Certificate Revocation
Most certificates are given a lifespan when created, but there are times that
you might want to revoke a certificate to keep it from being used. For example, a
person might lose his keys or change positions within the company, or an e-
commerce site using SSL may merge with another company. In these situations,
and many more, a certificate should be revoked. But, this is much easier said than
done.
Do you remember the days when merchants had little booklets of bad credit card
numbers? (Yes, much simpler and more trusting days.) A certificate revocation is
43
much like that. It uses a Certificate Revocation List (CRL) which is a list of
certificate serial numbers signed by the CA. When someone attempts to validate
the certificate, the CA can look up the serial number to see if it is good and form a
response. However, this is yet another job that CAs find very time consuming and
it slows down the process of issuing certificates and the other jobs that a CA is
responsible for. The usual answer is to put the CRL on an LDAP server.
This, though, brings up other problems. How often should the CRL server send
updates to the CA? Should it even send them to the CA or should the
authentication process work some other way? Ideally persons, applications, and
other computers ought to be able to query the CRL via the LDAP which then
queries the CA. These are some of the issues you’ll have to contend with when you
are dealing with Digital Certificates. It’s not a hard job when you have a limited
number of certificates, but when the numbers of certificates reaches into the tens of
thousands, it becomes quite a large task.
There is something you can do to reduce the burden of updating CRLs — and this
is something you can do when certificates are initially issued. There is a field in
the certificate in which you can set an expiration date. When that date comes
around, the certificate automatically becomes unusable for new transactions. Of
course, you’d still have the job of issuing a new certificate to replace the expired
one (like getting a new credit card when your old one reaches its expiration date).
Reissuing a new certificate in this case is a lot easier and less labor intensive than
revoking one and updating the CRL. As we mentioned before, it’s not such a big
deal when you are dealing with a limited number of certificates, but setting
expiration dates should be standard procedure when you are dealing with large
numbers of certificates [1]
44

2.4.3 Registration Authority (RA)
Sometimes the PKI kingdom and the king are overwhelmed or tired of
having to process all the certificate paperwork all of the time. It’s time then to
delegate responsibility to someone else. Enter the Registration Authority (RA). It’s
like the prince of the PKI kingdom and he can do things under the king’s authority.
The prince is a lower-level authority than the king, and in many respects can be
seen as subservient to the king. The king tells the prince what authority he has and
what duties he can undertake. In most situations, the prince acts as a middleman
between the person requesting a Digital Certificate and the king. That’s because
the king can sometimes be overwhelmed with requests coming from many
different entities and the prince can help take a load off. Often the prince will
process applications for identity papers (Digital Certificates) and sometimes give
temporary papers until he can verify the person’s identity and then he forwards the
identity papers to the king for him to sign.
If you have a small organization or a small e-commerce business, you

probably won’t need an RA. As we indicated above, the RA is a type of support
vehicle for a CA that gets overwhelmed with requests. You’ll most often find RA
in large organizations that have many offices. Each office can have its own RA
with the CA located at the headquarters building. The RAs can store up their
requests for signed Digital Certificates and then forward them to the CA to handle
all in one batch. An RA has its own digital signature (which identifies it as an RA)
that is issued by the CA and gives the RA authority and permission to issue Digital
Certificates. The RA’s Digital Certificate is signed by the CA to show that it is
authentic. When an RA issues certificates, it creates a chain of records indicating
the issuance and signing process. Not so amazingly, this downward delegation is
45
called chaining certificates. If you were to examine the details of a Digital

Certificate issued by an RA, you would see a hierarchical relationship and the
certificates at the top of the hierarchy signify a higher level of trust and authority
than those at the bottom of the hierarchy [1]
Fig 2.2 PKI Architecture [10]
2.5 PKI Management Functions

PKI identifies a number of management functions that potentially need to be
supported by management protocols. These are indicated in Figure 2.2 and include
the following:
46

 Registration: This is the process whereby a user first makes itself known to a
CA (directly, or through an RA), prior to that CA issuing a certificate or
certificates for that user. Registration begins the process of enrolling in a
PKI. Registration usually involves some offline or online procedure for
mutual authentication. Typically, the end entity is issued one or more shared
secret keys used for subsequent authentication.
 Initialization: Before a client system can operate securely, it is necessary to

install key materials that have the appropriate relationship with keys stored
elsewhere in the infrastructure. For example, the client needs to be securely
initialized with the public key and other assured information of the trusted
CA(s), to be used in validating certificate paths.
 Certification: This is the process in which a CA issues a certificate for a
user's public key, and returns that certificate to the user's client system
and/or posts that certificate in a repository.
 Key pair recovery: Key pairs can be used to support digital signature
creation and verification, encryption and decryption, or both. When a key
pair is used for encryption/decryption, it is important to provide a
mechanism to recover the necessary decryption keys when normal access to
the keying material is no longer possible, otherwise it will not be possible to
recover the encrypted data. Loss of access to the decryption key can result
from forgotten passwords/PINs, corrupted disk drives, damage to hardware
tokens, and so on. Key pair recovery allows end entities to restore their
encryption/decryption key pair from an authorized key backup facility
(typically, the CA that issued the End Entity's certificate).
47

 Key pair update: All key pairs need to be updated regularly (i.e., replaced
with a new key pair) and new certificates issued. Update is required when
the certificate lifetime expires and as a result of certificate revocation.
 Revocation request: An authorized person advises a CA of an abnormal
situation requiring certificate revocation. Reasons for revocation include
private key compromise, change in affiliation, and name change.
 Cross certification: Two CAs exchange information used in establishing a
cross-certificate. A cross-certificate is a certificate issued by one CA to
another CA that contains a CA signature key used for issuing certificates.[10]
2.6 PKI Security Services
The principle business objectives and risk management controls that can be
implemented by a PKI are summarized in this section. An organization should only
consider the implementation of a PKI if they have an actual business need for one
or more of the security services described in the following sections. Note that these
security services depend on the correct use of accepted certificate formats and
signing protocols. Without adherence to accepted certificate formats and signing
protocols, relying entities cannot determine the correctness of results from various
operations.
2.6.1 Confidentiality
Confidentiality means ensuring that the secrecy and privacy of data is
provided with cryptographic encryption mechanisms. Customer personal
information and legal or contractual data are prime examples of data that should be
48
kept secret by using confidentiality mechanisms. Encryption of data is possible by

using either public (asymmetric), or secret (symmetric) cryptography. Since public
key cryptography is not as efficient as secret key cryptography for data
encipherment, it is normally used to encipher relatively small data objects such as
secret keys used by symmetric-based encryption systems. Symmetric
cryptographic systems are often incorporated into PKIs for bulk data encryption;
thus, they are normally the actual mechanism used to provide confidentiality.
2.6.2 Integrity
Integrity means ensuring that data cannot be corrupted or modified and
transactions cannot be altered. Public key certificates and digital signature
envelopes are good examples of information that must have an assurance of
integrity. Often, the content of messages, emails, purchase transactions and
contracts, and information that others rely on, also require the assurance of
integrity. Integrity can be provided within a PKI by the use of either public
(asymmetric), or secret (symmetric) cryptography. An example of secret key
cryptography used for integrity is DES in Cipher Block Chaining mode where a
Message Authentication Code (MAC) is generated. Note that in the PKI
environment, using symmetric cryptographic systems for implementing integrity
does not scale particularly well. Public key cryptography is typically used in
conjunction with a hashing algorithm such as SHA-1 or MD5 to provide integrity.
A well-designed PKI will use protocols that require the use of these algorithms to
provide an efficient integrity mechanism. .
2.6.3 Authentication
Authentication means verifying that the identity of entities is provided by
the use of public key certificates and digital signature envelopes. Authentication in
49

the e-commerce environment is performed very well by public key cryptographic
systems incorporated into PKIs. In fact, the primary goal of authentication in a PKI
is to support the remote and unambiguous authentication between entities
unknown to each other, using public key certificates and CA trust hierarchies.
Authentication in a PKI environment relies on the mathematical relationship
between the public and private keys. Messages signed by one entity can be tested
by any relying entity. The relying entity can be confident that only the owner of
the private key originated the message, because only the owner has access to the
private key. .
2.6.4 Non-Repudiation
Non-repudiation means ensuring that data cannot be renounced or a
transaction denied. This is provided through public key cryptography by digital
signing. Non-repudiation is a critical security service of any e-commerce
application where value exchanges, legal, or contractual obligations are negotiated.
Non-repudiation is a by-product of using public key cryptography. When data is
cryptographically signed using the private key of a key pair, anyone who has
access to the public key of that pair can determine that only the owner of the key
pair itself could have signed the data in question. For this reason, it is paramount
that end entities secure and protect their private keys used for digitally signing
data.[9]
2.7 Uses For PKI Systems
The dream of PKI was to issue a Digital Certificate to everyone which they
would store on a smart cart, electronic token, floppy disk, or similar device. When
a person wanted to conduct a bank transaction, he/she would insert his/her
certificate token into a reader and would be automatically identified. When he/she
was finished with his/her banking, he/she could board a bus and place his/her
token on the reader which would verify that he/she has a monthly transportation
card. Then, when he/she got home, he/she could log on to his/her favorite online
shopping site and run his/her token through the reader. That would give the
shopping site his/her name, address, store account number, and credit card number.
It is important to understand that a PKI is not by itself an authentication,

authorization, auditing, privacy, or integrity mechanism. Rather, a PKI is an
enabling infrastructure that supports these various business and technical needs. In
particular, a PKI only allows for the identification of entities. For example, a PKI
does not infer trust by itself, but requires the establishment of a trust base, on
which the PKI can rely. This requirement means that the basis of trust must be
established on a personal, business, or other level, before it can be accepted by the
PKI.
A real world example of this is, suppose you misplace your drivers license
and are issued a temporary one which does not have your photograph. A temporary
license without a picture does not allow a store clerk to determine if you are the
owner of it. Therefore, you may not be able to write a check or use a credit card
because your identification mechanism, the temporary license, is not acceptable.
This indicates that the trust inferred by identification is a rather subjective matter.
Therefore, PKI is mainly used for secure transactions between companies or
governmental agencies. An e-commerce Web site that uses SSL for encryption is a
portion of PKI system. Encrypted e-mail is also another transaction that may be a
part of a PKI system. Some companies or agencies may want all staff to digitally
sign any documents they’ve created. Because a digital signature is derived from a
Digital Certificate and its key, this is also part of a PKI system. There are so many
possible scenarios and solutions it’s almost impossible to list them all. However,
PKI in the workplace is usually tied to three things:
1. Identifying system users

2. Using Digital Certificates to describe access permissions
3. Using Digital Certificates to encrypt email and other data
If you’re a small company and can’t afford an expensive PKI system; especially
if you just want to do a few things, you’re much better off using PGP. PGP is a
type of PKI solution without all the overhead. Instead of depending upon
Certificate Authorities and key servers, you rely upon a circle of trusted colleagues
and acquaintances to verify your identity and you use free public key servers to
distribute your public keys. It works well for small organizations, but it can get
really complicated for large ones. PKI can be used to indicate a company’s
commitment to maintaining a secure infrastructure. Note that PKI is not used to
replace any security policies or procedures, but it can be used to strengthen
implementation. Because Digital Certificates can be used to control access to
computers, networks, and documents, it can help keep unauthorized personnel out.
If all documents are digitally signed by their creators, then you can also control the
integrity of your data and also tie ultimate responsibility to the data’s creator. It’s
difficult for someone to say they didn’t write a particular memo if their digital
signature is on it. [1]
2.8 PKI Protocols
To achieve the basic security services mentioned above the public key
infrastructure uses a number of protocols which include the following:-
 SSL,TLS, IPsec for communication and transactional security

 S/MIME and PGP for email security
 SET for value exchange[9]
2.8.1 Secure Socket Layer (SSL)
The Transmission Control Protocol/Internet Protocol (TCP/IP) governs the

transport and routing of data over the Internet. Other protocols, such as the
HyperText Transport Protocol (HTTP), Lightweight Directory Access Protocol
(LDAP), or Internet Messaging Access Protocol (IMAP), run "on top of" TCP/IP
in the sense that they all use TCP/IP to support typical application tasks such as
displaying web pages or running email servers.
Fig 2.3 Position of the SSL protocol
53

The SSL protocol runs above TCP/IP and below higher-level protocols such
as HTTP or IMAP. It uses TCP/IP on behalf of the higher-level protocols, and in
the process allows an SSL-enabled server to authenticate itself to an SSL-enabled
client, allows the client to authenticate itself to the server, and allows both
machines to establish an encrypted connection.
These capabilities address fundamental concerns about communication over the
Internet and other TCP/IP networks:
 SSL server authentication allows a user to confirm a server's identity.
SSL-enabled client software can use standard techniques of public-key
cryptography to check that a server's certificate and public ID are valid and
have been issued by a certificate authority (CA) listed in the client's list of
trusted CAs. This confirmation might be important if the user, for example,
is sending a credit card number over the network and wants to check the
receiving server's identity.
 SSL client authentication allows a server to confirm a user's identity.

Using the same techniques as those used for server authentication, SSL-
enabled server software can check that a client's certificate and public ID are
valid and have been issued by a certificate authority (CA) listed in the
server's list of trusted CAs. This confirmation might be important if the
server, for example, is a bank sending confidential financial information to a
customer and wants to check the recipient's identity.
 An encrypted SSL connection requires all information sent between a

client and a server to be encrypted by the sending software and decrypted by
the receiving software, thus providing a high degree of confidentiality.
54
Confidentiality is important for both parties to any private transaction. In

addition, all data sent over an encrypted SSL connection is protected with a
mechanism for detecting tampering--that is, for automatically determining
whether the data has been altered in transit.
The SSL protocol includes two sub-protocols: the SSL record protocol and the
SSL handshake protocol. The SSL record protocol defines the format used to
transmit data. The SSL handshake protocol involves using the SSL record protocol
to exchange a series of messages between an SSL-enabled server and an SSL-
enabled client when they first establish an SSL connection. This exchange of
messages is designed to facilitate the following actions:
 Authenticate the server to the client.
 Allow the client and server to select the cryptographic algorithms, or
ciphers, that they both support.
 Optionally authenticate the client to the server.
 Use public-key encryption techniques to generate shared secrets.
 Establish an encrypted SSL connection.
2.8.2 Transport Layer Security (TLS)
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer
(SSL), are cryptographic protocols that provide secure communications on the
Internet for such things as web browsing, e-mail, Internet faxing, instant
messaging and other data transfers. There are slight differences between SSL and
TLS, but the protocol remains substantially the same.
The TLS protocol allows applications to communicate across a network in a

way designed to prevent eavesdropping, tampering, and message forgery. TLS
55

provides endpoint authentication and communications privacy over the Internet

using cryptography. Typically, only the server is authenticated (i.e., its identity is
ensured) while the client remains unauthenticated; this means that the end user
(whether an individual or an application, such as a Web browser) can be sure with
whom it is communicating. The next level of security—in which both ends of the
"conversation" are sure with whom they are communicating—is known as mutual
authentication. Mutual authentication requires public key infrastructure (PKI)
deployment to clients unless TLS-PSK or TLS-SRP are used, which provide strong
mutual authentication without needing to deploy a PKI.
TLS involves three basic phases:
1. Peer negotiation for algorithm support

2. Key exchange and authentication
3. Symmetric cipher encryption and message authentication
During the first phase, the client and server negotiate cipher suites, which
determine the ciphers to be used, the key exchange and authentication algorithms,
as well as the message authentication codes (MACs). The key exchange and
authentication algorithms are typically public key algorithms, or as in TLS-PSK
preshared keys could be used. The message authentication codes are made up
from cryptographic hash functions using the HMAC construction
2.8.3 The IPsec Protocol
IPsec protocols operate at the network layer, layer 3 of the OSI model. Other
Internet securities protocols in widespread use, such as SSL, and TLS , operate
from the transport layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it
56

can be used for protecting layer 4 protocols, including both TCP and UDP, the
most commonly used transport layer protocols. IPsec has an advantage over SSL
and other methods that operate at higher layers: an application doesn't need to be
designed to use IPsec, whereas the ability to use SSL or another higher-layer
protocol must be incorporated into the design of an application.
The IP security architecture uses the concept of a security association as the

basis for building security functions into IP. A security association is simply the
bundle of algorithms and parameters (such as keys) that is being used to encrypt
and authenticate a particular flow in one direction. Therefore, in normal bi-
directional traffic, the flows are secured by a pair of security associations. The
actual choice of encryption and authentication algorithms (from a defined list) is
left to the IPsec administrator.
In order to decide what protection is to be provided for an outgoing packet,

IPsec uses the security parameter index (SPI), an index to the security association
database (SADB), along with the destination address in a packet header, which
together uniquely identify a security association for that packet. A similar
procedure is performed for an incoming packet, where IPsec gathers decryption
and verification keys from the security association database.
For multicast, a security association is provided for the group, and is

duplicated across all authorized receivers of the group. There may be more than
one security association for a group, using different SPIs, thereby allowing
multiple levels and sets of security within a group. Indeed, each sender can have
multiple security associations, allowing authentication, since a receiver can only
know that someone knowing the keys sent the data. Note that the relevant standard
does not describe how the association is chosen and duplicated across the group; it
57

is assumed that a responsible party will have made the choice.IPsec was intended
to provide either transport mode or tunnel mode.
In transport mode, only the payload (the data you transfer) of the IP packet
is encrypted and/or authenticated. The routing is intact, since the IP header is
neither modified nor encrypted; however, when the authentication header is used,
the IP addresses cannot be translated, as this will invalidate the hash value. The
transport and application layers are always secured by hash, so they cannot be
modified in any way (for example by translating the port numbers). Transport
mode is used for host-to-host communications.
In tunnel mode, the entire IP packet (data plus the message headers) is
encrypted and/or authenticated. It must then be encapsulated into a new IP packet
for routing to work. Tunnel mode is used for network-to-network communications
(secure tunnels between routers, e.g. for VPNs) or host-to-network and host-to-
host communications over the Internet. [11]
2.8.4 Pretty Good Privacy (PGP)
PGP (short for Pretty Good Privacy), created by Philip Zimmermann, is the
de facto standard program for secure e-mail and file encryption on the Internet. Its
public-key cryptography system enables people who have never met to secure
transmitted messages against unauthorized reading and to add digital signatures to
messages to guarantee their authenticity.
PGP uses a digital signature (a combination of hashing and public key

encryption) to provide integrity, authentication and non-repudiation. It uses a
combination of secret key and public key to provide privacy. In other words it uses
one hash function, on secret key and tow private-public key pairs. Fig 2.4 shows
how PGP creates a secure email. The email message is hashed to create a digest.
The digest is encrypted (signed) using A’s private key. The message and the digest
are encrypted using the one time secret key created by A. The secret key is
encrypted using B’s public key and sent together with the encrypted combination
of message and digest. The second fig 2.4(B) shows how PGP uses hashing and
combination of a three keys to extract the original message at the receiver site
Sender Site A
Fig 2.4(A) PGP at the sender site
Receiver Site B
Fig 2.4(B) PGP at the receiver site
The combination of encrypted secret key and message plus digest is

received. The encrypted secret key is first decrypted (using B’s private key) to get
the one time secret key created by the sender. The secret key is then used to
decrypt the combination of the message plus digest. After receiving the original
message and the encrypted digest, the receiver separates the two. He/she applies
the same hash function to the message to create a second digest. The receiver also
decrypts the received digest using the public key of the sender. If the two digests
are the same all three aspects of security (integrity, authentication and non-
repudiation) are preserved. [12]
2.8.5 Secure/Multipurpose Internet Mai Extension(S/MIME)
The two most common solutions for encrypted e-mail are PGP (Pretty Good
Privacy mentioned in the above article and S/MIME (Secure/Multipurpose Internet
Mail Extension). MIME was created as a standard for transferring or transporting
60
different types of files attached to e-mails, such as GIFs, JPEGs, DOC files, and so
on. The S in S/MIME indicates a standard for incorporating secure encryption
standards into the protocol. In a perfect world this would work perfectly; however,
as is usually the case, the various vendors have taken to interpreting the standards
to meet their own needs. S/MIME works, but different e-mail clients use it
differently, and the results are not always fabulous. On the plus side, S/MIME is
cheap and is included in most e-mail systems and e-mail clients such as Outlook.
When problems with e-mail security raised their ugly heads, the vendors of
e-mail programs realized that they would have to figure out a way for everyone to
be able to send secure e-mail. That is, e-mail in some sort of coded or encrypted
form. It only made sense that this new feature be standardized, so they created
S/MIME — Secure Multipurpose Internet Mail Extensions. Standards being as they
are, we don’t have to remind you that the assorted vendors have interpreted the
standards to suit their needs. That means that S/MIME (or MIME, for that matter)
doesn’t always work perfectly between different e-mail programs. But, it works
well enough to at least give it a try. [1]
2.8.6 Secure electronic transaction(set)
Secure Electronic Transactions (SET) is an open protocol which has the

potential to emerge as a dominant force in the securing of electronic transactions.
Jointly developed by Visa and MasterCard, in conjunction with leading computer
vendors such as IBM, SET is an open standard for protecting the privacy, and
ensuring the authenticity, of electronic transactions. This is critical to the success
of electronic commerce over the Internet; without privacy, consumer protection
cannot be guaranteed, and without authentication, neither the merchant nor the
consumer can be sure that valid transactions are being made.
61

Secure Electronic Transactions (SET) relies on the science of cryptography
– the art of encoding and decoding messages. Cryptography dates back many
centuries – even in the time of Julius Caesar, encryption was used to preserve the
secrecy of messages. Preserving the secrecy of transactions is no different, though
stronger encryption algorithms are used, as well as significantly stronger
encryption keys. Encryption advancements have come about through its
application by the military, and by advances in computing power and mathematics.
The SET protocol relies on two different encryption mechanisms, as well as

an authentication mechanism. SET uses symmetric encryption, in the form of the
aging Data Encryption Standard (DES), as well as asymmetric, or public-key,
encryption to transmit session keys for DES transactions. Rather than offer the
security and protection afforded by public-key cryptography, SET simply uses
session keys (56 bits) which are transmitted asymmetrically – the remainder of the
transaction uses symmetric encryption in the form of DES. This has disturbing
connotations for a "secure" electronic transaction protocol – because public key
cryptography is only used only to encrypt DES keys and for authentication, and
not for the main body of the transaction. The computational cost of asymmetric
encryption is cited as reason for using weak 56 bit DES, however other reasons
such as export/import restrictions, and the perceived need by law enforcement and
government agencies to access the plain-text of encrypted
Secure electronic transactions will be an important part of electronic

commerce in the future. Without such security, the interests of the merchant, the
consumer, and the credit or economic institution cannot be served. Privacy of
transactions, and authentication of all parties, is important for achieving the level
of trust that will allow such transactions to flourish. However, it is important that
the encryption algorithms and key-sizes used, will be robust enough to prevent
observation by hostile entities (either criminal or foreign powers). The ideal of the
secure electronic transactions protocol (SET) is important for the success of
electronic commerce. However, it remains to be seen whether the protocol will be
widely used because of the weakness of the encryption that it uses. [11]
Chapter three
3.1 What is SSL and how does it work?

Before we first introduce the SSL, let us make an analogy between
communications between computers on the Internet and communications between
people over the telephone. Without SSL, your computer-to-computer
communications suffer from the same security problems from which your
telephone communications suffer:
Who are you talking to? In a phone conversation, how can you be sure that the
person who picks up the phone at the other end is really the person you are trying
to call (especially if you have never spoken to them before)? What if your phone
call was intercepted or re-routed, or what if someone else is answering your call
recipient's phone? There really is no way to be sure you have reached the right
person, especially if they are trying to fool you.
Eavesdropping? As you are aware of from watching TV or reading, it is very easy
to tap phone lines: the police and spies do this all the time to covertly gather
information. It is not easy to detect if your lines are tapped. The same applies with
communications over the Internet -- how can you be sure that your
communications are not being "tapped" and recorded? These results in two very
real security issues for communications over the Internet:-
 Knowing for sure that you are connecting to the right computers (i.e. those
at your bank and not those at a hacker's or phisher's web site), and
 . Knowing that your data is safe from prying eyes during transit to those
computers. This is where SSL comes in.
To solve these problems to a large degree, most Internet services support use of
SSL as a mechanism for securing communications.
SSL (Secure Sockets Layer) is the standard security technology for establishing an
encrypted link between a web server and a browser. This link ensures that all data
passed between the web server and browsers remain private and integral. SSL is an
65

industry standard and is used by millions of websites in the protection of their

online transactions with their customers. To be able to create an SSL connection a
web server requires an SSL Certificate. When you choose to activate SSL on your
web server you will be prompted to complete a number of questions about the
identity of your website and your company. Your web server then creates two
cryptographic keys - a Private Key and a Public Key. [11]
The SSL protocol, which was developed by Netscape in 1994, allows clients
(Web browsers, typically) and HTTP servers to communicate over a secure
connection. It offers encryption, source authentication, and data integrity as means
to protect information exchanged over insecure, public networks. There are several
versions of SSL: SSL 2.0 has security weaknesses and is hardly used today; SSL
3.1 is universally supported; and finally the Transport Layer Security (TLS), which
is an improvement on SSL 3.0, has been adopted as an Internet standard and is
supported by almost all recent software.
Encryption protects data from unauthorized use by converting it to an apparently

meaningless form before transmission. The data is encrypted by one side (the
client or the server), transmitted, decrypted by the other side, then processed.
Source authentication is a method of verifying the data sender's identity. The first
time a browser or other client attempts to communicate with a Web server over a
secure connection, the server presents the client with a set of credentials in the
form of a certificate.
Certificates are issued and validated by trusted authorities known as

certification authorities (CAs). A certificate represents the public-key identity of a
person. It is a signed document that says: I certify that the public key in this
document belongs to the entity named in this document. Signed (certificate
66

authority). Well-known CAs include Verisign, Entrust, and Thawte. Note that
the certificates used with SSL/TLS today are X.509 certificates. [15]
In this way SSL is able to provide:
• Privacy
The connection is made private by encrypting the data to be exchanged

between the client and the server. In other words, only they can decrypt it and
make sense of the data. This allows for secure transfer of private information such
as credit card numbers, passwords, secret contracts, etc.
• Data integrity
The SSL connection is reliable. The message transport includes a message

integrity check based on a secure hash function. So there is practically no
possibility of data corruption without detection.
• Authenticity
The client can authenticate the server and an authenticated server can
authenticate the client (optionally). This means that the information is guaranteed
to be exchanged only between the intended parties. The authentication mechanism
is based on the exchange of digital certificates.
• Non-repudiation
Digital signatures and certificates together imply non-repudiation. This

establishes accountability of information about a particular event or action to its
originating entity, and the communications between the parties can be proved later.
SSL is comprised of two protocols: the record protocol and the handshake
protocol. The record protocol defines the way that messages, passed between the
client and server, are encapsulated. At any point in time it has a set of cipher suite,
which defines the parameters associated with it, known as a cryptographic methods
being used.
3.2 Negotiable Encryption

Among the features of SSL that have made it the de facto standard vehicle
for secure e-commerce transactions is its support for negotiable encryption and
authentication algorithms. The designers of SSL realized that not all parties will
use the same client software and consequently not all clients will include any
particular encryption algorithm. The same is true for servers. The client and server
at the two ends of a connection negotiate the encryption and decryption algorithms
(cipher suites) during their initial handshake. It may turn out that they do not have
sufficient algorithms in common, in which case the connection attempt will fail.
Note that while SSL allows both the client and the server to authenticate
each other, typically only the server is authenticated in the SSL layer. Clients are
customarily authenticated in the application layer, through the use of passwords
sent over an SSL-protected channel. This pattern is common in banking, stock
trading, and other secure Web applications.
The SSL full handshake protocol is illustrated in Figure 3.1. It shows the sequences
of messages exchanged during the SSL handshake.
Figure 3.1: SSL handshake protocol
These messages mean:
1. ClientHello: The client sends the server information such as SSL protocol
version, session id, and cipher suites information such cryptographic
algorithms and key sizes supported.
2. ServerHello: The server chooses the best cipher suite that both the client and
server support and sends this information to the client.
3. Certificate: The server sends the client its certificate which contains the
server's public key. While this message is optional, it is used when server
authentication is required. In other words, it is used to confirm the server's
identity to the client.
4. Certificate Request: This message is sent only if the server requires the
client to authenticate itself. Most e-commerce applications do not require the
client to authenticate itself.
5. Server Key Exchange: This message is sent if the certificate, which contains
the server's public key, is not sufficient for key exchange.
6. ServerHelloDone: This message informs the client that the server finished
the initial negotiation process.
7. Certificate: This message is sent only if the server requested the client to
authenticate itself.
8. Client Key Exchange: The client generates a secret key to be shared between
the client and server. If the Rivest-Shamir-Adelman (RSA) encryption
algorithm is used, the client encrypts the key using the server's public key
and sends it to the server. The server uses its private or secret key to decrypt
the message and retrieves the shared secret key. Now, client and server share
a secret key that has been distributed securely.
9. Certificate Verify: If the server requested to authenticate the client, this
message allows the server to complete the authentication process.
10.Change Cipher Spec: The client asks the server to change to encrypted
mode.
11.Finished: The client tells the server it is ready for secure communication.
12.Change Cipher Spec: The server asks the client to change to encrypted
mode.
13.Finished: The server tells the client it is ready for secure communication.
This marks the end of the SSL handshake.
14.Encrypted Data: The client and server can now start exchanging encrypted
messages over a secure communication channel
70
3.3 Java Secure Socket Extension 'JSSE'

Any information transmitted over computer networks, or the Internet, is
subject to interception. Some of that information could be sensitive, such as credit
card numbers and other personal data. To make the Internet more useful in an
enterprise setting and for e-commerce, applications must protect their users'
information, using encryption, authentication, and secure communications
protocols. The secure Hypertext Transfer Protocol (HTTPS), which is HTTP over
the Secure Sockets Layer (SSL), is already being used successfully for e-
commerce applications.
The Java Secure Socket Extension (JSSE), which is a set of Java packages
that enable secure Internet communications, is a framework and 100% Pure Java
implementation of the Secure Socket Layer (SSL). These packages enable you, the
Java developer, to develop secure network applications that feature the secure
passage of data between a client and a server running any application protocol,
such as HTTP, FTP, Telnet, or NTTP, over TCP/IP.
The good news is that JSSE has been integrated into the Java 2 SDK,
Standard Edition, version 1.4 (J2SE 1.4). This means if you have J2SE 1.4
installed, then you can build secure Internet applications based on SSL without
downloading any additional packages. By abstracting the complex underlying
security algorithms and "handshaking" mechanisms, JSSE minimizes the risk of
creating subtle, but dangerous security vulnerabilities. Furthermore, it simplifies
application development by serving as a building block which developers can
integrate directly into their applications. JSSE provides both an application
programming interface (API) framework and an implementation of that API. The
JSSE API supplements the "core" cryptographic services defined in the Java 2
71
SDK, v 1.4 java.security and java.net packages by providing extended
networking socket classes, trust managers, key managers, SSLContexts, and a
socket factory framework for encapsulating socket creation behavior. The JSSE
API is capable of supporting SSL versions 2.0 and 3.0 and Transport Layer
Security (TLS) 1.0. These security protocols encapsulate a normal bidirectional
stream socket and the JSSE API adds transparent support for authentication,
encryption, and integrity protection. The JSSE implementation in the J2SDK, v 1.4
implements SSL 3.0 and TLS 1.0. It does not implement SSL 2.0. The JSSE API
contains the following three packages:-
3.3.1 The javax.net Package
This package is not specific to SSL and has two classes in it, namely
SocketFactory and ServerSocketFactory, which represent the basic socket and
server socket factories respectively:
• SocketFactory class
This class creates sockets. It may be subclassed by other factories, which create
particular subclasses of sockets and thus provide a general framework for the
addition of public socket-level functionality.
• ServerSocketFactory class
This class creates server sockets. It may be subclassed by other factories, which
create particular types of server sockets. This provides a general framework for the
addition of public socket-level functionality. It is the server-side analog of a socket
factory, and similarly provides a way to capture a variety of policies related to the
sockets being constructed. Like socket factories, ServerSocketFactory instances
72
have methods used to create sockets. There is also an environment specific default
server socket factory; frameworks will often use their own customized factory.
3.3.2 The javax.net.ssl Package
The javax.net.ssl package is an SSL API, but it does not provide full access to
specialized features, sometimes needed by applications, such as the control on
what private keys get used.There are five basic features in this API:
1. SSL sockets and SSL server sockets

2. SSL socket factories
3. SSL-specific session capabilities
4. A handshake completion event facility
5. SSL-specific exceptions
This package has six classes, four interfaces and five exceptions:
• SSLSocket class
SSLSocket is an abstract class extended by sockets that support SSL or IETF

Transport Layer Security (TLS) protocols. Such sockets are normal stream sockets
(java.net.Socket), but they add a layer of security over the underlying network
transport protocol, such as TCP. Those security features include integrity
protection, confidentiality, and authentication.
• SSLServerSocket class
The server-side implementation of the SSLSocket class is SSLServerSocket. This

class is extended by server sockets that return connections protected using the SSL
protocol, and that extend the SSLSocket class.
73

• SSLSocketFactory class
Instances of this kind of socket factory return SSL sockets. An SSL

implementation may be established as the default factory.
• SSLServerSocketFactory class
The server-side equivalent of the SSLSocketFactory class is

SSLServerSocketFactory. This class creates SSL server sockets.
• SSLSession interface
This interface can be used to describe the current relationship between the server
and the client.
• SSLSessionContext interface
An SSLSessionContext is a grouping of SSL sessions associated with a single

entity. For example, they could be associated with a server or client who
participates in many sessions concurrently. This interface provides methods for
retrieving an SSLSession based on its ID, and allows such IDs to be listed.
• SSLSessionBindingListener interface
This interface is implemented by objects that want to know when they are being
bound to or unbound from an SSLSession. When either event occurs, it is
communicated through an SSLSessionBindingEvent identifying the session into
which the object is being bound, or from which the object is being unbound.
• SSLSessionBindingEvent class
This event is communicated to an SSLSessionBindingListener whenever such a

listener is bound to or unbound from an SSLSession value. The events source is
the SSLSession to which the listener is being bound, or from which the listener is
being unbound.
• HandshakeCompletedListener interface
This interface is implemented by any class that wants to receive notifications about
the completion of an SSL protocol handshake on a given SSL connection. When
an SSL handshake completes, new security parameters will have been defined.
Those parameters always include the security keys used to protect messages. They
may also include parameters associated with a new session such as authenticated
peer identity and a new SSL cipher suite.
• HandshakeCompletedEvent class
This event indicates that an SSL handshake has completed on a given SSL
connection. All of the core information about that handshake’s result is captured
through an SSLSession object. As a convenience, this event class provides direct
access to some important session attributes. The source of this event is the
SSLSocket on which handshaking just completed.
• SSLException class
Indicates some kind of error detected by an SSL subsystem.

• SSLHandshakeException class
Indicates that the client and server could not negotiate the desired level of security.
The connection is no longer usable.
• SSLKeyException class
Reports a bad SSL key. Normally, this indicates misconfiguration of the server or
client SSL certificate and private key.
• SSLPeerUnverifiedException class
Indicates that the peers identity has not been verified. You may request the identity
of the peer. When the peer is not able to identify itself (for example, no certificate,
or the particular cipher suite being used does not support authentication, or no peer
authentication was established during SSL handshaking) this exception may be
thrown.
• SSLProtocolException class
Reports an error in the operation of the SSL protocol. Normally this indicates a
flaw in one of the protocol implementations.
3.3.3 The javax.security.cert Package
This package contains two classes and five exceptions, but it can be safely
replaced by the more powerful java.security.cert package shipped with the Java 2
SDK.
• Certificate class
This is an abstract class for managing a variety of identity certificates that have
different formats but important common uses. For example, different types of
certificates, such as X.509, Pretty Good Privacy (PGP) and Simple Distributed
Security Infrastructure (SDSI), share general certificate functionality (like
encoding and verifying) and some types of information (like a public key).X.509,
PGP, and SDSI certificates can all be implemented by subclassing the Certificate
class, even though they contain different sets of information, and they store and
retrieve the information in different ways.
• X509Certificate class
This is an abstract class for X.509 V1 certificates. This provides a standard way to
access all the Version 1 attributes of an X.509 certificate. Attributes that are
specific to X.509 V2 or V3 are not available through this class, but you can make
use of the classes provided by the java.security.cert package of the Java 2 SDK.
• CertificateEncodingException class
A certificate encoding exception is thrown whenever an error occurs while

attempting to encode a certificate.
• CertificateException class
This exception indicates one of a variety of certificate problems.
• CertificateExpiredException class
This kind of exception is thrown whenever the current date or the specified date is
after the notAfter date and time specified in the validity period of the certificate.
• CertificateNotYetValidException class
This kind of exception is thrown whenever the current date or the specified date is
before the notBefore date and time in the certificate validity period.
• CertificateParsingException class
This exception is thrown whenever an invalid DER encoded certificate is parsed or

unsupported DER features are found in the certificate.
3.3.4 Installing and Customizing JSSE
As we have already stated in the previous sections the java secure socket
extension JSSE cryptographic toolkit does not come free with the earlier Java 2
SDKs, but are shipped as part of other products, such as Java Server Toolkit (JST)
and the HotJava browser; however, the sun Microsystems started to integrate the
JSSE with the later versions starting with v 1.4.x and greater. Therefore, to
install the JSSE in thoses earlier versions just download the jssse version you want
and save it any where in your local disk. Note that JSSE version you downloaded
requires that you have Java(tm) 2 SDK v1.2.x or 1.3.x already installed on your
computer. After that Uncompress and extract the downloaded file and as a result a
directory named jsse v will be created, with two subdirectories named doc and lib
then perform the following two steps:-
Step 1. Install the JSSE jar files
The JSSE lib subdirectory contains the extension files jsse.jar, jcert.jar, and
jnet.jar.you can either install these files in the JDK/JRE ("installed extension") or
bundle them with your applet or application ("bundled extension"). If you wish to
install them as an installed extension, place them in the following directory: <java-
78
home>/lib/ext, where <java-home> refers to the directory in which the Java 2

Runtime Environment (JRE) was installed. If you do not know your < java-home>,
here is a simple application that allows you to find it:
public class FindJavaHome {

public static void main(String argv[])
{ System.out.println(System.getProperty("java.home")
);
}
}
Step 2. Register the SunJSSE provider.

JSSE comes standard with a Cryptographic Service Provider, or "provider" for
short, named "SunJSSE". Although the "SunJSSE" provider is supplied with every
JSSE installation, it still needs to be configured explicitly, either statically or
dynamically, before its services can be accessed. if you are statically registering
the SunJSSE provider, add the "SunJSSE" provider to your list of approved
providers. This is done statically by editing the security properties file:
<java-home>\lib\security\java.security .
One of the types of properties contained in the java.security file is of the following
form:
security.provider.n=providerClassName
This declares a provider, and specifies its preference order "n". The preference
order is the order in which providers are searched for requested algorithms (when
no specific provider is requested). The order is 1-based; 1 is the most preferred,
followed by 2, and so on. Add the above line to java.security, replacing
providerClassName with com.sun.net.ssl.internal.ssl.Provider, and substituting n
with the priority that you would like to assign to the "SunJSSE" provider. For
79

example, to add the Sun internal SSL provider to the standard provider shipped
with the JRE, your entries would look like:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider.
"SunJSSE" would now be the second preferred provider. Instead of registering the
provider statically, you can add the provider dynamically at runtime by adding the
following line of code at the beginning of your program:
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider());
3.4 Programming with JSSE

The JSSE APIs supplement the java.security and java.net packages by
providing extended networking socket classes, trust and key managers, and a
socket factory framework for encapsulating socket creation behavior. These classes
are included in the packages javax.net and javax.net.ssl
 SSLSocket and SSLServerSocket
The javax.net.ssl.SSLSocket is a subclass of the java.net.Socket class.

Therefore, it supports all the standard Socket methods and adds additional
methods specific to secure sockets. The javax.net.ssl.SSLServerSocket class is
analogous to the SSLSocket class except that it is used to create server sockets.
Creating an instance of SSLSocket can be done in two ways:
1. As an instance of SSLSocketFactory by invoking one of the

createSocket methods on that class.
2. Through the accept method on the SSLServerSocket.
80
 SSLSocketFactory and SSLServerSocketFactory
The javax.net.ssl.SSLSocketFactory class is an object factory for creating

secure sockets, and the javax.net.ssl.SSLServerSocketFactory is an object
factory for creating server sockets.
An SSLSocketFactory instance can be obtained in two ways:
1. Get the default factory by calling SSLSocketFactory.getDefault.

2. Construct a new factory with specified configured behavior.
Note that the default factory is configured to enable server authentication only.
3.4.1 Making Existing Client/Server Applications Secure

Incorporating SSL into existing client/server applications to make them
secure can be easily done using a few lines of JSSE code. The lines highlighted in
bold in the following example show the code necessary to make a server secure:
import java.io.*;
import javax.net.ssl.*;
public class Server {

int port = portNumber;
SSLServerSocket server;
try {
SSLServerSocketFactory factory =
(SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
server = (SSLServerSocket)
factory.createServerSocket(portNumber);
81

SSLSocket client = (SSLSocket)
server.accept();
// Create input and output streams as usual

// send secure messages to client through the
// output stream
// receive secure messages from client through
// the input stream
} catch(Exception e) {
}}
The lines highlighted in bold in the following example show the code necessary to
make a client secure:
import java.io.*;
public class Client {

...
try {
SSLSocketFactory factory = (SSLSocketFactory)
SSLSocketFactory.getDefault();
server = (SSLServerSocket)
factory.createServerSocket(portNumber);
SSLSocket client = (SSLSOcket)
factory.createSocket(serverHost, port);
// Create input and output streams as usual

// send secure messages to server through the
// output stream receive secure
// messages from server through the input stream
} catch(Exception e) {
}}
3.4.2 A Complete Example

We found that the most complex issue when working with JSSE is related to
system configuration and managing certificates and keys. Throughout this
example, we demonstrate how to develop, configure, and run a complete HTTP
server application that supports the GET request method.
 Overview of HTTP
The Hypertext Transfer Protocol (HTTP) is a request-reply application
protocol. This protocol supports a fixed set of methods such as GET, POST, PUT,
DELETE, etc. The GET method is commonly used to request resources from a Web
server. Here are two sample GET requests:
GET / HTTP/1.0 <empty-line>

GET /names.html HTTP/1.0 <empty-line>
 Insecure HTTP Server

In order to develop an HTTP server, you need to understand how the HTTP
protocol works. This server, however, is simple since it only supports the GET
request method. A sample implementation is shown in Code Sample 1. This is a
multi-threaded HTTP server where the ProcessConnection class is used to run
each new request in a different thread. When the server receives a request from the
browser, it parses the request to find out which document is being requested. If the
requested document is available on the server, the shipDocument method is used to
send the requested document to the server. If the document is not found, an error
message is sent to the server.
Code Sample 1: HttpServer.java
import java.io.*;
import java.net.*;
import java.util.StringTokenizer;
/**
* This class implements a multithreaded simple HTTP
* server that supports the GET request method.
* It listens on port 8080, waits client requests, and
* serves documents.
*/
public class HttpServer {

// The port number which the server
// will be listening on
public static final int HTTP_PORT = 8080;
public ServerSocket getServer() throws Exception {

return new ServerSocket(HTTP_PORT);
}
// multi-threading -- create a new connection

// for each request
public void run() {
ServerSocket listen;
try {
listen = getServer();
while(true) {
Socket client = listen.accept();
ProcessConnection cc = new
ProcessConnection(client);
}
} catch(Exception e)
{ System.out.println("Exceptio
n:
"+e.getMessage());
}
}
// main program
public static void main(String argv[]) throws
Exception {
HttpServer httpserver = new HttpServer();
httpserver.run();
}
}
class ProcessConnection extends Thread {

Socket client;
BufferedReader is;
DataOutputStream os;
public ProcessConnection(Socket s) { // constructor

client = s;
try {
is = new BufferedReader(new InputStreamReader
(client.getInputStream()));
os = new DataOutputStream(client.getOutputStream());
} catch (IOException e)
{ System.out.println("Exception:
"+e.getMessage());
}
this.start(); // Thread starts here...this start()
will call run()
}
public void run() {

try {
// get a request and parse it.
String request = is.readLine();
System.out.println( "Request: "+request );
StringTokenizer st = new StringTokenizer( request );
if ( (st.countTokens() >= 2) &&
st.nextToken().equals("GET") ) {
if ( (request =
st.nextToken()).startsWith("/") )
request = request.substring( 1 );
if ( request.equals("") )
request = request + "index.html";
File f = new File(request);
shipDocument(os, f);
} else {
os.writeBytes( "400 Bad Request" );
}
client.close();
} catch (Exception e)
{ System.out.println("Exception: "
+
e.getMessage());
}
}
/**
* Read the requested file and ships it
* to the browser if found.
*/
public static void shipDocument(DataOutputStream out,

86

File f) throws Exception {

try {
DataInputStream in = new
DataInputStream(new FileInputStream(f));
int len = (int) f.length();
byte[] buf = new byte[len];
in.readFully(buf);
in.close();
out.writeBytes("HTTP/1.0 200 OK\r\n");
out.writeBytes("Content-Length: " +
f.length() +"\r\n");
out.writeBytes("Content-Type:
text/html\r\n\r\n");
out.write(buf);
out.flush();
} catch (Exception e)
{ out.writeBytes("<html><head><title>error</titl
e>
</head><body>\r\n\r\n");
out.writeBytes("HTTP/1.0 400 " + e.getMessage() +
"\r\n");
out.writeBytes("Content-Type: text/html\r\n\r\n");
out.writeBytes("</body></html>");
out.flush();
} finally
{ out.close(
);
}
}
}
87

To experiment with the HttpServer class:
88

1. Copy HttpServre and save it in a file called HttpServer.java in a
directory of your choice, mostly in the bin directory of Java 2 SDK version
on your machine.
2. Compile the HttpServer.java using javac.
3. Create some sample HTML file, like the one below, including
"index.html", which is the default document served in this example
<html>
<head><title>Secure Connection</title></head>
<style>
.tx01{background-color:#000088;font-family:arial;font-
size:22pt;
font-weight:bold;color:#ffff00;text-align:left}
.tx03{font-size:18pt;color:#00ff00}
.butSt{background-color:#aaffaa;font-family:arial;font-
weight:bold;
font-size:14pt;color:#880000;width:250px;height:35px}
</style>
<body class="tx01" style="text-align:center">
Welcome the httpServer<br /><br />
<div class="tx03">
the server is now running on port 8080
</div><br />
</body>
</html>
4. Run the HttpServer. The server runs on port 8080.
5. Open a web browser and make a request such as http://localhost:8080 or

http://127.0.0.1:8080/index.html to load the default page"index.html"
Fig 3.2 the index.html page

3.4.3 Extending HttpServer to Handle https:// URLs

Now, let's modify the HttpServer class, making it secure. We'd like the
HTTP server to be capable of handling https:// URLs. As we mentioned earlier,
JSSE allows you to integrate SSL into your applications quite easily.
3.4.3.1 Creating a Server Certificate

As we mentioned earlier, SSL uses certificates for authentication.
Certificates must be created for clients and servers that need to communicate
securely using SSL. JSSE uses certificates created using the Java keytool shipped
with J2SE. We used the following command to create an RSA certificate for the
HTTP server.
prompt> keytool -genkey -keystore serverkeys -keyalg rsa -alias muhedin
This command will generate a certificate referenced by the alias Muhedin, and will
be stored in a file named serverkeys. The tool prompted us for information to
generate the certificate. The information we entered is shown in the below
command window.
Fig 3.3 Certificate Creation

90

As you can see, the keytool prompted us to enter a password for the
keystore meaning that in order for the server to access the keystore it must know
that password. Also, the tool asked us to enter a password for the alias. If you like,
such password information can be related on the keytool command line using the
options -storepass and -keypass. Note that we used the IP address
"192.168.100.1" for the first and last name. This IP address is that of the machine
we used. You should enter the hostname or the IP address of the server's machine.
When you run the keytool command, it may take a few seconds to generate the
certificate depending on the speed of your machine.
Once a certificate for our server has been generated, we can revise our
HttpServer to make it secure. If you examine the HttpServer class, you'll notice
that the getServer method is used to return a server socket. This means, the only
method we need to modify is the getServer method so that it returns a secure
server socket. The changes are highlighted in bold in Code Sample 2. Notice that
we have changed the port number to 443. This is the default port number for
HTTPs. It is important to note that port numbers between 0 and 1023 are reserved.
If you run HttpsServer on a different port number, the url should be:
https://localhost:portnumber but if you run it on 443 then the URL is:
https://localhost.
Code Sample 2: HttpsServer.java
import java.io.*;
import java.net.*;
import javax.net.*;
import java.security.*;
91

import java.util.StringTokenizer;
/**
* This class implements a multithreaded simple HTTPS
* server that supports the GET request method.
* It listens on port 443, waits client requests
* and serves documents.
*/
public class HttpsServer {
String keystore = "serverkeys";

char keystorepass[] = "africa".toCharArray();
char keypassword[] = "computer".toCharArray();
// The port number which the server will be listening on

public static final int HTTPS_PORT = 443;
public ServerSocket getServer() throws Exception {
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), keystorepass);
KeyManagerFactory kmf =
KeyManagerFactory.getInstance("SunX509");
kmf.init(ks, keypassword);
SSLContext sslcontext =
SSLContext.getInstance("SSLv3");
sslcontext.init(kmf.getKeyManagers(), null, null);
ServerSocketFactory ssf =
92
sslcontext.getServerSocketFactory();
SSLServerSocket serversocket = (SSLServerSocket)
ssf.createServerSocket(HTTPS_PORT);
return serversocket;
// multi-threading -- create a new connection

// for each request
public void run() {
ServerSocket listen;
try {
listen = getServer();
while(true) {
Socket client = listen.accept();
ProcessConnection cc = new
ProcessConnection(client);
}
} catch(Exception e)
{ System.out.println("Exception:
"+e.getMessage());
}
}
// main program
public static void main(String argv[]) throws Exception {
HttpsServer https = new HttpsServer();
https.run();
}
}
93

The lines:
String keystore = "serverkeys";

char keystorepass[] = "africa".toCharArray();
char keypassword[] = "computer".toCharArray();
specify the name of the keystore, its password, and the key password. Hardcoding
the passwords into the code is not a good idea for production code, however. They
can be specified on the command line when running the server. The rest of the
JSSE related code is in the getServer method: It accesses the serverkeys
keystore. The JKS is the Java KeyStore (a type of keystore created by keytool).
The KeyManagerFactory is used to create an X.509 key manager for the
keystore. An SSLContext is an environment for implementing JSSE. It is used
to create a ServerSocketFactory that in turn used to create a
SSLServerSocket. Although we specify SSL 3.0, the implementation that is
returned will often support other protocol versions, such as TLS 1.0. Older
browsers, however, use SSL 3.0 more widely.
Note that by default client authentication is not required. If you wish for your
server to require client authentication, use:
serversocket.setNeedClientAuth(true).
To experiment with the HttpsServer class:
1.Copy the HttpsServer and ProcessConnection classes into a

file named HttpsServer.java
2.Save this file in the same directory where the serverkeys file
was created by the keytool
3.Compile the HttpsServer.java using javac as seen before in
the HttpServer.
4.Run the HttpsServer. By default it runs on port 443, but if you cannot
start it on this port, choose another port number greater than 1024.
5.Open a web browser and enter the request: https://localhost or
https://127.0.0.1. This assumes the server is running on port 443. If not, then
use: https://localhost:port
When you enter an https:// URL in the browser, you get a security alert popup
window like the one in Figure 3.3 This is because the HTTP server certificate was
self-generated. In other words, it was generated by an unknown certification
authority, one that was not found among the certification authorities your browser
keeps in its store. You have the option to view the certificate (check whether it is a
proper certificate and discover who signed it) and then install it, reject the
certificate, or accept the certificate.
Figure 3.4: Server certificate issued by an unknown certification authority
If you just view the certificate by clicking the Examine Certificate

button,you will see the certificate we have already generated. The figure below
shows this.Note we are using the Mozilla Firefox as our default browser.
Fig 3.5 A view of the generated certificate

Note: Generating your own certificate is fine for internal private systems. For
public systems, however, it is a good idea to get a certificate from a well known
Certification Authority in order to avoid the browser security alert.
If you accept the certificate you will be able to see the page behind the
secure connection, and future access to the same Web site will not cause the
browser to issue a security alert. Note that there are many Web sites that use
HTTPS whose certificates were either self-generated or generated by unknown
97
CAs. As an example, try to visit: https://www.jam.ca. If you have never visited this
Web site, you will see a security alert like the one in Figure 3.
Note: When you accept the certificate, it is only for that session. In other
words, once you completely exit the browser it is forgotten. Both Netscape and
Microsoft Internet Explorer (MSIE) allow you to install a certificate permanently.
To do this in MSIE, select "View Certificate" from Figure 3 and from the new
window select "Install Certificate".
3.4 Programming Client Applications with JSSE

As stated earlier in the previous section, The JSSE APIs supplement the
java.security and java.net packages by providing extended networking socket
classes, trust and key managers, and a socket factory framework for encapsulating
socket creation behavior. These classes are included in the packages javax.net and
javax.net.ssl.
The javax.net.ssl.SSLSocketFactory class is an object factory for creating secure

sockets. An instance of SSLSocketFactory can be obtained in two ways:
1. Get the default factory by calling SSLSocketFactory.getDefault. The

default factory is configured to enable server authentication only (no client
authentication). Note that most e-commerce web sites do not require client
authentication.
2. Construct a new factory with specified configured behavior (this is beyond
the scope of this project).
Once an instance of SSLSocketFactory has been created, you can create an

instance of SSLSocket by invoking a createSocket method on the
SSLSocketFactory instance. Here is an example that creates a socket
98
connection to Sun's WWW server through the SSL port 443, which is the default
port number for HTTPS.
// Get a Socket factory

SocketFactory factory = SSLSocketFactory.getDefault();
// Get Socket from factory

Socket socket = factory.createSocket("www.sun.com", 443);
3.5.1 Working with Low-level SSL Sockets

Now, let's see a complete example of opening an SSL socket connection to
an HTTPS server using low-level sockets. In this example, an SSL socket
connection will be opened to an HTTPS server, and then we read the content of the
default document. Code Sample 1 shows this application. The instructions that
open the SSL socket are highlighted in bold. As you can see, the rest of the
application is regular Java code for input/output streams.
Code Sample 1: ReadHttpsURL1
import java.net.*;
import javax.net.*;
public class ReadHttpsURL1 {

static final int HTTPS_PORT = 443;
public static void main(String argv[]) throws Exception {

if (argv.length != 1) {
99

System.out.println("Usage: java ReadHttpsURL1 ");

System.exit(0);
}
// Get a Socket factory

SocketFactory factory = SSLSocketFactory.getDefault();
// Get Socket from factory

Socket socket = factory.createSocket(argv[0], HTTPS_PORT);
BufferedWriter out = new BufferedWriter(new

OutputStreamWriter(socket.getOutputStream()));
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
out.write("GET / HTTP/1.0\n\n");
out.flush();
String line;
StringBuffer sb = new StringBuffer();
while((line = in.readLine()) != null) {
sb.append(line);
}
out.close();
in.close();
System.out.println(sb.toString());
}
}
To experiment with this application:
100
1. Copy and paste the code of the ReadHttpsURL1 class into a file named
ReadHttpsURL1.java, and save this file in a directory of your choice.
2. Compile the ReadHttpsURL1.java using javac.
3. Run the ReadHttpsURL1 and provide the domain of an HTTPS url.
Here is an example:
Prompt> java ReadHttpsURL1 www.sun.com
After a few seconds, you will note that tons of HTML code is displayed on
your screen. Note that even though we are providing the domain
www.sun.com, we are opening a connection to https://www.sun.com.
This is because the port number we are using, 443, is the default port number
for HTTPS.
Try another example, such as:
Prompt> java ReadHttpsURL1 www.jam.ca
This will throw the following exception. Can you guess why?
Exception in thread "main" javax.net.ssl.SSLHandshakeException:

java.security.cert.CertificateException: Couldn't find
trusted certificate at
com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(Dasho
A 6275)
It didn't work for a good reason. This was caused by the remote server
sending a certificate that is unknown to the client. As we mentioned in the previous
sections, when a client connects to a server, the server sends its certificate to the
client for authentication. Well, in the first example, where you entered
www.sun.com, that server did send its certificate, but Java checks the default 101

certificate store and realized that the certificate was generated by one of the trusted
Certificate Authorities that Java trusts by default. In the second example where you
entered www.jam.ca, the certificate for that site was either self-generated or
generated by a Certification Authority unknown to Java, and therefore it wasn't
trusted.
3.5.2 Exporting and Importing Certificates
To explain how to export and import certificates, we will use our own HTTPS
server which is discussed in the 3.4.3 section (sample code 2). To get started, do
the following:
1. Run the HTTPS server as discussed in section 3.4.3.

2. Run the ReadHttpsURL1: java ReadHttpsURL1 localhost. You
will receive the same exception as the one described above.
3. Export the server's certificate using the following keytool command
that says:
 Export the server's certificate from the file serverkeys, whose
alias is Muhedin.
 Save the exported certificate in a file called server.cert, which
will be created by the keytool. As you can see, we are asked to
enter the password. Upon successful entry of the password, the
server's certificate got exported and saved in the file server.cert.
Prompt> keytool -export -keystore serverkeys -alias muhedin -
file server.cert.
The following command window shows the process;

4. Copy the server.cert file to the directory where ReadHttpsURL1

is located. Use the keytool to create a new keystore and import the
server's server.cert certificate into it. Here is a sample command:
Prompt> keytool -import -keystore trustedcerts -alias muhedin -

file server.cert
This command produces the following output. We were asked to enter a

password. This is a new password for the trustedcerts keystore. This
keystore is created by the keytool. At the end of the output, we got asked if
we wish to trust this certificate our answer was yes.
5. Now run the ReadHttpsURL1 and inform it where to look for

certificates using the following command:
Prompt> java -Djavax.net.ssl.trustStore=trustedcerts

ReadHttpsURL1 localhost
103
This will contact your HTTPS server, verify its certificate and if it is valid, will
download the default page index.html as following window shows.
Note: A trust manager is responsible for determining if the remote authentication

credentials should be trusted. The following rules are used:
1. If a truststore is specified by the javax.net.ssl.trustStore

system property, then the trust manager will use the file provided to
check for credentials. If, however, the system property exists but the file
specified doesn't exist, then no truststore is utilized and a
CertificateException will be thrown.
2. If the javax.net.ssl.trustStore system property is not
defined, then a default trust store is searched for:
o If a trust store named jssecacerts exists in the lib/security
subdirectory of your java.home directory, it will be used.
o If jssecacerts doesn't exist, but cacerts does (which
is shipped with the J2SDK with a limited number of trusted
root certificates), it will be used.
On our Windows client machine we used, the java.home directory is
C:\j2sdk1.4.1\jre. In the above example, if you change the name of trustStore
to jssecacerts and move it to the lib/security subdirectory, then you
no 104

longer need to specify the javax.net.ssl.trustStore property on the
command line as window below shows.
Chapter four
4.1 Results
After a deep study of the public key infrastructure and its security protocols
especially the secure socket layer protocol that is implemented in our project, we
reached the following main results:-
1. The SSL protocol together with some other protocols like SET,PGP and
TLS form the backbone of the e-commerce and secure communications.
2. The java programming language offers a great network programming tools
as well as network security implementations.
3. When using the Http protocol under the SSL (meaning Https), some
problems may appear. Those problems are mainly due to authentication; for
example, a client initiates a communication using a secure channel to
defined server; the initiated server sends a certificate which is not trusted by
the client e.g. self generated certificate.
4. In any PKI system, there must be a trusted third party on condition that both
communicating parties trust it. This third party is called Certification
Authority (CA). The main function of the CA is the production of digital
certificates.
5. The JSSE API is implementable on either JDK 1.1.x or Java TM 2 Platform,
Standard Edition. This implementation is not intended for use in the J2SDK
version 1.4, which has a version of JSSE already bundled.
6. Modern encryption and security technologies are mostly dominated and
restricted by west especially the united state of America. This relates greatly
the political aspect to the scientific development.
4.2 Project’s Problems
During the course of our project research, which took approximately four
months, we come across a number of problems of which its prominent ones are:-
1. The Public key infrastructure is a new technology of internet security which
is not broadly explored and searched before, this resulted scarcity of the
required information. Therefore, we spent much time and hardly collected
the needed information
2. Another problem, which the most important, is the unavailability of the
implementation of the newly discovered security protocols or even a clue of
its implementation idea. To further explain this, we used the java
programming language to implement the practical part of our project which
we introduced the SSL protocol. The java security packages that are
necessary for the implementation of the SSL protocol is called java security
socket extension 'JSSE'. The JSSE does not freely come with earlier versions
of the java development kits. It therefore needs to be downloaded from Sun's
official Website and then integrated to the JDKs.The problem came after we
tried to download the JSSE packages and the reason is that the JSSE
packages obey the American exportation law. This means that any American
product can not be exported to US embargoed country. Knowing that Sudan
is an American embargoed country we could not download the packages. To
solve that problem, we were assisted by some of our friends in the US.
3. One last problem that we met which may also face any developer, using the
internet security or PKI protocols is software integration of the encryption
toolkits.
4.3 Recommendations
The purpose of this research is to discover the general idea about the Public
Key Infrastructure (PKI). How ever, there were problems that we faced during the
preparation of this research, but we eventually recovered and got solutions for
them. In this section we recommend the upcoming researchers in PKI to give
special attention to the following recommendations:
1. An improved background of cryptography is a necessary step towards the
understanding the Public Key Infrastructure (PKI).
2. Researchers, who are performing study on PKI technology, are
recommended to continue developing where we stopped.
3. We highly recommend making a lot of studies to this field so as to utilize
the technology behind PKI.
4. We also recommend manipulating the SSL built in software tools like
OpenSSL instead of using programming language.
5. Any one who is studying the PKI protocols is recommended to concentrate
on the Secure Socket Layer protocol (SSL), because the SSL is considered
to be the basic protocol among the PKI protocols.
4.4 Glossary
American National Standards Institute (ANSI)
Founded in 1918, ANSI is a voluntary organization composed of over 1,300
members that creates standards for the computer industry.
Application Programming Interface (API)
A set of routines or functions that are available to developers and applications to
provide specific services used by a system.
Bytecode
The compiled format for Java source programs. Once a Java program has been
converted to bytecode, it can be transferred across a network and executed by JVM
or JRE. By convention, Java bytecode files end with a .class file extension.
Certificate (or digital certificate)
An attachment to an electronic message used for security purposes. The common
purpose of a digital certificate is to verify the identity of the sender.
Certification Authority (CA)
A trusted third-party organization or company that issues digital certificates. The
CA guarantees that the identity of the party in the certificate is genuine.
Client
A computer or device on a network that calls another computer for resources.
Connection
A link between two or more computers, processes, applications, devices, networks,
and so on. Connections may be logical, physical, or both.
Cryptography
A general term for the encryption and decryption methods used for data
transmission and protection.
E-commerce
Conducting business online. This includes, for example, buying and selling
products on the Internet.
Email
Electronic messages transmitted on a network. It is a general term for electronic
mail or Internet mail.
Event handler
A routine inside an application to be triggered by an event such as a mouse click.
Event listener
A routine inside an application to listen to any event generated by the user.
File Transfer Protocol (FTP)
The protocol used on the Internet for sending and receiving files.
Hyper Text Transfer Protocol (HTTP)
The underlying protocol defining how messages are formatted and transmitted on
the Web, and what actions Web servers and browsers should take in respond to
various commands.
Internet
Sometimes called the TCP/IP network, this is the vast collection of interconnected
networks that all use the TCP/IP suite.
Internet Engineering Task Force (IETF)
The main standards organization for the Internet concerned with Internet
architecture and operations. It is open to anyone who is interested.
Internet Explorer (IE)
The Web browser developed by Microsoft for Windows platforms. IE is the most
popular browser used on the Web.
IP address (or IP number)

A unique number consisting of four parts separated by dots, e.g., 165.113.223.2
Each part can have values from 0 to 255. For the TCP/IP network (or Internet), IP
addresses can be used to uniquely identify a computer on the network.
J2SDK
A Java development environment from Sun Microsystems used to develop Java
applications. It converts Java source file to bytecode to be executed by the JVM
and JRE.
Java
A high-level programming language developed by Sun Microsystems. Java is an
object-oriented language similar to C++, but simplified to eliminate language
features that cause common programming errors. By convention, Java program
files end with a .java file extension.
Java Runtime Environment (JRE)
A run time environment developed by Sun Microsystems to convert Java bytecode
into machine language and execute it locally.
Java Vitural Machine (JVM)
An abstract computing machine, or virtual machine, JVM is a platform-
independent execution environment that converts Java bytecode into machine
language and executes it locally.
LINUX
An implementation of UNIX that runs on PCs and many other platforms. It was
developed mainly by Linus Torvalds. LINUX is freely distributable with open
source code.
Multipurpose Internet Mail Extension (MIME)
A specification for formatting non-ASCII messages so that graphics, audio, and
video can be sent over the Internet.
Netscape browser (NS)
The Web browser developed by Netscape Communications. It runs on all the
major platforms such as Windows, MacOS, and UNIX/LINUX.
Network News Transfer Protocol (NNTP)
The protocol used to post, distribute, and retrieve USENET messages. The official
specification is RFC 977.
Port
A number used to identify TCP/IP applications. Generally a port is an entry or exit
point
Pretty Good Privacy (PGP)
A method developed by Phil Zimmermann to encrypt or disguise computer
information so that it can be securely transmitted over a network.
Private Key
The digital key that is kept secret in a public-key cryptographic structure
Protocol
Rules governing the behavior or method of operation.
Public key
The digital key mode available to the public in a public-key cryptographic
structure.
Public-key cryptography
113
A cryptographic technique that uses two digital keys, a public key known to
everyone and a private or secret key to keep secret. When, say, John wants to send
a secure message to Mary, he uses Mary's public key to encrypt the message. Only
Mary or the owner of the corresponding secret key can decrypt the message.
Public-Key Infrastructure (PKI)

A system of digital certificates, Certification Authorities, and other registration
authorities that verify and authenticate the validity of each party involved in an
Internet transaction.
Secure Electronic Transfer (SET)
A standard used by major credit card companies to set up secure credit card
transactions on the Internet. SET allows your credit card number to go direct to the
credit card company without being seen by the merchant.
Secure Sockets Layer (SSL)
A protocol developed by Netscape to set up a public-key cryptography connection
on the Web. SSL allows a Web browser to locate and display a Web page in secure
mode. The Web browser and server, in this case, are performing
encryption/decryption using public-key technologies online.
Server
A computer or device on a network that manages network resources. Usually,
servers are set up on a network to provide services to clients.
Socket
In the TCP/IP network, an addressable point that consists of an IP address and a
TCP or UDP port number that provides applications with access to TCP/IP.
TCP/IP network
114
The network using the TCP and IP suite. TCP guarantees data transmission; IP
deals with packets and address. TCP/IP networks are generally called Internet.
Transmission Control Protocol (TCP)
One of the main protocols in TCP/IP networks. TCP enables two hosts to establish
a connection and exchange data. It guarantees delivery of data and also that
packets will be delivered in the same order in which they were sent. Data will be
retransmitted if necessary.
Transport Layer Security (TLS)
Based on Netscape's SSL 3.0, TLS is an extension of SSL.
Uniform Resource Locator (URL)
The global address of documents and other resources on the Web. For example,
http://www.pwt-ex.com/ex01-01.htm and ftp://www.pwt-ex.com/ex01-01.htm are
two URLs to identify the same file on the Web.
UNIX
An operating system written by Ken Thompson of Bell Labs and used for
mainframes and minicomputers. It is now available for personal computers (PCs).
Web
A community of Internet servers that support HTML/XHTML formatted
documents. The documents or Web pages support a feature that links to other
documents, as well as graphics, audio, and video files.
Web browser
A software application used to locate and display Web pages on the Internet.
Web client
A computer or device running a Web browser to request network resources.
Web page
A document on the Web. Every Web page is identified by a unique address called
the uniform resource locator (URL).
115

Web server
A machine running server software such as Apache or IIS, assigned an IP address,
and connected to the Internet so that it can provide documents on the Web. A Web
server is sometimes called a host computer.
Web site
A Web server with a global unique URL.
Web site address

Refers to the IP address (such as 165.181.109.11) of the host computer or the name
(such as www.iua.com) that can be translated into an IP address.
4.5 Books Referred

1- Cryptography For Dummies
By Chey Cobb
John Wiley & Sons © 2004
Publisher: Wiley publishing Inc
2- An article from the net
Under title of "what is cryptography"
Written by Dan Blacharski
3- Information security (an overview)
Printed by Mohan Makhajan
Publisher: Asoke K.Ghosh
New Delhi 2004
4- An introduction to cryptography
Printed in USA
Author not found
5- A paper from the internet
Under title of "An overview of cryptography"
By Gary C.Kessler
Pub date: May 1998
6- Secure XML: the new syntax for signatures & encryption
By Donald E.Eastlake, Kitty Niles
Publisher: Adison Wesley
Pub date: July 19, 2002
7- Article from (wikipedia – the free encyclopedia on the net)
8- Practical web technologies
117
By P.K. yuen, V.Lau

Publisher: Adison Wesley
Printed in Great Britain
Pub date: September 09, 2003
9- Public key infrastructure overview
By Joel weise
Publisher: Sun Microsystems
Pub date: August 2001
10- Cryptography & Network security principle and practices
Fourth edition
By William stallings
Publisher: Prentice Hall
November 16, 2005
11- The Internet

12- Data Communication & Networking
By Behrouz A.Forouzan
Deanza College
Publisher: Tofa McGrow.Hill
New Delhi
13- Secure programming cookbook for c and c++
By Matt Messier , John viega
Published by O'Reily
Pub date : July 2003
14- network security with OpenSSL
By Pravir Chandra, john Viega
Publisher : O'Reily
118

Pub date: June 2002
15- An article from the net
Written by Qusay H. Mahmoud
November 2002

Public Key Infrastructure by Muhedin Abdullahi Mohammed

Uploaded by

Copyright:

Available Formats

Public Key Infrastructure by Muhedin Abdullahi Mohammed

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Public Key Infrastructure by Muhedin Abdullahi Mohammed

Uploaded by

Copyright:

Available Formats

1

Public key Infrastructure by Muhedin Abdullahi Mohammed

Computers and use of the Internet have fostered new interest in

Because cryptography is usually associated with spies, secret messages, and

The process of distinguishing information into an unintelligible form is

Fig 1.1: process of cryptography [4]

Predating computers by thousands of years, cryptography has its roots in

The Secure Sockets Layer (SSL) is a common encryption protocol used in e-

The goal of cryptography extends beyond merely making data unreadable, it

Public key Infrastructure by Muhedin Abdullahi Mohammed

The study of cryptography is advancing steadily, and scientists are rapidly

Cryptography is the art of secret writing.

1.3 Types of Cryptography

Cryptography has been implemented in many ways. During war

There are several ways of classifying cryptographic algorithms. For

1. Private (secret) Key Cryptography (SKC).

Public key Infrastructure by Muhedin Abdullahi Mohammed

1.3.1 Private Key Cryptography

Most cryptography techniques are key based. A key is a mathematical value

Secret key cryptography schemes are generally categorized as being either

 Electronic Codebook (ECB) mode is the simplest, most obvious

Fig 1.2 Secret Key Cryptography

Secret key cryptography algorithms that are in use today include:

Public key Infrastructure by Muhedin Abdullahi Mohammed

insecure network (such as the Internet) exchange a symmetric key securely?

same symmetric key, the authentication and integrity is not provable to a

1.3.2 Public-Key Cryptography

Public-key cryptography has been said to be the most significant new

PKC depends upon the existence of so-called one-way functions, or

1. Multiplication vs. factorization: Suppose we tell you that we have two

Public key Infrastructure by Muhedin Abdullahi Mohammed

Fig 1.3 Public Key Cryptography

cryptography over secret key cryptography. This is because public key

Public key Infrastructure by Muhedin Abdullahi Mohammed

o Another advantage of public key cryptography is that it ensures non-

1.3.3 Hash functions

Public key Infrastructure by Muhedin Abdullahi Mohammed

Fig 1.4 hash function [5]

Hash algorithms that are in common use today include:

 Message Digest (MD) algorithms: A series of byte-oriented algorithms that

Public key Infrastructure by Muhedin Abdullahi Mohammed

Fig 1.5 PGP uses Hash function [4]

1.4 Digital Cryptography Basics

1.4.1 Message Digests

Message digest functions convert sequences of bits, possibly quite long,

 It should be computationally infeasible to find another message whose

 It should be computationally infeasible to find two arbitrary messages whose

Fig 1.6 Message digest function

In the common case where an authentication method takes a large amount of

Public key Infrastructure by Muhedin Abdullahi Mohammed

Then the check octet is the middle eight bits of

With this level of complexity, it is no longer quite so trivial for an adversary

Expressing the goals of message digests more formally, if the message

Like other modern digital cryptographic functions, message digest functions

1.4.2 Message Authentication Codes

A message authentication code (MAC) function computes a MAC from a

A difficulty with MAC authentication in a system with multiple originators

As with message digest functions, if a strong MAC is N bits long, the

1.4.3 Digital Signatures