Chapter-1 Computer and Network Security (Introduction)

What security is about in general?

Security is about protection of assets
 Prevention take measure that prevent your assets from being damaged (or stolen)
 Example: locks at doors, window bars, secure the walls around the property, hire a guard
 encrypt your order and card number, enforce merchants to do some extra checks, using PIN even for Internet
transactions, don’t send card number via Internet
 Detectiontake measure so that you can detect when, how and by whom an asset has been damaged
 missing items, burglar alarms, closed circuit TV
 an unauthorized transaction appears on your credit card statement
 Reaction take measures so that you can recover your assets
 Example: attack on burglar (not recommended ), call the police, replace stolen items, make an insurance claim
 complain, dispute, ask for a new card number, sue (if you can find of course ) Or, pay and forget (a glass
of cold water) 
Information security in past & present
Traditional Information Security
 keep the cabinets locked
 put them in a secure room
 human guards
 electronic surveillance systems
 in general: physical and administrative mechanisms
Modern World
 Data are in computers
 Computers are interconnected
Traditionally information security provided by physical (eg. rugged filing cabinets with locks) and administrative
mechanisms (eg. Personnel screening procedures during hiring process). Growing computer use implies a need for
automated tools for protecting files and other information stored on it. This is especially the case for a shared system,
such as a time-sharing system, and even more so for systems that can be accessed over a public telephone network,
data network, or the Internet.
Computer Security Terminology
 Computer Security
• 2 main focuses: Information and Computer itself
• tools and mechanisms to protect data in a computer (actually an automated information system), even
if the computers/system are connected to a network
• tools and mechanisms to protect the information system itself (hardware, software, firmware, *ware )
 Against?
• against hackers (intrusion)
• against viruses
• against denial of service attacks
• etc. (all types of malicious behavior)
 Network and Internet Security
• measures to prevent, detect, and correct security violations that involve the transmission of information
in a network or interconnected networks

1|Page
Table 1.1 defines terms.
Relationships among the security Concepts

Skill and knowledge required to mount an attack

Discussion: Attacks became more sophisticated to find out and more automated so that any kid can mount.

2|Page
The global average cost of cyber crime/attacks

2017 Cost of Cyber Crime Study by Accenture* Steeper increasing trend in the recent years
Average cost of cyber crime By Country

institutions responded

- Germany has highest percentage increase; - UK, US are around the mean in percentage increase
Breakdown by Sector

2017 Cost of Cyber Crime

Study by Accenture*

- Financial Services Sector

has the Highest Cost due to
Cyber Crime

Types of cyber attacks experienced

-2017 Cost of Cyber Crime Study by Accenture*  Percentage of the respondents experienced Ransomware doubled
Deployment Rate of Security Technologies

-2017 Cost of Cyber Crime Study by Accenture* - Percentage of the respondents experienced Ransomware doubled

3|Page
Security Objectives: CIA Triad and Beyond

These three concepts form what is often referred to as the CIA triad. The three concepts embody the fundamental
security objectives for both data and for information and computing services. For example, the NIST standard FIPS
199 (Standards for Security Categorization of Federal Information and Information Systems) lists confidentiality,
integrity, and availability as the three security objectives for information and for information systems. FIPS 199
provides a useful characterization of these three objectives in terms of requirements and the definition of a loss of
security in each category:
• Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for
protecting personal privacy and proprietary information. A loss of confidentiality is the unauthorized disclosure of
information.
• Integrity: Guarding against improper information modification or destruction, including ensuring information
nonrepudiation and authenticity. A loss of integrity is the unauthorized modification or destruction of information.
• Availability: Ensuring timely and reliable access to and use of information. A loss of availability is the disruption
of access to or use of information or an information system.
Computer Security Objectives
This definition introduces three key objectives that are at the heart of computer security:
• Confidentiality: This term covers two related concepts:
 Data confidentiality: Assures that private or confidential information is not made available or disclosed to
unauthorized individuals.
 Privacy: Assures that individuals control or influence what information related to them may be collected
and stored and by whom and to whom that information may be disclosed.
•Integrity: This term covers two related concepts:
 Data integrity: Assures that information and programs are changed only in a specified and authorized
manner.
 System integrity: Assures that a system performs its intended function in an unimpaired manner, free from
deliberate or inadvertent unauthorized manipulation of the system.
• Availability: Assures that systems work promptly and service is not denied to authorized users.
Additional concepts:

Although the use of the CIA triad to define security objectives is well established, some in the security field feel that
additional concepts are needed to present a complete picture. Two of the most commonly mentioned are as follows:
• Authenticity: The property of being genuine and being able to be verified and trusted; confidence in the validity of
a transmission, a message, or message originator. This means verifying that users are who they say they are and that
each input arriving at the system came from a trusted source.
• Accountability: The security goal that generates the requirement for actions of an entity to be traced uniquely to
that entity. This supports nonrepudiation, deterrence, fault isolation, intrusion detection and prevention, and after
action recovery and legal action. Because truly secure systems are not yet an achievable goal, we must be able to trace
a security breach to a responsible party. Systems must keep records of their activities to permit later forensic analysis
to trace security breaches or to aid in transaction disputes.

4|Page
Services, Mechanisms, Attacks
• 3 aspects of information security:
 security attacks (and threats)actions that (may) compromise security
 security servicesservices counter attacks
 security mechanismsused by services
e.g. secrecy is a service, encryption (a.k.a. encipherment) is a mechanism
Attacks on computer systems
break-in to destroy information
break-in to steal information
blocking to operate properly
malicious softwarewide spectrum of problems
Source of attacks
i. Insiders ii. Outsiders
Network Security
i. Active attacks ii. Passive attacks
Passive attacks
interception of the messages
What can the attacker do?
• use information internallyhard to understand
• release the contentcan be understood
• traffic analysishard to avoid
Hard to detect, try to prevent
Active attacks
 Attacker actively manipulates the communication
 Masquerade
 pretend as someone else
 possibly to get more privileges
 Replay
 passively capture data and send later
 Denial-of-service
 prevent the normal use of servers, end users, or network itself
 deny
 repudiate sending/receiving a message later
 modification
 change the content of a message

5|Page
Security Services
 to prevent or detect attacks
 to enhance the security
 replicate functions of physical documents
• e.g.
• have signatures, dates
• need protection from disclosure, tampering, or destruction
• notarize
• record
Basic Security Services
Authentication
 assurance that the communicating entity is the one it claims to be
 peer entity authentication
 mutual confidence in the identities of the parties involved in a connection
 Data-origin authentication
 assurance about the source of the received data
Access Control
 prevention of the unauthorized use of a resource
 to achieve this, each entity trying to gain access must first be identified and authenticated, so that access
rights can be tailored to the individual
Data Confidentiality
 protection of data from unauthorized disclosure (against eavesdropping)
 traffic flow confidentiality is one step ahead
 this requires that an attacker not be able to observe the source and destination, frequency, length,
or other characteristics of the traffic on a communications facility
Data Integrity
 assurance that data received are exactly as sent by an authorized sender
 i.e. no modification, insertion, deletion, or replay
Non-Repudiation
 protection against denial by one of the parties in a communication
 Origin non-repudiation
• proof that the message was sent by the specified party
 Destination non-repudiation
• proof that the message was received by the specified party
Relationships among integrity, data-origin authentication and non-repudiation

6|Page
Security Mechanisms
Cryptographic Techniques
Software and hardware for access limitations
 Firewalls
Intrusion Detection and Prevention Systems
Traffic Padding
 against traffic analysis
Hardware for authentication
 Smartcards, security tokens
Security Policies / Access Control
 define who has access to which resources.
Physical security
 Keep it in a safe place with limited and authorized physical access
Authentication Exchange
 ensure the identity of an entity by exchanging some information
Notarization
 use of a trusted third party to assure certain properties of a data exchange
Timestamping
 inclusion of correct date and time within messages
Cryptographic Security Mechanisms
Encryption (a.k.a. Encipherment)
 use of mathematical algorithms to transform data into a form that is not readily intelligible
• keys are involved
Message Digest
 similar to encryption, but one-way (recovery not possible)
 generally no keys are used
Digital Signatures and Message Authentication Codes
 Data appended to, or a cryptographic transformation of, a data unit to prove the source and the integrity of the data
And the Oscar goes to …
• On top of everything, the most fundamental problem in security is =>SECURE KEY EXCHANGE
• mostly over an insecure channel
A General Model for Network Security

 using this model requires us to:

• design a suitable algorithm for the security transformation
• generate the secret information (keys) used by the algorithm
• develop methods to distribute and share the secret information
• specify a protocol enabling the principals to use the transformation and secret information for a security service

7|Page
The second model is concerned with controlled access to information or resources on a computer system, in the
presence of possible opponents. Here appropriate controls are needed on the access and within the system, to provide
suitable security.
 using this model requires us to:
• select appropriate gatekeeper functions to identify users and processes and ensure only authorized users and
processes access designated information or resources
• Internal control to monitor the activity and analyze information to detect unwanted intruders
More on Computer System Security
 Based on “Security Policies”
 Set of rules that specify
• How resources are managed to satisfy the security requirements
• Which actions are permitted, which are not
 Ultimate aimPrevent security violations such as unauthorized access, data loss, service interruptions, etc.
 ScopeOrganizational or Individual
ImplementationPartially automated, but mostly humans are involved
Assurance and Evaluation
Assurance: degree of confidence to a system
Security products and systems must be evaluated using certain criteria in order to decide whether they assure security or not
Organizational security policy: Laws, rules, and practices that regulate how an organization manages and protects
resources to achieve its security objectives.
Automated security policy: Restrictions and properties that specify how a computing system prevents security violations.
Aspects of Computer Security
Mostly related to Operating Systems
Similar to those discussed for Network Security
 Confidentiality
 Integrity
 Availability
 Authenticity
 Accountability
 Dependability
Confidentiality
 Prevent unauthorized disclosure of information
 Synonyms: Privacy and Secrecyany differences? Let’s discuss
Integrity
 two types: data integrity and system integrity
 In general, “make sure that everything is as it is supposed to be”
 More specifically, “no unauthorized modification, deletion” on data (data integrity)
 System performs as intended without any unauthorized manipulations (system integrity)
Availability
 services should be accessible when needed and without extra delay
Dependability
 Can we trust the system as a whole?
Accountability
 audit information must be selectively kept and protected so that actions affecting security can be
traced to the responsible party
 How can we do that?
 Users have to be identified and authenticated to have a basis for access control decisions
and to find out responsible party in case of a violation.
 The security system keeps an audit log (audit trail) of security relevant events to detect
and investigate intrusions.
More on integrity: According to Orange Book, data integrity refers to “computerized data are the
same as the source documents”. To implement this we should have a base to compare. It is not so
easy to implement automated processes (internal to computer) for this.

8|Page
Attack Surfaces
 An attack surface consists of the reachable and exploitable vulnerabilities in a system
 Examples:
 Open ports on outward facing Web and other servers, and code listening on those ports
 Services available in a firewall
 Code that processes incoming data, email, XML, office documents, etc.
 Interfaces and Web forms
 An employee with access to sensitive information vulnerable to a social engineering attack
An attack surface consists of the reachable and exploitable vulnerabilities in a system [MANA11, HOWA03].
Examples of attack surfaces are the following:
 Open ports on outward facing Web and other servers, and code listening on those ports
 Services available on the inside of a firewall
 Code that processes incoming data, email, XML, office documents, and industry-specific custom data
exchange formats
 Interfaces, SQL, and Web forms
 An employee with access to sensitive information vulnerable to a social Engineering attack
Attack Surface Categories
Attack surfaces can be categorized as follows:
 Network attack surface: This category refers to vulnerabilities over an enterprise network, wide-area
network, or the Internet. Included in this category are network protocol vulnerabilities, such as those used
for a denial-of-service attack, disruption of communications links, and various forms of intruder attacks.
 Software attack surface: This refers to vulnerabilities in application, utility, or operating system code. A
particular focus in this category is Web server Software.
 Human attack surface: This category refers to vulnerabilities created by personnel or outsiders, such as
social engineering, human error, and trusted insiders.
Fundamental Dilemma of Security
“Security unaware users have specific security requirements but no security expertise.”from D. Gollmann
• Solution: level of security is given in predefined classes specified in some common criteria
• Orange book (Trusted Computer System Evaluation Criteria) is such a criteria.
Fundamental Tradeoff
• Between security and ease-of-use
• Security may require clumsy and inconvenient restrictions on users and processes
“If security is an add-on that people have to do something special to get, then most of the time they will not get it”
Martin Hellman, co-inventor of Public Key Cryptography.
There is a similarity between security and taxation. Jean Baptiste Colbert (French Economist and Minister of Finance under
King Louis XIV of France. 1619-1683) once said that “The art of taxation consists in so plucking the goose as to obtain
the largest possible amount of feathers with the smallest possible amount of hissing”. The main story behind security
measures is also the same. If the security measures are too tight, most probably people will try to circumvent it.
Good Enough Security
“Everything should be as secure as necessary, but not securer” Ravi Sandhu, “Good Enough Security”, IEEE Internet
Computing, January/February 2003, pp. 66- 68.
• Read the full article at http://dx.doi.org/10.1109/MIC.2003.1167341
Some Other Security Facts
 Not as simple as it might first appear to the novice
 Must consider all potential attacks when designing a system
 Generally yields complex and counterintuitive systems
 Battle of intelligent strategies between attacker and admin
 Requires regular monitoring
 Not considered as a beneficial investment until a security failure occurs
 Actually security investments must be considered as insurance against attacks
 too often an afterthought
 Not only from investment point of view, but also from design point of view

9|Page
Chapter-2 Introduction to Cryptography
Classical Encryption Techniques
Symmetric encryption, also referred to as conventional encryption or single-key encryption, was the only type of
encryption in use prior to the development of public-key encryption in the 1970s. It remains by far the most widely
used of the two types of encryption. All traditional schemes are symmetric / single key / private-key encryption
algorithms, with a single key, used for both encryption and decryption. Since both sender and receiver are equivalent,
either can encrypt or decrypt messages using that common key.
Some Basic Terminology
 plaintext - original message
 ciphertext - coded message
 cipher - algorithm for transforming plaintext to ciphertext
 key - info used in cipher known only to sender/receiver
 encipher (encrypt) - converting plaintext to ciphertext
 decipher (decrypt) - recovering plaintext from ciphertext
 cryptography - study of encryption principles/methods
 cryptanalysis (codebreaking) - study of principles/ methods of deciphering ciphertext without knowing key
 cryptology - field of both cryptography and cryptanalysis

The five ingredients of the symmetric cipher model, shown in Stallings Figure 2.1:
• plaintext - original message
• encryption algorithm – performs substitutions/transformations on plaintext
• secret key – control exact substitutions/transformations used in encryption algorithm
• ciphertext - scrambled message
• decryption algorithm – inverse of encryption algorithm
There are two requirements for secure use of conventional encryption that mean we assume that it is impractical to decrypt a
message on the basis of the cipher- text plus knowledge of the encryption/decryption algorithm, and hence do not need to keep the
algorithm secret; rather we only need to keep the key secret. This feature of symmetric encryption is what makes it feasible for
widespread use. It allows easy distribution of s/w and h/w implementations. Can take a closer look at the essential elements of a
symmetric encryption scheme: mathematically it can be considered a pair of functions with: plaintext X, ciphertext Y, key K,
encryption algorithm E, decryption algorithm D. The intended receiver, in possession of the key, is able to invert the transformation.
An opponent, observing Y but not having access to K or X, may attempt to recover X or K.
Requirements
Two requirements for secure use of symmetric encryption:
1. a strong encryption algorithm
2. a secret key known only to sender / receiver
Mathematically have:
Y = E(K, X)
X = D(K, Y)
Assume encryption algorithm is known
 implies a secure channel to distribute key
Cryptographic systems can be characterized along these three independent dimensions.
1. The type of operations used for transforming plaintext to ciphertext. All encryption algorithms are based
on two general principles: substitution, in which each element in the plaintext (bit, letter, group of bits or letters)
is mapped into another element, and transposition, in which elements in the plaintext are rearranged. The
fundamental requirement is that no information be lost (that is, that all operations are reversible). Most systems,
referred to as product systems, involve multiple stages of substitutions and transpositions.

10 | P a g e
 2. The number of keys used. If both sender and receiver use the same key, the system is referred to as symmetric,
single-key, secret-key, or conventional encryption. If the sender and receiver use different keys, the system is
referred to as asymmetric, two-key, or public-key encryption.
3. The way in which the plaintext is processed. A block cipher processes the input one block of elements at a
time, producing an output block for each input block. A stream cipher processes the input elements continuously,
producing output one element at a time, as it goes along.
Cryptography can characterize cryptographic system by:
1. type of encryption operations used
 substitution,
 transposition &
 product
2. number of keys used
 single-key or private
 two-key or public
3. way in which plaintext is processed
 block
 stream
Cryptanalysis
 objective to recover key not just message
 general approaches:
 cryptanalytic attack
 brute-force attack
if either succeed all key use compromised
Typically, objective is to recover the key in use rather than simply to recover the plaintext of a single ciphertext. There
are two general approaches:
• Cryptanalysis: relies on the nature of the algorithm plus perhaps some knowledge of the general
characteristics of the plaintext or even some sample plaintext- ciphertext pairs. This type of attack exploits the
characteristics of the algorithm to attempt to deduce a specific plaintext or to deduce the key being used.
• Brute-force attacks try every possible key on a piece of ciphertext until an intelligible translation into
plaintext is obtained. On average, half of all possible keys must be tried to achieve success.
If either type of attack succeeds in deducing the key, the effect is catastrophic: All future and past messages encrypted
with that key are compromised.
Cryptanalytic Attacks
Stallings Table 2.1 summarizes the various types of cryptanalytic attacks, based on the amount of information known
to the cryptanalyst, from least to most. The most difficult problem is presented when all that is available is the
ciphertext only. In some cases, not even the encryption algorithm is known, but in general we can assume that the
opponent does know the algorithm used for encryption. Then with increasing information have the other attacks.
Generally, an encryption algorithm is designed to withstand a known-plaintext attack.
ciphertext only -only know algorithm & ciphertext, is statistical, know or can identify
plaintext
known plaintext - know/suspect plaintext & ciphertext
chosen plaintext -select plaintext and obtain ciphertext
chosen ciphertext - select ciphertext and obtain plaintext
chosen text - select plaintext or ciphertext to en/decrypt
More Definitions
 unconditional security - no matter how much computer power or time is available; the cipher cannot be broken
since the ciphertext provides insufficient information to uniquely determine the corresponding plaintext.
 computational security - given limited computing resources (eg time needed for calculations is greater than
age of universe), the cipher cannot be broken.
Two more definitions are worthy of note. An encryption scheme is unconditionally secure if the ciphertext generated by the scheme
does not contain enough information to determine uniquely the corresponding plaintext, no matter how much ciphertext is available.
An encryption scheme is said to be computationally secure if either the cost of breaking the cipher exceeds the value of the encrypted
information, or the time required to break the cipher exceeds the useful lifetime of the information. Unconditional security would
be nice, but the only known such cipher is the one-time pad (later). For all reasonable encryption algorithms, we have to assume
computational security where it either takes too long, or is too expensive, to bother breaking the cipher.

11 | P a g e
Brute Force Search
A brute-force attack involves trying every possible key until an intelligible translation of the ciphertext into plaintext
is obtained. On average, half of all possible keys must be tried to achieve success. Stallings Table 2.2 shows how
much time is required to conduct a brute-force attack, for various common key sizes (DES is 56, AES is 128, Triple-
DES is 168, plus general mono-alphabetic cipher), where either a single system or a million parallel systems, are used.

 always possible to simply try every key

 most basic attack, proportional to key size
 assume either know / recognise plaintext
Classical Substitution Ciphers
In this section and the next, we examine a sampling of what might be called classical encryption techniques. A study
of these techniques enables us to illustrate the basic approaches to symmetric encryption used today and the types of
cryptanalytic attacks that must be anticipated. The two basic building blocks of all encryption technique are
substitution and transposition. We examine these in the next two sections. Finally, we discuss a system that combine
both substitution and transposition. A substitution technique is one in which the letters of plaintext are replaced by
other letters or by numbers or symbols. If the plaintext is viewed as a sequence of bits, then substitution involves
replacing plaintext bit patterns with ciphertext bit patterns.
 where letters of plaintext are replaced by other letters or by numbers or symbols
 or if plaintext is viewed as a sequence of bits, then substitution involves replacing plaintext bit patterns with
ciphertext bit patterns
Caesar Cipher
• earliest known substitution cipher
• by Julius Caesar
• first attested use in military affairs
• replaces each letter by 3rd letter on
• example: meet me after the toga party
PHHW PH DIWHU WKH WRJD SDUWB
Substitution ciphers form the first of the fundamental building blocks. The core idea is to replace one basic unit
(letter/byte) with another. Whilst the early Greeks described several substitution ciphers, the first attested use in
military affairs of one was by Julius Caesar, described by him in Gallic Wars (cf. Kahn pp83-84). Still call any cipher
using a simple letter shift a caesar cipher, not just those with shift 3.
 can define transformation as:
abcdefghijklmnopqrstuvwxyz
DEFGHIJKLMNOPQRSTUVWXYZABC
 mathematically give each letter a number
abcdefghij k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
 then have Caesar cipher as:
c = E(k, p) = (p + k) mod (26)
p = D(k, c) = (c – k) mod (26)
This mathematical description uses modulo (clock) arithmetic. Here, when you reach Z you go back to A and start
again. Mod 26 implies that when you reach 26, you use 0 instead (ie the letter after Z, or 25 + 1 goes to A or 0).
Example: howdy (7,14,22,3,24) encrypted using key f (ie a shift of 5) is MTBID

12 | P a g e
Cryptanalysis of Caesar Cipher
 only have 26 possible ciphers A maps to A,B,..Z
 could simply try each in turn
 a brute force search
 given ciphertext, just try all shifts of letters
 do need to recognize when have plaintext
 eg. break ciphertext "GCUA VQ DTGCM"
With a caesar cipher, there are only 26 possible keys, of which only 25 are of any use, since mapping A to A etc doesn't really
obscure the message! Note this basic rule of cryptanalysis "check to ensure the cipher operator hasn't goofed and sent a plaintext
message by mistake"! Can try each of the keys (shifts) in turn, until can recognise the original message. See Stallings Fig 2.3 for
example of search. Note: as mentioned before, do need to be able to recognise when have an original message (ie is it English or
whatever). Usually easy for humans, hard for computers. Though if using say compressed data could be much harder.
Example "GCUA VQ DTGCM" when broken gives "easy to break", with a shift of 2 (key C).
Monoalphabetic Cipher
 rather than just shifting the alphabet could shuffle (jumble) the letters arbitrarily
 each plaintext letter maps to a different random ciphertext letter hence key is 26 letters long
Plain: abcdefghijklmnopqrstuvwxyz
Cipher: DKVQFIBJWPESCXHTMYAUOLRGZN
Plaintext: ifwewishtoreplaceletters
Ciphertext: WIRFRWAJUHYFTSDVFSFUUFYA
With only 25 possible keys, the Caesar cipher is far from secure. A dramatic increase in the key space can be achieved by allowing
an arbitrary substitution, where the translation alphabet can be any permutation of the 26 alphabetic characters. A permutation of a
finite set of elements S is an ordered sequence of all the elements of S, with each element appearing exactly once. In general, there
are n! permutations of a set of n elements. See text example of a translation alphabet, and an encrypted message using it.
Monoalphabetic Cipher Security
• now we have a total of 26! = 4 x 1026 keys
• with so many keys, might think is secure
• but would be !!!WRONG!!!
• problem is language characteristics
Note that even given the very large number of keys, being 10 orders of magnitude greater than the key space for DES, the
monoalphabetic substitution cipher is not secure, because it does not sufficiently obscure the underlying language characteristics.
Language Redundancy and Cryptanalysis
 human languages are redundant
 eg "th lrd s m shphrd shll nt wnt"
 letters are not equally commonly used
 in English E is by far the most common letter followed by T,R,N,I,O,A,S
 other letters like Z,J,K,Q,X are fairly rare
 have tables of single, double & triple letter frequencies for various languages
As the example shows, we don't actually need all the letters in order to understand written English text. Here vowels were removed,
but they're not the only redundancy. cf written Hebrew has no vowels for same reason. Are usually familiar with "party
conversations", can hear one person speaking out of hubbub of many, again because of redundancy in aural language also. This
redundancy is also the reason we can compress text files; the computer can derive a more compact encoding without losing any
information. Basic idea is to count the relative frequencies of letters, and note the resulting pattern.
English Letter Frequencies

13 | P a g e
Note that all human languages have varying letter frequencies, though the number of letters and their frequencies
varies. Stallings Figure 2.5 shows English letter frequencies. Seberry & Pieprzyk, "Cryptography - An Introduction to
Computer Security", Prentice-Hall 1989, Appendix A has letter frequency graphs for 20 languages (most European &
Japanese & Malay). Also useful are tables of common two-letter combinations, known as digrams, and three-letter
combinations, known as trigrams.
Use in Cryptanalysis
 key concept - monoalphabetic substitution ciphers do not change relative letter frequencies
 discovered by Arabian scientists in 9th century
 calculate letter frequencies for ciphertext
 compare counts/plots against known values
 if caesar cipher look for common peaks/troughs
 peaks at: A-E-I triple, NO pair, RST triple
 troughs at: JK, X-Z
 for monoalphabetic must identify each letter
 tables of common double/triple letters help
The simplicity and strength of the monoalphabetic substitution cipher meant it dominated cryptographic use for the
first millenium AD. It was broken by Arabic scientists. The earliest known description is in Abu al-Kindi's "A
Manuscript on Deciphering Cryptographic Messages", published in the 9th century but only rediscovered in 1987 in
Istanbul, but other later works also attest to their knowledge of the field. Monoalphabetic ciphers are easy to break
because they reflect the frequency data of the original alphabet. The cryptanalyst looks for a mapping between the
observed pattern in the ciphertext, and the known source language letter frequencies. If English, look for peaks at: A-
E-I triple, NO pair, RST triple, and troughs at: JK, X-Z. Monoalphabetic ciphers are easy to break because they reflect
the frequency data of the original alphabet.
Example Cryptanalysis
 given ciphertext:
UZQSOVUOHXMOPVGPOZPEVSGZWSZOPFPESXUDBMETSXAIZVUEPHZHMDZSHZOWSFPAPPD
TSVPQUZWYMXUZUHSXEPYEPOPDZSZUFPOMBZWPFUPZHMDJUDTMOHMQ
 count relative letter frequencies (see text)
 guess P & Z are e and t
 guess ZW is th and hence ZWP is the
 proceeding with trial and error finally get:
it was disclosed yesterday that several informal but direct contacts have been made with political representatives of the viet cong in moscow
Illustrate the process with this example from the text in Stallings section 2.2. Comparing letter frequency breakdown
with Figure 2.5, it seems likely that cipher letters P and Z are the equivalents of plain letters e and t, but it is not certain
which is which. The letters S, U, O, M, and H are all of relatively high frequency and probably correspond to plain
letters from the set {a, h, i, n, o, r, s}. The letters with the lowest frequencies (namely, A, B, G, Y, I, J) are likely
included in the set {b, j, k, q, v, x, z}. A powerful tool is to look at the frequency of two-letter combinations, known
as digrams. A table similar to Figure 2.5 could be drawn up showing the relative frequency of digrams. The most
common such digram is th. In our ciphertext, the most common digram is ZW, which appears three times. So we make
the correspondence of Z with t and W with h. Then, by our earlier hypothesis, we can equate P with e. Now notice
that the sequence ZWP appears in the ciphertext, and we can translate that sequence as "the." This is the most frequent
trigram (three- letter combination) in English, which seems to indicate that we are on the right track. Next, notice the
sequence ZWSZ in the first line. We do not know that these four letters form a complete word, but if they do, it is of
the form th_t. If so, S equates with a. Only four letters have been identified, but already we have quite a bit of the
message. Continued analysis of frequencies plus trial and error should easily yield a solution from this point. The
complete plaintext, with spaces added between words, is shown on above.
Steganography
Steganography is an alternative to encryption which hides the very existence of a message by some means. There are
a large range of techniques for doing this. Steganography has a number of drawbacks when compared to encryption.
It requires a lot of overhead to hide a relatively few bits of information.
Also, once the system is discovered, it becomes virtually worthless, although a message can be first encrypted and
then hidden using steganography. The advantage of steganography is that it can be employed by parties who have
something to lose should the fact of their secret communication (not necessarily the content) be discovered.

14 | P a g e
 • an alternative to encryption
• hides existence of message
• using only a subset of letters/words in a longer message marked in some way
• using invisible ink
• hiding in LSB in graphic image or sound file
• has drawbacks
• high overhead to hide relatively few info bits
• advantage is can obscure encryption use
Block vs Stream Ciphers
Block ciphers work a on block / word at a time, which is some number of bits. All of these bits have to be available
before the block can be processed. Stream ciphers work on a bit or byte of the message at a time, hence process it as
a “stream”. Block ciphers are currently better analysed, and seem to have a broader range of applications, hence focus
on them.
• block ciphers process messages in blocks, each of which is then en/decrypted
• like a substitution on very big characters 64-bits or more
• stream ciphers process messages a bit or byte at a time when en/decrypting
• many current ciphers are block ciphers
• better analyzed
• broader range of applications

A block cipher is one in which a block of plaintext is treated as a whole and used to produce a ciphertext block of equal length.
Typically, a block size of 64 or 128 bits is used. As with a stream cipher, the two users share a symmetric encryption key (Figure
3.1b). A stream cipher is one that encrypts a digital data stream one bit or one byte at a time. In the ideal case, a one-time pad
version of the Vernam cipher would be used (Figure 2.7), in which the keystream (k ) is as long as the plaintext bit stream (p).
Block Cipher Principles
Most symmetric block encryption algorithms in current use are based on a structure referred to as a Feistel block
cipher. A block cipher operates on a plaintext block of n bits to produce a ciphertext block of n bits. An arbitrary
reversible substitution cipher for a large block size is not practical, however, from an implementation and performance
point of view. In general, for an n-bit general substitution block cipher, the size of the key is n x 2n. For a 64-bit block,
which is a desirable length to thwart statistical attacks, the key size is 64x 2 64 = 270 = 1021 bits. In considering these
difficulties, Feistel points out that what is needed is an approximation to the ideal block cipher system for large n,
built up out of components that are easily realizable.
 most symmetric block ciphers are based on a Feistel Cipher Structure
 needed since must be able to decrypt ciphertext to recover messages efficiently
 block ciphers look like an extremely large substitution
 would need table of 264 entries for a 64-bit block
 instead create from smaller building blocks
 using idea of a product cipher

15 | P a g e
Ideal Block Cipher
Feistel refers to an n-bit general substitution as an ideal block cipher, because it allows for the maximum number of
possible encryption mappings from the plaintext to ciphertext block. A 4-bit input produces one of 16 possible input
states, which is mapped by the substitution cipher into a unique one of 16 possible output states, each of which is
represented by 4 ciphertext bits. The encryption and decryption mappings can be defined by a tabulation, as shown in
Stallings Figure 3.2. It illustrates a tiny 4-bit substitution to show that each possible input can be arbitrarily mapped
to any output - which is why its complexity grows so rapidly.

Claude Shannon and Substitution-Permutation Ciphers

Feistel proposed that we can approximate the ideal block cipher by utilizing the concept of a product cipher, which is the execution
of two or more simple ciphers in sequence in such a way that the final result or product is cryptographically stronger than any of
the component ciphers. In particular, Feistel proposed the use of a cipher that alternates substitutions and permutations, as a practical
application of a proposal by Claude Shannon. Claude Shannon’s 1949 paper has the key ideas that led to the development of modern
block ciphers. Critically, it was the technique of layering groups of S-boxes separated by a larger P-box to form the S-P network,
a complex form of a product cipher. He also introduced the ideas of confusion and diffusion, notionally provided by S-boxes and
P-boxes (in conjunction with S-boxes).
 Claude Shannon introduced idea of substitution-permutation (S-P) networks in 1949 paper
 form basis of modern block ciphers
 S-P nets are based on the two primitive cryptographic operations seen before:
 substitution (S-box)
 permutation (P-box)
 provide confusion & diffusion of message & key
Confusion and Diffusion
The terms diffusion and confusion were introduced by Claude Shannon to capture the two basic building blocks for any
cryptographic system. Shannon's concern was to thwart cryptanalysis based on statistical analysis. Every block cipher involves a
transformation of a block of plaintext into a block of ciphertext, where the transformation depends on the key. The mechanism of
diffusion seeks to make the statistical relationship between the plaintext and ciphertext as complex as possible in order to thwart
attempts to deduce the key. Confusion seeks to make the relationship between the statistics of the ciphertext and the value of the
encryption key as complex as possible, again to thwart attempts to discover the key. So successful are diffusion and confusion in
capturing the essence of the desired attributes of a block cipher that they have become the cornerstone of modern block cipher
design.
 cipher needs to completely obscure statistical properties of original message
 a one-time pad does this
 more practically Shannon suggested combining S & P elements to obtain:
 diffusion – dissipates statistical structure of plaintext over bulk of ciphertext
 confusion – makes relationship between ciphertext and key as complex as possible
Feistel Cipher Structure
Horst Feistel, working at IBM Thomas J Watson Research Labs devised a suitable invertible cipher structure in early 70's. One of
Feistel's main contributions was the invention of a suitable structure which adapted Shannon's S-P network in an easily inverted
structure. It partitions input block into two halves which are processed through multiple rounds which perform a substitution on
left data half, based on round function of right half & subkey, and then have permutation swapping halves. Essentially the same
h/w or s/w is used for both encryption and decryption, with just a slight change in how the keys are used. One layer of S-boxes and
the following P-box are used to form the round function.

16 | P a g e
 • Horst Feistel devised the feistel cipherbased on concept of invertible product cipher
• partitions input block into two halves
• process through multiple rounds which perform a substitution on left data half
• based on round function of right half & subkey
• then have permutation swapping halves
• implements Shannon’s S-P net concept

Stallings Figure 3.3 illustrates the classical feistel cipher structure, with data split in 2 halves, processed through a
number of rounds which perform a substitution on left half using output of round function on right half & key, and a
permutation which swaps halves, as listed previously. The LHS side of this figure shows the flow during encryption,
the RHS in decryption. The inputs to the encryption algorithm are a plaintext block of length 2w bits and a key K. The
plaintext block is divided into two halves, L0 and R0. The two halves of the data pass through n rounds of processing
and then combine to produce the ciphertext block. Each round i has as inputs L i–1 and Ri–1, derived from the previous
round, as well as a subkey Ki, derived from the overall K. In general, the subkeys K are different from K and from
each other. The process of decryption with a Feistel cipher is essentially the same as the encryption process. The rule
is as follows: Use the ciphertext as input to the algorithm, but use the subkeys Ki in reverse order. That is, use Kn in
the first round, Kn–1 in the second round, and so on until K1 is used in the last round. This is a nice feature because it
means we need not implement two different algorithms, one for encryption and one for decryption. See discussion in
text for why using the same algorithm with a reversed key order produces the correct result, noting that at every round,
the intermediate value of the decryption process is equal to the corresponding value of the encryption process with the
two halves of the value swapped.
Feistel Cipher Design Elements
The exact realization of a Feistel network depends on the choice of the following parameters and design features:
 block size - increasing size improves security, but slows cipher
 key size - increasing size improves security, makes exhaustive key searching harder, but may slow cipher
 number of rounds - increasing number improves security, but slows cipher
 subkey generation algorithm - greater complexity can make analysis harder, but slows cipher
 round function - greater complexity can make analysis harder, but slows cipher
 fast software en/decryption - more recent concern for practical use
 ease of analysis - for easier validation & testing of strength

17 | P a g e
Data Encryption Standard (DES)
The most widely used private key block cipher, is the Data Encryption Standard (DES). It was adopted in 1977 by the National
Bureau of Standards as Federal Information Processing Standard 46 (FIPS PUB 46). DES encrypts data in 64-bit blocks using a
56-bit key. The DES enjoys widespread use. It has also been the subject of much controversy its security.
• most widely used block cipher in world
• adopted in 1977 by NBS (now NIST)
• as FIPS PUB 46
• encrypts 64-bit data using 56-bit key
• has widespread use
• has been considerable controversy over its security
In the late 1960s, IBM set up a research project in computer cryptography led by Horst Feistel. The project concluded in 1971 with
the development of the LUCIFER algorithm. LUCIFER is a Feistel block cipher that operates on blocks of 64 bits, using a key size
of 128 bits. Because of the promising results produced by the LUCIFER project, IBM embarked on an effort, headed by Walter
Tuchman and Carl Meyer, to develop a marketable commercial encryption product that ideally could be implemented on a single
chip. It involved not only IBM researchers but also outside consultants and technical advice from NSA. The outcome of this effort
was a refined version of LUCIFER that was more resistant to cryptanalysis but that had a reduced key size of 56 bits, to fit on a
single chip. In 1973, the National Bureau of Standards (NBS) issued a request for proposals for a national cipher standard. IBM
submitted the modified LUCIFER. It was by far the best algorithm proposed and was adopted in 1977 as the Data Encryption
Standard.
IBM developed Lucifer cipher
 by team led by Feistel in late 60’s
 used 64-bit data blocks with 128-bit key
then redeveloped as a commercial cipher with input from NSA and others
in 1973 NBS issued request for proposals for a national cipher standard
IBM submitted their revised Lucifer which was eventually accepted as the DES
DES Design Controversy
Before its adoption as a standard, the proposed DES was subjected to intense & continuing criticism over the size of its key & the
classified design criteria. Recent analysis has shown despite this controversy, that DES is well designed. DES is theoretically
broken using Differential or Linear Cryptanalysis but in practise is unlikely to be a problem yet. Also rapid advances in computing
speed though have rendered the 56 bit key susceptible to exhaustive key search, as predicted by Diffie & Hellman. DES has
flourished and is widely used, especially in financial applications. It is still standardized for legacy systems, with either AES or
triple DES for new applications.
although DES standard is public
had considerable controversy over design
 in choice of 56-bit key (vs Lucifer 128-bit)
 and because design criteria were classified
 subsequent events and public analysis show in fact design was appropriate
 use of DES has flourished
• especially in financial applications
• still standardised for legacy application use
DES Encryption Overview

18 | P a g e
The overall scheme for DES encryption is illustrated in Stallings Figure 3.4, which takes as input 64-bits of data and of key. The
left side shows the basic process for enciphering a 64-bit data block which consists of:
- an initial permutation (IP) which shuffles the 64-bit input block
- 16 rounds of a complex key dependent round function involving substitutions & permutations
- a final permutation, being the inverse of IP
The right side shows the handling of the 56-bit key and consists of:
- an initial permutation of the key (PC1) which selects 56-bits out of the 64-bits input, in two 28-bit halves
- 16 stages to generate the 48-bit subkeys using a left circular shift and a permutation of the two 28-bit halves
Initial Permutation IP
The initial permutation and its inverse are defined by tables, as shown in Stallings Tables 3.2a and 3.2b, respectively. The tables
are to be interpreted as follows. The input to a table consists of 64 bits numbered left to right from 1 to 64. The 64 entries in the
permutation table contain a permutation of the numbers from 1 to 64. Each entry in the permutation table indicates the position of
a numbered input bit in the output, which also consists of 64 bits. Note that the bit numbering for DES reflects IBM mainframe
practice, and is the opposite of what we now mostly use - so be careful! Numbers from Bit 1 (leftmost, most significant) to bit
32/48/64 etc (rightmost, least significant). For example, a 64-bit plaintext value of “675a6967 5e5a6b5a” (written in left & right
halves) after permuting with IP becomes “ffb2194d 004df6fb”. Note that example values are specified using hexadecimal.
 first step of the data computation
 IP reorders the input data bits
 even bits to LH half, odd bits to RH half
 quite regular in structure (easy in h/w)
 example: IP(675a6967 5e5a6b5a) = (ffb2194d 004df6fb)
DES Round Structure
We now review the internal structure of the DES round function F, which takes R half & subkey, and processes them. The round
key Ki is 48 bits. The R input is 32 bits. This R input is first expanded to 48 bits by using a table that defines a permutation plus an
expansion that involves duplication of 16 of the R bits (Table 3.2c). The resulting 48 bits are XORed with Ki This 48-bit result
passes through a substitution function that produces a 32-bit output, which is permuted as defined by Table 3.2d. This follows the
classic structure for a feistel cipher. Note that the s-boxes provide the “confusion” of data and key values, whilst the permutation
P then spreads this as widely as possible, so each S-box output affects as many S-box inputs in the next round as possible, giving
“diffusion”.
 uses two 32-bit L & R halves
 as for any Feistel cipher can describe as:
Li = Ri–1
Ri = Li–1  F(Ri–1, Ki)
 F takes 32-bit R half and 48-bit subkey:
 expands R to 48-bits using perm E
 adds to subkey using XOR
 passes through 8 S-boxes to get 32-bit result
 finally permutes using 32-bit perm P
Stallings Figure 3.7 illustrates the internal structure of the DES round function F. The R input is first expanded to 48 bits by using
expansion table E that defines a permutation plus an expansion that involves duplication of 16 of the R bits (Stallings Table 3.2c).
The resulting 48 bits are XORed with key Ki . This 48-bit result passes through a substitution function comprising 8 S-boxes which
each map 6 input bits to 4 output bits, producing a 32-bit output, which is then permuted by permutation P as defined by Stallings
Table 3.2d.

19 | P a g e
Substitution Boxes S
The substitution consists of a set of eight S-boxes, each of which accepts 6 bits as input and produces 4 bits as output.
These transformations are defined in Stallings Table 3.3, which is interpreted as follows: The first and last bits of the
input to box Si form a 2-bit binary number to select one of four substitutions defined by the four rows in the table for
Si. The middle four bits select one of the sixteen columns. The decimal value in the cell selected by the row and
column is then converted to its 4-bit representation to produce the output. For example, in S1, for input 011001, the
row is 01 (row 1) and the column is 1100 (column 12). The value in row 1, column 12 is 9, so the output is 1001. The
example lists 8 6-bit values (ie 18 in hex is 011000 in binary, 09 hex is 001001 binary, 12 hex is 010010 binary, 3d
hex is 111101 binary etc), each of which is replaced following the process detailed above using the appropriate S-box.
ie
S1(011000) lookup row 00 col 1100 in S1 to get 5
S2(001001) lookup row 01 col 0100 in S2 to get 15 = f in hex
S3(010010) lookup row 00 col 1001 in S3 to get 13 = d in hex
S4(111101) lookup row 11 col 1110 in S4 to get 2 etc
 have eight S-boxes which map 6 to 4 bits
 each S-box is actually 4 little 4 bit boxes
 outer bits 1 & 6 (row bits) select one row of 4
 inner bits 2-5 (col bits) are substituted
 result is 8 lots of 4 bits, or 32 bits
 row selection depends on both data & key
 feature known as autoclaving (autokeying)
 example:
 S(18 09 12 3d 11 17 38 39) = 5fd25e03
DES Key Schedule
The DES Key Schedule generates the subkeys needed for each data encryption round. A 64-bit key is used as input to the algorithm,
though every eighth bit is ignored, as indicated by the lack of shading in Table 3.4a. It is first processed by Permuted Choice One
(Stallings Table 3.4b). The resulting 56-bit key is then treated as two 28-bit quantities C & D. In each round, these are separately
processed through a circular left shift (rotation) of 1 or 2 bits as shown in Stallings Table 3.4d. These shifted values serve as input
to the next round of the key schedule. They also serve as input to Permuted Choice Two (Stallings Table 3.4c), which produces a
48-bit output that serves as input to the round function F. The 56 bit key size comes from security considerations as we know now.
It was big enough so that an exhaustive key search was about as hard as the best direct attack (a form of differential cryptanalysis
called a T-attack, known by the IBM & NSA researchers), but no bigger. The extra 8 bits were then used as parity (error detecting)
bits, which makes sense given the original design use for hardware communications links. However, we hit an incompatibility with
simple s/w implementations since the top bit in each byte is 0 (since ASCII only uses 7 bits), but the DES key schedule throws
away the bottom bit! A good implementation needs to be cleverer!
 forms subkeys used in each round
initial permutation of the key (PC1) which selects 56-bits in two 28-bit halves
16 stages consisting of:
 rotating each half separately either 1 or 2 places depending on the key rotation schedule K
 selecting 24-bits from each half & permuting them by PC2 for use in round function F
 note practical use issues in h/w vs s/w
DES Decryption
As with any Feistel cipher, DES decryption uses the same algorithm as encryption except that the subkeys are used in
reverse order SK16 .. SK1. If you trace through the DES overview diagram can see how each decryption step top to
bottom with reversed subkeys, undoes the equivalent encryption step moving from bottom to top.
 decrypt must unwind steps of data computation
 with Feistel design, do encryption steps again using subkeys in reverse order (SK16 … SK1)
 IP undoes final FP step of encryption
 1st round with SK16 undoes 16th encrypt round
 ….
 16th round with SK1 undoes 1st encrypt round
 then final FP undoes initial encryption IP
 thus recovering original data value

20 | P a g e
Avalanche Effect
A desirable property of any encryption algorithm is that a small change in either the plaintext or the key should produce
a significant change in the ciphertext. In particular, a change in one bit of the plaintext or one bit of the key should
produce a change in many bits of the ciphertext. If the change were small, this might provide a way to reduce the size
of the plaintext or key space to be searched. DES exhibits a strong avalanche effect, as may be seen in Stallings Table 3.5.
• key desirable property of encryption alg
• where a change of one input or key bit results in changing approx half output bits
• making attempts to “home-in” by guessing keys impossible
• DES exhibits strong avalanche
Strength of DES – Key Size
Since its adoption as a federal standard, there have been lingering concerns about the level of security provided by
DES in two areas: key size and the nature of the algorithm. With a key length of 56 bits, there are 256 possible keys,
which is approximately 7.2*1016 keys. Thus a brute-force attack appeared impractical. However, DES was finally and
definitively proved insecure in July 1998, when the Electronic Frontier Foundation (EFF) announced that it had broken
a DES encryption using a special-purpose "DES cracker" machine that was built for less than $250,000. The attack
took less than three days. The EFF has published a detailed description of the machine, enabling others to build their
own cracker [EFF98]. There have been other demonstrated breaks of the DES using both large networks of computers
& dedicated h/w, including:
- 1997 on a large network of computers in a few months
- 1998 on dedicated h/w (EFF) in a few days
- 1999 above combined in 22hrs!
It is important to note that there is more to a key-search attack than simply running through all possible keys. Unless
known plaintext is provided, the analyst must be able to recognize plaintext as plaintext.
Clearly must now consider alternatives to DES, the most important of which are AES and triple DES.
 56-bit keys have 256 = 7.2 x 1016 values
 brute force search looks hard
 recent advances have shown is possible
 in 1997 on Internet in a few months
 in 1998 on dedicated h/w (EFF) in a few days
 in 1999 above combined in 22hrs!
 still must be able to recognize plaintext
 must now consider alternatives to DES
Strength of DES – Analytic Attacks
Another concern is the possibility that cryptanalysis is possible by exploiting the characteristics of the DES algorithm.
The focus of concern has been on the eight substitution tables, or S-boxes, that are used in each iteration. These
techniques utilise some deep structure of the cipher by gathering information about encryptions so that eventually you
can recover some/all of the sub-key bits, and then exhaustively search for the rest if necessary. Generally, these are
statistical attacks which depend on the amount of information gathered for their likelihood of success. Attacks of this
form include differential cryptanalysis. linear cryptanalysis, and related key attacks.
 now have several analytic attacks on DES
 these utilise some deep structure of the cipher
 by gathering information about encryptions
 can eventually recover some/all of the sub-key bits
 if necessary then exhaustively search for the rest
 generally, these are statistical attacks
 differential cryptanalysis
 linear cryptanalysis
 related key attacks

21 | P a g e
Chapter-3 Introduction to Modern Cryptography
Origins
The Advanced Encryption Standard (AES) was published by NIST (National Institute of Standards and Technology) in 2001. AES
is a symmetric block cipher that is intended to replace DES as the approved standard for a wide range of applications. The AES
cipher (& other candidates) form the latest generation of block ciphers, and now we see a significant increase in the block size -
from the old standard of 64-bits up to 128-bits; and keys from 128 to 256-bits. In part this has been driven by the public
demonstrations of exhaustive key searches of DES. Whilst triple-DES is regarded as secure and well understood, it is slow,
especially in s/w. In a first round of evaluation, 15 proposed algorithms were accepted. A second round narrowed the field to 5
algorithms. NIST completed its evaluation process and published a final standard (FIPS PUB 197) in November of 2001. NIST
selected Rijndael as the proposed AES algorithm. The two researchers who developed and submitted Rijndael for the AES are both
cryptographers from Belgium: Dr. Joan Daemen and Dr.Vincent Rijmen.
 A clear replacement for DES was needed
 have theoretical attacks that can break it
 have demonstrated exhaustive key search attacks
 can use Triple-DES – but slow, has small blocks
 US NIST issued call for ciphers in 1997
 15 candidates accepted in Jun 98
 5 were shortlisted in Aug-99
 Rijndael was selected as the AES in Oct-2000
 issued as FIPS PUB 197 standard in Nov-2001
The AES Cipher - Rijndael
The Rijndael proposal for AES defined a cipher in which the block length and the key length can be independently specified to be
128,192,or 256 bits. The AES specification uses the same three key size alternatives but limits the block length to 128 bits. Rijndael
is an academic submission, based on the earlier Square cipher, from Belgium academics Dr Joan Daemen and Dr Vincent Rijmen.
It is an iterative cipher (operates on entire data block in every round) rather than feistel (operate on halves at a time), and was
designed to have characteristics of: Resistance against all known attacks, Speed and code compactness on a wide range of platforms,
& Design simplicity.
 designed by Rijmen-Daemen in Belgium
 has 128/192/256 bit keys, 128 bit data
 an iterative rather than feistel cipher
 processes data as block of 4 columns of 4 bytes
 operates on entire data block in every round
 designed to be:
 resistant against known attacks
 speed and code compactness on many CPUs
 design simplicity
AES Encryption Process

Stallings Figure 5.1 shows the overall encryption process in AES.

22 | P a g e
AES Structure
The input to the AES encryption and decryption algorithms is a single 128-bit block, depicted in FIPS PUB 197, as a
square matrix of bytes. This block is copied into the State array, which is modified at each stage of encryption or
decryption. After the final stage, State is copied to an output. The key is expanded into 44/52/60 lots of 32-bit words
(see later), with 4 used in each round. Note that the ordering of bytes within a matrix is by column. So, for example,
the first four bytes of a 128-bit plaintext input to the encryption cipher occupy the first column of the in matrix, the
second four bytes occupy the second column, and so on. Similarly, the first four bytes of the expanded key, which
form a word, occupy the first column of the w matrix. The data computation then consists of an “add round key” step,
then 9/11/13 rounds with all 4 steps, and a final 10 th/12th/14th step of byte subs + mix cols + add round key. This can
be viewed as alternating XOR key & scramble data bytes operations. All of the steps are easily reversed, and can be
efficiently implemented using XOR’s & table lookups.
 data block of 4 columns of 4 bytes is state
 key is expanded to array of words
 has 9/11/13 rounds in which state undergoes:
 byte substitution (1 S-box used on every byte)
 shift rows (permute bytes between groups/columns)
 mix columns (subs using matrix multiply of groups)
 add round key (XOR state with key material)
 view as alternating XOR key & scramble data bytes
 initial XOR key material & incomplete last round
 with fast XOR & table lookup implementation

Stallings Figure 5.3 shows the structure of AES in more detail. The cipher consists of N rounds, where the number of
rounds depends on the key length: 10 rounds for a 16-byte key; 12 rounds for a 24-byte key; and 14 rounds for a 32-
byte key. The first N – 1 rounds consist of four distinct transformation functions: SubBytes, ShiftRows, MixColumns,
and AddRoundKey, which are described subsequently. The final round contains only 3 transformations, and there is
a initial single transformation (AddRoundKey) before the first round, which can be considered Round 0. Each
transformation takes one or more 4 x 4 matrices as input and produces a 4 x 4 matrix as output. Figure 5.1 shows that
the output of each round is a 4 x 4 matrix, with the output of the final round being the ciphertext. Also, the key
expansion function generates N + 1 round keys, each of which is a distinct 4 x 4 matrix. Each round key serve as one
of the inputs to the AddRoundKey transformation in each round.

23 | P a g e
Some Comments on AES
1. an iterative rather than feistel cipher
2. key expanded into array of 32-bit words
1. four words form round key in each round
3. 4 different stages are used as shown
4. has a simple structure
5. only AddRoundKey uses key
6. AddRoundKey a form of Vernam cipher
7. each stage is easily reversible
8. decryption uses keys in reverse order
9. decryption does recover plaintext
10. final round has only 3 stages
Substitute Bytes
We now turn to a discussion of each of the four transformations used in AES. For each stage, we mention the forward
(encryption) algorithm, the inverse (decryption) algorithm, and the rationale for the design of that stage. The Substitute
bytes stage uses an S-box to perform a byte-by-byte substitution of the block. There is a single 8-bit wide S-box used
on every byte. This S-box is a permutation of all 256 8-bit values, constructed using a transformation which treats the
values as polynomials in GF(28) – however it is fixed, so really only need to know the table when implementing.
Decryption requires the inverse of the table. These tables are given in Stallings Table 5.2. The table was designed to
be resistant to known cryptanalytic attacks. Specifically, the Rijndael developers sought a design that has a low
correlation between input bits and output bits, with the property that the output cannot be described as a simple
mathematical function of the input, with no fixed points and no “opposite fixed points”.
 a simple substitution of each byte
 uses one table of 16x16 bytes containing a permutation of all 256 8-bit values
 each byte of state is replaced by byte indexed by row (left 4-bits) & column (right 4-bits)
 eg. byte {86} is replaced by byte in row 8 column 6
 which has value {2A}
 S-box constructed using defined transformation of values in GF(2 8)
 designed to be resistant to all known attacks

As this diagram from Stallings Fig 5.5a shows, the Byte Substitution operates on each byte of state independently,
with the input byte used to index a row/col in the table to retrieve the substituted value.
Substitute Bytes Example

Show an example of the SubBytes transformation from the text.

24 | P a g e
Shift Rows
The ShiftRows stage provides a simple “permutation” of the data, whereas the other steps involve substitutions.
Further, since the state is treated as a block of columns, it is this step which provides for diffusion of values between
columns. It performs a circular rotate on each row of 0, 1, 2 & 3 places for respective rows. When decrypting it
performs the circular shifts in the opposite direction for each row. This row shift moves an individual byte from one
column to another, which is a linear distance of a multiple of 4 bytes, and ensures that the 4 bytes of one column are
spread out to four different columns.
 a circular byte shifts in each row
 1st row is unchanged
 2nd row does 1-byte circular shift to left
 3rd row does 2-byte circular shift to left
 4th row does 3-byte circular shift to left
 decrypt inverts using shifts to right
 since state is processed by columns, this step permutes bytes between the columns

Stalling Figure 5.7a illustrates the Shift Rows permutation. Then show an example of ShiftRows from the text.
Mix Columns

Stalling Figure 5.5b illustrates the Mix Columns transformation.

Mix Columns Example

Show an example of the MixColumns transformation from the text, along with verification of the first column of this
example. In practise, you implement Mix Columns by expressing the transformation on each column as 4 equations
(Stallings equation 5.4) to compute the new bytes for that column. This computation only involves shifts, XORs &
conditional XORs (for the modulo reduction). The decryption computation requires the use of the inverse of the matrix,
which has larger coefficients, and is thus potentially a little harder & slower to implement. The designers & the AES
standard provide an alternate characterization of Mix Columns, which treats each column of State to be a four-term
polynomial with coefficients in GF(28). Each column is multiplied by a fixed polynomial a(x) given in Stallings eqn
5.7. Whilst this is useful for analysis of the stage, the matrix description is all that’s required for implementation. The
coefficients of the matrix are based on a linear code with maximal distance between code words, which ensures a good
mixing among the bytes of each column. The mix column transformation combined with the shift row transformation
ensures that after a few rounds, all output bits depend on all input bits. In addition, the choice of coefficients in
MixColumns, which are all {01}, {02}, or {03}, was influenced by implementation considerations.

25 | P a g e
  can express each col as 4 equations
 to derive each new byte in col
 decryption requires use of inverse matrix
 with larger coefficients, hence a little harder
 have an alternate characterisation
 each column a 4-term polynomial
 with coefficients in GF(28)
 and polynomials multiplied modulo (x4+1)
 coefficients based on linear code with maximal distance between codewords
Add Round Key
Lastly is the Add Round Key stage which is a simple bitwise XOR of the current block with a portion of the expanded
key. Note this is the only step which makes use of the key and obscures the result, hence MUST be used at start and
end of each round, since otherwise could undo effect of other steps. But the other steps provide
confusion/diffusion/non-linearity. That us you can look at the cipher as a series of XOR with key then
scramble/permute block repeated. This is efficient and highly secure it is believed.
 XOR state with 128-bits of the round key
 again processed by column (though effectively a series of byte operations)
 inverse for decryption identical
 since XOR own inverse, with reversed keys
 designed to be as simple as possible
 a form of Vernam cipher on expanded key
 requires other stages for complexity / security

Stallings Figure 5.5b illustrates the Add Round Key stage, which like Byte Substitution, operates on each byte of state independently.
AES Round

Can thus now view all the internal details of the AES round, showing how each byte of the state is manipulated, as shown in Stallings Figure 5.4.
AES Key Expansion
The AES key expansion algorithm takes as input a 4-word (16-byte) key and produces a linear array of words, providing a 4-word
round key for the initial AddRoundKey stage and each of the 10/12/14 rounds of the cipher. It involves copying the key into the
first group of 4 words, and then constructing subsequent groups of 4 based on the values of the previous & 4th back words. The
first word in each group of 4 gets “special treatment” with rotate + S-box + XOR constant on the previous word before XOR’ing
the one from 4 back. In the 256-bit key/14 round version, there’s also an extra step on the middle word. The text includes in section
5.4 pseudocode that describes the key expansion.

26 | P a g e
  takes 128-bit (16-byte) key and expands into array of 44/52/60 32-bit words
 start by copying key into first 4 words
 then loop creating words that depend on values in previous & 4 places back
 in 3 of 4 cases just XOR these together
 1st word in 4 has rotate + S-box + XOR round constant on previous, before XOR 4 th back

The first block of the AES Key Expansion is shown here in Stallings Figure 5.9a. It shows each group of 4 bytes in
the key being assigned to the first 4 words, then the calculation of the next 4 words based on the values of the previous
4 words, which is repeated enough times to create all the necessary subkey information.
Key Expansion Rationale
The Rijndael developers designed the expansion key algorithm to be resistant to known cryptanalytic attacks. It is
designed to be simple to implement, but by using round constants break symmetries, and make it much harder to
deduce other key bits if just some are known (but once have as many consecutive bits as are in key, can then easily
recreate the full expansion). The design criteria used are listed.
 designed to resist known attacks
 design criteria included
 knowing part key insufficient to find many more
 invertible transformation
 fast on wide range of CPU’s
 use round constants to break symmetry
 diffuse key bits into round keys
 enough non-linearity to hinder analysis
 simplicity of description
AES Example Encryption
Next, Table 5.4 shows the progression of the state matrix through the AES encryption process. The first column shows
the value of the state matrix at the start of a round. For the first row, the state matrix is just the matrix arrangement of
the plaintext. The second, third, and fourth columns show the value of the state matrix for that round after the
SubBytes, ShiftRows, and MixColumns transformations, respectively. The fifth column shows the round key. You
can verify that these round keys equate with those shown in Table 5.3. The first column shows the value of the state
matrix resulting from the bitwise XOR of the state after the preceding MixColumns with the round key for the
preceding round.

27 | P a g e
AES Example Avalanche
In any good cipher design, want the avalanche effect, in which a small change in plaintext or key produces a large
change in the ciphertext. Using the example from Table 5.4, Table 5.5 shows the result when the eighth bit of the
plaintext is changed. The second column of the table shows the value of the state matrix at the end of each round for
the two plaintexts. Note that after just one round, 20 bits of the state vector differ. And after two rounds, close to half
the bits differ. This magnitude of difference propagates through the remaining rounds. A bit difference in
approximately half the positions in the most desirable outcome.

28 | P a g e
Public Key Cryptography and RSA
Every Egyptian received two names, which were known respectively as the true name and the good name, or the great name and
the little name; and while the good or little name was made public, the true or great name appears to have been carefully concealed.
—The Golden Bough, Sir James George Frazer
Private-Key Cryptography
The development of public-key cryptography is the greatest and perhaps the only true revolution in the entire history
of cryptography. From its earliest beginnings to modern times, virtually all cryptographic systems have been based on
the elementary tools of substitution and permutation, and can be classed as private/secret/single key (symmetric)
systems. All classical, and modern block and stream ciphers are of this form.
 traditional private/secret/single key cryptography uses one key
 shared by both sender and receiver
 if this key is disclosed communications are compromised
 also is symmetric, parties are equal
 hence does not protect sender from receiver forging a message & claiming is sent by sender
Public-Key Cryptography
Will now discuss the radically different public key systems, in which two keys are used. Public-key cryptography
provides a radical departure from all that has gone before. The development of public-key cryptography is the greatest
and perhaps the only true revolution in the entire history of cryptography. It is asymmetric, involving the use of two
separate keys, in contrast to symmetric encryption, that uses only one key. Anyone knowing the public key can encrypt
messages or verify signatures, but cannot decrypt messages or create signatures, counter-intuitive though this may
seem. The use of two keys has profound consequences in the areas of confidentiality, key distribution, and
authentication. It works by the clever use of number theory problems that are easy one way but hard the other. Note
that public key schemes are neither more nor less secure than private key (security depends on the key size for both),
nor do they replace private key schemes (they are too slow to do so), rather they complement them. Both also have
issues with key distribution, requiring the use of some suitable protocol.
 probably most significant advance in the 3000 year history of cryptography
 uses two keys – a public & a private key
 asymmetric since parties are not equal
 uses clever application of number theoretic concepts to function
 complements rather than replaces private key crypto
Why Public-Key Cryptography?
The concept of public-key cryptography evolved from an attempt to attack two of the most difficult problems
associated with symmetric encryption: key distribution and digital signatures. The first problem is that of key
distribution, which under symmetric encryption requires either (1) that two communicants already share a key, which
somehow has been distributed to them; or (2) the use of a key distribution center. This seemed to negated the very
essence of cryptography: the ability to maintain total secrecy over your own communication. The second was that of
"digital signatures." If the use of cryptography was to become widespread, not just in military situations but for
commercial and private purposes, then electronic messages and documents would need the equivalent of signatures
used in paper documents. The idea of public key schemes, and the first practical scheme, which was for key distribution
only, was published in 1976 by Diffie & Hellman. The concept had been previously described in a classified report in
1970 by James Ellis (UK CESG) - and subsequently declassified [ELLI99]. Its interesting to note that they discovered
RSA first, then Diffie-Hellman, opposite to the order of public discovery! There is also a claim that the NSA knew of
the concept in the mid-60’s [SIMM93].
 developed to address two key issues:
 key distribution – how to have secure communications in general without having to trust a KDC with your
key
 digital signatures – how to verify a message comes intact from the claimed sender
 public invention due to Whitfield Diffie & Martin Hellman at Stanford Uni in 1976
 known earlier in classified community
Asymmetric algorithms rely on one key for encryption and a different but related key for decryption. These algorithms
have the following important characteristic:

29 | P a g e
• It is computationally infeasible to determine the decryption key given only knowledge of the cryptographic algorithm and the
encryption key.
In addition, some algorithms, such as RSA, also exhibit the following characteristic:
• Either of the two related keys can be used for encryption, with the other used for decryption.
Anyone knowing the public key can encrypt messages or verify signatures, but cannot decrypt messages or create signatures,
thanks to some clever use of number theory.
 public-key/two-key/asymmetric cryptography involves the use of two keys:
 a public-key, which may be known by anybody, and can be used to encrypt messages, and verify signatures
 related private-key, known only to the recipient, used to decrypt messages, and sign (create) signatures
 infeasible to determine private key from public
 is asymmetric because
 those who encrypt messages or verify signatures cannot decrypt messages or create signatures

Stallings Figure 9.1a “Public-Key Cryptography”, shows that a public-key encryption scheme has six ingredients:
• Plaintext: the readable message /data fed into the algorithm as input.
• Encryption algorithm: performs various transformations on the plaintext.
• Public and private keys: a pair of keys selected so that if one is used for encryption, the other is used for decryption. The exact
transformations performed by the algorithm depend on the public or private key that is provided as input.
• Ciphertext: the scrambled message produced as output. It depends on the plaintext and the key. For a given message, two different
keys will produce two different ciphertexts.
• Decryption algorithm: accepts the ciphertext and matching key and produces the original plaintext.
Consider the following analogy using padlocked boxes: traditional schemes involve the sender putting a message in a box and
locking it, sending that to the receiver, and somehow securely also sending them the key to unlock the box. The radical advance in
public key schemes was to turn this around, the receiver sends an unlocked box (their public key) to the sender, who puts the
message in the box and locks it (easy - and having locked it cannot get at the message), and sends the locked box to the receiver
who can unlock it (also easy), having the (private) key. An attacker would have to pick the lock on the box (hard).
Symmetric vs Public-Key
Stallings Table 9.2 summarizes some of the important aspects of symmetric and public-key encryption. To discriminate between
the two, we refer to the key used in symmetric encryption as a secret key. The two keys used for asymmetric encryption are referred
to as the public key and the private key. Invariably, the private key is kept secret, but it is referred to as a private key rather than
a secret key to avoid confusion with symmetric encryption.

30 | P a g e
Public-Key Cryptosystems
Stallings Figure 9.4 “Public-Key Cryptosystems: Secrecy and Authentication” illustrates the essential elements of a
public-key encryption scheme. Note that public-key schemes can be used for either secrecy or authentication, or both
(as shown here). There is some source A that produces a message in plaintext X The M elements of X are letters in
some finite alphabet. The message is intended for destination B. B generates a related pair of keys: a public key, PUb,
and a private key, PRb. PRb is known only to B, whereas PUb is publicly available and therefore accessible by A.
With the message X and the encryption key PUb as input, A forms the ciphertext Y = E(PUb, X) The intended receiver,
in possession of the matching private key, is able to invert the transformation: X = D(PRb, Y) An adversary, observing
Y and having access to PUb, but not having access to PRb or X, must attempt to recover X and/or PRb. This provides
confidentiality. Can also use a public-key encryption to provide authentication: Y = E(PRa, X); X = D(PUa, Y) To
provide both the authentication function and confidentiality have a double use of the public-key scheme (as shown
here): Z = E(PUb, E(PRa, X)) X = D(PUa, D(PRb, Z)) In this case, separate key pairs are used for each of these
purposes. The receiver owns and creates secrecy keys, sender owns and creates authentication keys. In practice
typically DO NOT do this, because of the computational cost of public-key schemes. Rather encrypt a session key
which is then used with a block cipher to encrypt the actual message, and separately sign a hash of the message as a
digital signature - this will be discussed more later.

Public-Key Applications
Public-key systems are characterized by the use of a cryptographic type of algorithm with two keys. Depending on the application,
the sender uses either the sender’s private key or the receiver’s public key, or both, to perform some type of cryptographic function.
In broad terms, we can classify the use of public-key cryptosystems into the three categories:
• Encryption/decryption: The sender encrypts a message with the recipient’s public key.
• Digital signature: The sender “signs” a message with its private key, either to the whole message or to a small block of data that
is a function of the message.
• Key exchange: Two sides cooperate to exchange a session key. Several different approaches are possible, involving the private
key(s) of one or both parties.
Some algorithms are suitable for all three applications, whereas others can be used only for one or two of these applications.
Stallings Table 9.3 (shown here) indicates the applications supported by the algorithms discussed in this book.
can classify uses into 3 categories:
 encryption/decryption (provide secrecy)
 digital signatures (provide authentication)
 key exchange (of session keys)
some algorithms are suitable for all uses, others are specific to one

31 | P a g e
Public-Key Requirements
The cryptosystem illustrated in Figures 9.2 through 9.4 depends on a cryptographic algorithm based on two related
keys. Diffie and Hellman postulated this system without demonstrating that such algorithms exist.
However, they did lay out the conditions that such algorithms must fulfill:
1. It is computationally easy for a party B to generate a pair (public key PUb, private key PRb).
2. It is computationally easy for a sender A, knowing the public key and the message to be encrypted, M, to generate
the corresponding ciphertext: C = E(PUb, M)
3. It is computationally easy for the receiver B to decrypt the resulting ciphertext using the private key to recover
the original message: M = D(PRb, C) = D[PRb, E(PUb, M)
4. It is computationally infeasible for an adversary, knowing the public key, Pb, to determine the private key, PRb
5. It is computationally infeasible for an adversary, knowing the public key, Pb, and a ciphertext, C, to recover the
original message, M.
6. (optional) The two keys can be applied in either order:
M = D[PU , E(PR, M)] = D[PR, E(PU, M)]
These are formidable requirements, as evidenced by the fact that only a few algorithms (RSA, elliptic curve
cryptography, Diffie-Hellman, DSS) have received widespread acceptance in the several decades since the concept of
public-key cryptography was proposed.
Public-Key algorithms rely on two keys where:
 it is computationally infeasible to find decryption key knowing only algorithm & encryption key
 it is computationally easy to en/decrypt messages when the relevant (en/decrypt) key is known
 either of the two related keys can be used for encryption, with the other used for decryption (for some
algorithms)
these are formidable requirements which only a few algorithms have satisfied
The requirements boil down to the need for a trap-door one-way function. A one-way function is one that maps a
domain into a range such that every function value has a unique inverse, with the condition that the calculation of the
function is easy whereas the calculation of the inverse is infeasible:
Y = f(X) easy
X = f–1(Y) infeasible
Generally, easy is defined to mean a problem that can be solved in polynomial time as a function of input length. The
term infeasible is a much fuzzier concept. In general, we can say a problem. Now consider a trap-door one-way
function, which is easy to calculate in one direction and infeasible to calculate in the other direction unless certain
additional information is known. With the additional information the inverse can be calculated in polynomial time.
We can summarize as follows: A trap-door one-way function is a family of invertible functions fk, such that:
Y = fk(X) easy, if k and X are known
X = fk–1(Y) easy, if k and Y are known
X = fk–1(Y) infeasible, if Y known but k not known
Thus, the development of a practical public-key scheme depends on discovery of a suitable trap-door one-way
function.
need a trapdoor one-way function
one-way function has
 Y = f(X) easy
 X = f–1(Y) infeasible
a trap-door one-way function has
 Y = fk(X) easy, if k and X are known
 X = fk–1(Y) easy, if k and Y are known
 X = fk–1(Y) infeasible, if Y known but k not known
a practical public-key scheme depends on a suitable trap-door one-way function
Security of Public Key Schemes
Public key schemes are no more or less secure than private key schemes - in both cases the size of the key determines
the security. As with symmetric encryption, a public-key encryption scheme is vulnerable to a brute-force attack. The
countermeasure is the same: Use large keys. However, there is a tradeoff to be considered. Public-key systems depend
on the use of some sort of invertible mathematical function. The complexity of calculating these functions may not

32 | P a g e
scale linearly with the number of bits in the key but grow more rapidly than that. Thus, the key size must be large
enough to make brute-force attack impractical but small enough for practical encryption and decryption. In practice,
the key sizes that have been proposed do make brute-force attack impractical but result in encryption/decryption
speeds that are too slow for general-purpose use. Instead, as was mentioned earlier, public-key encryption is currently
confined to key management and signature applications. Another form of attack is to find some way to compute the
private key given the public key. To date, it has not been mathematically proven that this form of attack is infeasible
for a particular public-key algorithm. Note also that you can't compare key sizes - a 64-bit private key scheme has
very roughly similar security to a 512-bit RSA - both could be broken given sufficient resources. But with public key
schemes at least there is usually a firmer theoretical basis for determining the security since its based on well-known
and well-studied number theory problems.
 like private key schemes brute force exhaustive search attack is always theoretically possible
 but keys used are too large (>512bits)
 security relies on a large enough difference in difficulty between easy (en/decrypt) and hard (cryptanalyse)
problems
 more generally the hard problem is known, but is made hard enough to be impractical to break
 requires the use of very large numbers
 hence is slow compared to private key schemes
RSA
RSA is the best known, and by far the most widely used general public key encryption algorithm, and was first
published by Rivest, Shamir & Adleman of MIT in 1978 [RIVE78]. The Rivest-Shamir-Adleman (RSA) scheme has
since that time reigned supreme as the most widely accepted and implemented general-purpose approach to public-
key encryption. It is based on exponentiation in a finite (Galois) field over integers modulo a prime, using large
integers (eg. 1024 bits). Its security is due to the cost of factoring large numbers.
 by Rivest, Shamir & Adleman of MIT in 1977
 best known & widely used public-key scheme
 based on exponentiation in a finite (Galois) field over integers modulo a prime
 nb. exponentiation takes O((log n)3) operations (easy)
 uses large integers (eg. 1024 bits)
 security due to cost of factoring large numbers
 nb. factorization takes O(e log n log log n) operations (hard)
RSA En/decryption
The scheme developed by Rivest, Shamir, and Adleman makes use of an expression with exponentials. Plaintext is
encrypted in blocks, with each block having a binary value less than some number n. The actual RSA encryption and
decryption computations are each simply a single exponentiation mod (n). Both sender and receiver must know the
value of n. The sender knows the value of e, and only the receiver knows the value of d. Thus, this is a public-key
encryption algorithm with a public key of PU = {e, n} and a private key of PR = {d, n}. Note that the message must
be smaller than the modulus. The “magic” is in the choice of the modulus and exponents which makes the system
work.
to encrypt a message M the sender:
 obtains public key of recipient PU={e,n}
 computes: C = Me mod n, where 0≤M<n
to decrypt the ciphertext C the owner:
 uses their private key PR={d,n}
 computes: M = Cd mod n
note that the message M must be smaller than the modulus n (block if needed)
RSA Key Setup
The required moduls and exponent values are chosen during key setup. RSA key setup is done once (rarely) when a
user establishes (or replaces) their public key, using the steps as shown. The exponent e is usually fairly small, just
must be relatively prime to ø(n). Need to compute its inverse mod ø(n) to find d. It is critically important that the
factors p & q of the modulus n are kept secret, since if they become known, the system can be broken. Note that
different users will have different moduli n.
each user generates a public/private key pair by selecting two large primes at random: p, q

33 | P a g e
 computing their system modulus n=p.q
 note ø(n)=(p-1)(q-1)
selecting at random the encryption key e
 where 1<e<ø(n), gcd(e,ø(n))=1
solve following equation to find decryption key d
 e.d=1 mod ø(n) and 0≤d≤n
publish their public encryption key: PU={e,n}
keep secret private decryption key: PR={d,n}
Why RSA Works
For this algorithm to be satisfactory for public-key encryption, it must be possible to find values of e, d, n such that
Med mod n = M for all M < n. We need to find a relationship of the form Med mod n = M The preceding relationship
holds if e and d are multiplicative inverses modulo ø (n), where ø (n) is the Euler totient function. This is a direct
consequence of Euler’s Theorem, so that raising a number to power e then d (or vica versa) results in the original
number!
because of Euler's Theorem: aø(n)mod n = 1 where gcd(a,n)=1
in RSA have:
 n=p.q
 ø(n)=(p-1)(q-1)
 carefully chose e & d to be inverses mod ø(n)
 hence e.d=1+k.ø(n) for some k
hence :
Cd = Me.d = M1+k.ø(n) = M1.(Mø(n))k
= M1.(1)k = M1 = M mod n
RSA Example - Key Setup
Stallings provides an example of RSA key generation using “trivial” sized numbers.
Selecting primes requires the use of a primality test.
Finding d as inverse of e mod ø(n) requires use of Euclid’s Inverse algorithm (see Ch4)
1. Select primes: p=17 & q=11
2. Calculate n = pq =17 x 11=187
3. Calculate ø(n)=(p–1)(q-1)=16x10=160
4. Select e: gcd(e,160)=1; choose e=7
5. Determine d: de=1 mod 160 and d < 160 Value is d=23 since 23x7=161= 10x160+1
6. Publish public key PU={7,187}
7. Keep secret private key PR={23,187}
RSA Example - En/Decryption
Then show that the encryption and decryption operations are simple exponentiations mod 187. Rather than having to
laborious repeatedly multiply, can use the "square and multiply" algorithm with modulo reductions to implement all
exponentiations quickly and efficiently (see next).
 sample RSA encryption/decryption is:
 given message M = 88 (nb. 88<187)
 encryption: C = Me mod n
C = 887 mod 187 = 11
 decryption: M = Cd mod n
M = 1123 mod 187 = 88
Exponentiation
To perform the modular exponentiations, you can use the “Square and Multiply Algorithm”, a fast, efficient algorithm
for doing exponentiation, which has a long history. The idea is to repeatedly square the base, and multiply in the ones
that are needed to compute the result, as found by examining the binary representation of the exponent.
can use the Square and Multiply Algorithm
a fast, efficient algorithm for exponentiation
concept is based on repeatedly squaring base
and multiplying in the ones that are needed to compute the result

34 | P a g e
 look at binary representation of exponent
only takes O(log2 n) multiples for number n
 eg. 75 = 74.71 = 3.7 = 10 mod 11
 eg. 3129 = 3128.31 = 5.3 = 4 mod 11
State here one version of the “Square and Multiply Algorithm”, from Stallings Figure 9.8.
c = 0; f = 1
for i = k downto 0
do c = 2 x c
f = (f x f) mod n
if bi == 1 then
c=c+1
f = (f x a) mod n
return f
Efficient Encryption
To speed up the operation of the RSA algorithm using the public key, can choose to use a small value of e. The most
common choice is 65537 (216 + 1); two other popular choices are 3 and 17. Each of these choices has only two 1 bits
and so the number of multiplications required to perform exponentiation is minimized. However, with a very small
public key, such as e = 3, RSA becomes vulnerable to a simple attack. The reader may have noted that the definition
of the RSA algorithm (Figure 9.5) requires that during key generation the user selects a value of e that is relatively
prime to ø (n). Thus, if a value if e is selected first, and the primes p and q are generated, it may turn out that gcd(ø(n),
e) /= 1. In that case, the user must reject the p, q values and generate a new p, q pair.
encryption uses exponentiation to power e
hence if e small, this will be faster
 often choose e=65537 (216-1)
 also see choices of e=3 or e=17
but if e too small (eg e=3) can attack
 using Chinese remainder theorem & 3 messages with different modulii
if e fixed must ensure gcd(e,ø(n))=1
 ie reject any p or q not relatively prime to e
Efficient Decryption
We cannot similarly choose a small constant value of d for efficient operation. A small value of d is vulnerable to a
brute-force attack and to other forms of cryptanalysis [WIEN90]. However, there is a way to speed up computation
using the Chinese Remainder Theorem (CRT) to compute mod p & q separately, and then combine results to get the
desired answer, as shown in the text. This is approx 4 times faster than calculating “Cd mod n” directly. Note that only
the owner of the private key details (who knows the values of p & q) can do this, but of course that’s exactly where
help is needed, since if e is small then d will be likely be large!
decryption uses exponentiation to power d
 this is likely large, insecure if not
can use the Chinese Remainder Theorem (CRT) to compute mod p & q separately. then combine to get
desired answer
 approx 4 times faster than doing directly
only owner of private key who knows values of p & q can use this technique
RSA Key Generation
Before the application of the public-key cryptosystem, each participant must generate a pair of keys, which requires
finding primes and computing inverses. Both the prime generation and the derivation of a suitable pair of inverse
exponents may involve trying a number of alternatives. Typically make random guesses for a possible p or q, and
check using a probabilistic primality test whether the guessed number is indeed prime. If not, try again. Note that the
prime number theorem shows that the average number of guesses needed is not too large. Then compute decryption
exponent d using Euclid’s Inverse Algorithm, which is quite efficient.
users of RSA must:
 determine two primes at random - p, q
 select either e or d and compute the other

35 | P a g e
 primes p,q must not be easily derived from modulus n=p.q
 means must be sufficiently large
 typically guess and use probabilistic test
exponents e, d are inverses, so use Inverse algorithm to compute the other
RSA Security
Note some possible possible approaches to attacking the RSA algorithm, as shown. The defense against the brute-
force approach is the same for RSA as for other cryptosystems, namely, use a large key space. Thus the larger the
number of bits in d, the better. However, because the calculations involved both in key generation and in
encryption/decryption are complex, the larger the size of the key, the slower the system will run. Will now review the
other possible types of attacks.
 possible approaches to attacking RSA are:
 brute force key search - infeasible given size of numbers
 mathematical attacks - based on difficulty of computing ø(n), by factoring modulus n
 timing attacks - on running of decryption
 chosen ciphertext attacks - given properties of RSA
Factoring Problem
We can identify three approaches to attacking RSA mathematically, as shown. Mathematicians currently believe all equivalent to
factoring. See Stallings Table 9.4 (next slide) for progress in factoring, where see slow improvements over the years, with the
biggest improvements coming from improved algorithms. The best current algorithm is the “Lattice Sieve” (LS), which replaced
the “Generalized Number Field Sieve” (GNFS), which replaced the “Quadratic Sieve”(QS). Have to assume computers will
continue to get faster, and that better factoring algorithms may yet be found. Thus, we need to be careful in choosing a key size for
RSA. For the near future, a key size in the range of 1024 to 2048 bits seems reasonable. In addition to specifying the size of n, a
number of other constraints have been suggested by researchers. To avoid values of n that may be factored more easily, the
algorithm's inventors suggest the following constraints on p and q:
1. p and q should differ in length by only a few digits. Thus, for a 1024-bit key (309 decimal digits), both p and q should be
on order of 1075 to 10100.
2. Both (p – 1) and (q – 1) should contain a large prime factor
3. gcd(p–1, q–1) should be small.
mathematical approach takes 3 forms:
 factor n=p.q, hence compute ø(n) and then d
 determine ø(n) directly and compute d
 find d directly
currently believe all equivalent to factoring
 have seen slow improvements over the years
 as of May-05 best is 200 decimal digits (663) bit with LS
 biggest improvement comes from improved algorithm
 cf QS to GHFS to LS
 currently assume 1024-2048 bit RSA is secure
 ensure p, q of similar size and matching other constraints
Progress in Factoring
Stallings Table 9.5 shows the progress in factoring to date. The level of effort is measured in MIPS-years: a million-instructions-
per-second processor running for one year, which is about 3 x 10 13 instructions executed. A 1 GHz Pentium is about a 250-MIPS
machine.

36 | P a g e
The threat to larger key sizes is twofold: the continuing increase in computing power, and the continuing refinement of factoring
algorithms. We have seen that the move to a different algorithm resulted in a tremendous speedup. We can expect further
refinements in the GNFS, and the use of an even better algorithm is also a possibility. In fact, a related algorithm, the special
number field sieve (SNFS), can factor numbers with a specialized form considerably faster than the generalized number field sieve.
Stallings Figure 9.9 compares the performance of the two algorithms. It is reasonable to expect a breakthrough that would enable
a general factoring performance in about the same time as SNFS, or even better.
Timing Attacks
Have a radical new category of attacks developed by Paul Kocher in mid-1990’s, based on observing how long it takes to compute
the cryptographic operations. Timing attacks are applicable not just to RSA, but to other public-key cryptography systems. This
attack is alarming for two reasons: It comes from a completely unexpected direction and it is a ciphertext-only attack. A timing
attack is somewhat analogous to a burglar guessing the combination of a safe by observing how long it takes for someone to turn
the dial from number to number. Although the timing attack is a serious threat, there are simple countermeasures that can be used,
including using constant exponentiation time algorithms, adding random delays, or using blind values in calculations.
developed by Paul Kocher in mid-1990’s
exploit timing variations in operations
 eg. multiplying by small vs large number
 or IF's varying which instructions executed
infer operand size based on time taken
RSA exploits time taken in exponentiation
countermeasures
 use constant exponentiation time
 add random delays
 blind values used in calculations
Chosen Ciphertext Attacks
The RSA algorithm is vulnerable to a chosen ciphertext attack (CCA). CCA is defined as an attack in which adversary chooses a
number of ciphertexts and is then given the corresponding plaintexts, decrypted with the target’s private key. The adversary exploits
properties of RSA and selects blocks of data that, when processed using the target’s private key, yield information needed for
cryptanalysis. Can counter simple attacks with random pad of plaintext. More sophisticated variants need to modify the plaintext
using a procedure known as optimal asymmetric encryption padding (OAEP).
• RSA is vulnerable to a Chosen Ciphertext Attack (CCA)
• attackers chooses ciphertexts & gets decrypted plaintext back
• choose ciphertext to exploit properties of RSA to provide info to help cryptanalysis
• can counter with random pad of plaintext
• or use Optimal Asymmetric Encryption Padding (OASP)
Optimal Asymmetric Encryption Padding (OASP)
To counter such attacks RSA Security Inc., a leading RSA vendor and former holder of the RSA patent, recommends modifying
the plaintext using a procedure known as optimal asymmetric encryption padding (OAEP). Stallings Figure 9.10 depicts OAEP
encryption. As a first step the message M to be encrypted is padded. A set of optional parameters P is passed through a hash function
H. The output is then padded with zeros to get the desired length in the overall data block (DB). Next, a random seed is generated
and passed through another hash function, called the mask generating function (MGF). The resulting hash value is bit-by-bit XORed
with DB to produce a maskedDB. The maskedDB is in turn passed through the MGF to form a hash that is XORed with the seed
to produce the masked seed. The concatenation of the maskedseed and the maskedDB forms the encoded message EM. Note that
the EM includes the padded message, masked by the seed, and the seed, masked by the maskedDB. The EM is then encrypted using RSA.

37 | P a g e
Chapter-4 Network Security Applications
 Authentication Applications: Kerberos, Public Key infrastructure, Directory Authentication Service
 Electronic Mail Security: Pretty good Privacy (PGP), S/MIME
 Internet Protocol Security(IPSec)
 Network management security
We cannot enter into alliance with neighbouring princes until we are acquainted with their designs. —The Art of War, Sun Tzu
User Authentication
This chapter examines some of the authentication functions that have been developed to support network-based use
authentication. In most computer security contexts, user authentication is the fundamental building block and the
primary line of defense. User authentication is the basis for most types of access control and for user accountability.
RFC 2828 defines user authentication as the process of verifying an identity claimed by or for a system entity. An
authentication process consists of two steps:
• Identification step: Presenting an identifier to the security system. (Identifiers should be assigned carefully, because
authenticated identities are the basis for other security services, such as access control service.)
• Verification step: Presenting or generating authentication information that corroborates the binding between the entity and
the identifier.”
In essence, identification is the means by which a user provides a claimed identity to the system; user authentication is the means
of establishing the validity of the claim. Note that user authentication is distinct from message authentication.
 fundamental security building block basis of access control & user accountability
 is the process of verifying an identity claimed by or for a system entity
 has two steps:
 identification - specify identifier
 verification - bind entity (person) and identifier
 distinct from message authentication
Means of User Authentication
There are four general means of authenticating a user's identity, which can be used alone or in combination:
• Something the individual knows: Examples includes a password, a personal identification number (PIN), or answers to a
prearranged set of questions.
• Something the individual possesses: Examples include electronic keycards, smart cards, and physical keys. This type of
authenticator is referred to as a token.
• Something the individual is (static biometrics): Examples include recognition by fingerprint, retina, and face.
• Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting
characteristics, and typing rhythm.
All of these methods, properly implemented and used, can provide secure user authentication. However, each method
has problems. An adversary may be able to guess or steal a password. Similarly, an adversary may be able to forge or
steal a token. A user may forget a password or lose a token. Further, there is a significant administrative overhead for
managing password and token information on systems and securing such information on systems. With respect to
biometric authenticators, there are a variety of problems, including dealing with false positives and false negatives,
user acceptance, cost, and convenience.
Authentication Protocols
An important application area is that of mutual authentication protocols. Such protocols enable communicating parties
to satisfy themselves mutually about each other's identity and to exchange session keys. This topic was examined in
Chapter 14. There, the focus was key distribution. We return to this topic here to consider the wider implications of
authentication. Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness.
To prevent masquerade and to prevent compromise of session keys, essential identification and session key
information must be communicated in encrypted form. This requires the prior existence of secret or public keys that
can be used for this purpose. The second issue, timeliness, is important because of the threat of message replays.
used to convince parties of each others identity and to exchange session keys
may be one-way or mutual
key issues are
 confidentiality – to protect session keys
 timeliness – to prevent replay attacks

38 | P a g e
Replay Attacks
Replay Attacks are where a valid signed message is copied and later resent. Such replays, at worst, could allow an
opponent to compromise a session key or successfully impersonate another party. At minimum, a successful replay
can disrupt operations by presenting parties with messages that appear genuine but are not. [GONG93] lists the
examples above of replay attacks.
Possible countermeasures include the use of:
• sequence numbers (generally impractical since must remember last number used with every communicating party)
• timestamps (needs synchronized clocks amongst all parties involved, which can be problematic)
• challenge/response (using unique, random, unpredictable nonce, but not suitable for connectionless applications
because of handshake overhead)
where a valid signed message is copied and later resent
 simple replay
 repetition that can be logged
 repetition that cannot be detected
 backward replay without modification
countermeasures include
 use of sequence numbers (generally impractical)
 timestamps (needs synchronized clocks)
 challenge/response (using unique nonce)
One-Way Authentication
One application for which encryption is growing in popularity is electronic mail (e-mail). The very nature of electronic
mail, and its chief benefit, is that it is not necessary for the sender and receiver to be online at the same time. Instead,
the e-mail message is forwarded to the receiver’s electronic mailbox, where it is buffered until the receiver is available
to read it. The "envelope" or header of the e-mail message must be in the clear, so that the message can be handled by
the store-and-forward e-mail protocol, such as the Simple Mail Transfer Protocol (SMTP) or X.400. However, it is
often desirable that the mail-handling protocol not require access to the plaintext form of the message, because that
would require trusting the mail- handling mechanism. Accordingly, the e-mail message should be encrypted such that
the mail- handling system is not in possession of the decryption key. A second requirement is that of authentication.
Typically, the recipient wants some assurance that the message is from the alleged sender.
 required when sender & receiver are not in communications at same time (eg. email)
 have header in clear so can be delivered by email system
 may want contents of body protected & sender authenticated
Using Symmetric Encryption
A two-level hierarchy of symmetric encryption keys can be used to provide confidentiality for communication in a
distributed environment. Usually involves the use of a trusted key distribution center (KDC). Each party in the network
shares a secret master key with the KDC. The KDC is responsible for generating session keys, and for distributing
those keys to the parties involved, using the master keys to protect these session keys.
 as discussed previously can use a two-level hierarchy of keys
 usually with a trusted Key Distribution Center (KDC)
 each party shares own master key with KDC
 KDC generates session keys used for connections between parties
 master keys used to distribute these to them
Needham-Schroeder Protocol
The Needham-Schroeder Protocol is the original, basic key exchange protocol, as was shown in Stallings Figure 14.3 (previous
chapter). Used by 2 parties who both trusted a common key server, it gives one party the info needed to establish a session key
with the other. Note that since the key server chooses the session key, it is capable of reading/forging any messages between A&B,
which is why they need to trust it absolutely! Note that all communications is between A&KDC and A&B, B&KDC don't talk
directly (though indirectly a message passes from KDC via A to B, encrypted in B's key so that A is unable to read or alter it).
Other variations of key distribution protocols can involve direct communications between B&KDC.
 original third-party key distribution protocol
 for session between A B mediated by KDC
 protocol overview is:

39 | P a g e
1. A->KDC: IDA || IDB || N1
2. KDC -> A: E(Ka,[Ks||IDB||N1|| E(Kb,[Ks||IDA])])
3. A -> B: E(Kb, [Ks||IDA])
4. B -> A: E(Ks, [N2])
5. A -> B: E(Ks, [f(N2)])
There is a critical flaw in the protocol, as shown. The message in step 3 can be decrypted, and hence understood,
supposedly only by B. But if an opponent, X, has been able to compromise an old session key, then X can impersonate
A and trick B into using the old key by simply replaying step 3. Admittedly, this is a much more unlikely occurrence
than that an opponent has simply observed and recorded step 3. It can however be corrected by either using timestamps,
or an additional nonce, with respective advantages and limitations, see text for discussion.
This example emphasises the need to be extremely careful in codifying assumptions, and tracking the timeliness of
the flow of info in protocols. Designing secure protocols is not easy, and should not be done lightly. Great care and
analysis is needed.
 used to securely distribute a new session key for communications between A & B
 but is vulnerable to a replay attack if an old session key has been compromised
 then message 3 can be resent convincing B that is communicating with A
 modifications to address this require:
 timestamps in steps 2 & 3 (Denning 81)
 using an extra nonce (Neuman 93)
One-Way Authentication
With some refinement, the KDC strategy illustrated in Stallings Figure 14.3 (previous chapter) is a candidate for
securing electronic mail. Because we wish to avoid requiring that the recipient (B) be on line at the same time as the
sender (A), steps 4 and 5 must be eliminated. For a message with content M, the sequence is as shown. This approach
guarantees that only the intended recipient of a message will be able to read it. It also provides a level of authentication
that the sender is A. As specified, the protocol does not protect against replays. Some measure of defense could be
provided by including a timestamp with the message. However, because of the potential delays in the e-mail process,
such timestamps may have limited usefulness.
 use refinement of KDC to secure email
 since B no online, drop steps 4 & 5
 protocol becomes:
1. A->KDC: IDA || IDB || N1
2. KDC -> A: E(Ka, [Ks||IDB||N1 || E(Kb,[Ks||IDA])])
3. A -> B: E(Kb, [Ks||IDA]) || E(Ks, M)
 provides encryption & some authentication
 does not protect from replay attack
Kerberos
Kerberos is an authentication service developed as part of Project Athena at MIT, and is one of the best known and
most widely implemented trusted third party key distribution systems. Kerberos provides a centralized
authentication server whose function is to authenticate users to servers and servers to users. Unlike most other
authentication schemes, Kerberos relies exclusively on symmetric encryption, making no use of public-key
encryption. Two versions of Kerberos are in common use: v4 & v5.
 trusted key server system from MIT
 provides centralised private-key third-party authentication in a distributed network
 allows users access to services distributed through network
 without needing to trust all workstations
 rather all trust a central authentication server
 two versions in use: 4 & 5
Kerberos Requirements
In a more open environment, in which network connections to other machines are supported, an approach that requires
the user to prove his or her identity for each service invoked, and also require that servers prove their identity to clients,
is needed to protect user information and resources housed at the server. Kerberos supports this approach, and assumes

40 | P a g e
a distributed client/server architecture that employs one or more Kerberos servers to provide an authentication service.
The first published report on Kerberos [STEI88] listed the following requirements:
• Secure: A network eavesdropper should not be able to obtain the necessary information to impersonate a user. More
generally, Kerberos should be strong enough that a potential opponent does not find it to be the weak link.
• Reliable: For all services that rely on Kerberos for access control, lack of availability of the Kerberos service means
lack of availability of the supported services. Hence, Kerberos should be highly reliable and should employ a
distributed server architecture, with one system able to back up another.
• Transparent: Ideally, the user should not be aware that authentication is taking place, beyond the requirement to
enter a password.
• Scalable: The system should be capable of supporting large numbers of clients and servers. This suggests a modular,
distributed architecture.
To support these requirements, Kerberos is a trusted third-party authentication service that uses a protocol based on
that proposed by Needham and Schroeder which was discussed earlier in this chapter.
 its first report identified requirements as:
• secure
• reliable
• transparent
• scalable
 implemented using an authentication protocol based on Needham-Schroeder
Kerberos v4 Overview
The core of Kerberos is the Authentication and Ticket Granting Servers – these are trusted by all users and servers
and must be securely administered. The protocol includes a sequence of interactions between the client, AS, TGT and
desired server. Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide the authentication
service. Viewing the protocol as a whole, it can be difficult to see the need for the many elements contained therein.
The text contains more detailed discussion about the development of and need for the components of the final v4
protocol.
 a basic third-party authentication scheme
 have an Authentication Server (AS)
• users initially negotiate with AS to identify self
• AS provides a non-corruptible authentication credential (ticket granting ticket TGT)
 have a Ticket Granting server (TGS)
• users subsequently request access to other services from TGS on basis of users TGT
 using a complex protocol using DES
Kerberos v4 Dialogue
The full Kerberos v4 authentication dialogue is shown here from Stallings Table 15.1, divided into 3 phases. The
justification for each item in the messages is given in Stallings Table 15.2. First, consider the problem of captured
ticket-granting tickets and the need to determine that the ticket presenter is the same as the client for whom the ticket
was issued. An efficient way of doing this is to use a session encryption key to secure information. Table 15.1a shows
the technique for distributing the session key. Note that several additional pieces of information have been added to
this first phase of the dialogue. Message (1) includes a timestamp, so that the AS knows that the message is timely.
Message (2) includes several elements of the ticket in a form accessible to C. This enables C to confirm that this ticket
is for the TGS and to learn its expiration time. Note that the ticket does not prove anyone's identity but is a way to
distribute keys securely. It is the authenticator that proves the client's identity. Because the authenticator can be used
only once and has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for
presentation later is countered. C then sends the TGS a message that includes the ticket plus the ID of the requested
service (message 3). The reply from the TGS, in message (4), follows the form of message (2). C now has a reusable
service-granting ticket for V. When C presents this ticket, as shown in message (5), it also sends an authenticator. The
server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is
required, the server can reply as shown in message (6)

41 | P a g e
 Stallings Figure 15.1 diagrammatically summarizes the Kerberos v4 authentication dialogue, with 3 pairs of messages, for each phase listed previously.
Kerberos Realms
A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a number of application
servers is referred to as a Kerberos realm. A Kerberos realm is a set of managed nodes that share the same Kerberos
database, and are part of the same administrative domain. If have multiple realms, their Kerberos servers must share
keys and trust each other.
a Kerberos environment consists of:
 a Kerberos server
 a number of clients, all registered with server
 application servers, sharing keys with server
this is termed a realm
 typically, a single administrative domain
if have multiple realms, their Kerberos servers must share keys and trust

42 | P a g e
Stallings Figure 15.2 shows the authentication messages where service is being requested from another domain. The
ticket presented to the remote server indicates the realm in which the user was originally authenticated. The server
chooses whether to honor the remote request. One problem presented by the foregoing approach is that it does not
scale well to many realms, as each pair of realms need to share a key.

Kerberos Version 5
Kerberos Version 5 is specified in RFC 1510 and provides a number of improvements over version 4 in the areas of
environmental shortcomings and technical deficiencies, in areas as noted. See Stallings Table 14.3 for details of the
Kerberos v5 authentication dialogue.
developed in mid 1990’s
specified as Internet standard RFC 1510
provides improvements over v4
 addresses environmental shortcomings
 encryption alg, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm auth
 and technical deficiencies
 double encryption, non-std mode of use, session keys, password attacks
Kerberos v5 Dialogue
The basic Kerberos version 5 authentication dialogue is shown here from Stallings Table 15.3. First, consider the authentication
service exchange.
Message (1) is a client request for a ticket-granting ticket.
Message (2) returns a ticket-granting ticket, identifying information for the client, and a block encrypted using the encryption key
based on the user's password. This block includes the session key to be used between the client and the TGS. Now compare the
ticket-granting service exchange for versions 4 and 5. See that message (3) for both versions includes an authenticator, a ticket,
and the name of the requested service. In addition, version 5 includes requested times and options for the ticket and a nonce, all
with functions similar to those of message (1). The authenticator itself is essentially the same as the one used in version 4. Message
(4) has the same structure as message (2), returning a ticket plus information needed by the client, the latter encrypted with the
session key now shared by the client and the TGS. Finally, for the client/server authentication exchange, several new features
appear in version 5, such as a request for mutual authentication. If required, the server responds with message (6) that includes the
timestamp from the authenticator. The flags field included in tickets in version 5 supports expanded functionality compared to that
available in version 4. Stallings Table 15.4 summarizes the flags that may be included in a ticket., with discussion of details in the
text.

43 | P a g e
Remote User Authentication
In Chapter 14, we presented one approach to the use of public-key encryption for the purpose of session key distribution (Figure
14.8). This protocol assumes that each of the two parties is in possession of the current public key of the other. It may not be
practical to require this assumption. A protocol using timestamps is provided in [DENN81] that uses a central system, referred to
as an authentication server (AS), because it is not actually responsible for secret key distribution. Rather, the AS provides public-
key certificates. The session key is chosen and encrypted by A; hence, there is no risk of exposure by the AS. The timestamps
protect against replays of compromised keys. See text for details. This protocol is compact but, as before, requires synchronization
of clocks. Another approach, proposed by Woo and Lam [WOO92a], makes use of nonces. Note the authors themselves spotted a
flaw in it and submitted a revised version of the algorithm in [WOO92b]. In both this example and the protocols described earlier,
protocols that appeared secure were revised after additional analysis. These examples highlight the difficulty of getting things right
in the area of authentication.
public-key encryption for session key distribution
 assumes both parties have other’s public keys
 may not be practical
 have Denning protocol using timestamps
 uses central authentication server (AS) to provide public-key certificates
 requires synchronized clocks
 have Woo and Lam protocol using nonces
 care needed to ensure no protocol flaws
One-Way Authentication
We have already presented public-key encryption approaches that are suited to electronic mail, including the straightforward
encryption of the entire message for confidentiality (Figure 12.1b), authentication (Figure 12.1c), or both (Figure 12.1d). These
approaches require that either the sender know the recipient's public key (confidentiality) or the recipient know the sender's public
key (authentication) or both (confidentiality plus authentication). In addition, the public-key algorithm must be applied once or
twice to what may be a long message. If confidentiality is the primary concern, then better to encrypt the message with a one-time
secret key, and also encrypt this one-time key with B's public key. If authentication is the primary concern, then a digital signature
may suffice (but could be replaced by an opponent). To counter such a scheme, both the message and signature can be encrypted
with the recipient's public key. The latter two schemes require that B know A's public key and be convinced that it is timely. An
effective way to provide this assurance is the digital certificate.
 have public-key approaches for email
 encryption of message for confidentiality, authentication, or both
 must know public keys
 using costly public-key alg on long message
 for confidentiality encrypt message with one-time secret key, public-key encrypted
 for authentication use a digital signature
 may need to protect by encrypting signature
 use digital certificate to supply public key
Federated Identity Management
Federated identity management is a relatively new concept dealing with the use of a common identity management scheme across
multiple enterprises and numerous applications and supporting many thousands, even millions of users. Identity management is a
centralized, automated approach to provide enterprise-wide access to resources by employees and other authorized individuals,

44 | P a g e
defining an identity for each user (human or process), associating attributes with the identity, and enforcing a means by which a
user can verify identity. Its principal elements are:
• Authentication: confirmating user corresponds to the user name provided.
• Authorization: granting access to services/resources given user authentication.
• Accounting: process for logging access and authorization.
• Provisioning: enrollment of users in the system.
• Workflow automation: movement of data in a business process.
• Delegated administration: use of role-based access control to grant permissions.
• Password synchronization: Creating a process for single sign-on (SSO) or reduced sign-on (RSO).
• Self-service password reset: enable user to modify their password
• Federation: process where authentication and permission will be passed on from one system to another, usually across multiple
enterprises, reducing the number of authentications needed by the user.
Kerberos contains a number of the elements of an identity management system.
 use of common identity management scheme
 across multiple enterprises & numerous applications
 supporting many thousands, even millions of users
 principal elements are:
 authentication, authorization, accounting, provisioning, workflow automation, delegated administration, password
synchronization, self-service password reset, federation
 Kerberos contains many of these elements
Identity Management
Figure 15.3 illustrates entities and data flows in a generic identity management architecture. A principal is an identity holder.
Typically, this is a human user that seeks access to resources and services on the network. User devices, agent processes, and server
systems may also function as principals. Principals authenticate themselves to an identity provider. The identity provider
associates authentication information with a principal, as well as attributes and one or more identifiers. Increasingly, digital
identities incorporate attributes other than simply an identifier and authentication information (such as passwords and biometric
information). An attribute service manages the creation and maintenance of such attributes. For example, a user needs to provide
a shipping address each time an order is placed at a new Web merchant, and this information needs to be revised when the user
moves. Identity management enables the user to provide this information once, so that it is maintained in a single place and released
to data consumers in accordance with authorization and privacy policies. Users may create some of the attributes to be associated
with their digital identity, such as address. Administrators may also assign attributes to users, such as roles, access permissions,
and employee information.
Data consumers are entities that obtain and employ data maintained and provided by identity and attribute providers, often to
support authorization decisions and to collect audit information. For example, a database server or file server is a data consumer
that needs a client's credentials so as to know what access to provide to that client.

Identity Federation
Identity federation is, in essence, an extension of identity management to multiple security domains. Federated identity management
refers to the agreements, standards, and technologies that enable the portability of identities, identity attributes, and entitlements
across multiple enterprises and numerous applications and supporting many thousands, even millions, of users. Stallings Figure
15.4 illustrates entities and data flows in a generic federated identity management architecture. The identity provider acquires
attribute information through dialogue and protocol exchanges with users and administrators. Identity management enables the user
to provide this information once, so that it is maintained in a single place and released to data consumers in accordance with
authorization and privacy policies. Service providers are entities that obtain and employ data maintained and provided by identity
providers, often to support authorization decisions and to collect audit information. A service provider can be in the same domain

45 | P a g e
as the user and the identity provider. The power of this approach is for federated identity management, in which the service provider
is in a different domain.

Standards Used
Federated identity management uses a number of standards as the building blocks for secure identity exchange across different
domains or heterogeneous systems. In essence, organizations issue some form of security tickets for their users that can be processed
by cooperating partners. Identity federation standards are thus concerned with defining these tickets, in terms of content and format,
providing protocols for exchanging tickets and performing a number of management tasks. These tasks include configuring systems
to perform attribute transfers and identity mapping, and performing logging and auditing functions. The principal underlying
standard for federated identity is the Security Assertion Markup Language (SAML), which SAML is an XML-based language that
defines the exchange of security information between online business partners. SAML conveys authentication information in the
form of assertions about subjects. Assertions are statements about the subject issued by an authoritative entity. SAML is part of a
broader collection of standards being issued by OASIS (Organization for the Advancement of Structured Information Standards)
for federated identity management. For example, WS-Federation enables browser-based federation; it relies on a security token
service to broker trust of identities, attributes, and authentication between participating Web services. The challenge with federated
identity management is to integrate multiple technologies, standards, and services to provide a secure, user-friendly utility. The
key, as in most areas of security and networking, is the reliance on a few mature standards widely accepted by industry. Federated
identity management seems to have reached this level of maturity.
 Security Assertion Markup Language (SAML)
 XML-based language for exchange of security information between online business partners
 part of OASIS (Organization for the Advancement of Structured Information Standards) standards for federated identity
management
 e.g. WS-Federation for browser-based federation
 need a few mature industry standards
Federated Identity Examples
To get some feel for the functionality of identity federation, we look at three scenarios, taken from [COMP06] (more details in
text). In the first (Figure 15.5a), Workplace.com contracts with Health.com to provide employee health benefits. An employee
signs on and authenticates to Workplace.com. The two organizations federated and cooperatively exchanges user identifiers.
Health.com maintains user identities for every employee at Workplace.com and associates with each identity health benefits info
& access rights. Figure 15.5b shows another browser-based scheme. PartsSupplier.com is a regular supplier of parts to
Workplace.com. A role-based access control (RBAC) scheme is used. An engineer of Workplace.com authenticates to
Workplace.com and clicks on a link to access information at PartsSupplier.com. For this scenario, PartSupplier.com does not have
identity information for individual employees at Workplace.com. Rather, the linkage between the two federated partners is in terms
of roles. The scenario in Figure 15.5c can be referred to as document-based. Workplace.com has a purchasing agreement with
PinSupplies.com which has a business relationship with E-Ship.com. An employee of WorkPlace.com signs on and is authenticated
to make purchases. The procurement application generates an XML/SOAP order document, and inserts into the header the user's
credentials and Workplace.com's organizational identity. It then posts the message to the PinSupplies.com's purchasing Web
service. This service authenticates the incoming message and processes the request, sending a SOAP message to its shipping partner
to fulfill the order.

46 | P a g e
Chapter-5 Network Security Applications [Email, IPSEC]
Despite the refusal of VADM Poindexter and LtCol North to appear, the Board's access to other sources of information filled much of this gap. The
FBI provided documents taken from the files of the National Security Advisor and relevant NSC staff members, including messages from the PROF
system between VADM Poindexter and LtCol North. The PROF messages were conversations by computer, written at the time events occurred and
presumed by the writers to be protected from disclosure. In this sense, they provide a first-hand, contemporaneous account of events.
—The Tower Commission Report to President Reagan on the Iran-Contra Affair, 1987 Electronic Mail(Email) Security
In virtually all distributed environments, electronic mail is the most heavily used network-based application. But
current email services are roughly like "postcards”, anyone who wants could pick it up and have a look as its in transit
or sitting in the recipients mailbox.
 email is one of the most widely used and regarded network services
 currently message contents are not secure
 may be inspected either in transit
 or by suitably privileged users on destination system
Email Security Enhancements
With the explosively growing reliance on electronic mail for every conceivable purpose, there grows a demand for
authentication and confidentiality services. What we want is something more akin to standard mail (contents protected
inside an envelope) if not registered mail (have confidence about the sender of the mail and its contents). That is, the
“classic” security services listed are desired.
 confidentiality
 protection from disclosure
 authentication
 of sender of message
 message integrity
 protection from modification
 non-repudiation of origin
 protection from denial by sender
Pretty Good Privacy (PGP)
The Pretty Good Privacy (PGP) secure email program, is a remarkable phenomenon, has grown explosively and is
now widely used. Largely the effort of a single person, Phil Zimmermann, who selected the best available crypto
algorithms to use & integrated them into a single program, PGP provides a confidentiality and authentication service
that can be used for electronic mail and file storage applications. It runs on a wide range of systems, in both free &
commercial versions.
 widely used de facto secure email
 developed by Phil Zimmermann
 selected best available crypto algs to use
 integrated into a single program
 on Unix, PC, Macintosh and other systems
 originally free, now also have commercial versions available
PGP Operation – Authentication
The actual operation of PGP, as opposed to the management of keys, consists of four services: authentication,
confidentiality, compression, and e-mail compatibility. Stallings Figure 18.1a illustrates the digital signature service
provided by PGP. This is the digital signature scheme discussed in Chapter 13 and illustrated in Figure 13.2. The
sequence is as listed. Note this assumes use of RSA digital signatures, created using the sender's private key, and
verified with the sender's public key. Recent PGP versions also support the use of DSS signatures. Signatures can also
be detached from a message/file and sent/stored separately. This can be useful to maintain a separate signature log of
all messages sent or received; or on an executable program to detect subsequent virus infection, or when more than
one party must sign a document.
1. sender creates message
2. make SHA-1160-bit hash of message
3. attached RSA signed hash to message
4. receiver decrypts & recovers hash code
5. receiver verifies received message hash

47 | P a g e
PGP Operation – Confidentiality
Another basic service provided by PGP is confidentiality, provided by encrypting messages to be transmitted or to be
stored locally as files, using symmetric encryption algorithms CAST-128, IDEA or 3DES in 64-bit cipher feedback
(CFB) mode. The randomly chosen session key used for this is sent encrypted using the recipient’s public RSA key.
The steps used in this process are as listed. Stallings Figure 18.1b illustrates the sequence. Recent PGP versions also
support the use of ElGamal (a Diffie-Hellman variant) for session-key exchange.
1. sender forms 128-bit random session key
2. encrypts message with session key
3. attaches session key encrypted with RSA
4. receiver decrypts & recovers session key
5. session key is used to decrypt message

PGP Operation – Confidentiality & Authentication

As Stallings Figure 18.1c illustrates, both confidentiality & authentication services may be used for the same message.
Firstly, a signature is generated for the plaintext message and prepended to the it. Then the plaintext message plus
signature is encrypted using CAST-128 (or IDEA or 3DES), and the session key is encrypted using RSA (or ElGamal).
This sequence is preferable to the opposite: encrypting the message and then generating a signature for the encrypted
message. It is generally more convenient to store a signature with a plaintext version of a message. Furthermore, for
purposes of third-party verification, if the signature is performed first, a third party need not be concerned with the
symmetric key when verifying the signature. In summary, when both services are used, the sender first signs the
message with its own private key, then encrypts the message with a session key, and then encrypts the session key
with the recipient's public key.
can use both services on same message
 create signature & attach to message
 encrypt both message & signature
 attach RSA/ElGamal encrypted session key

48 | P a g e
PGP Operation – Compression
By default, PGP compresses the message after applying the signature but before encryption. This has the benefit of
saving space both for e-mail transmission and for file storage. The signature is generated before compression for the
reasons shown. The compression algorithm used is ZIP, and is indicated by Z for compression and Z–1 for
decompression in Figure 18.1. It is described in Online Appendix O.
 by default PGP compresses message after signing but before encrypting
 so can store uncompressed message & signature for later verification
 & because compression is non deterministic
 uses ZIP compression algorithm
PGP Operation – Email Compatibility
When PGP is used, at least part of the block to be transmitted is encrypted, and thus consists of a stream of arbitrary
8-bit octets. However, many electronic mail systems only permit the use of ASCII text. To accommodate this
restriction, PGP provides the service of converting the raw 8-bit binary stream to a stream of printable ASCII
characters. It uses radix-64 conversion, in which each group of three octets of binary data is mapped into four ASCII
characters. The use of radix 64 expands a message by 33%. Fortunately, the session key and signature portions of the
message are relatively compact, and the plaintext message has been compressed, often by more than enough to
compensate for the radix-64 expansion. This format also appends a CRC to detect transmission errors. See Stallings
Appendix 18A for a description. PGP also automatically subdivides a message that is too large for a single email, into
segments that are small enough to send.
 when using PGP will have binary data to send (encrypted message etc)
 however email was designed only for text
 hence PGP must encode raw binary data into printable ASCII characters
 uses radix-64 algorithm
 maps 3 bytes to 4 printable chars
 also appends a CRC
 PGP also segments messages if too big
PGP Operation – Summary
Stallings Figure 18.2 illustrates the general operation of PGP, and the relationship between the services discussed. On
transmission, if it is required, a signature is generated using a hash code of the uncompressed plaintext. Then the
plaintext, plus signature if present, is compressed. Next, if confidentiality is required, the block (compressed plaintext
or compressed signature plus plaintext) is encrypted and pre-pended with the public-key-encrypted symmetric
encryption key. Finally, the entire block is converted to radix-64 format. On reception, the incoming block is first
converted back from radix-64 format to binary. Then, if the message is encrypted, the recipient recovers the session
key and decrypts the message. The resulting block is then decompressed. If the message is signed, the recipient
recovers the transmitted hash code and compares it to its own calculation of the hash code.

49 | P a g e
PGP Session Keys
PGP makes use of four types of keys: one-time session symmetric keys, public keys, private keys, and passphrase-
based symmetric keys. Each session key is associated with a single message and is used only for the purpose of
encrypting and decrypting that message, using a symmetric encryption algorithm, such as CAST-128 and IDEA with
128-bit keys; or 3DES with a 168-bit key. Random numbers are generated using the ANSI X12.17 generator, with
inputs based on keystroke input from the user, where both the keystroke timing and the actual keys struck are used to
generate a randomized stream of numbers. Stallings Online Appendix P discusses PGP random number generation
techniques in more detail.
 need a session key for each message
• of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit Triple-DES
 generated using ANSI X12.17 mode
 uses random inputs taken from previous uses and from keystroke timing of user
PGP Public & Private Keys
Since many public/private keys may be in use with PGP, there is a need to identify which key is actually used to
encrypt the session key for any specific message. You could just send the full public-key with every message, but this
is inefficient. Rather PGP use a key identifier based on the least significant 64-bits of the key, which will very likely
be unique. Then only the much shorter key ID would need to be transmitted with any message. A key ID is also
required for the PGP digital signature.
 since many public/private keys may be in use, need to identify which is actually used to encrypt session key in a message
• could send full public-key with every message
• but this is inefficient
 rather use a key identifier based on key
• is least significant 64-bits of the key
• will very likely be unique
 also use key ID in signatures
PGP Message Format
Stallings Figure 18.3 shows the format of a transmitted PGP message. A message consists of three components: the
message component, a signature (optional), and a session key component (optional). The message component
includes the actual data to be stored or transmitted, as well as a filename and a timestamp that specifies the time of
creation. The signature component includes a timestamp, encrypted SHA-1 message digest, leading two digest octets
for verification, and the Key ID of the sender’s public key. The session key component includes the session key and
the identifier of the recipient's public key that was used by the sender to encrypt the session key. The entire block is
usually encoded with radix-64 encoding.

50 | P a g e
PGP Key Rings
Keys & key IDs are critical to the operation of PGP. These keys need to be stored and organized in a systematic way
for efficient and effective use by all parties. PGP uses a pair of data structures, one to store the users public/private
key pairs - their private-key ring; and one to store the public keys of other known users, their public-key ring. The
private keys are kept encrypted using a block cipher, with a key derived by hashing a pass-phrase which the user enters
whenever that key needs to be used. As in any system based on passwords, the security of this system depends on the
security of the password, which should be not easily guessed but easily remembered.
 each PGP user has a pair of keyrings:
• public-key ring contains all the public-keys of other PGP users known to this user, indexed by key ID
• private-key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted keyed
from a hashed passphrase
 security of private keys thus depends on the pass-phrase security
Stallings Figure 18.4 shows the general structure of a private-key ring. We can view the ring as a table, in which each row
represents one of the public/private key pairs owned by this user. The private-key ring can be indexed by either User ID or Key ID.
The actual private key itself encrypted using CAST-128 (or IDEA or 3DES) keyed using a user supplied passphrase. Figure 18.4
also shows the general structure of a public-key ring. This data structure is used to store public keys of other users that are known
to this user. The public-key ring can be indexed by either User ID or Key ID.

PGP Message Generation

Stallings Figure 18.5 illustrates how these key rings are used in message transmission to implement the various PGP
crypto services (ignoring compression and radix-64 conversion for simplicity). The sending PGP entity performs the
following steps:
1. Signing the message:
a. PGP retrieves the sender's private key from the private-key ring using your_userid as an index. If your_userid was
not provided in the command, the first private key on the ring is retrieved.
b. PGP prompts the user for the passphrase to recover the unencrypted private key.
c. The signature component of the message is constructed.
2. Encrypting the message:
a. PGP generates a session key and encrypts the message.
b. PGP retrieves the recipient's public key from the public-key ring using her_userid as an index.
c. The session key component of the message is constructed.

51 | P a g e
PGP Message Reception
Stallings Figure 18.6 then illustrates how these key rings are used in message reception to implement the various PGP
crypto services (again ignoring compression and radix-64 conversion for simplicity). The receiving PGP entity
performs the following steps:
1. Decrypting the message:
a. PGP retrieves the receiver's private key from the private-key ring, using the Key ID field in the session key
component of the message as an index.
b. PGP prompts the user for the passphrase to recover the unencrypted private key.
c. PGP then recovers the session key and decrypts the message.
2. Authenticating the message:
a. PGP retrieves the sender's public key from the public-key ring, using the Key ID field in the signature key
component of the message as an index.
b. PGP recovers the transmitted message digest.
c. PGP computes the message digest for the received message and compares it to the transmitted message digest to authenticate.

PGP Key Management

The PGP documentation notes that “This whole business of protecting public keys from tampering is the single most difficult
problem in practical public key applications”. Its solution is to support a variety of formal and informal environments, in which
any user can act as a “CA” to certify another user’s public key, and then act as a “trusted introducer” to other users, thus forming a
“web of trust”. PGP provides a convenient means of using trust, associating trust with public keys, and exploiting trust information.
The key ring is regularly processed to derive trust indicators for keys in it. Associated with each such entry is a key legitimacy
field that indicates the extent to which PGP will trust that this is a valid public key for this user; the higher the level of trust, the
stronger is the binding of this user ID to this key. PGP allows a user to revoke their current public key, either because compromise
is suspected or simply to avoid the use of the same key for an extended period.

52 | P a g e
  rather than relying on certificate authorities
 in PGP every user is own CA
• can sign keys for users they know directly
 forms a “web of trust”
• trust keys have signed
• can trust keys others have signed if have a chain of signatures to them
 key ring includes trust indicators
 users can also revoke their keys
PGP Trust Model Example
Stallings Figure 18.7 provides an example of the way in which signature trust and key legitimacy are related. The
figure shows the structure of a public-key ring. The user has acquired a number of public keys, some directly from
their owners and some from a third party such as a key server. The node labeled "You" refers to the entry in the
public-key ring corresponding to this user. This key is legitimate and the OWNERTRUST value is ultimate trust. Each
other node in the key ring has an OWNERTRUST value of undefined unless some other value is assigned by the user.
In this example, this user has specified that it always trusts the following users to sign other keys: D, E, F, L. This user
partially trusts users A and B to sign other keys. So the shading, or lack thereof, of the nodes in Figure 18.7 indicates
the level of trust assigned by this user. The tree structure indicates which keys have been signed by which other users.
If a key is signed by a user whose key is also in this key ring, the arrow joins the signed key to the signatory. If the
key is signed by a user whose key is not present in this key ring, the arrow joins the signed key to a question mark,
indicating that the signatory is unknown to this user.

S/MIME (Secure/Multipurpose Internet Mail Extensions)

S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to the MIME Internet e-mail
format standard, which in turn provided support for varying content types and multi-part messages over the text only
support in the original Internet RFC822 (now RFC5322) email standard. See text for discussion of these extensions.
MIME is specified in RFCs 2045 through 2049. MIME allows encoding of binary data to textual form for transport
over traditional RFC822 email systems. S/MIME support is now included in many modern mail agents.
 security enhancement to MIME email
 original Internet RFC822 email was text only
 MIME provided support for varying content types and multi-part messages
 with encoding of binary data to textual form
 S/MIME added security enhancements
 have S/MIME support in many mail agents
 eg MS Outlook, Mozilla, Mac Mail etc
S/MIME Functions
In terms of general functionality, S/MIME is very similar to PGP. Both offer the ability to sign and/or encrypt
messages. S/MIME provides the functions shown.
 enveloped dataencrypted content and associated keys
 signed dataencoded message + signed digest
 clear-signed datacleartext message + encoded signed digest
 signed & enveloped datanesting of signed & encrypted entities

53 | P a g e
S/MIME Cryptographic Algorithms
S/MIME uses a range of cryptographic algorithms, as shown. Support for SHA-1, DSS, RSA and Triple-DES is
required, the rest should be provided for backwards compatibility of possible. The S/MIME specification includes a
discussion of the procedure for deciding which content encryption algorithm to use, based on the capabilities of all
parties. To support this decision process, a sending agent may announce its decrypting capabilities in order of
preference any message that it sends out. A receiving agent may store that information for future use. If a message is
to be sent to multiple recipients and a common encryption algorithm cannot be selected for all, then the sending agent
will need to send two messages. However, in that case, it is important to note that the security of the message is made
vulnerable by the transmission of one copy with lower security.
 digital signatures: DSS & RSA
 hash functions: SHA-1 & MD5
 session key encryption: ElGamal & RSA
 message encryption: AES, Triple-DES, RC2/40 and others
 MAC: HMAC with SHA-1
 have process to decide which algs to use
S/MIME Messages
S/MIME secures a MIME entity with a signature, encryption, or both. A MIME entity may be an entire message or one or more of
the subparts of the message. The MIME entity plus some security related data, such as algorithm identifiers and certificates, are
processed by S/MIME to produce a PKCS, which refers to a set of public-key cryptography specifications issued by RSA
Laboratories. A PKCS object is then treated as message content and wrapped in MIME. A range of S/MIME content-types are
specified, as shown. See text for details of how these are used.
 S/MIME secures a MIME entity with a signature, encryption, or both
 forming a MIME wrapped PKCS object
 have a range of content-types:
 enveloped data
 signed data
 clear-signed data
 registration request
 certificate only message
S/MIME Certificate Processing
S/MIME uses public-key certificates that conform to version 3 of X.509 (see Chapter 14). The key-management
scheme used by S/MIME is in some ways a hybrid between a strict X.509 certification hierarchy and PGP’s web of
trust. S/MIME managers and/or users must configure each client with a list of trusted keys and with certificate
revocation lists, needed to verify incoming signatures and to encrypt outgoing messages. But certificates are signed
by trusted certification authorities.
 S/MIME uses X.509 v3 certificates
 managed using a hybrid of a strict X.509 CA hierarchy & PGP’s web of trust
 each client has a list of trusted CA’s certs
 and own public/private key pairs & certs
 certificates must be signed by trusted CA’s
Certificate Authorities
There are several companies that provide X.509 certification authority (CA) services. Of these, the most widely used
is the VeriSign CA service. VeriSign issues X.509 certificates known as Digital IDs. As of early 1998, over 35,000
commercial Web sites were using VeriSign Server Digital IDs, and over a million consumer Digital IDs had been
issued to users of Netscape and Microsoft browsers. VeriSign provides three levels, or classes, of security for public-
key certificates, with increasing levels of checks & hence trust, as shown above, and with additional details in Stallings
Table 18.8. Class 1 and Class 2 requests are processed on line, and in most cases take only a few seconds to approve.
For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance. An individual must prove his or her
identity by providing notarized credentials or applying in person.
 have several well-known CA’s
 Verisign one of most widely used
 Verisign issues several types of Digital IDs
 increasing levels of checks & hence trust

54 | P a g e
 Class Identity Checks Usage
1 name/email check web browsing/email
2 + enroll/addr check email, subs, s/w validate
3 + ID documents e-banking/service access
S/MIME Enhanced Security Services
As of this writing, three enhanced security services have been proposed in an Internet draft, and may change or be
extended. The three services are:
• Signed receipts: may be requested in a SignedData object to provide proof of delivery to the originator of a message
and allows the originator to demonstrate to a third party that the recipient received the message.
• Security labels: may be included in the authenticated attributes of a SignedData object, and is a set of security
information regarding the sensitivity of the content that is protected by S/MIME encapsulation. They may be used for
access control, indicating which users are permitted access to an object
• Secure mailing lists: When a user sends a message to multiple recipients, a certain amount of per-recipient
processing is required, including the use of each recipient's public key. The user can be relieved of this work by
employing the services of an S/MIME Mail List Agent (MLA). An MLA can take a single incoming message, perform
recipient-specific encryption for each recipient, and forward the message. The originator of a message need only send
the message to the MLA, with encryption performed using the MLA's public key.
3 proposed enhanced security services:
 signed receipts
 security labels
 secure mailing lists
Domain Keys Identified Mail
Domain Keys Identified Mail (DKIM) is a specification for cryptographically signing email messages, permitting a
signing domain to claim responsibility for a message in the mail stream. Message recipients (or agents acting in their
behalf) can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and
thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.
DKIM is a proposed Internet Standard (RFC 4871: DomainKeys Identified Mail (DKIM) Signatures). DKIM has been
widely adopted by a range of email providers, including corporations, government agencies, gmail, yahoo, and many
Internet Service Providers (ISPs).
 a specification for cryptographically signing email messages
 so signing domain claims responsibility
 recipients / agents can verify signature
 proposed Internet Standard RFC 4871
 has been widely adopted
Internet Mail Architecture
To understand to operation of DKIM, it is useful to have a basic grasp of the Internet mail architecture, as illustrated
in Stallings Figure 18.9. At its most fundamental level, the Internet mail architecture consists of a user world in the
form of Message User Agents (MUA), and the transfer world, in the form of the Message Handling Service (MHS),
which is composed of Message Transfer Agents (MTA). A MUA is usually housed in the user's computer, and referred
to as a client email program, or on a local network email server. The MHS accepts a message from one User and
delivers it to one or more other users, creating a virtual MUA-to-MUA exchange environment. The MSA accepts the
message submitted by an MUA and enforces the policies of the hosting domain and the requirements of Internet
standards. This function may be co-located with the MUA or be a separate functional model. In the latter case, the
Simple Mail Transfer Protocol (SMTP) is used between the MUA and the MSA. The MTA relays mail for one
application-level hop. Relaying is performed by a sequence of MTAs, until the message reaches a destination MDA.
The MDA is responsible for transferring the message from the MHS to the MS. An MS can be located on a remote
server or on the same machine as the MUA. Typically, an MUA retrieves messages from a remote server using POP
(Post Office Protocol) or IMAP (Internet Message Access Protocol). Also an administrative management domain
(ADMD) is an Internet email provider. The Domain Name System (DNS) is a directory lookup service that provides
a mapping between the name of a host on the Internet and its numerical address.

55 | P a g e
Email Threats
RFC 4684 (Analysis of Threats Motivating DomainKeys Identified Mail) describes the problem space being addressed
by DKIM in terms of the characteristics, capabilities, and location of potential attackers. It characterizes the range of
attackers on a spectrum of three levels of threat: low end attackers who simply want to send email that a recipient does
not want to receive, often with falsified sender addresses. At the next level are professional senders of bulk spam mail.
The most sophisticated and financially motivated senders of messages are those who stand to receive substantial
financial benefit, such as from an email-based fraud scheme. The RFC then lists a range of capabilities that an attacker
might have in terms of where submitted, signed, volume, routing naming etc (see text). DKIM focuses primarily on
attackers located outside of the administrative units of the claimed originator and the recipient.
 see RFC 4684- Analysis of Threats Motivating DomainKeys Identified Mail
 describes the problem space in terms of:
 range: low end, spammers, fraudsters
 capabilities in terms of where submitted, signed, volume, routing naming etc
 outside located attackers
DKIM Strategy
DKIM is designed to provide an email authentication technique transparent to the end user. In essence, a user's email message is
signed by a private key of the administrative domain from which the email originates. The signature covers all of the content of the
message and some of the RFC 5322 message headers. At the receiving end, the MDA can access the corresponding public key via
a DNS and verify the signature, thus authenticating that the message comes from the claimed administrative domain. Thus, mail
that originates from somewhere else but claims to come from a given domain will not pass the authentication test and can be
rejected. This approach differs from that of S/MIME and PGP, which use the originator's private key to sign the content of the
message, for various pragmatic reasons (see text). Stallings Figure 18.10 shows a simple example of the operation of DKIM. An
email message is generated by an email client program. The content of the message, plus selected RFC 5322 headers, is signed by
the email provider using the provider's private key. The signer is associated with a domain, which could be a corporate local
network, an ISP, or a public email facility such as gmail. The signed message then passes through the Internet via a sequence of
MTAs. At the destination, the MDA retrieves the public key for the incoming signature and verifies the signature before passing
the message on to the destination email client. The default signing algorithm is RSA with SHA-256. RSA with SHA-1 may also be
used.

 transparent to user
 MSA sign
 MDA verify
 for pragmatic reasons

56 | P a g e
DKIM Functional Flow
Stallings Figure 18.11 provides a more detailed look at the elements of DKIM operation. Basic message processing is
divided between a signing Administrative Management Domain (ADMD) and a verifying ADMD. Signing is
performed by an authorized module within the signing ADMD and uses private information from a Key Store.
Verifying is performed by an authorized module within the verifying ADMD. The module verifies the signature or
determines whether a particular signature was required. Verifying the signature uses public information from the Key
Store. If the signature passes, reputation information is used to assess the signer and that information is passed to the
message filtering system. If the signature fails or there is no signature using the author's domain, information about
signing practices related to the author can be retrieved remotely and/or locally, and that information is passed to the
message filtering system. The signature is inserted into the RFC 5322 message as an additional header entry, starting
with the keyword Dkim-Signature. Before a message is signed, a process known as canonicalization is performed on
both the header and body of the RFC 5322 message. Canonicalization is necessary to deal with the possibility of minor
changes in the message made en route. The signature includes a number of fields, as listed in the text.

Summary

 have considered:
 secure email
 PGP
 S/MIME
 domain-keys identified email

IP Security
If a secret piece of news is divulged by a spy before the time is ripe, he must be put to death, together with the man to
whom the secret was told. —The Art of War, Sun Tzu
The Internet community has developed application-specific security mechanisms in a number of application areas,
including electronic mail (S/MIME, PGP), client/server (Kerberos), Web access (Secure Sockets Layer), and others.
However, users have some security concerns that cut across protocol layers. By implementing security at the IP level,
an organization can ensure secure networking not only for applications that have security mechanisms but also for the
many security-ignorant applications.
 have a range of application specific security mechanisms
 eg. S/MIME, PGP, Kerberos, SSL/HTTPS
 however, there are security concerns that cut across protocol layers
 would like security implemented by the network for all applications
IP-level security encompasses three functional areas: authentication, confidentiality, and key management. The
authentication mechanism assures that a received packet was transmitted by the party identified as the source in the
packet header, and that the packet has not been altered in transit. The confidentiality facility enables communicating
nodes to encrypt messages to prevent eavesdropping by third parties. The key management facility is concerned with
the secure exchange of keys. IPSec provides the capability to secure communications across a LAN, across private
and public WANs, and across the Internet. In 1994, the Internet Architecture Board (IAB) issued a report titled
"Security in the Internet Architecture" (RFC 1636). The report stated the general consensus that the Internet needs
more and better security and identified key areas for security mechanisms. To provide security, the IAB included
authentication and encryption as necessary security features in the next-generation IP, which has been issued as IPv6.
Fortunately, these security capabilities were designed to be usable both with the current IPv4 and the future IPv6.

57 | P a g e
  general IP Security mechanisms
 provides
 authentication
 confidentiality
 key management
 applicable to use over LANs, across public & private WANs, & for the Internet
 need identified in 1994 report
 need authentication, encryption in IPv4 & IPv6
IP Security Uses
Stallings Figure 19.1 illustrates a typical IP Security scenario. An organization maintains LANs at dispersed locations.
Nonsecure IP traffic is conducted on each LAN. For traffic offsite, through some sort of private or public WAN, IPSec
protocols are used. These protocols operate in networking devices, such as a router or firewall, that connect each LAN
to the outside world. The IPSec networking device will typically encrypt and compress all traffic going into the WAN,
and decrypt and decompress traffic coming from the WAN; these operations are transparent to workstations and
servers on the LAN. Secure transmission is also possible with individual users who dial into the WAN. Such user
workstations must implement the IPSec protocols to provide security.

Benefits of IPSec
Some of the benefits of IPSec include:
• When implemented in a firewall or router, it provides strong security that can be applied to all traffic crossing the
perimeter. Traffic within a company or workgroup does not incur the overhead of security-related processing.
• in a firewall is resistant to bypass if all traffic from the outside must use IP and the firewall is the only means of
entrance from the Internet into the organization.
• is below the transport layer (TCP, UDP) and so is transparent to applications. There is no need to change software
on a user or server system when IPsec is implemented in the firewall or router. Even if IPsec is implemented in end
systems, upper-layer software, including applications, is not affected.
• can be transparent to end users. There is no need to train users on security mechanisms, issue keying material on a
per-user basis, or revoke keying material when users leave the organization.
• can provide security for individual users if needed. This is useful for offsite workers and for setting up a secure
virtual subnetwork within an organization for sensitive applications.
It also plays a vital role in the routing architecture required for internetworking.
 in a firewall/router provides strong security to all traffic crossing the perimeter
 in a firewall/router is resistant to bypass
 is below transport layer, hence transparent to applications
 can be transparent to end users
 can provide security for individual users
 secures routing architecture

58 | P a g e
IP Security Architecture
The IPSec specification has become quite complex. key management. The totality of the IPsec specification is
scattered across dozens of RFCs and draft IETF documents, making this the most complex and difficult to grasp of all
IETF specifications. The best way to keep track of and get a handle on this body of work is to consult the latest version
of the IPsec document roadmap. The documents can be categorized into the following groups:
• Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPsec
technology, see RFC 4301, Security Architecture for the Internet Protocol.
• Authentication Header (AH): AH is an extension header for message authentication, now deprecated. See RFC 4302,
IP Authentication Header.
• Encapsulating Security Payload (ESP): ESP consists of an encapsulating header and trailer used to provide
encryption or combined encryption/authentication. See RFC 4303, IP Encapsulating Security Payload (ESP).
• Internet Key Exchange (IKE): a collection of documents describing the key management schemes for use with IPsec.
See RFC4306, Internet Key Exchange (IKEv2) Protocol, and other related RFCs.
• Cryptographic algorithms: a large set of documents that define and describe cryptographic algorithms for encryption,
message authentication, pseudorandom functions (PRFs), and cryptographic key exchange.
• Other: There are a variety of other IPsec-related RFCs, including those dealing with security policy and management
information base (MIB) content.
 specification is quite complex, with groups:
 Architecture
 RFC4301 Security Architecture for Internet Protocol
 Authentication Header (AH)
 RFC4302 IP Authentication Header
 Encapsulating Security Payload (ESP)
 RFC4303 IP Encapsulating Security Payload (ESP)
 Internet Key Exchange (IKE)
 RFC4306 Internet Key Exchange (IKEv2) Protocol
 Cryptographic algorithms
 Other
IPSec Services
IPSec provides security services at the IP layer by enabling a system to select required security protocols, determine
the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested
services. Two protocols are used to provide security: an authentication protocol designated by the header of the
protocol, Authentication Header (AH); and a combined encryption/authentication protocol designated by the format
of the packet for that protocol, Encapsulating Security Payload (ESP). RFC 4301 lists the security services supported
as shown above.
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets
 a form of partial sequence integrity
 Confidentiality (encryption)
 Limited traffic flow confidentiality
Transport and Tunnel Modes
Both AH and ESP support two modes of use: transport and tunnel mode, but will focus on ESP.
Transport mode provides protection primarily for upper-layer protocols. Transport mode ESP is used to encrypt and
optionally authenticate the data carried by IP. Typically, transport mode is used for end-to-end communication
between two hosts (e.g., a client and a server, or two workstations). When a host runs AH or ESP over IPv4, the
payload is the data that normally follow the IP header. For IPv6, the payload is the data that normally follow both the
IP header and any IPv6 extensions headers that are present. Transport mode operation provides confidentiality for any
application that uses it, thus avoiding the need to implement confidentiality in every individual application.
Tunnel mode ESP is used to encrypt an entire IP packet. To achieve this, after the AH or ESP fields are added to the
IP packet, the entire packet plus security fields is treated as the payload of new "outer" IP packet with a new outer IP

59 | P a g e
header. The entire original, or inner, packet travels through a "tunnel" from one point of an IP network to another; no
routers along the way are able to examine the inner IP header. Tunnel mode is useful in a configuration that includes
a firewall or other sort of security gateway that protects a trusted network from external networks. In this latter case,
encryption occurs only between an external host and the security gateway or between two security gateways. With
tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without
implementing IPsec.
 Transport Mode
 to encrypt & optionally authenticate IP data
 can do traffic analysis but is efficient
 good for ESP host to host traffic
 Tunnel Mode
 encrypts entire IP packet
 add new header for next hop
 no routers on way can examine inner IP header
 good for VPNs, gateway to gateway security
Stallings Figure 19.7 shows two ways in which the IPsec ESP service can be used. In the upper part of the figure, encryption (and
optionally authentication) is provided directly between two hosts. Figure 19.7b shows how tunnel mode operation can be used to
set up a virtual private network. In this example, an organization has four private networks interconnected across the Internet.
Hosts on the internal networks use the Internet for transport of data but do not interact with other Internet- based hosts. By
terminating the tunnels at the security gateway to each internal network, the configuration allows the hosts to avoid implementing
the security capability. The former technique is support by a transport mode SA, while the latter technique uses a tunnel mode SA.

Transport and Tunnel Mode Protocols

Stallings Figure 19.9 shows the protocol architecture for the two modes when ESP is used.

60 | P a g e
Security Associations
Fundamental to the operation of IPsec is the concept of a security policy applied to each IP packet that transits from a
source to a destination. IPsec policy is determined primarily by the interaction of two databases, the security
association database (SAD) and the security policy database (SPD).
A key concept that appears in both the authentication and confidentiality mechanisms for IP is the security association
(SA). An association is a one-way relationship between a sender and a receiver that affords security services to the
traffic carried on it. If a peer relationship is needed, for two-way secure exchange, then two security associations are
required. Security services are afforded to an SA for the use of AH or ESP, but not both. A security association is
uniquely identified by three parameters:
• Security Parameters Index (SPI): A bit string assigned to this SA and having local significance only
• IP Destination Address: the address of the destination endpoint of the SA
• Security Protocol Identifier: indicates whether the association is an AH or ESP security association.
A SA may also have a number of other parameters. In each IPSec implementation, there is a Security Association
Database that defines the parameters associated with each SA. See text for details of these.
 a one-way relationship between sender & receiver that affords security for traffic flow
 defined by 3 parameters:
 Security Parameters Index (SPI)
 IP Destination Address
 Security Protocol Identifier
 has a number of other parameters
 seq no, AH & ESP info, lifetime etc
 have a database of Security Associations
Security Policy Database
The means by which IP traffic is related to specific SAs (or no SA in the case of traffic allowed to bypass IPsec) is
the nominal Security Policy Database. In its simplest form, an SPD contains entries, each of which defines a subset of
IP traffic and points to an SA for that traffic. In more complex environments, there may be multiple entries that
potentially relate to a single SA or multiple SAs associated with a single SPD entry. Each SPD entry is defined by a
set of IP and upper-layer protocol field values, called selectors. These include local & remote IP addresses, next layer
protocol, name, local & remote ports. In effect, these selectors are used to filter outgoing traffic in order to map it into
a particular SA. Stallings Table 19.2 provides an example of an SPD on a host system (as opposed to a network system
such as a firewall or router). This table reflects the following configuration: A local network configuration consists of
two networks. The basic corporate has the IP network number 1.2.3.0/24. The local configuration also includes a
secure LAN, often known as a DMZ, that is identified as 1.2.4.0/24. The DMZ is protected from both the outside
world and the rest of the corporate LAN by firewalls. The host in this example has the IP address 1.2.3.10, and it is
authorized to connect to the server 1.2.4.10 in the DMZ. The entries in the SPD should be self-explanatory. For
example, UDP port 500 is the designated port for IKE. Any traffic from the local host to a remote host for purposes
of an IKE exchange bypasses the IPsec processing.
 relates IP traffic to specific SAs
 match subset of IP traffic to relevant SA
 use selectors to filter outgoing traffic to map
 based on: local & remote IP addresses, next layer protocol, name, local & remote ports

61 | P a g e
Encapsulating Security Payload (ESP)
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service
(a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends
on options selected at the time of Security Association (SA) establishment and on the location of the implementation
in a network topology. ESP can work with a variety of encryption and authentication algorithms, including
authenticated encryption algorithms such as GCM.
 provides message content confidentiality, data origin authentication, connectionless integrity, an anti-replay
service, limited traffic flow confidentiality
 services depend on options selected when establish Security Association (SA), net location
 can use a variety of encryption & authentication algorithms
Encapsulating Security Payload
Stallings Figure 19.5b shows the format of an ESP packet, with fields:
• Security Parameters Index (32 bits): Identifies a security association
• Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is
protected by encryption
• Padding (0–255 bytes): for various reasons
• Pad Length (8 bits): the number of pad bytes immediately preceding this field
• Next Header (8 bits): identifies the type of data in the payload data field
• Integrity check value (variable): a variable-length field that contains the Integrity Check Value computed over the
ESP packet. When any combined mode algorithm is employed, it is expected to return both the decrypted plaintext
and a pass/fail indication for the integrity check. Two additional fields may be present in the payload. An initialization
value (IV), or nonce, is present if this is required by the encryption or authenticated encryption algorithm used for
ESP. If tunnel mode is being used, then the IPsec implementation may add traffic flow confidentiality (TFC) padding
after the Payload Data and before the Padding field, as explained subsequently.

Encryption & Authentication Algorithms & Padding

The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service. If the algorithm used to encrypt
the payload requires cryptographic synchronization data, such as an initialization vector (IV), then these data may be carried
explicitly at the beginning of the Payload Data field. If included, an IV is usually not encrypted, although it is often referred to as
being part of the ciphertext. The ICV field is optional. It is present only if the integrity service is selected and is provided by either
a separate integrity algorithm or a combined mode algorithm that uses an ICV. The ICV is computed after the encryption is
performed. The Padding field serves several purposes: If an encryption algorithm requires the plaintext to be a multiple of some
number of bytes, the Padding field is used to expand the plaintext to the required length; to assure that the Pad Length and Next
Header fields are right aligned within a 32-bit word; to provide partial traffic flow confidentiality by concealing the actual length
of the payload.
 ESP can encrypt payload data, padding, pad length, and next header fields
 if needed have IV at start of payload data
 ESP can have optional ICV for integrity
 is computed after encryption is performed
 ESP uses padding
 to expand plaintext to required length
 to align pad length and next header fields
 to provide partial traffic flow confidentiality

62 | P a g e
Anti-Replay Service
A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to the intended destination.
The receipt of duplicate, authenticated IP packets may disrupt service in some way or may have some other undesired consequence.
The Sequence Number field is designed to thwart such attacks. When a new SA is established, the sender initializes a sequence
number counter to 0. Each time that a packet is sent on this SA, the sender increments the counter and places the value in the
Sequence Number field. Thus, the first value to be used is 1. If anti-replay is enabled (the default), the sender must not allow the
sequence number to cycle past 232 – 1 back to zero. If this limit is reached, the sender should terminate this SA and negotiate a new
SA with a new key. Because IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered
in order and does not guarantee that all packets will be delivered. Therefore, the IPsec authentication document dictates that the
receiver should implement a window of size W, with a default of W = 64. The right edge of the window represents the highest
sequence number, N, so far received for a valid packet. For any packet with a sequence number in the range from N – W + 1 to N
that has been correctly received (i.e., properly authenticated), the corresponding slot in the window is marked.
 replay is when attacker resends a copy of an authenticated packet
 use sequence number to thwart this attack
 sender initializes sequence number to 0 when a new SA is established
 increment for each packet
 must not exceed limit of 232 – 1
 receiver then accepts packets with seq no within window of (N –W+1)
Combining Security Associations
An individual SA can implement either the AH or ESP protocol but not both. Sometimes a particular traffic flow will call for the
services provided by both AH and ESP. Further, a particular traffic flow may require IPSec services between hosts and ,for that
same flow, separate services between security gateways, such as firewalls. In all of these cases, multiple SAs must be employed
for the same traffic flow to achieve the desired IPSec services. The term security association bundle refers to a sequence of SAs
through which traffic must be processed to provide a desired set of IPSec services. The SAs in a bundle may terminate at different
endpoints or at the same endpoints. Security associations may be combined into bundles in two ways:
• Transport adjacency: more than one security protocol on same IP packet, without invoking tunneling
• Iterated tunneling: application of multiple layers of security protocols effected through IP tunneling
Encryption and authentication can be combined in order to transmit an IP packet that has both confidentiality and authentication
between hosts. We look at several approaches, including: ESP with authentication option, use two bundled transport SAs, with the
inner being an ESP SA and the outer being an AH SA; use a bundle consisting of an inner AH transport SA and an outer ESP tunnel
SA. See text for more details.
 SA’s can implement either AH or ESP
 to implement both need to combine SA’s
 form a security association bundle
 may terminate at different or same endpoints
 combined by
• transport adjacency
• iterated tunneling
 combining authentication & encryption
 ESP with authentication, bundled inner ESP & outer AH, bundled inner transport & outer ESP
Combining Security Associations
The IPSec Architecture document lists four examples of combinations of SAs that must be supported by compliant IPSec hosts or
security gateways. These are illustrated in Stallings Figure 19.10. The lower part of each case in the figure represents the physical
connectivity of the elements; the upper part represents logical connectivity via one or more nested SAs. Each SA can be either AH
or ESP. For host-to-host SAs, the mode may be either transport or tunnel; otherwise it must be tunnel mode. Note the *’d devices
implement IPSec. The cases are:
Case 1 security is provided between end systems that implement IPSec, who share suitable keys, using AH tunnel, ESP transport,
ESP + AH transport, any of above inside AH/ESP tunnel; to support authentication, encryption, authentication before encryption,
and authentication after encryption.
Case 2 security is provided only between gateways (routers, firewalls,etc.) and no hosts implement IPSec, a simple VPN using a
single AH or ESP tunnel SA
Case 3 builds on Case 2 by adding end-to-end security. The same combinations discussed for cases 1 and 2 are allowed here.
Case 4 provides support for a remote host that uses the Internet to reach an organization’s firewall and then to gain access to some
server or workstation behind the firewall. Only tunnel mode is required between the remote host and the firewall. As in Case 1, one
or two SAs may be used between the remote host and the local host.

63 | P a g e
IPSec Key Management
The key management portion of IPSec involves the determination and distribution of secret keys. A typical
requirement is four keys for communication between two applications: transmit and receive pairs for both AH and
ESP. The IPSec Architecture document mandates support for two types of key management:
• Manual where a system administrator manually configures each system with its own keys and with the keys of other
communicating
• Automated where an automated system enables the on-demand creation of keys for SAs and facilitates the use of
keys in a large distributed system with an evolving configuration
The default automated key management protocol for IPSec is referred to as ISAKMP/Oakley.
 handles key generation & distribution
 typically need 2 pairs of keys
 2 per direction for AH & ESP
 manual key management
 sysadmin manually configures every system
 automated key management
 automated system for on demand creation of keys for SA’s in large systems
 has Oakley & ISAKMP elements
Oakley
Oakley is a key exchange protocol based on the Diffie-Hellman algorithm but providing added security. Oakley is generic in that
it does not dictate specific formats. Oakley is designed to retain the advantages of Diffie-Hellman while countering its weaknesses.
These include that it does not provide any information about the identities of the parties, is subject to a man-in-the-middle attack,
and is computationally intensive. The Oakley algorithm is characterized by five important features:
1. It employs a mechanism known as cookies to thwart clogging attacks
2. It enables the two parties to negotiate a group; this, in essence, specifies the global parameters of the Diffie-Hellman key
exchange
3. It uses nonces to ensure against replay attacks
4. It enables the exchange of Diffie-Hellman public key values
5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks
Oakley supports the use of different groups for the Diffie-Hellman key exchange, being 768, 1024 or 1536 bit primes,
or 155 or 185 bit elliptic curves. See text for more details.
 a key exchange protocol
 based on Diffie-Hellman key exchange
 adds features to address weaknesses
 no info on parties, man-in-middle attack, cost
 so adds cookies, groups (global params), nonces, DH key exchange with
authentication
 can use arithmetic in prime fields or elliptic curve fields

64 | P a g e
ISAKMP
The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for Internet key
management and provides the specific protocol support, defining procedures and packet formats to establish,
negotiate, modify, and delete security associations. ISAKMP by itself does not dictate a specific key exchange
algorithm; rather, ISAKMP consists of a set of message types that enable the use of a variety of key exchange
algorithms. Oakley is the specific key exchange algorithm mandated for use with the initial version of ISAKMP. In
IKEv2, the terms Oakley and ISAKMP are no longer used, and there are significant differences from the use of Oakley
and ISAKMP in IKEv1. Nevertheless, the basic functionality is the same.
 Internet Security Association and Key Management Protocol
 provides framework for key management
 defines procedures and packet formats to establish, negotiate, modify, & delete SAs
 independent of key exchange protocol, encryption alg, & authentication method
 IKEv2 no longer uses Oakley & ISAKMP terms, but basic functionality is same
IKEV2 Exchanges
The IKEv2 protocol involves the exchange of messages in pairs. The first two pairs of exchanges are referred to as the initial
exchanges (see Stallings Figure 19.11a). In the first exchange the two peers exchange information concerning cryptographic
algorithms and other security parameters they are willing to use along with nonces and Diffie-Hellman (DH) values. The result of
this exchange is to set up a special SA called the IKE SA (Figure 19.2). This SA defines parameters for a secure channel between
the peers over which subsequent message exchanges take place. Thus, all subsequent IKE message exchanges are protected by
encryption and message authentication. In the second exchange, the two parties authenticate one another and set up a first IPsec
SA to be placed in the SADB and used for protecting ordinary (i.e. non-IKE) communications between the peers. Thus four
messages are needed to establish the first SA for general use. The CREATE_CHILD_SA exchange can be used to establish
further SAs for protecting traffic. The informational exchange is used to exchange management information, IKEv2 error messages,
and other notifications.

ISAKMP
An ISAKMP message consists of an ISAKMP header followed by one or more payloads, carried in a transport protocol (UDP by
default).
Stallings Figure19.12a shows the header format for an ISAKMP message, which includes the fields:
• Initiator SPI (64 bits): chosen by the initiator to identify a unique SA
• Responder Cookie (64 bits): chosen by responder to identify unique IKE SA
• Next Payload (8 bits): type of the first payload in the message.
• Major/Minor Version (4 bits): Indicates major/minor version of IKE in use
• Exchange Type (8 bits): type of exchange.
• Flags (8 bits): specific options set for this IKE exchange.
• Message ID (32 bits): control retransmission, matching of requests /responses.
• Length (32 bits): of total message (header plus all payloads) in octets.
All ISAKMP payloads begin with the same generic payload header shown in Figure 12.12b. The Next Payload field has a value of
0 if this is the last payload in the message; otherwise its value is the type of the next payload. The Payload Length field indicates
the length in octets of this payload, including the generic payload header. The critical bit is zero if the sender wants the recipient to
skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. It is set to one
if the sender wants the recipient to reject this entire message if it does not understand the payload type.

65 | P a g e
IKE Payloads & Exchanges
Stallings Table19.3 summarizes the payload types defined for ISAKMP, and lists the fields, or parameters, that are part of each
payload. The SA payload is used to begin the establishment of an SA. The payload has a complex, hierarchical structure. The
payload may contain multiple proposals. Each proposal may contain multiple protocols. Each protocol may contain multiple
transforms. And each transform may contain multiple attributes. These elements are formatted as substructures within the payload
with proposal, transform and attribute. See text for more details.
 have a number of ISAKMP payload types:
 Security Association, Key Exchange, Identification, Certificate, Certificate Request, Authentication, Nonce, Notify, Delete,
Vendor ID, Traffic Selector, Encrypted, Configuration, Extensible Authentication Protocol
 payload has complex hierarchical structure
 may contain multiple proposals, with multiple protocols & multiple transforms
Cryptographic Suites
The IPsecv3 and IKEv3 protocols rely on a variety of types of cryptographic algorithms. To promote interoperability, two RFCs
define recommended suites of cryptographic algorithms and parameters for various applications. RFC 4308 defines two
cryptographic suites for establishing virtual private networks. Suite VPN-A matches the commonly used corporate VPN security
used in older IKEv1 implementations. Suite VPN-B provides stronger security and is recommended for new VPNs that implement
IPsecv3 and IKEv2. Stallings Table 19.4a lists the algorithms and parameters for the two suites. For symmetric cryptography, VPN-
A relies on 3DES and HMAC, while VPN-B relies exclusively on AES. RFC 4869 defines four optional cryptographic suites
compatible with the US National Security Agency's Suite B specifications. The four suites defined in RFC 4869 provide choices
for ESP and IKE. They are differentiated by the choice of cryptographic algorithm strengths and a choice of whether ESP is to
provide both confidentiality and integrity or integrity only. All of the suites offer greater protection than the two VPN suites defined
in RFC 4308. Stallings Table 19.4b lists the algorithms and parameters for these suites. For ESP, authenticated encryption is
provided using the GCM mode with either 128-bit or 256-bit AES keys. For IKE encryption, CBC is used, as it was for the VPN
suites. For ESP, if only authentication is required, then GMAC is used. For IKE, message authentication is provided using HMAC
with one of the SHA-3 hash functions. As with the VPN suites, IKEv2 in these suites generates pseudorandom bits by repeated use
of the MAC used for message authentication. For the Diffie-Hellman algorithm, the use of elliptic curve groups modulo a prime is
specified. Finally, for authentication, elliptic curve digital signatures are listed.
 variety of cryptographic algorithm types
 to promote interoperability have
 RFC4308 defines VPN cryptographic suites
• VPN-A matches common corporate VPN security using 3DES & HMAC
• VPN-B has stronger security for new VPNs implementing IPsecv3 and IKEv2 using AES
 RFC4869 defines four cryptographic suites compatible with US NSA specs
• provide choices for ESP & IKE
• AES-GCM, AES-CBC, HMAC-SHA, ECP, ECDSA
Summary
 have considered:
 IPSec security framework
 IPSec security policy
 ESP
 combining security associations
 internet key exchange
 cryptographic suites used

66 | P a g e
Chapter-6 Web Application Security
What is web security?
Browser security
 e.g. Same Origin Policy – Isolate sites from each other, while running in the same browser
Server app security
 Attackers can run arbitrary HTTP clients; can send anything to server
Client app security
 Prevent user from being attacked while using web app locally
Protect the user
 From social engineering
 From trackers, private data being leaked
Why is web security hard?
Extremely ambitious goal – Run untrusted code securely
Different sites interacting in the same tab ("mashups")
Low-level features; hardware access
Desire for high performance
APIs were not designed from first principles; evolved
Strict backwards compatibility requirements
 "Don't break the web"
The browser has a seemingly impossible task
Sites – even malicious ones – can:
 Download content from anywhere
 Spawn worker processes
 Open sockets to a server, or even to another user's browser
 Display media in a huge number of formats
 Run custom code on the GPU
 Save/read data from the filesystem
1. Injection
 Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an
interpreter as part of a command or query.
 The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data
without proper authorization.
2. Broken Authentication
 Application functions related to authentication and session management are often implemented
incorrectly,
 allowing attackers to compromise passwords, keys, or session tokens, or
 to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
3. Sensitive Data Exposure
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII.
Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes.
Sensitive data may be compromised without extra protection,
 such as encryption at rest or in transit,
requires special precautions when exchanged with the browser.
4.XML External Entities (XXE)
Many older or poorly configured XML processors evaluate external entity references within XML documents.
External entities can be used to disclose internal files using
 the file URI handler,
 internal file shares,
 internal port scanning,
 remote code execution, and
 denial of service attacks.
5.Broken Access Control

67 | P a g e
 Restrictions on what authenticated users are allowed to do are often not properly enforced.
Attackers can exploit these flaws to access
 unauthorized functionality and/or data,
 access other users’ accounts,
 view sensitive files,
 modify other users’ data,
 change access rights, etc.
6.Security Misconfiguration
the most commonly seen issue.
commonly a result of
 insecure default configurations,
 incomplete or ad hoc configurations,
 open cloud storage,
 misconfigured HTTP headers, and
 verbose error messages containing sensitive information.
all operating systems, frameworks, libraries, and applications be securely configured, but they must be
patched/upgraded in a timely fashion.
7.Cross-Site Scripting (XSS)
occur whenever an application includes
 untrusted data in a new web page without proper validation or escaping,
 updates an existing web page with user-supplied data using a browser API that can create HTML or
JavaScript.
XSS allows attackers to execute scripts in the victim’s browser which can hijack
 user sessions,
 deface web sites, or
 redirect the user to malicious sites.
8.Insecure Deserialization
often leads to remote code execution.
can be used to perform attacks,
 including replay attacks,
 injection attacks, and
 privilege escalation attacks.
9. Using Components with Known Vulnerabilities
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the
application.
a vulnerable component can be exploited
such an attack can facilitate serious data loss or server takeover
Applications and APIs using components with known vulnerabilities may
 undermine application defenses and
 enable various attacks and impacts
10. Insufficient logging and monitoring
coupled with missing or ineffective integration with incident response
 allows attackers to further attack systems,
 maintain persistence,
 pivot to more systems,
 tamper, extract, or destroy data.
studies show time to detect a breach is over 200 days,
typically detected by external parties rather than internal processes or monitoring.
Web Security
The World Wide Web is widely used by businesses, government agencies, and many individuals. But the Internet and
the Web are extremely vulnerable to compromises of various sorts, with a range of threats as shown briefly above,
and in detail in Stallings Table 16.1. These can be described as passive attacks including eavesdropping on network

68 | P a g e
traffic between browser and server and gaining access to information on a Web site that is supposed to be restricted;
and active attacks including impersonating another user, altering messages in transit between client and server, and
altering information on a Web site. The web needs added security mechanisms to address these threats.
Web now widely used by business, government, individuals
but Internet & Web are vulnerable
have a variety of threats
 integrity
 confidentiality
 denial of service
 authentication
need added security mechanisms
Web Traffic Security Approaches
A number of approaches to providing Web security are possible. The various approaches that have been considered are similar in
the services they provide and, to some extent, in the mechanisms that they use, but they differ with respect to their scope of
applicability and their relative location within the TCP/IP protocol stack. Stallings Figure 16.1 illustrates this difference. One way
to provide Web security is to use IP Security (Figure 16.1a). The advantage of using IPSec is that it is transparent to end users and
applications and provides a general-purpose solution. Further, IPSec includes a filtering capability so only selected traffic need
incur the IPSec processing overhead. Another relatively general-purpose solution is to implement security just above TCP (Figure
16.1b). The foremost example of this approach is the Secure Sockets Layer (SSL) and the follow-on Internet standard known as
Transport Layer Security (TLS). At this level, there are two implementation choices. For full generality, SSL (or TLS) could be
provided as part of the underlying protocol suite and therefore be transparent to applications. Alternatively, SSL can be embedded
in specific packages, e.g. both the Netscape and Microsoft Explorer browsers come with SSL, & most Web servers have
implemented it. Application-specific security services are embedded within the particular application. Figure 16.1c shows examples
of this architecture. The advantage of this approach is that the service can be tailored to the specific needs of a given application.

SSL (Secure Socket Layer)

SSL probably most widely used Web security mechanism, and it is implemented at the Transport layer (cf. figure 16.1b on previous
slide). SSL is designed to make use of TCP to provide a reliable end-to-end secure service. Netscape originated SSL. Version 3 of
the protocol was designed with public review and input from industry and was published as an Internet draft document.
Subsequently, when a consensus was reached to submit the protocol for Internet standardization, the TLS working group was
formed within IETF to develop a common standard. This first published version of TLS can be viewed as essentially an SSLv3.1
and is very close to and backward compatible with SSLv3. SSL is not a single protocol but rather two layers of protocol, as shown next.
transport layer security service
originally developed by Netscape
version 3 designed with public input
subsequently became Internet standard known as TLS (Transport Layer Security)
uses TCP to provide a reliable end-to-end service
SSL has two layers of protocols
SSL Architecture
Stallings Figure 16.2 shows the SSL Protocol stack.
The SSL Record Protocol provides basic security services to various higher-layer protocols. In particular, the Hypertext Transfer
Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of SSL. Three higher-
layer protocols are also defined as part of SSL: the Handshake Protocol, Change Cipher Spec Protocol, and Alert Protocol. These
SSL-specific protocols are used in the management of SSL exchanges.

69 | P a g e
SSL Architecture
Two important SSL concepts are the SSL connection and the SSL session:
• Connection: A connection is a network transport that provides a suitable type of service, such connections are transient, peer-to-
peer relationships, associated with one session
• Session: An SSL session is an association between a client and a server, created by the Handshake Protocol. Sessions define a set
of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive
negotiation of new security parameters for each connection. Between any pair of parties (applications such as HTTP on client and
server), there may be multiple secure connections. In theory, there may also be multiple simultaneous sessions between parties, but
this feature is not used in practice. There are a number of states associated with each session. Once a session is established, there
is a current operating state for both read and write (i.e., receive and send). In addition, during the Handshake Protocol, pending
read and write states are created. Upon successful conclusion of the Handshake Protocol, the pending states become the current
states. A session state and a connection state are defined by sets of parameters, see text for details.
 SSL connection
 a transient, peer-to-peer, communications link
 associated with 1 SSL session
 SSL session
 an association between client & server
 created by the Handshake Protocol
 define a set of cryptographic parameters
 may be shared by multiple SSL connections
SSL Record Protocol Services
SSL Record Protocol defines two services for SSL connections:
• Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL
payloads. The message is compressed before being concatenated with the MAC and encrypted, with a range of ciphers
being supported as shown.
• Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message
authentication code (MAC), which is similar to HMAC
confidentiality
 using symmetric encryption with a shared secret key defined by Handshake Protocol
 AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
 message is compressed before encryption
message integrity
 using a MAC with shared secret key
 similar to HMAC but with different padding
SSL Record Protocol Operation
Stallings Figure16.3 shows the overall operation of the SSL Record Protocol. The Record Protocol takes an application
message to be transmitted, fragments the data into manageable blocks, optionally compresses the data, computes and
appends a MAC (using a hash very similar to HMAC), encrypts (using one of the symmetric algorithms listed on the
previous slide), adds a header (with details of the SSL content type, major/minor version, and compressed length),
and transmits the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and
reassembled and then delivered to higher-layer applications. See text for additional details.

70 | P a g e
SSL Change Cipher Spec Protocol
The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is the simplest,
consisting of a single message (shown in Stallings Figure 16.5a), which consists of a single byte with the value 1. The sole purpose
of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this
connection.
one of 3 SSL specific protocols which use the SSL Record protocol
a single message
causes pending state to become current
hence updating the cipher suite in use

SSL Alert Protocol

The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with other applications that use SSL, alert messages
are compressed and encrypted, as specified by the current state. Each message in this protocol consists of two bytes (as shown in
Stallings Figure 16.5b), the first takes the value warning(1) or fatal(2) to convey the severity of the message. The second byte
contains a code that indicates the specific alert. The first group shown are the fatal alerts, the others are warnings.
 conveys SSL-related alerts to peer entity
 severity
 warning or fatal
 specific alert
 fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter
 warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired,
certificate unknown
 compressed & encrypted like all SSL data

SSL Handshake Protocol

The most complex part of SSL is the Handshake Protocol. This protocol allows the server and client to authenticate each other and
to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The
Handshake Protocol is used before any application data is transmitted. The Handshake Protocol consists of a series of messages
exchanged by client and server, which have the format shown in Stallings Figure 16.5c, and which can be viewed in 4 phases:
• Phase 1. Establish Security Capabilities - this phase is used by the client to initiate a logical connection and to establish
the security capabilities that will be associated with it
• Phase 2. Server Authentication and Key Exchange - the server begins this phase by sending its certificate if it needs to be
authenticated.
• Phase 3. Client Authentication and Key Exchange - the client should verify that the server provided a valid certificate if
required and check that the server_hello parameters are acceptable
• Phase 4. Finish - this phase completes the setting up of a secure connection. The client sends a change_cipher_spec
message and copies the pending CipherSpec into the current CipherSpec. At this point the handshake is complete and the
client and server may begin to exchange application layer data.

71 | P a g e
  allows server & client to:
 authenticate each other
 to negotiate encryption & MAC algorithms
 to negotiate cryptographic keys to be used
 comprises a series of messages in phases
 Establish Security Capabilities
 Server Authentication and Key Exchange
 Client Authentication and Key Exchange
 Finish

Stallings Figure16.6 shows the initial exchange needed to establish a logical connection between client and server.
The exchange can be viewed as having the four phases discussed previously. Additional details on the operation of
these phases is given in the text.

Cryptographic Computations
Two further items are of interest: the creation of a shared master secret by means of the key exchange, and the
generation of cryptographic parameters from the master secret. The shared master secret is a one-time 48-byte value
(384 bits) generated for this session by means of secure key exchange. The creation is in two stages. First, a
pre_master_secret is exchanged. Second, the master_secret is calculated by both parties. For pre_master_secret
exchange, there are two possibilities, using either RSA or Diffie-Hellman. Both sides now compute the master_secret
by hashing the relevant information, as detailed in the text. CipherSpecs require a client write MAC secret, a server
write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated
from the master secret in that order. These parameters are generated from the master secret by hashing the master
secret into a sequence of secure bytes of sufficient length for all needed parameters.
 master secret creation
 a one-time 48-byte value
 generated using secure key exchange (RSA / Diffie-Hellman) and then hashing info
 generation of cryptographic parameters
 client write MAC secret, a server write MAC secret, a client write key, a server write key, a
client write IV, and a server write IV
 generated by hashing master secret

72 | P a g e
TLS (Transport Layer Security)
TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL. TLS is defined as a Proposed
Internet Standard in RFC 2246. RFC 2246 is very similar to SSLv3, but with a number of minor differences in the areas shown, as
discussed in the text.
IETF standard RFC 2246 similar to SSLv3
with minor differences
 in record format version number
 uses HMAC for MAC
 a pseudo-random function expands secrets
 based on HMAC using SHA-1 or MD5
 has additional alert codes
 some changes in supported ciphers
 changes in certificate types & negotiations
 changes in crypto computations & padding
HTTPS
HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure communication between a Web browser
and a Web server. The HTTPS capability is built into all modern Web browsers. Its use depends on the Web server supporting
HTTPS communication. The principal difference seen by a user of a web browser is that URL (uniform resource locator) addresses
begin with https:// rather than http://. A normal HTTP connection uses port 80. If HTTPS is specified, port 443 is specified, which
invokes SSL. When HTTPS is used, the following elements of the communication are encrypted: URL of the requested document,
Contents of the document, Contents of browser forms (filled in by browser user), Cookies sent from browser to server and from
server to browser, and Contents of HTTP header. HTTPS is documented in RFC 2818, HTTP Over TLS. There is no fundamental
change in using HTTP over either SSL or TLS, and both implementations are referred to as HTTPS.
 HTTPS (HTTP over SSL)
 combination of HTTP & SSL/TLS to secure communications between browser & server
 documented in RFC2818
 no fundamental change using either SSL or TLS
 use https:// URL rather than http://
 and port 443 rather than 80
 encrypts
 URL, document contents, form data, cookies, HTTP headers
HTTPS Use
For HTTPS, the agent acting as the HTTP client also acts as the TLS client. The client initiates a connection to the server on the
appropriate port and then sends the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The
client may then initiate the first HTTP request. All HTTP data is to be sent as TLS application data. Normal HTTP behavior,
including retained connections is followed. An HTTP client or server can indicate the closing of a connection by including in an
HTTP record: “Connection: close”. This indicates that the connection will be closed after this record is delivered. The closure of
an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve
closing the underlying TCP connection. At the TLS level, the proper way to close a connection is for each side to use the TLS alert
protocol to send a close_notify alert. TLS implementations must initiate an exchange of closure alerts before closing a connection.
A TLS implementation may, after sending a closure alert, close the connection without waiting for the peer to send its closure alert,
generating an "incomplete close". Note that an implementation that does this may choose to reuse the session. This should only be
done when the application knows (typically through detecting HTTP message boundaries) that it has received all the message data
that it cares about. HTTP clients must also be able to cope with a situation in which the underlying TCP connection is terminated
without a prior close_notify alert and without a Connection: close indicator. Such a situation could be due to a programming error
on the server, or a communication error that causes the TCP connection to drop. However, the unannounced TCP closure could be
evidence of some sort of attack. So the HTTPS client should issue some sort of security warning when this occurs.
 connection initiation
 TLS handshake then HTTP request(s)
 connection closure
 have “Connection: close” in HTTP record
 TLS level exchange close_notify alerts
 can then close TCP connection
 must handle TCP close before alert exchange sent or completed

73 | P a g e
Secure Shell (SSH)
Secure Shell (SSH) is a protocol for secure network communications designed to be relatively simple and inexpensive to implement.
The initial version, SSH1 was focused on providing a secure remote logon facility to replace TELNET and other remote logon
schemes that provided no security. SSH also provides a more general client/server capability and can be used for such network
functions as file transfer and email. A new version, SSH2, fixes a number of security flaws in the original scheme. SSH2 is
documented as a proposed standard in IETF RFCs 4250 through 4254. SSH client and server applications are widely available for
most operating systems. It has become the method of choice for remote login and X tunneling and is a rapidly becoming one of the
most pervasive applications for encryption technology outside of embedded systems.
 protocol for secure network communications
 designed to be simple & inexpensive
 SSH1 provided secure remote logon facility
 replace TELNET & other insecure schemes
 also has more general client/server capability
 SSH2 fixes a number of security flaws
 documented in RFCs 4250 through 4254
 SSH clients & servers are widely available
 method of choice for remote login/ X tunnels
SSH Protocol Stack
SSH is organized as three protocols that typically run on top of TCP (Stallings Figure 16.8):
• Transport Layer Protocol: Provides server authentication, data confidentiality, and data integrity with forward secrecy (i.e., if
a key is compromised during one session, the knowledge does not affect the security of earlier sessions). The transport layer may
optionally provide compression.
• User Authentication Protocol: Authenticates the user to the server.
• Connection Protocol: Multiplexes multiple logical communications channels over a single underlying SSH connection.

SSH Transport Layer Protocol

Server authentication occurs at the transport layer, based on the server possessing a public/private key pair. The server host key is
used during key exchange to authenticate the identity of the host. For this to be possible, the client must have a priori knowledge
of the server's public host key. Next, consider events in the SSH Transport Layer Protocol. First, a client establishes a TCP
connection to the server. Once the connection is established, the client and server exchange data, referred to as packets, in the data
field of a TCP segment. Each packet has the format shown in Stallings Figure 16.10 and described in the text. The SSH Transport
Layer packet exchange consists of a sequence of steps. The first step, the identification string exchange, begins with the client
sending a packet with an identification string. Next comes algorithm negotiation. Each side sends an SSH_MSG_KEXINIT
containing lists of supported algorithms, one list for each type of cryptographic algorithm, in the order of preference to the sender.
For each category, the algorithm chosen is the first algorithm on the client's list that is also supported by the server. The next step
is key exchange. The specification allows for alternative methods of key exchange, but at present only two versions of Diffie-
Hellman key exchange are specified. As a result of these steps, the two sides now share a master key K. In addition, the server has
been authenticated to the client. The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS packets. At this
point, both sides may start using the keys generated from K, as discussed subsequently. The final step is service request. The
client sends an SSH_MSG_SERVICE_REQUEST packet to request either the User Authentication or the Connection Protocol.
Subsequent to this, all data is exchanged as the payload of an SSH Transport Layer packet, protected by encryption and MAC.

74 | P a g e
 server authentication occurs at transport layer, based on server/host key pair(s)
 server authentication requires clients to know host keys in advance
packet exchange
 establish TCP connection
 can then exchange data
 identification string exchange, algorithm negotiation, key exchange, end of key exchange, service request
 using specified packet format
SSH User Authentication Protocol
The User Authentication Protocol provides the means by which the client is authenticated to the server. Three types of messages
are always used in the User Authentication Protocol. Authentication requests from the client have type
SSH_MSG_USERAUTH_REQUEST. If the server either (a) rejects the authentication request, or (b) accepts the request but
requires one or more additional authentication methods, the server sends a SSH_MSG_USERAUTH_FAILURE message that
includes a list of methods that may productively continue the dialog. If the server accepts authentication then it sends a single byte
message, SSH_MSG_USERAUTH_SUCCESS.
The server may require one or more of the following authentication methods:
• publickey - client sends a message to the server that contains the client's public key, with the message signed by the
client's private key
• password - client sends a message containing a plaintext password, protected by TLS encryption
• hostbased - authentication is performed on the client's host, rather than the client itself
• authenticates client to server
• three message types:
• SSH_MSG_USERAUTH_REQUEST
• SSH_MSG_USERAUTH_FAILURE
• SSH_MSG_USERAUTH_SUCCESS
• authentication methods used
• public-key, password, host-based
SSH Connection Protocol
The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes that a secure authentication connection
is in use. That secure authentication connection, referred to as a tunnel is used by the Connection Protocol to multiple a number of
logical channels. All types of communication using SSH, such as a terminal session, are supported using separate channels. Either
side may open a channel. For each channel, each side associates a unique channel number, which need not be the same on both
ends. Channels are flow controlled using a window mechanism. No data may be sent to a channel until a message is received to
indicate that window space is available. The life of a channel progresses through three stages: opening a channel, data transfer,
and closing a channel. Four channel types are recognized in the SSH Connection Protocol specification:
• session - remote execution of a program
• x11 - X Window System display traffic
• forwarded-tcpip - remote port forwarding
• direct-tcpip - local port forwarding
 runs on SSH Transport Layer Protocol
 assumes secure authentication connection
 used for multiple logical channels
 SSH communications use separate channels
 either side can open with unique id number
 flow controlled
 have three stages:
• opening a channel, data transfer, closing a channel
 four types:
• session, x11, forwarded-tcpip, direct-tcpip.

75 | P a g e
SSH Connection Protocol Exchange
Stallings Figure 16.11 provides an example of Connection Protocol Exchange.

Port Forwarding
One of the most useful features of SSH is port forwarding / tunneling. Port forwarding provides the ability to convert
any insecure TCP connection into a secure SSH connection. Note that any application that runs on top of TCP has a
port number. Incoming TCP traffic is delivered to the appropriate application on the basis of the port number. To
secure such a connection, SSH is configured so that the SSH Transport Layer Protocol establishes a TCP connection
between the SSH client and server entities, with TCP port numbers a and b, respectively. A secure SSH tunnel is
established over this TCP connection. Traffic from the client at port x is redirected to the local SSH entity and travels
through the tunnel where the remote SSH entity delivers the data to the server application on port y. Traffic in the
other direction is similarly redirected. SSH supports two types of port forwarding: local forwarding and remote
forwarding. Local forwarding allows the client to set up a "hijacker" process. This will intercept selected application
level traffic and redirect it from an unsecured TCP connection to a secure SSH tunnel. This could be used to secure
the traffic from an email client on your desktop that gets email from the mail server via POP, the Post Office Protocol.
With remote forwarding, the user's SSH client acts on the server's behalf. The client receives traffic with a given
destination port number, places the traffic on the correct port and sends it to the destination the user chooses. This
could be used to securely access a server at work from a home computer.
convert insecure TCP connection into a secure SSH connection
 SSH Transport Layer Protocol establishes a TCP connection between SSH client & server
 client traffic redirected to local SSH, travels via tunnel, then remote SSH delivers to server
supports two types of port forwarding
 local forwarding – hijacks selected traffic
 remote forwarding – client acts for server

76 | P a g e
Chapter-7 System Security
Topics:
• Hardening Network Components: router, switch, hub, wireless devices security
• Intrusion detection IPS/IDS, Firewall, VPN
• Operating system security
• Malicious software and countermeasures
• Distributed Denial of service attacks (DDOS)
 Hardening Network Components
Hardening network devices reduces the risk of unauthorized access into a network’s infrastructure
All networking devices, including routers and switches, come equipped with services turned on when they are received
from the manufacturer.
Enable
 SSHv3 or TLS: Both of these protocols are used to securely communicate to remote network devices.
Disable
 Echo Protocol, Chargen Protocol, Discard Protocol, Daytime Protocols, FTP Protocol, Telnet, BootP Service,
HTTP Server, SNMP Protocol, Discovery Protocols, IP Source Routing, IP Unreachable (ICMP), IP Mask
Reply, Zero Touch Provisioning
https://media.defense.gov/2020/Aug/18/2002479461/-1/1/0/HARDENING_NETWORK_DEVICES.PDF
Interface and Switch Port Recommendations
 Enable port security.
 Shut down unused interfaces and switch ports.
 Place unused switch ports in a VLAN that is not routed and closely monitored. Reassign the native VLAN.
 Disable
• Unused interfaces and routing protocols
• IP direct-broadcast
• IP proxy-arp
Secure Access Recommendations
 Use multi-factor authentication using hardware tokens and passwords.
 Use out-of-band management to separate network administration traffic from normal user traffic.
 Implement the manufacturer’s configuration guidance to restrict access to the console port. · Limit the number of
simultaneous management connections.
 Enable the strongest password encryption supported by the equipment.
 Follow “Digital Identity Guidelines – Authentication and Lifecycle Management” (NIST SP 800-63B2).
 Reduce the risk of exposing administrative interfaces to user traffic by applying IP address access control lists.
 Restrict physical access to routers/switches and apply access control lists for remote access.
 Monitor and log all attempts to access network devices.
 Intrusion detection IPS/IDS
A significant security problem for networked systems is hostile, or at least unwanted, trespass being unauthorized login or use of a
system, by local or remote users; or by software such as a virus, worm, or Trojan horse. One of the two most publicized threats to
security is the intruder (hacker/cracker), which Anderson identified three classes of:
 Masquerader: An individual who is not authorized to use the computer (outsider)
 Misfeasor: A legitimate user who accesses unauthorized data, programs, or resources (insider)
 Clandestine user: An individual who seizes supervisory control of the system and uses this control to evade auditing and
access controls or to suppress audit collection (either) Intruder attacks range from the benign (simply exploring net to see
what is there); to the serious (who attempt to read privileged data, perform unauthorized modifications, or disrupt system).
Intruders
• significant issue for networked systems is hostile or unwanted access
• either via network or local
• can identify classes of intruders:
• masquerader
• misfeasor
• clandestine user
• varying levels of competence
The intruder threat has been well publicized, particularly because of the famous “Wily Hacker” incident of 1986–1987, documented
by Cliff Stoll. Intruder attacks range from the benign to the serious. At the benign end of the scale, there are many people who
simply wish to explore internets and see what is out there. At the serious end are individuals who are attempting to read privileged
data, perform unauthorized modifications to data, or disrupt the system. One of the results of the growing awareness of the intruder

77 | P a g e
problem has been the establishment of a number of computer emergency response teams (CERTs). These cooperative ventures
collect information about system vulnerabilities and disseminate it to systems managers. The techniques and behavior patterns of
intruders are constantly shifting, to exploit newly discovered weaknesses and to evade detection and countermeasures. Even so,
intruders typically follow one of a number of recognizable behavior patterns, and these patterns typically differ from those of
ordinary users.
• range
• benign: explore, still costs resources
• serious: access/modify data, disrupt system
• led to the development of CERTs
• intruder techniques & behavior patterns constantly shifting, have common features
[GRAN04] lists the following examples of intrusion:
• Performing a remote root compromise of an e-mail server
• Defacing a Web server
• Guessing and cracking passwords
• Copying a database containing credit card numbers
• Viewing sensitive data, including payroll records and medical information, without authorization
• Running a packet sniffer on a workstation to capture usernames and passwords
• Using a permission error on an anonymous FTP server to distribute pirated software and music files
• Dialing into an unsecured modem and gaining internal network access
• Posing as an executive, calling the help desk, resetting the executive’s e-mail password, and learning the new password
• Using an unattended, logged-in workstation without permission
Examples of Intrusion
 remote root compromise
 web server defacement
 guessing / cracking passwords
 copying viewing sensitive data / databases
 running a packet sniffer
 distributing pirated software
 using an unsecured modem to access net
 impersonating a user to reset password
 using an unattended workstation
Hackers
Traditionally, those who hack into computers do so for the thrill of it or for status. The hacking community is a strong meritocracy
in which status is determined by level of competence. Thus, attackers often look for targets of opportunity, and then share the
information with others. Benign intruders might be tolerable, although they do consume resources and may slow performance for
legitimate users. However, there is no way in advance to know whether an intruder will be benign or malign. Consequently, even
for systems with no particularly sensitive resources, there is a motivation to control this problem. Intrusion detection systems (IDSs)
and intrusion prevention systems (IPSs) are designed to counter this type of hacker threat. In addition to using such systems,
organizations can consider restricting remote logons to specific IP addresses and/or use virtual private network technology. One of
the results of the growing awareness of the intruder problem has been the establishment of a number of computer emergency
response teams (CERTs). These cooperative ventures collect information about system vulnerabilities and disseminate it to systems
managers. Unfortunately, hackers can also gain access to CERT reports. Thus, it is important for system administrators to quickly
insert all software patches to discovered vulnerabilities.
motivated by thrill of access and status
• hacking community a strong meritocracy
• status is determined by level of competence
benign intruders might be tolerable
• do consume resources and may slow performance
• can’t know in advance whether benign or malign
IDS / IPS / VPNs can help counter
awareness led to establishment of CERTs
• collect / disseminate vulnerability info / responses
Hacker Behavior Example
The techniques and behavior patterns of intruders are constantly shifting, to exploit newly discovered weaknesses and to evade
detection and countermeasures. Even so, intruders typically follow one of a number of recognizable behavior patterns, and these
patterns typically differ from those of ordinary users. Table 20.1a, based on [RADC04] summarizes an example of the behavior of
hackers. This example is a break-in at a large financial institution. The intruder took advantage of the fact that the corporate network

78 | P a g e
was running unprotected services, some of which were not even needed. In this case, the key to the break-in was the pcAnywhere
application. The manufacturer, Symantec, advertises this program as a remote control solution that enables secure connection to
remote devices. But the attacker had an easy time gaining access to pcAnywhere; the administrator used the same three-letter
username and password for the program. In this case, there was no intrusion detection system on the 700-node corporate network.
The intruder was only discovered when a vice president walked into her office and saw the cursor moving files around on her
Windows workstation.
1. select target using IP lookup tools
2. map network for accessible services
3. identify potentially vulnerable services
4. brute force (guess) passwords
5. install remote administration tool
6. wait for admin to log on and capture password
7. use password to access remainder of network
Criminal Enterprise
Organized groups of hackers have become a widespread and common threat to Internet-based systems. These groups can be in the
employ of a corporation or government, but often are loosely affiliated gangs of hackers. Typically, these gangs are young, often
Eastern European or Russian hackers who do business on the Web. They meet in underground forums with names like
DarkMarket.org and theftservices.com to trade tips and data and coordinate attacks. A common target is a credit card file at an e-
commerce server. Attackers attempt to gain root access. The card numbers are used by organized crime gangs to purchase expensive
items, and are then posted to carder sites, where others can access and use the account numbers; this obscures usage patterns and
complicates investigation. Whereas traditional hackers look for targets of opportunity, criminal hackers usually have specific
targets, or at least classes of targets in mind. Once a site is penetrated, the attacker acts quickly, scooping up as much valuable
information as possible and exiting. IDSs and IPSs can also be used for these types of attackers, but may be less effective because
of the quick in-and-out nature of the attack. For e-commerce sites, database encryption should be used for sensitive customer
information, especially credit cards. For hosted e-commerce sites (provided by an outsider service), the e-commerce organization
should make use of a dedicated server (not used to support multiple customers) and closely monitor the provider's security services.
organized groups of hackers now a threat
• corporation / government / loosely affiliated gangs
• typically young
• often Eastern European or Russian hackers
• often target credit cards on e-commerce server
criminal hackers usually have specific targets
once penetrated act quickly and get out
IDS / IPS help but less effective
sensitive data needs strong protection
Criminal Enterprise Behavior
1. act quickly and precisely to make their activities harder to detect
2. exploit perimeter via vulnerable ports
3. use trojan horses (hidden software) to leave back doors for re-entry
4. use sniffers to capture passwords
5. do not stick around until noticed
6. make few or no mistakes.
Insider Attacks
Insider attacks are among the most difficult to detect and prevent. Employees already have access and knowledge about the structure
and content of corporate databases. Insider attacks can be motivated by revenge of simply a feeling of entitlement. An example of
the former is the case of Kenneth Patterson, fired from his position as data communications manager for American Eagle Outfitters.
Patterson disabled the company's ability to process credit card purchases during five days of the holiday season of 2002. As for a
sense of entitlement, there have always been many employees who felt entitled to take extra office supplies for home use, but this
now extends to corporate data. An example is that of a vice president of sales for a stock analysis firm who quit to go to a competitor.
Before she left, she copied the customer database to take with her. The offender reported feeling no animus toward her former
employee; she simply wanted the data because it would be useful to her. Although IDS and IPS facilities can be useful in countering
insider attacks, other more direct approaches are of higher priority. Examples include: enforcing least privilege, monitor logs,
protect sensitive resources with strong authentication, on termination delete employee's computer and network access and make a
mirror image of employee's hard drive before reissuing it.
 among most difficult to detect and prevent
 employees have access & systems knowledge
 may be motivated by revenge / entitlement
 when employment terminated

79 | P a g e
  taking customer data when move to competitor
 IDS / IPS may help but also need:
 least privilege, monitor logs, strong authentication, termination process to block access & mirror data
Insider Behavior Example
1. create network accounts for themselves and their friends
2. access accounts and applications they wouldn't normally use for their daily jobs
3. e-mail former and prospective employers
4. conduct furtive instant-messaging chats
5. visit web sites that cater to disgruntled employees, such as f'dcompany.com
6. perform large downloads and file copying
7. access the network during off hours.

Intrusion Techniques
The objective of the intruder is to gain access to a system or to increase the range of privileges accessible on a system. Most initial
attacks use system or software vulnerabilities that allow a user to execute code that opens a back door into the system. Alternatively,
the intruder attempts to acquire information that should have been protected. In some cases, this information is in the form of a user
password. With knowledge of some other user's password, an intruder can log in to a system and exercise all the privileges accorded
to the legitimate user. Knowing the standard attack methods is a key element in limiting your vulnerability. The basic aim is to gain
access and/or increase privileges on some system. The basic attack methodology list is taken from McClure et al "Hacking
Exposed”.
• aim to gain access and/or increase privileges on a system
• often use system / software vulnerabilities
• key goal often is to acquire passwords
• so then exercise access rights of owner
• basic attack methodology
• target acquisition and information gathering
• initial access
• privilege escalation
• covering tracks
Password Guessing
Password guessing is a common attack. If an attacker has obtained a poorly protected password file, then can mount attack off-line,
so target is unaware of its progress. Some O/S take less care than others with their password files. If have to actually attempt to
login to check guesses, then system should detect an abnormal number of failed logins, and hence trigger appropriate
countermeasures by admins/security. Likelihood of success depends very much on how well the passwords are chosen.
Unfortunately, users often don’t choose well (see later).
 one of the most common attacks
 attacker knows a login (from email/web page etc)
 then attempts to guess password for it
 defaults, short passwords, common word searches
 user info (variations on names, birthday, phone, common words/interests)
 exhaustively searching all possible passwords
 check by login or against stolen password file
 success depends on password chosen by user
 surveys show many users choose poorly
Password Capture
There is also a range of ways of "capturing" a login/password pair, from the low-tech looking over the shoulder, to the use of Trojan
Horse programs (eg. game program or nifty utility with a covert function as well as the overt behaviour), to sophisticated network
monitoring tools, or extracting recorded info after a successful login - say from web history or cache, or last number dialed memory
on phones etc. Need to educate users to be aware of whose around, to check they really are interacting with the computer system
(trusted path), to beware of unknown source s/w, to use secure network connections (HTTPS, SSH, SSL), to flush browser/phone
histories after use etc.
 another attack involves password capture
 watching over shoulder as password is entered
 using a trojan horse program to collect
 monitoring an insecure network login eg. telnet, FTP, web, email
 extracting recorded info after successful login (web history/cache, last number dialed etc)
 using valid login/password can impersonate user
 users need to be educated to use suitable precautions/countermeasures

80 | P a g e
Intrusion Detection
Inevitably, the best intrusion prevention system will fail. A system’s second line of defense is intrusion detection, which aims to
detect intrusions so can: block access & minimize damage if detected quickly; act as deterrent given chance of being caught; or
can collect info on intruders to improve future security. Intrusion detection is based on the assumption that the behavior of the
intruder differs from that of a legitimate user in ways that can be quantified. This is imperfect at best.
inevitably will have security failures
so need also to detect intrusions so can
• block if detected quickly
• act as deterrent
• collect info to improve security
assume intruder will behave differently to a legitimate user
• but will have imperfect distinction between
Stallings Figure 20.1 suggests, in very abstract terms, the nature of the task confronting the designer of an intrusion detection
system. Although the typical behavior of an intruder differs from the typical behavior of an authorized user, there is an overlap in
these behaviors. Thus, a loose interpretation of intruder behavior, which will catch more intruders, will also lead to a number of
"false positives," or authorized users identified as intruders. On the other hand, an attempt to limit false positives by a tight
interpretation of intruder behavior will lead to an increase in false negatives, or intruders not identified as intruders. Thus, there is
an element of compromise and art in the practice of intrusion detection.

Approaches to Intrusion Detection

Can identify the following approaches to intrusion detection:
1. Statistical anomaly detection: collect data relating to the behavior of legitimate users, then use statistical tests to
determine with a high level of confidence whether new behavior is legitimate user behavior or not.
a. Threshold detection: define thresholds, independent of user, for the frequency of occurrence of events.
b. Profile based: develop profile of activity of each user and use to detect changes in the behavior
2. Rule-based detection: attempt to define a set of rules used to decide if given behavior is an intruder
a. Anomaly detection: rules detect deviation from previous usage patterns
b. Penetration identification: expert system approach that searches for suspicious behavior
In a nutshell, statistical approaches attempt to define normal, or expected, behavior, whereas rule-based approaches
attempt to define proper behavior. In terms of the types of attackers listed earlier, statistical anomaly detection is
effective against masqueraders, who are unlikely to mimic the behavior patterns of the accounts they appropriate. On
the other hand, such techniques may be unable to deal with misfeasors. For such attacks, rule-based approaches may
be able to recognize events and sequences that, in context, reveal penetration. In practice, a system may exhibit a
combination of both approaches to be effective against a broad range of attacks.
statistical anomaly detection
• attempts to define normal/expected behavior
• threshold
• profile based
rule-based detection
• attempts to define proper behavior
• anomaly
• penetration identification

81 | P a g e
Audit Records
A fundamental tool for intrusion detection is the audit record. Some record of ongoing activity by users must be maintained as
input to an intrusion detection system. Basically, two plans are used:
• Native audit records: Virtually all main O/S’s include accounting software that collects information on user activity, advantage
is its already there, disadvantage is it may not contain the needed information.
• Detection-specific audit records: implement collection facility to generates custom audit records with desired info, advantage is
it can be vendor independent and portable, disadvantage is extra overhead involved
fundamental tool for intrusion detection
native audit records
• part of all common multi-user O/S
• already present for use
• may not have info wanted in desired form
detection-specific audit records
• created specifically to collect wanted info
• at cost of additional overhead on system
Statistical Anomaly Detection
Statistical anomaly detection techniques cover threshold detection and profile-based systems. Threshold detection involves
counting no occurrences of a specific event type over an interval of time, if count surpasses a reasonable number, then intrusion is
assumed. By itself, is a crude and ineffective detector of even moderately sophisticated attacks. Profile-based anomaly detection
focuses on characterizing past behavior of users or groups, and then detecting significant deviations. A profile may consist of a set
of parameters, so that deviation on just a single parameter may not be sufficient in itself to signal an alert. Foundation of this
approach is analysis of audit records.
threshold detection
• count occurrences of specific event over time
• if exceed reasonable value assume intrusion
• alone is a crude & ineffective detector
profile based
• characterize past behavior of users
• detect significant deviations from this
• profile usually multi-parameter
Audit Record Analysis
An analysis of audit records over a period of time can be used to determine the activity profile of the average user. Then current
audit records are used as input to detect intrusion, by analyzing incoming audit records to determine deviation from average
behavior. Examples of metrics that are useful for profile-based intrusion detection are: counter, gauge, interval timer, resource use.
Given these general metrics, various tests can be performed to determine whether current activity fits within acceptable limits, such
as: Mean and standard deviation, Multivariate, Markov process, Time series, Operational; as discussed in the text. Stallings Table
20.2 shows various measures considered or tested for the Stanford Research Institute (SRI) intrusion detection system. The main
advantage of the use of statistical profiles is that a prior knowledge of security flaws is not required. Thus it should be readily
portable among a variety of systems.
foundation of statistical approaches
analyze records to get metrics over time
• counter, gauge, interval timer, resource use
use various tests on these to determine if current behavior is acceptable
• mean & standard deviation, multivariate, markov process, time series, operational
key advantage is no prior knowledge used
Rule-Based Intrusion Detection
Rule-based techniques detect intrusion by observing events in the system and applying a set of rules that lead to a decision regarding
whether a given pattern of activity is or is not suspicious. Can characterize approaches as either anomaly detection or penetration
identification, although there is overlap. Rule-based anomaly detection is similar in terms of its approach and strengths to statistical
anomaly detection. Historical audit records are analyzed to identify usage patterns and to automatically generate rules that describe
those patterns. Current behavior is then observed and matched against the set of rules to see if it conforms to any historically
observed pattern of behavior. As with statistical anomaly detection, rule-based anomaly detection does not require knowledge of
security vulnerabilities within the system.
observe events on system & apply rules to decide if activity is suspicious or not
rule-based anomaly detection
• analyze historical audit records to identify usage patterns & auto-generate rules for them
• then observe current behavior & match against rules to see if conforms

82 | P a g e
 • like statistical anomaly detection does not require prior knowledge of security flaws
Rule-based penetration identification takes a very different approach based on expert system technology. It uses rules for identifying
known penetrations or penetrations that would exploit known weaknesses, or identify suspicious behavior. The rules used are
specific to machine and operating system. The rules are generated by “experts”, from interviews of system administrators and
security analysts. Thus the strength of the approach depends on the skill of those involved in setting up the rules.
 rule-based penetration identification
 uses expert systems technology
 with rules identifying known penetration, weakness patterns, or suspicious behavior
 compare audit records or states against rules
 rules usually machine & O/S specific
 rules are generated by experts who interview & codify knowledge of security admins
 quality depends on how well this is done
Base-Rate Fallacy
To be of practical use, an intrusion detection system should detect a substantial percentage of intrusions while keeping the false
alarm rate at an acceptable level. If only a modest percentage of actual intrusions are detected, the system provides a false sense of
security. On the other hand, if the system frequently triggers an alert when there is no intrusion (a false alarm), then either system
managers will begin to ignore the alarms, or much time will be wasted analyzing the false alarms. Unfortunately, because of the
nature of the probabilities involved, it is very difficult to meet the standard of high rate of detections with a low rate of false alarms.
A study of existing intrusion detection systems indicated that current systems have not overcome the problem of the base-rate
fallacy.
practically an intrusion detection system needs to detect a substantial percentage of intrusions
with few false alarms
• if too few intrusions detected -> false security
• if too many false alarms -> ignore / waste time
this is very hard to do
existing systems seem not to have a good record
Distributed Intrusion Detection
Until recently, work on intrusion detection systems focused on single-system standalone facilities. The typical organization,
however, needs to defend a distributed collection of hosts supported by a LAN or internetwork, where a more effective defense can
be achieved by coordination and cooperation among intrusion detection systems across the network. Porras points out the following
major issues in the design of a distributed IDS:
• A distributed intrusion detection system may need to deal with different audit record formats
• One or more nodes in the network will serve as collection and analysis points for the data, which must be securely transmitted to
them
• Either a centralized (single point, easier but bottleneck) or decentralized (multiple centers must coordinate) architecture can be
used.
• traditional focus is on single systems
• but typically have networked systems
• more effective defense has these working together to detect intrusions
• issues
• dealing with varying audit record formats
• integrity & confidentiality of networked data
• centralized or decentralized architecture
Distributed Intrusion Detection - Architecture
Stallings Figure 20.2 shows the overall architecture, consisting of three main components, of the system independent
distributed IDS developed at the University of California at Davis. The components are:
• Host agent module: audit collection module operating as a background process on a monitored system
• LAN monitor agent module: like a host agent module except it analyzes LAN traffic
• Central manager module: Receives reports from LAN monitor and host agents and processes and correlates these
reports to detect intrusion

83 | P a g e
Distributed Intrusion Detection – Agent Implementation
Stallings Figure 20.3 shows the general approach that is taken. The agent captures each native O/S audit record, & applies a filter
that retains only records of security interest. These records are then reformatted into a standardized format (HAR). Then a template-
driven logic module analyzes the records for suspicious activity. When suspicious activity is detected, an alert is sent to the central
manager. The central manager includes an expert system that can draw inferences from received data. The manager may also query
individual systems for copies of HARs to correlate with those from other agents.

Honeypots
Honeypots are decoy systems, designed to lure a potential attacker away from critical systems, and:
 divert an attacker from accessing critical systems
 collect information about the attacker’s activity
 encourage the attacker to stay on the system long enough for administrators to respond
These systems are filled with fabricated information designed to appear valuable but which any legitimate user of the system
wouldn’t access, thus, any access is suspect. They are instrumented with sensitive monitors and event loggers that detect these
accesses and collect information about the attacker’s activities. Have seen evolution from single host honeypots to honeynets of
multiple dispersed systems. The IETF Intrusion Detection Working Group is currently drafting standards to support interoperability
of IDS info (both honeypot and normal IDS) over a wide range of systems & O/S’s.
 decoy systems to lure attackers
 away from accessing critical systems
 to collect information of their activities
 to encourage attacker to stay on system so administrator can respond
 are filled with fabricated information
 instrumented to collect detailed information on attackers activities
 single or multiple networked systems
 cf IETF Intrusion Detection WG standards
Firewall
A firewall is inserted between the premises network and the Internet to establish a controlled link and to erect an outer security
wall or perimeter, forming a single choke point where security and audit can be imposed. A firewall:
1. defines a single choke point that keeps unauthorized users out of the protected network, prohibits potentially vulnerable
services from entering or leaving the network, and provides protection from various kinds of IP spoofing & routing attacks.
2. provides a location for monitoring security-related events
3. is a convenient platform for several Internet functions that are not security related, such as NAT and Internet usage audits or logs
4. A firewall can serve as the platform for IPSec to implement virtual private networks.
The firewall itself must be immune to penetration, since it will be a target of attack.
What is a Firewall?
 a choke point of control and monitoring
 interconnects networks with differing trust
 imposes restrictions on network services
• only authorized traffic is allowed

84 | P a g e
  auditing and controlling access
• can implement alarms for abnormal behavior
 provide NAT & usage monitoring
 implement VPNs using IPSec
 must be immune to penetration
Stallings Figure 22.1a illustrates the general model of firewall use on the security perimeter, as a choke point for traffic between
the external less-trusted Internet and the internal more trusted private network.

Firewall Limitations
Firewalls have their limitations, including that they:
1. cannot protect against attacks that bypass the firewall, eg PCs with dial-out capability to an ISP, or dial-in modem pool use
2. do not protect against internal threats, eg disgruntled employee or one who cooperates with an attacker
3. An improperly secured wireless LAN may be accessed from outside the organization. An internal firewall that separates
portions of an enterprise network cannot guard against wireless communications between local systems on different sides of the
internal firewall.
4. A laptop, PDA, or portable storage device may be used and infected outside the corporate network, and then attached and used
internally.
 cannot protect from attacks bypassing it
• eg sneaker net, utility modems, trusted organisations, trusted services (eg SSL/SSH)
 cannot protect against internal threats
• eg disgruntled or colluding employees
 cannot protect against access via WLAN
• if improperly secured against external use
 cannot protect against malware imported via laptop, storage infected outside
Firewalls – Packet Filters
Have three common types of firewalls: packet filters, application-level gateways, & circuit-level gateways.
A packet-filtering router applies a set of rules to each incoming and outgoing IP packet to forward or discard the packet. Filtering
rules are based on information contained in a network packet such as src & dest IP addresses, ports, transport protocol & interface.
Some advantages are simplicity, transparency & speed.
If there is no match to any rule, then one of two default policies are applied:
 that which is not expressly permitted is prohibited (default action is discard packet), conservative policy
 that which is not expressly prohibited is permitted (default action is forward packet), permissive policy
 simplest, fastest firewall component
 foundation of any firewall system
 examine each IP packet (no context) and permit or deny according to rules
 hence restrict access to services (ports)
 possible default policies
o that not expressly permitted is prohibited
o that not expressly prohibited is permitted
Stallings Figure 22.1b (along with 4/e Figure 20.1a) illustrates the packet filter firewall role as utilizing information from the
transport, network & data link layers to make decisions on allowable traffic flows, and its placement in the border router between
the external less-trusted Internet and the internal more trusted private network.

Stallings Table 22.1 gives some examples of packet-filtering rule sets. In each set, the rules are applied top to bottom.
A. Inbound mail is allowed to a gateway host only (port 25 is for SMTP incoming
B. explicit statement of the default policy

85 | P a g e
 C. tries to specify that any inside host can send mail to the outside, but has problem that an outside machine could be
configured to have some other application linked to port 25
D. properly implements mail sending rule, by checking ACK flag of a TCP segment is set
E. this rule set is one approach to handling FTP connections

Attacks on Packet Filters

Some of the attacks that can be made on packet-filtering routers & countermeasures are:
• IP address spoofing: where intruder transmits packets from the outside with internal host source IP addr, need to filter & discard
such packets
• Source routing attacks: where source specifies the route that a packet should take to bypass security measures, should discard all
source routed packets
• Tiny fragment attacks: intruder uses the IP fragmentation option to create extremely small fragments and force the TCP header
information into a separate fragments to circumvent filtering rules needing full header info, can enforce minimum fragment size
to include full header.
 IP address spoofing
• fake source address to be trusted
• add filters on router to block
 source routing attacks
• attacker sets a route other than default
• block source routed packets
 tiny fragment attacks
• split header info over several tiny packets
• either discard or reassemble before check
Firewalls – Stateful Packet Filters
A traditional packet filter makes filtering decisions on an individual packet basis and does not take into consideration any higher
layer context. In general, when an application that uses TCP creates a session with a remote host, it creates a TCP connection in
which the TCP port number for the remote (server) application is a number less than 1024 and the TCP port number for the local
(client) application is a number between 1024 and 65535. A simple packet filtering firewall must permit inbound network traffic
on all these high- numbered ports for TCP-based traffic to occur. This creates a vulnerability that can be exploited by unauthorized
users. A stateful inspection packet filter tightens up the rules for TCP traffic by creating a directory of outbound TCP connections,
and will allow incoming traffic to high-numbered ports only for those packets that fit the profile of one of the entries in this
directory. Hence they are better able to detect bogus packets sent out of context. A stateful packet inspection firewall reviews the
same packet information as a packet filtering firewall, but also records information about TCP connections. Some stateful firewalls
also keep track of TCP sequence numbers to prevent attacks that depend on the sequence number, such as session hijacking. Some
even inspect limited amounts of application data for some well-known protocols like FTP, IM and SIPS commands, in order to
identify and track related connections.
traditional packet filters do not examine higher layer context
• i.e. matching return packets with outgoing flow
stateful packet filters address this need
they examine each IP packet in context
• keep track of client-server sessions
• check each packet validly belongs to one
hence are better able to detect bogus packets out of context
may even inspect limited application data

86 | P a g e
Firewalls - Application Level Gateway (or Proxy)
An application-level gateway (or proxy server), acts as a relay of application-level traffic. A user contacts the gateway to access
some service, provides details of the service, remote host & authentication details, contacts the application on the remote host and
relays all data between the two endpoints. If the gateway does not implement the proxy code for a specific application, then it is
not supported and cannot be used. Note that some services naturally support proxying, whilst others are more problematic.
Application-level gateways tend to be more secure than packet filters, &can log and audit traffic at application level.
 have application specific gateway / proxy
 has full access to protocol
 user requests service from proxy
 proxy validates request as legal
 then actions request and returns result to user
 can log / audit traffic at application level
 need separate proxies for each service
 some services naturally support proxying
 others are more problematic
Stallings Figure 22.1d (along with 4/e Figure 20.1b) illustrates an application-level gateway (or proxy server), emphasizing that it
only supports a specific list of application services.

Firewalls - Circuit Level Gateway

A fourth type of firewall is the circuit-level gateway or circuit-level proxy. This can be a stand-alone system or it can be a
specialized function performed by an application-level gateway for certain applications. A circuit-level gateway relays two TCP
connections, one between itself and an inside TCP user, and the other between itself and a TCP user on an outside host. Once the
two connections are established, it relays TCP data from one connection to the other without examining its contents. The security
function consists of determining which connections will be allowed. It is typically used when internal users are trusted to decide
what external services to access. One of the most common circuit-level gateways is SOCKS, defined in RFC 1928. It consists of a
SOCKS server on the firewall, and a SOCKS library & SOCKS-aware applications on internal clients. When a TCP-based client
wishes to establish a connection to an object that is reachable only via a firewall (such determination is left up to the
implementation), it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system. If the connection
request succeeds, the client enters a negotiation for the authentication method to be used, authenticates with the chosen method,
and then sends a relay request. The SOCKS server evaluates the request and either establishes the appropriate connection or denies
it. UDP exchanges are handled in a similar fashion.
• relays two TCP connections
• imposes security by limiting which such connections are allowed
• once created usually relays traffic without examining contents
• typically used when trust internal users by allowing general outbound connections
• SOCKS is commonly used
Stallings Figure 22.1e (along with 4/e Figure 20.1c) illustrates a circuit-level gateway, showing how it relays between 2 TCP
connections. Note that it can be implemented in a stand-alone system or can be a specialized function in an application-level
gateway for certain applications. Note also that relaying UDP packets is more problematical, because of the lack of connection
context, and require a parallel TCP connection to provide these details.

87 | P a g e
Bastion Host
It is common to base a firewall on a stand-alone machine running a common operating system, such as UNIX or Linux. Firewall
functionality can also be implemented as a software module in a router or LAN switch. A bastion host is a critical strong point in
the network’s security, serving as a platform for an application-level or circuit-level gateway, or for external services. It is thus
potentially exposed to "hostile" elements and must be secured to withstand this. Common characteristics of a bastion host include
that it:
• executes a secure version of its O/S, making it a trusted system
• has only essential services installed on the bastion host
• may require additional authentication before a user may access to proxy services
• configured to use only subset of standard commands, access only specific hosts
• maintains detailed audit information by logging all traffic
• each proxy module a very small software package designed for network security
• has each proxy independent of other proxies on the bastion host
• have a proxy performs no disk access other than read its initial configuration file
• have each proxy run as a non-privileged user in a private and secured directory
A bastion host may have two or more network interfaces (or ports), and must be trusted to enforce trusted separation between these
network connections, relaying traffic only according to policy.
 highly secure host system
 runs circuit / application level gateways
 or provides externally accessible services
 potentially exposed to "hostile" elements
 hence is secured to withstand this
 hardened O/S, essential services, extra auth
 proxies small, secure, independent, non-privileged
 may support 2 or more net connections
 may be trusted to enforce policy of trusted separation between these net connections
Host-Based Firewalls
A host-based firewall is a software module used to secure an individual host. Such modules are available in many operating
systems or can be provided as an add-on package. Like conventional stand-alone firewalls, host-resident firewalls filter and
restrict the flow of packets. A common location for such firewalls is a server. There are several advantages to the use of a server-
based or workstation-based firewall:
• Filtering rules can be tailored to the host environment. Specific corporate security policies for servers can be implemented, with
different filters for servers used for different application.
• Protection is provided independent of topology. Thus both internal and external attacks must pass through the firewall.
• Used in conjunction with stand-alone firewalls, the host-based firewall provides an additional layer of protection. A new type of
server can be added to the network, with its own firewall, without the necessity of altering the network firewall configuration.
s/w module used to secure individual host
• available in many operating systems
• or can be provided as an add-on package
often used on servers
advantages:
• can tailor filtering rules to host environment
• protection is provided independent of topology
• provides an additional layer of protection

88 | P a g e
Personal Firewalls
A personal firewall controls the traffic between a personal computer or workstation on one side and the Internet or enterprise
network on the other side. Personal firewall functionality can be used in the home environment and on corporate intranets.
Typically, the personal firewall is a software module on the personal computer. In a home environment with multiple computers
connected to the Internet, firewall functionality can also be housed in a router that connects all of the home computers to a DSL,
cable modem, or other Internet interface.
Personal firewalls are typically much less complex than either server-based firewalls or stand-alone firewalls. The primary role of
the personal firewall is to deny unauthorized remote access to the computer. The firewall can also monitor outgoing activity in an
attempt to detect and block worms and other malware.
• controls traffic between PC/workstation and Internet or enterprise network
• a software module on personal computer
• or in home/office DSL/cable/ISP router
• typically much less complex than other firewall types
• primary role to deny unauthorized remote access to the computer
• and monitor outgoing activity for malware
Firewall Configurations
As Figure 22.1a indicates, a firewall is positioned to provide a protective barrier between an external, potentially untrusted source
of traffic and an internal network. With that general principle in mind, a security administrator must decide on the location and on
the number of firewalls needed. In addition to the use of a simple configuration consisting of a single system, more complex
configurations are possible and indeed more common. Stallings 4/e Figure 20.2 illustrates three common firewall configurations.
4/e Figure 20.2a shows the “screened host firewall, single-homed bastion configuration”, where the firewall consists of two
systems:
• a packet-filtering router - allows Internet packets to/from bastion only
• a bastion host - performs authentication and proxy functions
This configuration has greater security, as it implements both packet-level & application-level filtering, forces an intruder to
generally penetrate two separate systems to compromise internal security, & also affords flexibility in providing direct Internet
access to specific internal servers (eg web) if desired.

Stallings 4/e Figure 20.2b illustrates the “screened host firewall, dual-homed bastion configuration” which physically separates the
external and internal networks, ensuring two systems must be compromised to breach security. The advantages of dual layers of
security are also present here. Again, an information server or other hosts can be allowed direct communication with the router if
this is in accord with the security policy, but are now separated from the internal network.

89 | P a g e
Stallings 4/e Figure 20.2c shows the “screened subnet firewall configuration”, being the most secure shown. It has two packet-
filtering routers, one between the bastion host and the Internet and the other between the bastion host and the internal network,
creating an isolated subnetwork. This may consist of simply the bastion host but may also include one or more information servers
and modems for dial-in capability. Typically, both the Internet and the internal network have access to hosts on the screened subnet,
but traffic across the screened subnet is blocked.
This configuration offers several advantages:
• There are now three levels of defense to thwart intruders
• The outside router advertises only the existence of the screened subnet to the Internet; therefore the internal network is invisible
to the Internet
• Similarly, the inside router advertises only the existence of the screened subnet to the internal network; hence systems on the
inside network cannot construct direct routes to the Internet

DMZ Networks
Stallings Figure 22.3 further illustrates the use of a “screened subnet”, also known as a demilitarized zone (DMZ), located between
an internal and an external firewall. An external firewall is placed at the edge of a local or enterprise network, just inside the
boundary router that connects to the Internet or some wide area network (WAN). One or more internal firewalls protect the bulk of
the enterprise network. Systems that are externally accessible but need some protections are usually located on DMZ networks.
Typically, the systems in the DMZ require or foster external connectivity, such as a corporate Web site, an e-mail server, or a DNS
(domain name system) server. The external firewall provides a measure of access control and protection for the DMZ systems
consistent with their need for external connectivity. The external firewall also provides a basic level of protection for the remainder
of the enterprise network. In this type of configuration, internal firewalls serve three purposes:
1. The internal firewall adds more stringent filtering capability, vs the external firewall, to protect enterprise servers and
workstations from external attack.
2. The internal firewall provides two-way protection with respect to the DMZ, as it protects the remainder of the network
from attacks launched from DMZ systems, and protects DMZ systems from attack by internal hosts.
3. Multiple internal firewalls can be used to protect portions of the internal network from each other.
A common practice is to place the DMZ on a different network interface on the external firewall from that used to access the
internal networks.

90 | P a g e
Distributed Firewalls
A distributed firewall configuration involves stand-alone firewall devices plus host-based firewalls working together
under a central administrative control. Stallings Figure 22.5 suggests a distributed firewall configuration.
Administrators can configure host-resident firewalls on hundreds of servers and workstation as well as configure
personal firewalls on local and remote user systems. Tools let the network administrator set policies and monitor
security across the entire network. These firewalls protect against internal attacks and provide protection tailored to
specific machines and applications. Stand-alone firewalls provide global protection, including internal firewalls and
an external firewall, as discussed previously. With distributed firewalls, it may make sense to establish both an internal
and an external DMZ. Web servers that need less protection because they have less critical information on them could
be placed in an external DMZ, outside the external firewall. What protection is needed is provided by host-based
firewalls on these servers. An important aspect of a distributed firewall configuration is security monitoring. Such
monitoring typically includes log aggregation and analysis, firewall statistics, and fine-grained remote monitoring of
individual hosts if needed.

Operating System Security

Designing Trusted Operating Systems
What makes an operating system “secure”? Or “trustworthy?
How are trusted systems designed, and which of those design principles carry over naturally to other
program development tasks?
How do we develop “assurance” of the correctness of a trusted operating systems?
Primitive security services
• Memory protection
• File protection
• General object access control
• User authentication
OS is trusted if we have confidence that it provides these four services in a consistent and effective way.
What is a trusted system?

• Trusted process – process that can affect system security

• Trusted product – evaluated and approved product
• Trusted software- software portion of system that can be relied upon to enforce security policy

91 | P a g e
• Trusted computing base – set of all protection mechanisms within a computing system that enforce a unified
security policy
• Trusted system – system that employs sufficient hardware and software integrity measures to allow its use for
processing sensitive information
Trusted System Design Elements
• Least privilege
• Economy of mechanism
• Open design
• Complete mediation
• Permission based
• Separation of privilege
• Least common mechanism
• Ease of use
Security Features of Ordinary Operating Systems
• Authentication of users
• Protection of memory
• File and I/O device access control
• Allocation and access control to general objects
• Enforcement of sharing
• Guarantee of fair service
• Interprocess communications and synchronization
• Protection of operating system protection data
Security Features of Trusted Operating Systems
 Trusted systems incorporate technology to address both features and assurance
 Objects are accompanied (surrounded) by an access control mechanism
 Memory is separated by user, and data and program libraries have controlled sharing and separation
 Identification and Authentication
• Require secure id of individuals, each individual must be uniquely identified
 Mandatory and Discretionary Access Control
• MAC – access control policy decisions are made beyond the control of the individual owner of the
object
• DAC – leaves access control to the discretion of the object’s owner
• MAC has precedence over DAC
 Object Reuse Protection
• Prevent object reuse leakage
• OS clears (overwrites) all space to be reassigned
• Problem of magnetic remanence
 Complete Mediation
• All accesses must be controled
 Trusted Path
• For critical operations (setting password, etc.), users want unmistakable communications
 Accountability and Audit
• Maintain a log of security relevant events
• Audit log must be protected from outsiders
 Audit Log Reduction
• Audit only open and close of files/objects
 Intrusion detection
• Build patterns of normal system usage, triggering an alarm any time usage seems abnormal
• Intrusion prevention
Kernelized Design
Kernel – part of OS that performs lowest-level functions
• Synchronization, interprocess communications, message passing, interrupt handling

92 | P a g e
 • Security kernel – responsible for enforcing security mechanism for entire OS; provides interface among
the hardware, OS, and other parts of computer system
Malicious software and countermeasures
Software Flaws and Malware
If automobiles had followed the same development cycle as the computer, a Rolls-Royce would today cost
$100, get a million miles per gallon, and explode once a year, killing everyone inside.  Robert X.
Cringely
My software never has bugs. It just develops random features.  Anonymous
Software Issues

Lines of Code and Bugs

• Conservative estimate: 5 bugs/10,000 LOC
• Do the math
• Typical computer: 3000 exe’s of 100,000 LOC each
• Conservative estimate: 50 bugs/exe
• Implies about 150,000 bugs per computer
• So, 30,000-node network has 4.5 billion bugs
• Maybe only 10% of bugs security-critical and only 10% of those remotely exploitable
• Then “only” 45 million critical security flaws!
Software Security Topics
Program flaws (unintentional)
 Buffer overflow
 Incomplete mediation
 Race conditions
Malicious software (intentional)
 Viruses
 Worms
 Other breeds of malware
Program Flaws
An error is a programming mistake
• Made by human/programmer
An error may lead to incorrect state: fault
• A fault is internal to the program
A fault may lead to a failure, where a system departs from its expected behavior
• A failure is externally observable

Program Flaws - Example

 This program has an error
 This error might cause a fault
o Incorrect internal state
 If a fault occurs, it might lead to a failure
o Program behaves incorrectly (external)

93 | P a g e
  We use the term flaw for all of the above

Secure Software

1. Buffer Overflow

1. Buffer Overflow: Attack Scenario

94 | P a g e
95 | P a g e
96 | P a g e
2. Incomplete Mediation

Input Validation
• Consider: strcpy(buffer, argv[1])
• A buffer overflow occurs if
len(buffer) < len(argv[1])
• Software must validate the input by checking the length of argv[1]
• Failure to do so is an example of a more general problem: incomplete mediation
Input Validation - Example
Consider web form data
Suppose input is validated on client. For example, the following is valid
http://www.things.com/orders/final&custID=112&num=55&qty=20&price=10&shipping=5&total=205
Suppose input is not checked on server. Why bother since input checked on client?
Then attacker could send http message
http://www.things.com/orders/final&custID=112&num=55&qty=20&price=10&shipping=5&total=25

97 | P a g e
3. Race Conditions

 Security processes should be atomic

 Occur “all at once”
 Race conditions can arise when security-critical process occurs in stages
The term race condition refers to a "race" between the attacker and the next stage of the process
 Attacker makes change between stages
Often, between stage that gives authorization, but before stage that transfers ownership
 Example: Unix mkdir
 The outdated version of the Unix command mkdir, which creates a new directory
 Thus, the directory is created in stages—
1. there is a stage that determines authorization
2. followed by a stage that transfers ownership

Race Conditions
 Race conditions are common
 Race conditions may be more prevalent than buffer overflows
 But race conditions harder to exploit
• Buffer overflow is “low hanging fruit” today
 To prevent race conditions, make security-critical processes atomic
• Occur all at once, not in stages
• Not always easy to accomplish in practice

98 | P a g e
Malware
Malicious Software (Malware) is not new…
 Fred Cohen’s initial virus work in 1980’s
 Cohen used viruses to break MLS systems
Types of malware (no standard definition)
 Virus  passive propagation
 Worm  active propagation
 Trojan horse  unexpected functionality
 Trapdoor/backdoor  unauthorized access
 Rabbit  exhaust system resources
 Spyware  steals info, such as passwords
Where do Viruses Live?
 They live just about anywhere, such as…
 Boot sector
 Take control before anything else
 Memory resident
 Stays in memory
 Applications, macros, data, ……. .. etc.
 Library routines
 Compilers, debuggers, virus checker, ….. .. etc.
Malware Detection
Three common detection methods
1. Signature detection
2. Change detection
3. Anomaly detection

99 | P a g e
100 | P a g e