UNIT 4

NETWORK SECURITY
Authentication applications
1. Kerberos
2. X.509 authentication service
3. Electronic mail security
4. PGP
5. S/MIME
6. IP security
7. Web security

Kerberos
Kerberos is an authentication service developed as part of Project Athena at MIT.
Kerberos provides a centralized authentication server whose function is to authenticate users to servers and
servers to users.
Kerberos relies exclusively on symmetric encryption, making no use of public-key encryption.
Two versions of Kerberos are in common use.
1. Version 4
2. Version 5
The first published report on Kerberos listed the following requirements:
1. Secure
2. Reliable
3. Transparent
4. Scalable
Kerberos Version 4:
Version 4 of Kerberos makes use of DES to provide authentication service.
More Secure Authentication Dialogue:
Two problems remain in the above scenario.
1. First, we would like to minimize the number of times that a user has to enter a password.
2. The second problem is that the earlier scenario involved a plaintext transmission of the password. An
eavesdropper could capture the password and use any service accessible to the victim.
To solve these problems, a new scheme has been introduced for avoiding plaintext passwords and a new server,
known as the ticket-granting server (TGS).
Once per user logon session:
(1) C AS: ID C || ID tgs
(2) AS C: EKc [Ticket tgs ]
Once per type of service:
(3) C TGS: ID C || ID V|| Ticket tgs
(4) TGS C: Ticket v
Once per service session:
(5) C V: ID C || Ticket v
Ticket tgs = EKtgs [ ID C || AD C || ID tgs || TS 1 || Lifetime 1 ]
Ticket v = EKv [ ID C || AD C || ID v || TS 2 || Lifetime 2 ]
TGS:
The new service, TGS, issues tickets to users who have been authenticated to AS.
Thus, the user first requests a ticket-granting ticket (Ticket tgs) from the AS.
The client module in the user workstation saves this ticket.
The TGS then grants a ticket for the particular service.
The client saves each service-granting ticket and uses it to authenticate its user to a server each time a
particular service is requested.
The authentication steps are as follows:
1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID and password to
the AS, together with the TGS ID, indicating a request to use the TGS service.
2. The AS responds with a ticket that is encrypted with a key that is derived from the user's password.

3. The client requests the TGS for a service-granting ticket on behalf of the user.
4. The TGS decrypts the incoming ticket and verifies the success of the decryption by the presence of its ID.
Then after verification by the TGS, the TGS issues a ticket to grant access to the requested service.

5. The client requests the server for accessing a service on behalf of the user. The server authenticates by
using the contents of the ticket.

The Version 4 Authentication Dialogue:

Two additional problems remain in the above scenario.
1. The first problem is the lifetime associated with the ticket-granting ticket.
If this lifetime is very short, then the user will be repeatedly asked for a password.
If the lifetime is long, then an opponent has a greater opportunity for replay.
2. The second problem is that there may be a requirement for servers to authenticate themselves to users.
The above problems have been addressed in the following protocol.

Kerberos Version 4 Message Exchanges

(1) C AS ID c ||ID tgs ||TS 1
(2) AS C E( K c ,[ K c,tgs ||ID tgs ||TS 2 ||Lifetime 2 ||Ticket tgs ])
Ticket tgs = E(K tgs , [K c,tgs ||ID c ||AD c ||ID tgs ||TS 2|| Lifetime 2 ])
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C TGS ID v Ticket tgs Authenticator c
(4) TGS C E( K c,tgs , [ K c,v|| ID v ||TS 4 ||Ticket v ])
Ticket tgs = E(K tgs , [K c,tgs ||ID C|| AD C|| ID tgs|| TS 2 ||Lifetime 2])
Ticket v = E(K v , [K c,v|| ID C ||AD C|| ID v ||TS 4||Lifetime 4 ])
Authenticator c = E(K c,tgs , [ID C ||ADC ||TS 3 ])
 (b) Ticket-Granting Service Exchange to obtain service-granting ticket
(5) C V Ticket v ||Authenticator c
(6) V C E( K c,v , [ TS 5 + 1]) (for mutual authentication)
Ticket v = E(K v , [K c,v|| ID c ||AD c ||ID v ||TS 4|| Lifetime 4 ])
Authenticator c = E(K c,v ,[ID c ||AD C ||TS 5 ])
(c) Client/Server Authentication Exchange to obtain service
1. The client sends a message to the AS requesting access to the TGS.
2. The AS responds with a message, encrypted with a key derived from the user's password ( K c ) that contains
the ticket.
3. C sends the TGS a message that includes the ticket plus the ID of the requested service.
4. The reply from the TGS follows the form of message (2).
5. C now has a reusable service-granting ticket for V. When C presents this ticket it also sends an
authenticator.
6. The server can reply as shown in message (6). The server returns the value of the timestamp from the
authenticator, incremented by 1, and encrypted in the session key.
Finally, at the conclusion of this process, the client and server share a secret key.

Kerberos Realms and Multiple Kerberi:

A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a number of
application servers requires the following:
1. The Kerberos server must have the user ID and hashed passwords of all participating users in its database.
All users are registered with the Kerberos server.
2. The Kerberos server must share a secret key with each server. All servers are registered with the Kerberos
server.
Such an environment is referred to as a Kerberos realm.

Realm:
A Kerberos realm is a set of managed nodes that share the same Kerberos database.
The read only copy of the Kerberos database resides on the Kerberos master computer system, which
should be kept in a physically secure room.
All changes to the database must be made on the master computer system.
Changing or accessing the contents of a Kerberos database requires the Kerberos master password.
Kerberos provides a mechanism for supporting such interrealm authentication. For two realms to support
interrealm authentication, a third requirement is added:
o The Kerberos server in each interoperating realm shares a secret key with the server in the other
realm. The two Kerberos servers are registered with each other.
The mechanism is as follows:
1. A user wishing service on a server in another realm needs a ticket for that server.
2. The user's client follows the usual procedures to gain access to the local TGS and then requests a ticket-
granting ticket for a remote TGS.
3. The client can then apply to the remote TGS for a service-granting ticket for the desired server in the realm
of the remote TGS.
Request for Service in Another Realm
(1) C AS: ID c || ID tgs|| TS 1
(2) AS C: E( K c , [ K c,tgs|| ID tgs ||TS 2 ||Lifetime 2 ||Ticket tgs ])
(3) C TGS: ID tgsrem ||Ticket tgs ||Authenticator c
(4) TGS C: E( K c,tgs , [ K c,tgsrem ||ID tgsrem ||TS 4|| Ticket tgsrem ])
(5) C TGS rem : ID vrem ||Ticket tgsrem ||Authenticator c
(6) TGS rem C: E( K c,tgsrem , [ K c,vrem ||ID vrem ||TS 6 ||Ticket vrem ])
(7) C V rem : Ticket vrem ||Authenticator c
 The ticket presented to the remote server (Vrem ) indicates the realm in which the user was originally
authenticated. The server chooses whether to honor the remote request.
Kerberos Version 5:
Kerberos Version 5 provides a number of improvements over version 4.

Differences between Versions 4 and 5:

Version 5 is intended to address the limitations of version 4 in two areas:
1. Environmental shortcomings
2. Technical deficiencies
Environmental shortcomings:
1. Encryption system dependence
2. Internet protocol dependence
3. Message byte ordering
4. Ticket lifetime
5. Authentication forwarding
6. Inter realm authentication
Technical deficiencies
1. Double encryption
2. PCBC (Propagating cipher block chaining) encryption
3. Session keys
4. Password attacks

The Version 5 Authentication Dialogue:

Kerberos Version 5 Message Exchanges
(1) C AS Options ID c ||Realm c ||ID tgs ||Times ||Nonce 1
(2) AS C Realm c ||ID C ||Ticket tgs|| E( K c , [ K c,tgs ||Times ||Nonce 1 ||Realm tgs|| ID tgs ])
Ticket tgs = E( K tgs , [ Flags ||K c,tgs|| Realm c|| ID c|| AD c|| Times])
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C TGS Options ID v ||Times ||Nonce 2 ||Ticket tgs ||Authenticator c
(4) TGS C Realm c ||ID c ||Ticket v ||E( K c,tgs , [ K c,v ||Times ||Nonce 2 ||Realmv ||ID v ])
Ticket tgs = E(K tgs , [ Flags ||K C,tgs ||Realm c|| ID C|| AD C ||Times])
Ticket v = E(K v , [Flags||K c,v ||Realm c ||ID C ||AD c ||Times])
Authenticator c = E( K c,tgs , [ ID C ||Realm c|| TS 1])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
(5) C V Options||Ticket v ||Authenticator c
(6) V C E K c,v [TS 2|| Subkey|| Seq#]
Ticket v = E(K v , [Flags||K c,v ||Realm c ||ID C ||AD C ||Times])
Authenticator c = E( K c,v ,[ ID C ||Realm c ||TS 2 ||Subkey ||Seq #])
(c) Client/Server Authentication Exchange to obtain service
First, consider the authentication service exchange.
1. First message is a client request for a ticket-granting ticket. It includes the ID of the user and the TGS. The
following new elements are added:
Realm, Options, Time and Nonce
2. Message (2) returns a ticket-granting ticket, identifying information for the client, and a block encrypted
using the encryption key based on the user's password.
3. Message (3) includes an authenticator, a ticket, and the name of the requested service.
4. Message (4) has the same structure as message (2), returning a ticket plus information needed by the client,
the latter encrypted with the session key now shared by the client and the TGS.
5. Message (5), the client may request as an option that mutual authentication is required. The authenticator
includes several new fields as follows:
Subkey
Sequence numbers
Ticket Flags
The flags field included in tickets in version 5 supports expanded functionality compared to that available in version
4. Table 14.4 summarizes the flags that may be included in a ticket.
Kerberos Version 5 Flags
1. INITIAL
2. PRE-AUTHENT
3. HW-AUTHENT
4. RENEWABLE
5. MAY-POSTDATE
6. POSTDATED
7. INVALID
8. PROXIABLE
9. PROXY
10. FORWARDABLE
11. FORWARDED
X.509 Authentication Service
ITU-T recommendation X.509 is part of the X.500 series that define a directory service.
The directory is a server or distributed set of servers that maintains a database of information about users.
X.509 defines a framework for the provision of authentication services by the X.500 directory to its users.
The directory may serve as a repository of public-key certificates.
X.509 is based on the use of public-key cryptography and digital signatures.
The standard does not dictate the use of a specific algorithm but recommends RSA.
The digital signature scheme require the use of a hash function and it does not indicate any specific hash
function.
Certificates:
The heart of the X.509 scheme is the public-key certificate associated with each user.
These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the
directory by the CA or by the user.
The general format of a certificate, which includes the following elements:
1. Version
2. Serial number
3. Signature algorithm identifier
4. Issuer name.
5. Period of validity
6. Subject name
7. Subject's public-key information
 8. Issuer unique identifier
9. Subject unique identifier
10. Extensions
11. Signature
X.509 Formats
The standard uses the following notation to define a certificate:
CA<<A>> = CA {V, SN, AI, CA, T A , A, Ap}
Where
Y <<X>> = the certificate of user X issued by certification authority Y
Y{I} = the signing of I by Y.
The CA signs the certificate with its private key.
Obtaining a User's Certificate:
A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is expressed as
X 1 <<X 2 >> X 2 <<B>>
In the same fashion, B can obtain A's public key with the reverse chain:
X 2 <<X 1 >> X 1 <<A>>
This scheme need not be limited to a chain of two certificates. In this case, each pair of CAs in the chain
(X i, X i+1 ) must have created certificates for each other.

X.509 Hierarchy:
The connected circles indicate the hierarchical relationship among the CAs; the associated boxes indicate
certificates maintained in the directory for each CA entry. The directory entry for each CA includes two types of
certificates:
Forward certificates: Certificates of X generated by other CAs
Reverse certificates: Certificates generated by X that are the certificates of other CAs

Revocation of Certificates:
Each certificate includes a period of validity.
A new certificate is issued just before the expiration of the old one.
In addition, it may be desirable to revoke a certificate before it expires, for one of the following reasons:
1. The user's private key is assumed to be compromised.
2. The user is no longer certified by this CA.
3. The CA's certificate is assumed to be compromised.
Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA.
Authentication Procedures:
X.509 also includes three alternative authentication procedures that are intended for use across a variety of
applications.
One-Way Authentication:
One way authentication involves a single transfer of information from one user (A) to another (B), and establishes
the following:
1. The identity of A and that the message was generated by A
2. That the message was intended for B
3. The integrity and originality of the message
Two-Way Authentication:
In addition to the three elements just listed, two-way authentication establishes the following elements:
1. The identity of B and that the reply message was generated by B
2. That the message was intended for A
3. The integrity and originality of the reply

Three-Way Authentication:
In three-way authentication, a final message from A to B is included, which contains a signed copy of the
nonce rB.
The intent of this design is that timestamps need not be checked

X.509 Strong Authentication Procedures

 X.509 Version 3:
The X.509 version 2 format does not convey all of the information.
The following requirements are not satisfied by version 2:
1. The Subject field is inadequate to convey the identity of a key owner to a public-key user. X.509 names
may be relatively short.
2. The Subject field is also inadequate for many applications.
3. There is a need to indicate security policy information.
4. There is a need to limit the damage that can result from a faulty or malicious CA.
5. It is important to be able to identify different keys used by the same owner at different times.
Version 3 includes a number of optional extensions. Each extension consists of an extension identifier, a
criticality indicator, and an extension value.
The criticality indicator indicates whether an extension can be safely ignored.
The certificate extensions fall into three main categories:
1. Key and policy information
2. Subject and issuer attributes
3. Certification path constraints.
Key and Policy Information:
These extensions convey additional information about the subject and issuer keys, plus indicators of
certificate policy.
A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular
community and/or class of application with common security requirements.
This area includes the following:
1. Authority key identifier
2. Subject key identifier
3. Key usage
4. Private-key usage period
5. Certificate policies
6. Policy mappings
Certificate Subject and Issuer Attributes:
These extensions support alternative names, in alternative formats, for a certificate subject or certificate
issuer and can convey additional information about the certificate subject.
The extension fields in this area include the following:
1. Subject alternative name
2. Issuer alternative name
 3. Subject directory attributes
Certification Path Constraints:
These extensions allow constraint specifications to be included in certificates issued for CAs by other CAs.
The constraints may restrict the types of certificates that can be issued by the subject CA.
The extension fields in this area include the following:
1. Basic constraints
2. Name constraints
3. Policy constraints

IP Security
IPSec provides the capability to secure communications across a LAN, across private and public WANs,
and across the Internet.
The principal feature of IPSec is that it can encrypt and/or authenticate all traffic at the IP level.

Benefits of IPSec:
When IPSec is implemented in a firewall or router, it provides strong security.
There is no need to change software on a user or server system when IPSec is implemented in the firewall
or router.
There is no need to train users on security mechanisms when users leave the organization.
IPSec can provide security for individual users if needed.
Routing Applications:
IPSec can assure that
A router advertisement comes from an authorized router
A neighbor advertisement comes from an authorized router.
A redirect message comes from the router to which the initial packet was sent.
A routing update is not forged.

IP Security Architecture:
1. Architecture: Covers the general concepts, security requirements, definitions, and mechanisms
defining IPSec technology.
2. Encapsulating Security Payload (ESP): provides encryption and, optionally, authentication.
3. Authentication Header (AH): provides packet authentication.
4. Encryption Algorithm: describes various encryption algorithms
5. Authentication Algorithm: describes various authentication algorithms
6. Key Management: describes key management schemes.
7. Domain of Interpretation (DOI): Contains values needed for the other documents to relate to each other.
IPSec Document Overview

IPSec Services:
IPSec provides security services at the IP layer by enabling a system to select required security protocols, determine
the algorithms to use for the services and put in place any cryptographic keys required to provide the requested
services.
Two protocols are used to provide security:
1. Authentication Header (AH) authentication protocol designated by the header of the protocol
2. Encapsulating Security Payload (ESP) combined encryption/authentication protocol designated by the
format of the packet for that protocol
The services are
Access control
Connectionless integrity
Data origin authentication
Rejection of replayed packets (a form of partial sequence integrity)
Confidentiality (encryption)
Limited traffic flow confidentiality
IPSec Services

Security Associations (SA):

An association is a one-way relationship between a sender and a receiver that affords security services to the traffic
carried on it.
A security association is uniquely identified by three parameters:
Security Parameters Index (SPI): SPI is a bit string assigned to this SA and is carried in AH and ESP
headers to enable the receiving system to select the SA.
IP Destination Address: This is the address of the destination endpoint of the SA.
Security Protocol Identifier: This indicates whether the association is an AH or ESP security association.

SA Parameters:
A security association is normally defined by the following parameters:
1. Sequence Number Counter
2. Sequence Counter Overflow
3. Anti-Replay Window
4. AH Information
5. ESP Information
6. Lifetime of This Security Association
7. IPSec Protocol Mode
8. Path MTU

SA Selectors:
IPSec provides the user with considerable flexibility in the way in which IPSec services are applied to IP traffic.
1. Security Policy Database (SPD) Is related to specific SAs
Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors.
Outbound processing obeys the following general sequence for each IP packet:
o Compare the values of the appropriate fields in the packet against the SPD to find a matching
SPD entry,
o Determine the SA if any for this packet and its associated SPI.
o Do the required IPSec processing
2. Source and Destination IP Address determines an SPD entry
May a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address
3. UserID: A user identifier from the operating system
4. Data Sensitivity Level: Used for systems providing information flow security
5. Transport Layer Protocol: Obtained from the IPv4 Protocol or IPv6 Next Header field.
6. Source and Destination Ports: These may be individual TCP or UDP port values, an enumerated list of
ports, or a wildcard port.

Transport and Tunnel Modes

Both AH and ESP supports these two modes of use
Transport Mode
Transport mode provides protection primarily for upper-layer protocols.
Transport mode is used for end-to-end communication between two hosts.
ESP in transport mode encrypts and optionally authenticates the IP payload but not the IP header.

Tunnel Mode
 Tunnel mode provides protection to the entire IP packet.
The entire original packet travels through a "tunnel" from one point of an IP network to another.
Tunnel mode is used for router- router or firewall - firewall communication.
ESP in tunnel mode encrypts and optionally authenticates the entire inner IP packet, including the inner IP
header. AH in tunnel mode authenticates the entire inner IP packet and selected portions of the outer IP
header.
Authentication Header
The Authentication Header provides support for data integrity and authentication of IP packets.
Prevents the address spoofing attacks
Detects malicious modifications
Detect replays via sequence numbers
Authentication is based on the use of a message authentication code (MAC)two parties must share a secret key.
Fields of AH:
1. Next Header (8 bits): Identifies the type of header immediately following this header.
2. Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2.
3. Reserved (16 bits): For future use.
4. Security Parameters Index (32 bits): Identifies a security association.
5. Sequence Number (32 bits): A monotonically increasing counter value
6. Authentication Data (variable): Variable-length field that contains Integrity Check Value (ICV), or MAC.
IPSec Authentication Header

Anti-Replay Service:
Detection of duplicate packets
A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to
the intended destination.
The Sequence Number field is designed to thwart such attacks.
Sequence numbers:
Associated with SA
32 bit value
When a new SA is established, the sender initializes a sequence number counter to 0.
If anti-replay is enabled (the default), the sender must not allow the sequence number to cycle past 2 32 -1
back to zero.
If the limit of 232 -1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.
Problem:
IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered in order and
does not guarantee that all packets will be delivered.
Solution:
Window based mechanism implemented at the receiver side with a default of W = 64.
The right edge of the window represents the highest sequence number N.
If the received packet falls within the window
o If authenticated and unmarked, mark it
o If marked, then replay
If the received packet is > N
o If authenticated, the window is advanced so that this sequence number is the right edge and marked.
If the received packet is < = N-W
o If authentication fails, the packet is discarded
Anti-replay Mechanism
Integrity Check Value (ICV):
ICV is a MAC or a truncated version of a code produced by a MAC algorithm.
Supports HMAC
The current specification dictates that a compliant implementation must support
o MD5
o SHA-1
Full HMAC value is calculated but then truncated by using the first 96 bits, which is the default length for
the Authentication Data field.

MAC is calculated over

IP header fields that are immutable (source address) or that are mutable but predictable (destination address)
AH header
IP payload (Entire upper-level protocol data)

Scope of AH Authentication
1. For transport mode AH using IPv4, the AH is inserted after the original IP header and before the
IP payload
Authentication covers the entire packet, excluding mutable fields in the IPv4 header
In the context of IPv6, AH is viewed as an end-to-end payload and 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.
Authentication covers the entire packet, excluding mutable fields that are set to zero for MAC calculation.
2. For tunnel mode AH, the entire original IP packet is authenticated, and the AH is inserted between the
original IP header and a new outer IP header.
With tunnel mode, the entire inner IP packet, including the entire inner IP header is protected by AH.
The outer IP header (and in the case of IPv6, the outer IP extension headers) is protected except for mutable
and unpredictable fields.
 Encapsulating Security Payload
The Encapsulating Security Payload provides confidentiality services
1. Confidentiality of message contents
2. Limited traffic flow confidentiality
3. Optionally authentication service.
Supports range of encryption modes:
RC5, IDEA, Three-key triple IDEA, CAST and Blowfish
ESP Format:
1. Security Parameters Index (32 bits): Identifies a security association.
2. Sequence Number (32 bits): Increasing counter value

3. Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that
is protected by encryption.
4. Padding (0255 bytes): The purpose of this field is discussed later.
5. Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
6. Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first
header.
7. Authentication Data (variable): A variable-length field
Padding:
The Padding field serves several purposes:
Encryption algorithm requires that the plaintext to be expanded to the required length
The ESP format requires 32-bit word
Additional padding may be added to provide partial traffic flow confidentiality by concealing the actual
length of the payload.
Transport Mode ESP:
Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP.
 Transport mode operation provides data confidentiality but left the IP header in clear.
One drawback to this mode is that it is possible to do traffic analysis on the transmitted packets.
Used mostly for end-end traffic

Tunnel Mode ESP:

Tunnel mode ESP is used to encrypt an entire IP packet.
This method can be used to counter traffic analysis.
Add new header for processing at intermediate routers
Good for router-router security

Combining Security Associations

An individual SA can implement either the AH or ESP protocol but not both.
To implement both, need to combine SAs.
The term security association bundle refers to a sequence of SAs through which traffic must be processed to
provide a desired set of IPSec services.
Security associations may be combined into bundles in two ways:
1. Transport adjacency: Refers to applying more than one security protocol to the same IP packet, without
invoking tunneling
 2. Iterated tunneling: Refers to the application of multiple layers of security protocols effected through IP
tunneling.
Basic Combinations of Security Associations:
a) AH in transport mode
b) ESP in transport mode
c) ESP followed by AH in transport mode
d) Any one of a, b, or c inside an AH or ESP in tunnel mode

Key Management
IPSec Architecture document mandates support for two types of key management:
1. Manual: A system administrator manually configures each system with its own keys.
2. Automated: An automated system enables the on-demand creation of keys for SAs.
The default automated key management protocol for IPSec is referred to as
1. ISAKMP
2. Oakley
Oakley Key Determination Protocol:
Oakley is a refinement of the Diffie-Hellman key exchange algorithm.
The Diffie-Hellman algorithm has two attractive features:
Secret keys are created only when needed.
The exchange requires no preexisting infrastructure other than an agreement on the global parameters.
Weaknesses to Diffie-Hellman:
It is subject to a man-in-the-middle attack
Features of Oakley
The Oakley algorithm is characterized by five important features:
1. It employs a mechanism known as cookies to thwart clogging(denial of service) attacks.
2. It enables the two parties to negotiate a group
3. It uses nonces to ensure against replay attacks.
4. It enables the exchange of Diffie-Hellman public key values.
5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks using symmetric or
asymmetric encryption.

ISAKMP:
Internet Security Association and Key Management Protocol defines procedures and packet formats to
establish, negotiate, modify, and delete security associations.
It is not a key exchange protocol.
ISAKMP Header Format:
An ISAKMP message consists of an ISAKMP header followed by one or more payloads.
Based on the concept of DOI (Domain of Interpretation)
It consists of the following fields:
1. Initiator Cookie (64 bits): Cookie of entity that initiated SA establishment, SA notification, or SA deletion.
2. Responder Cookie (64 bits): Cookie of responding entity; null in first message from initiator.
3. Next Payload (8 bits): Indicates the type of the first payload in the message; payloads are discussed in the
next subsection.
4. Major Version (4 bits): Indicates major version of ISAKMP in use.
5. Minor Version (4 bits): Indicates minor version in use.
6. Exchange Type (8 bits): Indicates the type of exchange; these are discussed later in this section.
7. Flags (8 bits): Indicates specific options set for this ISAKMP exchange.
8. Message ID (32 bits): Unique ID for this message.
9. Length (32 bits): Length of total message (header plus all payloads) in octets.

ISAKMP Payload Types:

The Next Payload field has a value of 0 if this is the last payload in the message; otherwise its value is the
type of the next payload.
The Payload Length field indicates the length in octets of this payload, including the generic payload
header.
1. SA payload To exchange the DOI information
2. Proposal and Transform payload To exchange the security and crypto capabilities in the DOI
3. Key exchange payload To exchange the key exchange information
4. Identification Exchange identification information
5. Certificate Transport certificate
6. Certificate request Request certificates
7. Hash Contains data generated by hash function
8. Signature Contains data generated by DS function
9. Nonce Contains nonce
10. Notification Transmit notification data and error condition
11. Delete Indicates an SA no longer valid

ISAKMP Exchanges:
ISAKMP provides a framework for message exchange, with the payload types serving as the building blocks.
The specification identifies five default exchange types that should be supported.
1. The Base Exchange allows key exchange and authentication material to be transmitted together. This
minimizes the number of exchanges.
2. The Identity Protection Exchange expands the Base Exchange to protect the users' identities.
3. The Authentication Only Exchange is used to perform mutual authentication, without a key exchange.
4. The Aggressive Exchange minimizes the number of exchanges at the expense of not providing identity
protection.
5. The Informational Exchange is used for one-way transmittal of information for SA management.
 S/MIME
S/MIME (Secure/ Multipurpose Internet Mail Extension) is a security enhancement to the MIME- Internet
e-mail format standard, based on technology from RSA Data Security.

Multipurpose Internet Mail Extensions

MIME is an extension to the RFC 822 framework that is intended to address some of the problems and limitations
of the use of SMTP or some other mail transfer protocol and RFC 822 for electronic mail.
Overview
The MIME specification includes the following elements:
1. Five new message header fields are defined.
2. A number of content formats are defined that support multimedia electronic mail.
3. Transfer encodings are defined that enable the conversion of any content format into a form that is protected
from alteration by the mail system.

Five message header fields: The next two subsections deal with content formats and transfer encodings.
1. MIME-Version: Must have the parameter value 1.0.
2. Content-Type: Describes the data contained in the body with sufficient detail.
3. Content-Transfer-Encoding: Indicates the type of transformation.
4. Content-ID: Used to identify MIME entities.
5. Content-Description: A text description of the object with the body.

MIME Content Types

There are 7 major types of content and a total of 15 subtypes.
In general, a content type declares the general type of data, and the subtype specifies a particular format for
that type of data.
1. Text
2. Multipart
3. Message
4. Image
5. Video
6. Audio
7. Application
1. Text Type:
The primary subtype is plain text, which is simply a string of ASCII characters.
The enriched subtype allows greater formatting flexibility.
2. Multipart Type:
The multipart type indicates that the body contains multiple, independent parts.
The Content-Type header field includes a parameter, called boundary that defines the delimiter
between body parts.
There are four subtypes of the multipart type, all of which have the same overall syntax.
Multipart/mixed
Multipart/parallel
Multipart/alternative
Multipart/digest
3. Message Type:
The message/rfc822 subtype indicates that the body is an entire message, including header and
body.
The message/partial subtype enables fragmentation of a large message into a number of parts.
The message/external-body subtype indicates that the actual data to be conveyed in this message
are not contained in the body.

MIME Transfer Encodings:

The other major component of the MIME specification is a definition of transfer encodings for message
bodies.
The objective is to provide reliable delivery across the largest range of environments.
 The Content-Transfer-Encoding field can actually take on six values.
1. 7 bit
2. 8 bit
3. X-token
4. Quoted
5. Base64
Native and Canonical Form
Native form The native character set is used and, where appropriate, local end-of-line conventions are used
as well.
Canonical form The entire body is converted to a universal canonical form.
Conversion to the proper canonical form may involve character set conversion, transformation of audio data,
compression, or various other operations specific to the various media types.

S/MIME Functionality:
S/MIME provides the following functions:
1. Enveloped data: This consists of encrypted content of any type and encrypted-content encryption keys for
one or more recipients.
2. Signed data: A digital signature is formed by taking the message digest of the content to be signed.
3. Clear-signed data: As with signed data, a digital signature of the content is formed.
4. Signed and enveloped data: Signed-only and encrypted-only entities may be nested.

Cryptographic Algorithms
S/MIME uses the following terminology, taken from RFC 2119 to specify the requirement level:
1. Must: The definition is an absolute requirement of the specification. An implementation must include this
feature or function to be in conformance with the specification.
2. Should: There may exist valid reasons in particular circumstances to ignore this feature or function. But it
is recommended that an implementation include the feature or function.
Cryptographic Algorithms Used in S/MIME:
SHA-1
MD5
RSA
Diffie-Hellman and HMAC

General procedures for S/MIME message preparation:

Securing a MIME Entity:
S/MIME secures a MIME entity with a signature, encryption, or both.
A MIME entity may be an entire message or if the MIME content type is multipart.
Then 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.
EnvelopedData:
The steps for preparing an envelopedData MIME entity are as follows:
1. Generate a pseudorandom session key for a particular symmetric encryption algorithm.
2. For each recipient, encrypt the session key with the recipient's public RSA key.

3. 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.
4. Encrypt the message content with the session key.
SignedData:
The signedData smime-type can actually be used with one or more signers.
The steps for preparing a signedData MIME entity are as follows:
1. Select a message digest algorithm (SHA or MD5).
2. Compute the message digest, or hash function, of the content to be signed.
3. Encrypt the message digest with the signer's private key.
4. Prepare a block known as SignerInfo that contains the signer's public-key certificate, an identifier of the
message digest algorithm,
Clear Signing:
Clear signing is achieved using the multipart content type with a signed subtype.
This signing process does not involve transforming the message to be signed, so that the message is sent "in
the clear."
Thus, recipients with MIME capability but not S/MIME capability are able to read the incoming message.

Registration Request:
The certification request includes certificationRequestInfo block, followed by an identifier of the public-key
encryption algorithm, followed by the signature of the certificationRequestInfo block, made using the
sender's private key.
The certificationRequestInfo block includes a name of the certificate subject and a bit-string representation
of the user's public key.

S/MIME Certificate Processing:

S/MIME uses public-key certificates that conform to version 3 of X.509.
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.

User Agent Role:

An S/MIME user has several key-management functions to perform:
1. Key generation
2. Registration
3. Certificate storage and retrieval
VeriSign Certificates:
VeriSign provides a CA service that is intended to be compatible with S/MIME and a variety of other
applications.
VeriSign issues X.509 certificates with the product name VeriSign Digital ID.
At a minimum, each Digital ID contains
1. Owner's public key
2. Owner's name or alias
3. Expiration date of the Digital ID
4. Serial number of the Digital ID
5. Name of the certification authority that issued the Digital ID
6. Digital signature of the certification authority that issued the Digital ID
7. Digital IDs can also contain other user-supplied information, including
8. Address
9. E-mail address
10. Basic registration information (country, zip code, age, and gender)

VeriSign provides three levels, or classes, of security for public-key certificates.

The following procedures are used:
1. For Class 1 Digital IDs, VeriSign confirms the user's e-mail address by sending a PIN and Digital ID pick-
up information to the e-mail address provided in the application.
2. For Class 2 Digital IDs, VeriSign verifies the information in the application through an automated
comparison with a consumer database.
3. For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance.

Enhanced Security Services:

Three enhanced security services have been proposed in an Internet draft. The three services are as follows:
1. Signed receipts: A signed receipt may be requested in a Signed Data object.
2. Security labels: A security label may be included in the authenticated attributes of a Signed Data object. A
security label is a set of security information regarding the sensitivity of the content.
3. Secure mailing lists: When a user sends a message to multiple recipients, a certain amount of per-recipient
processing is required.
 The user can be relieved of this work by employing the services of an S/MIME Mail List Agent
(MLA).
An MLA can take a single incoming message, perform the recipient-specific encryption for each
recipient, and forward the message.
The originator of a message need only send the message to the MLA, with encryption performed
using the MLA's public key.

Pretty Good Privacy

PGP provides a confidentiality and authentication service that can be used for electronic mail and file
storage applications.
The package includes RSA, DSS, and Diffie-Hellman for public-key encryption.

Operational Description:
The actual operation of PGP consists of five services:
1. Authentication
2. Confidentiality
3. Compression
4. E-mail compatibility
5. Segmentation

1. Authentication:
The sequence is as follows:
The sender creates a message. SHA-1 is used to generate a 160-bit hash code of the message.
The hash code is encrypted with RSA using the sender's private key, and the result is prepended to the
message.
The receiver uses RSA with the sender's public key to decrypt and recover the hash code.
The receiver generates a new hash code for the message and compares it with the decrypted hash code. If
the two match, the message is accepted as authentic.
As an alternative, signatures can be generated using DSS/SHA-1.
Detached signatures are supported. A detached signature may be stored and transmitted separately from the
message it signs.

2. Confidentiality:
Confidentiality is provided by encrypting messages to be transmitted or to be stored locally as files.
Symmetric encryption algorithm CAST-128 may be used.
As an alternative PGP provides an option referred to as Diffie-Hellman.

3. Compression:
PGP compresses the message after applying the signature but before encryption. The placement of the
compression algorithm, indicated by Z for compression and Z -1 for decompression. The signature is
generated before compression or after compression.
Message encryption after compression:
Message encryption is applied after compression to strengthen cryptographic security.
Because the compressed message has less redundancy than the original plaintext, cryptanalysis is more
difficult. The compression algorithm used is ZIP.

4. E-mail Compatibility:
When PGP is used, at least part of the block to be transmitted is encrypted.
If only the signature service is used, then the message digest is encrypted.
If the confidentiality service is used, the message plus signature are encrypted.
Radix-64:
The scheme used for this purpose is radix-64 conversion. Each group of three octets of binary data is
mapped into four ASCII characters. The use of radix 64 expands a message by 33%.

Relationship among the four services:

On transmission, if it is required, a signature is generated using a hash code of the uncompressed plaintext.
Then the plaintext, plus signature if present, is compressed.
Next, if confidentiality is required, the block is encrypted and prepended with the public-key-encrypted
symmetric encryption key.
Finally, the entire block is converted to radix-64 format.
On reception, the incoming block is first converted back from radix-64 format to binary.
Then, if the message is encrypted, the recipient recovers the session key and decrypts the message.
The resulting block is then decompressed.
If the message is signed, the recipient recovers the transmitted hash code and compares it to its own
calculation of the hash code.

Transmission and Reception of PGP Messages

Cryptographic Keys and Key Rings:

PGP makes use of four types of keys:
1. One-Time Session Symmetric Keys
2. Public Keys
3. Private Keys
4. Passphrase-Based Symmetric Keys

Session Key Generation:

Each session key is associated with a single message and is used only for the purpose of encrypting and
decrypting that message.
Random 128-bit numbers are generated using CAST-128 itself. The input to the random number generator
consists of a 128-bit key and two 64-bit blocks that are treated as plaintext to be encrypted.
Using cipher feedback mode, the CAST-128 encrypter produces two 64-bit cipher text blocks, which are
concatenated to form the 128-bit session key.

Key Identifiers:
The technique adopted by PGP is to assign a key ID to each public key that is unique within a user ID.
The key ID associated with each public key consists of its least significant 64 bits. That is, the key ID of
public PUa is ( PUa mod 2 64 ).
A key ID is also required for the PGP digital signature.

A message consists of three components:

1. The message component
2. A signature (optional)
 3. A session key component (optional).
The message component includes the actual data to be stored or transmitted, as well as a filename and a
timestamp that specifies the time of creation.
The signature component includes the following:
1. Timestamp
2. Message digest
3. Leading two octets of message digest
4. Key ID of sender's public key
The session key component includes the session key and the identifier of the recipient's public key that was
used by the sender to encrypt the session key.

Key Rings:
The scheme used in PGP is to store and organize the key is a pair of data structures at each node.
These data structures are referred to, respectively, as the private-key ring and the public-key ring.
We can view the ring as a table, in which each row represents one of the public/private key pairs owned by this user.
Each row contains the following entries:
1. Timestamp
2. Key ID
3. Public key
4. Private key
Private key ring:
The private-key ring can be indexed by either User ID or Key ID.
It is intended that the private-key ring be stored only on the machine of the user that created and owns the
key pairs, and that it be accessible only to that user.
Public key ring:
The public-key ring can be indexed by either User ID or Key ID
This data structure is used to store public keys of other users that are known to this user. This table includes the
following fields:
1. Timestamp
2. Key ID
3. Public Key
4. User ID
Usage of key rings in message transmission and reception:
First consider message transmission and assume that the message is to be both signed and encrypted. The sending
PGP entity performs the following steps:

1. Signing the message

a) PGP retrieves the sender's private key from the private-key ring using your_userid as an index. If
your_userid was not provided in the command, the first private key on the ring is retrieved.
b) PGP prompts the user for the passphrase to recover the unencrypted private key.
c) The signature component of the message is constructed.
2. Encrypting the message
a) PGP generates a session key and encrypts the message.
b) PGP retrieves the recipient's public key from the public-key ring using her_userid as an index.
c) The session key component of the message is constructed.

The receiving PGP entity performs the following steps:

1. Decrypting the message
a) PGP retrieves the receiver's private key from the private-key ring, using the Key ID field in the
session key component of the message as an index.
b) PGP prompts the user for the passphrase to recover the unencrypted private key.
c) PGP then recovers the session key and decrypts the message.
2. Authenticating the message
a) PGP retrieves the sender's public key from the public-key ring, using the Key ID field in the
signature key component of the message as an index.
b) PGP recovers the transmitted message digest.
c) PGP computes the message digest for the received message and compares it to the transmitted
message digest to authenticate.

Web Security
Secure Socket Layer and Transport Layer Security:
Netscape originated SSL.
SSL Architecture:
SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
SSL is not a single protocol but rather two layers of protocols.
4.2 SSL Protocol Stack

Higher-layer protocols are defined as part of SSL:

o Handshake Protocol
o HTTP
o Change Cipher Spec Protocol
 o Alert Protocol
Two important SSL concepts are the SSL session and the SSL connection, which are defined in the
specification as follows:

Connection:
A connection is a transport that provides a suitable type of service.
Such connections are peer-to-peer relationships.
The connections are transient.
Every connection is associated with one session.
Session:
A session is an association between a client and a server.
Sessions are created by the Handshake Protocol.
Sessions define a set of cryptographic security parameters, which can be shared among multiple
connections.
A session state is defined by the following parameters:
Session identifier, Peer certificate, Compression method, Cipher spec, Master secret and Is resumable
A connection state is defined by the following parameters:
Server and client random, Server write MAC secret, Client write MAC secret, Server write key, Client write
key, Initialization vectors and Sequence numbers

SSL Record Protocol:

The SSL Record Protocol provides two services for SSL connections:
1. Confidentiality
2. Message Integrity
SSL Record Protocol Operation
The first step is fragmentation.
Each upper-layer message is fragmented into blocks of 2 14 bytes or less.
Next, compression is optionally applied and it must be lossless.
The next step in processing is to compute a message authentication code over the compressed data. For this
purpose, a shared secret key is used.
The calculation is defined as
Hash (MAC _ write _ secret || pad_2 || hash (MAC _ write _ secret || pad_1|| seq _ num ||
SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment))
Next, the compressed message plus the MAC are encrypted using symmetric encryption.
The final step of SSL Record Protocol processing is to prepend a header, consisting of the following fields:
Content Type (8 bits)
Major Version (8 bits)
Minor Version (8 bits)
Compressed Length (16 bits)

Change Cipher Spec Protocol:

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record
Protocol.
This protocol consists of a single message, which consists of a 1 byte with the value 1.
The sole purpose of this message is to cause the pending state to be copied into the current state.
 4.5 SSL Record Protocol Payload

Alert Protocol:
The Alert Protocol is used to convey SSL- related alerts to the peer entity.
Alert messages are compressed and encrypted, as specified by the current state.
Each message in this protocol consists of two bytes.
The first byte takes the value warning (1) or fatal (2) to convey the severity of the message.
The second byte contains a code that indicates the specific alert.

Handshake Protocol:
This protocol allows the server and client to authenticate each other
The Handshake Protocol is used before any application data is transmitted.
The Handshake Protocol consists of a series of messages exchanged by client and server.
Each message has three fields:
Type (1 byte): Indicates one of 10 messages.
Length (3 bytes): The length of the message in bytes.
Content ( 0 bytes): The parameters associated with this message.

Handshake Protocol Action

The exchange can be viewed as having four phases.
Phase 1: Establish Security Capabilities
This phase is used to initiate a logical connection and to establish the security capabilities that will be
associated with it.
The exchange is initiated by the client, which sends a client_hello message with the following parameters:
After sending the client_hello message, the client waits for the server_hello message, which contains the
same parameters as the client_hello message.
The first element of the Cipher Suite parameter is the key exchange method.

The following key exchange methods are supported:

o RSA, Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman
Phase 2: Server Authentication and Key Exchange
The server begins this phase by sending its certificate, if it needs to be authenticated; the message contains
one or a chain of X.509 certificates.
The final message in Phase 2 is the server_done message, which is sent by the server to indicate the end of
the server hello and associated messages.
After sending this message, the server will wait for a client response. This message has no parameters.

Phase 3: Client Authentication and Key Exchange

Upon receipt of the server_done message, the client should verify that the server provided a valid certificate
if required and check that the server_hello parameters are acceptable.
If all is satisfactory, the client sends one or more messages back to the server.
Next is the client_key_exchange message, which must be sent in this phase. The content of the message
depends on the type of key exchange.
Finally the client may send a certificate_verify message to provide explicit verification of a client
certificate.
Phase 4: Finish
This phase completes the setting up of a secure connection.
The client sends a change_cipher_spec message and copies the pending CipherSpec into the current
CipherSpec.
The client then immediately sends the finished message under the new algorithms, keys, and secrets.
The finished message verifies that the key exchange and authentication processes were successful.
Transport Layer Security
TLS goal is to produce an Internet standard version of SSL.
TLS is defined as a Proposed Internet Standard in RFC 2246.

Version Number:
The TLS Record Format is the same as that of the SSL Record Format, and the fields in the header have the
same meanings.
The one difference is in version values.
For the current version of TLS, the Major Version is 3 and the Minor Version is 1.

Message Authentication Code

There are two differences between the SSLv3 and TLS MAC schemes.
TLS makes use of the HMAC algorithm defined in RFC 2104.
HMAC is defined as follows:
HMAC K (M ) = H[( K + opad)||H[M ]]
SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret key rather
than being XORed with the secret key padded to the block length.
For TLS, the MAC calculation encompasses the fields indicated in the following expression:
HMAC_hash(MAC_write_secret, seq_num TLSCompressed.type TLSCompressed.version
TLSCompressed.length TLSCompressed.fragment)
Pseudorandom Function:
The objective is to make use of a relatively small shared secret value but to generate longer blocks of data
in a way that is secure from the kinds of attacks.
The PRF is based on the following data expansion function:
P_hash(secret, seed) = HMAC_hash(secret, A(1) seed) HMAC_hash(secret, A(2) seed) HMAC_hash(secret, A(3)
seed) ...
where A() is defined as
A(0) = seed
A( i ) = HMAC_hash (secret, A( i - 1))
To make PRF as secure as possible, it uses two hash algorithms in a way that should guarantee its security if
either algorithm remains secure. PRF is defined as
o PRF(secret, label, seed) = P_MD5(S1, label seed) P_SHA-1(S2, label seed)
PRF takes as input a secret value, an identifying label, and a seed value and produces an output of arbitrary
length.
Output is created by splitting the secret value into two halves (S1 and S2) and performing P_hash on each
half, using MD5 on one half and SHA-1 on the other half.
The two results are XORed to produce the output.

Alert Codes:
TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate.
A number of additional codes are defined in TLS; of these, the following are always fatal:
1. decryption_failed
2. record_overflow
3. unknown_CA
4. access_denied
5. decode_error
6. protocol_version
7. internal_error

Client Certificate Types:

TLS defines the following certificate types to be requested in a certificate_request message: rsa_sign,
dss_sign, rsa_fixed_dh, and dss_fixed_dh.

Certificate_Verify and Finished Messages

In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over
handshake_messages.
As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared
master_secret, the previous handshake messages, and a label that identifies client or server.
Padding
In SSL, the padding added prior to encryption is the minimum amount required so that the total size of the
data to be encrypted is a multiple of the cipher's block length.
In TLS, the padding can be any amount that results in a total that is a multiple of the cipher's block length,
up to a maximum of 255 bytes.
Secure Electronic Transaction
SET is an open encryption and security specification designed to protect credit card transactions on the Internet.
It is a set of security protocols and formats that enables users to employ the existing credit card payment
infrastructure on an open network in a secure fashion.
SET provides three services:
o Provides a secure communications channel among all parties involved in a transaction
o Provides trust by the use of X.509v3 digital certificates
o Ensures privacy.

Key Features of SET:

SET incorporates the following features:
Confidentiality of information
Integrity of data
Cardholder account authentication
Merchant authentication.

SET Participants:
Participants in the SET system, which include the following:
Cardholder
Merchant
Issuer
Acquirer
Payment gateway
Certification authority
Sequence of events that are required for a transaction:
1. The customer opens an account.
2. The customer receives a certificate.
3. Merchants have their own certificates.
4. The customer places an order.
5. The merchant is verified.
6. The order and payment are sent.
7. The merchant requests payment authorization.
8. The merchant confirms the order.
9. The merchant provides the goods or service.
10. The merchant requests payment.

Dual Signature
The purpose of the dual signature is to link two messages that are intended for two different recipients.
In this case, the customer creates dual signature
1. Order information (OI) to the merchant
2. Payment information (PI) to the bank.
Construction of digital signature:
1. The customer takes the hash (using SHA-1) of the PI and the hash of the OI.
2. These two hashes are then concatenated
3. Again the result is subjected to hash.
4. Finally, the customer encrypts the final hash with his private signature key, creating the dual
signature.
The operation can be summarized as
DS = E( PR c , [H(H(PI) || H(OI))])
Where PR c is the customer's private signature key.
 Payment Processing:
Transaction types supported by SET.
Purchase request
Payment authorization
Payment capture
Purchase Request:
The purchase request exchange consists of four messages:
1. Initiate Request
2. Initiate Response
3. Purchase Request
4. Purchase Response
1. The customer requests the certificates in the Initiate Request message, sent to the merchant.
2. The merchant generates a response and signs it with its private signature key.
3. The cardholder prepares the Purchase Request message.

The message includes the following:

1. Purchase- related information:
Consists of PI, Dual Signature, OIMD and Digital envelope
2. Order-related information:
Consists of OI, Dual Signature, PIMD and Cardholder certificate
When the merchant receives the Purchase Request message, it performs the following actions.
Verifies the cardholder certificates by means of its CA signatures.
Verifies the dual signature using the customer's public signature key.
 Processes the order and forwards the payment information to the payment gateway.
Sends a purchase response to the cardholder.

4. The Purchase Response message includes a response block that acknowledges the order and references the
corresponding transaction number.
This block is signed by the merchant using its private signature key.
The block and its signature are sent to the customer, along with the merchant's signature certificate.
When the cardholder software receives the purchase response message, it verifies the merchant's
certificate and then verifies the signature on the response block.
Finally, it takes some action based on the response, such as displaying a message to the user or updating
a database with the status of the order.

Merchant Verifies Customer Purchase Request

Payment Authorization:
This authorization guarantees that the merchant will receive payment; the merchant can therefore
provide the services or goods to the customer.
The payment authorization exchange consists of two messages:
1. Authorization Request
2. Authorization response.

Authorization Request
The merchant sends an Authorization Request message to the payment gateway consisting of the following:
Purchase-related information: This information was obtained from the customer and consists of
PI
Dual Signature
OI message digest (OIMD)
Digital Envelope
Authorization-related information: This information is generated by the merchant and consists of
An authorization block that includes the transaction ID
Digital Envelope
Certificates

The payment gateway performs the following tasks:

1. Verifies all certificates
2. Decrypts the digital envelope of the authorization block to obtain the symmetric key and then decrypts the
authorization block
 3. Verifies the merchant's signature on the authorization block
4. Decrypts the digital envelope of the payment block to obtain the symmetric key and then decrypts the
payment block
5. Verifies the dual signature on the payment block
6. Verifies that the transaction ID received from the merchant
7. Requests and receives an authorization from the issuer

Authorization Response
Then payment gateway returns an Authorization Response message to the merchant. It includes the following
elements:
Authorization-related information which includes an
Authorization block
Digital envelope
Capture token information this information will be used to effect payment later. This block is a signed,
encrypted capture token together with a digital envelope. This token is not processed by the merchant.
Payment Capture:
To obtain payment, the merchant engages the payment gateway in a payment capture transaction, consisting
of
1. Capture request
2. Capture response message

For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which
includes the payment amount and the transaction ID.
o When the payment gateway receives the capture request message, it decrypts and verifies the
capture request block capture token block.
o It then creates a clearing request that is sent to the issuer over the private payment network.
o This request causes funds to be transferred to the merchant's account.

The gateway then notifies the merchant of payment in a Capture Response message.
o The message includes a capture response block that the gateway signs and encrypts.
o The message also includes the gateway's signature key certificate.