Cryptography Basics PKI

Unit 1 : Cryptography Basics Introduction and Key Terms
LEARN CRYPO & PKI
« La Citadelle électronique »
Cryptography
A technology for protecting you digital asset
And then design Security Solution

Introduction and Key Terms Unit 1 : Cryptography Basics
TRAINING CRYPTOGRAPHY & PKI
Author: Sylvain Maret

Security architect, PKI instructor & Checkpoint instructor
(Checkpoint CCSE)
Dimension Data (Swiss) formerly Datelec
Cédric Enzler
IPSEC & cryptographic engineer, PKI instructor
Dimension Data (Swiss) formerly Datelec
Revision: Version 1.5, October 1999, rev. August 2000

TABLE OF CONTENTS
Learn Crypo & PKI _______________________________________________1
Training Cryptography & PKI ______________________________________2
Table of contents _________________________________________________3
1. Cryptography Basics ___________________________________________5
1.1. Introduction _______________________________________________________5
1.2. Key terms _________________________________________________________5
1.3. Miscellaneous Cryptosystems _________________________________________7
1.3.1. Secret Key __________________________________________________________ 7
1.3.2. Public Key __________________________________________________________ 7
1.3.3. Message Digest ______________________________________________________ 7
1.4. Cryptography in history _____________________________________________8
1.5. Cryptoanalysis ____________________________________________________20
1.6. AES (Advanced Encryption Standard) ________________________________22
1.6.1. Overview of the AES Development Effort ________________________________ 22
1.6.2. Minimum Acceptability Requirements ___________________________________ 23
1.6.3. AES Round 2 Finalists ________________________________________________ 23
1.7. Smart Cards ______________________________________________________25
1.7.1. Introduction ________________________________________________________ 25
1.7.2. What kinds of Smart Cards are available? _________________________________ 25
1.7.3. Symmetric / Asymmetric Cryptoprocessing _______________________________ 26
1.7.4. Smart Cards with different “flavor” ______________________________________ 26
1.7.5. Memory Cards ______________________________________________________ 26
1.7.6. Symmetric Cryptoprocessor Cards ______________________________________ 27
1.7.7. PKI Smart Cards ____________________________________________________ 27
2. PKI Applications (lab exercises)_________________________________29
2.1. Symmetric file encryption ___________________________________________29
2.1.1. Lab Exercise 1 ______________________________________________________ 29
2.2. Message-Digest Algorithms __________________________________________33
2.2.1. Lab Exercise 2 ______________________________________________________ 33
2.3. Securing the desktop _______________________________________________37
2.3.1. Introduction ________________________________________________________ 37
2.3.2. Blowfish Advanced CS _______________________________________________ 37
2.3.3. Lab Exercise 3 ______________________________________________________ 40
2.4. PGP (Pretty Good Privacy) __________________________________________46
2.4.1. The PGP Symmetric Algorithms ________________________________________ 46
2.4.2. About PGP Data Compression Routines __________________________________ 47
2.4.3. About the Random Numbers used as Session Keys__________________________ 48
2.4.4. About the Message Digest _____________________________________________ 48
2.4.5. Encryption and Decryption ____________________________________________ 49
2.4.6. Digital Signature for PGP _____________________________________________ 50
2.4.7. Lab Exercise 4_______________________________________________________ 51

2.5. The SSH Protocol _________________________________________________ 63
2.5.1. Introduction _________________________________________________________ 63
2.5.2. Host Authentication___________________________________________________ 64
2.5.3. User Authentication___________________________________________________ 64
2.5.4. Cryptographic Methods________________________________________________ 65
2.5.5. Lab Exercise 5_______________________________________________________ 66
2.6. S/MIME _________________________________________________________ 79
2.6.1. Lab Exercise 6_______________________________________________________ 79
2.7. SSL _____________________________________________________________ 97
2.7.1. History_____________________________________________________________ 97
2.7.2. Secure Sockets Layer (SSL) ____________________________________________ 97
2.7.3. Session Establishment _________________________________________________ 98
2.7.4. Key Exchange Method ________________________________________________ 99
2.7.5. Cipher for Data Transfer _______________________________________________ 99
2.7.6. Digest Function _____________________________________________________ 100
2.7.7. Handshake Sequence Protocol _________________________________________ 100
2.7.8. Data Transfer_______________________________________________________ 101
2.7.9. Lab Exercise 7______________________________________________________ 102
2.7.10. Lab Exercise 8______________________________________________________ 123
2.8. Smart Card _____________________________________________________ 138
2.8.1. Lab Exercise 9______________________________________________________ 138
2.9. Playing the security officer _________________________________________ 140
2.9.1. Lab Exercise 10_____________________________________________________ 140
2.10. Revocation with client SSL authentication __________________________ 143
2.10.1. Lab Exercise 11_____________________________________________________ 143
2.11. IPSEC ________________________________________________________ 147
2.11.1. Introduction ________________________________________________________ 147
2.11.2. IPSec Architecture___________________________________________________ 148
2.11.3. IPSec Tunneling ____________________________________________________ 149
2.11.4. IKE Main Mode and Quick Mode_______________________________________ 154
2.11.5. Lab Exercise 12_____________________________________________________ 157
1. CRYPTOGRAPHY BASICS
1.1. INTRODUCTION
It is likely that almost all students attending our “introduction to PKI” already have at least a
basic knowledge of encryption and related subjects. Consequently, some of you might wish to
skip this chapter: defining a terminology or a set of cryptography key terms is austere. However,
we decided to begin with this less exciting section because we noticed, in many discussions with
people familiar to the field, that terms definitions are often mixed up. As a result, we decided to
start with simple definitions of key terms, which will be used constantly in the course, in order to
provide the basis needed to understand the subject.
1.2. KEY TERMS

A message will be defined as plaintext or cleartext.
The process of disguising a message to hide its substance is encryption.
The encrypted message is refered to as ciphertext.
Decryption is the process turning cyphertext back into plaintext.
You can see hereafter a schematic view of these definitions:
Cryptography Key Terms Figure 1
Cryptography is the science allowing messages to be kept secure.
Cryptanalysis is the art and science of breaking ciphertext (seeing through the above disguise).
Cryptology is the mathematics branch encompassing both cryptography and cryptanalysis.

Today, as cryptology is based on mathematical properties of numbers both in modern algebra and
number theory, cryptologists are theoretical mathematicians.
Encryption and decryption are conducted by way of a set of mathematical functions, referred to
as cryptographic algorithm or cipher. Besides providing confidentiality, cryptography is
required to provide other security feature, as:
- Authentication: It should be possible for the receiver of an encrypted message to be certain

of the sender’s identity. Authentication is the process that guarantees the respect of this rule.
- Non repudiation: Inability of a sender to certify he was not the sender of the ciphertext.
- Integrity: Provides a guarantee that the message was not modified between the sender and
the receiver.
First ciphers or cryptographic algorithms suffered a major drawback : their security was based on
the secrecy of the algorithm itself. As a result, every time a user was leaving the group of people
knowing the algorithm, all other users had to switch to a different one! We understand today that
this is not acceptable, therefore these ciphers, called restricted algorithms, are not used anymore.
Modern cryptography worked around this drawback by introducing the concept of key. In these
algorithms, security is based on key(s), meaning that the algorithm can be published at no risk. In
most cases, the key used for encryption is not the same as the one used for decryption. As a
result, the above diagram is modified as follows:
Cryptography Key Terms Figure 2
A cryptosystem consists of a cipher, keys and all possible plaintexts and ciphertexts.
In some algorithms, the decryption key can be calculated from the encryption key. Both keys can
be similar or different. In this case, we talk about symmetric encryption (see further in the
course). In some other algorithms, both keys cannot be calculated from each other: this is called
asymmetric encryption or Public-Key encryption.
Unit 1 : Cryptography Basics Miscellaneous Cryptosystems
1.3. MISCELLANEOUS CRYPTOSYSTEMS

Today’s cryptosystems do not rely on simple text shifts or substitution techniques, like those
described in the beginning of the next section, but rather on sophisticated mathematical
algorithms that theoretically would use an unreasonable amount of computer power and time to
break. The range of applications using cryptography to solve everyday problems is growing.
Today, exchanging information is so easy and the amount of information we routinely exchange is
so far greater than ever before, that the need to secure that information and have secure means of
transmitting it is of considerable importance.
Records ranging from personal medical data to credit card purchases that were once relatively
easy to secure in hard copy now flow freely over public networks. Today, the use of cryptography
has shifted from a “weapon” conceived primarily for military applications and espionage to a
valuable and indispensable tool the general public to conduct everyday, routine transactions
1.3.1. Secret Key

This cryptosystem – sometimes referred to as Symmetric Key Encryption, this is a rather
straightforward cryptographic system in which plain text is encrypted by providing the encryption
algorithm with a value; this value is the secret key. Only the parties that know the secret key value
are able to decrypt the resulting cyphertext.
1.3.2. Public Key

Sometimes referred to as Asymmetric Key Encryption, this type of cryptosystem relies on a key set
composed of two elements: a private key and a public key. The public key is typically stored in a
location available to anyone. When someone wants to send an encrypted message to another
party, he obtains that party’s public key and uses it to encrypt the message. As the recipient is in
possession of the private component of the key, only he can decrypt s the message.
Miscellaneous Cryptosystems Figure 1
1.3.3. Message Digest

This type of cryptosystem is often called a hashing function. With this technology, a variable length
message is run through the encryption algorithm to produce a fixed length digest through the
algorithm to produce the original message.
All three cryptosystems are used in most Public Key Infrastructure implementations. They will be
described in more details in the following sections.
© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Version 1.5, October 1999, rev. August 2000 Page 7
Cryptography in History Unit 1 : Cryptography Basics
1.4. CRYPTOGRAPHY IN HISTORY

Cryptography is one of the oldest fields of technical study we can find records of, going back at
least 4,000 years. It is quite noteworthy that, of all the cryptosystems developed in those 4,000
years of effort, only 3 systems remain hard enough to break to be of real value.
Cryptography probably began in or around 2000 B.C. in Egypt, where hieroglyphics were used to
decorate the tombs of deceased rulers and kings. These hieroglyphics told the story of the life of
the king and proclaimed the great acts of his life. They were purposefully cryptic, but not
apparently intended to hide the text. Rather, they seem to have been intended to make the text
seem more regal and important. As time went by, these writings became more and more
complicated, and eventually the people lost interest in deciphering them.
Cryptography in History Figure 1: Hieroglyphics
Cryptology was (and still is to some extent) enshrouded in a veil of mystique to most people. It
was because of this that the public began to acquaint cryptography with the black arts. It was
often thought to be related to communication with dark spirits, and developed a bad image
because of this. Most early cryptographers were scientists, but the common people were often
convinced that they were also followers of the devil.
The ancient Chinese used the ideographic nature of their language to hide the meaning of words.
Messages were often transformed into ideographs for privacy, but no substantial use in early
Chinese military conquests is apparent. Genghis Khan, for example, seems never to have used
cryptography.
In India, secret writing was apparently more advanced. The government used secret codes to
communicate with a network of spies spread throughout the country. Early Indian ciphers
consisted mostly of simple alphabetic substitutions, often based on phonetics. Some of these were
spoken or used as sign language. This is somewhat similar to "pig latin" (igpay atinlay) where the
first consonant is placed at the end of the word and followed by the sound "ay".

Unit 1 : Cryptography Basics Cryptography in History
The cryptographic history of Mesopotamia was similar to that of Egypt, in that cuneiforms were
used to encipher text. The picture here under shows table of numbers found in Suse (Iran
modern). These numbers were associated to words, demonstrating an amazingly modern level of
cryptography.
Cryptography in History Figure 2: Mesopotamian tables
This technique was also used in Babylon and Assyria. In the Bible, a Hebrew ciphering method is
used at times. In this method, the last letter of the alphabet is replaced by the first, and vice versa.
This is called 'atbash'. For example, the following table gives a translation of this sort for English.
The word "HELLO" becomes "SVOOL". Try to decrypt the word "WVXIBKG" and see what
you get.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ZYXWVUTSRQPONMLKJIHGFEDCBA
Cryptography in History Figure 3: An “Atbash” cipher
In the famous Greek drama the 'Iliad', cryptography was used when Bellerophon was sent to the
king with a secret tablet, which told the king to have him put to death. The king tried to kill him
by having him fight several mythical creatures, but he won every battle.
The Spartans used a system, which consisted of a thin sheet of papyrus wrapped around a staff
(now called a "staff cipher"). Messages were written down the length of the staff, and the papyrus
was unwrapped. In order to read the message, the papyrus had to be wrapped around a staff of
equal diameter. Called the 'skytale' cipher, this was used in the 5th century B.C. to send secret
messages between Greek warriors. Without the right staff, it would be difficult to decode the
message using the techniques available at that time. The following version of the alphabet
demonstrates the technique. First we see the wrapped version of the alphabet, then the
unwrapped version.
ADGJMPSVY
BEHKNQTWZ
CFILORUX
ADGJMPSVYBEHKNQTWZCFILORUX
Cryptography in History Figure 4: A “Skytale” cypher

Polybius developed another Greek method (now called the "Polybius Square"). The letters of the
alphabet would be laid out in a five by five square (similar to the later Playfair method), with i and
j occupying the same square. Rows and columns are numbered 1 to 5 so that each letter has a
corresponding (row,column) pair. These pairs could easily be signaled by torches or hand signals.
Decryption consists of mapping the digit pairs back into their corresponding characters. This
system was the first to reduce the size of the symbol set, and in a loose sense it might be
considered the forerunner of modern binary representations of characters.
Cryptography in History Figure 5: The “Polybius Square”
Julius Ceasar used a system of cryptography (i.e. the 'Caesar Cipher') which shifted each letter 2
places further through the alphabet (e.g. Y shifts to A, R shifts to T, etc.). This is probably the
first cipher used by most schoolchildren. In figure 5, the first row is plaintext, while the second
row is the equivalent ciphertext. The distance of the displacement is not important to the scheme,
and in fact, neither is the lexical ordering chosen. The general case of this sort of cipher is the
"monoalphabetic substitution cipher" wherein each letter is mapped into another letter in a one to
one fashion. Try decoding VJKU.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
CDEFGHIJKLMNOPQRSTUVWXYZAB
Cryptography in History Figure 6: The “Caesar” cypher
Cryptanalysis is the practice of changing ciphertext into plaintext without complete knowledge of
the cipher. The Arabs were the first to make significant advances in cryptanalysis. An Arabic
author, Qalqashandi, wrote down a technique for solving ciphers which is still used today. The
technique is to write down all the ciphertext letters and count the frequency of each symbol.
Using the average frequency of each letter of the language, the plaintext can be written out. This
technique is powerful enough to cryptanalyze ANY monoalphabetic substitution cipher if enough
cyphertext is provided.
During the Middle Ages, cryptography started to progress. All of the Western European
governments used cryptography in one form or another, and codes started to become more
popular. Ciphers were commonly used to keep in touch with ambassadors. The first major
advances in cryptography were made in Italy. Venice created an elaborate organization in 1452
with the sole purpose of dealing with cryptography. They had three cipher secretaries who solved
and created ciphers that were used by the government.

Leon Battista Alberti was known as "The Father of Western Cryptology" in part because of his
development of polyalphabetic substitution. Polyalphabetic substitution is any technique allowing
different ciphertext symbols to represent the same plaintext symbol. This makes it more difficult
to interpret ciphertext using frequency analysis. In order to develop this technique, Alberti
analyzed the methods for breaking ciphers, and devised a cipher which would try to render these
techniques invalid. He designed two copper disks that fit into each other, each with the alphabet
inscribed upon it. To start enciphering, a predetermined letter on the inner disk is lined up with
any letter on the outer disk, which is written as the first character of the ciphertext. The disks are
kept stationary, with each plaintext letter on the inner disk aligned with a ciphertext letter on the
outer disk. After a few words of ciphertext, the disks are rotated so that the index letter on the
inner disk is aligned with a new letter on the outer disk, and in this manner, the message is
enciphered. By rotating the disk every few words, the cipher changed enough to limit the
effectiveness of frequency analysis. Even though this technique in its stated form is very weak, the
idea of rotating the disks and therefore changing the cipher many times within a message was a
major breakthrough in cryptography.
The next major step was taken in 1518 by Trithemius, a German monk who had a deep interest in
the occult. He wrote a series of six books called 'Polygraphia', and in the fifth book, devised a
table that repeated the alphabet with each row a duplicate of the one above it, shifted over one
letter. To encode a message, the first letter of the plaintext is enciphered with the first row of the
table, the second letter with the second row, and so on. This produces a message where all
available ciphers are used before being repeated. Figure 7 shows a changing key cipher of this sort.
Notice that the assignment of code symbols to plaintext symbols changes at each time step
(T1,T2,...). In this system, the key repeats every 26 letters of ciphertext. Here under we see the
table used (called tabula recta) as well as successiv encryption step
Cryptography in History Figure 7: “Tabula recta”
ABCDEFGHIJKLMNOPQRSTUVWXYZ Plaintext
FGUQHXSZACNDMRTVWEJBLIKPYO T0
OFGUQHXSZACNDMRTVWEJBLIKPY T1
YOFGUQHXSZACNDMRTVWEJBLIKP T2
PYOFGUQHXSZACNDMRTVWEJBLIK T3
GUQHXSZACNDMRTVWEJBLIKPYOF T25
Cryptography in History Figure 8: A “Changing Key” cipher

In 1553, Giovan Batista Belaso extended this technique by choosing a keyword that is written
above the plaintext, in a letter to letter correspondence. The keyword is restarted at the beginning
of each new plaintext word. The letter of the keyword above the letter of the plaintext is the first
letter of the cipher line to be used. In other words, if the plaintext letter is 'b', and it's keyword
letter is 'r', then the line of the Trithemius cipher beginning with 'r' is used to encipher the letter
'b'. He chose to name the keyword a “password”…
Keyword : BEL ASOBELA SOB ELASOB

Plaintext : LES ITALIENS ONT TROUVE
The basic keyword is BELASO in this example.
The most famous cryptographer of the 16th century was Blaise de Vigenere (1523-1596). In 1585,
he wrote 'Tracte des Chiffres' in which he used a Trithemius table, but changed the way the key
system worked. One of his techniques was to use plaintext as its own key. Another used
ciphertext. The way in which these keys are used is known as key scheduling, and is an integral part
of the "Data Encryption Standard" (DES) which we will discuss later.
Cryptography in History Figure 9
Until 1917, Vigene cipher was considered as impossible to decrypt.
In 1628, a Frenchman named Antoine Rossignol helped his army defeat the Huguenots by
decoding a captured message. After this victory, he was called upon many times to solve ciphers
for the French government. He used two lists to solve his ciphers: "one in which the plain
elements were in alphabetical order and the code elements randomized, and one to facilitate
decoding in which the code elements stood in alphabetical or numerical order while their plain
equivalents were disarranged." When Rossignol died in 1682, his son, and later his grandson,

continued his work. By this time, there were many cryptographers employed by the French
government. Together, they formed the "Cabinet Noir" (the "Black Chamber").
By the 1700's, "Black Chambers" were common in Europe, one of the most renown being that in
Vienna. It was called 'The Geheime Kabinets-Kanzlei' and was directed by Baron Ignaz de Koch
between 1749 and 1763. This organization read through all the mail coming to foreign embassies,
copied the letters, resealed them, and returned them to the post-office the same morning. The
same office also handled all other political or military interceptions, and would sometimes read as
many as 100 letters a day. The English Black Chamber was formed by John Wallis in 1701. Until
that time, he had been solving ciphers for the government in a variety of unofficial positions.
After his death in 1703, his grandson, William Blencowe, who was taught by his grandfather, took
over his position and was granted the title of Decypherer. The English Black Chamber had a long
history of victories in the cryptographic world.
In the colonies, there was no centralized cryptographic organization. Decryption was done
predominantly by interested individuals and men of the cloth. In 1775, a letter intercepted from
Dr. Benjamin Church was suspected to be a coded message to the British, yet the American
revolutionaries could not decipher it. Their problem was solved by Elbridge Gerry, who later
became the fifth Vice-President, and Elisha Porter. The message proved Church guilty of trying
to inform the Tories, and he was later exiled.
Benedict Arnold used a code wherein each correspondent has an exact copy of the same
'codebook'. Each word of plaintext is replaced by a number indicating its position in the book
(e.g. 3.5.2, means page 3, line 5, word 2). Arnold's correspondent was caught and hung, so the
codebook wasn't used very much.
The revolutionaries also employed ciphers during the war. Samuel Woodhull and Robert
Townsend supplied General George Washington with much information about British troop
strength and movements in and around New York City. The code they used consisted of
numbers, which replaced plaintext words. Major Benjamin Tallmadge wrote this code. For further
assurance, they also used invisible ink.
The father of American cryptology is James Lovell. He was loyal to the colonies, and solved many
British ciphers, some which led to Revolutionary victories. In fact, one of the messages that he
deciphered set the stage for the final victory of the war.
Former Vice-President Aaron Burr and his assistant General James Wilkinson were exploring the
Southwest for possible colonization at the expense of Spain, and there was some confusion as to
whether this colony would belong to the United States or Aaron Burr. Wilkinson was a Spanish
agent, and changed one of Burr's encrypted letters home to make it appear as if Burr's intentions
were to carve out his own country. This letter fell into the hands of President Thomas Jefferson.
Burr was tried and acquitted, but his name was tainted forever.
The 'wheel cipher' was invented by Thomas Jefferson around 1795, and although he never did
very much with it, a very similar system was still in use by the US navy only a few years ago. The
wheel cipher consisted of a set of wheels, each with random orderings of the letters of the
alphabet. The key to the system is the ordering in which the wheels are placed on an axle. The
message is encoded by aligning the letters along the rotational axis of the axle such that the
desired message is formed. Any other row of aligned letters can then be used as the ciphertext for

transmission. The decryption requires the recipient to align the letters of the ciphertext along the
rotational axis and find a set of aligned letters that makes linguistic sense as plaintext. This will be
the message. There is a very small probability that there will be two sensible messages from the
decryption process, but this can be checked simply by the originator. Without knowing the
orderings of symbols on the wheels and the ordering of wheels on the axle, any plaintext of the
appropriate length is possible, and thus the system is quite secure for one time use. Statistical
attacks are feasible if the same wheels are used in the same order many times.
Wheel 1 GJTXUVWCHYIZKLNMARBFDOESQP
Wheel 2 IKMNQLPBYFCWEDXGZAJHURSTOV
Wheel 3 HJLIKNXWCGBDSRVUEOFYPAMQZT
...
Wheel n BDFONGHJIKLSTVUWMYEPRQXZAC
Cryptography in History Figure 10: A “Wheel” cipher
In 1817, Colonel Decius Wadsworth developed a set of two disks, one inside the other, where the
outer disk had the 26 letters of the alphabet, and the numbers 2-8, and the inner disk had only the
26 letters. The disks were geared together at a ratio of 26:33. To encipher a message, the inner
disk is turned until the desired letter is at the top position, with the number of turn required for
this result transmitted as ciphertext. Because of the gearing, a ciphertext substitution for a
character will not repeat itself until all 33 characters for that plaintext letter have been used.
Unfortunately, Wadsworth never got credit for his design, because Charles Wheatstone invented
an almost identical machine a few years after Wadsworth, and got all the credit.
In 1844, the development of cryptography was dramatically altered by the invention of the
telegraph. Communication with the telegraph was by no means secure, so ciphers were needed to
transmit secret information. The public's interest in cryptography blossomed, and many
individuals attempted to formulate their own cipher systems. The advent of the telegraph
provided the first instance where a base commander could be in instant communication with his
field commanders during battle. Thus, a field cipher was needed. At first, the military used a
Vigenere cipher with a short repeating keyword, but in 1863, a solution was discovered by
Friedrich W. Kasiski for all periodic polyalphabetic ciphers, which until this time were considered
unbreakable. So the military had to search for a new cipher to replace the Vigenere.
The Black Chambers of Europe continued to operate and were successful in solving most
American ciphers, but without a war underway, their usefulness was diminished, and by 1850 they
were dissolved.

The 'Playfair' system was invented by Charles Wheatstone and Lyon Playfair in 1854, and was the
first system that used pairs of symbols for encryption. The alphabet is laid out in a random 5 x 5
square, and the text is divided into adjacent pairs. The two letters of the pair are located, and a
rectangle is formed with the two letters at opposite corners. The letters at the other two corners
are the two letters of ciphertext. This is very simple to use, but is not extremely difficult to break.
The real breakthrough in this system was the use of two letters at a time. The effect is to make the
statistics of the language less pronounced, and therefore to increase the amount of work and the
amount of ciphertext required to determine a solution. This system was still in limited use in
World War 2, and was very effective against the Japanese.
I K M N Q
L P B Y F
C W E D X
G Z A H U
R S T O V
Plaintext: PL AI NT EX TZ
Ciphertext: LP MG MO XE AS
In 1859, Pliny Earle Chase, developed what is known as the fractionating or tomographic cipher.
A two digit number was assigned to each character of plaintext by means of a table. These
numbers were written so that the first numbers formed a row on top of the second numbers. The
bottom row was multiplied by nine, and the corresponding pairs are put back in the table to form
the ciphertext.
Kasiski developed a cryptanalysis method in 1863, which broke almost every existing cipher of
that time. The method was to find repetitions of strings of characters in the ciphertext. The
distance between these repetitions is then used to find the length of the key. Since repetitions of
identically ciphered identical plaintext occur at distances that are a multiple of the key length,
finding greatest common divisors of repetition distances will lead to the key length. Once the key
length (N) is known, we use statistics on every Nth character and the frequency of use implies
which character it represents in that set of ciphertext symbols. These repetitions sometimes occur
by pure chance, and it sometimes takes several tries to find the true length of the key using this
method, but it is considerably more effective than previous techniques. This technique makes
cryptanalysis of polyalphabetic substitution ciphers quite straight forward.
During the Civil War (1861-1865), ciphers were not very complex. Many techniques consisted
merely of writing words in a different order and substituting code words for proper names and
locations. Where the Union had centralized cipher control, the Confederacy tended to let field
commanders decide their own forms of ciphers. The Vigenere system was widely used by field
commanders, and sometimes led to the Union deciphering messages faster than their Confederate
recipients. The Confederacy used three keywords for most of its messages during the War,
"Manchester Bluff", "Complete Victory", and "Come Retribution". They were quickly discovered
by three Union cryptanalysts Tinker, Chandler, and Bates, and messages encoded using them were
regularly deciphered by the Union. The use of common words as keys to cryptosystems has
caused many plaintext messages to be discovered. In fact, the use of common words for
passwords is the most common entry point in modern computer system attacks.

In 1883, Auguste Kerckhoffs wrote 'La Cryptographie Militaire' in which he set forth six basic
requirements of cryptography. We note that the easily remembered key is very amenable to attack,
and that these rules, as all others, should be questioned before placing trust in them.
1. Ciphertext should be unbreakable.

2. The cryptosystem should be convenient for the correspondents.
3. The key should be easily remembered and changeable.
4. The ciphertext should be transmissible by telegraph.
5. The cipher apparatus should be easily portable.
6. The cipher machine should be relatively easily to use.
In the beginning of the 20th century, war was becoming likely in Europe. England spent a
substantial effort improving its cryptanalytic capabilities so that when the war started, they were
able to solve most enemy ciphers. The cryptanalysis group was called 'Room 40' because of its
initial location in a particular building in London. Their greatest achievements were in solving
German naval ciphers. These solutions were greatly simplified because the Germans often used
political or nationalistic words as keys, changed keys at regular intervals, gave away intelligence
indicators when keys were changed, etc.
Just as the telegraph changed cryptography in 1844, the radio changed cryptography in 1895. Now
transmissions were open for anyone's inspection, and physical security was no longer possible.
The French had many radio stations by WW1 and intercepted most German radio transmissions.
The Germans used a double columnar transposition that they called 'Ubchi', which was easily
broken by French cryptanalysts.
In 1917, the Americans formed the cryptographic organization MI-8. Its director was Herbert
Osborne Yardley. They analyzed all types of secret messages, including secret inks, encryption,
and codes. They continued with much success during and after WW1, but in 1929, Herbert
Hoover decided to close them down because he thought it was improper to "read others' mail".
Yardley was hard pressed to find work during the depression, so to feed his family, he wrote a
book describing the workings of MI-8. It was titled "The American Black Chamber", and became
a best seller. Many criticized him for divulging secrets and glorifying his own actions during the
War. Another American, William Frederick Friedman, worked with his wife, Elizabeth Smith, to
become "the most famous husband-and-wife team in the history of cryptology". He developed
new ways to solve Vigenere-like ciphers using a method of frequency counts and superimposition
to determine the key and plaintext.
Up to 1917, transmissions sent over telegraph wires were encoded in Baudot code for use with
teletypes. The American Telephone and Telegraph company was very concerned with how easily
these could be read, so Gilbert S. Vernam developed a system which added together the plaintext
electronic pulses with a key to produce ciphertext pulses. It was difficult to use at times, because
keys were cumbersome. Vernam developed a machine to encipher messages, but the system was
never widely used.
The use of cryptographic machines dramatically changed the nature of cryptography and
cryptanalysis. Cryptography became intimately related to machine design, and security personnel
became involved with the protection of these machines. The basic systems remained the same,
but the method of encryption became reliable and electromechanical.

In 1929, Lester S. Hill published an article "Cryptography in an Algebraic Alphabet" in "The

American Mathematical Monthly". Each plaintext letter was given a numerical value. He then
used polynomial equations to encipher plaintext, with values over 25 reduced modulo 26. To
simplify equations, Hill transformed them into matrices, which are more easily multiplied. This
method eliminates almost all ciphertext repetitions, and is not broken with a normal frequency
analysis attack. It has been found that if a cryptanalyst has two different ciphertexts from the
same plaintext, and if they use different equations of the same type, the equations can be solved,
and the system is thus broken. To counter charges that his system was too complicated for day to
day use, Hill constructed a cipher machine for his system using a series of geared wheels
connected together. One problem was that the machine could only handle a limited number of
keys, and even with the machine, the system saw only limited use in the encipherment of
government radio call signs. Hill's major contribution was the use of mathematics to design and
analyze cryptosystems.
The next major advance in electromechanical cryptography was the invention of the rotor. The
rotor is a hick disk with two faces, each with 26 brass contacts separated by insulating material.
Each contact on the input (plaintext) face is connected by a wire to a random contact on the
output (ciphertext) face. Each contact is assigned a letter. An electrical impulse applied to a
contact on the input face will result in a different letter being output from the ciphertext face. The
simple rotor thus implements a monoalphabetic substitution cipher. This rotor is set in a device
which takes plaintext input from a typewriter keyboard and sends the corresponding electrical
impulse into the plaintext face. The ciphertext is generated from the rotor and printed and/or
transmitted.
The next step separates the rotor from previous systems. After each letter, the rotor is turned so
that the entire alphabet is shifted one letter over. The rotor is thus a "progressive key
polyalphabetic substitution cipher with a mixed alphabet and a period of 26". A second rotor is
then added, which shifts its position one spot when the first rotor has completed each rotation.
Each electrical impulse is driven through both rotors so that it is encrypted twice. Since both
rotors move, the alphabet now has a period of 676. As more rotors are added the period increases
dramatically. With 3 rotors, the period is 17,576, with 4 it is 456,976, and with 5 it is 11,881,376.
In order for a 5 rotor cipher to be broken with frequency analysis, the ciphertext must be
extremely long.
The rotor system can be broken because, if a repetition is found in the first 26 letters, the
cryptanalyst knows that only the first rotor has moved, and that the connections are changed only
by that movement. Each successive set of 26 letters has this property, and using equations, the
cryptanalyst can completely determine this rotor, hence eliminating one rotor from the whole
problem. This can be repeated for each successive rotor as the previous rotor becomes known,
with the additional advantage that the periods become longer, and thus they are guaranteed to
have many repetitions. This is quite complex to do by hand.
The first rotor machine was invented by Edward Hugh Hebern in 1918, and he instantly realized
what a success it could be. He founded a company called Hebern Electric Code, which he
promised would be a great financial success. The company died in a bitter struggle, the
Government bought some of his machines, and he continued to produce them on his own, but
never with great success.

During Prohibition, alcohol was transported into the country by illegal smugglers (i.e. rum
runners) who used coded radio communication to control illegal traffic and help avoid Coast
Guard patrols. In order to keep the Coast Guard in the dark the smugglers used an intricate
system of codes and ciphers. The Coast Guard hired Mrs. Elizabeth Smith Friedman to decipher
these codes, and thus forced the rum runners to use more complex codes, and to change their
keys more often. She succeeded in sending many rum runners to jail.
During WW2, the neutral country Sweden had one of the most effective cryptanalysis
departments in the world. It was formed in 1936, and by the time the war started, employed 22
people. The department was divided into groups, each concerned with a specific language. The
Swedes were very effective in interpreting the messages of all the warring nations. They were
helped, however, by bungling cryptographers. Often the messages that were received were
haphazardly enciphered, or even not enciphered at all. The Swedes even solved a German cipher
that was implemented on a Siemens machine similar to a Baudot machine used to encipher wired
messages.
During WW2, the Americans had great success at breaking Japanese codes, while the Japanese,
unable to break US codes, assumed that their codes were also unbreakable. Cryptanalysis was used
to thwart the Japanese attack on Midway, a decisive battle in the South Pacific. The US had been
regularly reading Japanese codes before the attack on Pearl Harbor, and knew of the declaration
of war that was presented to the President just after the attack on Pearl Harbor, several hours
before the Japanese embassy in Washington had decoded it. German codes in WW2 were
predominantly based on the 'Enigma' machine, which is an extension of the electromechanical
rotor machine discussed above. A British cryptanalysis group, in conjunction with an escaped
group of Polish cryptanalysts, first broke the Enigma early in WW2, and some of the first uses of
computers were for decoding Enigma ciphers intercepted from the Germans. The fact that these
codes were broken was of such extreme sensitivity, that advanced knowledge of bombing raids on
England was not used to prepare for the raids. Instead, much credit was given to radar, and air
raids were given very shortly before the bombers arrived.
In 1948, Shannon published "A Communications Theory of Secrecy Systems". Shannon was one
of the first modern cryptographers to attribute advanced mathematical techniques to the science
of ciphers. Although the use of frequency analysis for solving substitution ciphers was begun
many years earlier, Shannon's analysis demonstrates several important features of the statistical
nature of language that make the solution to nearly all previous ciphers very straight forward.
Perhaps the most important result of Shannon's famous paper is the development of a measure of
cryptographic strength called the 'unicity distance'.
The unicity distance is a number that indicates the quantity of ciphertext required in order to
uniquely determine the plaintext of a message. It is a function of the length of the key used to
encipher the message and the statistical nature of the plaintext language. Given enough time, it is
guaranteed that any cipher can be broken given a length of ciphertext such that the unicity
distance is 1.
Shannon noted that in a system with an infinite length random key, the unicity distance is infinite,
and that for any alphabetic substitution cipher with a random key of length greater than or equal
to the length of the message, plaintext cannot be derived from ciphertext alone. This type of
cipher is called a "one-time-pad", because of the use of pads of paper to implement it in WW2
and before.

The story of cryptography would be finished if it weren't for the practical problem that, in order
to send a secret message, an equal amount of secret key must first be sent. This problem is not
severe in some cases, and it is apparently used on the hot line between Moscow and Washington,
but it is not the ultimate solution for many practical situations.
For most human (and computer) languages, a key of given length can only be guaranteed safe for
2-3 times the length of the key. From this analysis, it appears that any system with a finite key is
doomed to fail, but several issues remain to be resolved before all hope of a finite key
cryptography is abandoned.

Cryptoanalysis Unit 1 : Cryptography Basics
1.5. CRYPTOANALYSIS
As stated earlier, the strength of a cryptosystem lies in the key and whether or not the algorithm
has stood the test of time in a public forum. There are two terms used to describe the degree of
difficulty, sometimes called computational difficulty, associated with breaking a particular
cryptosystem:
Computationally secure: With a cryptosystem that is said to be computationally secure, it is

understood that given enough computing power and disk storage
space the system could eventually be broken. However, unless the
cryptosystem is flawed in some fundamental way, the amount of
time and computing power necessary to break the system would
either be too costly or unreasonable. For example, given today’s
technology, it would take an amount of time approximately equal
to the age of the universe to break the cryptosystem!
Unconditionally secure: A cryptosystem that can never be broken even if an infinite amount
of resources were dedicated to the effort is said to be
unconditionally secure.
By making the code of a cryptographic system available to the world, cryptographers have the
opportunity to do what they can to break a cryptosystem. Often, cryptographers will have a high
degree of computing power at their disposal: much more so than the average individual. This is
what is known as cryptoanalysis. In this field, a cryptanalyst deploys a variety of tools and
methods to break a cryptosystem, however, it does not necessarily mean that the entire algorithm
has been compromised. In fact, there are different levels of weaknesses one can discover in a
cryptosystem:
Information deduction: This is the lowest level weakness in which the cryptanalyst is able
to discover portions of the key or some information about the
plain text from the cipher text.
Instance deduction: The cryptanalyst is able to find the plaintext of a given intercepted
cipher.
Global deduction: The cryptanalyst devises an algorithm that can decrypt the
ciphertext created from another algorithm.
Total break: The cryptanalyst can recover the key and decrypt any encrypted
message.

Unit 1 : Cryptography Basics Cryptoanalysis
There are a variety of methods one can use to break a cipher. The easiest way is to obtain the key
either through social engineering, chance or some form of coercion. These however, are not
cryptanalytic techniques:
Ciphertext only: In this scenario, the cryptanalyst only has cipher text to work with.
If this is the case, one approach may be to user a brute-force attack in
which the cryptanalyst attempts to try all possible combinations of
keys. If the key is based on a pass phrase, often the cryptanalyst can
engage a dictionary attack in which he tries common words and
combinations
Chosen ciphertext: The cryptanalyst chooses the cipher text and attempts to obtain the
corresponding plaintext.
Adaptive chosen ciphertext:This is a variation of the attack outlined above in which the
cryptanalyst has free user of decryption hardware, but is unable to
extract the encryption key from it.
Known plaintext: The cryptanalyst may have the benefit of obtaining plaintext that
corresponds to some ciphertext. With these two elements, the
cryptanalyst may be able to derive the key with which to decipher
any text encrypted with that key.
Chosen plaintext: A variant of the known plaintext attack in which the cryptanalyst can
select the plaintext to use for the analysis and and then obtain the
corresponding ciphertext.
Adaptive chosen plaintext: A variation of the chosen plaintext attack in which the cryptanalyst
can dynamically choose the plaintext samples. Then, he can change
his selection based on the results of previous encryptions.
Biological attacks: This type of attack gets its name because the technique used to
break the cryptosystem resembles methods used in biology to study
organisms rather than the mathematically based techniques
described above. Biological techniques subject the cryptosystem
different stimuli to see how it reacts and studying its input and
outputs. An example would be some work done by Paul Kocher of
Cryptography research in which he was able to extract various
secrets from smartcards by monitoring its power consumption.
Specific information on these techniques can be found at
http://www.cryptography.com/dpa
Cryptanalytic attacks can be mounted against any cryptographic system including encryption
algorithms, digital signature algorithms and message authentication code (MAC) algorithms to
name a few.

AES (Advanced Encryption Standard) Unit 1 : Cryptography Basics
1.6. AES (ADVANCED ENCRYPTION STANDARD)
1.6.1. Overview of the AES Development Effort

The National Institute of Standards and Technology (NIST) has been working with industry and
the cryptographic community to develop an Advanced Encryption Standard (AES). The overall
aim is to develop a Federal Information Processing Standard (FIPS) that specifies an encryption
algorithm(s) capable of protecting sensitive government information well into the next century.
The algorithm(s) is expected to be used by the U.S. Government and, on a voluntary basis, by the
private sector.
On January 2, 1997, NIST announced the initiation of the AES development effort. They made a
formal call for algorithms on September 12, 1997. The call stipulated that the AES would specify
an unclassified, publicly disclosed encryption algorithm(s), available royalty-free, worldwide. In
addition, the algorithm(s) must implement symmetric key cryptography as a block cipher and (at a
minimum) support block sizes of 128-bits and key sizes of 128-, 192- and 256-bits.
On August 20th 1998, NIST announced a group of fifteen AES algorithm candidates at the First
AES Candidate Conference (AES1). Members of the cryptographic community from all over the
world had submitted these algorithms. At that conference and in a simultaneously published
Federal Register notice, NIST solicited public comments on the candidates. A Second AES
Candidate Conference (AES2) was held in March 1999, to discuss the results of the analysis
conducted by the global cryptographic community on the algorithm candidates. The public
comment period on the initial algorithm review closed on April 15th 1999. Using the analyses and
comments received, NIST selected five algorithms out of the fifteen.
The AES finalist algorithm candidates are MARS, RC6, Rijndael, Serpent, and Twofish. NIST has
developed a Round 1 Report describing the selection of the finalists. These algorithm finalists will
receive further analysis during a second, more detailed review period, and this before the selection
of the final algorithm(s) for the AES FIPS.
NIST solicits comments on the remaining algorithms until May 15th, 2000. Comments and
analysis are actively sought by NIST on any aspect of the candidate algorithm including (but not
limited to) the following topics: cryptanalysis, intellectual property, crosscutting analyses of all the
AES finalists, overall recommendations and implementation issues. An informal AES discussion
forum is also provided by NIST for interested parties to discuss the AES finalists and relevant
AES issues.
Near the end of Round 2, NIST will sponsor the Third AES Candidate Conference (AES3),
which is an open, public forum for discussing the analyses of the AES finalists. Submitters of the
AES finalists will be invited to attend the discussions and make comments on their algorithms.
AES3 will be held April 13th-14th, 2000 in New York, NY, USA. Proposed papers for this
conference are due to NIST by January 15th, 2000 and they will also be considered as Round 2
public comments.
After the closing of the Round 2 public analysis period on May 15th, 2000, NIST intends to study
all available information and propose the AES, which will incorporate one or more AES
algorithms selected from the finalists. The AES will be announced as a proposed Federal
Information Processing Standard (FIPS), which will be published for public review and

Unit 1 : Cryptography Basics AES (Advanced Encryption Standard)
comments. Following the comment period, the standard will be revised, as appropriate, by NIST
in response to those comments. A review, an approval and a promulgation process will also
follow. If all steps of the AES development process proceed as planned, it is scheduled that the
standard will be completed by the summer of 2001.
1.6.2. Minimum Acceptability Requirements

1. The algorithm must implement symmetric (secret) key cryptography.
2. The algorithm must be a block cipher.
3. The algorithm candidates shall be capable of supporting key-block combinations with sizes of
128-128, 192-128, and 256-128 bits. A submitted algorithm may support other key-block sizes
and combinations, and such features will be taken into consideration during analysis and
evaluation.
1.6.3. AES Round 2 Finalists

Mars – IBM Research
MARS is a shared-key (symmetric) block cipher, supporting 128-bit blocks and a variable key size.
It is designed to take advantage of the powerful operations supported in today's computers,
resulting in a much improved security/performance trade-off over existing ciphers. As a result,
MARS offers better security than triple DES while running significantly faster than single DES.
The current C implementation runs at rates of about 65 Mbit/sec. on a 200 MHz Pentium-Pro,
and 85 Mbit/sec. on a 200 MHz PowerPC. In hardware, MARS can achieve a 10X-speedup
factor. Moreover, both hardware and software MARS implementations are remarkably compact
and fit easily on a smartcard and in other limited-resource environments.
The combination of high security, high speed and flexibility makes of MARS an excellent choice
for the encryption needs of this century’s world information.
TwoFish – Counterpane Bruce Schneier

Twofish is a 128-bit block cipher that accepts a variable-length key up to 256 bits. The cipher is a
16-round Feistel network with a bijective F function made up of four key-dependent 8-by-8-bit S-
boxes, a fixed 4-by-4 maximum distance separable matrix over GF(28), a pseudo-Hadamard
transform, bitwise rotations, and a carefully designed key schedule. A fully optimized
implementation of Twofish encrypts on a Pentium Pro at 17.8 clock cycles per byte, and an 8-bit
smart card implementation encrypts at 1820 clock cycles per byte.
Twofish can be implemented in a 14000-gate hardware. The design of the round function and the
key schedule permits a wide variety of tradeoffs between speed, software size, key setup time, gate
count and memory. We have extensively cryptanalyzed Twofish : our best attack breaks 5 rounds
with 222.5 chosen plaintexts and 251 efforts.
RC6 - RSA Laboratories

Like all AES ciphers, RC6 works on 128 bit blocks. It can accept variable length keys and is very
similar to RC5, incorporating the results of various studies on RC5 to improve the algorithm. The
studies of RC5 found that not all bits of data are used to determine the rotation amount (rotation
is used extensively in RC5). However, RC6 uses multiplication to determine the rotation amount
and all bits of input data to determine the rotation amount, strengthening the avalanche effect.

AES (Advanced Encryption Standard) Unit 1 : Cryptography Basics
Serpent - Ross Anderson, Eli Biham, Lars Knudsen

Serpent is an AES submission by Ross Anderson, Eli Biham, and Lars Knudsen. Its authors
combined the design principles of DES with the recent development of bitslicing techniques to
create a very secure and very fast algorithm. While bitslicing is generally used to encrypt multiple
blocks in parallel, the designers of Serpent have embraced the technique of bitslicing
incorporating it into the design of the algorithm itself.
Serpent uses 128 bit blocks and 256 bit keys. Like DES, Serpent includes both an initial and a
final permutation of no cryptographic significance; these permutations are used to optimize the
data before encryption. Serpent was released at the 5th International Workshop on Fast Software
Encryption. This iteration of Serpent was called Serpent 0 and used the original DES S-boxes.
After comments, the key schedule and the S-boxes were changed slightly. This new iteration of
Serpent is called Serpent 1 and resists both linear and differential attacks.
Rijndael - Joan Daemen, Vincent Rijmen

The cipher has a variable block and key length. The authors have demonstrated how to extend the
block and key lengths by multiples of 32 bits. The SQUARE algorithm influenced the design of
Rijndael. The authors provide a Rijndael specification and a more theoretical paper on their
design principles. The authors have vowed to never patent Rijndael.

Unit 1 : Cryptography Basics Smart Cards
1.7. SMART CARDS
1.7.1. Introduction
Security issues around network (Internet) connected personal computers are heavily debated
today. One of the most discussed issues is weather someone can access your stored data or read
and alter information you type prior to sending it over the network.
If you want to do business over the Internet there are three major security services that have to be
in place:
1. Authentication
2. Confidentiality
3. Non-repudiation
PKI can offer those security services and seems to be the solution. PKI systems build on the
uniqueness and protection of the user’s private keys. The private key should never be exposed to
anyone, not even necessarily to the owner/user.
Where would you trust storing the keys you use to identity yourself and sign document or
agreements, order, etc… over the Internet? As you would have guessed, the answer to this
question is within a Smart Card.
1.7.2. What kinds of Smart Cards are available?

There are a number of smart cards on the market today but not all of them are viable for e-
commerce solutions requiring non-repudiation and remote authentication.
Smart cards consists of a chip (processor or/and memory), a contact plate (generally the visual
recognition point of a smart card) and a piece of plastic (ISO 7810 - 54x85x0.8 mm). Processor
chips require operating software (generally named a mask).
Although the chip may be the same, smart cards may be assembled and equipped by different
companies providing unique operating services. Widely known producers of smart cards are, to
mention a few, Gemplus, Schlumberger, Oberthur, Siemens, Giesecke & Devrient, Setec and
Bull. They all provide smart cards for a broad application range.
The combination of built-in chip functionality and an operating system on the chip (the mask),
supporting this functionality is essential in producing smart card security.
Basically all categories of cards described below offer some kind of write protection but not all of
them offer read protection. What is more important, some cards can not offer processing of data
(key) that only take place securely inside the chip. It should never be possible to copy "your
signature". Thus, techniques where signature keys are transported, even if encrypted, from the
card are simply not good enough. Therefore, in order to provide for non-repudiation services
there is an obvious need to have a secure signature process inside the smart card chip.

Smart Cards Unit 1 : Cryptography Basics
Smart cards can be divided into three prime categories:
1. Memory Cards
2. Symmetric Cryptoprocessor Cards
3. PKI smart cards (our name for asymmetric cryptoprocessor cards)
1.7.3. Symmetric / Asymmetric Cryptoprocessing

The reason for dividing Cryptoprocessor Cards into a symmetric and an asymmetric part (PKI
smart card) is simply because these processes are different when it comes to authentication and
non-repudiation. The processor on the chip providing symmetric encryption could possibly be
equipped with software (mask) enabling asymmetric encryption. Nevertheless, existing
asymmetric cryptoprocessor cards are dedicated to perform the cryptographic process (commonly
RSA) as fast as possible.
1.7.4. Smart Cards with different “flavor”

Remember that all smart cards are not alike, they come in different “flavors”. Many cards cannot
provide support for the RSA algorithm within the card processor. And even if they do support
RSA they may not be optimised to handle this process very efficiently. Far too often there are
solutions in place where the smart card is nothing but a storage media for the keys. This
document will describe various types of smart cards and where they typically apply.
1.7.5. Memory Cards
Access Control
Plain memory cards may provide access restrictions through one or several Personal Identification
Number (PIN). However, memory cards may not protect the contents of the stored information
file from disclosure. A memory card can be compared to a floppy disc although providing less
storage capacity. On the other hand the card reader device is less complex and less expensive
compared to a floppy disc reader, thus enabling a better commercial ground for deployment in
environments where a floppy disc reader may not be present.
Processing
Memory smart cards should probably not even be categorized as smart cards. Their processing
power is restricted to perform storage operations but little else. Once a user/owner of a PIN
protected file in a plain memory card has been granted read access he/she can freely retrieve the
contents of the file. Hence, the actual file contents may be copied from the smart card. These
cards exist with various amounts of memory and can be used in applications requiring none or
limited read protection. They may for instance be useful for storing medical information
necessary for emergency actions, such as your name and blood type. They may provide write
protection, which enables them to be useful in other applications where adding or modifying data
on the card should be restricted. However, such protection generally requires more than just a
PIN code, thus the commercial use is limited.
Conclusion
Memory cards can not provide a secure non-repudiation service, hence not very suitable for e-
commerce.

Unit 1 : Cryptography Basics Smart Cards
1.7.6. Symmetric Cryptoprocessor Cards
Access Control
Symmetric cryptoprocessor smart cards may offer a sophisticated access structure. Files may be
readable but not “writeable” or vice versa and if the reverse order applies, it is likely that the file
contents is accessible within the card. Files may be protected by one or several passwords (PIN)
and not accessible without entering the correct PIN. The PIN file itself is only “writeable” (in
order to let you change your password) and accessible within the card (in order to verify the PIN
you enter).
Processing
By using encryption it is possible to transfer information between two parties without disclosing
the contents to a "third-person". This is quite useful for applications utilizing an electronic smart
card purse or in connection with GSM cards. It is not only possible to have "files" write
protected. In fact, it is possible with the encryption process to ensure that only an authorized
party may alter information in a successful manner.
Symmetric encryption is fast, by broad margin faster than asymmetric encryption.
Conclusion
Although symmetric encryption is fast, it has a few drawbacks. First, key management is virtually
impossible from a large-scale public perspective, mainly due to the difficulty of deploying and
maintaining trust, and secondly, it is not possible to provide non-repudiation services.
1.7.7. PKI Smart Cards
Access Control
The basic difference between the PKI smart card and symmetric cryptoprocessor smart cards is
that the former offer a secure RSA process onboard the chip. From an access point of view they
are equal, what differs is the processing of RSA. In fact, it is likely that the PKI smart card
additionally can offer symmetric as well as asymmetric encryption functionality. Files may be
readable but not writeable or vice versa and only accessible within the card as described earlier.
Files may be protected by one or several passwords (PIN) and not accessible without entering the
correct PIN. This is also a necessity concerning the private key file.
Processing
PKI smart cards enable secure remote authentication and non-repudiation services through the
use of the RSA algorithm. PKI smart cards are using a cryptoprocessor handling asymmetric
encryption. The general positive effects of smart cards, i.e. ease of use and fairly low-cost
equipment, apply for all cards including PKI smart cards.
What makes PKI smart cards additionally beneficial compared to symmetric encryption cards is
the possibility to provide a scalable solution and not to be forgotten, the ability to provide for a
secure authentication and non-repudiation service. Scalability advantages due to the fact that there
is a public and a private part of keys involved and this makes deployment and maintenance much
easier from a security perspective compared to symmetric keys.

Smart Cards Unit 1 : Cryptography Basics
Also consider the effect of having only the RSA cryptoprocessor enabled to use your private
information; the private information is not possible to copy! It can never leave the card. The PKI
card offers a completely different level of security compared to storing private information on a
floppy disc, on a hard disc or even on a less protected smart card.
It is the card's operating system that prevents the keys from being exposed outside the card. They
can thus never be read, removed or tampered with (even by the user). The user will only have
access to the functions of the card through the use of a secret PIN code that the user may change
at any time.
Conclusion
The only secure smart card solution out on the market today would be a solution based on PKI
smart cards. If using something less, keys are only as secure as if they were stored on a floppy or
on your hard disc. PKI smart cards are the only alternative for doing business over an evolving e-
commerce market.

Unit 2 : PKI Applications (Lab Exercises) Symmetric File Encryption
2. PKI APPLICATIONS (LAB EXERCISES)

2.1. SYMMETRIC FILE ENCRYPTION
2.1.1. Lab Exercise 1
Objective
The student will use a symmetric encryption algorithm to encrypt a text file. DES and IDEA will
be used for this lab.
Main steps
1. Create a text file with an editor
2. Encrypt this file using DES
3. Encrypt this file using IDEA
4. Decrypt this file using DES
5. Decrypt this file using IDEA
Time
15 minutes

Symmetric File Encryption Unit 2 : PKI Applications (Lab Exercises)
Step 1: Create a text file with an editor

• Create a “Notepad file” called toto.txt in c:\temp
• Edit this file and add a text like “Hello world…”

• Save and quit

Unit 2 : PKI Applications (Lab Exercises) Symmetric File Encryption
Step 2: Encrypt this file using DES

• On your desktop, launch OpenSSL
• You will encrypt this file with DES. Type the command
des –in toto.txt –out toto.txt.des –e
• Enter a password that will be the secret key
• Have a look at the file toto.txt.des
Step 3: Encrypt this file using IDEA

• Encrypt the file toto.txt with IDEA. Type the command
idea –in toto.txt –out toto.txt.idea –e
• Enter a password
• Have a look at the file toto.txt.idea

Symmetric File Encryption Unit 2 : PKI Applications (Lab Exercises)
Step 4: Decrypt this file using DES

• You can now decrypt those two files
• Type des –in toto.txt.des –d to decrypt the DES file
• Enter your password
Step 5: Decrypt this file using IDEA

• Type idea –in toto.txt.idea –d to decrypt the IDEA file
• Enter your password
• Now you are finished…

Unit 2 : PKI Applications (Lab Exercises) Message-Digest Algorithms
2.2. MESSAGE-DIGEST ALGORITHMS
For a theoretical introduction, please refer to the book “Digital Certificates” written by Jalal Feghhi, Jalil Feghhi
and Peter Williams.
Objective
The student will “play” with message digest functions. MD5 and SHA-1 will be used to compute
digest for an input text file.
Main steps
1. Create a text file with an editor
2. Compute message digest functions with MD5
3. Change the text
4. Compute message digest functions again with MD5
5. Compute message digest functions with SHA-1
Time
15 minutes

Message-Digest Algorithms Unit 2 : PKI Applications (Lab Exercises)
Step 1: Create a text file with an editor

• Create a file with an editor called toto.txt in c:\temp
• Edit this file and add a text like “Hello world…”

• Save and quit

Unit 2 : PKI Applications (Lab Exercises) Message-Digest Algorithms
Step 2: Compute message digest functions with MD5

• On your desktop, launch OpenSSL
• Type the command md5 toto.txt
• Have a look at the result. You will see the MD5 digest (128 bits)
Step 3: Change the text

• Edit again c:\temp\toto.txt and change only one character (for instance H Æ h)

Message-Digest Algorithms Unit 2 : PKI Applications (Lab Exercises)
Step 4: Compute message digest functions again with MD5

• Type md5 toto.txt again on the OpenSSL applications
• What do you see? This is the new MD5 digest
Step 5: Compute message digest functions with SHA-1

• Type now sha1 toto.txt on the OpenSSL application
• What do you see? Compare this with the MD5 digest!
• You are now finished…

Unit 2 : PKI Applications (Lab Exercises) Securing the Desktop
2.3. SECURING THE DESKTOP
2.3.1. Introduction
Safeguarding data being transmitted as e-mail messages over an open network like the Internet is
an important step to take in order to keep your data private. Protecting data on a personal
computer presents a different set of issues in terms of how the data should be protected and how
to control keys. The most important issue may perhaps be how to select a data encryption
product for your desktop. Many products are available on the market to perform file encryption
(RSA SecurPC, Blowfish Advances CS, etc.)
For this particular training we will use “Blowfish Advanced CS” because it is a very simple
product to use. Moreover, it will allow you to be familiar with secret-key file encryption, key
splitting and files wiping.
2.3.2. Blowfish Advanced CS
Introduction
Blowfish Advanced CS is a file encryption program, protecting your files with a key built from a
password or a key disk, so that no one except you can access its contents. Blowfish Advanced CS
erases sensitive files that are no longer needed, in order to prevent anyone to restore them.
Working with encrypted files and clearing empty disk space are other useful features.
Today, we are in the information age and encrypting data is becoming more and more important
for most of us. There are many reasons why data have to be protected from unauthorized access,
as for instance sensitive medical data, private or business documents, or just some “hot stuff”
from the Internet.
There are many ways to make data readable only to a selection of people. Besides physical
measures like locking removable disks into a safe or hiding files with stenography (which is a
cheap solution), the only way to make files really inaccessible is to use strong cryptography. That
means high-end encryption algorithm with long-enough keys to resist any attacks, this combined
with secure removal of the original data.
Encryption Algorithms
Blowfish Advanced CS is currently shipped with 4 algorithms, which are the followings:
Blowfish
Bruce Schneier designed the algorithm. Blowfish is a very fast algorithm, performing with
excellence on modern 32bit processors. Another advantage is its variable key-size, which goes up
to 448 bits (56 bytes). It was first published in Doctor Dobb's Journal, issue 4/94, and after a year
of intensive cryptanalysis it was still unbroken (as reported in DDJ 10/95).
PC1
This algorithm is 100% compatible with the RC4 stream cipher. Ron Rivest developed RC4 in
1987. Someone posted 1994 the source code in a mailing list and since then it has been spread all
over the world. RC4 is a stream cipher handling single bytes. The implementation used by
Blowfish Advanced CS uses a key size of 160 bits.

Securing the Desktop Unit 2 : PKI Applications (Lab Exercises)
Triple-DES
DES is the standard encryption algorithm, designed by IBM in the middle seventies. Although it
has been cryptanalyzed for over 20 years, no weakness has been found yet. The only problem of
DES is its short key length of 7 bytes (equals 56 bits). If someone has access to very fast
computers, he can try out all possible keys within a few hours. There are some DES variants,
extending the original algorithm to a new one with a larger key. The most common one is triple-
DES, where a 64-bit data block will be encrypted three times with DES, using three different keys
(or a single key split into three parts). Therefore, the key length is 21 bytes (168 bits), improving
significantly the security but also slowing down the algorithm. The triple-DES implementation in
Blowfish Advanced CS is 100% compatible with the DES standard.
Twofish
TwoFish is the AES candidate from Counterpane. It is a new, fast and very flexible encryption
algorithm. After extensive cryptanalysis, no weaknesses are known yet. For more information
about TwoFish, visit http://www.counterpane.com. The version of Twofish in Blowfish Advanced CS
uses a key size of 256 bits and a block size of 128 bits.
Key Setup
Different encryption algorithms require different key lengths. The Blowfish encryption algorithm
needs e.g. a key of 448 bits (56 bytes). It is very uncomfortable to find passwords having exactly
the right length each time, so that the program converts the password into a key for the individual
algorithm.
Blowfish Advanced CS uses a key setup in which your password (or key disk content) is hashed
with SHA-1, the most "Secure Hash Algorithm" available today. One of the advantages is that the
key result appears in binary form and looks like random data. Moreover, the password’s length is
not restricted to the maximum key-length of the selected algorithm, so it can be hashed up or
down to the right size.
You will find hereafter two examples, which will help you to understand the key setup of Blowfish Advanced CS:
Let us choose "helloworld" as our password. We want to create a key of 128 bits (16 bytes). The
SHA-1 allows us to input as many data bytes as we wish and it puts out a hash of 160 bits (20
bytes). A hash (also called digest) is like a CRC32 checksum, but secure for encryption.

To resize the 20 bytes of the hash to the required 16 bytes for the key, we take the first 16 bytes
of the hash and XOR the rest of 4 bytes over the beginning of these 16 bytes. Doing so, we take
the totality of the hash into consideration:
In the second example, we still define "helloworld" as our password, but we need a key for
Blowfish having the required length of 56 bytes.
As already mentioned, SHA-1 only returns 20 bytes. So we have to create 36 additional bytes
from the password in the following way: we hash the password with SHA-1 and get 20 bytes.
Then we add those 20 bytes to the original password and hash the modified password again. The
result is a new hash, which means 20 new bytes for our key. Due to the modified password, this
new hash is completely different from the first one. Now we append this second hash to the
modified password again and rehash it to get the last 20 bytes. Of course, we have now 4 bytes
too much, so we XOR them over the first hash as we did in the first example. At least, we have
the needed 56 bytes for the Blowfish encryption algorithm.
Random Number Generation

Blowfish Advanced CS offers you two pseudo random number generators. PRNGs are used to
create random data for security purposes, (e.g. salt values, which are combined with keys), for
overwriting (wiping) data or (most important) to create key files.
Yarrow
This PRNG was designed by Counterpane and can be considered as the best concept to create
random data for security purposes. Blowfish Advanced CS uses a Yarrow implementation with
SHA-1 as the hash algorithm and triple-DES as the block cipher. For the latest paper of the
Yarrow specifications please visit http://www.counterpane.com.
CryptPak PRNG
The random generator was working in the predecessor Blowfish Advanced 97 as the one and only
PRNG. It uses a SHA-1 rescrambling method. To initialize the generator, a string with various
data (system date and time, drive information, etc.) is built and hashed by SHA-1. As a result, one
gets a 20 bytes buffer of random data, from which just 16 bytes are used to avoid predictable
random sequences. If another 16 bytes are requested, the hash value is hashed with itself to a new
digest. This method provides a much better randomness than conventional 32-bit random
number generators.

Objective
The student will setup a file’s encryption software to protect sensitive information. This software
will use strong symmetric encryption mechanisms to protect information.
Scenario
The Management wants to implement a solution to protect sensitive information on the laptop.
For specific files they want to implement key splitting. Moreover, they want to store a secret key
on an external support that will be a diskette.
Main Steps
1. Encrypt a file with one secret key
2. Exchange this file with your partner
3. Decrypt the partner’s file you receive
4. Encrypt a file with two secret keys (Key Splitting)
Time
20 minutes

Step 1: Encrypt a file with one secret key

• On your desktop, launch Blowfish Advanced CS.
• Select c:\encrypted files\ssh.pdf.
• Encrypt this file using the Blowfish encryption algorithm.
• Enter a password. In fact, it will be your private key.

• Keep this password secret. Your partner should not know it.
• Reenter the password to confirm.

• Now your file ssh.pdf is encrypted with your private key (or symmetric key).
Step 2: Exchange this file with your partner

• Send this encrypted file to your partner via e-mail. Your partner will also send one to you.

Step 3: Decrypt the partner’s file you receive

• Read your e-mail. You should have received the encrypted file from your partner.
• Double click on the attachment. Blowfish Advanced CS will be launched.

• Ask your partner’s password.
• Enter the password.
• That’s it, you are able to read the PDF document.

Step 4: Encrypt a file with two secret keys (Key Splitting)

You will now use Key Splitting
• Insert a diskette into your reader. The Key Disk will be stocked on it.
• Go to Tools Æ Option menu Miscellaneous and choose make a Key Disk. This key will be used as
a private key for encryption and decryption.
• Move you mouse until the progress bar has reached 100%. Those mouse’s movements are for
random seed.
• Key Disk generation is done.

• Now you can encrypt the file c:\encrypted files\securegate.pdf with your Key Disk.
• On the Encrypt option choose first Multi Key Input and Use Key Disk.

• Press Yes to append another password. It will be the second private key that we call Key
Splitting.
• Choose Password option and ask your partner to enter a password. Your partner should keep
this password private.
• Press No to end the encryption.
• The encryption with two keys (one Key Disk and one Standard password) is done.
• You can try to decrypt this file.
• Now, you are finished…

PGP (Pretty Good Privacy) Unit 2 : PKI Applications (Lab Exercises)
2.4. PGP (PRETTY GOOD PRIVACY)
2.4.1. The PGP Symmetric Algorithms

PGP offers a selection of different secret key algorithms to encrypt the actual message. By secret
key algorithm, we mean a conventional or symmetric block cipher that uses the same key to both
encrypt and decrypt. The three symmetric block ciphers offered by PGP are CAST, Triple-DES
and IDEA. They are not “home-grown” algorithms. Teams of cryptographers with distinguished
reputations developed them all.
For the cryptographic curious, all three ciphers operate on 64-bit blocks of plaintext and
ciphertext. CAST and IDEA have key sizes of 128 bits, while Triple-DES uses a 168-bit key. Like
Data Encryption Standard (DES), any of these ciphers can be used in cipher feedback (CFB) and
cipher block chaining (CBC) modes. PGP uses them in a 64-bit CFB mode.
CAST encryption algorithm has been included in PGP because it is promising as a good block
cipher with a 128-bit key size. Moreover, it is very fast and free. The name is derived from the
initials of its designers, Carlisle Adams and Stafford Tavares of Northern Telecom (Nortel).
Nortel have applied for a CAST patent, but they have made a written commitment to make CAST
available to anyone on a royalty-free basis. CAST appears to be exceptionally well designed by
people with good field reputation. The design is based on a very formal approach, with a number
of formally provable assertions, giving good reasons to believe that it probably requires key
exhaustion to break its 128-bit key. CAST has no weak or semiweak keys. There are strong
arguments that CAST is completely immune to both linear and differential cryptanalysis, the two
most powerful forms of cryptanalysis in the published literature. Moreover, both of them have
been effective in cracking DES.
CAST is too new to have developed a long track record, but its formal design and the good
reputation of its designers will undoubtedly draw the attention and attempt cryptanalytic attacks
of the rest of the academic cryptographic community. I nearly have the same good feeling of
confidence for CAST that I had years ago for IDEA, the cipher I selected for use in earlier
versions of PGP.
The IDEA (International Data Encryption Algorithm) block cipher is based on the design
concept of “mixing operations from different algebraic groups.” It was developed at ETH in
Zurich by James L. Massey and Xuejia Lai and published in 1990. Early published papers on the
algorithm called it IPES (Improved Proposed Encryption Standard), but they later changed the
name to IDEA. So far, IDEA has resisted attack much better than other ciphers such as FEAL,
REDOC-II, LOKI, Snefru and Khafre. Moreover, IDEA is more resistant than DES to Biham
and Shamir’s highly successful differential cryptanalysis attack, as well as attacks from linear
cryptanalysis.

Unit 2 : PKI Applications (Lab Exercises) PGP (Pretty Good Privacy)
As this cipher continues to attract attack efforts from the most formidable quarters of the
cryptanalytic world, confidence in IDEA is growing with the time. Sadly, the biggest obstacle to
IDEA’s acceptance as a standard has been the fact that Ascom Systec holds a patent on its design,
and unlike DES and CAST, IDEA has not been made available to anyone on a royalty-free basis.
As a hedge, PGP includes three-key Triple-DES in its repertoire of available block ciphers. IBM
developed the DES in the mid-1970s. While it has a good design, its 56-bit key size is too small
for today’s standards. Triple-DES is very strong and has been well studied for many years, that is
the reason why it might be a safer bet than the newer ciphers such as CAST and IDEA. Triple-
DES is the DES applied three times to the same block of data, using three different keys, except
that the second DES operation is run backwards, in decrypt mode. While Triple-DES is much
slower than either CAST or IDEA, speed is usually not critical for e-mail applications. Although
Triple-DES uses a key size of 168 bits, it appears to have an effective key strength of at least 112
bits against an attacker with immense data storage capacity to use in the attack.
According to a paper presented by Michael Weiner at Crypto96, any remotely plausible amount of
data storage available to the attacker would enable an attack requiring about as much work as
breaking a 129-bit key. It is important to specify that Triple-DES is not encumbered by any
patents.
PGP public keys that were generated by PGP Version 5.0, or later have information embedded in
them that tells a sender what block ciphers are understood by the recipient’s software, so that the
sender’s software knows which ciphers can be used to encrypt. Diffie-Hellman/DSS public keys
accept CAST, IDEA or Triple-DES as the block cipher, with CAST as the default selection. At
present, for compatibility reasons, RSA keys do not provide this feature. Only the IDEA cipher is
used by PGP to send messages to RSA keys, because older versions of PGP only supported RSA
and IDEA.
2.4.2. About PGP Data Compression Routines

PGP normally compresses the plaintext before encrypting it, because it is too late to compress the
plaintext after it has been encrypted. In fact, encrypted data is not compressible. Data
compression saves modem transmission time, disk space and, more importantly, strengthens
cryptographic security. Most cryptanalysis techniques exploit redundancies found in the plaintext
to crack the cipher. Data compression reduces this redundancy in the plaintext, thereby greatly
enhancing resistance to cryptanalysis. It takes extra time to compress the plaintext, but from a
security point of view, it is worth it. Files that are too short to compress, or that just don’t
compress well, are not compressed by PGP. In addition, the program recognizes files produced
by most popular compression programs, such as PKZIP, and does not try to compress a file that
has already been compressed.
For the technically curious, the program uses the freeware ZIP compression routines written by
Jean-Loup Gailly, Mark Adler, and Richard B. Wales. This ZIP software uses compression
algorithms that are functionally equivalent to those used by PKWare’s PKZIP 2.x. This ZIP
compression software was selected for PGP mainly because it has a really good compression ratio
and because it is fast.

2.4.3. About the Random Numbers used as Session Keys

PGP uses a cryptographically strong pseudo-random-number generator for creating temporary
session keys. If this random seed file does not exist, it is automatically created and seeded with
truly random numbers derived from your random events, gathered by the PGP program from the
timing of your keystroke and mouse movements. This generator “reseeds” the seed file each time
it is used, by mixing in new material partially derived from the time of day and other truly random
sources.
It uses the conventional encryption algorithm as an engine for the random number generator. The
seed file contains both random seed material and random key material used to key the
conventional encryption engine for the random generator. This random seed file should be
protected from disclosure, to reduce the risk of an attacker deriving your next or previous session
keys. The attacker would have a very hard time getting anything useful from capturing this
random seed file, because the file is cryptographically laundered before and after each use.
Nonetheless, it seems prudent to try to keep it from falling into the wrong hands. If possible,
make the file readable only by you. If this is not possible, don’t let other people indiscriminately
copy disks from your computer.
2.4.4. About the Message Digest

The message digest is a compact (160-bit or 128-bit) “distillate” of your message or file checksum.
You can also consider it as a “fingerprint” of the message or file. The message digest “represents”
your message, so that if the message were altered in any way, a different message digest would be
computed from it. This allows the detection of any changes made to the message by a forger.
A message digest is computed using a cryptographically strong one-way hash function of the
message. It should be computationally infeasible for an attacker to devise a substitute message
that would produce an identical message digest. In that respect, a message digest is much better
than a checksum, because it is easy to devise a different message that would produce the same
checksum. But like a checksum, you can’t derive the original message from its message digest.
The message digest algorithm used now in PGP (Version 5.0) is called SHA, which stands for
Secure Hash Algorithm, designed by the NSA for the National Institute of Standards and
Technology (NIST). SHA is a 160-bit hash algorithm. Some people might consider everything
from the NSA with suspicion, because the NSA is in charge of intercepting communications and
breaking codes. But keep in mind that the NSA has no interest in forging signatures and the
government would benefit from a good unforgeable digital signature standard that would
preclude anyone from repudiating their signatures. This has distinct benefits for law enforcement
and intelligence gathering.
SHA has been published in the open literature and has been extensively peer-reviewed by most of
the best cryptographers in the world who specialize in hash functions. Moreover, the unanimous
opinion is that SHA is extremely well designed. It has some design innovations that overcome all
the observed weaknesses in message digest algorithms previously published by academic
cryptographers. All new versions of PGP use SHA as the message digest algorithm for creating
signatures with the new DSS keys that comply with the NIST Digital Signature Standard. For
compatibility reasons, new versions of PGP still use MD5 for RSA signatures, because older
versions of PGP used MD5 for RSA signatures.

2.4.5. Encryption and Decryption

PGP combines some of the best features of both conventional and public key cryptography. PGP
is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP compresses first the
plaintext. Data compression saves modem transmission time and disk space and, more
importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns
found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext,
thereby greatly enhancing resistance to cryptanalysis. (Files that are too short to compress or
which don’t compress well aren’t compressed.) PGP creates then a session key, which is a one-
time-only secret key. This key is a randomnumber generated from the randommovements of your
mouse and the keystrokes you type. This session key works with a very secure, fast conventional
encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted,
the session key is then encrypted to the recipient’s public key. This public key-encrypted session
key is transmitted along with the ciphertext to the recipient.
PGP Figure 1
Decryption works in the reverse. The recipient’s copy of PGP uses his or her private key to
recover the temporary session key, which is then used by PGP to decrypt the conventionally
encrypted ciphertext.
PGP Figure 2
The combination of both encryption methods provides the convenience of public key encryption
with the speed of conventional encryption. Conventional encryption is about 1,000 times faster
than public key encryption. Public key encryption in turn provides a solution to key distribution
and data transmission issues. Used together, both encryption methods improve performance and
key distribution. Thus, security is not compromised.

2.4.6. Digital Signature for PGP

A major benefit of public key cryptography is that it provides a method for employing digital
signatures. Digital signatures enable the recipient of information to verify the authenticity of the
information’s origin and also that the information is intact. Thus, public key digital signatures
provide authentication and data integrity. A digital signature also provides non-repudiation,
which means that it prevents the sender from claiming that he or she did not actually send the
information. These features are as fundamental to cryptography as privacy, if not more !
A digital signature has the same purpose as a handwritten signature. However, a handwritten
signature is easy to counterfeit. A digital signature is superior to a handwritten signature as it is
nearly impossible to counterfeit. Moreover, it attests to the contents of the information as well as
to the identity of the signer. Some people tend to use signatures more than they use encryption.
For example, you may not care if anyone knows that you just deposited $1000 in your account,
but you do want to be sure it was the bank teller you were dealing with!
The basic manner in which digital signatures are created is illustrated in Figure 1. Instead of
encrypting information using someone else’s public key, you encrypt it with your private key. If
the information can be decrypted with your public key, then it must have originated by you.
PGP Figure 3

Objective
In order to make the student sensitive to other standards, the latter will setup an e-mail using
PGP encryption and key signature.
Scenario
You want to guarantee the privacy of an e-mail sent through the Internet between two peers. To
justify the idea, one admits that both peers do not have a common trust certificate authority (if so,
S/MIME would be in the scope) but hire the PGP software.
Main Steps
1. Generation of PGP key peers by each peer
2. Key cross exchange
3. Certification of a partner public key
4. Send a signed message
5. Send an encrypted and signed message
6. PGP behavior after unexpected cleartext modifications
Time
40minutes
Step 1: Generation of PGP Key pair

• Launch the PGP Keys application located in the systray. The first time, the user is prompt by a
wizard to generate a key-pair.

• Enter your personal data.
• So that each student can exchange encrypted information with the others, enter following
parameters:
Key-pair type: RSA
Key-pair size: 1024 bits
Key-pair never expires
• Once you have done this, you will be prompt to enter a passphrase that will protect the use of
your private key.

• After the key generation process has started, you are asked if you want to send your public
key to a root server. The aim of this PGP root server is to play the role of a PGP public key
container. The idea behind this is that if you want to establish a secure connection with
another PGP pair, you simply get its public key from this server. Of course, this sounds very
practical, but is it secure? Think about it!
Note: In the current case, we will not try to send the key...
• The following window will appear and confirm the key-pair generation.

Step 2: Key cross exchange

Before entering step 2, check that your partner has successfully accomplished step 1. In this
example, Londres’s partner will be Rome, so...watch carefully the recipient/sender names in the next
printed screens. To avoid confusion, keep in mind that the printed screens are coming from
Londres ONLY.
Londres is now ready to send its public key to Rome. Rome will also send its key to Londres.
• Londres starts by copying its key shown in the PGPkeys window.
• Then, Londres opens its mail browser and sends an e-mail to Rome. Londres pastes the
clipboard as the message.

• Rome did exactly the same for its part, hence Londres will receive the following message
containing Rome’s public key. There are several ways to proceed; the first is to select the text
including the beginning and the end marks.
• Once copied in the clipboard, launch the PGP key window and paste the key as shown
hereafter.
• Rome’s newly imported key should appear in this window.

• For its part, Rome has imported Londre’s public key giving an end to this so-called key
exchange process. Are you sure about the effective origin of this public key? What should be
done in order to guarantee it? Think about it!

Step 3: Certification of a partner public key

• At this stage, you have only imported a public key without defining any trust level for it. If
you are convince of its reliability you can sign it by right clicking on ROME’s key, the
following screen appears.
• Choose OK and enter the passphrase protecting your private key. Right click on your
partner’s key and select Key Properties. The following window appears thanks to which you can
set the level of trust with the button Trusted.
• Because Rome followed the same procedure for its part, crossed certification is finished now.

Step 4: Send a signed message

So that your partner can be sure of the message’s sender, we will now send him a signed message.
• Open your mail browser and write a message to your partner, i.e Rome in our case. Once
done, maintain the mail window active, right click on systray and select “sign”.
• The consequence should be the transformation of your message, as follows.

• Rome did exactly the same, hence you receive the following mail:
• You will see now how to check the validity of this signed message. To do so, select the mail
window, launch Systray / Current Window / Decrypt and Verify and the following verification
window appears.

Step 5: Send an encrypted and signed message

In this final step, we will be more practical and send an encrypted message, whose sender identity
can be checked.
• Similarly to the precedent step, open you mail browser and write a message. Check that the
window is active and right click on Systray / Current window / Encrypt and Sign. A window
appears asking you who will be the recipient. In this case, we select Rome.
• Automatically the written message is transformed as shown hereunder.

• You can now send it to your partner. He also sent you a similar message that you have to
decrypt and check.
• As you might guess, select Systray / Current Window / Decrypt and Verify / Enter passphrase.
Think about the reason why you have to enter the passphrase...The result is the following:

Step 6: PGP behavior after unexpected cleartext modifications
Now we will write and sign an Email. Before sending it to your partner, you will simulate an
unexpected content modification…
• Open your mail browser and write the message to your partner. Once done, maintain the mail
windows active, right click on systray and select sign (cf. Step 4).
• Then modify slightly the content of the cleartext

• Now you can send the modified message to your partner

• Your partner did exactly the same, therefore you receive an Email. Open it, and verify it, what
do you observe?
• Now your PGP lab is completed…

Unit 2 : PKI Applications (Lab Exercises) The SSH Protocol
2.5. THE SSH PROTOCOL
2.5.1. Introduction
As the student already knows, IP protocol does not guarantee in any aspect information security.
More precisely, this protocol doesn’t offer any authentication, privacy or integrity protection
mechanism. Moreover, due to the OSI model philosophy, all higher-level protocols are in the
same way deficient, as they usually assume the lower level can be trusted. Therefore, the need of a
security mechanism at the application level arose out of the market, in parallel to the Internet’s
success.
Such a need has been fulfilled by the SSH protocol. It provides a transport-layer encryption
mechanism offering host authentication and user authentication, as well as privacy and integrity
protection. In its most common application, it gives users secure login connections, secure file
transfer, secure X11windowing system and secure TCP/IP connection over “untrusted”
networks. SSH is a packet-based binary protocol that works on top of any transport that will pass
a stream of binary data. Normally, TCP/IP is used as the transport but the implementation also
permits to pass data to and from the server using any arbitrary proxy program to pass data to and
from a server.
Effectively, thanks to the port-forwarding technology, it is possible to forward arbitrary (almost)

insecure connections over a secure channel. To explain this, consider the client-server model:
basically, the SSH client creates a local proxy server for a remote TCP/IP service. This service can
be one of the Internet protocols (pop, smtp and http) or almost any other TCP/IP based service.
This local proxy server listens to a socket on the desired port, forwards the request and data over
the secure channel and instructs the SSH server to connect on the specified port of the remote
machine.
This might be better explained with an example: Consider three hosts, X, Y, and Z. Host X is the client
and establishes a session with Y, the server, via ssh. A port on X, say 1999 is setup to be
forwarded to another port on the remote host Z, say 23. This port is forwarded over the
encrypted tunnel to Y, which sends it then unencrypted to host Z's port 23. Thus, the command
“telnet localhost 1999” would result in a telnet connection being established with host Z, passing
over the encrypted tunnel to Y.
The SSH Protocol Figure 1: Port forwarding technology
The only noticeable change is that the client application is configured to connect to the local
proxy instead of the remote server.

The SSH Protocol Unit 2 : PKI Applications (Lab Exercises)
2.5.2. Host Authentication

As mentioned above, host authentication is one of the key features offered by the SSH protocol.
Let’s have a quick oversight of this process illustrated by the figure hereunder:
The SSH Protocol Figure 2: Host authentication
The server sends its public RSA host-key and another public RSA key called server key that
changes each hour. The client compares the received host key with its own database of known
host keys. It is our choice to accept or not the key of an unknown host before storing it inside the
database. The client generates then a 256 bits random number using a cryptographically strong
random number generator and chooses an encryption algorithm supported by the server
(normally blowfish or 3DES). The client encrypts this random number (or session key) with RSA
using both the host key and the server key, and finally sends it to the server.
The purpose of the host key is to bind the connection to the desired server host (because only the
server can decrypt the encrypted session key). The server key, which is changed every hour, makes
decryption of recorded historic traffic impossible in case the host key becomes compromised.
The host key is normally a 1024-bit RSA key and the server is normally a 768-bit. A
cryptographically strong random number generator generates both keys.
Then, the server decrypts the RSA encryption and recovers the session key. Both parties start
using the session key and the connection is now encrypted. The server sends an encrypted
confirmation to the client. A receipt of this confirmation tells the client that the server was able to
decrypt the key and therefore holds the proper private keys.
At this stage, the server machine has been authenticated and the transport-level encryption as
well as the integrity protection are in use.
2.5.3. User Authentication

The user can be authenticated by the server in several ways. The user authentication dialogue is
driven by the client who sends requests to the server. The first request always declares the
username to use for logging on. The server gives request with a “success” or “failure” response.
Then, further authentication is required: either traditional static password (the password will be
sent through the encrypted tunnel) or a pure RSA authentication. In the latter authentication
scheme, the user uses its RSA key pair to prove his identity (actually he will have to prove his
identity by using his private key).

The student should be aware that this authentication scheme has some weaknesses, this is one of
the drawbacks of SSH. However, it has been corrected in SSH2, which implements strong
authentication schemes (SecurID token etc.). Further in the course, we’ll talk about strong
authentication based on RSA keys enforced by a third party, but this is for later...
2.5.4. Cryptographic Methods

As mentioned above, for host and user authentication, SSH provides strong security using DSA
or RSA. Host and user authentication keys length is between 768 and 2048 bits long.
The server key, which changes every hour, is 768 bits long by default. It is used to protect
intercepted sessions from being decrypted, in case the host key is later compromised. This key is
never saved on the disk.
For SSH 2, key exchange is done via Diffie-Hellman key-exchange algorithm. This key exchange
transfers 256 bits of keying data to the server. Different encryption methods use different key
portions. For data encryption, Blowfish uses 128-bit keys and 3DES uses 168-bit keys.
Another fundamental aspect of security is the use of cryptographically strong random number
generators.
Hereafter you will find a table showing the ciphers used by SSH for encryption:
Cipher SSH1 SSH2

DES Yes no
3DES Yes Yes
IDEA Yes Yes
Blowfish Yes Yes
Twofish No Yes
Arcfour No Yes
Cast128-cbc No Yes
You have here a table showing the ciphers used by SSH for authentication:
Cipher SSH1 SSH2

RSA yes yes
DSA no yes

Objective
The student will learn how to use SSH to replace a standard telnet connection. In order to do so,
he will use two authentication mechanisms. The student will also learn how to setup a SSH
tunnel.
Scenario
The Management wants to implement a very secure solution to replace “telnet” for Unix station
management. They want to use a strong encryption and a strong authentication. The Management
wants also to implement a SSH tunnel to access an Intranet server from Internet
Main steps
1. Use Telnet to connect to a Linux box
2. Use SSH with standard password to connect to a Linux box
3. Use SSH with Public Key authentication to connect to a Linux box
4. Use SSH tunnel to connect to an Intranet server
Time
60 minutes

Step 1: Use Telnet to connect to a Linux box

You will use SecureCRT as emulator to perform the remote connection to the Linux box
(newton.pki.datelec.com). This emulator can use Telnet, SSH1 and SSH2. Hereafter you will find the
detailed instructions:
• Run SecureCRT.
• Choose Newton-Telnet session.
• Connect yourself to newton.pki.datelec.com using Telnet.
• Authenticate yourself to newton.pki.datelec.com using a standard username (your hostname) and a

password (abc123).
• Have a look at the instructor’s sniffer.

• What do you see?
• Now you can quit SecureCRT.

Step 2: Use SSH with standard password to connect to a Linux box

• Connect yourself to newton.pki.datelec.com using SSH2 with a standard password as
authentication.
• Run SecureCRT and choose Newton-SSH-Pass session.
• SecureCRT will ask you to accept the “newton’s public key”.

• Press Accept and Save.
• Can you affirm that this is really the “newton’s public key”?
• Think about it!
• Authenticate yourself to newton.pki.datelec.com using a standard username and a password.

• Have a look at the instructor’s sniffer.

• You can quit SecureCRT.

Step 3: Use SSH with Public Key authentication to connect to a Linux box
For this step, you will use a public key to authenticate yourself to the “newton’s Linux box”. You
will then generate a public key-pair and give the public part to the SSH2 server (“newton’s Linux
box”).
• Run SecureCRT and choose New Session.

You will define a new SSH session using a PublicKey authentication method by proceeding as
follows:
Name: Newton-SSH-key
Protocol: SSH2
Hostname: newton
Port: 22
Username: your-site (here for instance londres)
Cipher: 3DES
Mac: MD5
Authentication: PublicKey
SSH server: DataFellows 2.0.13

• SecureCRT will propose you to generate a key-pair.

• Press Yes.
• SecureCRT will generate an identity file.
• Press Create Identify File.
• Press Next in the Key Generation Wizard.

• Enter a Passphrase to protect your private key. You will use this Passphrase to lock or unlock
your private key.
• Choose the key length: here 1024 bits.
• SecureCRT will now generate the keys using the mouse movements as a seed
(Random number).

• When the generation is done press Finish.
• On your local station, go to directory c:\program file\SecureCRT 3.0\.

• With Notepad open “identity.pub”.
• Copy the public key on your clipboard.

In order to place your public key on the SSH server (newton.pki.datelec.com), proceed as follows:
• Connect yourself to newton.pki.datelec.com using SSH with standard password as authentication.
Run SecureCRT and choose Newton-SSH-Pass session.
• Go to ~/.ssh2 directory (cd .ssh2 from your home directory).
• Using “vi” create a file called “your-site.pub” (for instance londres.pub).
• Paste the public key.
• Using “vi” create and edit a file called “authorization”.

• Add the name of the public key file: Key Æ your-site.pub (Tabulation).
• The account is now ready to be accessed, using public key authentication from a client that
holds the correct identity file (containing the private and public key-pair).
• Connect yourself to newton.pki.datelec.com using SSH with Public Key as authentication.
• Run SecureCRT and choose Newton-SSH-Key session.
• Now you will be prompt to enter the Passphrase.
• Now you are ready to setup a tunnel using SSH2

Step 4: Use SSH tunnel to connect to an Intranet server

To simulate the Intranet server we will use www.cisco.com as URL.
• Run SecureCRT and choose New Session.
• You will define a new session using SSH2 and a password authentication method, by
proceeding as follows:
Name: Newton-SSH-Tunnel
Protocol: SSH2
Hostname: newton
Port: 22
Username: your-site (here for instance londres)
Cipher: 3DES
Mac: MD5
Authentication: Password
SSH server: DataFellows 2.0.13

• To configure the tunnel, go to the Advanced menu.

• Select Port Forwarding menu.
• Define tunnel parameters by proceeding as follows:
Local port: 1234
Remote hostname: www.cisco.com
Remote port: 80
• Press Save.
• Press OK.
• And press OK to terminate the session definition.
• Now connect yourself to newton.pki.datelec.com using the new session.
• Authenticate yourself with standard username and password and minimize the SecureCRT
application.
• Check if the tunnel’s entry is listening on port 1234. On Command Prompt run the command
“netstat –a” and have a look.

• Now you can test the tunnel using your browser. Run the browser with http://localhost:1234
as URL.
• Now you are finished with the SSH lab…

Unit 2 : PKI Applications (Lab Exercises) S/MIME
2.6. S/MIME
For a theoretical introduction, please refer to the book “Digital Certificates” written by Jalal Feghhi, Jalil Feghhi
and Peter Williams.
Objective
The student will setup an e-mail system using S/Mime. He will have to use Digital Signature and
Encryption. Moreover, the student will use LDAP protocol to retrieve X.509 certificates.
Scenario
The Management now wants to implement encryption and digital signature for the corporate E-
mail system. Due to management issues, all certificates are stored inside a directory server which
is requested via LDAP. You will use an internal CA and it will be Keon 5.5 from RSA Security.
Main Steps
1 Request a client certificate from a Certification Authority (CA)
2 Install on your browser the certificate sent to you by the CA
3 Send a signed e-mail to your partner
4 Send an encrypted e-mail to your partner
5 Send a signed and encrypted e-mail to your partner
6 Getting a certificate via a LDAP request
Time
45 minutes

S/MIME Unit 2 : PKI Applications (Lab Exercises)
Step 1: Request a client certificate from a Certification Authority (CA)

• Now you can enroll for a client certificate. Via the browser, connect to the Keon
Subscriber Services (http://cerbere.pki.datelec.com).
• Choose Datelec – PKI Training jurisdiction.
• Choose Enroll for a Personal Certificate.

• Enter Enrollment information:

First Name
Last Name
E-mail Address (Important)
Title
• Enter your Challenge Phrase (for revocation, etc.).
• Choose Signing and Encryption.
• And then press Accept.

• Your browser will now generate a Private key that will be stocked on the local disk.
• Enter a PIN code to protect your KEY.

• Now the enrollment is completed. Please wait in order to get your certificate. If the CA agrees
to issue a certificate for you, you will be notified by e-mail.
• Read you e-mail. You will receive a PIN number to retrieve your certificate.
• Paste your PIN number on your clipboard.

Step 2: Install on you browser the certificate sent to you by the CA

• Via the browser connect to the retrieving menu (http://cerbere.pki.datelec.com/getid.htm).
• Paste your PIN number and press Submit.

• Go to menu Security Info.

• Choose Security info / Messenger.

• Select the client’s certificate you will use for sending and signing an e-mail with S/Mime.

Step 3: Send a signed e-mail to your partner

• Choose your partner to exchange an e-mail (Example: Londres and Rome).
Note: the certificate will be exchanged the first time by sending a signed message. We will not
use a directory server LDAP to retrieve certificate. However, in a real deployment, it will work
with LDAP.
• Now you are ready to send a signed e-mail to your partner.
Note: this lab will be performed on both sites, your partner will also send you a signed e-mail.
• Send e-mail with option Signed.

• Get Message and read the signed mail from your partner.
• You will see a “Signed” icon on the mail.
• To verify, click on the “Signed” icon. You will be able to identify the sender.
• Now you can reply to the sender with an encrypted e-mail.

• To view the sender’s Certificate, click to “View/Edit” button.
• Note: the sender’s certificate has automatically been added to your list of People’s Certificates, in
order to make it possible for you to send a secure mail to this person.

Step 4: Send an encrypted e-mail to your partner

• Now you are ready to send an encrypted e-mail to your partner.
Note: this lab will be performed on both sites, your partner will also send an encrypted e-mail
to you.
• Send e-mail with option Encrypted.

• Get Message and read the encrypted mail from your partner.
• You will see an “Encrypted” icon on the mail.

• To verify, click on the “Encrypted” icon. You will see what algorithm is used for the
encryption (168 bits DES).

Step 5: Send a signed and encrypted e-mail to your partner

• Now you are ready to send an encrypted and signed e-mail to your partner.
Note: this lab will be performed on both sites, your partner will also send an encrypted and
signing e-mail to you.
• Send e-mail with option Encrypted and Signed.

• Get Message and read the encrypted and signed mail from your partner.
• You will see a “Encrypted and Signed” icon on the mail.

• To verify, click on the “Encrypted and Signed” icon. You will see what algorithm is used for
the encryption (168 bits DES) and the signature information.

Step 6: Getting a certificate via a LDAP request
• Choose Security info/ Other people’s certificates
• You will now send your LDAP request by selecting Search Directory. Select the Datelec directory
server and enter the Email address of the partner whose certificate you want to obtain.
• Note: the sender’s certificate has automatically been added to your list of People’s Certificates in
order to make it possible for you to send a secure mail to this person. Repeat this step for all
your partners and try to send encrypted/signed Email
• You just finished your S/MIME, congratulations!

Unit 2 : PKI Applications (Lab Exercises) SSL (Secure Socket Layer)
2.7. SSL
2.7.1. History
The SSL protocol was designed by Netscape Communications for use with Netscape Navigator.
The version 1.0 of the protocol was used with Netscape and the version 2.0 with Navigator
Versions 1 and 2. After SSL 2.0 has been published, Microsoft created a similar secure link
protocol called PCT (Private Communications Technology) that overcame some of SSL 2.0’s
shortcoming. The progresses of PCT were incorporated into SSL 3.0, which is being used as the
basis for the secure protocol being developed by the IETF (TLS).
2.7.2. Secure Sockets Layer (SSL)

The Secure Sockets Layer protocol is a protocol layer, which may be placed between a reliable
connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g.
HTTP). SSL provides for secure communication between client and server, by allowing mutual
authentication, the use of digital signatures for integrity and encryption for privacy.
The protocol is designed to support a range of choices for specific algorithms used for
cryptography, digests, and signatures. It allows use of algorithm selection for specific servers,
based on legal, export or other concerns, and also enables the protocol to take advantage of new
algorithms. Choices are negotiated between client and server while starting to establish a protocol
session.
SSL Table 1
There are a number of versions of the SSL protocol, as shown in Table 1. As noted there, one of
the benefits in SSL 3.0 is that it adds support for certificate chain loading. This feature allows a
server to pass a server certificate along with issuer certificates to the browser. Chain loading also
permits the browser to validate the server certificate, even if Certificate Authority certificates are
not installed for the intermediate issuers, since they are included in the certificate chain. SSL 3.0 is
the basis for the Transport Layer Security [TLS] protocol standard, currently in development by
the Internet Engineering Task Force (IETF).

SSL (Secure Sockets Layer) Unit 2 : PKI Applications (Lab Exercises)
2.7.3. Session Establishment

The SSL session is established by following a handshake sequence between client and server, as
shown in Figure 1. This sequence may vary, depending on whether the server is configured to
provide a server certificate or request a client certificate. Although cases exist, where additional
handshake steps are required for management of cipher information, this article summarizes one
common scenario: see the SSL specification for the full range of possibilities.
Note:
Once an SSL session has been established it may be reused, thus avoiding the performance
penalty of repeating the many steps needed to start a session. This is the reason why the server
assigns to each SSL session a unique session identifier. This one is cached in the server and usable
by the client on forthcoming connections to reduce the handshake (until the session identifier
expires in the server’s cache).
SSL Figure 1
The elements of the handshake sequence, as used by the client and server, are listed below:
1. Negotiate the Cipher Suite to be used during the data transfer

2. Establish and share a session key between client and server
3. Optionally authenticate the server to the client
4. Optionally authenticate the client to the server

The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite
supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A
Cipher Suite is defined by the following components:
1. Key Exchange Method

2. Cipher for Data Transfer
3. Message Digest for creating the Message Authentication Code (MAC)
These three elements are described in the following sections.
2.7.4. Key Exchange Method

The key exchange method defines how client and server will agree upon the shared secret
symmetric cryptography key, used for application data transfer. SSL 2.0 uses RSA key exchange
only, while SSL 3.0 supports a choice of key exchange algorithms including the RSA key exchange
when certificates are used, and Diffie-Hellman key exchange for exchanging keys, without
certificates and without prior communication between client and server.
One variable in the choice of key exchange methods is digital signatures : whether or not to use
them, and if so, what kind of signatures to use. Signing with a private key provides assurance
against a man-in-the-middle-attack during the information exchange used in generating the shared
key.
2.7.5. Cipher for Data Transfer

SSL uses the conventional cryptography algorithm (symmetric cryptography) described earlier for
encrypting messages in a session. There are nine choices, including the choice to perform no
encryption:
1. No encryption
Stream Ciphers
2. RC4 with 40-bit keys
3. RC4 with 128-bit keys
CBC Block Ciphers
4. RC2 with 40 bit key
5. DES with 40 bit key
6. DES with 54 bit key
7. Triple-DES with 168 bit key
8. Idea (128 bit key)
9. Fortezza (96 bit key)
• "CBC" refers here to Cipher Block Chaining, which means that a portion of the previously
encrypted cipher text is used in the encryption of the current block.
• "DES" refers to the Data Encryption Standard, which has a number of variants (including
DES40 and 3DES_EDE).
• "Idea" is one of the best and cryptographically strongest available algorithms.
• "RC2" is a proprietary algorithm from RSA DSI.

2.7.6. Digest Function

The choice of digest function determines how a digest is created from a record unit. SSL supports
the following:
• No digest (Null choice)

• MD5, a 128-bit hash
• Secure Hash Algorithm (SHA-1), a 160-bit hash
The message digest is used to create a Message Authentication Code (MAC), which is encrypted
with the message to provide integrity and to prevent replay attacks.
2.7.7. Handshake Sequence Protocol

The handshake sequence uses three protocols:
• The SSL Handshake Protocol for performing the client and server SSL session establishment.
• The SSL Change Cipher Spec Protocol for actually establishing agreement on the Cipher Suite
for the session.
• The SSL Alert Protocol for conveying SSL error messages between client and server.
These protocols, as well as application protocol data, are encapsulated in the SSL Record
Protocol, as shown in Figure 2. An encapsulated protocol is transferred as data by the lower layer
protocol, which does not examine the data. The encapsulated protocol has no knowledge of the
underlying protocol.
SSL Figure 2
The encapsulation of SSL control protocols by the record protocol means that if an active session
is renegotiated, the control protocols will be transmitted securely. If there was no session before,
the Null cipher suite is used, which means that there is no encryption. Moreover, messages have
no integrity digests until the session has been established.

2.7.8. Data Transfer

The SSL Record Protocol, shown in Figure 3, is used to transfer application and SSL Control data
between the client and the server, fragmenting possibly this data into smaller units, or combining
multiple higher level protocol data messages into single units. It may compress, attach digest
signatures and encrypt these units before transmitting them using the underlying reliable transport
protocol (Note: all major SSL implementations lack currently support for compression).
SSL Figure 3
One common use of SSL is to secure Web HTTP communication between a browser and a
webserver. This case does not preclude the use of non-secured HTTP. The secure version is
mainly plain HTTP over SSL (named HTTPS), but with one major difference: it uses the URL
scheme https rather than http and a different server port (by default 443).

Objective
The student will setup a SSL web server using Netscape Enterprise Server.
Scenario
The Management wants to implement an intranet server using SSL for your enterprise. You will
use an internal CA to certify this Intranet server.
Main steps
To enable SSL on your server, you must complete the following steps:
1. Generate your server’s key-pair file (public and private keys)

2. Request a certificate from a Certification Authority (CA)
3. Install the CA certificate that has been sent to you
Time
1 hour

Unit 2 : PKI Applications (Lab Exercises) SSL (Secure Sockets Layer)
Step1: Generating a key-pair-file

A key-pair file contains the public and private keys used for SSL encryption. You use the key-pair
file when you request and install a certificate. The key-pair file is stored encrypted in the directory
<server_root>/alias/<alias>-key.db. When you create the key, you have to specify a password that
will be used later while starting a server using encrypted communications.
• Go to the <server root>/bin/admin/admin/bin directory.

• Run the sec-key.exe application. The key-pair file generation program appears.
• When prompted, type an alias for the new key-pair file. You may choose an alias that matches
your server (for instance, web or mail). The alias cannot contain spaces, but it can use symbols
that your operating system accepts in filenames (such as hyphens and underscores).

• A screen with a progress meter appears. Move your mouse in random motions at random
speed. These random movements are used to generate a random number for the unique key-
pair file.
• When prompted, type an eight-character (or more) password for your key-pair file. The
password must have at least one non-alphabetical character (a number or punctuation mark).
Make sure you memorize this password. The security of your server is only as good as the
security of the key-pair file and its password. After you turn on “SSL for a server” (either the
administration server or another Netscape server), you must type the key-pair file password
when you start the server.
• Retype the password and click OK. The file is created and stored.

• Return to the Server Manager forms (http://yoursite:6969).

• Enter username admin and password abc123.

• Go on Request Certificate menu.

• After you generate a key-pair file, you can request a certificate from a Certification Authority
(CA). In the Server Administration page, choose Keys & Certificates / Request Certificate.
• In the form that appears, specify if you want a new certificate or a renewal.
• Specify how you want to submit the request for the certificate. In your case it will be by mail
at: kcserver@pki.datelec.com.
• From the drop-down list, select the alias for the key-pair file you want to use when requesting
the certificate.
• Type the password for your key-pair file. The server uses the password to get your private key
and encrypt a message to the CA. The server then sends both your public key and the
encrypted message to the CA. The CA uses the public key to decrypt your message.
• Type your identification information. The format of this information is variable from one CA
to the other.
Here is an example:
Requestor Name: Sylvain Maret
Telephone number: +41 22 708 15 80
Common name: londres.pki.datelec.com (very important: enter your site!)
Email address: londres@pki.datelec.com (enter your email address)
Organization: Datelec (very important)
Organizational unit: PKI Training (very important)
Locality: Geneva
State or Province: GVA
Country: CH
NB: Print screen on top of following page


• If every field is all right, press OK.

• Copy the Certificate request on the clipboard to submit the request to the CA. In the present
case you will use an internal CA that will be Keon.

Step 2: Request a certificate from a Certification Authority (CA)

• Now, you are ready to submit the request to the certificate server (Keon). Via the browser,
connect to the Keon Subscriber Services (http://cerbere.pki.datelec.com).
• Choose PKI Training jurisdiction – Datelec.

• Choose Enroll for a server Certificate.

• Then, paste the Certificate Signing Request (CSR) from the Netscape server on the Keon
Enrollment.
• Press submit.

• You can read now the CSR information and control it.
• Then, enter your First Name, Last Name and your e-mail Address (your-site@pki.datelec.com).
• Enter a Challenge Passphrase. This phrase can for instance be used later for revocation.
• If you want, you can enter some comments for the CA (security officer).
• Press Submit.

• If the CA agrees to issue a certificate for you, you will be informed by e-mail.

• Read you e-mail, you should receive the X509 certificate from the CA (Keon).

Step 3: Install the CA certificate that has been sent to you

• Now you are ready to install the certificate on the Netscape server.
• In the Server Administration page, choose Keys & Certificates / Install Certificate.
• Choose This Server under Certificate For.
• Paste the e-mail text in the field called Message text. Be sure to include the headers "Begin
Certificate" and "End Certificate." Do not forget to check the corresponding button for either
the file or the text.
• From the drop-down list, select the alias you used when you requested the certificate. If you
choose the incorrect alias, the certificate will not be installed.

• Click OK. Another form appears asking if you want to add the certificate. Click the Add
button. The certificate is stored in the directory “<server _root>/ alias”.
The file name will be <alias>-cert.db. For example, if your alias is Intranet, the file will be
intranet-cert.db.
• Now you can activate SSL for your server.

• Select Server Administration. (Very important!)

• Select your web site, in Server Preferences menu choose Encryption On/Off. The Encryption On/Off
form appears.
• Check the On button.
• In the drop-down list, choose the alias for the key-pair file and certificate file that you want to
use. You must know the password for the key-pair file referenced by this alias. It is the
password you must enter before starting or stopping a server that uses SSL encryption.

• Press Save and Apply Changes.

• The server will restart and you have to enter the password.
• Now you are ready to test the SSL web server. With your broswer connect to
https://you-site.pki.datelec.com.
• To see info on Netscape, go to Security Info menu.

• Go to Open Page Info.

Objective
Student will setup a SSL client authentication to protect the access to Intranet server.
Scenario
The Management wants now to implement a strong authentication based on SSL client certificate
to be able to access the Intranet.
Main Steps
To enable SSL authentication on your server, you must complete these steps:
1. Import CA’s root certificate on the web server

2. Configure the web server to ask a client SSL certificate for authentication
3. Request a client certificate from a Certification Authority (CA)
4. Install on your browser the CA certificate that has been sent to you
Time
1 hour

Step 1: Import CA’s root certificate on the web server

In order to be able to verify the client certificate, the web server has to know the root certificate
who deliver the client certificate. In this case it will be the internal CA Keon.
• Go to the Subsciber Services to pick up the Keon’s root certificate. Choose Menu Trusted Root
Services / View Server Trusted Root (http://cerbere.pki.datelec.com).

• Copy this certificate on your clipboard.

Step 2: Configure the web server to ask client SSL certificate for authentication
• In the Server Administration page, choose Keys & Certificates / Install Certificate.
• Choose Certificate For / Trusted Certificate Authority (CA).
• Paste the Keon’s roots certificate in the field called Message text. Be sure to include the headers
"Begin Certificate" and "End Certificate." Do not forget to check the corresponding button
for either the file or the text.
• From the drop-down list, select the alias you used when you requested the certificate. If you
choose the incorrect alias, the certificate will not be installed.
• Press OK.

• Another form appears asking if you want to add the certificate. Click the Add button. The
certificate is stored in the directory <server_root>/alias. The filename will be <alias>-cert.db. For
example, if your alias is intranet, the file will be intranet-cert.db. Now you can activate SSL for
your server.

• In Server Administration select your site and choose Server Preferences and Admin Preferences
/Encryption Preferences. Under Require Client Certificates choose Yes.
• Press OK and save.
• Enter a password.
• Now the web server SSL is ready to ask client authentication to access to web pages.

Step 3: Request a client certificate from a Certification Authority (CA)

• Now you can enroll for a client certificate. Via the browser, connect to the Keon Subscriber
Services (http://cerbere.pki.datelec.com).
• Choose Datelec – PKI Training under Jurisdictions.

• Choose Enroll for a Personal Certificate.

• Enter the following Enrollment Information :

First Name
Last Name
Email Address (Important)
Title
• Enter your Challenge Phrase (for revocation, etc.).
• Choose Signing and Encryption.
• Press Accept.

• Now your browser will generate a Private key. This key will be stocked on the local disk.
• Enter a PIN code to protect your KEY.

• Now the enrollment is completed. Wait until you get your certificate. If the CA agrees to issue
a certificate for you, the CA will inform you by e-mail.

• Read you e-mail. You will receive a PIN number to retrieve your certificate.
• Paste your PIN number on your clipboard.

Step 4: Install the certificate the CA send to you on your browser

• Via the browser, connect yourself to the retrieving menu
(http://cerbere.pki.datelec.com/getid.htm).
• Paste your PIN number and press Submit.

• Wait until you get the message shown hereafter.

• Your client certificate is now ready.
• You are ready to test the SSL web server. With your browser, connect yourself to
https://you-site.pki.datelec.com.
• Your browser will ask you a client certificate to authenticate yourself.
• Select your certificate.
• Enter your PIN code to unlock the private key.

• Now you are authenticated and connected to your SSL web site
• To see your client certificate, Go to the Security Info menu.
• Choose Certificates / Yours.

• Then, choose View.
• Now, you are finished…

Smart Card Unit 2 : PKI Applications (Lab Exercises)
2.8. SMART CARD
Objective
Student will install a smartcard reader on his personal computer. This smartcard will be used in
next labs.
Scenario
The Management wants now to implement a corporate extranet solution. The content of the
extranet being highly sensitive, the top management wants the authentication to be based on
smartcards.
Main Steps
To activate the smartcard reader on your PC, follow these steps:
1. Installation
2. Verification
3. our browser the CA certificate that has been sent to you
Time
15 minutes
Step 1: Installation
• Your reader is physically connected to your PC through the serial interface. In c:\smartcard
double click setup.exe and choose following options
• Then Choose COM1…

Unit 2 : PKI Applications (Lab Exercises) Smart Card
• Finish the installation by restarting the computer and then choosing to install the security
module on netscape.
• Close netscape in order to load your environment
Step 2: Verification
• Launch Netscape browser, select Security / Cryptographic module following content should
appear
• Smartcard installation done!

•

Playing the Security Officer Unit 2 : PKI Applications (Lab Exercises)
2.9. PLAYING THE SECURITY OFFICER
Objective
Student will request a certificate that will be stored on smartcard. The student will carry the
security engineer task to validate his certificate request
Scenario
Same scenario as lab exercise 9
Main Steps
1. Certificate enrollement
2. Security engineer validates the certificate request
3. Pushing the certificate on the smartcard
Time
30 minutes
Step 1: Certificate enrollement
• Connect to http://cerbere and follow almost the same procedure as in S/MIME lab. The
only difference appears when Keon triggers Netscape RSA key pair generation. You have now
the choice between storing the key material in smartcard container or in netscape software key
container. Select ActivCard module
• Enrollement is now finished

Unit 2 : PKI Applications (Lab Exercises) Playing the Security Officer
Step 2: Security engineer validate the certificate request
• Connect to CA admin page (https://cerbere.pki.datelec.com:445/home.htm) using your x.509

digital ID to authenticate yourself as a security officer.
• Choose certificate management/ process request you should see your own certificate request waiting
to be validated
• Click on approve and you see the acknowledgment

• Note: don’t close the Netscape browser before next step

Playing the Security Officer Unit 2 : PKI Applications (Lab Exercises)
Step 3: Pushing the certificate on the smartcard
• Open your netscape messenger and connect to the certificate retrieval page using the PIN
received by mail
• Choose continue and it will install the certificate on your smartcard
• Now you are ready to proceed to next lab

Unit 2 : PKI Applications (Lab Exercises) Revocation with client SSL authentication
2.10. REVOCATION WITH CLIENT SSL AUTHENTICATION
Objective
Use the key material stored on smartcard to authenticate the access to extranet. Certificate validity
is checked against a CRL repository.
Scenario
Your management wants to provide revocation mechanism in order to guarantee high security
access that fits to the corporate structure.
Main Steps
1. Connect and authenticate yourself using your smartcard
2. Play the security officer revoking a certificate
3. Try again and interpret the experience
Time
30 minutes
Step 1: Connect and authenticate yourself using your smartcard
• Connect to extranet server https://ayrton.datelec.ch

• enter pin code to unlock your smartcard
• Choose your certifcate
• You’ve authenticated successfully against the server

Revocation with client SSL authentication Unit 2 : PKI Applications (Lab Exercises)
Step 2: Play the security officer revoking a certificate
• Connect to CA admin page (https://cerbere.pki.datelec.com:445/home.htm) using your x.509

digital ID to authenticate yourself as a security officer.
• Choose certificate management/revoke certificate you should see the following window

Unit 2 : PKI Applications (Lab Exercises) Revocation with client SSL authentication
• You can select one of the certificates and revoke it by choosing revoke. A revocation reason is
required

Revocation with client SSL authentication Unit 2 : PKI Applications (Lab Exercises)
• Press revoke and the following window should appear; read carefully the message…
• Ask the CA’s super-administrator to force the immediate handling of your revocation on the CA
and extranet application. Once done, try again and your access should be revoked.

Unit 2 : PKI Applications (Lab Exercises) IPSEC
2.11. IPSEC
2.11.1. Introduction
As the reader will understand at the sight of such a chapter name, IPSec’s goal is to provide a
protocol to Secure IP protocol. More precisely, it is to provide both integrity and confidentiality
of IP packets.
Before entering into the details of the IPSec structure, let us recall an old drawing of different
security schemes for different level of IP datagram.
IPSec Figure 1: Encryption and OSI layer
Basically, IPSec will deal with IP datagram encapsulation inside IPSec packets, hence it will
provide security to network layer. The idea in this picture is that the further down you go, the more
transparent you are and the further up you go, the easier it is to deploy. Hence, IPSec will be the
most transparent PKI based solution that we’ll talk about in this lecture. In fact, for some people
IPSec might not be part of PKI as for others it would.
For us, PKI is some kind of generic expression to be understood as a set of components bringing
authenticity and confidentiality to traffic or message sent across an untrusted backbone (internet
is only an example). Consequently, IPSec will deal with exactly the same concept we defined
above: symmetric encryption, public/private keys, hash functions, x.509 certificates, CA, key
exchange, etc. This chapter will try to show the student how to integrate these tools to provide
confidentiality, authenticity and non-repudiation to network layer…

IPSEC Unit 2 : PKI Applications (Lab Exercises)
2.11.2. IPSec Architecture

The IPSec is defined by people of a working group being part of the “Internet Engineering Task
Force” (IETF). The definition of the protocol is summarized into around 15 RFCs. We will try to
concentrate their contents into the most easily digestible form as possible.
First of all, let us start by an IPSec oversight showing the relationship between the different
subsets of IPSec.
IPSec Figure 2: IPSec components and their interaction
First of all, the drawing shows that IPSec is based on two main protocols (or sub-protocols), ESP
(Encapsulation Security Payload) and AH (Authentication Header). The reason is that
IPSec has two main requirements: provide “confidentiality” as well as data “integrity”.
Confidentiality is achieved by ESP protocol and integrity can be achieved either by ESP or AH
protocols. To achieve their task, these protocols used define-as-standard algorithms like DES,
3DES or Blowfish for encryption and MD5, SHA1 for authentication via message digest.
As we already saw, these algorithms are binded to keys (session keys, private and public keys),
which are handled (or even defined) after a key management process. IKE (or Internet Key
Exchange) protocol is the chosen standard for IPSec key management. However, IKE is not
dedicated to IPSec hence is generic enough to be implemented as a support for many protocols
(SSH, SSL, OSPF etc…). Consequently, the presence of a Domain Of Interpretation (DOI) is
needed in order to define the parameters that are negotiated by IKE. Besides, another component
is needed in order to determine if two entities have the right to communicate and if so, the kind
of encryption algorithm or hash function to agree with this component called Policy.

2.11.3. IPSec Tunneling

AH and ESP can be used to protect either the entire IP datagram or only the payload (data). In
IPSec this is translated by the existence of two different modes, the tunnel mode and the
transport mode. In transport mode, an IP header is inserted between the IP header and the
upper-layer protocol headers, as shown here under:
Original IP packet IP header tcp header Data
Transport mode IP header IPsec header tcp header Data
In tunnel mode, the entire IP packet is encapsulated in a new datagram with a new IP header. An
IPSec header is added in between the encapsulation and the new header, as shown hereunder:
Tunnel mode IP header Ipsec header IP header tcp header Data
Transport mode and tunnel mode are both possible with ESP and AH. It is however important to
precise that, due to its construction, transport mode can be used only to protect IP packet where
the communication endpoints are the encryption endpoints as well. Therefore, tunnel mode is
often preferred. Moreover, it offers the possibility to provide security services for other network
entities. This last remark is very relevant because it justifies IPSec as being a major component in
the construction of VPNs (Virtual Private Networks).
The need of building secure and transparent communication channels, in order to privatize a
public or untrusted IP network (as for example the internet), sets IPSec tunneling as a powerful
tool to accomplish this task. Effectively, as described hereunder, placing IPSec gateways at the
endpoints of an untrusted network like the Internet, offers a secure channeled communication
solution.

IPSec Figure 3: IPSec based VPN
In this drawing, the importance of a certified tunnel is shown.
Students should be aware that other protocols like PPTP (Point to Point Tunneling Protocol) or
L2TP (Layer 2 Tunneling Protocol) offer only tunneling, compared to IPSec that offers
encryption, authentication as well as tunneling. This is the reason why we think that it is less likely
that IPSec fall into an eventual dying standard category.
SA (Security Associations)
Before going deeper into AH and ESP protocols, we want to define the SA concept, which will
be very often referred to when talking about IPSec…
The goal of Security Associations (SA) is to maintain the agreements that enable two parties to
exchange secure data. Each connection between two security gateways will require a unique SA.
An exchange between two peers that involves both authentication and encryption requires two
Security Associations, one for agreements regarding authentication and one for agreements about
the encryption. As negotiation always precedes agreements, SA needs to be negotiated between
gateways. For example one might have a gateway able to perform DES and Blowfish encryption,
as another might be able to run only DES algorithm, hence the negotiation will reach the
agreement of using DES encryption. In order to be quantified, all SAs are indexed or identified by
a number called the Security Payload Index (or SPI) which will appear in the IPSec headers.

Security Associations are set up between pairs of communicating hosts. These SAs contain the
agreements that are specific to the transfer of data between the two parties. These specific
agreements do not apply to communication that may take place with any other party. Each
Security Association maintains agreements about shared session keys, the IP addresses of the pair
of IPSec compliant gateways, the IP addresses of protected hosts or subnets, and related
parameters regarding the expiration of session keys (i.e., when the session keys must be re-
generated). Once the session keys reach a defined expiration time, a new Security Association
must be established, thereby ensuring on going SA (or Security Associations).
AH
As we saw already, AH is the protocol that will provide authentication and data integrity but will
not provide data confidentiality. Hence, the header will be quite simple and no field of this header
will be in clear or plaintext form. AH is a new IP protocol whose value are 51.
The AH header contains a SPI to define the SA with which the packet is processed and a data
authentication field. To understand how to process such an authentication let us recall that until
now, we have bound authentication to a digital signature concept. In the case of IP packet
authentication, it would not be reasonable to proceed that way because processing public key
algorithm is very CPU demanding.
A simple way to proceed could be to process the whole IP datagram into a hash function and
define the resulting message digest as the authentication packet (hash functions are not much
CPU consuming…). This might sound as an interesting workaround but as the student should
know at this step of the lecture, performing hash doesn’t provide a real authentication. Effectively
any eventual eavesdropper could change the IP datagram, reapply the hash and replace the
authentication packet with this message digest!

Both peers could use the hashing mechanism together with some secret they share…This is called
key hashing and is used to generate message authentication code (or MAC). Let us recall once again the
MAC process:
IPSec Figure 4: MAC
The idea here is to add a p

reshared key to a stream of data (for example an IP datagram), the result is a new stream of data.
Then it goes through a hash function and the resulting message digest is the MAC. The MAC and
the SPI will form the AH header. The remote IPSec gateways verify authenticity and integrity of
the IP datagram simply by processing it with his secret key (supposed to be the same) into the
hash function. In this case, an eavesdropper couldn’t reproduce the MAC because he is not
supposed to hold the secret key.
Note: Despite the similarity, MAC is conceptually very different from digital signature. For
example, digital signature (based on public key cryptosystem) offers non-repudiation, which is not
the case with MAC.
IP header AH header tcp header Datas
IPSec Figure 5: An AH protected packet
A special kind of MAC is called HMAC. Without giving details, it is basically a keyed hash inside a
keyed hash, in order to enforce the MAC concept. Practically, HMAC are used to generate IPSec
Authentication Headers. In term of policy definition they appear as HMAC-SHA1 or HMAC-
MD5 etc.
ESP
ESP is the IPSec protocol to provide confidentiality, data integrity and data source authentication
of IP packets. It does so by inserting a new header after an IP header and before the data to be
protected.
Encrypted
IP header ESP header Protected ESP trailer

data
Authenticated
IPSec Figure 6: An ESP protected packet

Since ESP provides both confidentiality and authentication, its SAs contains the cipher and the
authenticator. We can see the ESP header as the AH header plus data specific to the encryption
part. It is possible for an ESP header to have a null cipher or a null authenticator but it is illegal
for both to be set as null!
The ESP header is not encrypted, this is because it contains for example the SPI which, together
with source/destination IP, identify the SA and by consequence the cipher needed to decrypt
cipherdata. In addition, sequence number and authentication data are in clear, this is due to the
order of processing ESP packets: first check the sequence number, then data integrity and finally
decrypt data. Contrarily to the header, the ESP trailer can be partly encrypted as long as enough
information is kept clear to allow the packet to be processed.
IKE
An important process in IPSec is key management. IPSec supports both manual exchanges of
keys (e.g., telling the other party verbally or delivering a written copy) as well as automatic key
exchange using IKE.
IKE is designed to provide:
• The means for parties to agree on which protocols, algorithms and keys to use.
• Confirmation that the party you are communicating with is in fact who they say they are.
• Management of keys after they have been agreed upon
Automatic key management is the procedure that generates the session keys that are used by
certified peers for encrypting and authenticating data packets. Key management can be performed
automatically whenever data is transferred to a new trusted peer, and as an ongoing process to
ensure that session keys are changed regularly.
Each side of a communication needs to generate unique pairs of shared session keys between
itself and the party it wants to communicate with. One key is used for data encryption, and the
other key is used for data Authentication (see keyed MAC described above). Encryption is
performed using an agreement upon algorithm, such as DES. Authentication may be performed
using one of several standard message digest algorithms – HMAC-MD5 etc.
All the essential information required for this communication is defined within a SA. This
includes the shared session keys, the IP addresses of participating IPSec compliant gateways, the
IP addresses of the protected hosts or subnets, and other important related parameters (such as
how often to change the keys). A distinct Security Association is created for each pair of
protected hosts or subnets. A pair of session keys is unique to a pair of protected hosts or
subnets. The pair of keys is also unique to the direction of the data flow. For data that is sent
from one IPSec gateway to another, a unique pair of session keys is required. If the other gateway
needs to send data to the first, another unique pair of session keys is required. In other words,
only one device can use a unique session key for data encryption, while the other device in the
pair uses that same key for decryption. Thus, a single session between two hosts or subnets may
involve four keys.

2.11.4. IKE Main Mode and Quick Mode

Once communication has been established between two IPSec compliant security gateways, the
key exchange process must be properly managed for continuing security. The security device that
decrypts incoming data, initiates the key management process with the security device that
encrypts the data, whenever the session keys are close to an agreed upon expiration time. The key
management protocol used by IPSec is composed of two stages. The first stage, called ‘IKE main
mode’, generates the Security Association that is used for the protection of the second stage
exchanges. The Security Association, created by IKE main mode, is called IKE SA. An IKE SA is
created between two security gateway devices.
Whenever this SA expires, a new IKE main mode is initiated by the device that detected the
expiration. The second stage of key management is called ‘IKE quick mode’. This stage generates
a security association that is used for the tunnel creation. A distinct tunnel is created for each pair
of protected hosts or subnets. Several IKE quick modes, for several hosts or subnets pairs, can be
protected by a single IKE SA. Key exchange is performed to generate a single, unique secret that
is shared by the participating pair of IPSec compliant gateways. In the main mode, keys for the
protection of the quick mode are generated. In the quick mode, two pairs of shared session keys
are derived from the shared secret, one for sending and the other for receiving. A number of
different session keys can be derived from one shared secret.
IKE main mode

The IKE main mode process comprises three phases (each phase consists of two messages):
1. Cookie and SA Proposal Exchange

2. Diffie-Hellman Exchange
3. Authentication Information Exchange
Cookie and SA proposal exchange

The Cookie Exchange, the first phase of the IKE main mode, prevents an IPSec compliant
gateway from initiating the key management process with an unrecognized party. The Cookie is a
token that is derived from the gateway’s IP address and generated by each gateway by hashing
together a unique secret (the peer’s identity) and a time-based counter (for the casual observer, it
will look like a random number). Verification of the cookie ensures that the key management
process is taking place within the appropriate session, with the correct peer. Thus, cookie
exchange provides some kind of limited denial of service attack. With the initiator cookie, an SA
(Security Association) proposal is sent. This proposal contains the IKE SA parameters suggested
by the initiator (such as the encryption and authentication algorithms, lifetime of this SA, etc.).
Diffie-Hellman exchange
The Diffie-Hellman Exchange phase generates the shared secret from which the symmetric IKE
keys are derived. Both peers are involved in this process. The devices generate the Diffie-Hellman
components using a real random number generator. Each IPSec compliant device generates a part
of the shared secret and sends a copy of it to the other device. Each device combines its own
number with the number received. By the end of the Diffie-Hellman exchange, both devices
possess a single, unique shared secret.

The benefit of Diffie-Hellman is that it prevents a physical key exchange, moreover if an

eavesdropper intercept any parameters exchanged, he can’t deduce shared secret (For a complete
description algorithm, refer to the book “Applied Cryptography” by B. Schneier, referred in the
Bibliography).
Authentication information exchange

The last phase of the IKE main mode is used to authenticate the whole exchange. The security
device can use two optional authentication methods; either pre-shared secret authentication, or
RSA signature authentication. When the first method is used, the shared secret, created in the
previous stage, the pre-shared secret (that is entered by the user from the management station),
and some other data, are signed by both sides, using a hash algorithm (such as MD5). The IKE
SA can be used only after both sides verify the signature of the other side. When the second
method (RSA signatures) is being used, each side signs the shared secret created in the previous
phase, and some other data, using its private RSA key. The signature is verified by each side using
the other side’s public RSA key. As we saw in the previous chapters, this process requires the
presence of a Cerificate Authority certifying the identity of a public key holder (X.509 certificates).
IKE quick mode (or Aggressive Mode)

The IKE quick mode process comprises three messages:
1. SA Proposal
2. SA Response
3. SA Acknowledgment
SA proposal
This message comprises the parameters of the tunnel protection, proposed by the initiator
(algorithms, lifetime, etc.), the IP address of the host or the subnet that will use this tunnel, and an
optional Diffie-Hellman component. Enhanced security can be obtained by using the ‘Perfect
Forward Secrecy’ option, which prevents any association between successive session keys. This
may, however, affect the key exchange performance, as each exchange will take longer. ‘Perfect
Forward Secrecy’ means that the optional Diffie-Hellman component will be sent.
SA response
This message comprises the parameters of the tunnel protection selected by the responder
(algorithms, lifetime, etc.) and the IP address of the host or the subnet that will use this tunnel. If
the SA proposal contains a Diffie-Hellman component, the SA response also contains a Diffie-
Hellman component. If Diffie-Hellman is used, both sides generate a shared secret using Diffie-
Hellman, like they did in the main mode. Otherwise (if not in perfect forward secrecy), a new
shared secret is derived from the Diffie-Hellman shared secret generated in the first stage. The
message is signed digitally, in a similar way to that described in the Authentication Information
Exchange phase of the main mode. The initiator sets the tunnel after sending this message. (Refer
to the book “Applied Cryptography” by B. Schneier, mentioned in the Bibliography for a description of
the algorithms).

SA acknowledgment
This message is used to acknowledge to the responder that the initiator indeed accepted its
response. This message is also digitally signed. The responder sets the tunnel only after verifying
this message.
Determining the rate of changing keys

Though it is difficult to do, the session keys used for encrypting and authenticating data can be
guessed by an unauthorized party, damaging the data’s security. Thus, the more frequently a key is
changed, the less data will be compromised if the key is discovered. The frequency of changing
keys may be determined by time intervals or traffic volume. The user determines when new keys
are changed (i.e., when a new quick mode is initiated). The IPSec compliant security gateways
determines when to initiate the entire key management process (i.e., initiate a new main mode).
Summary
IPSec offers a “layer 3” solution to data privacy being network, application independent and
supporting all IP services. IPSec mechanisms are using Diffie-Hellman to deliver secret keys,
public key cryptosystem for signing Diffie-Hellman exchanges, symmetric encryption for
encrypting data and digital certificates cryptosystem for validating public keys. We can consider
IPSec as a condensed of all 3 cryptosystems described in this lecture tightly bound to IP standard.
Thus it is likely for IPSec to become a widely used protocol in the years to come…

Objective
The student will setup an IPSEC link between a client and an IPSec gateway (FW-1/VPN-1
Checkpoint). He will use IKE protocol for key management and a two factor authentication
based on X.509 certificate.
Scenario
The Management wants to build a VPN between remote users and a central site protected by a
Firewall/IPSec gateway. Due to server heterogeneity, corporate decision was to privilege an
IPSec-based solution rather than SSL.
Main steps
1. Configuration of Firewall (done by instructor)
2. Securemote installation
Time
1 hour 30
Step 1: Configuration of Firewall (instructor)
• Create a CA server of type: OPSec PKI, choose LDAP Server for CRL retrieval and
deactivate http
• Bootstrap Firewall with Root CA certificate
• Create LDAP account unit (cerbere, LDAP rights Read)
• Firewall Enrollment (DN: CN=IP address), copy CSR and paste on cerbere
• Certificate stored in .cert file and imported in firewall
• Edit Firewall object/vpn IKE edit and choose public key signature, configure and choose my-
cert.
• Edit Firewall object/vpn FWZ, Generate Diffie-Hellman
• Manage users and create generic* with IKE encryption and public-key authentication
• Add encryption rule and install security policy

Step 2: Securemote installation
• Install Securemote client on your PC using source code in c:\sr directory, Choose the
following options :
• Reboot your computer and configure Securemote by importing the site: Site / New
192.168.150.222

• In this lab, we will use the same certificate as the one of S/MIME exercise. Therefore, open
your Netscape messenger and export your certificate in PKCS#12 format
(Security/Yours/Export…)
• Import your PKCS#12 formatted key material inside Securemote by selecting certificate/import
• Consequently, the key material format will be reformated as follows

• We define which certificate will be used for IPSec client authentication
• Note: by default, Securemote is configured to work with Entrust PKI; therefore don’t forget
to disable Entrust intelligence
• Now, try to reach some server behind the firewall, for example telnet 192.168.104.40. You
will be prompt for the password protecting the key material as follows
• And if you configured everything correctly…


Cryptography Basics PKI

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

Cryptography Basics PKI

Uploaded by

Copyright:

Available Formats

Unit 1 : Cryptography Basics Introduction and Key Terms

LEARN CRYPO & PKI

A technology for protecting you digital asset

And then design Security Solution

TRAINING CRYPTOGRAPHY & PKI

Author: Sylvain Maret

Revision: Version 1.5, October 1999, rev. August 2000

2.4.7. Lab Exercise 4_______________________________________________________ 51

1.2. KEY TERMS

The process of disguising a message to hide its substance is encryption.

The encrypted message is refered to as ciphertext.

Decryption is the process turning cyphertext back into plaintext.

You can see hereafter a schematic view of these definitions:

Cryptography Key Terms Figure 1

Cryptography is the science allowing messages to be kept secure.

Cryptology is the mathematics branch encompassing both cryptography and cryptanalysis.

- Authentication: It should be possible for the receiver of an encrypted message to be certain

Cryptography Key Terms Figure 2

1.3. MISCELLANEOUS CRYPTOSYSTEMS

1.3.1. Secret Key

1.3.2. Public Key

Miscellaneous Cryptosystems Figure 1

1.3.3. Message Digest

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

1.4. CRYPTOGRAPHY IN HISTORY

Cryptography in History Figure 1: Hieroglyphics

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Cryptography in History Figure 2: Mesopotamian tables

Cryptography in History Figure 3: An “Atbash” cipher

Cryptography in History Figure 4: A “Skytale” cypher

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Cryptography in History Figure 5: The “Polybius Square”

Cryptography in History Figure 6: The “Caesar” cypher

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Cryptography in History Figure 7: “Tabula recta”

Cryptography in History Figure 8: A “Changing Key” cipher

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Keyword : BEL ASOBELA SOB ELASOB

The basic keyword is BELASO in this example.

Cryptography in History Figure 9

Until 1917, Vigene cipher was considered as impossible to decrypt.

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Cryptography in History Figure 10: A “Wheel” cipher

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

1. Ciphertext should be unbreakable.

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

In 1929, Lester S. Hill published an article "Cryptography in an Algebraic Alphabet" in "The

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

Computationally secure: With a cryptosystem that is said to be computationally secure, it is

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

1.6. AES (ADVANCED ENCRYPTION STANDARD)

1.6.1. Overview of the AES Development Effort

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler

1.6.2. Minimum Acceptability Requirements

1.6.3. AES Round 2 Finalists

TwoFish – Counterpane Bruce Schneier

RC6 - RSA Laboratories

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler