Public Key Infrastructure by Muhedin Abdullahi Mohammed
Public Key Infrastructure by Muhedin Abdullahi Mohammed
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.
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
mechanisms, the keys used for encryption and decryption might be different and
that is known as public key cryptography [3]
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.
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:
7
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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.
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
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
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
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
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).
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
International University of Africa Faculty of computer studies
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
13
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]
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]
15
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]
International University of Africa Faculty of computer studies
18
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
19
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
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.
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.
24
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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
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 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]
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]
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]
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
terminals over time. Thus, each device needs a number of keys supplied
dynamically. The problem is especially difficult in a wide area distributed system.
Public announcement
Publicly available directory
Public-key authority
Public- certificates
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
International University of Africa Faculty of computer studies
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.
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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]
35
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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.
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.
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
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]
International University of Africa Faculty of computer studies
40
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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
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
International University of Africa Faculty of computer studies
need a lot of certificates from the king (CA), it could get very expensive! So in the
real world, this all translates as follows:
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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
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.
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.
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]
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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
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.
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
International University of Africa Faculty of computer studies
difficult for someone to say they didn’t write a particular memo if their digital
signature is on it. [1]
To achieve the basic security services mentioned above the public key
infrastructure uses a number of protocols which include the following:-
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.
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.
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
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.
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]
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.
Sender Site A
Receiver Site B
International University of Africa Faculty of computer studies
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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]
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.
• Privacy
• Data integrity
• 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
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
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.
International University of Africa Faculty of computer studies
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
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:-
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
International University of Africa Faculty of computer studies
have methods used to create sockets. There is also an environment specific default
server socket factory; frameworks will often use their own customized factory.
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:
This package has six classes, four interfaces and five exceptions:
• SSLSocket class
• SSLServerSocket class
• SSLServerSocketFactory class
• SSLSession interface
This interface can be used to describe the current relationship between the server
and the client.
• SSLSessionContext interface
• 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
• 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 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.
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
• CertificateException class
• 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.
International University of Africa Faculty of computer studies
• 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
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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());
80
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
Note that the default factory is configured to enable server authentication only.
import java.io.*;
import javax.net.ssl.*;
81
The lines highlighted in bold in the following example show the code necessary to
make a client secure:
import java.io.*;
import javax.net.ssl.*;
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:
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.
*/
// main program
public static void main(String argv[]) throws
Exception {
HttpServer httpserver = new HttpServer();
httpserver.run();
}
}
/**
* Read the requested file and ships it
* to the browser if found.
*/
public static void shipDocument(DataOutputStream out,
out.writeBytes("Content-Type: text/html\r\n\r\n");
out.writeBytes("</body></html>");
out.flush();
} finally
{ out.close(
);
}
}
}
87
88
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>
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.
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.
import java.io.*;
import java.net.*;
import javax.net.*;
import javax.net.ssl.*;
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.
*/
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
sslcontext.getServerSocketFactory();
SSLServerSocket serversocket = (SSLServerSocket)
ssf.createServerSocket(HTTPS_PORT);
return serversocket;
// main program
public static void main(String argv[]) throws Exception {
HttpsServer https = new HttpsServer();
https.run();
}
}
93
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).
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
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".
connection to Sun's WWW server through the SSL port 443, which is the default
port number for HTTPS.
import java.net.*;
import javax.net.*;
import javax.net.ssl.*;
99
String line;
StringBuffer sb = new StringBuffer();
while((line = in.readLine()) != null) {
sb.append(line);
}
out.close();
in.close();
System.out.println(sb.toString());
}
}
100
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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:
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.
This will throw the following exception. Can you guess why?
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
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:
103
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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.
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.
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
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies
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.
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
117
Public key Infrastructure by Muhedin Abdullahi Mohammed
International University of Africa Faculty of computer studies