Professional Documents
Culture Documents
« La Citadelle électronique »
Cryptography
Cédric Enzler
IPSEC & cryptographic engineer, PKI instructor
Dimension Data (Swiss) formerly Datelec
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
Introduction and Key Terms Unit 1 : Cryptography Basics
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.
Cryptanalysis is the art and science of breaking ciphertext (seeing through the above disguise).
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:
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:
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
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
All three cryptosystems are used in most Public Key Infrastructure implementations. They will be
described in more details in the following sections.
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.
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".
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.
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
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
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.
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
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
ABCDEFGHIJKLMNOPQRSTUVWXYZ Plaintext
FGUQHXSZACNDMRTVWEJBLIKPYO T0
OFGUQHXSZACNDMRTVWEJBLIKPY T1
YOFGUQHXSZACNDMRTVWEJBLIKP T2
PYOFGUQHXSZACNDMRTVWEJBLIK T3
GUQHXSZACNDMRTVWEJBLIKPYOF T25
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”…
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.
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
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.
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.
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.
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:
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.
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.
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
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.
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 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.
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.
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.
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.
1. Memory Cards
2. Symmetric Cryptoprocessor Cards
3. PKI smart cards (our name for asymmetric cryptoprocessor 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.
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.
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.
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.
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.
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
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
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.
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.
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.
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
• Now your file ssh.pdf is encrypted with your private key (or symmetric key).
• Move you mouse until the progress bar has reached 100%. Those mouse’s movements are for
random seed.
• 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.
• 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…
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.
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.
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.
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.
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.
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.
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
• 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.
Londres is now ready to send its public key to Rome. Rome will also send its key to Londres.
• 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.
• 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.
• 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”.
• 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.
• 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.
• 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:
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).
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.
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 only noticeable change is that the client application is configured to connect to the local
proxy instead of the remote server.
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.
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...
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:
You have here a table showing the ciphers used by SSH for authentication:
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
• Run SecureCRT.
• Choose Newton-Telnet session.
• Connect yourself to newton.pki.datelec.com using Telnet.
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”).
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
• Enter a Passphrase to protect your private key. You will use this Passphrase to lock or unlock
your private key.
• SecureCRT will now generate the keys using the mouse movements as a seed
(Random number).
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.
• 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
• 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.
• What do you see?
• Now you can test the tunnel using your browser. Run the browser with http://localhost:1234
as URL.
• What do you see?
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
• Your browser will now generate a Private key that will be stocked on the local disk.
• 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.
• 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.
• 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.
• 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).
• 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.
• 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
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).
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).
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:
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:
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.
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.
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.
• 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.
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:
Time
1 hour
• 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.
• 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
• 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.
• 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).
• 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.
• 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.
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:
Time
1 hour
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.
• Now your browser will generate a Private key. This key will be stocked on the local disk.
• Read you e-mail. You will receive a PIN number to retrieve your certificate.
• Paste your PIN number on your clipboard.
• 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.
• Now you are authenticated and connected to your SSL web site
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
• Finish the installation by restarting the computer and then choosing to install the security
module on netscape.
Step 2: Verification
• Launch Netscape browser, select Security / Cryptographic module following content should
appear
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
• 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
• Choose certificate management/ process request you should see your own certificate request waiting
to be validated
• 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
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
• Choose certificate management/revoke certificate you should see the following window
• You can select one of the certificates and revoke it by choosing revoke. A revocation reason is
required
• 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.
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.
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…
First of all, let us start by an IPSec oversight showing the relationship between the different
subsets of IPSec.
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.
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:
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.
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:
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
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
Authenticated
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.
• 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.
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.
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.
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.
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.
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
• 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
• 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
• 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