cryptography basics pki

Unit 1 : Cryptography Basics Introduction and Key Terms

LEARN CRYPO & PKI

« La Citadelle électronique »

Cryptography

A technology for protecting you digital asset

And then design Security Solution

Introduction and Key Terms Unit 1 : Cryptography Basics

TRAINING CRYPTOGRAPHY & PKI

Author: Sylvain Maret

Security architect, PKI instructor & Checkpoint instructor (Checkpoint CCSE)

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


TABLE OF CONTENTS Learn Crypo & PKI _______________________________________________1

Training Cryptography & PKI ______________________________________2

Table of contents _________________________________________________3

1. Cryptography Basics ___________________________________________5

1.1. Introduction _______________________________________________________5

1.2. Key terms _________________________________________________________5

1.3. Miscellaneous Cryptosystems _________________________________________7 1.3.1. Secret Key __________________________________________________________ 7 1.3.2. Public Key __________________________________________________________ 7 1.3.3. Message Digest ______________________________________________________ 7

1.4. Cryptography in history _____________________________________________8

1.5. Cryptoanalysis ____________________________________________________20

1.6. AES (Advanced Encryption Standard) ________________________________22 1.6.1. Overview of the AES Development Effort ________________________________ 22 1.6.2. Minimum Acceptability Requirements ___________________________________ 23 1.6.3. AES Round 2 Finalists________________________________________________ 23

1.7. Smart Cards ______________________________________________________25 1.7.1. Introduction ________________________________________________________ 25 1.7.2. What kinds of Smart Cards are available? _________________________________ 25 1.7.3. Symmetric / Asymmetric Cryptoprocessing _______________________________ 26 1.7.4. Smart Cards with different “flavor”______________________________________ 26 1.7.5. Memory Cards ______________________________________________________ 26 1.7.6. Symmetric Cryptoprocessor Cards ______________________________________ 27 1.7.7. PKI Smart Cards ____________________________________________________ 27

2. PKI Applications (lab exercises)_________________________________29

2.1. Symmetric file encryption ___________________________________________29 2.1.1. Lab Exercise 1 ______________________________________________________ 29

2.2. Message-Digest Algorithms __________________________________________33 2.2.1. Lab Exercise 2 ______________________________________________________ 33

2.3. Securing the desktop _______________________________________________37 2.3.1. Introduction ________________________________________________________ 37 2.3.2. Blowfish Advanced CS _______________________________________________ 37 2.3.3. Lab Exercise 3 ______________________________________________________ 40

2.4. PGP (Pretty Good Privacy) __________________________________________46 2.4.1. The PGP Symmetric Algorithms ________________________________________ 46 2.4.2. About PGP Data Compression Routines __________________________________ 47 2.4.3. About the Random Numbers used as Session Keys__________________________ 48 2.4.4. About the Message Digest _____________________________________________ 48 2.4.5. Encryption and Decryption ____________________________________________ 49 2.4.6. Digital Signature for PGP _____________________________________________ 50


2.4.7. Lab Exercise 4_______________________________________________________ 51 2.5. The SSH Protocol _________________________________________________ 63

2.5.1. Introduction _________________________________________________________ 63 2.5.2. Host Authentication___________________________________________________ 64 2.5.3. User Authentication___________________________________________________ 64 2.5.4. Cryptographic Methods________________________________________________ 65 2.5.5. Lab Exercise 5_______________________________________________________ 66

2.6. S/MIME _________________________________________________________ 79 2.6.1. Lab Exercise 6_______________________________________________________ 79

2.7. SSL _____________________________________________________________ 97 2.7.1. History_____________________________________________________________ 97 2.7.2. Secure Sockets Layer (SSL) ____________________________________________ 97 2.7.3. Session Establishment_________________________________________________ 98 2.7.4. Key Exchange Method ________________________________________________ 99 2.7.5. Cipher for Data Transfer _______________________________________________ 99 2.7.6. Digest Function _____________________________________________________ 100 2.7.7. Handshake Sequence Protocol _________________________________________ 100 2.7.8. Data Transfer_______________________________________________________ 101 2.7.9. Lab Exercise 7______________________________________________________ 102 2.7.10. Lab Exercise 8______________________________________________________ 123

2.8. Smart Card _____________________________________________________ 138 2.8.1. Lab Exercise 9______________________________________________________ 138

2.9. Playing the security officer_________________________________________ 140 2.9.1. Lab Exercise 10_____________________________________________________ 140

2.10. Revocation with client SSL authentication __________________________ 143 2.10.1. Lab Exercise 11_____________________________________________________ 143

2.11. IPSEC ________________________________________________________ 147 2.11.1. Introduction ________________________________________________________ 147 2.11.2. IPSec Architecture___________________________________________________ 148 2.11.3. IPSec Tunneling ____________________________________________________ 149 2.11.4. IKE Main Mode and Quick Mode_______________________________________ 154 2.11.5. Lab Exercise 12_____________________________________________________ 157


1. CRYPTOGRAPHY BASICS

1.1. INTRODUCTION It is likely that almost all students attending our “introduction to PKI” already have at least a basic knowledge of encryption and related subjects. Consequently, some of you might wish to skip this chapter: defining a terminology or a set of cryptography key terms is austere. However, we decided to begin with this less exciting section because we noticed, in many discussions with people familiar to the field, that terms definitions are often mixed up. As a result, we decided to start with simple definitions of key terms, which will be used constantly in the course, in order to provide the basis needed to understand the subject.

1.2. KEY TERMS A message will be defined as plaintext or cleartext.

The process of disguising a message to hide its substance is encryption. The encrypted message is refered to as ciphertext. Decryption is the process turning cyphertext back into plaintext. You can see hereafter a schematic view of these definitions:

Cryptography Key Terms Figure 1

Cryptography is the science allowing messages to be kept secure. Cryptanalysis is the art and science of breaking ciphertext (seeing through the above disguise). Cryptology is the mathematics branch encompassing both cryptography and cryptanalysis. Today, as cryptology is based on mathematical properties of numbers both in modern algebra and number theory, cryptologists are theoretical mathematicians.


Encryption and decryption are conducted by way of a set of mathematical functions, referred to as cryptographic algorithm or cipher. Besides providing confidentiality, cryptography is required to provide other security feature, as: - Authentication: It should be possible for the receiver of an encrypted message to be certain

of the sender’s identity. Authentication is the process that guarantees the respect of this rule. - Non repudiation: Inability of a sender to certify he was not the sender of the ciphertext. - Integrity: Provides a guarantee that the message was not modified between the sender and

the receiver. First ciphers or cryptographic algorithms suffered a major drawback : their security was based on the secrecy of the algorithm itself. As a result, every time a user was leaving the group of people knowing the algorithm, all other users had to switch to a different one! We understand today that this is not acceptable, therefore these ciphers, called restricted algorithms, are not used anymore. Modern cryptography worked around this drawback by introducing the concept of key. In these algorithms, security is based on key(s), meaning that the algorithm can be published at no risk. In most cases, the key used for encryption is not the same as the one used for decryption. As a result, the above diagram is modified as follows:

Cryptography Key Terms Figure 2

A cryptosystem consists of a cipher, keys and all possible plaintexts and ciphertexts. In some algorithms, the decryption key can be calculated from the encryption key. Both keys can be similar or different. In this case, we talk about symmetric encryption (see further in the course). In some other algorithms, both keys cannot be calculated from each other: this is called asymmetric encryption or Public-Key encryption.

Unit 1 : Cryptography Basics Miscellaneous Cryptosystems

© Dimension Data SA (Switzerland), Sylvain Maret & Cédric Enzler Version 1.5, October 1999, rev. August 2000

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

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

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

Miscellaneous Cryptosystems Figure 1

1.3.3. Message Digest This type of cryptosystem is often called a hashing function. With this technology, a variable length message is run through the encryption algorithm to produce a fixed length digest through the algorithm to produce the original message. All three cryptosystems are used in most Public Key Infrastructure implementations. They will be described in more details in the following sections.

Cryptography in History Unit 1 : Cryptography Basics


1.4. CRYPTOGRAPHY IN HISTORY Cryptography is one of the oldest fields of technical study we can find records of, going back at least 4,000 years. It is quite noteworthy that, of all the cryptosystems developed in those 4,000 years of effort, only 3 systems remain hard enough to break to be of real value. Cryptography probably began in or around 2000 B.C. in Egypt, where hieroglyphics were used to decorate the tombs of deceased rulers and kings. These hieroglyphics told the story of the life of the king and proclaimed the great acts of his life. They were purposefully cryptic, but not apparently intended to hide the text. Rather, they seem to have been intended to make the text seem more regal and important. As time went by, these writings became more and more complicated, and eventually the people lost interest in deciphering them.

Cryptography in History Figure 1: Hieroglyphics

Cryptology was (and still is to some extent) enshrouded in a veil of mystique to most people. It was because of this that the public began to acquaint cryptography with the black arts. It was often thought to be related to communication with dark spirits, and developed a bad image because of this. Most early cryptographers were scientists, but the common people were often convinced that they were also followers of the devil. The ancient Chinese used the ideographic nature of their language to hide the meaning of words. Messages were often transformed into ideographs for privacy, but no substantial use in early Chinese military conquests is apparent. Genghis Khan, for example, seems never to have used cryptography. In India, secret writing was apparently more advanced. The government used secret codes to communicate with a network of spies spread throughout the country. Early Indian ciphers consisted mostly of simple alphabetic substitutions, often based on phonetics. Some of these were spoken or used as sign language. This is somewhat similar to "pig latin" (igpay atinlay) where the first consonant is placed at the end of the word and followed by the sound "ay".

Unit 1 : Cryptography Basics Cryptography in History


The cryptographic history of Mesopotamia was similar to that of Egypt, in that cuneiforms were used to encipher text. The picture here under shows table of numbers found in Suse (Iran modern). These numbers were associated to words, demonstrating an amazingly modern level of cryptography.

Cryptography in History Figure 2: Mesopotamian tables This technique was also used in Babylon and Assyria. In the Bible, a Hebrew ciphering method is used at times. In this method, the last letter of the alphabet is replaced by the first, and vice versa. This is called 'atbash'. For example, the following table gives a translation of this sort for English. The word "HELLO" becomes "SVOOL". Try to decrypt the word "WVXIBKG" and see what you get.

ABCDEFGHIJKLMNOPQRSTUVWXYZ ZYXWVUTSRQPONMLKJIHGFEDCBA

Cryptography in History Figure 3: An “Atbash” cipher

In the famous Greek drama the 'Iliad', cryptography was used when Bellerophon was sent to the king with a secret tablet, which told the king to have him put to death. The king tried to kill him by having him fight several mythical creatures, but he won every battle. The Spartans used a system, which consisted of a thin sheet of papyrus wrapped around a staff (now called a "staff cipher"). Messages were written down the length of the staff, and the papyrus was unwrapped. In order to read the message, the papyrus had to be wrapped around a staff of equal diameter. Called the 'skytale' cipher, this was used in the 5th century B.C. to send secret messages between Greek warriors. Without the right staff, it would be difficult to decode the message using the techniques available at that time. The following version of the alphabet demonstrates the technique. First we see the wrapped version of the alphabet, then the unwrapped version. ADGJMPSVY BEHKNQTWZ CFILORUX ADGJMPSVYBEHKNQTWZCFILORUX Cryptography in History Figure 4: A “Skytale” cypher



Polybius developed another Greek method (now called the "Polybius Square"). The letters of the alphabet would be laid out in a five by five square (similar to the later Playfair method), with i and j occupying the same square. Rows and columns are numbered 1 to 5 so that each letter has a corresponding (row,column) pair. These pairs could easily be signaled by torches or hand signals. Decryption consists of mapping the digit pairs back into their corresponding characters. This system was the first to reduce the size of the symbol set, and in a loose sense it might be considered the forerunner of modern binary representations of characters.

Cryptography in History Figure 5: The “Polybius Square” Julius Ceasar used a system of cryptography (i.e. the 'Caesar Cipher') which shifted each letter 2 places further through the alphabet (e.g. Y shifts to A, R shifts to T, etc.). This is probably the first cipher used by most schoolchildren. In figure 5, the first row is plaintext, while the second row is the equivalent ciphertext. The distance of the displacement is not important to the scheme, and in fact, neither is the lexical ordering chosen. The general case of this sort of cipher is the "monoalphabetic substitution cipher" wherein each letter is mapped into another letter in a one to one fashion. Try decoding VJKU.

ABCDEFGHIJKLMNOPQRSTUVWXYZ CDEFGHIJKLMNOPQRSTUVWXYZAB

Cryptography in History Figure 6: The “Caesar” cypher

Cryptanalysis is the practice of changing ciphertext into plaintext without complete knowledge of the cipher. The Arabs were the first to make significant advances in cryptanalysis. An Arabic author, Qalqashandi, wrote down a technique for solving ciphers which is still used today. The technique is to write down all the ciphertext letters and count the frequency of each symbol. Using the average frequency of each letter of the language, the plaintext can be written out. This technique is powerful enough to cryptanalyze ANY monoalphabetic substitution cipher if enough cyphertext is provided. During the Middle Ages, cryptography started to progress. All of the Western European governments used cryptography in one form or another, and codes started to become more popular. Ciphers were commonly used to keep in touch with ambassadors. The first major advances in cryptography were made in Italy. Venice created an elaborate organization in 1452 with the sole purpose of dealing with cryptography. They had three cipher secretaries who solved and created ciphers that were used by the government.



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

Cryptography in History Figure 7: “Tabula recta” ABCDEFGHIJKLMNOPQRSTUVWXYZ Plaintext FGUQHXSZACNDMRTVWEJBLIKPYO T0 OFGUQHXSZACNDMRTVWEJBLIKPY T1 YOFGUQHXSZACNDMRTVWEJBLIKP T2 PYOFGUQHXSZACNDMRTVWEJBLIK T3 GUQHXSZACNDMRTVWEJBLIKPYOF T25

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



In 1553, Giovan Batista Belaso extended this technique by choosing a keyword that is written above the plaintext, in a letter to letter correspondence. The keyword is restarted at the beginning of each new plaintext word. The letter of the keyword above the letter of the plaintext is the first letter of the cipher line to be used. In other words, if the plaintext letter is 'b', and it's keyword letter is 'r', then the line of the Trithemius cipher beginning with 'r' is used to encipher the letter 'b'. He chose to name the keyword a “password”… Keyword : BEL ASOBELA SOB ELASOB Plaintext : LES ITALIENS ONT TROUVE The basic keyword is BELASO in this example. The most famous cryptographer of the 16th century was Blaise de Vigenere (1523-1596). In 1585, he wrote 'Tracte des Chiffres' in which he used a Trithemius table, but changed the way the key system worked. One of his techniques was to use plaintext as its own key. Another used ciphertext. The way in which these keys are used is known as key scheduling, and is an integral part of the "Data Encryption Standard" (DES) which we will discuss later.

Cryptography in History Figure 9

Until 1917, Vigene cipher was considered as impossible to decrypt. In 1628, a Frenchman named Antoine Rossignol helped his army defeat the Huguenots by decoding a captured message. After this victory, he was called upon many times to solve ciphers for the French government. He used two lists to solve his ciphers: "one in which the plain elements were in alphabetical order and the code elements randomized, and one to facilitate decoding in which the code elements stood in alphabetical or numerical order while their plain equivalents were disarranged." When Rossignol died in 1682, his son, and later his grandson,



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



transmission. The decryption requires the recipient to align the letters of the ciphertext along the rotational axis and find a set of aligned letters that makes linguistic sense as plaintext. This will be the message. There is a very small probability that there will be two sensible messages from the decryption process, but this can be checked simply by the originator. Without knowing the orderings of symbols on the wheels and the ordering of wheels on the axle, any plaintext of the appropriate length is possible, and thus the system is quite secure for one time use. Statistical attacks are feasible if the same wheels are used in the same order many times.

Wheel 1 GJTXUVWCHYIZKLNMARBFDOESQP Wheel 2 IKMNQLPBYFCWEDXGZAJHURSTOV Wheel 3 HJLIKNXWCGBDSRVUEOFYPAMQZT ... Wheel n BDFONGHJIKLSTVUWMYEPRQXZAC

Cryptography in History Figure 10: A “Wheel” cipher

In 1817, Colonel Decius Wadsworth developed a set of two disks, one inside the other, where the outer disk had the 26 letters of the alphabet, and the numbers 2-8, and the inner disk had only the 26 letters. The disks were geared together at a ratio of 26:33. To encipher a message, the inner disk is turned until the desired letter is at the top position, with the number of turn required for this result transmitted as ciphertext. Because of the gearing, a ciphertext substitution for a character will not repeat itself until all 33 characters for that plaintext letter have been used. Unfortunately, Wadsworth never got credit for his design, because Charles Wheatstone invented an almost identical machine a few years after Wadsworth, and got all the credit. In 1844, the development of cryptography was dramatically altered by the invention of the telegraph. Communication with the telegraph was by no means secure, so ciphers were needed to transmit secret information. The public's interest in cryptography blossomed, and many individuals attempted to formulate their own cipher systems. The advent of the telegraph provided the first instance where a base commander could be in instant communication with his field commanders during battle. Thus, a field cipher was needed. At first, the military used a Vigenere cipher with a short repeating keyword, but in 1863, a solution was discovered by Friedrich W. Kasiski for all periodic polyalphabetic ciphers, which until this time were considered unbreakable. So the military had to search for a new cipher to replace the Vigenere. The Black Chambers of Europe continued to operate and were successful in solving most American ciphers, but without a war underway, their usefulness was diminished, and by 1850 they were dissolved.



The 'Playfair' system was invented by Charles Wheatstone and Lyon Playfair in 1854, and was the first system that used pairs of symbols for encryption. The alphabet is laid out in a random 5 x 5 square, and the text is divided into adjacent pairs. The two letters of the pair are located, and a rectangle is formed with the two letters at opposite corners. The letters at the other two corners are the two letters of ciphertext. This is very simple to use, but is not extremely difficult to break. The real breakthrough in this system was the use of two letters at a time. The effect is to make the statistics of the language less pronounced, and therefore to increase the amount of work and the amount of ciphertext required to determine a solution. This system was still in limited use in World War 2, and was very effective against the Japanese.

I K M N Q L P B Y F C W E D X G Z A H U R S T O V

Plaintext: PL AI NT EX TZ Ciphertext: LP MG MO XE AS In 1859, Pliny Earle Chase, developed what is known as the fractionating or tomographic cipher. A two digit number was assigned to each character of plaintext by means of a table. These numbers were written so that the first numbers formed a row on top of the second numbers. The bottom row was multiplied by nine, and the corresponding pairs are put back in the table to form the ciphertext. Kasiski developed a cryptanalysis method in 1863, which broke almost every existing cipher of that time. The method was to find repetitions of strings of characters in the ciphertext. The distance between these repetitions is then used to find the length of the key. Since repetitions of identically ciphered identical plaintext occur at distances that are a multiple of the key length, finding greatest common divisors of repetition distances will lead to the key length. Once the key length (N) is known, we use statistics on every Nth character and the frequency of use implies which character it represents in that set of ciphertext symbols. These repetitions sometimes occur by pure chance, and it sometimes takes several tries to find the true length of the key using this method, but it is considerably more effective than previous techniques. This technique makes cryptanalysis of polyalphabetic substitution ciphers quite straight forward. During the Civil War (1861-1865), ciphers were not very complex. Many techniques consisted merely of writing words in a different order and substituting code words for proper names and locations. Where the Union had centralized cipher control, the Confederacy tended to let field commanders decide their own forms of ciphers. The Vigenere system was widely used by field commanders, and sometimes led to the Union deciphering messages faster than their Confederate recipients. The Confederacy used three keywords for most of its messages during the War, "Manchester Bluff", "Complete Victory", and "Come Retribution". They were quickly discovered by three Union cryptanalysts Tinker, Chandler, and Bates, and messages encoded using them were regularly deciphered by the Union. The use of common words as keys to cryptosystems has caused many plaintext messages to be discovered. In fact, the use of common words for passwords is the most common entry point in modern computer system attacks.



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



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



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



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

Cryptoanalysis Unit 1 : Cryptography Basics


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

understood that given enough computing power and disk storage space the system could eventually be broken. However, unless the cryptosystem is flawed in some fundamental way, the amount of time and computing power necessary to break the system would either be too costly or unreasonable. For example, given today’s technology, it would take an amount of time approximately equal to the age of the universe to break the cryptosystem!

Unconditionally secure: A cryptosystem that can never be broken even if an infinite amount

of resources were dedicated to the effort is said to be unconditionally secure.

By making the code of a cryptographic system available to the world, cryptographers have the opportunity to do what they can to break a cryptosystem. Often, cryptographers will have a high degree of computing power at their disposal: much more so than the average individual. This is what is known as cryptoanalysis. In this field, a cryptanalyst deploys a variety of tools and methods to break a cryptosystem, however, it does not necessarily mean that the entire algorithm has been compromised. In fact, there are different levels of weaknesses one can discover in a cryptosystem: Information deduction: This is the lowest level weakness in which the cryptanalyst is able

to discover portions of the key or some information about the plain text from the cipher text.

Instance deduction: The cryptanalyst is able to find the plaintext of a given intercepted

cipher. Global deduction: The cryptanalyst devises an algorithm that can decrypt the

ciphertext created from another algorithm. Total break: The cryptanalyst can recover the key and decrypt any encrypted

message.

Unit 1 : Cryptography Basics Cryptoanalysis


There are a variety of methods one can use to break a cipher. The easiest way is to obtain the key either through social engineering, chance or some form of coercion. These however, are not cryptanalytic techniques: Ciphertext only: In this scenario, the cryptanalyst only has cipher text to work with.

If this is the case, one approach may be to user a brute-force attack in which the cryptanalyst attempts to try all possible combinations of keys. If the key is based on a pass phrase, often the cryptanalyst can engage a dictionary attack in which he tries common words and combinations

Chosen ciphertext: The cryptanalyst chooses the cipher text and attempts to obtain the

corresponding plaintext. Adaptive chosen ciphertext:This is a variation of the attack outlined above in which the

cryptanalyst has free user of decryption hardware, but is unable to extract the encryption key from it.

Known plaintext: The cryptanalyst may have the benefit of obtaining plaintext that

corresponds to some ciphertext. With these two elements, the cryptanalyst may be able to derive the key with which to decipher any text encrypted with that key.

Chosen plaintext: A variant of the known plaintext attack in which the cryptanalyst can

select the plaintext to use for the analysis and and then obtain the corresponding ciphertext.

Adaptive chosen plaintext: A variation of the chosen plaintext attack in which the cryptanalyst

can dynamically choose the plaintext samples. Then, he can change his selection based on the results of previous encryptions.

Biological attacks: This type of attack gets its name because the technique used to

break the cryptosystem resembles methods used in biology to study organisms rather than the mathematically based techniques described above. Biological techniques subject the cryptosystem different stimuli to see how it reacts and studying its input and outputs. An example would be some work done by Paul Kocher of Cryptography research in which he was able to extract various secrets from smartcards by monitoring its power consumption. Specific information on these techniques can be found at http://www.cryptography.com/dpa

Cryptanalytic attacks can be mounted against any cryptographic system including encryption algorithms, digital signature algorithms and message authentication code (MAC) algorithms to name a few.

AES (Advanced Encryption Standard) Unit 1 : Cryptography Basics


1.6. AES (ADVANCED ENCRYPTION STANDARD)

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

Unit 1 : Cryptography Basics AES (Advanced Encryption Standard)


comments. Following the comment period, the standard will be revised, as appropriate, by NIST in response to those comments. A review, an approval and a promulgation process will also follow. If all steps of the AES development process proceed as planned, it is scheduled that the standard will be completed by the summer of 2001.

1.6.2. Minimum Acceptability Requirements 1. The algorithm must implement symmetric (secret) key cryptography. 2. The algorithm must be a block cipher. 3. The algorithm candidates shall be capable of supporting key-block combinations with sizes of

128-128, 192-128, and 256-128 bits. A submitted algorithm may support other key-block sizes and combinations, and such features will be taken into consideration during analysis and evaluation.

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

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

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

AES (Advanced Encryption Standard) Unit 1 : Cryptography Basics


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

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

Unit 1 : Cryptography Basics Smart Cards


1.7. SMART CARDS

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

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

Smart Cards Unit 1 : Cryptography Basics


Smart cards can be divided into three prime categories: 1. Memory Cards 2. Symmetric Cryptoprocessor Cards 3. PKI smart cards (our name for asymmetric cryptoprocessor cards)

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

1.7.4. Smart Cards with different “flavor” Remember that all smart cards are not alike, they come in different “flavors”. Many cards cannot provide support for the RSA algorithm within the card processor. And even if they do support RSA they may not be optimised to handle this process very efficiently. Far too often there are solutions in place where the smart card is nothing but a storage media for the keys. This document will describe various types of smart cards and where they typically apply.

1.7.5. Memory Cards

Access Control Plain memory cards may provide access restrictions through one or several Personal Identification Number (PIN). However, memory cards may not protect the contents of the stored information file from disclosure. A memory card can be compared to a floppy disc although providing less storage capacity. On the other hand the card reader device is less complex and less expensive compared to a floppy disc reader, thus enabling a better commercial ground for deployment in environments where a floppy disc reader may not be present.

Processing Memory smart cards should probably not even be categorized as smart cards. Their processing power is restricted to perform storage operations but little else. Once a user/owner of a PIN protected file in a plain memory card has been granted read access he/she can freely retrieve the contents of the file. Hence, the actual file contents may be copied from the smart card. These cards exist with various amounts of memory and can be used in applications requiring none or limited read protection. They may for instance be useful for storing medical information necessary for emergency actions, such as your name and blood type. They may provide write protection, which enables them to be useful in other applications where adding or modifying data on the card should be restricted. However, such protection generally requires more than just a PIN code, thus the commercial use is limited.

Conclusion Memory cards can not provide a secure non-repudiation service, hence not very suitable for e-commerce.

Unit 1 : Cryptography Basics Smart Cards


1.7.6. Symmetric Cryptoprocessor Cards

Access Control Symmetric cryptoprocessor smart cards may offer a sophisticated access structure. Files may be readable but not “writeable” or vice versa and if the reverse order applies, it is likely that the file contents is accessible within the card. Files may be protected by one or several passwords (PIN) and not accessible without entering the correct PIN. The PIN file itself is only “writeable” (in order to let you change your password) and accessible within the card (in order to verify the PIN you enter).

Processing By using encryption it is possible to transfer information between two parties without disclosing the contents to a "third-person". This is quite useful for applications utilizing an electronic smart card purse or in connection with GSM cards. It is not only possible to have "files" write protected. In fact, it is possible with the encryption process to ensure that only an authorized party may alter information in a successful manner. Symmetric encryption is fast, by broad margin faster than asymmetric encryption.

Conclusion Although symmetric encryption is fast, it has a few drawbacks. First, key management is virtually impossible from a large-scale public perspective, mainly due to the difficulty of deploying and maintaining trust, and secondly, it is not possible to provide non-repudiation services.

1.7.7. PKI Smart Cards

Access Control The basic difference between the PKI smart card and symmetric cryptoprocessor smart cards is that the former offer a secure RSA process onboard the chip. From an access point of view they are equal, what differs is the processing of RSA. In fact, it is likely that the PKI smart card additionally can offer symmetric as well as asymmetric encryption functionality. Files may be readable but not writeable or vice versa and only accessible within the card as described earlier. Files may be protected by one or several passwords (PIN) and not accessible without entering the correct PIN. This is also a necessity concerning the private key file.

Processing PKI smart cards enable secure remote authentication and non-repudiation services through the use of the RSA algorithm. PKI smart cards are using a cryptoprocessor handling asymmetric encryption. The general positive effects of smart cards, i.e. ease of use and fairly low-cost equipment, apply for all cards including PKI smart cards. What makes PKI smart cards additionally beneficial compared to symmetric encryption cards is the possibility to provide a scalable solution and not to be forgotten, the ability to provide for a secure authentication and non-repudiation service. Scalability advantages due to the fact that there is a public and a private part of keys involved and this makes deployment and maintenance much easier from a security perspective compared to symmetric keys.

Smart Cards Unit 1 : Cryptography Basics


Also consider the effect of having only the RSA cryptoprocessor enabled to use your private information; the private information is not possible to copy! It can never leave the card. The PKI card offers a completely different level of security compared to storing private information on a floppy disc, on a hard disc or even on a less protected smart card. It is the card's operating system that prevents the keys from being exposed outside the card. They can thus never be read, removed or tampered with (even by the user). The user will only have access to the functions of the card through the use of a secret PIN code that the user may change at any time.

Conclusion The only secure smart card solution out on the market today would be a solution based on PKI smart cards. If using something less, keys are only as secure as if they were stored on a floppy or on your hard disc. PKI smart cards are the only alternative for doing business over an evolving e-commerce market.

Unit 2 : PKI Applications (Lab Exercises) Symmetric File Encryption


2. PKI APPLICATIONS (LAB EXERCISES)

2.1. SYMMETRIC FILE ENCRYPTION

2.1.1. Lab Exercise 1

Objective The student will use a symmetric encryption algorithm to encrypt a text file. DES and IDEA will be used for this lab.

Main steps 1. Create a text file with an editor 2. Encrypt this file using DES 3. Encrypt this file using IDEA 4. Decrypt this file using DES 5. Decrypt this file using IDEA

Time 15 minutes

Symmetric File Encryption Unit 2 : PKI Applications (Lab Exercises)


Step 1: Create a text file with an editor • Create a “Notepad file” called toto.txt in c:\temp

• Edit this file and add a text like “Hello world…” • Save and quit

Unit 2 : PKI Applications (Lab Exercises) Symmetric File Encryption


Step 2: Encrypt this file using DES • On your desktop, launch OpenSSL • You will encrypt this file with DES. Type the command

des –in toto.txt –out toto.txt.des –e • Enter a password that will be the secret key

• Have a look at the file toto.txt.des

Step 3: Encrypt this file using IDEA • Encrypt the file toto.txt with IDEA. Type the command

idea –in toto.txt –out toto.txt.idea –e • Enter a password

• Have a look at the file toto.txt.idea

Symmetric File Encryption Unit 2 : PKI Applications (Lab Exercises)


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

Step 5: Decrypt this file using IDEA • Type idea –in toto.txt.idea –d to decrypt the IDEA file • Enter your password

• Now you are finished…

Unit 2 : PKI Applications (Lab Exercises) Message-Digest Algorithms


2.2. MESSAGE-DIGEST ALGORITHMS For a theoretical introduction, please refer to the book “Digital Certificates” written by Jalal Feghhi, Jalil Feghhi and Peter Williams.


Objective The student will “play” with message digest functions. MD5 and SHA-1 will be used to compute digest for an input text file.

Main steps 1. Create a text file with an editor 2. Compute message digest functions with MD5 3. Change the text 4. Compute message digest functions again with MD5 5. Compute message digest functions with SHA-1

Time 15 minutes

Message-Digest Algorithms Unit 2 : PKI Applications (Lab Exercises)


Step 1: Create a text file with an editor • Create a file with an editor called toto.txt in c:\temp

• Edit this file and add a text like “Hello world…” • Save and quit

Unit 2 : PKI Applications (Lab Exercises) Message-Digest Algorithms


Step 2: Compute message digest functions with MD5 • On your desktop, launch OpenSSL • Type the command md5 toto.txt • Have a look at the result. You will see the MD5 digest (128 bits)

Step 3: Change the text • Edit again c:\temp\toto.txt and change only one character (for instance H h)

Message-Digest Algorithms Unit 2 : PKI Applications (Lab Exercises)


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

Step 5: Compute message digest functions with SHA-1 • Type now sha1 toto.txt on the OpenSSL application • What do you see? Compare this with the MD5 digest!

• You are now finished…

Unit 2 : PKI Applications (Lab Exercises) Securing the Desktop


2.3. SECURING THE DESKTOP

2.3.1. Introduction Safeguarding data being transmitted as e-mail messages over an open network like the Internet is an important step to take in order to keep your data private. Protecting data on a personal computer presents a different set of issues in terms of how the data should be protected and how to control keys. The most important issue may perhaps be how to select a data encryption product for your desktop. Many products are available on the market to perform file encryption (RSA SecurPC, Blowfish Advances CS, etc.) For this particular training we will use “Blowfish Advanced CS” because it is a very simple product to use. Moreover, it will allow you to be familiar with secret-key file encryption, key splitting and files wiping.

2.3.2. Blowfish Advanced CS

Introduction Blowfish Advanced CS is a file encryption program, protecting your files with a key built from a password or a key disk, so that no one except you can access its contents. Blowfish Advanced CS erases sensitive files that are no longer needed, in order to prevent anyone to restore them. Working with encrypted files and clearing empty disk space are other useful features. Today, we are in the information age and encrypting data is becoming more and more important for most of us. There are many reasons why data have to be protected from unauthorized access, as for instance sensitive medical data, private or business documents, or just some “hot stuff” from the Internet. There are many ways to make data readable only to a selection of people. Besides physical measures like locking removable disks into a safe or hiding files with stenography (which is a cheap solution), the only way to make files really inaccessible is to use strong cryptography. That means high-end encryption algorithm with long-enough keys to resist any attacks, this combined with secure removal of the original data.

Encryption Algorithms Blowfish Advanced CS is currently shipped with 4 algorithms, which are the followings:

Blowfish Bruce Schneier designed the algorithm. Blowfish is a very fast algorithm, performing with excellence on modern 32bit processors. Another advantage is its variable key-size, which goes up to 448 bits (56 bytes). It was first published in Doctor Dobb's Journal, issue 4/94, and after a year of intensive cryptanalysis it was still unbroken (as reported in DDJ 10/95).

PC1 This algorithm is 100% compatible with the RC4 stream cipher. Ron Rivest developed RC4 in 1987. Someone posted 1994 the source code in a mailing list and since then it has been spread all over the world. RC4 is a stream cipher handling single bytes. The implementation used by Blowfish Advanced CS uses a key size of 160 bits.

Securing the Desktop Unit 2 : PKI Applications (Lab Exercises)


Triple-DES DES is the standard encryption algorithm, designed by IBM in the middle seventies. Although it has been cryptanalyzed for over 20 years, no weakness has been found yet. The only problem of DES is its short key length of 7 bytes (equals 56 bits). If someone has access to very fast computers, he can try out all possible keys within a few hours. There are some DES variants, extending the original algorithm to a new one with a larger key. The most common one is triple-DES, where a 64-bit data block will be encrypted three times with DES, using three different keys (or a single key split into three parts). Therefore, the key length is 21 bytes (168 bits), improving significantly the security but also slowing down the algorithm. The triple-DES implementation in Blowfish Advanced CS is 100% compatible with the DES standard.

Twofish TwoFish is the AES candidate from Counterpane. It is a new, fast and very flexible encryption algorithm. After extensive cryptanalysis, no weaknesses are known yet. For more information about TwoFish, visit http://www.counterpane.com. The version of Twofish in Blowfish Advanced CS uses a key size of 256 bits and a block size of 128 bits.

Key Setup Different encryption algorithms require different key lengths. The Blowfish encryption algorithm needs e.g. a key of 448 bits (56 bytes). It is very uncomfortable to find passwords having exactly the right length each time, so that the program converts the password into a key for the individual algorithm. Blowfish Advanced CS uses a key setup in which your password (or key disk content) is hashed with SHA-1, the most "Secure Hash Algorithm" available today. One of the advantages is that the key result appears in binary form and looks like random data. Moreover, the password’s length is not restricted to the maximum key-length of the selected algorithm, so it can be hashed up or down to the right size. You will find hereafter two examples, which will help you to understand the key setup of Blowfish Advanced CS: Let us choose "helloworld" as our password. We want to create a key of 128 bits (16 bytes). The SHA-1 allows us to input as many data bytes as we wish and it puts out a hash of 160 bits (20 bytes). A hash (also called digest) is like a CRC32 checksum, but secure for encryption.



To resize the 20 bytes of the hash to the required 16 bytes for the key, we take the first 16 bytes of the hash and XOR the rest of 4 bytes over the beginning of these 16 bytes. Doing so, we take the totality of the hash into consideration:

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

Random Number Generation Blowfish Advanced CS offers you two pseudo random number generators. PRNGs are used to create random data for security purposes, (e.g. salt values, which are combined with keys), for overwriting (wiping) data or (most important) to create key files.

Yarrow This PRNG was designed by Counterpane and can be considered as the best concept to create random data for security purposes. Blowfish Advanced CS uses a Yarrow implementation with SHA-1 as the hash algorithm and triple-DES as the block cipher. For the latest paper of the Yarrow specifications please visit http://www.counterpane.com.

CryptPak PRNG The random generator was working in the predecessor Blowfish Advanced 97 as the one and only PRNG. It uses a SHA-1 rescrambling method. To initialize the generator, a string with various data (system date and time, drive information, etc.) is built and hashed by SHA-1. As a result, one gets a 20 bytes buffer of random data, from which just 16 bytes are used to avoid predictable random sequences. If another 16 bytes are requested, the hash value is hashed with itself to a new digest. This method provides a much better randomness than conventional 32-bit random number generators.




Objective The student will setup a file’s encryption software to protect sensitive information. This software will use strong symmetric encryption mechanisms to protect information.

Scenario The Management wants to implement a solution to protect sensitive information on the laptop. For specific files they want to implement key splitting. Moreover, they want to store a secret key on an external support that will be a diskette.

Main Steps 1. Encrypt a file with one secret key 2. Exchange this file with your partner 3. Decrypt the partner’s file you receive 4. Encrypt a file with two secret keys (Key Splitting)

Time 20 minutes



Step 1: Encrypt a file with one secret key • On your desktop, launch Blowfish Advanced CS. • Select c:\encrypted files\ssh.pdf. • Encrypt this file using the Blowfish encryption algorithm.

• Enter a password. In fact, it will be your private key. • Keep this password secret. Your partner should not know it.

• Reenter the password to confirm.



• Now your file ssh.pdf is encrypted with your private key (or symmetric key).

Step 2: Exchange this file with your partner • Send this encrypted file to your partner via e-mail. Your partner will also send one to you.



Step 3: Decrypt the partner’s file you receive • Read your e-mail. You should have received the encrypted file from your partner.

• Double click on the attachment. Blowfish Advanced CS will be launched. • Ask your partner’s password. • Enter the password.

• That’s it, you are able to read the PDF document.



Step 4: Encrypt a file with two secret keys (Key Splitting) You will now use Key Splitting • Insert a diskette into your reader. The Key Disk will be stocked on it. • Go to Tools Option menu Miscellaneous and choose make a Key Disk. This key will be used as

a private key for encryption and decryption.

• Move you mouse until the progress bar has reached 100%. Those mouse’s movements are for random seed.

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



• Press Yes to append another password. It will be the second private key that we call Key Splitting.

• Choose Password option and ask your partner to enter a password. Your partner should keep

this password private.

• Press No to end the encryption.

• The encryption with two keys (one Key Disk and one Standard password) is done. • You can try to decrypt this file. • Now, you are finished…

PGP (Pretty Good Privacy) Unit 2 : PKI Applications (Lab Exercises)


2.4. PGP (PRETTY GOOD PRIVACY)

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

Unit 2 : PKI Applications (Lab Exercises) PGP (Pretty Good Privacy)


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

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



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

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



2.4.5. Encryption and Decryption PGP combines some of the best features of both conventional and public key cryptography. PGP is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP compresses first the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. (Files that are too short to compress or which don’t compress well aren’t compressed.) PGP creates then a session key, which is a one-time-only secret key. This key is a randomnumber generated from the randommovements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient’s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.

PGP Figure 1

Decryption works in the reverse. The recipient’s copy of PGP uses his or her private key to recover the temporary session key, which is then used by PGP to decrypt the conventionally encrypted ciphertext.

PGP Figure 2

The combination of both encryption methods provides the convenience of public key encryption with the speed of conventional encryption. Conventional encryption is about 1,000 times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, both encryption methods improve performance and key distribution. Thus, security is not compromised.



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

PGP Figure 3




Objective In order to make the student sensitive to other standards, the latter will setup an e-mail using PGP encryption and key signature.

Scenario You want to guarantee the privacy of an e-mail sent through the Internet between two peers. To justify the idea, one admits that both peers do not have a common trust certificate authority (if so, S/MIME would be in the scope) but hire the PGP software.

Main Steps 1. Generation of PGP key peers by each peer 2. Key cross exchange 3. Certification of a partner public key 4. Send a signed message 5. Send an encrypted and signed message 6. PGP behavior after unexpected cleartext modifications

Time 40minutes

Step 1: Generation of PGP Key pair • Launch the PGP Keys application located in the systray. The first time, the user is prompt by a

wizard to generate a key-pair.



• Enter your personal data.

• So that each student can exchange encrypted information with the others, enter following

parameters: Key-pair type: RSA Key-pair size: 1024 bits Key-pair never expires

• Once you have done this, you will be prompt to enter a passphrase that will protect the use of your private key.



• After the key generation process has started, you are asked if you want to send your public key to a root server. The aim of this PGP root server is to play the role of a PGP public key container. The idea behind this is that if you want to establish a secure connection with another PGP pair, you simply get its public key from this server. Of course, this sounds very practical, but is it secure? Think about it!

Note: In the current case, we will not try to send the key...

• The following window will appear and confirm the key-pair generation.



Step 2: Key cross exchange Before entering step 2, check that your partner has successfully accomplished step 1. In this example, Londres’s partner will be Rome, so...watch carefully the recipient/sender names in the next printed screens. To avoid confusion, keep in mind that the printed screens are coming from Londres ONLY. Londres is now ready to send its public key to Rome. Rome will also send its key to Londres. • Londres starts by copying its key shown in the PGPkeys window.

• Then, Londres opens its mail browser and sends an e-mail to Rome. Londres pastes the

clipboard as the message.



• Rome did exactly the same for its part, hence Londres will receive the following message containing Rome’s public key. There are several ways to proceed; the first is to select the text including the beginning and the end marks.

• Once copied in the clipboard, launch the PGP key window and paste the key as shown

hereafter.

• Rome’s newly imported key should appear in this window. • For its part, Rome has imported Londre’s public key giving an end to this so-called key

exchange process. Are you sure about the effective origin of this public key? What should be done in order to guarantee it? Think about it!



Step 3: Certification of a partner public key • At this stage, you have only imported a public key without defining any trust level for it. If

you are convince of its reliability you can sign it by right clicking on ROME’s key, the following screen appears.

• Choose OK and enter the passphrase protecting your private key. Right click on your

partner’s key and select Key Properties. The following window appears thanks to which you can set the level of trust with the button Trusted.

• Because Rome followed the same procedure for its part, crossed certification is finished now.



Step 4: Send a signed message So that your partner can be sure of the message’s sender, we will now send him a signed message. • Open your mail browser and write a message to your partner, i.e Rome in our case. Once

done, maintain the mail window active, right click on systray and select “sign”.

• The consequence should be the transformation of your message, as follows.



• Rome did exactly the same, hence you receive the following mail:

• You will see now how to check the validity of this signed message. To do so, select the mail

window, launch Systray / Current Window / Decrypt and Verify and the following verification window appears.



Step 5: Send an encrypted and signed message In this final step, we will be more practical and send an encrypted message, whose sender identity can be checked. • Similarly to the precedent step, open you mail browser and write a message. Check that the

window is active and right click on Systray / Current window / Encrypt and Sign. A window appears asking you who will be the recipient. In this case, we select Rome.

• Automatically the written message is transformed as shown hereunder.



• You can now send it to your partner. He also sent you a similar message that you have to decrypt and check.

• As you might guess, select Systray / Current Window / Decrypt and Verify / Enter passphrase.

Think about the reason why you have to enter the passphrase...The result is the following:



Step 6: PGP behavior after unexpected cleartext modifications Now we will write and sign an Email. Before sending it to your partner, you will simulate an unexpected content modification… • Open your mail browser and write the message to your partner. Once done, maintain the mail

windows active, right click on systray and select sign (cf. Step 4).

• Then modify slightly the content of the cleartext



• Now you can send the modified message to your partner • Your partner did exactly the same, therefore you receive an Email. Open it, and verify it, what

do you observe?

• Now your PGP lab is completed…

Unit 2 : PKI Applications (Lab Exercises) The SSH Protocol


2.5. THE SSH PROTOCOL

2.5.1. Introduction As the student already knows, IP protocol does not guarantee in any aspect information security. More precisely, this protocol doesn’t offer any authentication, privacy or integrity protection mechanism. Moreover, due to the OSI model philosophy, all higher-level protocols are in the same way deficient, as they usually assume the lower level can be trusted. Therefore, the need of a security mechanism at the application level arose out of the market, in parallel to the Internet’s success. Such a need has been fulfilled by the SSH protocol. It provides a transport-layer encryption mechanism offering host authentication and user authentication, as well as privacy and integrity protection. In its most common application, it gives users secure login connections, secure file transfer, secure X11windowing system and secure TCP/IP connection over “untrusted” networks. SSH is a packet-based binary protocol that works on top of any transport that will pass a stream of binary data. Normally, TCP/IP is used as the transport but the implementation also permits to pass data to and from the server using any arbitrary proxy program to pass data to and from a server. Effectively, thanks to the port-forwarding technology, it is possible to forward arbitrary (almost) insecure connections over a secure channel. To explain this, consider the client-server model: basically, the SSH client creates a local proxy server for a remote TCP/IP service. This service can be one of the Internet protocols (pop, smtp and http) or almost any other TCP/IP based service. This local proxy server listens to a socket on the desired port, forwards the request and data over the secure channel and instructs the SSH server to connect on the specified port of the remote machine. This might be better explained with an example: Consider three hosts, X, Y, and Z. Host X is the client and establishes a session with Y, the server, via ssh. A port on X, say 1999 is setup to be forwarded to another port on the remote host Z, say 23. This port is forwarded over the encrypted tunnel to Y, which sends it then unencrypted to host Z's port 23. Thus, the command “telnet localhost 1999” would result in a telnet connection being established with host Z, passing over the encrypted tunnel to Y.

The SSH Protocol Figure 1: Port forwarding technology

The only noticeable change is that the client application is configured to connect to the local proxy instead of the remote server.

The SSH Protocol Unit 2 : PKI Applications (Lab Exercises)


2.5.2. Host Authentication As mentioned above, host authentication is one of the key features offered by the SSH protocol. Let’s have a quick oversight of this process illustrated by the figure hereunder:

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

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



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

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

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

Cipher SSH1 SSH2 RSA yes yes DSA no yes




Objective The student will learn how to use SSH to replace a standard telnet connection. In order to do so, he will use two authentication mechanisms. The student will also learn how to setup a SSH tunnel.

Scenario The Management wants to implement a very secure solution to replace “telnet” for Unix station management. They want to use a strong encryption and a strong authentication. The Management wants also to implement a SSH tunnel to access an Intranet server from Internet

Main steps 1. Use Telnet to connect to a Linux box 2. Use SSH with standard password to connect to a Linux box 3. Use SSH with Public Key authentication to connect to a Linux box 4. Use SSH tunnel to connect to an Intranet server

Time 60 minutes



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

• Authenticate yourself to newton.pki.datelec.com using a standard username (your hostname) and a password (abc123).

• Have a look at the instructor’s sniffer. • What do you see? • Now you can quit SecureCRT.



Step 2: Use SSH with standard password to connect to a Linux box • Connect yourself to newton.pki.datelec.com using SSH2 with a standard password as

authentication. • Run SecureCRT and choose Newton-SSH-Pass session.

• SecureCRT will ask you to accept the “newton’s public key”. • Press Accept and Save. • Can you affirm that this is really the “newton’s public key”? • Think about it!

• Authenticate yourself to newton.pki.datelec.com using a standard username and a password.



• Have a look at the instructor’s sniffer. • What do you see?

• You can quit SecureCRT.



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



You will define a new SSH session using a PublicKey authentication method by proceeding as follows:

Name: Newton-SSH-key Protocol: SSH2 Hostname: newton Port: 22 Username: your-site (here for instance londres) Cipher: 3DES Mac: MD5 Authentication: PublicKey SSH server: DataFellows 2.0.13



• SecureCRT will propose you to generate a key-pair. • Press Yes. • SecureCRT will generate an identity file.

• Press Create Identify File.

• Press Next in the Key Generation Wizard.



• Enter a Passphrase to protect your private key. You will use this Passphrase to lock or unlock your private key.

• Choose the key length: here 1024 bits.

• SecureCRT will now generate the keys using the mouse movements as a seed

(Random number).



• When the generation is done press Finish.

• On your local station, go to directory c:\program file\SecureCRT 3.0\. • With Notepad open “identity.pub”. • Copy the public key on your clipboard.



In order to place your public key on the SSH server (newton.pki.datelec.com), proceed as follows: • Connect yourself to newton.pki.datelec.com using SSH with standard password as authentication.

Run SecureCRT and choose Newton-SSH-Pass session. • Go to ~/.ssh2 directory (cd .ssh2 from your home directory). • Using “vi” create a file called “your-site.pub” (for instance londres.pub). • Paste the public key.

• Using “vi” create and edit a file called “authorization”. • Add the name of the public key file: Key your-site.pub (Tabulation). • The account is now ready to be accessed, using public key authentication from a client that

holds the correct identity file (containing the private and public key-pair). • Connect yourself to newton.pki.datelec.com using SSH with Public Key as authentication. • Run SecureCRT and choose Newton-SSH-Key session. • Now you will be prompt to enter the Passphrase.

• Now you are ready to setup a tunnel using SSH2



Step 4: Use SSH tunnel to connect to an Intranet server To simulate the Intranet server we will use www.cisco.com as URL. • Run SecureCRT and choose New Session.

• You will define a new session using SSH2 and a password authentication method, by proceeding as follows:

Name: Newton-SSH-Tunnel Protocol: SSH2 Hostname: newton Port: 22 Username: your-site (here for instance londres) Cipher: 3DES Mac: MD5 Authentication: Password SSH server: DataFellows 2.0.13



• To configure the tunnel, go to the Advanced menu. • Select Port Forwarding menu. • Define tunnel parameters by proceeding as follows:

Local port: 1234 Remote hostname: www.cisco.com Remote port: 80

• Press Save.

• Press OK. • And press OK to terminate the session definition. • Now connect yourself to newton.pki.datelec.com using the new session.

• Authenticate yourself with standard username and password and minimize the SecureCRT

application. • Check if the tunnel’s entry is listening on port 1234. On Command Prompt run the command

“netstat –a” and have a look. • 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?

• Now you are finished with the SSH lab…

Unit 2 : PKI Applications (Lab Exercises) S/MIME


2.6. S/MIME For a theoretical introduction, please refer to the book “Digital Certificates” written by Jalal Feghhi, Jalil Feghhi and Peter Williams.


Objective The student will setup an e-mail system using S/Mime. He will have to use Digital Signature and Encryption. Moreover, the student will use LDAP protocol to retrieve X.509 certificates.

Scenario The Management now wants to implement encryption and digital signature for the corporate E-mail system. Due to management issues, all certificates are stored inside a directory server which is requested via LDAP. You will use an internal CA and it will be Keon 5.5 from RSA Security.

Main Steps 1 Request a client certificate from a Certification Authority (CA) 2 Install on your browser the certificate sent to you by the CA 3 Send a signed e-mail to your partner 4 Send an encrypted e-mail to your partner 5 Send a signed and encrypted e-mail to your partner 6 Getting a certificate via a LDAP request

Time 45 minutes

S/MIME Unit 2 : PKI Applications (Lab Exercises)


Step 1: Request a client certificate from a Certification Authority (CA) • Now you can enroll for a client certificate. Via the browser, connect to the Keon

Subscriber Services (http://cerbere.pki.datelec.com). • Choose Datelec – PKI Training jurisdiction. • Choose Enroll for a Personal Certificate.



• Enter Enrollment information: First Name Last Name E-mail Address (Important) Title

• Enter your Challenge Phrase (for revocation, etc.). • Choose Signing and Encryption. • And then press Accept.



• Your browser will now generate a Private key that will be stocked on the local disk.

• Enter a PIN code to protect your KEY.



• Now the enrollment is completed. Please wait in order to get your certificate. If the CA agrees to issue a certificate for you, you will be notified by e-mail.

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



Step 2: Install on you browser the certificate sent to you by the CA • Via the browser connect to the retrieving menu (http://cerbere.pki.datelec.com/getid.htm). • Paste your PIN number and press Submit.



• Go to menu Security Info.



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



Step 3: Send a signed e-mail to your partner • Choose your partner to exchange an e-mail (Example: Londres and Rome).

Note: the certificate will be exchanged the first time by sending a signed message. We will not use a directory server LDAP to retrieve certificate. However, in a real deployment, it will work with LDAP.

• Now you are ready to send a signed e-mail to your partner. Note: this lab will be performed on both sites, your partner will also send you a signed e-mail.

• Send e-mail with option Signed.



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

• To verify, click on the “Signed” icon. You will be able to identify the sender. • Now you can reply to the sender with an encrypted e-mail.



• To view the sender’s Certificate, click to “View/Edit” button.

• Note: the sender’s certificate has automatically been added to your list of People’s Certificates, in

order to make it possible for you to send a secure mail to this person.



Step 4: Send an encrypted e-mail to your partner • Now you are ready to send an encrypted e-mail to your partner.

Note: this lab will be performed on both sites, your partner will also send an encrypted e-mail to you.

• Send e-mail with option Encrypted.



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



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



Step 5: Send a signed and encrypted e-mail to your partner • Now you are ready to send an encrypted and signed e-mail to your partner.

Note: this lab will be performed on both sites, your partner will also send an encrypted and signing e-mail to you.

• Send e-mail with option Encrypted and Signed.



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



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



Step 6: Getting a certificate via a LDAP request • Choose Security info/ Other people’s certificates

• You will now send your LDAP request by selecting Search Directory. Select the Datelec directory

server and enter the Email address of the partner whose certificate you want to obtain.

• Note: the sender’s certificate has automatically been added to your list of People’s Certificates in order to make it possible for you to send a secure mail to this person. Repeat this step for all your partners and try to send encrypted/signed Email

• You just finished your S/MIME, congratulations!

Unit 2 : PKI Applications (Lab Exercises) SSL (Secure Socket Layer)


2.7. SSL

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

2.7.2. Secure Sockets Layer (SSL) The Secure Sockets Layer protocol is a protocol layer, which may be placed between a reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides for secure communication between client and server, by allowing mutual authentication, the use of digital signatures for integrity and encryption for privacy. The protocol is designed to support a range of choices for specific algorithms used for cryptography, digests, and signatures. It allows use of algorithm selection for specific servers, based on legal, export or other concerns, and also enables the protocol to take advantage of new algorithms. Choices are negotiated between client and server while starting to establish a protocol session.

SSL Table 1 There are a number of versions of the SSL protocol, as shown in Table 1. As noted there, one of the benefits in SSL 3.0 is that it adds support for certificate chain loading. This feature allows a server to pass a server certificate along with issuer certificates to the browser. Chain loading also permits the browser to validate the server certificate, even if Certificate Authority certificates are not installed for the intermediate issuers, since they are included in the certificate chain. SSL 3.0 is the basis for the Transport Layer Security [TLS] protocol standard, currently in development by the Internet Engineering Task Force (IETF).

SSL (Secure Sockets Layer) Unit 2 : PKI Applications (Lab Exercises)


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

SSL Figure 1

The elements of the handshake sequence, as used by the client and server, are listed below: 1. Negotiate the Cipher Suite to be used during the data transfer 2. Establish and share a session key between client and server 3. Optionally authenticate the server to the client 4. Optionally authenticate the client to the server



The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite is defined by the following components: 1. Key Exchange Method 2. Cipher for Data Transfer 3. Message Digest for creating the Message Authentication Code (MAC) These three elements are described in the following sections.

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

2.7.5. Cipher for Data Transfer SSL uses the conventional cryptography algorithm (symmetric cryptography) described earlier for encrypting messages in a session. There are nine choices, including the choice to perform no encryption: 1. No encryption Stream Ciphers 2. RC4 with 40-bit keys 3. RC4 with 128-bit keys CBC Block Ciphers 4. RC2 with 40 bit key 5. DES with 40 bit key 6. DES with 54 bit key 7. Triple-DES with 168 bit key 8. Idea (128 bit key) 9. Fortezza (96 bit key)

• "CBC" refers here to Cipher Block Chaining, which means that a portion of the previously

encrypted cipher text is used in the encryption of the current block. • "DES" refers to the Data Encryption Standard, which has a number of variants (including

DES40 and 3DES_EDE). • "Idea" is one of the best and cryptographically strongest available algorithms. • "RC2" is a proprietary algorithm from RSA DSI.



2.7.6. Digest Function The choice of digest function determines how a digest is created from a record unit. SSL supports the following: • No digest (Null choice) • MD5, a 128-bit hash • Secure Hash Algorithm (SHA-1), a 160-bit hash The message digest is used to create a Message Authentication Code (MAC), which is encrypted with the message to provide integrity and to prevent replay attacks.

2.7.7. Handshake Sequence Protocol The handshake sequence uses three protocols: • The SSL Handshake Protocol for performing the client and server SSL session establishment. • The SSL Change Cipher Spec Protocol for actually establishing agreement on the Cipher Suite

for the session. • The SSL Alert Protocol for conveying SSL error messages between client and server. These protocols, as well as application protocol data, are encapsulated in the SSL Record Protocol, as shown in Figure 2. An encapsulated protocol is transferred as data by the lower layer protocol, which does not examine the data. The encapsulated protocol has no knowledge of the underlying protocol.

SSL Figure 2 The encapsulation of SSL control protocols by the record protocol means that if an active session is renegotiated, the control protocols will be transmitted securely. If there was no session before, the Null cipher suite is used, which means that there is no encryption. Moreover, messages have no integrity digests until the session has been established.



2.7.8. Data Transfer The SSL Record Protocol, shown in Figure 3, is used to transfer application and SSL Control data between the client and the server, fragmenting possibly this data into smaller units, or combining multiple higher level protocol data messages into single units. It may compress, attach digest signatures and encrypt these units before transmitting them using the underlying reliable transport protocol (Note: all major SSL implementations lack currently support for compression).

SSL Figure 3 One common use of SSL is to secure Web HTTP communication between a browser and a webserver. This case does not preclude the use of non-secured HTTP. The secure version is mainly plain HTTP over SSL (named HTTPS), but with one major difference: it uses the URL scheme https rather than http and a different server port (by default 443).




Objective The student will setup a SSL web server using Netscape Enterprise Server.

Scenario The Management wants to implement an intranet server using SSL for your enterprise. You will use an internal CA to certify this Intranet server.

Main steps To enable SSL on your server, you must complete the following steps: 1. Generate your server’s key-pair file (public and private keys) 2. Request a certificate from a Certification Authority (CA) 3. Install the CA certificate that has been sent to you

Time 1 hour

Unit 2 : PKI Applications (Lab Exercises) SSL (Secure Sockets Layer)


Step1: Generating a key-pair-file A key-pair file contains the public and private keys used for SSL encryption. You use the key-pair file when you request and install a certificate. The key-pair file is stored encrypted in the directory <server_root>/alias/<alias>-key.db. When you create the key, you have to specify a password that will be used later while starting a server using encrypted communications. • Go to the <server root>/bin/admin/admin/bin directory. • Run the sec-key.exe application. The key-pair file generation program appears. • When prompted, type an alias for the new key-pair file. You may choose an alias that matches

your server (for instance, web or mail). The alias cannot contain spaces, but it can use symbols that your operating system accepts in filenames (such as hyphens and underscores).



• A screen with a progress meter appears. Move your mouse in random motions at random speed. These random movements are used to generate a random number for the unique key-pair file.

• When prompted, type an eight-character (or more) password for your key-pair file. The password must have at least one non-alphabetical character (a number or punctuation mark). Make sure you memorize this password. The security of your server is only as good as the security of the key-pair file and its password. After you turn on “SSL for a server” (either the administration server or another Netscape server), you must type the key-pair file password when you start the server.

• Retype the password and click OK. The file is created and stored.



• Return to the Server Manager forms (http://yoursite:6969). • Enter username admin and password abc123.



• Go on Request Certificate menu.



• After you generate a key-pair file, you can request a certificate from a Certification Authority (CA). In the Server Administration page, choose Keys & Certificates / Request Certificate.

• In the form that appears, specify if you want a new certificate or a renewal. • Specify how you want to submit the request for the certificate. In your case it will be by mail

at: [email protected]. • 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: [email protected] (enter your email address) Organization: Datelec (very important) Organizational unit: PKI Training (very important) Locality: Geneva State or Province: GVA Country: CH

NB: Print screen on top of following page



• If every field is all right, press OK.



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



Step 2: Request a certificate from a Certification Authority (CA) • Now, you are ready to submit the request to the certificate server (Keon). Via the browser,

connect to the Keon Subscriber Services (http://cerbere.pki.datelec.com). • Choose PKI Training jurisdiction – Datelec.



• Choose Enroll for a server Certificate.



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

• Press submit.



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



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



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



Step 3: Install the CA certificate that has been sent to you • Now you are ready to install the certificate on the Netscape server. • In the Server Administration page, choose Keys & Certificates / Install Certificate. • Choose This Server under Certificate For. • Paste the e-mail text in the field called Message text. Be sure to include the headers "Begin

Certificate" and "End Certificate." Do not forget to check the corresponding button for either the file or the text.

• From the drop-down list, select the alias you used when you requested the certificate. If you choose the incorrect alias, the certificate will not be installed.



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

• Now you can activate SSL for your server.



• Select Server Administration. (Very important!) • Select your web site, in Server Preferences menu choose Encryption On/Off. The Encryption On/Off

form appears. • Check the On button. • In the drop-down list, choose the alias for the key-pair file and certificate file that you want to

use. You must know the password for the key-pair file referenced by this alias. It is the password you must enter before starting or stopping a server that uses SSL encryption.



• Press Save and Apply Changes.



• The server will restart and you have to enter the password.

• Now you are ready to test the SSL web server. With your broswer connect to

https://you-site.pki.datelec.com. • To see info on Netscape, go to Security Info menu.



• Go to Open Page Info.




Objective Student will setup a SSL client authentication to protect the access to Intranet server.

Scenario The Management wants now to implement a strong authentication based on SSL client certificate to be able to access the Intranet.

Main Steps To enable SSL authentication on your server, you must complete these steps: 1. Import CA’s root certificate on the web server 2. Configure the web server to ask a client SSL certificate for authentication 3. Request a client certificate from a Certification Authority (CA) 4. Install on your browser the CA certificate that has been sent to you

Time 1 hour



Step 1: Import CA’s root certificate on the web server In order to be able to verify the client certificate, the web server has to know the root certificate who deliver the client certificate. In this case it will be the internal CA Keon. • Go to the Subsciber Services to pick up the Keon’s root certificate. Choose Menu Trusted Root

Services / View Server Trusted Root (http://cerbere.pki.datelec.com).



• Copy this certificate on your clipboard.



Step 2: Configure the web server to ask client SSL certificate for authentication • In the Server Administration page, choose Keys & Certificates / Install Certificate. • Choose Certificate For / Trusted Certificate Authority (CA). • Paste the Keon’s roots certificate in the field called Message text. Be sure to include the headers

"Begin Certificate" and "End Certificate." Do not forget to check the corresponding button for either the file or the text.

• From the drop-down list, select the alias you used when you requested the certificate. If you choose the incorrect alias, the certificate will not be installed.

• Press OK.



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



• In Server Administration select your site and choose Server Preferences and Admin Preferences /Encryption Preferences. Under Require Client Certificates choose Yes.

• Press OK and save. • Enter a password. • Now the web server SSL is ready to ask client authentication to access to web pages.



Step 3: Request a client certificate from a Certification Authority (CA) • Now you can enroll for a client certificate. Via the browser, connect to the Keon Subscriber

Services (http://cerbere.pki.datelec.com). • Choose Datelec – PKI Training under Jurisdictions.



• Choose Enroll for a Personal Certificate.



• Enter the following Enrollment Information : First Name Last Name Email Address (Important) Title

• Enter your Challenge Phrase (for revocation, etc.). • Choose Signing and Encryption. • Press Accept.



• Now your browser will generate a Private key. This key will be stocked on the local disk.

• Enter a PIN code to protect your KEY. • Now the enrollment is completed. Wait until you get your certificate. If the CA agrees to issue

a certificate for you, the CA will inform you by e-mail.



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



Step 4: Install the certificate the CA send to you on your browser • Via the browser, connect yourself to the retrieving menu

(http://cerbere.pki.datelec.com/getid.htm). • Paste your PIN number and press Submit.



• Wait until you get the message shown hereafter. • Your client certificate is now ready.

• You are ready to test the SSL web server. With your browser, connect yourself to https://you-site.pki.datelec.com.

• Your browser will ask you a client certificate to authenticate yourself. • Select your certificate.

• Enter your PIN code to unlock the private key.



• Now you are authenticated and connected to your SSL web site

• To see your client certificate, Go to the Security Info menu.

• Choose Certificates / Yours.



• Then, choose View.

• Now, you are finished…

Smart Card Unit 2 : PKI Applications (Lab Exercises)


2.8. SMART CARD


Objective Student will install a smartcard reader on his personal computer. This smartcard will be used in next labs.

Scenario The Management wants now to implement a corporate extranet solution. The content of the extranet being highly sensitive, the top management wants the authentication to be based on smartcards.

Main Steps To activate the smartcard reader on your PC, follow these steps: 1. Installation 2. Verification 3. our browser the CA certificate that has been sent to you

Time 15 minutes

Step 1: Installation • Your reader is physically connected to your PC through the serial interface. In c:\smartcard

double click setup.exe and choose following options

• Then Choose COM1…

Unit 2 : PKI Applications (Lab Exercises) Smart Card


• Finish the installation by restarting the computer and then choosing to install the security

module on netscape. • Close netscape in order to load your environment

Step 2: Verification • Launch Netscape browser, select Security / Cryptographic module following content should

appear

• Smartcard installation done! •

Playing the Security Officer Unit 2 : PKI Applications (Lab Exercises)


2.9. PLAYING THE SECURITY OFFICER


Objective Student will request a certificate that will be stored on smartcard. The student will carry the security engineer task to validate his certificate request

Scenario Same scenario as lab exercise 9

Main Steps 1. Certificate enrollement 2. Security engineer validates the certificate request 3. Pushing the certificate on the smartcard

Time 30 minutes

Step 1: Certificate enrollement • Connect to http://cerbere and follow almost the same procedure as in S/MIME lab. The

only difference appears when Keon triggers Netscape RSA key pair generation. You have now the choice between storing the key material in smartcard container or in netscape software key container. Select ActivCard module

• Enrollement is now finished

Unit 2 : PKI Applications (Lab Exercises) Playing the Security Officer


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

digital ID to authenticate yourself as a security officer.

• Choose certificate management/ process request you should see your own certificate request waiting

to be validated

• Click on approve and you see the acknowledgment • Note: don’t close the Netscape browser before next step

Playing the Security Officer Unit 2 : PKI Applications (Lab Exercises)


Step 3: Pushing the certificate on the smartcard • Open your netscape messenger and connect to the certificate retrieval page using the PIN

received by mail • Choose continue and it will install the certificate on your smartcard • Now you are ready to proceed to next lab

Unit 2 : PKI Applications (Lab Exercises) Revocation with client SSL authentication


2.10. REVOCATION WITH CLIENT SSL AUTHENTICATION


Objective Use the key material stored on smartcard to authenticate the access to extranet. Certificate validity is checked against a CRL repository.

Scenario Your management wants to provide revocation mechanism in order to guarantee high security access that fits to the corporate structure.

Main Steps 1. Connect and authenticate yourself using your smartcard 2. Play the security officer revoking a certificate 3. Try again and interpret the experience

Time 30 minutes

Step 1: Connect and authenticate yourself using your smartcard • Connect to extranet server https://ayrton.datelec.ch • enter pin code to unlock your smartcard

• Choose your certifcate

• You’ve authenticated successfully against the server

Revocation with client SSL authentication Unit 2 : PKI Applications (Lab Exercises)


Step 2: Play the security officer revoking a certificate • Connect to CA admin page (https://cerbere.pki.datelec.com:445/home.htm) using your x.509

digital ID to authenticate yourself as a security officer.

• Choose certificate management/revoke certificate you should see the following window

Unit 2 : PKI Applications (Lab Exercises) Revocation with client SSL authentication


• You can select one of the certificates and revoke it by choosing revoke. A revocation reason is required

Revocation with client SSL authentication Unit 2 : PKI Applications (Lab Exercises)


• Press revoke and the following window should appear; read carefully the message…

• Ask the CA’s super-administrator to force the immediate handling of your revocation on the CA

and extranet application. Once done, try again and your access should be revoked.

Unit 2 : PKI Applications (Lab Exercises) IPSEC


2.11. IPSEC

2.11.1. Introduction As the reader will understand at the sight of such a chapter name, IPSec’s goal is to provide a protocol to Secure IP protocol. More precisely, it is to provide both integrity and confidentiality of IP packets. Before entering into the details of the IPSec structure, let us recall an old drawing of different security schemes for different level of IP datagram.

IPSec Figure 1: Encryption and OSI layer

Basically, IPSec will deal with IP datagram encapsulation inside IPSec packets, hence it will provide security to network layer. The idea in this picture is that the further down you go, the more transparent you are and the further up you go, the easier it is to deploy. Hence, IPSec will be the most transparent PKI based solution that we’ll talk about in this lecture. In fact, for some people IPSec might not be part of PKI as for others it would. For us, PKI is some kind of generic expression to be understood as a set of components bringing authenticity and confidentiality to traffic or message sent across an untrusted backbone (internet is only an example). Consequently, IPSec will deal with exactly the same concept we defined above: symmetric encryption, public/private keys, hash functions, x.509 certificates, CA, key exchange, etc. This chapter will try to show the student how to integrate these tools to provide confidentiality, authenticity and non-repudiation to network layer…

IPSEC Unit 2 : PKI Applications (Lab Exercises)


2.11.2. IPSec Architecture The IPSec is defined by people of a working group being part of the “Internet Engineering Task Force” (IETF). The definition of the protocol is summarized into around 15 RFCs. We will try to concentrate their contents into the most easily digestible form as possible. First of all, let us start by an IPSec oversight showing the relationship between the different subsets of IPSec.

IPSec Figure 2: IPSec components and their interaction

First of all, the drawing shows that IPSec is based on two main protocols (or sub-protocols), ESP (Encapsulation Security Payload) and AH (Authentication Header). The reason is that IPSec has two main requirements: provide “confidentiality” as well as data “integrity”. Confidentiality is achieved by ESP protocol and integrity can be achieved either by ESP or AH protocols. To achieve their task, these protocols used define-as-standard algorithms like DES, 3DES or Blowfish for encryption and MD5, SHA1 for authentication via message digest. As we already saw, these algorithms are binded to keys (session keys, private and public keys), which are handled (or even defined) after a key management process. IKE (or Internet Key Exchange) protocol is the chosen standard for IPSec key management. However, IKE is not dedicated to IPSec hence is generic enough to be implemented as a support for many protocols (SSH, SSL, OSPF etc…). Consequently, the presence of a Domain Of Interpretation (DOI) is needed in order to define the parameters that are negotiated by IKE. Besides, another component is needed in order to determine if two entities have the right to communicate and if so, the kind of encryption algorithm or hash function to agree with this component called Policy.



2.11.3. IPSec Tunneling AH and ESP can be used to protect either the entire IP datagram or only the payload (data). In IPSec this is translated by the existence of two different modes, the tunnel mode and the transport mode. In transport mode, an IP header is inserted between the IP header and the upper-layer protocol headers, as shown here under: Original IP packet Transport mode In tunnel mode, the entire IP packet is encapsulated in a new datagram with a new IP header. An IPSec header is added in between the encapsulation and the new header, as shown hereunder:

Tunnel mode 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.

IP header tcp header Data

IP header IPsec header tcp header Data

IP header Ipsec header IP header tcp header Data



IPSec Figure 3: IPSec based VPN In this drawing, the importance of a certified tunnel is shown. Students should be aware that other protocols like PPTP (Point to Point Tunneling Protocol) or L2TP (Layer 2 Tunneling Protocol) offer only tunneling, compared to IPSec that offers encryption, authentication as well as tunneling. This is the reason why we think that it is less likely that IPSec fall into an eventual dying standard category.

SA (Security Associations) Before going deeper into AH and ESP protocols, we want to define the SA concept, which will be very often referred to when talking about IPSec… The goal of Security Associations (SA) is to maintain the agreements that enable two parties to exchange secure data. Each connection between two security gateways will require a unique SA. An exchange between two peers that involves both authentication and encryption requires two Security Associations, one for agreements regarding authentication and one for agreements about the encryption. As negotiation always precedes agreements, SA needs to be negotiated between gateways. For example one might have a gateway able to perform DES and Blowfish encryption, as another might be able to run only DES algorithm, hence the negotiation will reach the agreement of using DES encryption. In order to be quantified, all SAs are indexed or identified by a number called the Security Payload Index (or SPI) which will appear in the IPSec headers.



Security Associations are set up between pairs of communicating hosts. These SAs contain the agreements that are specific to the transfer of data between the two parties. These specific agreements do not apply to communication that may take place with any other party. Each Security Association maintains agreements about shared session keys, the IP addresses of the pair of IPSec compliant gateways, the IP addresses of protected hosts or subnets, and related parameters regarding the expiration of session keys (i.e., when the session keys must be re-generated). Once the session keys reach a defined expiration time, a new Security Association must be established, thereby ensuring on going SA (or Security Associations).

AH As we saw already, AH is the protocol that will provide authentication and data integrity but will not provide data confidentiality. Hence, the header will be quite simple and no field of this header will be in clear or plaintext form. AH is a new IP protocol whose value are 51. The AH header contains a SPI to define the SA with which the packet is processed and a data authentication field. To understand how to process such an authentication let us recall that until now, we have bound authentication to a digital signature concept. In the case of IP packet authentication, it would not be reasonable to proceed that way because processing public key algorithm is very CPU demanding. A simple way to proceed could be to process the whole IP datagram into a hash function and define the resulting message digest as the authentication packet (hash functions are not much CPU consuming…). This might sound as an interesting workaround but as the student should know at this step of the lecture, performing hash doesn’t provide a real authentication. Effectively any eventual eavesdropper could change the IP datagram, reapply the hash and replace the authentication packet with this message digest!



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

IPSec Figure 4: MAC

The idea here is to add a p reshared key to a stream of data (for example an IP datagram), the result is a new stream of data. Then it goes through a hash function and the resulting message digest is the MAC. The MAC and the SPI will form the AH header. The remote IPSec gateways verify authenticity and integrity of the IP datagram simply by processing it with his secret key (supposed to be the same) into the hash function. In this case, an eavesdropper couldn’t reproduce the MAC because he is not supposed to hold the secret key. Note: Despite the similarity, MAC is conceptually very different from digital signature. For example, digital signature (based on public key cryptosystem) offers non-repudiation, which is not the case with MAC.

IPSec Figure 5: An AH protected packet A special kind of MAC is called HMAC. Without giving details, it is basically a keyed hash inside a keyed hash, in order to enforce the MAC concept. Practically, HMAC are used to generate IPSec Authentication Headers. In term of policy definition they appear as HMAC-SHA1 or HMAC-MD5 etc.

ESP ESP is the IPSec protocol to provide confidentiality, data integrity and data source authentication of IP packets. It does so by inserting a new header after an IP header and before the data to be protected. Encrypted Authenticated

IPSec Figure 6: An ESP protected packet

AH header tcp header DatasIP header

ESP header Protected data

ESP trailerIP header



Since ESP provides both confidentiality and authentication, its SAs contains the cipher and the authenticator. We can see the ESP header as the AH header plus data specific to the encryption part. It is possible for an ESP header to have a null cipher or a null authenticator but it is illegal for both to be set as null! The ESP header is not encrypted, this is because it contains for example the SPI which, together with source/destination IP, identify the SA and by consequence the cipher needed to decrypt cipherdata. In addition, sequence number and authentication data are in clear, this is due to the order of processing ESP packets: first check the sequence number, then data integrity and finally decrypt data. Contrarily to the header, the ESP trailer can be partly encrypted as long as enough information is kept clear to allow the packet to be processed.

IKE An important process in IPSec is key management. IPSec supports both manual exchanges of keys (e.g., telling the other party verbally or delivering a written copy) as well as automatic key exchange using IKE. IKE is designed to provide: • The means for parties to agree on which protocols, algorithms and keys to use. • Confirmation that the party you are communicating with is in fact who they say they are. • Management of keys after they have been agreed upon Automatic key management is the procedure that generates the session keys that are used by certified peers for encrypting and authenticating data packets. Key management can be performed automatically whenever data is transferred to a new trusted peer, and as an ongoing process to ensure that session keys are changed regularly. Each side of a communication needs to generate unique pairs of shared session keys between itself and the party it wants to communicate with. One key is used for data encryption, and the other key is used for data Authentication (see keyed MAC described above). Encryption is performed using an agreement upon algorithm, such as DES. Authentication may be performed using one of several standard message digest algorithms – HMAC-MD5 etc. All the essential information required for this communication is defined within a SA. This includes the shared session keys, the IP addresses of participating IPSec compliant gateways, the IP addresses of the protected hosts or subnets, and other important related parameters (such as how often to change the keys). A distinct Security Association is created for each pair of protected hosts or subnets. A pair of session keys is unique to a pair of protected hosts or subnets. The pair of keys is also unique to the direction of the data flow. For data that is sent from one IPSec gateway to another, a unique pair of session keys is required. If the other gateway needs to send data to the first, another unique pair of session keys is required. In other words, only one device can use a unique session key for data encryption, while the other device in the pair uses that same key for decryption. Thus, a single session between two hosts or subnets may involve four keys.



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

IKE main mode The IKE main mode process comprises three phases (each phase consists of two messages): 1. Cookie and SA Proposal Exchange 2. Diffie-Hellman Exchange 3. Authentication Information Exchange

Cookie and SA proposal exchange The Cookie Exchange, the first phase of the IKE main mode, prevents an IPSec compliant gateway from initiating the key management process with an unrecognized party. The Cookie is a token that is derived from the gateway’s IP address and generated by each gateway by hashing together a unique secret (the peer’s identity) and a time-based counter (for the casual observer, it will look like a random number). Verification of the cookie ensures that the key management process is taking place within the appropriate session, with the correct peer. Thus, cookie exchange provides some kind of limited denial of service attack. With the initiator cookie, an SA (Security Association) proposal is sent. This proposal contains the IKE SA parameters suggested by the initiator (such as the encryption and authentication algorithms, lifetime of this SA, etc.).

Diffie-Hellman exchange The Diffie-Hellman Exchange phase generates the shared secret from which the symmetric IKE keys are derived. Both peers are involved in this process. The devices generate the Diffie-Hellman components using a real random number generator. Each IPSec compliant device generates a part of the shared secret and sends a copy of it to the other device. Each device combines its own number with the number received. By the end of the Diffie-Hellman exchange, both devices possess a single, unique shared secret.



The benefit of Diffie-Hellman is that it prevents a physical key exchange, moreover if an eavesdropper intercept any parameters exchanged, he can’t deduce shared secret (For a complete description algorithm, refer to the book “Applied Cryptography” by B. Schneier, referred in the Bibliography).

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

IKE quick mode (or Aggressive Mode) The IKE quick mode process comprises three messages: 1. SA Proposal 2. SA Response 3. SA Acknowledgment

SA proposal This message comprises the parameters of the tunnel protection, proposed by the initiator (algorithms, lifetime, etc.), the IP address of the host or the subnet that will use this tunnel, and an optional Diffie-Hellman component. Enhanced security can be obtained by using the ‘Perfect Forward Secrecy’ option, which prevents any association between successive session keys. This may, however, affect the key exchange performance, as each exchange will take longer. ‘Perfect Forward Secrecy’ means that the optional Diffie-Hellman component will be sent.

SA response This message comprises the parameters of the tunnel protection selected by the responder (algorithms, lifetime, etc.) and the IP address of the host or the subnet that will use this tunnel. If the SA proposal contains a Diffie-Hellman component, the SA response also contains a Diffie-Hellman component. If Diffie-Hellman is used, both sides generate a shared secret using Diffie-Hellman, like they did in the main mode. Otherwise (if not in perfect forward secrecy), a new shared secret is derived from the Diffie-Hellman shared secret generated in the first stage. The message is signed digitally, in a similar way to that described in the Authentication Information Exchange phase of the main mode. The initiator sets the tunnel after sending this message. (Refer to the book “Applied Cryptography” by B. Schneier, mentioned in the Bibliography for a description of the algorithms).



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

Determining the rate of changing keys Though it is difficult to do, the session keys used for encrypting and authenticating data can be guessed by an unauthorized party, damaging the data’s security. Thus, the more frequently a key is changed, the less data will be compromised if the key is discovered. The frequency of changing keys may be determined by time intervals or traffic volume. The user determines when new keys are changed (i.e., when a new quick mode is initiated). The IPSec compliant security gateways determines when to initiate the entire key management process (i.e., initiate a new main mode).

Summary IPSec offers a “layer 3” solution to data privacy being network, application independent and supporting all IP services. IPSec mechanisms are using Diffie-Hellman to deliver secret keys, public key cryptosystem for signing Diffie-Hellman exchanges, symmetric encryption for encrypting data and digital certificates cryptosystem for validating public keys. We can consider IPSec as a condensed of all 3 cryptosystems described in this lecture tightly bound to IP standard. Thus it is likely for IPSec to become a widely used protocol in the years to come…




Objective The student will setup an IPSEC link between a client and an IPSec gateway (FW-1/VPN-1 Checkpoint). He will use IKE protocol for key management and a two factor authentication based on X.509 certificate.

Scenario The Management wants to build a VPN between remote users and a central site protected by a Firewall/IPSec gateway. Due to server heterogeneity, corporate decision was to privilege an IPSec-based solution rather than SSL.

Main steps 1. Configuration of Firewall (done by instructor) 2. Securemote installation

Time 1 hour 30

Step 1: Configuration of Firewall (instructor) • Create a CA server of type: OPSec PKI, choose LDAP Server for CRL retrieval and

deactivate http • Bootstrap Firewall with Root CA certificate • Create LDAP account unit (cerbere, LDAP rights Read) • Firewall Enrollment (DN: CN=IP address), copy CSR and paste on cerbere • Certificate stored in .cert file and imported in firewall • Edit Firewall object/vpn IKE edit and choose public key signature, configure and choose my-

cert. • Edit Firewall object/vpn FWZ, Generate Diffie-Hellman • Manage users and create generic* with IKE encryption and public-key authentication • Add encryption rule and install security policy



Step 2: Securemote installation • Install Securemote client on your PC using source code in c:\sr directory, Choose the

following options :

• Reboot your computer and configure Securemote by importing the site: Site / New 192.168.150.222



• In this lab, we will use the same certificate as the one of S/MIME exercise. Therefore, open your Netscape messenger and export your certificate in PKCS#12 format (Security/Yours/Export…)

• Import your PKCS#12 formatted key material inside Securemote by selecting certificate/import

• Consequently, the key material format will be reformated as follows



• We define which certificate will be used for IPSec client authentication

• Note: by default, Securemote is configured to work with Entrust PKI; therefore don’t forget to disable Entrust intelligence

• Now, try to reach some server behind the firewall, for example telnet 192.168.104.40. You will be prompt for the password protecting the key material as follows

• And if you configured everything correctly…