Transcript INS PPT - Home Kalim Puthawala

Information and Network Security
B.E. Semester VII (CE/IT)
Text:
CRYPTOGRAPHY AND NETWORK
SECURITY – Principles and Practice
by William Stallings
Hiren B Patel
CONVENTIONAL ENCRYPTION:
CLASSICAL TECHNIQUES
Home
MODEL OF CONVENTIONAL ENVRYPTION
Home
MODEL OF CONVENTIONAL CRYPTOSYSTEM
Home
CRYPTOGRAPHY
1.
Types of operations used for transforming plaintext to
ciphertext.
a.
b.
2.
Number of keys used.
a.
b.
3.
Substitution
Transposition
Symmetric/Single key/Secret key/Conventional
Asymmetric/Two key/public key
The way in which the plaintext is processed.
a.
b.
Block Cipher
Stream Cipher
Home
CLASSICAL ENCRYPTION TECHNIQUES
Home
CRYPTANALYSIS



It is the study of methods for obtaining the meaning
of encrypted information, without access to the
secret information.
It includes methods and techniques of recovering
information from encrypted material without
knowledge of the key.
Someone who performs cryptanalysis is called a
cryptanalyst.
Home
TYPES OF ATTACKS ON ENCRYPTED MESSAGES
Home
Classical Encryption Techniques




Caesar Cipher
Playfair Cipher
Hill Cipher
Rotor Machines
Home
Caesar Cipher – Substitution Cipher
Plain: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Cipher: DEFGHIJKLMNOPQRSTUVWXYZABC
Home
Caesar Cipher - Example
Plaintext: the quick brown fox jumps over the lazy dog
Ciphertext: WKH TXLFN EURZQ IRA MXPSV RYHU WKH ODCB GRJ
Encryption: En(X) = (X + n) mod 26
Decryption: Dn(X) = (X – n) mod 26
Home
Caesar Cipher – Breaking the Code
The Caesar cipher can be easily broken even in a ciphertext-only scenario. Since
there are only a limited number of possible shifts (26 in English), they can each be
tested in turn in a brute force attack.
A brute force attack is a method of defeating a cryptographic scheme by
systematically trying a large number of possibilities.
Have some fun on: http://www.secretcodebreaker.com/caesar.html
Home
Playfair Cipher
The Playfair cipher uses a 5 X 5 (also 6 X 6) table containing a key word or
phrase.
For example, Using "playfair example" as the key, the table becomes
PLAYF
IREXM
BCDGH
JKNOS
TUVWZ
Encrypting the message "Hide the gold in the tree stump":
HI DE TH EG OL DI NT HE TR EX ES TU MP
Encrypted Message
BM ND ZB XD KY BE JV DM UI XM MN UV IF
Home
Playfair Cipher
Home
Hill Cipher
Each letter is first encoded as a number. Often the simplest scheme is
used: A = 0, B =1, ..., Z=25. This algorithm takes m successive plaintext
letters and substitutes for them m ciphertext letters. For m=3, the system
can be described as below.
C1 = (k11p1 + k12p2 + k13p3) mod 26
C2 = (k21p1 + k22p2 + k23p3) mod 26
C4 = (k31p1 + k32p2 + k33p3) mod 26
Home
Hill Cipher - Encryption
Home
Hill Cipher - Decryption
In order to decrypt, we turn the ciphertext back into a vector, then simply
multiply by the inverse matrix of the key matrix (IFKVIVVMI in letters).
Home
Steganography
Steganography is the art and science of writing hidden messages in such
a way that no one, apart from the sender and intended recipient, suspects
the existence of the message, a form of security through obscurity.
The word steganography is of Greek origin and means "concealed
writing" from the Greek words steganos (στεγανός) meaning "covered or
protected", and graphein (γράφειν) meaning "to write".
Home
Steganography Vs. Cryptography
The advantage of steganography, over cryptography alone, is that
messages do not attract attention to themselves. Plainly visible encrypted
messages—no matter how unbreakable—will arouse suspicion, and may
in themselves be incriminating in countries where encryption is illegal.
Therefore, whereas cryptography protects the contents of a message,
steganography can be said to protect both messages and communicating
parties.
Home
Steganography
Steganography includes the concealment of information within computer
files. In digital steganography, electronic communications may include
steganographic coding inside of a transport layer, such as a document
file, image file, program or protocol. Media files are ideal for
steganographic transmission because of their large size. As a simple
example, a sender might start with an innocuous image file and adjust
the color of every 100th pixel to correspond to a letter in the alphabet, a
change so subtle that someone not specifically looking for it is unlikely
to notice it.
Home
Steganography: Example
Steganart example: Within this
picture, the letter positions of a hidden
message are represented by increasing
numbers (1 to 20), and a letter value is
given by its intersection position in the
grid. For instance, the first letter of the
hidden message is at the intersection of
1 and 4. So, after a few tries, the first
letter of the message seems to be the
14th letter of the alphabet; the last one
(number 20) is the 5th letter of the
alphabet.
Home
CONVENTIONAL ENCRYPTION: MODERN
TECHNIQUES
Home
SIMPLIFIED DES
IP: Initial Permutation
fk: A Complex Function (which involved
both substitution and permutation)
SW: Switch the data into two halves
IP-1: The inverse of IP
P: Permutation
Ciphertext = IP-1(fk2(SW(fk1(IP(plaintext)))))
k1=P8(Shift(P10(key)))
k2=P8(Shift(Shift(P10(key))))
Plaintext = IP-1(fk1(SW(fk2(IP(ciphertext)))))
Home
BLOCK CIPHER PRINCIPLES
• Stream Ciphers and Block Ciphers


Stream cipher: one bit or byte at a time
Block cipher: a large block, typically 64 or 128 bits, at a time
– Block ciphers work on a block at a time, which is some
number of bits. All of these bits have to be available
before they can be processed
– Broader range of applications than stream ciphers
– Large block thwarts statistical attacks
Home
BLOCK CIPHER PRINCIPLES
• Motivation for the Feistel Cipher Structure

What is the most general form of block cipher?
– For n-bit block, consider the transformation, F: 2n  2n
– F must be reversible, i.e., 1-1 correspondence
– (Ideal block cipher) 2n! mappings
 mapping itself is a key  key size = O(n  2n) bits
– 64-bit block   270  1021 bits key  Not practical
 Need approximation (k-bit key, 2k possible mappings)
Reversible Mapping
Irreversible Mapping
Plaintext
Ciphertext
Plaintext
Ciphertext
00
11
00
11
01
10
01
10
10
00
10
01
11
01
11
01
Home
Ideal Block Cipher
Home
Motivation for Feistel Cipher Structure

In 1949, Claude Shannon introduced the idea of
substitution-permutation (S-P) networks which form
the basis of modern block ciphers
Home
Motivation for Feistel
Cipher Structure



S-P network: a special form of substitutiontransposition product cipher
Product cipher
– Two or more simple ciphers are performed in
sequence in such a way that the final result or
product is cryptographically stronger than any of
the component ciphers
Feistel cipher
– In 1970’s, Horst Feistel (IBM T.J. Watson Research
Labs) invented a suitable (practical) structure
which adapted Shannon’s S-P network
– Encryption and decryption use the same structure
Home

Feistel Cipher Structure
Input block is partitioned into two
halves, Li-1 and Ri-1
 In round i,
Li = Ri-1
Ri = Li-1  F(Ki,Ri-1)
 Substitution followed by permutation
 Multiple rounds
 An Implementation of Shannon’s S-P
network (SPN) concept



Home
Feistel Cipher Design Elements







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 encryption/decryption
Home
Ease of analysis
Feistel Decryption
Algorithm




Essentially same as the
encryption
Same algorithm but use the
subkeys Ki in reverse order
F need not be a reversible
function
Satisfy DK(EK(P)) = P
Home
THE DATA ENCRYPTION STANDANRD





Block cipher (64-bit block)
Uses 56-bit key (out of 64 bits)
16 rounds
48-bit subkeys
Feistel structure (except initial and final
permutations)
Home
THE DATA ENCRYPTION STANDANRD
Home
Initial / Inverse Initial Permutation
Home
Single Round of DES
Home
DIFFERENTIAL AND LINEAR CRYPTANALYSIS
Linear cryptanalysis is a general form of cryptanalysis based on
finding affined approximations to the action of a cipher. There are
two parts to linear cryptanalysis. The first is to construct linear
equations relating plaintext, ciphertext and key bits that have a
high bias; that is, whose probabilities of holding (over the space of
all possible values of their variables) are as close as possible to 0
or 1. The second is to use these linear equations in conjunction
with known plaintext-ciphertext pairs to derive key bits.
Constructing linear equations
Deriving key bits
Home
BLOCK CIPHER DESIGN PRINCIPLES
•Permutation
•Number of rounds
•Design of Function F
•S-Box Design
•Key Schedule Algorithm
Home
BLOCK CIPHER MODES OF OPERATION
Electronic Codebook (ECB)
Cipher Block Chaining (CBC)
Cipher Feedback (CFB)
Output Feedback (OFB)
Home
BLOCK CIPHER MODES OF OPERATION
Electronic Codebook (ECB)
Home
BLOCK CIPHER MODES OF OPERATION
Cipher Block Chaining (CBC)
Home
BLOCK CIPHER MODES OF OPERATION
Cipher Feedback Mode (CFB)
Home
BLOCK CIPHER MODES OF OPERATION
Output Feedback Mode (OFB)
Home
CONVENTIONAL ENCRYPTION:
ALGORITHS
Home
Triple DES



Triple DES is the common name for the Triple Data
Encryption Algorithm (TDEA) block cipher.
It is so named because it applies the Data Encryption
Standard (DES) cipher algorithm three times to each
data block.
Triple DES provides a relatively simple method of
increasing the key size of DES to protect against
brute force attacks, without requiring a completely
new block cipher algorithm.
Triple DES
Triple DES
Triple DES
Triple DES








Triple DES uses a "key bundle" which comprises three DES keys, K1,
K2 and K3, each of 56 bits (excluding parity bits). The encryption
algorithm is:
ciphertext = EK3(DK2(EK1(plaintext)))
i.e., DES encrypt with K1, DES decrypt with K2, then DES encrypt with
K3.
Decryption is the reverse:
plaintext = DK1(EK2(DK3(ciphertext)))
I.e., decrypt with K3, encrypt with K2, then decrypt with K1.
Each triple encryption encrypts one block of 64 bits of data.
In each case the middle operation is the reverse of the first and last. This
improves the strength of the algorithm when using keying option 2, and
provides backward compatibility with DES with keying option 3.
International
Data Encryption Algorithm (IDEA)
In cryptography, the International Data Encryption Algorithm (IDEA) is a
block cipher designed by James Massey of ETH Zurich and Xuejia Lai
and was first described in 1991. As a block cipher, it is also symmetric.
The algorithm was intended as a replacement for the Data Encryption
Standard. IDEA is a minor revision of an earlier cipher, PES (Proposed
Encryption Standard); IDEA was originally called IPES (Improved PES).
International
Data Encryption Algorithm (IDEA)
IDEA operates on 64-bit blocks using a 128-bit key, and consists of a series of
eight identical transformations (a round, see the illustration) and an output
transformation (the half-round). The processes for encryption and decryption are
similar. IDEA derives much of its security by interleaving operations from
different groups — modular addition and multiplication, and bitwise eXclusive
OR (XOR) — which are algebraically "incompatible" in some sense.
In more detail, these operators, which all deal with 16-bit quantities, are:
After the eight rounds comes a final "half round", the output transformation
illustrated below:
An Encryption Round of IDEA
Bitwise eXclusive OR
(denoted with a blue
circled plus ⊕).
Addition modulo 216
(denoted with a green
boxed plus ⊞).
Multiplication
modulo
216+1, where the all-zero
word
(0x0000)
is
interpreted
as
216
(denoted by a red circled
dot ⊙).
International
Data Encryption Algorithm (IDEA)
After the eight rounds comes a final "half round", the output
transformation illustrated above:
IDEA: Key Schedule
Each round uses six 16-bit sub-keys, while the half-round uses four, a
total of 52 for 8.5 rounds. The first eight sub-keys are extracted directly
from the key, with K1 from the first round being the lower sixteen bits;
further groups of eight keys are created by rotating the main key left 25
bits between each group of eight. This means that it is rotated less than
once per round, on average, for a total of six rotations.
Blowfish
Blowfish is a keyed, symmetric block cipher, designed in 1993 by Bruce
Schneier and included in a large number of cipher suites and encryption
products. Blowfish provides a good encryption rate in software and no
effective cryptanalysis of it has been found to date. However, the Advanced
Encryption Standard now receives more attention.
Blowfish has a 64-bit block size and a variable key length from 32 up to 448
bits. It is a 16-round Feistel cipher and uses large key-dependent S-boxes. It
is similar in structure to CAST-128, which uses fixed S-boxes.
Blowfish
Feistel Structure
Round Function
Blowfish
The Feistel diagram shows the action of Blowfish. Each line represents 32 bits.
The algorithm keeps two subkey arrays: the 18-entry P-array and four 256-entry
S-boxes. The S-boxes accept 8-bit input and produce 32-bit output. One entry of
the P-array is used every round, and after the final round, each half of the data
block is XORed with one of the two remaining unused P-entries.
The F-function splits the 32-bit input into four eight-bit quarters, and uses the
quarters as input to the S-boxes. The outputs are added modulo 232 and XORed
to produce the final 32-bit output.
Decryption is exactly the same as encryption, except that P1, P2,..., P18 are used
in the reverse order. This is not so obvious because xor is commutative and
associative. A common mistake is to use inverse order of encryption as
decryption algorithm (i.e. first XORing P17 and P18 to the ciphertext block,
then using the P-entries in reverse order).
RC-2
In cryptography, RC2 is a block cipher designed by Ron Rivest in 1987.
"RC" stands for "Ron's Code" or "Rivest Cipher"; other ciphers designed by
Rivest include RC4, RC5 and RC6.
Block Cipher: 64 bit block
Number of rounds: 18 (16 MIXING + 2 MASHING)
Key Size: Variable. [8–128 bits, in steps of 8 bits; default 64 bits]
RC2 is vulnerable to a related-key attack using 234 chosen plaintexts (Kelsey
et al., 1997).
RC-2
The MIX transformation of
RC2;
four
of
these
comprise a MIXING round
RC-5
In cryptography, RC5 is a block cipher notable for its simplicity. Designed by
Ronald Rivest in 1994, RC stands for "Rivest Cipher", or alternatively, "Ron's
Code". The Advanced Encryption Standard (AES) candidate RC6 was based on
RC5.
Unlike many schemes, RC5 has a variable block size (32, 64 or 128 bits), key
size (0 to 2040 bits) and number of rounds (0 to 255). The original suggested
choice of parameters were a block size of 64 bits, a 128-bit key and 12 rounds.
RC-5
A key feature of RC5 is the use of data-dependent
rotations; one of the goals of RC5 was to prompt the
study and evaluation of such operations as a
cryptographic primitive. RC5 also consists of a
number of modular additions and eXclusive OR
(XOR)s. The general structure of the algorithm is a
Feistel-like network. The encryption and decryption
routines can be specified in a few lines of code. The
key schedule, however, is more complex, expanding
the key using an essentially one-way function with the
binary expansions of both e and the golden ratio as
sources of "nothing up my sleeve numbers". The
tantalising simplicity of the algorithm together with
the novelty of the data-dependent rotations has made
RC5 an attractive object of study for cryptanalysts.
The RC5 is basically denoted as RC5-w/r/b where
w=word size in bits, r=number of rounds, b=number
of 8-bit byte in the key.
One round (two half-rounds)
of the RC5 block cipher
Cast-128
CAST-128 is a 12- or 16-round Feistel network with a
64-bit block size and a key size of between 40 to 128
bits (but only in 8-bit increments). The full 16 rounds
are used when the key size is longer than 80 bits.
Components include large 8×32-bit S-boxes based on
bent functions, key-dependent rotations, modular
addition and subtraction, and XOR operations. There
are three alternating types of round function, but they
are similar in structure and differ only in the choice of
the exact operation (addition, subtraction or XOR) at
various points.
Three rounds of the CAST-128 block cipher
Characteristics of Advanced Symmetric
Block Ciphers
Variable
Mixed
Data
key length,
operators
dependent rotation
Key-dependent
rotation
Key-dependent
S-boxes
Lengthy
key scheduling algorithms
Variable
F
Variable
plaintext/ciphertext block length
Variable
number of rounds
Operation
on both halves of data
CONFIDENTIALITY USING
CONVENTIONAL ENCRYPTION
Home
Traffic Confidentiality
Knoweldge about the length and number of messages between nodes may
enable an Outsider to determine who is talking to whom.
Various types of information can be derived from a traffic analysis attack:
-Identities of Sender, Receiver, and associated parties
-How frequently Sender and Receiver are communicating
-Message pattern, message length, or quantity of messages
-Events that correlate with special conversations
Traffic patterns could also reveal elements of the Covert Channel being used
between Sender and Receivers.
Traffic Confidentiality
Traffic Confidentiality
Link Encryption Approach:
Packet Headers are encrypted
Still possible for Outsiders to assess the amount of traffic entering and leaving each end
system
When input plaintext is not present, random data are encrypted, making it possible for an
attacker to distinguish true data flow from padding, and thereby deduce the amount of traffic.
End-to-End Encryption Approach:
One technique is to pad out data units to a uniform length at either the transport of
application level.
Additionally, null values can be inserted randomly into the stream.
These tactics are designed to deny an Outsider knowledge about the amount of data
exchanged between users, and obsure underlying traffic patterns.
Key Distribution
For encryption to work over a network, the two parties
(Sender and Receiver) must exchange and share the same
keys, while protecting access to the keys from others.
A key could be selected by A and physically delivered to B.
A third party could select the key and physically deliver it to A and B.
If A and B have previously used a key, one party could transmit the new
key to the other, encrypted using the old key.
If A and B each have an encrypted connection to a third party C, C could
deliver a key on the encrypted links to A and B.
Symmetric Vs Asymmetric
Automatic Key Distribution for Connection Oriented Protocol
Automatic Key Distribution for Connection Oriented Protocol
(1) Host sends packet requesting connection.
(2) Front end buffers packet; asks KDC for sess key
(3) KDC distributes keys to both front-ends.
(4) Buffer packet transmitted.
(5) Terminology:
-FEP: Front-End Processor
-KDC: Key Distribution Center
-Session Key: Data encrypted with a one-time sess key. At the conclusion of the
sess, key is destroyed
-Permanent key: Used between entities for the purpose of distributing sess keys
Random Number Generation
•Use of random numbers (in cryptography)
–As key stream for a one-time pad
–For session keys
–For public key
–For nonces (random numbers) in protocols to prevent replays
–Good cryptography requires good random numbers
•Random number requirements
–Statistically random (uniform distribution, etc)
–Unpredictable (independent)
Random Number Generation
•Natural random noise (Natural real randomness)
–Radiation counters, radio noise, thermal noise in diodes, leaky capacitors,
mercury discharge tubes, etc
–Generally need special H/W for this
–Starting to see this in new CPU’s (Pentium III)
•Almost random sources
–Keystroke timing
–Mouse tracking
–Disk latency, etc
•Published lists
–e.g., Rand Co. in 1955 published a book of 1 million numbers generated using an
electronic roulette wheel
–Predictable
• In practice, pseudorandom numbers are algorithmically derived from a deterministic
PRNG (Pseudorandom Number Generator)
Pseudorandom Number Generation


Cyclic encryption
– Generate session keys from a master key
– A counter with period N is input to the encryption
logic
– e.g. 56-bit counter for 56-bit DES
– X0  X1  …  Xn-1
– Xi’s can not be deduced since the master key is
protected
– Full-period PRNG can be used instead of a simple
counter
DES OFB mode
– Can be used as a PRNG (IV is the seed)
– Successive 64-bit outputs constitute a sequence of
pseudorandom numbers with good statistical
properties
Email Security Enhancements




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)
Pretty Good Privacy (PGP)
Pretty Good Privacy (PGP)




It is an open source for email security.
It is developed by Phil Zimmermann
It incorporates tools for developing a public-key trust
model and public-key certificate management
It provides
–
–
–
–
–
Authentication (using digital signature)
Confidentiality (using symmetric block encryption)
Compression (using ZIP algorithm)
Compatibility (using radix-64 encoding scheme)
Segmentation & reassembly (for long emails)
Pretty Good Privacy (PGP): Features


Platform independent
PGP package includes
–
–
–


RSA, DSS, Diffie-Hellman (for public key encryption)
CAST-128, IDEA, 3DES (for symmetric encryption)
SHA-1 (for hash coding)
Flexibility to select & enforce a standardized
scheme for encryption
Recognizes standard (RFC 3156)
PGP Operation – Authentication
1.
2.
3.
4.
5.
sender creates message
use SHA-1 to generate 160-bit hash of message
signed hash with RSA using sender's private key, and is
attached to message
receiver uses RSA with sender's public key to decrypt and
recover hash code
receiver verifies received message using hash of it and
compares with decrypted hash code
PGP Operation – Confidentiality & Authentication

can use both services on same message
– create signature & attach to message
– encrypt both message & signature
– attach RSA/ElGamal encrypted session key
PGP Operation – Compression


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 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 Cryptographic Functions
Transmission and Reception of PGP
Messages
General format of PGP Messages
PGP Operation – Summary
PGP Session Keys



need a session key for each message
– of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit TripleDES
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, 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
PGP Key Rings


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
PGP Message Generation
PGP Message Reception
PGP Key Management





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
S/MIME
Secure/Multipurpose
Internet Mail
Extensions
S/MIME (Secure/Multipurpose Internet Mail Extensions)


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
RFC 822




defines a format for text messages to be sent using e-mail
Internet standard
structure of RFC 822 compliant messages
– header lines (e.g., from: …, to: …, cc: …)
– blank line
– body (the text to be sent)
example
Date: Tue, 16 Jan 1998 10:37:17 (EST)
From: “Levente Buttyan” <[email protected]>
Subject: Test
To: [email protected]
Blablabla
Problems with RFC 822 and SMTP



executable files must be converted into ASCII
– various schemes exist (e.g., Unix UUencode)
– a standard is needed
text data that includes special characters (e.g., Hungarian text)
some servers
– reject messages over a certain size
– delete, add, or reorder CR and LF characters
– truncate or wrap lines longer than 76 characters
– remove trailing white space (tabs and spaces)
– pad lines in a message to the same length
– convert tab characters into multiple spaces
MIME



defines new message header fields
defines a number of content formats (standardizing
representation of multimedia contents)
defines transfer encodings that protects the content
from alteration by the mail system
MIME - New header fields





MIME-Version
Content-Type
– describes the data contained in the body
– receiving agent can pick an appropriate method to represent the
content
Content-Transfer-Encoding
– indicates the type of the transformation that has been used to
represent the body of the message
Content-ID
Content-Description
– description of the object in the body of the message
– useful when content is not readable (e.g., audio data)
MIME – Content types and subtypes







text/plain, text/enriched
image/jpeg, image/gif
video/mpeg
audio/basic
application/postscript, application/octet-stream
multipart/mixed, multipart/parallel, multipart/alternative,
multipart/digest (each part is message/rfc822)
message/rfc822, message/partial, message/external-body
MIME – Transfer encodings

7bit
–

8bit
short lines of non-ASCII characters
binary
– non-ASCII characters
– lines are not necessarily short
quoted-printable
– non-ASCII characters are converted into hexa numbers (e.g., =EF)
base64 (radix 64)
– 3 8-bit blocks into 4 6-bit blocks
x-token
– non-standard encoding
–




short lines of ASCII characters
Delivered-To: [email protected]
Received: by 10.204.184.193 with SMTP id cl1csp161691bkb;
Sat, 7 Apr 2012 06:09:25 -0700 (PDT)
Received: by 10.220.79.134 with SMTP id p6mr622809vck.51.1333804164619;
Sat, 07 Apr 2012 06:09:24 -0700 (PDT)
Return-Path: <[email protected]>
Received: from mail-iy0-f170.google.com (mail-iy0-f170.google.com [209.85.210.170])
by mx.google.com with ESMTPS id hj4si4051548vdb.98.2012.04.07.06.09.23
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 07 Apr 2012 06:09:24 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected] designates 209.85.210.170 as permitted sender) client-ip=209.85.210.170;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 209.85.210.170 as permitted sender) [email protected]; dkim=pass
[email protected]
Received: by iaeh11 with SMTP id h11so4319198iae.15
for <[email protected]>; Sat, 07 Apr 2012 06:09:22 -0700 (PDT)
DomainKeys Identified Mail (DKIM) is a method for associating a
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
domain name to an email message.
d=gmail.com; s=20120113;
v: version
h=mime-version:date:message-id:subject:from:to:content-type;
a: signing algorithm
bh=K8R2aD7HufER5dJx+djgPQf/7ntxTjP/y3q8gYq2htM=;
b=WbNNuN4KLfNEFVEUWpBSkAofpqwe1/Op1IqFtDTmjK/c6hXBXFfPKG0O1LSQZGR++W
c: canonicalization algorithm(s) for header and body
Idf1bKHix4FLKSCr2VX0mHik8GdST3XMMvzPJh/EzDGHF9upkY1kPVufB4WTfBugWM3+
d: signing domain
aQDZvM1ALrz5w+rYnI3T5uyhv6CAMv123oRgI3kHPHrgQbIzNS9Wnne/WlimhWOXIyLg
s: selector
SGTtVpdremGGr0SWcEAsoAj17wqgXXzTyCWgNRdxFaMrizyHIxSIVFsxRXNrGbkoEvlq
b: actual digital signature of the contents (headers and body) of the
gPgrSuRiP9z9QXr5DifoxTdMAq7s9pOE5zoBxnDIhOGLNpCsszJsJ9DLTM9rU715D5RU
mail message
1euw==
bh: body hash
MIME-Version: 1.0
q: query method
Received: by 10.50.88.168 with SMTP id bh8mr907641igb.29.1333804162707; Sat,
07 Apr 2012 06:09:22 -0700 (PDT)
l: length of the canonicalized part of the body that has been signed
Received: by 10.42.141.3 with HTTP; Sat, 7 Apr 2012 06:09:22 -0700 (PDT)
t: signature timestamp
Date: Sat, 7 Apr 2012 18:39:22 +0530
x: expire time
Message-ID: <CAHMW_usQwMsRUZZP51N=x3hrdCt=2YBUT5ygvNKGnuNQiJQ+=w@mail.gmail.com>
h: list of signed header fields
Subject: Test
From: Hiren Patel <[email protected]>
To: [email protected]
Content-Type: multipart/alternative; boundary=e89a8f3ba55151727604bd167b53
--e89a8f3ba55151727604bd167b53
Content-Type: text/plain; charset=ISO-8859-1s: selector
b: actual digital signature of the contents (headers and body) of the mail message
bh: body hash
This is a test mail from [email protected] to [email protected]
--e89a8f3ba55151727604bd167b53
Content-Type: text/html; charset=ISO-8859-1
This is a test mail from <a href="mailto:[email protected]">[email protected]</a> to <a href="mailto:[email protected]">[email protected]</a><br>
MIME – Example
MIME-Version: 1.0
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed; boundary=unique-boundary-1
This is the preamble area of a multipart message. Mail readers that understand multipart format
should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader
that understands how to properly display multipart messages.
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
… Some text …
--unique-boundary-1
Content-type: text/enriched
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
This is <bold><italic>enriched.</italic></bold><smaller>as
defined in RFC 1896</smaller>
Isn’t it <bigger><bigger>cool?</bigger></bigger>
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
--unique-boundary-1
Content-Type: message/rfc822
... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ...
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
... base64-encoded image data goes here ...
--unique-boundary-1---unique-boundary-2--
S/MIME Functions/Services




enveloped data (application/pkcs7-mime; smime-type = enveloped-data)
– standard digital envelop
signed data (application/pkcs7-mime; smime-type = signed-data)
– standard digital signature (“hash and sign”)
– content + signature is encoded using base64 encoding
clear-signed data (multipart/signed)
– standard digital signature
– only the signature is encoded using base64
– recipient without S/MIME capability can read the message but
cannot verify the signature
signed and enveloped data
– signed and encrypted entities may be nested in any order
S/MIME Cryptographic Algorithms




message digest
– must: SHA-1
– should (receiver): MD5 (backward compatibility)
digital signature
– must: DSS
– should: RSA
asymmetric-key encryption
– must: ElGamal
– should: RSA
symmetric-key encryption
– sender:
 should: 3DES, RC2/40
– receiver:
 must: 3DES
 should: RC2/40
S/MIME / message formats
PKCS7 “signed data”
Version
(Set of) Digest Algorithms
Content type
Content Info
Content
Set of certificates
Version
Set of CRLs
Signer ID (issuer and ser. no.)
Digest Algorithm
Signer Info
Authenticated Attributes
Digest Encryption Alg.
Encrypted digest (signature)
S/MIME / message formats
PKCS7 “enveloped data”
Version
Originator Info
Version
Recipient ID (issuer and s.no.)
Recipient Info
Key Encryption Algorithm
Encrypted Key
Encrypted Content Info
Content type
Content Encryption Alg.
Encrypted Content
S/MIME / message formats
Enveloped data – Example
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
S/MIME / message formats
Clear-signed data – Example
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
This is a clear-signed message.
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--
S/MIME / key management


S/MIME certificates are X.509 conformant
key management scheme is between strict certification hierarchy and
PGP’s web of trust
–
–
–
certificates are signed by certification authorities (CA)
key authentication is based on chain of certificates
users/managers are responsible to configure their clients with a list of trusted
root keys
K
S/MIME Certificate Processing





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




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
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
IP Security
IP Security


The Internet community has developed applicationspecific 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.
IPSec



general IP Security mechanisms
provides
– Authentication (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)
– Confidentiality (enables communicating nodes to encrypt
messages to prevent eavesdropping by third parties)
– key management (is concerned with the secure exchange of
keys)
applicable to use over LANs, across public & private WANs, &
for the Internet
An IP Security Scenario
Benefits of IPSec






When IPSec is implemented in a firewall/router; it provides strong
security to all traffic crossing the perimeter
IPSec in a firewall/router is resistant to bypass
IPSec is below transport layer (TCP/UDP), hence transparent to
applications
IPSec can be transparent to end users
IPSec can provide security for individual users
IPSec secures routing architecture
IP Security Architecture




specification is quite complex
defined in numerous RFC’s
– incl. RFC 2401/2402/2406/2408
– many others, grouped by category
mandatory in IPv6, optional in IPv4
have two security header extensions:
– Authentication Header (AH)
– Encapsulating Security Payload (ESP)
IPSec Document Overview


Optional





Architecture: Covers the general concepts, security
requirements, definitions and mechanisms defining IPSec
technology.
Encapsulating Security Payload (ESP): Covers the packet
format and general issues related to the use of ESP for packet
encryption & optionally authentication.
Authentication Header (AH): Covers the packet format and
general issues related to the use of AH for packet
authentication.
Encryption Algorithm: A set of documents that describes
how various encryption algorithms are used for ESP.
Authentication Algorithm: A set of documents that
describes how various authentication algorithms are used for
AH and authentication option for ESP.
Key Management: Documents that describes the key
management schemes/
Domain of Interpretation (DOI): Contains values needed
for the other documents to relate each other. These include
identifiers for approved encryption
and authentication
algorithm; as well as operational parameters such as key
lifetime.
IPSec Services






Access control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
– a form of partial sequence integrity
Confidentiality (encryption)
Limited traffic flow confidentiality
Security Associations (SA)




It is a one-way relationship between sender & receiver that affords security
for traffic flow
SA is defined by 3 parameters:
• Security Parameters Index (SPI): A bit string assigned to this SA and
having local significance only.
• IP Destination Address: This is the address of the destination endpoint
of the SA (E.g. firewall/router).
• Security Protocol Identifier: This indicates whether the association is
an AH or ESP security association.
has a number of other parameters
– Sequence number counter, Sequence counter overflow, Anti-replay
window, AH information, ESP information, Lifetime of this SA, IPSec
protocol mode, Path MTU
have a database of Security Associations
Tunnel Mode Vs Transport Mode
Transport Mode SA
AH
Tunnel Mode SA
Authenticates IP payload and Authenticates entire inner IP
selected portions of IP header packet (inner header + payload)
& IPv6 ext. headers.
PLUS selected portion of outer IP
header & outer IPv6 ext. headers.
ESP
Encrypts IP payload & any Encrypts entire inner IP packet.
(Without
IPv6 ext. headers following
Authentication) the ESP headers.
ESP
Encrypts IP payload & any Encrypt
entire
IP
packet.
(with
IPv6 ext. headers following Authenticates inner IP packet.
Authentication) the
ESP
headers.
Authenticates IP payload but
not IP header.
Authentication Header (AH)

The Authentication Header provides support for data integrity and
authentication of IP packets.
– The data integrity feature ensures that undetected modification to a
packet’s content in transit is not possible.
– The authentication feature enables an end system or network device
to authenticate the user or application and filter traffic accordingly; it
also prevents address spoofing attacks and replay attacks.
– Authentication is based on the use of a message authentication code
(MAC), hence the two parties must share a secret key. AH supports
MACs using HMAC-MD5-96 or HMAC-SHA-1-96. Both of these
use the HMAC algorithm , the first with the MD5 hash code and the
second with the SHA-1 hash code.
Authentication Header
• Next Header (8 bits): Identifies the type of header immediately following this header
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2. (In
above example, six-32 bit words, so payload length=6-2=4)
• Reserved (16 bits): For future use
• Security Parameters Index (32 bits): Identifies a security association
• Sequence Number (32 bits): A monotonically increasing counter value
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value (ICV), or MAC, for this packet.
Transport & Tunnel Modes
Scope of AH Authentication
IP Payload is a TCP segment.
AH for Transport Mode (IPv4): AH is inserted
after the original IP header and before the IP
payload (TCP segment). Authentication covers
the entire packet, excluding the mutable fields
in IPv4 header that are set to zero for MAC
calculations.
AH for Transport Mode (IPv6): AH is viewed
as an end-to-end payload, that is, it is not
examined or processed by intermediate routers.
Therefore, the AH appears after the IPv6 base
header and the hop-by-hop, routing and
fragment extension headers.
AH for Tunnel Mode (IPv4): The entire original
IP packet is authenticated and the AH is
inserted between the original IP header and the
new outer IP header. The inner IP header carries
the ultimate source and destination addresses
while the outer IP header may contain different
IP addresses (e.g. firewall/gateways).
AH for Tunnel Mode (IPv6): The entire IP
packet, including the inner IP header, is
protected by AH. The outer IP header is
protected except for mutable and unpredictable
fields.
Encapsulating Security Payload (ESP)



provides message content confidentiality & limited traffic flow
confidentiality
can optionally provide the same authentication services as AH
supports range of ciphers, modes, padding
– incl. DES, Triple-DES, RC5, IDEA, CAST etc
– CBC & other modes
– padding needed to fill blocksize, fields, for traffic flow
Encapsulating Security Payload
• Security Parameters Index (32 bits): Identifies a security association
• Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function ,as
discussed for AH
• 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): Indicates the number of pad bytes immediately preceding this field
• Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first
header in that payload
• Authentication Data (variable): A variable-length field that contains the Integrity Check Value computed over
the ESP packet minus the Authentication Data field
Transport vs Tunnel Mode ESP


transport mode is used to encrypt & optionally authenticate IP data
– data protected but header left in clear
– 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
– good for VPNs, gateway to gateway security
(a) Transport-level security
(b) A virtual private network via tunnel mode
Scope of ESP Encryption & Authentication
Transport mode ESP is used to encrypt and optionally authenticate the
data carried by IP (E.g. TCP segment).
Transport mode ESP for IPv4: The ESP header is inserted into the IP
packet immediately before the transport layer header (TCP/UDP) and
an ESP trailer (padding, pad length & next header fields) is placed after
the IP packet. If authentication is selected, the ESP authentication data
field is added after ESP trailer. The entire transport-level segment plus
the ESP trailer are encrypted.
Transport mode ESP for IPv6: ESP is viewed as an end-to-end
payload.; that is, it is not examined or processed by immediate router.
Therefore ESP header appears after the IPv6 base header and the hopby-hop, routing, and fragment extension headers.
Tunnel mode ESP is used to encrypt the entire IP packet.
Combining Security Associations



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
issue of authentication & encryption order
Combining Security Associations
Key Management




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




a key exchange protocol
based on Diffie-Hellman key exchange
adds features to address weaknesses
– cookies, groups (global params), nonces, DH key exchange with
authentication
can use arithmetic in prime fields or elliptic curve fields
ISAKMP




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
ISAKMP
ISAKMP Payloads & Exchanges


have a number of ISAKMP payload types:
– Security, Proposal, Transform, Key, Identification, Certificate,
Certificate, Hash, Signature, Nonce, Notification, Delete
ISAKMP has framework for 5 types of message exchanges:
– base, identity protection, authentication only, aggressive,
informational
Web Security
Web Security




Secure Socket Layer (SSL) provides security services between TCP
and applications that uses TCP. The Internet standard version is called
Transport Layer Service (TLS).
SSL/TLS provides confidentiality (using symmetric encryption) and
message integrity (using MAC).
SSL/TLS includes protocol mechanism , to enable two TCP users to
determine the security mechanisms and service they will use.
Secure Electronic Transaction (SET) is an open encryption and
security specification designed to protect credit card transactions on the
Internet.
SSL (Secure Socket Layer)






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
SSL is not a single protocol but rather two layers of protocols.
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 higherlayer 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.
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.
SSL Record Protocol Services



SSL Record Protocol defines two services for SSL connections:
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: 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.
SSL Record Protocol Operation
SSL Record Format
Content Type: The higher layer
protocol used to process the enclosed
fragment. (change_cipher_spec, alert,
handshake, application_data)
Version Number: Major and Minor
version for SSL. (E.g. SSLv3,
Major=3, Minor=0)
Compressed Length: The length in
bytes of plaintext fragment.
Maximum value is 214+2048
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. Its purpose is to cause the pending state to be copied into the current
state, which updates the cipher suite to be used on this connection.
SSL Alert Protocol




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


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
1.
Establish Security Capabilities
2.
Server Authentication and Key Exchange
3.
Client Authentication and Key Exchange
4.
Finish
SSL
Handshake
Protocol
TLS (Transport Layer Security)


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
– has additional alert codes
– some changes in supported ciphers
– changes in certificate types & negotiations
– changes in crypto computations & padding
TLS (Transport Layer Security)
Content Type: The higher layer
protocol used to process the enclosed
fragment. (change_cipher_spec, alert,
handshake, application_data)
Version Number: Major and Minor
version for SSL. (E.g. SSLv3,
Major=3, Minor=0)
Compressed Length: The length in
bytes of plaintext fragment.
Maximum value is 214+2048
Secure Electronic Transactions (SET)





open encryption & security specification
to protect Internet credit card transactions
developed in 1996 by Mastercard, Visa etc
not a payment system
rather a set of security protocols & formats
– secure communications amongst parties
– trust from use of X.509v3 certificates
– privacy by restricted info to those who need it
SET Components
SET Transaction
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
customer opens account
customer receives a certificate
merchants have their own certificates
customer places an order
merchant is verified
order and payment are sent
merchant requests payment authorization
merchant confirms order
merchant provides goods or service
merchant requests payment
Dual Signature




customer creates dual messages
– order information (OI) for merchant
– payment information (PI) for bank
neither party needs details of other
but must know they are linked
use a dual signature for this
– signed concatenated hashes of OI & PI
DS=E(PRc, [H(H(PI)||H(OI))])
SET Purchase Request

SET purchase request exchange consists of four messages
1.
Initiate Request - get certificates
2.
Initiate Response - signed response
3.
Purchase Request - of OI & PI
4.
Purchase Response - ack order
Purchase Request – Customer
Purchase Request – Merchant
1.
2.
3.
4.
verifies cardholder certificates using CA sigs
verifies dual signature using customer's public signature key to ensure
order has not been tampered with in transit & that it was signed using
cardholder's private signature key
processes order and forwards the payment information to the payment
gateway for authorization (described later)
sends a purchase response to cardholder
Purchase Request – Merchant
Payment Gateway Authorization
1.
2.
3.
4.
5.
6.
7.
8.
verifies all certificates
decrypts digital envelope of authorization block to obtain symmetric
key & then decrypts authorization block
verifies merchant's signature on authorization block
decrypts digital envelope of payment block to obtain symmetric key &
then decrypts payment block
verifies dual signature on payment block
verifies that transaction ID received from merchant matches that in PI
received (indirectly) from customer
requests & receives an authorization from issuer
sends authorization response back to merchant
Payment Capture




merchant sends payment gateway a payment capture request
gateway checks request
then causes funds to be transferred to merchants account
notifies merchant using capture response
Firewalls
Firewalls - Introduction







seen evolution of information systems
now everyone want to be on the Internet
and to interconnect networks
has persistent security concerns
– can’t easily secure every system in org
typically use a Firewall
to provide perimeter defence
as part of comprehensive security strategy
What is a 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 and 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 Network Address Translation - 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.

Firewall Limitations
Firewalls have their limitations, including that they:
1. cannot protect against attacks that bypass the firewall, eg PCs with dialout 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. cannot protect against the transfer of virus-infected programs or files,
given wide variety of O/S & applications supported

Firewalls – Packet Filters





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
Firewalls – Packet Filters
Figure illustrates the packet filter firewall placement in the border router, on the
security perimeter, between the external less-trusted Internet, and the internal
more trusted private network.
Firewalls – Packet Filters
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.
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. 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.
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.
Firewalls - Application Level
Gateway (or Proxy)
Figure illustrates an application-level gateway (or proxy server), emphasizing
that it only supports a specific list of application services.
Firewalls - Circuit Level Gateway


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.
Firewalls - Circuit Level Gateway
Figure 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.
Bastion Host

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 is allowed access to the proxy services
is configured to support only a subset of the standard application’s command set, with access
only to specific hosts
maintains detailed audit information by logging all traffic
has each proxy module a very small software package specifically designed for network
security
has each proxy independent of other proxies on the bastion host
have a proxy performs no disk access other than to read its initial configuration file
have each proxy run as a nonprivileged 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.
Firewall Configurations
Figure 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.
Firewall Configurations
Figure 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.
Firewall Configurations
Figure shows the “screened subnet firewall configuration”, being the most secure shown. It has two packetfiltering 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
Access Control




given system has identified a user
determine what resources they can access
general model is that of access matrix with
– subject - active entity (user, process)
– object - passive entity (file or resource)
– access right – way object can be accessed
can decompose by
– columns as access control lists
– rows as capability tickets
Access Control Matrix
Trusted Computer Systems





information security is increasingly important
have varying degrees of sensitivity of information
– cf military info classifications: confidential, secret etc
subjects (people or programs) have varying rights of access to objects
(information)
known as multilevel security
– subjects have maximum & current security level
– objects have a fixed security level classification
want to consider ways of increasing confidence in systems to enforce
these rights
Bell LaPadula (BLP) Model





one of the most famous security models
implemented as mandatory policies on system
has two key policies:
no read up (simple security property)
– a subject can only read/write an object if the current security level of
the subject dominates (>=) the classification of the object
no write down (*-property)
– a subject can only append/write to an object if the current security
level of the subject is dominated by (<=) the classification of the
object
Reference Monitor
Figure illustrates the reference monitor as a controlling element in the h/w & O/S of a computer. It regulates access of
subjects to objects on the basis of their security parameters. It has access to the security kernel database, which lists
the access privileges (security clearance) of each subject & the protection attributes (classification level) of each
object. The reference monitor enforces the security rules (no read up, no write down). It must have properties of:
• Complete mediation: security rules are enforced on every access
• Isolation: reference monitor & database are protected from unauthorized modification
• Verifiability: reference monitor’s correctness must be provable
These are stiff requirements, usually met only by a trusted system.
Evaluated Computer Systems




governments can evaluate IT systems
against a range of standards:
– TCSEC, IPSEC and now Common Criteria
define a number of “levels” of evaluation with increasingly stringent
checking
have published lists of evaluated products
– though aimed at government/defense use
– can be useful in industry also
Common Criteria



international initiative specifying security requirements & defining
evaluation criteria
incorporates earlier standards
– eg CSEC, ITSEC, CTCPEC (Canadian), Federal (US)
specifies standards for
– evaluation criteria
– methodology for application of criteria
– administrative procedures for evaluation, certification and
accreditation schemes
Common Criteria




defines set of security requirements
have a Target Of Evaluation (TOE)
requirements fall in two categories
– functional
– assurance
both organised in classes of families & components
Common Criteria Requirements


Functional Requirements
– security audit, crypto support, communications, user data
protection, identification & authentication, security management,
privacy, protection of trusted security functions, resource
utilization, TOE access, trusted path
Assurance Requirements
– configuration management, delivery & operation, development,
guidance documents, life cycle support, tests, vulnerability
assessment, assurance maintenance
Common Criteria
The CC also defines two kinds of documents that can be generated using the CC-defined
requirements
• Protection profiles (PPs): define an implementation-independent reusable set of security
requirements and objectives for a category of products or systems that meet similar
consumer needs for IT security, reflecting user security requirements
• Security targets (STs): contain the IT security objectives and requirements of a specific
identified TOE and defines the functional and assurance measures offered by that TOE to
meet stated requirements, and forms the basis for an evaluation
Stallings Figure 20.6 illustrates the relationship between requirements and profiles and
targets.
Common Criteria
Figure shows the security functional requirements paradigm. It is based on the
reference monitor concept but makes use of the terminology and design
philosophy of the CC.