Secure Sockets Layer (SSL)

Introduction

Secure Sockets Layer (SSL) is a transport-layer security protocol designed to

provide secure communication over the Internet. It works on top of the
Transmission Control Protocol (TCP) and protects data exchanged
between a client and a server. SSL was developed to ensure that sensitive
information such as passwords, banking details, and personal data can be
transmitted safely across insecure networks.

SSL provides three important security services: Confidentiality, Integrity,

and Authentication. Confidentiality is achieved through encryption, integrity
is ensured using Message Authentication Codes (MACs), and authentication
is performed using digital certificates. Although SSL has been replaced by
Transport Layer Security (TLS), the term SSL is still widely used.

Need for SSL

Before SSL was introduced, data transmitted over the Internet was sent in
plain text, making it vulnerable to interception and modification by attackers.
SSL was developed to overcome these security issues by creating a secure
communication channel between the client and the server.

SSL is required for the following reasons:

 To protect confidential information from unauthorized users.

 To prevent modification of data during transmission.
 To verify the identity of websites and servers.
 To provide secure online communication and transactions.
 To improve user trust in Internet-based services.

SSL Architecture

SSL is positioned between the Application Layer and the Transport Layer
(TCP). It allows application protocols such as HTTP, FTP, SMTP, and others
to communicate securely without modifying the application itself.

SSL architecture consists of two layers:

1. SSL Record Protocol

The SSL Record Protocol is responsible for providing the basic security
services such as encryption, message integrity, and secure transmission of
data. All application data passes through this protocol before being
transmitted over the network.

2. Higher-Level SSL Protocols

SSL includes three higher-level protocols that manage secure communication.

  Handshake Protocol
 Change Cipher Spec Protocol
 Alert Protocol

These protocols work together to establish, maintain, and terminate secure

communication between the client and the server.

SSL Session and SSL Connection

SSL Session

An SSL session is a logical association established between a client and a

server. It is created by the Handshake Protocol and contains security
parameters that can be reused by multiple connections. Reusing an existing
session reduces the time and computational overhead required to establish a
new secure connection.

The session state contains the following information:

 Session Identifier
 Peer Certificate
 Compression Method
 Cipher Specification
 Master Secret
 Resumable Flag

SSL Connection

An SSL connection is a temporary secure communication channel between

the client and the server. Every SSL connection is associated with one SSL
session. Multiple secure connections can use the same session.

The connection state contains:

 Client Random Number

 Server Random Number
 Client Write Key
 Server Write Key
 Client Write MAC Secret
 Server Write MAC Secret
 Initialization Vector (IV)
 Sequence Numbers

SSL Record Protocol

The SSL Record Protocol is responsible for securely transmitting application

data between the client and the server. It ensures that the transmitted data
remains confidential and unchanged throughout communication.

The SSL Record Protocol provides two important services.

1. Confidentiality

Confidentiality is achieved by encrypting data using symmetric encryption

algorithms. Only the intended receiver possessing the correct secret key can
decrypt and read the transmitted information.

2. Message Integrity

Integrity is provided using a Message Authentication Code (MAC). Before

transmission, a MAC is generated using a shared secret key. The receiver
verifies the MAC to ensure that the message has not been altered during
transmission.

Working of SSL Record Protocol

The SSL Record Protocol processes data through the following steps:

Step 1: Fragmentation

Large application messages are divided into smaller fragments to make

transmission more efficient.

Step 2: Compression

The fragmented data may be compressed to reduce its size before encryption.
Compression is optional.

Step 3: Message Authentication Code (MAC)

A MAC is calculated using a shared secret key. This helps verify the integrity
of the transmitted data.

Step 4: Encryption

The compressed data along with the MAC is encrypted using a symmetric
encryption algorithm such as AES or 3DES.

Step 5: Header Addition

An SSL Record Header containing protocol information is added to the

encrypted message.

Step 6: Transmission

The complete SSL record is transmitted over TCP. At the receiving side, the
reverse operations—decryption, MAC verification, decompression, and
reassembly—are performed before delivering the original message to the
application.

SSL Record Header

Each SSL record contains a header with the following fields:

 Content Type
 Major Version
 Minor Version
 Compressed Length

These fields help identify the protocol version, message type, and length of
the transmitted data.

Change Cipher Spec Protocol

The Change Cipher Spec Protocol is the simplest protocol in SSL. It consists
of only a single one-byte message.

Its purpose is to notify both the client and the server that the newly negotiated
encryption algorithms and secret keys should now be used for all subsequent
communication. Once this message is exchanged, both parties begin secure
communication using the new cipher suite.

Alert Protocol

The Alert Protocol is used to communicate warning and error messages

between the client and the server. Alert messages are encrypted and
transmitted securely using the SSL Record Protocol.

Each alert message contains two fields:

Alert Level

The alert level specifies the severity of the message.

 Warning
 Fatal

Alert Description

The alert description specifies the exact error that occurred.

Common alert messages include:

 Unexpected Message
 Bad Record MAC
 Handshake Failure
 Illegal Parameter
 Bad Certificate
 Unsupported Certificate
 Certificate Expired
 Certificate Revoked
 Close Notify
If a Fatal Alert occurs, the SSL connection is terminated immediately to
prevent further communication.

SSL Handshake Protocol

The Handshake Protocol is the most important component of SSL. It is

responsible for authenticating the communicating parties, selecting
cryptographic algorithms, exchanging secret keys, and establishing a secure
communication session before any application data is transmitted.

The Handshake Protocol consists of four phases.

Phase 1: Establish Security Capabilities

The client initiates communication by sending a Client Hello message

containing the highest SSL version supported, a random number, session
identifier, supported cipher suites, and compression methods.

The server responds with a Server Hello message containing the SSL
version selected, its own random number, session identifier, chosen cipher
suite, and compression method.
This phase establishes the security capabilities that will be used throughout
the session.

Phase 2: Server Authentication and Key Exchange

During this phase, the server authenticates itself by sending its digital
certificate. If required, it also sends key exchange information and requests
the client's certificate. Finally, the server sends a Server Done message
indicating that it has completed its part of the handshake.

This phase ensures that the client is communicating with a legitimate server.

Phase 3: Client Authentication and Key Exchange

If requested, the client sends its digital certificate to the server. It then sends
the Client Key Exchange message, which contains the information necessary
to generate a shared secret key.

If client authentication is required, the client also sends a Certificate Verify

message to prove ownership of its private key.

Both the client and the server now independently generate the same shared
secret.

Phase 4: Finish

The client sends a Change Cipher Spec message followed by a Finished

message. The server performs the same operation.

These messages confirm that both parties have successfully established the
same encryption keys and security parameters. After this phase, secure
application data transmission begins.

Cryptographic Computations in SSL

SSL generates encryption keys using two stages.

1. Pre-Master Secret

The Pre-Master Secret is generated during the key exchange process using
RSA or Diffie-Hellman algorithms. It is securely shared between the client and
the server.

2. Master Secret

Both the client and the server independently compute a common 48-byte
Master Secret using the Pre-Master Secret and random numbers exchanged
during the handshake.

The Master Secret is then used to generate:

  Client Write Key
 Server Write Key
 Client MAC Secret
 Server MAC Secret
 Initialization Vectors (IVs)

These parameters are used to protect all future communication.

Advantages of SSL

 Provides secure communication over insecure networks.

 Encrypts confidential information during transmission.
 Ensures message integrity using Message Authentication Codes.
 Authenticates clients and servers using digital certificates.
 Prevents eavesdropping, tampering, and impersonation attacks.
 Increases user confidence in online applications and services.

Disadvantages of SSL

 Encryption and decryption increase processing overhead.

 The handshake process introduces additional communication delay.
 SSL requires proper management of digital certificates.
 Older versions of SSL contain security vulnerabilities and are no longer
recommended.

Applications of SSL

SSL is widely used in many Internet-based applications, including:

 HTTPS secure websites

 Online banking systems
 E-commerce websites
 Online payment gateways
 Email security
 Secure file transfer
 Cloud computing services
 Web servers and enterprise applications

Conclusion

Secure Sockets Layer (SSL) is one of the most important transport-layer

security protocols used to protect communication over the Internet. It provides
confidentiality, integrity, and authentication through encryption, Message
Authentication Codes, and digital certificates. The SSL architecture, including
the Record Protocol, Handshake Protocol, Change Cipher Spec Protocol, and
Alert Protocol, works together to establish secure communication between
clients and servers. Although SSL has been replaced by TLS, its fundamental
concepts continue to form the basis of secure Internet communication and are
widely used in modern web applications.
Transport Layer Security (TLS)

Introduction

Transport Layer Security (TLS) is the Internet standard security protocol

developed by the Internet Engineering Task Force (IETF) as the successor
to Secure Sockets Layer (SSL). TLS provides secure communication between
clients and servers by ensuring confidentiality, integrity, authentication,
and data security over the Internet.

TLS is defined in RFC 5246 and is widely used in applications such as

HTTPS, online banking, e-commerce, cloud computing, email security, and
secure file transfer. Although TLS is based on SSL version 3.0, it includes
several improvements in security, cryptographic algorithms, and protocol
design to overcome the weaknesses of SSL.

Need for TLS

As Internet communication became more common, stronger security

mechanisms were required to protect sensitive information from attackers.
SSL had several security limitations and vulnerabilities, which led to the
development of TLS.

TLS is required for the following reasons:

 To provide secure communication over public networks.

 To protect confidential information using strong encryption.
 To ensure data integrity during transmission.
 To authenticate clients and servers using digital certificates.
 To replace the security weaknesses present in SSL.
 To support modern cryptographic algorithms and stronger security
mechanisms.

Version Number

The TLS Record Format is almost identical to the SSL Record Format. The
structure of the record header and its fields remain the same. The only major
difference is the protocol version number.

For the version defined in RFC 5246, the protocol version is:

 Major Version : 3
 Minor Version : 3

This version number identifies the communication as TLS instead of SSL

while maintaining compatibility with previous protocol formats.

Message Authentication Code (MAC)

TLS uses a stronger Message Authentication Code (MAC) mechanism than
SSL to ensure message integrity and authentication.

Unlike SSL, which uses its own MAC algorithm, TLS uses the HMAC (Hash-
based Message Authentication Code) algorithm defined in RFC 2104.

The HMAC algorithm combines:

 Secret key
 Hash function (MD5 or SHA-1)
 Padding values

to generate a secure authentication code for every transmitted message.

The MAC is calculated over the following fields:

 Sequence Number
 Record Type
 Protocol Version
 Length of Data
 Actual Data Fragment

Including the protocol version in the MAC calculation provides additional

protection against protocol manipulation attacks.

Pseudorandom Function (PRF)

TLS introduces a Pseudorandom Function (PRF) for generating

cryptographic values.

The PRF expands a small shared secret into a larger amount of secure
random data required for encryption and authentication.

The PRF is mainly used for:

 Master Secret Generation

 Session Key Generation
 Key Validation
 Cryptographic Parameter Generation

The PRF is based on the HMAC algorithm and uses either MD5 or SHA-1 as
the underlying hash function.

Its main objective is to generate secure random values that are resistant to
cryptographic attacks.

Alert Codes

TLS supports almost all the alert messages available in SSL but also
introduces several new alert codes to improve error handling and security.
Unlike SSL, TLS does not support the No Certificate alert.

TLS defines several additional fatal alerts.

Record Overflow

This alert is generated when the received TLS record exceeds the maximum
allowed size.

Unknown Certificate Authority (Unknown CA)

This alert occurs when the received certificate is issued by an unknown or

untrusted Certificate Authority.

Access Denied

This alert is generated when a valid certificate is received, but the server
denies access because the user does not have sufficient permissions.

Decode Error

This alert indicates that the received message cannot be decoded correctly
because of invalid data or incorrect message length.

Protocol Version

This alert is generated when the client requests a TLS version that the server
does not support.

Insufficient Security

This alert occurs when the client supports only weak encryption algorithms
while the server requires stronger security.

Unsupported Extension

This alert indicates that the server has sent an extension that was not
requested or supported by the client.

Internal Error

This alert represents an unexpected internal system error that prevents the
TLS session from continuing.

Decrypt Error

This alert occurs when TLS fails to decrypt data correctly or cannot verify a
digital signature.

Other Alert Messages

TLS also supports warning alerts such as:

 User Cancelled
 No Renegotiation

These alerts do not terminate the connection immediately but notify the other
party about specific conditions.

Cipher Suites

A Cipher Suite defines the collection of cryptographic algorithms used during

TLS communication.

A TLS Cipher Suite specifies:

 Key Exchange Algorithm

 Symmetric Encryption Algorithm
 Message Authentication Algorithm
 Hash Algorithm

TLS supports almost all cipher suites available in SSL but introduces several
improvements.

Key Exchange

TLS supports:

 RSA
 Fixed Diffie-Hellman
 Ephemeral Diffie-Hellman
 Anonymous Diffie-Hellman

However, TLS removes support for the Fortezza key exchange method
because it is outdated.

Symmetric Encryption Algorithms

TLS supports symmetric encryption algorithms such as:

 AES
 DES
 Triple DES (3DES)
 RC2
 RC4

The Fortezza encryption algorithm available in SSL is removed from TLS.

Client Certificate Types

TLS defines several certificate types that can be requested by the server
during client authentication.

The commonly supported certificate types are:

 RSA Sign
 DSS Sign
 RSA Fixed Diffie-Hellman
 DSS Fixed Diffie-Hellman

Unlike SSL, TLS does not define separate certificate types for Ephemeral
Diffie-Hellman because the normal RSA and DSS signature types are
sufficient.

TLS also removes support for Fortezza certificates.

Certificate Verify and Finished Messages

TLS simplifies the Certificate Verify process compared to SSL.

In TLS, the Certificate Verify message calculates MD5 and SHA-1 hashes
only over the handshake messages.

Unlike SSL, the Master Secret and padding values are not included because
they do not provide additional security.

The Finished Message is generated using:

 Master Secret
 Handshake Messages
 Client or Server Label

The Finished Message confirms that:

 Authentication was successful.

 Key exchange was completed correctly.
 Both client and server generated the same secret key.

Cryptographic Computations

TLS performs cryptographic computations to generate secure encryption keys

for communication.

Pre-Master Secret

The Pre-Master Secret is generated during the key exchange process using
algorithms such as RSA or Diffie-Hellman.

Both communicating parties securely exchange this secret.

Master Secret Generation

TLS generates a 48-byte Master Secret from:

 Pre-Master Secret
 Client Random Number
 Server Random Number

Unlike SSL, TLS uses the Pseudorandom Function (PRF) to generate the
Master Secret, making the computation more secure.

Key Block Generation

After generating the Master Secret, TLS creates a Key Block using the PRF.

The Key Block contains:

 Client MAC Secret

 Server MAC Secret
 Client Encryption Key
 Server Encryption Key
 Initialization Vectors (IVs)

These keys are used to encrypt and authenticate all communication during
the TLS session.

Padding

Padding is used to ensure that encrypted data becomes an exact multiple of

the block size required by the encryption algorithm.

In SSL, only the minimum required padding is added.

In TLS, the amount of padding can vary from the minimum value up to 255
bytes, provided the final encrypted block size remains a multiple of the cipher
block length.

Variable padding improves security because attackers cannot easily estimate

the actual message length, making traffic analysis attacks more difficult.

Advantages of TLS

 Provides stronger security than SSL.

 Uses the secure HMAC algorithm for message authentication.
 Generates secure cryptographic keys using the PRF.
 Supports stronger encryption algorithms.
 Authenticates communicating parties using digital certificates.
 Protects against replay attacks and message tampering.
 Supports secure online communication and transactions.
Disadvantages of TLS

 Handshake process increases communication overhead.

 Encryption and decryption require additional processing time.
 Certificate management increases implementation complexity.
 Older TLS versions may contain known security vulnerabilities if not
updated.

Applications of TLS

TLS is widely used in various Internet applications, including:

 HTTPS secure web browsing

 Online banking systems
 E-commerce websites
 Email security
 Virtual Private Networks (VPNs)
 Cloud computing services
 Secure file transfer
 Enterprise web applications
 Online payment gateways

Conclusion

Transport Layer Security (TLS) is the modern standard protocol for providing
secure communication over the Internet. It improves upon SSL by introducing
stronger message authentication, a secure Pseudorandom Function (PRF),
enhanced alert handling, improved cryptographic computations, and better
key generation techniques. TLS ensures confidentiality, integrity,
authentication, and secure key management, making it the preferred
protocol for securing web applications, online banking, cloud services, e-
commerce, and other Internet-based communication systems.

HTTPS (Hypertext Transfer Protocol Secure)

Introduction

HTTPS (Hypertext Transfer Protocol Secure) is the secure version of HTTP

that combines HTTP with SSL (Secure Sockets Layer) or TLS (Transport
Layer Security) to provide secure communication between a web browser
and a web server. It ensures that the data exchanged between the client and
the server remains confidential, authentic, and protected from unauthorized
access.

HTTPS capability is built into all modern web browsers. However, its use
depends on whether the web server supports HTTPS communication. Most
websites that handle sensitive information, such as banking, e-commerce,
and online payment systems, use HTTPS to provide secure communication.
The main difference visible to the user is that the website address begins with
https:// instead of [Link] While a normal HTTP connection uses Port 80,
HTTPS uses Port 443, which automatically invokes the SSL/TLS protocol to
establish a secure connection before any data is transmitted.

When HTTPS is used, several important parts of the communication are

encrypted to protect them from attackers. These include:

 URL of the requested document – The address of the requested web

page is encrypted to prevent attackers from identifying the requested
resource.
 Contents of the document – The complete web page returned by the
server is encrypted during transmission.
 Contents of browser forms – Information entered by users, such as
usernames, passwords, personal details, and payment information, is
encrypted before transmission.
 Cookies – Cookies exchanged between the browser and the server
are encrypted, preventing attackers from stealing session information.
 Contents of the HTTP header – The HTTP request and response
headers are encrypted, protecting protocol-related information.

HTTPS is defined in RFC 2818, titled HTTP Over TLS. There is no major
difference between using HTTP over SSL or HTTP over TLS, and both
implementations are commonly referred to as HTTPS.

Connection Initiation

In HTTPS communication, the web browser acts as both an HTTP client and
a TLS client. To establish secure communication, the client first initiates a
connection to the server using Port 443, which is reserved for HTTPS.

The browser begins the TLS handshake by sending a ClientHello message

to the server. This message starts the process of negotiating security
parameters such as encryption algorithms, protocol version, and session
information. The server responds with the necessary handshake messages,
including its digital certificate, allowing both parties to authenticate each other
and establish shared secret keys.

Once the TLS handshake is successfully completed, a secure session is

established between the client and the server. Only after this secure session
is created does the client send the first HTTP request. All HTTP requests and
responses are then transmitted as TLS application data, ensuring that the
communication remains encrypted and secure.

HTTPS communication involves three levels of connection:

1. HTTP Level
At the HTTP level, the web browser requests a connection to the web server
by sending an HTTP request to the lower communication layer. Depending on
the protocol used, the lower layer may be TCP or TLS/SSL.

2. TLS Level

At the TLS level, a secure session is established between the TLS client and
the TLS server. A single TLS session can support one or more secure
connections, reducing the overhead of establishing new sessions for every
request.

3. TCP Level

TLS operates on top of TCP. Therefore, before the TLS handshake begins, a
reliable TCP connection must first be established between the client and the
server. Once the TCP connection is available, TLS establishes the secure
session, after which HTTP communication takes place through the encrypted
channel.

Connection Closure

After the communication between the client and the server is completed, the
HTTPS connection must be terminated securely.

At the HTTP level, either the client or the server can indicate that the
connection should be closed by including the following header in the HTTP
message:

Connection: close

This header informs the receiving party that the connection will be closed after
the current HTTP message has been delivered.

At the TLS level, the connection is closed using the TLS Alert Protocol.
Before terminating the connection, both the client and the server exchange a
close_notify alert message. This alert informs the other party that no more
encrypted data will be sent and that the connection is being closed normally.

After sending the close_notify alert, a TLS implementation may immediately

close the underlying TCP connection without waiting for the peer's close
notification. This is known as an incomplete close. Such an approach is
acceptable only when the application is certain that all required HTTP data
has already been received.

Sometimes, the underlying TCP connection may terminate unexpectedly

without receiving either a close_notify alert or a Connection: close header.
This situation may occur because of a server programming error, a network
communication failure, or an unexpected interruption in the TCP connection.
However, an unexpected TCP termination may also indicate a possible
security attack. Therefore, HTTPS clients should be capable of detecting such
abnormal connection closures and should display an appropriate security
warning to alert the user about the unexpected termination.

Conclusion

HTTPS is a secure communication protocol that combines HTTP with

SSL/TLS to provide secure communication between web browsers and web
servers. It encrypts important information such as URLs, web page contents,
browser form data, cookies, and HTTP headers, thereby protecting data from
unauthorized access and modification. Through secure connection initiation
using the TLS handshake and proper connection closure using the
close_notify alert, HTTPS ensures reliable and secure communication over
the Internet.

Secure Shell (SSH)

Introduction

Secure Shell (SSH) is a network security protocol designed to provide secure

communication over a network. It was developed as a simple and cost-
effective protocol to replace insecure remote login protocols such as TELNET,
which transmit data in plain text without any security.

The first version, SSH1, mainly provided secure remote login services. Later,
SSH2 was introduced to overcome the security weaknesses present in SSH1.
SSH2 is defined by the Internet Engineering Task Force (IETF) in RFC
4250 to RFC 4256 and is the version widely used today.

Besides remote login, SSH also provides secure services such as file
transfer, e-mail communication, remote command execution, and secure
tunneling. Due to its strong security features, SSH has become the preferred
protocol for secure remote administration and encrypted communication
across different operating systems.

SSH Architecture

SSH is organized into three protocols that operate on top of the TCP
protocol. Each protocol performs a specific function to provide secure
communication.

1. Transport Layer Protocol

The Transport Layer Protocol is responsible for establishing a secure

connection between the client and the server. It provides server
authentication, data confidentiality, data integrity, and forward secrecy.
Forward secrecy ensures that if a session key is compromised, the security of
previous sessions is not affected. This layer may also support data
compression to improve communication efficiency.
2. User Authentication Protocol

The User Authentication Protocol verifies the identity of the client before
access to the server is granted. It ensures that only authorized users can use
SSH services.

3. Connection Protocol

The Connection Protocol allows multiple logical communication channels to

operate simultaneously over a single secure SSH connection. This enables
several applications, such as terminal sessions and file transfers, to share the
same encrypted connection.

Transport Layer Protocol

The Transport Layer Protocol is the foundation of SSH because it establishes

a secure and authenticated communication channel between the client and
the server.

Its main responsibilities are:

 Server Authentication
 Key Exchange
 Data Encryption
 Message Integrity
 Optional Data Compression

Host Keys

Server authentication in SSH is based on public-key cryptography. Every

SSH server possesses a public key and a private key, collectively known as
the Host Key.

The server uses its private key to prove its identity during the key exchange
process. Before establishing communication, the client must verify the
server's public key.

SSH supports two trust models for host key verification.

1. Local Database Method

The client maintains a local database that stores the public key corresponding
to each server hostname.

Advantages

 No central authority is required.

 Easy to implement in small networks.

Disadvantages
  Difficult to maintain as the number of servers increases.

2. Certificate Authority (CA) Method

In this method, the server's public key is certified by a trusted Certificate

Authority (CA). The client stores only the CA's public key and verifies the
server's certificate using it.

Advantages

 Easier to manage in large organizations.

 Better scalability.

Disadvantages

 Requires a trusted Certificate Authority.

Packet Exchange

The SSH Transport Layer Protocol establishes secure communication through

a sequence of packet exchanges.

Step 1: TCP Connection

The client first establishes a TCP connection with the server. This step is
performed by TCP and is not part of the SSH protocol.

Step 2: Identification String Exchange

The client sends an identification string containing the SSH protocol version
and software version.

The server replies with its own identification string. These identification strings
are later used during the Diffie-Hellman key exchange process.

Step 3: Algorithm Negotiation

Both the client and the server exchange SSH_MSG_KEXINIT messages

containing the list of supported cryptographic algorithms.

The negotiated algorithms include:

 Key Exchange Algorithm

 Encryption Algorithm
 Message Authentication Code (MAC) Algorithm
 Compression Algorithm

The first algorithm supported by both the client and the server is selected.

Step 4: Key Exchange

SSH uses the Diffie-Hellman Key Exchange Algorithm to generate a
shared secret key.

During this process:

 The client generates a random number and sends its public value.
 The server generates its own random number.
 Both parties independently calculate the same shared secret key.
 The server signs part of the exchange using its private key to prove its
identity.
 The client verifies the server's signature.

At the end of this process:

 Both client and server share the same secret key.

 The server is authenticated.
 A unique session identifier is generated.

Step 5: New Keys

After key exchange, both sides exchange SSH_MSG_NEWKEYS messages.

From this point onward, all communication is encrypted using the negotiated
keys.

Step 6: Service Request

Finally, the client sends an SSH_MSG_SERVICE_REQUEST message

requesting either the User Authentication Protocol or the Connection
Protocol.

After this stage, all communication is encrypted and protected using Message
Authentication Codes (MACs).

SSH Packet Format

Each SSH packet consists of the following fields:

 Packet Length – Indicates the total packet size.

 Padding Length – Specifies the size of the random padding.
 Payload – Contains the actual transmitted data.
 Random Padding – Random bytes added to make the packet size a
multiple of the encryption block size.
 Message Authentication Code (MAC) – Ensures data integrity and
verifies that the packet has not been modified during transmission.

Once encryption has been negotiated, the complete packet except the MAC
field is encrypted before transmission.

Key Generation
After completing the key exchange, SSH generates several cryptographic
keys from the shared secret key (K), the hash value (H), and the session
identifier.

The generated keys include:

 Initial Initialization Vector (IV) from Client to Server.

 Initial Initialization Vector (IV) from Server to Client.
 Encryption Key from Client to Server.
 Encryption Key from Server to Client.
 Integrity (MAC) Key from Client to Server.
 Integrity (MAC) Key from Server to Client.

These keys are used to encrypt transmitted data and verify message integrity
throughout the SSH session.

User Authentication Protocol

The User Authentication Protocol verifies the identity of the client before
access is granted to the server.

The authentication process follows these steps:

1. The client sends an authentication request with the username.

2. The server verifies whether the username is valid.
3. If additional authentication is required, the server sends the list of
supported authentication methods.
4. The client selects one authentication method and submits the required
credentials.
5. If authentication succeeds, the server grants access by sending a
success message.

Authentication Methods

SSH supports three authentication methods.

Public Key Authentication

The client sends its public key along with a digital signature created using its
private key. The server verifies the signature before granting access.

Password Authentication

The client sends its password to the server. The password is protected
because it is transmitted through the encrypted SSH channel.

Host-Based Authentication
Instead of authenticating the individual user, the server authenticates the
client's host computer. The client host signs the authentication request using
its private key.

Connection Protocol

The SSH Connection Protocol operates after successful user authentication. It

allows multiple secure communication channels to be established over a
single SSH connection.

Channel Mechanism

Each SSH communication, such as a terminal session or file transfer, uses a

separate logical channel.

The life cycle of a channel consists of three stages:

Opening a Channel

Either the client or the server can request a new communication channel by
sending an SSH_MSG_CHANNEL_OPEN message.

Data Transfer

Once the channel is established, encrypted data is exchanged using

SSH_MSG_CHANNEL_DATA messages.

Closing a Channel

When communication is completed, either side closes the channel by sending

an SSH_MSG_CHANNEL_CLOSE message.

Channel Types

SSH supports four channel types.

 Session – Used for remote login, command execution, and file transfer.
 X11 – Used for graphical applications based on the X Window System.
 Forwarded TCP/IP – Used for remote port forwarding.
 Direct TCP/IP – Used for local port forwarding.

Port Forwarding

One of the most useful features of SSH is Port Forwarding, also called SSH
Tunneling. It allows an insecure TCP connection to be converted into a
secure encrypted SSH connection.

SSH supports two types of port forwarding.

Local Port Forwarding

In local port forwarding, the SSH client intercepts traffic from a local
application and redirects it through the encrypted SSH tunnel to the
destination server.

For example, an email client using POP3 (Port 110) can securely
communicate with the mail server through an SSH tunnel.

Remote Port Forwarding

In remote port forwarding, the SSH server receives traffic and forwards it
securely through the SSH tunnel to the client.

This technique is useful when a server is protected by a firewall and cannot

accept incoming SSH connections directly. By creating an outgoing SSH
connection first, secure remote access can still be established.

Conclusion

Secure Shell (SSH) is a secure network protocol that provides encrypted

communication, secure remote login, file transfer, and port forwarding over
TCP. Its three protocols—Transport Layer Protocol, User Authentication
Protocol, and Connection Protocol—work together to provide
authentication, confidentiality, integrity, and secure communication. Features
such as Diffie-Hellman key exchange, public-key authentication,
encrypted channels, and SSH tunneling make SSH one of the most widely
used protocols for secure remote access and network administration.

Pretty Good Privacy (PGP)

Introduction

Pretty Good Privacy (PGP) is a security software developed by Phil

Zimmermann to provide confidentiality and authentication for electronic
mail and file storage. It combines the best available cryptographic algorithms
into a simple, user-friendly application that works on different operating
systems and processors.

Zimmermann made PGP freely available over the Internet along with its
source code. Later, a commercial version was developed that was fully
compatible with the free version and provided vendor support.

PGP became widely popular because:

 It is freely available and works on various platforms such as Windows,

UNIX, and Macintosh.
 It uses strong and publicly tested cryptographic algorithms such as
RSA, DSS, Diffie-Hellman, CAST-128, IDEA, 3DES, and SHA-1.
 It is suitable for both organizations and individual users for secure
communication.
  It is independent of government control, making it attractive to many
users.
 It is recognized as an Internet standard through RFC 3156 (MIME
Security with OpenPGP).

Notation Used in PGP

The following symbols are commonly used in PGP.

 Ks – Session key used for symmetric encryption.

 PRa – Private key of user A.
 PUa – Public key of user A.
 EP – Public-key encryption.
 DP – Public-key decryption.
 EC – Symmetric encryption.
 DC – Symmetric decryption.
 H – Hash function.
 Z – Compression using the ZIP algorithm.
 R64 – Conversion to Radix-64 ASCII format.

Note: In PGP, the term private key is preferred instead of

secret key to avoid confusion with symmetric encryption keys.

Operational Description

The operation of PGP mainly provides four services:

1. Authentication
2. Confidentiality
3. Compression
4. E-mail Compatibility

1. Authentication

Authentication ensures that the received message is genuine and has not
been modified during transmission. PGP provides authentication using digital
signatures.

Steps of Authentication

1. The sender creates the message.

2. A SHA-1 hash function generates a 160-bit message digest.
3. The hash value is encrypted using RSA with the sender's private key to
create the digital signature.
4. The digital signature is attached to the message.
5. The receiver decrypts the signature using the sender's public key.
6. The receiver also generates a new hash value from the received
message.
7. If both hash values are identical, the message is accepted as authentic.
PGP also supports DSS/SHA-1 as an alternative digital signature algorithm.

Detached Signature

PGP also supports Detached Signatures, where the signature is stored

separately from the original message.

Detached signatures are useful because:

 They allow users to maintain a separate signature log.

 They help detect virus infection in executable programs.
 They allow multiple users to sign the same document independently.

2. Confidentiality

Confidentiality ensures that only the intended receiver can read the message.

PGP uses CAST-128 as the default symmetric encryption algorithm. It also

supports IDEA and 3DES.

A new random 128-bit session key is generated for every message. Since
the key is used only once, it is called a one-time session key.

Steps of Confidentiality

1. The sender creates the message.

2. A random 128-bit session key is generated.
3. The message is encrypted using CAST-128 (or IDEA/3DES).
4. The session key is encrypted using the receiver's public key through
RSA (or ElGamal).
5. The encrypted session key is attached to the encrypted message.
6. The receiver decrypts the session key using its private key.
7. The recovered session key is then used to decrypt the message.

Advantages

 Symmetric encryption is much faster than public-key encryption.

 Public-key encryption securely distributes the session key.
 Every message uses a different session key, increasing security.
 Even if one session key is compromised, other messages remain
secure.

3. Confidentiality and Authentication

PGP can provide both confidentiality and authentication for the same
message.

The operations are performed in the following order:

1. The sender first generates a digital signature using the private key.
 2. The signed message is encrypted using a randomly generated session
key.
3. The session key is encrypted using the receiver's public key.
4. The receiver decrypts the session key, decrypts the message, and
verifies the digital signature.

This sequence is preferred because:

 The signature remains associated with the original plaintext.

 Third parties can verify the signature without needing the session key.

4. Compression

PGP automatically compresses the message after generating the digital

signature but before encryption.

The compression algorithm used is ZIP.

Advantages of Compression

 Reduces storage space.

 Reduces transmission time.
 Removes redundancy from the plaintext.
 Makes cryptanalysis more difficult, thereby improving security.

Why Compression is Performed Before Encryption

 The signature should be generated before compression so that the

original message can be verified later.
 Compression before encryption improves encryption strength because
compressed data contains less redundancy.

5. E-mail Compatibility

Many e-mail systems can transmit only ASCII text. However, encrypted PGP
messages contain binary data that cannot be transmitted directly.

To solve this problem, PGP uses Radix-64 Conversion.

Radix-64 Conversion

 Converts binary data into printable ASCII characters.

 Converts every 3 bytes of binary data into 4 ASCII characters.
 Appends a CRC (Cyclic Redundancy Check) to detect transmission
errors.

Although Radix-64 increases the message size by approximately 33%, the

earlier ZIP compression usually compensates for this increase, so the final
message size remains relatively small.
Overall Working of PGP

The complete working of PGP follows these steps:

Sender Side

1. Create the plaintext message.

2. Generate a digital signature using SHA-1 and RSA (or DSS).
3. Compress the signed message using ZIP.
4. Generate a one-time session key.
5. Encrypt the compressed message using CAST-128 (or IDEA/3DES).
6. Encrypt the session key using the receiver's public key.
7. Convert the encrypted data into ASCII format using Radix-64.
8. Send the encrypted message.

Receiver Side

1. Convert the received Radix-64 data back into binary.

2. Decrypt the session key using the receiver's private key.
3. Decrypt the encrypted message using the session key.
4. Decompress the message using ZIP.
5. Verify the digital signature using the sender's public key.
6. If the hash values match, the message is accepted as authentic.

Conclusion

Pretty Good Privacy (PGP) is a widely used e-mail and file security system
that provides authentication, confidentiality, compression, and e-mail
compatibility. It combines public-key encryption, symmetric encryption,
digital signatures, hashing, ZIP compression, and Radix-64 encoding to
ensure secure, reliable, and efficient communication. Its strong cryptographic
algorithms and ease of use have made it one of the most trusted security
solutions for electronic communication.

S/MIME (Secure/Multipurpose Internet Mail Extension)

Definition

S/MIME (Secure/Multipurpose Internet Mail Extension) is an e-mail security

standard that provides encryption, digital signatures, authentication, and
data integrity for MIME-based e-mail. It is widely used in organizations and
commercial applications.

1. RFC 5322 (Internet Message Format)

Definition

RFC 5322 defines the standard format for Internet e-mail messages.

Structure of RFC 5322 Message

 1. Header – Contains sender, receiver, subject, date, etc.
2. Blank Line – Separates header and body.
3. Body – Contains the actual message.

Common Header Fields

 From
 To
 Subject
 Date
 Message-ID

2. MIME (Multipurpose Internet Mail Extensions)

Definition

MIME is an extension of RFC 5322 that allows e-mails to send multimedia

and binary files.

Need for MIME

SMTP has several limitations:

 Cannot send binary files.

 Cannot send images, audio, or video directly.
 Supports only 7-bit ASCII characters.
 Cannot handle large files efficiently.
 Causes character conversion problems.

MIME removes these limitations.

3. Features of MIME

MIME provides:

 Multimedia e-mail support.

 Binary file transfer.
 Multiple attachments.
 International language support.
 Standard encoding methods.

4. MIME Header Fields

Header Field Purpose

MIME-Version Indicates MIME version (1.0)
Content-Type Specifies data type
Content-Transfer-Encoding Specifies encoding method
Content-ID Uniquely identifies MIME object
 Header Field Purpose
Content-Description Description of attached object

5. MIME Content Types

Type Purpose
Text Plain or formatted text
Multipart Multiple body parts
Message Embedded message
Image JPEG, GIF images
Audio Sound files
Video MPEG videos
Application Binary files like PDF, ZIP, EXE

6. MIME Transfer Encoding

Encoding converts binary data into mail-safe text.

Types

 7bit – Standard ASCII

 8bit – ASCII + extended characters
 Binary – Raw binary data
 Quoted-Printable – Mostly text with few special characters
 Base64 – Converts binary data into printable ASCII
 x-token – Custom encoding

7. Canonical Form

Definition

Canonical form is the standard format used before applying S/MIME security.

Types

Native Form

 Original system format.

 Depends on operating system.

Canonical Form

 Standardized format used for secure transmission.

8. Functions of S/MIME
S/MIME provides four major services.

1. Enveloped Data

 Encrypts the message.

 Uses recipient's public key.
 Provides confidentiality.

2. Signed Data

 Digitally signs the message.

 Ensures authentication and integrity.
 Only S/MIME users can verify it.

3. Clear Signed Data

 Message remains readable.

 Only signature is encoded.
 Non-S/MIME users can read the message but cannot verify it.

4. Signed and Enveloped Data

 Message is first signed.

 Then encrypted.
 Provides confidentiality, authentication, integrity, and non-repudiation.

9. Cryptographic Algorithms Used in S/MIME

Purpose Algorithm
Hash Function SHA-1 (MD5 for compatibility)
Digital Signature DSS, RSA
Session Key Encryption RSA, Diffie-Hellman (ElGamal)
Message Encryption Triple DES, AES, RC2

10. S/MIME Message Preparation

For Encrypted Message

1. Generate random session key.

2. Encrypt message using Triple DES/AES.
3. Encrypt session key using recipient's RSA public key.
4. Attach encrypted session key.
5. Encode using Base64.

For Signed Message

1. Generate message hash using SHA-1.

2. Encrypt hash with sender's private key.
 3. Attach digital signature.
4. Encode using Base64.
5. Receiver verifies using sender's public key.

11. S/MIME Certificate Processing

S/MIME uses X.509 Version 3 Digital Certificates.

User Responsibilities

 Generate public/private keys.

 Register public key with Certification Authority (CA).
 Store certificates securely.
 Verify received certificates.

12. VeriSign Digital Certificates

VeriSign is a Certification Authority (CA) that issues Digital IDs.

Certificate Contains

 Public key
 Owner name
 Expiry date
 Certificate serial number
 CA name
 CA digital signature

VeriSign Certificate Classes

Class Verification Level Applications

Class
Email verification Basic email security
1
Class
Identity verification Secure email, online services
2
Class Personal verification with Banking, e-commerce, business
3 documents security

13. Enhanced Security Services

Signed Receipts

 Confirms message delivery.

 Provides proof that recipient received the message.

Security Labels

 Specifies confidentiality level.

  Used for access control.
 Examples: Secret, Confidential, Restricted.

Secure Mailing Lists

 Uses a Mail List Agent (MLA).

 Encrypts one message separately for multiple recipients.
 Reduces sender workload.

Advantages of S/MIME

 Provides confidentiality through encryption.

 Ensures authentication using digital signatures.
 Maintains message integrity.
 Supports multimedia attachments.
 Uses trusted X.509 certificates.
 Widely supported by commercial email systems.

Disadvantages of S/MIME

 Requires digital certificates.

 Certificate management is complex.
 Higher computational overhead.
 Depends on Certification Authorities.

IP Security (IPsec) Overview

Definition

IP Security (IPsec) is a collection of security protocols that provides

authentication, encryption, confidentiality, integrity, and secure key
management at the IP (Network) layer. It secures communication over
LANs, WANs, and the Internet.

Need for IPsec

In 1994, the Internet Architecture Board (IAB) recommended adding

security features to Internet Protocol because the Internet lacked built-in
security.

The main objectives were:

 Protect network traffic from unauthorized access.

 Authenticate communicating devices.
 Encrypt data during transmission.
 Secure end-to-end communication.

These security features became part of IPv6 and were later made compatible
with IPv4.
Applications of IPsec

1. Secure Branch Office Connectivity

 Connects branch offices securely over the Internet.

 Creates a Virtual Private Network (VPN).
 Reduces the need for expensive private leased lines.

Example: A bank securely connects all its branches through the Internet.

2. Secure Remote Access

 Allows employees working from home or while traveling to securely

access the company's network.
 Uses an Internet connection instead of costly direct telephone lines.

Example: A software employee securely accesses office files from home.

3. Extranet and Intranet Security

 Secures communication between an organization and its business

partners.
 Provides authentication, confidentiality, and secure key exchange.

Example: A manufacturer securely shares production data with suppliers.

4. Electronic Commerce Security

 Adds an extra security layer for online shopping and banking.

 Encrypts and authenticates all IP traffic.

Example: Secure online payment transactions.

Benefits of IPsec

1. Strong Network Security

Provides encryption and authentication for all network traffic crossing routers
or firewalls.

2. Prevents Unauthorized Access

If all Internet traffic passes through an IPsec-enabled firewall, attackers

cannot bypass security.

3. Transparent to Applications

Applications like email, web browsers, FTP, and file sharing work normally
without modification.
4. Transparent to Users

Users do not need to manually manage encryption keys or security settings.

5. Protects Individual Users

Provides secure communication for remote employees and sensitive

departments.

Routing Applications of IPsec

IPsec secures routing communication by ensuring that:

 Router advertisements come from authorized routers.

 Neighbor advertisements are genuine.
 Redirect messages are authentic.
 Routing updates are not forged.

This prevents attackers from redirecting or interrupting network traffic.

IPsec Documents (RFC Categories)

1. Architecture

Defines the overall IPsec framework and security mechanisms.

RFC: 4301

2. Authentication Header (AH)

Provides message authentication and integrity.

RFC: 4302

Note: AH is now deprecated because ESP also provides authentication.

3. Encapsulating Security Payload (ESP)

Provides encryption, authentication, and confidentiality.

RFC: 4303

4. Internet Key Exchange (IKE)

Performs secure key exchange between communicating devices.

RFC: 5996 (IKEv2)

5. Cryptographic Algorithms
Defines encryption, hashing, authentication, and key exchange algorithms.

6. Other RFCs

Cover security policies and management information.

IPsec Services

1. Access Control

Allows only authorized users to access network resources.

2. Connectionless Integrity

Ensures data is not modified during transmission.

3. Data Origin Authentication

Verifies that the sender is genuine.

4. Replay Protection

Rejects duplicate packets sent by attackers.

5. Confidentiality

Encrypts data so unauthorized users cannot read it.

6. Traffic Flow Confidentiality

Hides communication patterns to prevent traffic analysis.

IPsec Protocols

1. Authentication Header (AH)

Provides:

 Authentication
 Data Integrity
 Replay Protection

Does not provide encryption.

2. Encapsulating Security Payload (ESP)

Provides:

 Encryption
 Authentication
  Integrity
 Confidentiality

ESP is the most commonly used IPsec protocol.

Modes of IPsec

1. Transport Mode

Definition:
Transport mode protects only the data (payload) of the IP packet. The
original IP header remains unchanged.

Features

 Encrypts only the payload.

 Used for host-to-host communication.
 Faster because less data is encrypted.

Example: A laptop securely communicates with a web server.

Advantages

 Lower overhead.
 Faster performance.
 Suitable for end-to-end communication.

2. Tunnel Mode

Definition:
Tunnel mode protects the entire original IP packet by encrypting it and
placing it inside a new IP packet.

Features

 Encrypts both the IP header and payload.

 Adds a new outer IP header.
 Used between routers, gateways, and firewalls.

Example: Two company branches connected through a VPN.

Advantages

 Provides higher security.

 Hides internal IP addresses.
 Ideal for VPNs.

Advantages of IPsec

 Provides strong encryption.

  Ensures authentication.
 Protects data integrity.
 Prevents replay attacks.
 Works transparently with applications.
 Supports secure VPN communication.
 Secures LAN, WAN, and Internet communication.

Disadvantages of IPsec

 Complex configuration.
 Slightly reduces network performance due to encryption.
 Requires proper key management.
 Additional processing overhead.

Conclusion

IPsec is a network-layer security protocol suite that protects IP

communications through authentication, encryption, integrity checking,
replay protection, and secure key exchange. It is widely used for VPNs,
secure remote access, branch office connectivity, and secure Internet
communication, making it one of the most important technologies for
network security.

Encapsulating Security Payload (ESP)

Definition

Encapsulating Security Payload (ESP) is an IPsec protocol that provides

confidentiality (encryption), authentication, data integrity, anti-replay
protection, and limited traffic flow confidentiality. It is the most widely
used IPsec protocol because it supports both encryption and authentication.

The security services provided by ESP depend on the options selected during
the establishment of the Security Association (SA).

Features of ESP

 Provides data confidentiality through encryption.

 Provides data origin authentication.
 Ensures connectionless integrity.
 Protects against replay attacks.
 Provides limited traffic flow confidentiality.
 Supports various encryption and authentication algorithms such as
AES and GCM.

ESP Packet Format

An ESP packet contains the following fields:

1. Security Parameters Index (SPI)

  32-bit field.
 Identifies the Security Association (SA) used for the packet.

2. Sequence Number

 32-bit counter value.

 Increases with every transmitted packet.
 Used to prevent replay attacks.

3. Payload Data

 Contains the actual encrypted data.

 In Transport Mode, it contains a transport-layer segment (TCP/UDP).
 In Tunnel Mode, it contains the entire IP packet.

4. Padding

 Extra bytes added when required.

 Used to make the data length suitable for encryption.
 Helps hide the actual size of the message.

5. Pad Length

 Indicates the number of padding bytes added.

6. Next Header

 Specifies the protocol of the payload.

 Example: TCP, UDP, ICMP, or IPv6 extension header.

7. Integrity Check Value (ICV)

 Variable-length field.
 Used for authentication and integrity checking.
 Ensures that data has not been modified.

Encryption and Authentication in ESP

ESP encrypts the following fields:

 Payload Data
 Padding
 Pad Length
 Next Header

If an Initialization Vector (IV) is required by the encryption algorithm, it is

placed at the beginning of the payload. The IV is usually not encrypted.

Authentication is performed after encryption by calculating the Integrity

Check Value (ICV).
Purpose of Padding

The Padding field is used for three purposes:

1. Block Size Requirement

Some encryption algorithms require data lengths that are multiples of a fixed
block size. Padding is added to satisfy this requirement.

2. Data Alignment

Padding ensures that the Pad Length and Next Header fields are properly
aligned on a 32-bit boundary.

3. Traffic Flow Confidentiality

Additional padding hides the actual length of the message, making traffic
analysis more difficult.

Anti-Replay Service

A replay attack occurs when an attacker captures a valid packet and sends it
again to the receiver.

ESP prevents replay attacks using the Sequence Number field.

Working

 Each new Security Association starts with sequence number 0.

 The first transmitted packet uses sequence number 1.
 The sequence number increases for every packet.
 It must never repeat.
 When the maximum value (2³² − 1) is reached, a new Security
Association must be created.

Receiver Processing

The receiver maintains a sliding window (default size 64) to detect duplicate
packets.

When a packet is received:

1. If the packet is inside the window and has not been received before, it
is authenticated and accepted.
2. If the packet has a higher sequence number than the current window,
the window moves forward and the packet is accepted.
3. If the packet is outside the window or is a duplicate, it is rejected.

Transport Mode ESP

Definition

Transport Mode protects only the transport-layer data (payload) while

leaving the original IP header unchanged.

Working

1. The sender encrypts the transport-layer segment and ESP trailer.

2. The IP header remains unencrypted.
3. Routers read the IP header and forward the packet.
4. The receiver decrypts the encrypted payload using the Security
Association.

Characteristics

 Encrypts only the payload.

 Original IP header remains visible.
 Used for host-to-host communication.
 Faster because less data is encrypted.

Advantages

 Lower processing overhead.

 Better performance.
 Suitable for end-to-end communication.

Disadvantage

Since the IP header is visible, attackers can perform traffic analysis.

Tunnel Mode ESP

Definition

Tunnel Mode encrypts the entire original IP packet, including both the IP
header and payload.

A new outer IP header is added for routing.

Working

1. The sender creates the original IP packet.

2. ESP encrypts the entire packet.
3. A new IP header is added.
4. Routers use the outer IP header for forwarding.
5. The destination firewall or gateway removes the outer header, decrypts
the packet, and forwards the original packet to the destination host.

Characteristics
  Encrypts the complete IP packet.
 Adds a new outer IP header.
 Used between security gateways, routers, firewalls, and VPNs.

Advantages

 Provides stronger security.

 Hides internal IP addresses.
 Prevents traffic analysis.
 Ideal for Virtual Private Networks (VPNs).

Advantages of ESP

 Provides strong data encryption.

 Ensures authentication and integrity.
 Protects against replay attacks.
 Supports multiple encryption algorithms.
 Works in both Transport and Tunnel modes.
 Widely used in VPNs.
 Provides secure communication over public networks.

Disadvantages of ESP

 Increases packet size due to additional headers.

 Encryption and decryption increase processing time.
 Requires proper Security Association (SA) management.
 More complex than normal IP communication.

Conclusion

Encapsulating Security Payload (ESP) is the main protocol of IPsec that

provides confidentiality, authentication, integrity, and replay protection. It
encrypts data before transmission and supports both Transport Mode and
Tunnel Mode, making it suitable for secure host-to-host communication and
VPN-based gateway communication over public networks.

Internet Key Exchange (IKE)

Introduction

Internet Key Exchange (IKE) is the key management protocol of IPsec. It is

responsible for creating, exchanging, and managing secret keys securely
between communicating devices. Instead of manually entering keys, IKE
automatically generates and exchanges them whenever secure
communication is required.

A secure communication between two systems generally requires four keys:

 One transmit key for encryption

 One receive key for encryption
  One transmit key for integrity
 One receive key for integrity

Types of Key Management

1. Manual Key Management

 Keys are manually configured by the system administrator.

 Each system stores its own keys and the keys of other communicating
systems.
 Suitable for small and static networks.
 Simple but difficult to manage in large organizations.

2. Automated Key Management

 Keys are generated automatically whenever required.

 Creates Security Associations (SAs) dynamically.
 Suitable for large and changing networks.
 Easier and more secure than manual configuration.

Components of IKE

1. Oakley Key Determination Protocol

 Based on the Diffie-Hellman key exchange algorithm.

 Provides secure key exchange with additional security improvements.
 Does not define fixed message formats.

2. ISAKMP (Internet Security Association and Key Management Protocol)

 Provides a framework for Internet key management.

 Defines message formats used during security negotiation.
 Supports different key exchange algorithms.

Note:
In IKEv2, the names Oakley and ISAKMP are no longer used separately, but
their functionality is still available with several improvements.

Key Determination Protocol

IKE uses an improved version of the Diffie-Hellman Key Exchange

Algorithm to generate secure session keys.

Diffie-Hellman Working

1. Both users agree on common values (large prime number and primitive
root).
2. Each user selects a private key.
3. Each user generates and exchanges a public key.
4. Both users independently calculate the same shared secret key.
Advantages of Diffie-Hellman

 Secret keys are generated only when needed.

 No long-term storage of secret keys.
 No existing secure infrastructure is required except common public
parameters.

Limitations of Diffie-Hellman

 Does not verify the identity of communicating users.

 Vulnerable to Man-in-the-Middle Attack.
 Computationally expensive.
 Vulnerable to Clogging Attack, where attackers force a system to
perform unnecessary calculations.

Features of IKE Key Determination

IKE improves Diffie-Hellman by providing the following features:

1. Cookies

 Protect against clogging attacks.

 Each device sends a random cookie before performing expensive
calculations.
 Prevents fake users from consuming system resources.

2. Group Negotiation

 Allows both parties to agree on Diffie-Hellman parameters.

 Supports different security groups.

3. Nonces

 Random numbers generated for each session.

 Prevent replay attacks.
 Ensure message freshness.

4. Diffie-Hellman Public Key Exchange

 Securely exchanges public keys.

 Used to generate a shared secret session key.

5. Authentication

 Confirms the identity of communicating users.

 Prevents Man-in-the-Middle attacks.

Cookie Requirements

For security, cookies must satisfy three conditions:

 1. Must depend on the communicating devices.
2. Only the creator should be able to generate valid cookies.
3. Cookie generation and verification must be very fast.

Usually, cookies are generated using a fast hash function such as MD5.

Supported Diffie-Hellman Groups

IKE supports different security groups such as:

 768-bit Modular Exponentiation

 1024-bit Modular Exponentiation
 1536-bit Modular Exponentiation
 Elliptic Curve Group (155-bit)
 Elliptic Curve Group (185-bit)

The first three use the traditional Diffie-Hellman algorithm, while the last two
use Elliptic Curve Diffie-Hellman (ECDH).

Authentication Methods in IKE

IKE supports three authentication methods:

1. Digital Signatures

 Uses private keys to digitally sign exchanged information.

 Verifies the identity of both users.

2. Public Key Encryption

 Authentication is performed using public/private key encryption.

3. Symmetric Key Encryption

 Uses a shared secret key established before communication.

IKEv2 Message Exchanges

IKEv2 exchanges messages in pairs.

1. Initial Exchange

 Exchange cryptographic algorithms.

 Exchange Diffie-Hellman public keys.
 Exchange nonces.
 Create the IKE Security Association (IKE SA).

2. Authentication Exchange

 Authenticate both users.

  Create the first IPsec Security Association (IPsec SA).
 Used for secure data communication.

3. CREATE_CHILD_SA Exchange

 Creates additional IPsec Security Associations.

 Used when extra secure communication channels are needed.

4. Informational Exchange

Used for:

 Error messages
 Notifications
 Configuration updates
 SA deletion
 Management information

IKE Header Format

Every IKE message contains an IKE Header followed by one or more

payloads.

Fields of IKE Header

1. Initiator SPI

 Identifies the Security Association created by the initiator.

2. Responder SPI

 Identifies the Security Association created by the responder.

3. Next Payload

 Indicates the type of the next payload.

4. Major Version

 Specifies the major IKE version.

5. Minor Version

 Specifies the minor IKE version.

6. Exchange Type

 Identifies the type of IKE exchange.

7. Flags
  Indicate options such as initiator, response, and supported version.

8. Message ID

 Matches requests with responses.

 Helps retransmit lost packets.

9. Length

 Total size of the IKE message.

IKE Payload Types

1. Security Association (SA)

 Starts Security Association negotiation.

 Contains proposals, transforms, and attributes.

Proposal

 Specifies protocol (AH, ESP, or IKE).

Transform

 Specifies cryptographic algorithms.

Attribute

 Defines additional parameters such as key length.

2. Key Exchange Payload

 Exchanges Diffie-Hellman public keys.

 Generates the shared session key.

3. Identification Payload

 Identifies communicating devices.

 Usually contains IPv4 or IPv6 addresses.

4. Certificate Payload

Transfers digital certificates such as:

 X.509 Certificate
 PGP Certificate
 DNS Signed Key
 Kerberos Token
 Certificate Revocation List (CRL)
 Authority Revocation List (ARL)
  SPKI Certificate

5. Certificate Request Payload

 Requests the certificate of the communicating device.

 Specifies acceptable certificate types and Certificate Authorities.

6. Authentication Payload

 Provides message authentication.

 Supports RSA Digital Signature.
 Supports DSS Digital Signature.
 Supports Shared-Key Authentication.

7. Nonce Payload

 Contains random numbers.

 Protects against replay attacks.
 Ensures communication freshness.

8. Notify Payload

Used to send:

 Error messages
 Status information
 SA negotiation notifications

Examples:

 Invalid SPI
 Authentication Failed
 No Proposal Chosen
 Rekey SA
 Initial Contact
 Cookie
 Use Transport Mode

9. Delete Payload

 Removes Security Associations that are no longer required.

10. Vendor ID Payload

 Identifies the vendor implementation.

 Supports compatibility with vendor-specific features.

11. Traffic Selector Payload

 Identifies which packet flows will receive IPsec protection.

12. Encrypted Payload

 Contains encrypted IKE payloads.

 May include:

o Initialization Vector (IV)

o Integrity Check Value (ICV)

13. Configuration Payload

 Exchanges configuration information between IKE peers.

14. Extensible Authentication Protocol (EAP) Payload

 Allows IKE Security Associations to use EAP authentication.

 Commonly used for remote access VPN authentication.

Advantages of IKE

 Automatically generates secure session keys.

 Eliminates manual key configuration.
 Protects against replay, clogging, and Man-in-the-Middle attacks.
 Supports multiple authentication methods.
 Creates and manages Security Associations automatically.
 Provides secure communication for IPsec networks.