Information Security

Dr. Uma Godase

Computer Science and Engineering
MIT School of Engineering
 Web Security Approaches

▪ To use IPSec: (At Network Level)

▪ Provides a general purpose solution.
▪ Transparent to end users and applications.
▪ IPSec Filtering capability: only selected traffic need incur
the overhead of IPSec processing.
▪ Implement Just above TCP:
▪ Provides a general purpose solution. e.g.: SSL/TLS.
▪ As a part of underlying protocol suite, it is transparent to
the applications.
▪ SSL can also be embedded in applications. (Explorer
browsers are equipped with SSL.)
 Web Security Approaches

▪ Application Level:
▪ Security services are embedded within an application.
▪ Security service can be tailored for specific needs of an
application.
▪ Example: Secure Electronic Transaction (SET).
 IPSec
▪ general IP Security mechanisms
▪ provides
▪ Authentication(signatures and Certificates)
▪ Confidentiality (Encryption)
▪ key management
▪ does not provide a key exchange mechanism.
▪ applicable to use over LANs, across public &
private WANs, & for the Internet
▪ Key points of IPSec:
▪ Two modes of propagation (transport and tunnel)
▪ Security associations (SAs)
▪ Two types of header (ESP and AH)
 IPSec
▪ IPSec features are implemented in the form of
additional IP headers called as extension headers.
▪ 2 extension headers – one for authentication and one
for confidentiality
 IPSec
▪ IPsec: Building a Connection
▪ Internet Key Exchange
▪ Used for key management
▪ Used to negotiate the cryptographic algorithms to be later used in
actual operation.
▪ IPSec
▪ Security associations are negotiated on behalf of IPsec services.
 IPSec
▪ IPSec Security Association
▪ Security Association(SA) :a one-way relationship between
sender & receiver that affords security for traffic flow
▪ Before communication starts , 2 parties should establish
Security Association with each other
▪ SA is the output of IKE phase.
▪ If two parties communicate using both protocols in IPSec,
each party requires 2 sets of SA (one per protocol)
▪ SA is simplex i.e. unidirectional , hence one SA for
incoming & one for outgoing transmission is needed.
▪ Security Association Database(SAD) : storage area for
storing the SA information at each party.
 IPSec
▪ Transport and Tunnel Modes
▪ Transport mode:
▪ used to encrypt & optionally authenticate IP data
▪ data is encrypted but header left in clear i.e. does not
hide the actual source & destination address.
▪ can do traffic analysis but is efficient
▪ good for ESP host to host traffic
▪ Tunnel mode:
▪ encrypts entire IP packet
▪ A logical encrypted tunnel is established between 2
hosts.
▪ add new header for next hop
▪ good for VPNs, gateway to gateway security
External IP
header(not Internal IP data
encrypted) header
 Transport and Tunnel Modes
Transport Mode

Router Router

Tunnel Mode

Encrypted Tunnel
Gateway 1 Gateway 2

Encrypted
A B

New IP AH or ESP Orig IP TCP Data

Header Header Header
 Various Packets

Original IP header TCP header data

Transport IP header IPSec header TCP header data

mode

Tunnel
IP header IPSec header IP header TCP header data
mode
 IPSec Protocols

Two protocols in IPSes:

• Authentication Header Protocol (AH)
• Encapsulation Security Payload (ESP)

ESP AH

Encapsulating Security Authentication Header

Payload
IPSec Security Policy

IKE

Internet Key Exchange

Authentication Header (AH)
 Authentication Header (AH)
• Provides support for data integrity & Authentication of IP
packets.
Field Description
Next Header 8 bit field which identifies the type of header that
follows AH.
Payload length 8 bit field which contains the length of AH in 32 bit
words minus 2.
Reserved 16 bit field reserved for future use.
Security Parameter Index(SPI) 32 bit field used in combination with source address,
destination address & IPSec protocol(AH/ESP) to
uniquely identify the SA for the traffic to which a
datagram belongs.
Sequence Number 32bit field used to prevent replay attacks.
Authentication Data Variable length field that contains authentication data
called as Integrity Check Value(ICV). ICV is MAC
used for authentication & Integrity .
For IPv4 – value of ICV is multiple of 32
For IPv6 – value of ICV is multiple of 64
AH Transport & Tunnel Mode
Before Applying AH

IP header TCP header Data

After Applying AH

IP header AH TCP header Data

AH Transport Mode

New IP OriginalIP
AH TCP header Data
header Header

AH Tunnel Mode
 Dealing with Replay Attack
Marked if a Unmarked if a
valid packet is valid packet is not
N-W received N
yet received

Receiver’s Sliding Window(W=8)

▪ W – size of the window

▪ N – maximum highest sequence number so far
received for a valid packet
 Dealing with Replay Attack
▪ If sequence number of the received packet falls within
window & packet is new - its MAC is checked. If MAC is
successfully validated, the corresponding slot in the
window is marked. The window does not move to the right
hand side.
▪ If sequence number of the received packet falls to the
right of the window & packet is new – MAC is checked.
If packet is authenticated successfully, the window is
advanced to the right such that right edge of the window
matches with the sequence number of this packet.
▪ If sequence number of the received packet falls to the
left of the window or if the MAC check fails – Packet is
rejected & audible event is triggered.
Encapsulating Security Payload(ESP)
 Encapsulating Security Payload(ESP)

Field Description
Security Parameter Index(SPI) 32 bit field used in combination with source address,
destination address & IPSec protocol(AH/ESP) to
uniquely identify the SA for the traffic to which a
datagram belongs.
Sequence Number 32bit field used to prevent replay attacks.
Payload Data Variable length field that contains transport layer
segment (transport mode) or IP packet (tunnel mode),
which is protected by encryption.
Padding Padding bits
Padding length 8 bits field that specifies number of padding bytes in the
immediately preceding field.
Next Header 8 bit field which identifies the type of encapsulated data
in the payload.
Authentication Data Variable length field containing authentication data called
as Integrity Check Value(ICV). ICV is calculated
over the length of ESP packet minus Authentication Data
Field.
 ESP Transport & Tunnel Mode
Before Applying ESP

IP header TCP header Data

After Applying ESP

Original ESP
TCP header Data ESP trailer ESP auth
IP Header header

ESP Transport Mode

Original TCP
New IP ESP ESP trailer ESP auth
IP header Data
header header
header
ESP Tunnel Mode
 IPSec Advantages
• Transparent to the end user so no user training , key
issuance/revocation needed.
• Works at network layer hence no changes to upper
layer are needed.
• Allows interconnectivity between offices in a very
inexpensive manner.
• Allows traveling staff to access corporate network
securely.
• When it is implemented in a firewall, all outgoing &
incoming traffic gets protected but internal traffic
does not have to use IPSec. Hence it does not add
overhead for the internal traffic.
 Secure Socket Layer (SSL)

▪ SSL is a communications protocol layer which can be

placed between TCP/IP and HTTP
▪ It intercepts web traffic and provides security between
browser and server
▪ Encryption is used to guarantee secure communication in
an insecure environment
▪ All security operations are transparent at both ends of the
communication
▪ SSL uses public-key cryptography
 Secure Socket Layer (SSL)
▪ Implements three cryptographic assurances:
▪ Authentication.
▪ Confidentiality.
▪ Message integrity.
▪ Also provides secure key exchange between a browser
(client) and server.
▪ Provides security parameters negotiation.
▪ Does not offer non-repudiation.
 Position of SSL in TCP/IP
X Y

L5 Data Application L5 Data

L5 Data SH SSL L5 Data SH

L5 Data H4 Transport L5 Data H4

L4 Data H3 Internet L4 Data H3

L3 Data H2 Data Link L3 Data H2

0101010101100111000 Physical 0101010101100111000

 How SSL Works
Sub-protocols :
▪ Handshake Protocol
▪ Record Protocol
▪ Alert Protocol
 Handshake Protocol

▪ First sub protocol used by the client and server to

communicate using an SSL – enabled connection.
▪ Allows the server and client to
▪ - authenticate each other.
▪ - negotiate encryption, MAC algorithm and
▪ cryptographic keys.
▪ Used before any application data are transmitted. Format
of handshake protocol messages

Type Length Content

1 byte 3 bytes 1 or more bytes

 Handshake Protocol
▪ Type : indicates one of the ten possible messages.
Message Type Parameters
Hello request None
Client hello Version, Random number, Session id, Cipher suite,
Compression method
Server hello Version, Random number, Session id, Cipher suite,
Compression method
Certificate Chain of X.509 V3 certificates
Server key exchange Parameters, signature
Certificate request Type, authorities
Server hello done None
Certificate verify Signature
Client key exchange Parameters, signature

Finished Hash value

▪ Length : indicates length of the message in bytes.
▪ Content : contains parameters associated with this
 SSL Handshake Phases
▪ comprises a series of messages in phases

1. Establish Security Capabilities

2. Server authentication & key exchange
Web 3. Client authentication & key exchange Web
Browser 4. Finish Server
Handshake Protocol
Phase 1 - Establish Security Capabilities
▪ Initiate a logical connection & establishes the security
capabilities associated with that connection.
▪ Two messages:
1. Client Hello: Parameters are as follows
▪ Version – highest version of SSL that the client can support.
▪ Random – 32 bit current system date-time on the client
computer & 28 byte random number at client side.
▪ Session id – variable length session id which contains zero
if client creates a new connection with the server & nonzero
if client wants to update the parameters of existing
connection.
▪ Cipher suite - list of the cryptographic algorithms
supported by the client
▪ Compression method - list of the compression algorithms
Phase 1 - Establish Security Capabilities

2. Server Hello :
▪ Version – lower of the version suggested by the client and
the highest supported by the server.
▪ Random – same as random field of the client but random
value is independent of client’s random value.
▪ Session id – If session id sent by client is nonzero, server
uses the same value. Otherwise server creates a new session
id & puts in this field.
▪ Cipher suite – contains a single cipher suite, which is
selected by the server from the list sent by the client.
▪ Compression method - contains a single compression
algorithm, which is selected by the server from the list sent
by the client.
Phase 2 - Server authentication & key exchange

▪ Server initiates this phase & is the sole sender of all the
messages.
Steps :
1. Certificate – Server sends its digital certificate &
entire chain leading up to root CA to the client.
2. Server Key Exchange (optional) – Server sends its
public key to the client. It is used only if the server
does not send its digital certificate to the client in
step1.
3. Certificate Request (optional) – Server can request
for the client’s digital certificate.
4. Server hello done – indicates to the client that its
portion of the hello message is complete.
Phase 3 – Client authentication & key exchange
▪ Client initiates this phase & is the sole sender of all the
messages.
Steps :
1. Certificate(Optional) – This step is performed only if
server had requested for client’s digital certificate.
2. Client Key Exchange (optional) – Client sends
symmetric key that both parties will use in this session to
the server. It also creates a 48 byte pre master secret ,
encrypts it with server’s public key & send to it to the
server.
3. Certificate Verify (optional)– performed only if server
had demanded client authentication. Client combines the
pre master secret with random number exchanged by the
client & server after hashing them together and signs the
result with its private key.
 Phase 4 – Finish
▪ Client initiates this phase which the server ends .
▪ Both client & server create a master secret based on the
pre master secret.
▪ Both client & server generate shared secret key known
only to them.
Steps :
1. Change cipher specs – It is a confirmation from the
client that all is well.
2. Finished
3. Change cipher specs – It is a confirmation from the
server that all is well.
4. Finished
Phase 4 – Master Secret & Symmetric Key Generation
▪ Master secret generation :
Pre-master secret Client random Server random

Message Digest Algorithm

Master secret

▪ Symmetric Key generation :

Master secret Client random Server random

Message Digest Algorithm

Symmetric Key
 SSL Record Protocol

▪ Record protocol is performed after a successful

handshake protocol is completed between the client
and the server.
▪ Provides two services for SSL connections:
1. Confidentiality - achieved by using the shared
secret key defined by the handshake protocol.
2. Message Integrity - A shared secret key is used
to construct a message authentication code.
SSL Record Protocol - Operation
 SSL Record Protocol - Operation
▪ Record protocol takes an application message as input &
performs following steps on it
1. Fragmentation – Input message is broken into blocks of
size less than or equal to 214 bytes.
2. Compression –Fragmented blocks are optionally
compressed by using lossless compression mechanism.
3. Addition of MAC – Using the shared secret key , Message
Authentication Code(MAC) for each block is calculated.
4. Encryption – Using the symmetric key , output of previous
step is encrypted. Permitted SSL encryption algorithms are
RC$, AES, IDEA, RC2, DES, DES-3, Fortezza.
5. Append Header –
 SSL Record Protocol - Operation
5. Append Header – Header is added to the encrypted
block.
Fields of header :
▪ Content type (8 bits) – specifies the protocol used for
processing the record in the next higher level(e.g.
handshake, alert)
▪ Major version (8 bits) – specifies major version of SSL
in use. e.g. if SSL version is 3.1 , major version is 3.
▪ Minor version (8 bits) – specifies minor version of SSL
in use. e.g. if SSL version is 3.1 , minor version is 1.
▪ Compressed length (16 bits) – specifies the length in
bytes of the original plain text block or compressed
block.
 SSL Record Protocol - Operation

▪ Final output of SSL record protocol

Content type Major Version Minor Version Compressed length

E
n
cr
y Plain text (optionally compressed)
pt
e
d

MAC ( 0, 16 or 20 bytes)
 SSL Alert Protocol

▪ When either client or server detects an error ,

detecting party conveys SSL-related alerts to peer
entity.
▪ severity
▪ warning – Parties handle the error and continue.
▪ fatal - both parties immediately close the SSL
connection , destroy session identifiers & keys
associated with the connection.
▪ Alert protocol message format
Severity Cause
• Byte 1 byte 2
 SSL Alert Protocol

▪ Some specific alerts

Fatal alerts Non - fatal alerts

unexpected message no certificate
bad record MAC bad certificate
decompression failure unsupported certificate
handshake failure certificate revoked
illegal parameter certificate expired

certificate unknown
close notify
Transport Layer Security (TLS)
▪ TLS Handshake
 Transport Layer Security (TLS)
▪ TLS Handshake
▪ With a TLS enabled service, a sender sends a ClientHello. This includes
information about Client.
▪ Then server responds with ServerHello message (selecting highest
version of TLS supported by Client) and then chooses a cipher suite
from list in ClientHello message. The server also transmits its Digital
certificate and a final ServerHelloDone message.
▪ Client validates certificate. Client then sends ClientKeyExchange
message. Here client chooses a key exchange mechanism to securely
establish a shared secret with server. Client also needs to send
ChangeCipherSpec indicating that it is switching to secure
communication now, which is finally followed by Finished message for
indicating a successful handshake.
▪ Server replies with ChangeCipherSpec and an encrypted Finished
message once shared secret is received.
▪ Session key is Shared Symmetric Encryption Key used in TLS sessions
to encrypt data being sent back and forth.
 Transport Layer Security (TLS)
▪ Difference between SSL and TLS

SSL TLS

SSL stands for Secure Socket Layer. TLS stands for Transport Layer Security.

SSL supports the Fortezza algorithm. TLS does not support the Fortezza algorithm.

SSL is the 3.0 version. TLS is the 1.0 version.

In TLS, a Pseudo-random function is used to create a master

In SSL, the Message digest is used to create a master secret.
secret.

In SSL, the Message Authentication Code protocol is used. In TLS, Hashed Message Authentication Code protocol is used.

SSL is more complex than TLS(Transport Layer Security). TLS is simple.

SSL is less secured as compared to TLS(Transport Layer

TLS provides high security.
Security).

SSL is less reliable and slower. TLS is highly reliable and upgraded. It provides less latency.

SSL has been depreciated. TLS is still widely used.

 Pretty Good Privacy (PGP)
Provides a confidentiality and authentication service that can be
used for electronic mail and file storage applications
Developed by Phil Zimmermann
◦ Selected the best available cryptographic algorithms as
building blocks
◦ Integrated these algorithms into a general-purpose
application that is independent of operating system and
processor and that is based on a small set of easy-to-use
commands
◦ Made the package and its documentation, including the
source code, freely available via the Internet, bulletin
boards, and commercial networks
◦ Entered into an agreement with a company to provide a
fully compatible, low-cost commercial version of PGP
 PGP Growth

It is available free worldwide in versions that run on a variety of

platforms

The commercial version satisfies users who want a product that comes
with vendor support

It is based on algorithms that have survived extensive public review

and are considered extremely secure

It has a wide range of applicability

It was not developed by, nor is it controlled by, any governmental or

standards organization

Is now on an Internet standards track, however it still has an aura of

an antiestablishment endeavor
Summary of PGP Services
PGP Cryptography Function
 PGP Authentication
Combination of SHA-1 and RSA provides an effective
digital signature scheme
◦ Because of the strength of RSA the recipient is assured
that only the possessor of the matching private key can
generate the signature
◦ Because of the strength of SHA-1 the recipient is
assured that no one else could generate a new message
that matches the hash code

◦ As an alternative, signatures can be generated using

DSS/SHA-1

◦ Detached signatures are supported

◦ Each person’s signature is independent
 PGP Confidentiality
Provided by encrypting messages to be transmitted or to be
stored locally as files
◦ In both cases the symmetric encryption algorithm CAST-
128 may be used
◦ Alternatively IDEA or 3DES may be used
◦ The 64-bit cipher feedback (CFB) mode is used
◦ As an alternative to the use of RSA for key encryption,
PGP uses ElGamal, a variant of Diffie-Hellman that
provides encryption/decryption
In PGP each symmetric key is used only once

• Although referred to as a session key, it is in reality a one-

time key
• Session key is bound to the message and transmitted with it
• To protect the key, it is encrypted with the receiver’s public
key
 PGP Confidentiality and Authentication

Both services may be used for the same message

◦ First a signature is generated for the plaintext message
and prepended to the message
◦ 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)
When both services are used:
The sender first And finally encrypts
Then encrypts the
signs the message the session key with
message with a
with its own private the recipient’s public
session key
key key
 PGP Compression
As a 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 placement of the compression algorithm is critical
 Applying the hash function and signature after
compression would constrain all PGP implementations
to the same version of the compression algorithm
 Message encryption is applied after compression
to strengthen cryptographicsecurity
◦ The compression algorithm used is ZIP
 PGP E-mail Compatibility
Many electronic mail systems only permit the use of blocks
consisting 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
◦ The scheme used for this purpose is radix-64 conversion
 Each group of three octets of binary data is mapped into
four ASCII characters
 This format also appends a CRC to detect transmission
errors
Transmission and Reception of PGP Messages
Secure/Multipurpose Internet Mail Extension
(S/MIME)

A security enhancement to the MIME Internet e-mail

format standard based on technology from RSA Data
Security
Defined in:
◦ RFCs 3370, 3850, 3851, 3852
 RFC 5322
Defines a format for text messages that are sent using
electronic mail
Messages are viewed as having an envelope and contents
◦ The envelope contains whatever information is needed to
accomplish transmission and delivery
◦ The contents compose the object to be delivered to the
recipient
◦ RFC 5322 standard applies only to the contents
The content standard includes a set of header fields that may
be used by the mail system to create the envelope
 Multipurpose Internet Mail Extensions
(MIME)
MIME specification includes the following elements:
 An extension to the RFC 5322
framework that is intended to
address some of the problems
and limitations of the use of Transfer Five new message
Simple Mail Transfer Protocol encodings are header fields are
defined that defined, which
(SMTP) may be included
enable the
◦ Is intended to resolve these conversion of any in an RFC 5322
problems in a manner that is content format header; these
compatible with existing into a form that is fields provide
protected from information about
RFC 5322 implementations the body of the
alteration by the
◦ The specification is mail system message
provided in RFCs 2045
through 2049
A number of content
formats are defined, thus
standardizing
representations that
support multimedia
electronic mail
 The Five Header Fields Defined in
MIME
MIME-Version

• Must have the parameter value 1.0

• This field indicates that the message conforms to RFCs 2045 and 2046

Content-Type

• Describes the data contained in the body with sufficient detail that the receiving user agent can
pick an appropriate agent or mechanism to represent the data to the user or otherwise deal with
the data in an appropriate manner

Content-Transfer-Encoding

• Indicates the type of transformation that has been used to represent the body of the message in
a way that is acceptable for mail transport

Content-ID

• Used to identify MIME entities uniquely in multiple contexts

Content-Description

• A text description of the object with the body; this is useful when the object is not readable
MIME Content Types
MIME Transfer Encodings
Native and Canonical Form
 S/MIME Functionality

Enveloped data Signed data

• Consists of encrypted content of any type • A digital signature is formed by taking the
and encrypted content encryption keys for message digest of the content to be signed
one or more recipients and then encrypting that with the private key
of the signer
• The content plus signature are then encoded
using base64 encoding
• A signed data message can only be viewed by
a recipient with S/MIME capability

S/MIME

Clear-signed data Signed and enveloped data

• Only the digital signature is encoded using • Signed-only and encrypted-only entities may
base64 be nested, so that encrypted data may be
• As a result recipients without S/MIME signed and signed data or clear-signed data
capability can view the message content, may be encrypted
although they cannot verify the signature
Cryptographic Algorithms Used in S/MIME
S/MIME Content Types
 Securing a MIME Entity

S/MIME secures a MIME entity with a signature,

encryption, or both
The MIME entity is prepared according to the normal rules
for MIME message preparation
◦ The MIME entity plus some security-related data, such
as algorithm identifiers and certificates, are processed
by S/MIME to produce what is known as a PKCS
object
◦ A PKCS object is then treated as message content and
wrapped in MIME
In all cases the message to be sent is converted to canonical
form
 EnvelopedData
The steps for preparing an envelopedData MIME are:

Generate a pseudorandom session key for a particular

symmetric encryption algorithm

For each recipient, encrypt the session key with the recipient’s
public RSA key

For each recipient, prepare a block known as RecipientInfo

that contains an identifier of the recipient’s public-key
certificate, an identifier of the algorithm used to encrypt the
session key, and the encrypted session key

Encrypt the message content with the session key

 SignedData

The steps for preparing a

signedData MIME are:
Prepare a block
known as
SignerInfo
Encrypt the
that contains the
message digest
signer’s public-
with the signer’s
key certificate,
private key
Compute the an identifier of
message digest the message
(hash function) of digest algorithm,
the content to be an identifier of
signed the algorithm
used to encrypt
Select a the message
message digest digest, and the
algorithm encrypted
(SHA or MD5) message digest
Clear Signing

Achieved using the multipart content type

with a signed subtype
This signing process does not involve
transforming the message to be signed
Recipients with MIME capability but not
S/MIME capability are able to read the
incoming message
 S/MIME Certificate Processing

S/MIME uses public-key certificates that conform to

version 3 of X.509
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
◦ The responsibility is local for maintaining the
certificates needed to verify incoming signatures and
to encrypt outgoing messages
The certificates are signed by certification authorities
 User Agent Role
An S/MIME user has several key-management functions to
perform:
Certificate storage and
Key generation Registration
retrieval

The user of some related A user’s public key must be A user requires access to a
administrative utility must be registered with a certification local list of certificates in
capable of generating separate authority in order to receive an order to verify incoming
Diffie-Hellman and DSS key pairs X.509 public-key certificate signatures and to encrypt
and should be capable of outgoing messages
generating RSA key pairs

A user agent should generate

RSA key pairs with a length in
the range of 768 to 1024 bits
and must not generate a
length of less than 512 bits