Secure Socket Layer (SSL)

SSL or Secure Sockets Layer is an Internet security protocol that encrypts data to keep it safe.
It was created by Netscape in 1995 to ensure privacy, authen?ca?on, and data integrity in
online communica?ons. SSL is the older version of what we now call TLS (Transport Layer
Security).
Websites using SSL/TLS have “HTTPS” in their URL instead of “HTTP.”

Working of SSL
• Encryp0on: SSL encrypts data transmiNed over the web, ensuring privacy. If someone
intercepts the data, they will see only a jumble of characters that is nearly impossible
to decode.
• Authen0ca0on: SSL starts an authen?ca?on process called a handshake between two
devices to confirm their iden??es, making sure both par?es are who they claim to be.
• Data Integrity: SSL digitally signs data to ensure it hasn’t been tampered with,
verifying that the data received is exactly what was sent by the sender.

Importance of SSL
Originally, data on the web was transmiNed in plaintext, making it easy for anyone who
intercepted the message to read it. For example, if someone logged into their email account,
their username and password would travel across the Internet unprotected.

SSL was created to solve this problem and protect user privacy. By encryp?ng data between a
user and a web server, SSL ensures that anyone who intercepts the data sees only a scrambled
mess of characters. This keeps the user’s login creden?als safe, visible only to the email
service.

Addi?onally, SSL helps prevent cyber aNacks by:

• Authen0ca0ng Web Servers: Ensuring that users are connec?ng to the legi?mate
website, not a fake one set up by aNackers.
• Preven0ng Data Tampering: Ac?ng like a tamper-proof seal, SSL ensures that the
data sent and received hasn’t been altered during transit.

Secure Socket Layer Protocols

1. SSL Record Protocol
2. Handshake Protocol
3. Change-Cipher Spec Protocol
4. Alert Protocol
SSL Record Protocol
SSL Record provides two services to SSL connec?on.
• Confiden?ality
• Message Integrity

In the SSL Record Protocol applica?on data is divided into fragments. The fragment is
compressed and then encrypted MAC (Message Authen?ca?on Code) generated by
algorithms like SHA (Secure Hash Protocol) and MD5 (Message Digest) is appended. A_er
that encryp?on of the data is done and in last SSL header is appended to the data.

Handshake Protocol

Handshake Protocol is used to establish sessions. This protocol allows the client and server
to authen?cate each other by sending a series of messages to each other. Handshake
protocol uses four phases to complete its cycle.
• Phase-1: In Phase-1 both Client and Server send hello-packets to each other. In this
IP session, cipher suite and protocol version are exchanged for security purposes.
• Phase-2: Server sends it cer?ficate and Server-key-exchange. The server end phase-2
by sending the Server-hello-end packet.
• Phase-3: In this phase, Client replies to the server by sending it cer?ficate and Client-
exchange-key.
• Phase-4: In Phase-4 Change Cipher Spec occurs and a_er this the Handshake
Protocol ends.
 SSL Handshake Protocol Phases diagramma5c representa5on

Change-Cipher Protocol
This protocol uses the SSL record protocol. Unless Handshake Protocol is completed, the SSL
record Output will be in a pending state. A_er the handshake protocol, the Pending state is
converted into the current state.
Change-cipher protocol consists of a single message which is 1 byte in length and can have
only one value. This protocol’s purpose is to cause the pending state to be copied into the
current state.

Alert Protocol
This protocol is used to convey SSL-related alerts to the peer en?ty. Each message in this
protocol contains 2 bytes.

The level is further classified into two parts:

Warning (level = 1)
This Alert has no impact on the connec?on between sender and receiver. Some of them are:
• Bad Cer0ficate: When the received cer?ficate is corrupt.
• No Cer0ficate: When an appropriate cer?ficate is not available.
• Cer0ficate Expired: When a cer?ficate has expired.
• Cer0ficate Unknown: When some other unspecified issue arose in processing the
cer?ficate, rendering it unacceptable.
• Close No0fy: It no?fies that the sender will no longer send any messages in the
connec?on.
 • Unsupported Cer0ficate: The type of cer?ficate received is not supported.
• Cer0ficate Revoked: The cer?ficate received is in revoca?on list.
Fatal Error (level = 2):
This Alert breaks the connec?on between sender and receiver. The connec?on will be
stopped, cannot be resumed but can be restarted. Some of them are :
• Handshake Failure: When the sender is unable to nego?ate an acceptable set of
security parameters given the op?ons available.
• Decompression Failure: When the decompression func?on receives improper input.
• Illegal Parameters: When a field is out of range or inconsistent with other fields.
• Bad Record MAC: When an incorrect MAC was received.
• Unexpected Message: When an inappropriate message is received.
The second byte in the Alert protocol describes the error.

Secure Hypertext Transfer Protocol (S-HTTP)

Secure Hypertext Transfer Protocol, or S-HTTP, is a protocol for transmi`ng private documents
over the internet. It ensures data security by encryp?ng the messages at the message level.
This approach allows for securing individual message segments, affording a high degree of
flexibility. Although this can introduce complexity, as decisions must be made regarding which
parts of a message need securing, it does not necessitate a con?nuous connec?on and
supports an extensive range of security mechanisms.

S-HTTP vs. Hypertext Transfer Protocol Secure (HTTPS)

While both S-HTTP and HTTPS aim to establish secure communica?on over the internet, they
have different approaches and use cases. HTTPS operates at the transport layer, securing the
en?re communica?on session between the client and server. This makes HTTPS less flexible
but simpler to use, as it doesn’t require decisions on which parts of a message to secure.
Addi?onally, HTTPS requires a con?nuous connec?on, while S-HTTP does not, which can be a
cri?cal factor depending on the intended applica?on.

When choosing between S-HTTP and HTTPS, considera?ons should include the specific
security requirements, the complexity of the decisions regarding what to secure, and the need
for a con?nuous connec?on. Both protocols have their place and offer valuable tools in the
ongoing effort to secure internet communica?ons.

Secure Hypertext Transfer Protocol (S-HTTP)

Pros:
• S-HTTP provides granular control over message encryp?on, allowing specific parts of
a message to be secured.
• It does not require a con?nuous connec?on, making it adaptable to various network
situa?ons.
• Supports a wide range of security mechanisms, enhancing its versa?lity.
Cons:
• It can be complex to implement due to the need to decide which parts of a message
to secure.
• Its use is not as widespread as HTTPS.
S-HTTP (Secure Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure)
are both used to secure web communica?ons, but they differ in how they achieve security. S-
HTTP encrypts individual messages or segments, offering flexibility but not widely adopted,
while HTTPS uses TLS (or its predecessor SSL) to wrap the en?re communica?on in an
encrypted tunnel, providing a more robust and widely used solu?on.
Time Stamping Protocol (TSP) in Cryptography

The Time Stamping Protocol (TSP) is a standard protocol defined by the Internet Engineering
Task Force (IETF) under RFC 3161. It is used to prove that certain data existed at a specific
point in ?me and has not been altered since then.
This is crucial for applica?ons such as digital signatures, legal documents, intellectual property
claims, and blockchain technology.

Purpose of Time Stamping

1. Integrity Verifica0on: Ensures that a digital document has not been modified a_er
the ?mestamp was applied.
2. Non-repudia0on: Proves the existence of data at a certain point in ?me, preven?ng
denial by the sender.
3. Audit Trails: Maintains tamper-proof logs for accountability.
4. Long-term Signature Valida0on: Digital signatures may expire or be revoked, so ?me
stamps help extend their validity.

Key Components
1. Time Stamping Authority (TSA):
o A trusted third party that issues ?me stamps.
o Provides the current ?me and signs the data hash along with the ?mestamp
using its private key.
2. Time Stamp Token (TST):
o A signed message from the TSA.
o Contains:
§ Hash of the original data.
§ Time of stamping.
§ Unique serial number.
§ TSA's digital signature.
§ Policy and algorithm iden?fiers.
3. Requester/Client:
o The en?ty reques?ng a ?mestamp for some data.
o Computes the hash of the data and sends it to the TSA.

Working of TSP (Step-by-Step)

1. Hashing the Data
• The client computes a cryptographic hash (e.g., SHA-256) of the original
document/data.
2. Crea0ng Time Stamp Request (TSR)
• This request includes:
o The hash of the data.
o A unique request iden?fier (nonce).
o Informa?on about the hash algorithm used.
3. Sending the Request to TSA
• The client sends the TSR to the Time Stamping Authority.
4. TSA Validates and Creates Time Stamp Token (TST)
• The TSA:
o Notes the current ?me (accurate and synchronized).
o Verifies the format and integrity of the request.
o Signs a structure including the hash, ?me, and request info with its private
key.
5. Returning the TST to the Client
• The TSA sends the signed TST back to the requester.
6. Storage and Verifica0on
• The client stores the TST with the original data.
• To verify:
o Re-hash the original data.
o Match with the hash in the TST.
o Validate the TSA's signature.

Security Aspects
• Hashing ensures the TSA never sees the actual data—only its hash.
• Digital signature of TSA provides authen?city and non-repudia?on.
• Nonce prevents replay aNacks.
• Timestamp accuracy is cri?cal—TSA usually synchronizes ?me using UTC or NTP
servers.

Advantages
• Tamper detec?on
• Lightweight and efficient
• Enhances digital signature reliability
• Can be used offline for verifica?on
• Legally admissible in many jurisdic?ons

Limita0ons & Challenges

• Trust in TSA is cri?cal — compromise leads to system failure.
• Long-term availability of TSA cer?ficate and records.
• Key management and revoca?on issues.
Secure Electronic Transac?on (SET)

Secure Electronic Transac0on (SET) is a cryptographic protocol developed by Visa and

MasterCard in the mid-1990s to ensure secure transmission of payment informa0on over
the Internet. SET was designed specifically to protect credit card transac?ons in e-commerce.

Though not widely adopted due to its complexity and deployment cost, SET introduced
advanced security mechanisms that laid the founda?on for modern secure payment systems.

Objec0ves of SET
1. Confiden0ality: Ensure that informa?on remains private between par?cipants.
2. Integrity: Ensure that data is not altered during transmission.
3. Authen0ca0on: Verify the iden??es of the par?es involved (cardholder, merchant,
bank).
4. Non-repudia0on: Prevent any party from denying the transac?on later.

Key Components
Component Descrip0on
Cardholder Customer who wants to buy goods/services using a credit card.
Merchant Vendor selling products or services online.
Issuer Bank that issues the card to the cardholder.
Acquirer Bank that handles payments for the merchant.
Facilitates communica?on between merchant and financial
Payment Gateway
ins?tu?ons.
Cer0ficate Authority
Issues digital cer?ficates for authen?ca?on.
(CA)

Cryptographic Techniques Used

• Public Key Cryptography (RSA) for secure key exchange and digital signatures.
• Digital Cer0ficates (X.509) for iden?ty verifica?on.
• Symmetric Key Encryp0on (e.g., 3DES) for encryp?ng sensi?ve data.
• Dual Signature – a unique feature to protect both order and payment informa?on.

SET Transac0on Workflow

1. Ini0aliza0on and Cer0fica0on

• All par?cipants (cardholder, merchant, gateway) obtain digital cer0ficates from a
trusted Cer0ficate Authority (CA).
2. Shopping & Order Ini0a0on
• Cardholder selects items and prepares to make a purchase.
• The order informa0on (OI) and payment informa0on (PI) are separately prepared.
3. Dual Signature Crea0on
• Cardholder:
o Hashes both OI and PI.
o Creates a dual signature that links both hashes together.
o Encrypts PI using the merchant’s payment gateway’s public key.
o Sends the encrypted PI + OI + dual signature to the merchant.
4. Merchant Processing
• Merchant:
o Verifies the order and the cardholder’s cer?ficate.
 o Cannot read PI (it is encrypted for the payment gateway).
o Forwards PI and dual signature to the payment gateway.
5. Payment Gateway Processing
• Verifies:
o Cardholder’s and merchant’s cer?ficates.
o Dual signature for authen?city.
• Processes the payment by contac?ng the issuer bank.
• Sends authoriza0on to the merchant.
6. Confirma0on
• Merchant completes the transac?on and confirms the order to the cardholder.

Dual Signature
A dual signature is used to link the order informa?on and payment informa?on without
revealing them both to any single party. It ensures:
• The merchant cannot see payment details.
• The bank cannot see what was ordered.
• Both par?es can verify that the transac?on is legi?mate.
Dual Signature = Sign(H(H(OI) || H(PI)))

Advantages of SET
• High level of security.
• Prevents card number the_.
• Non-repudia?on through digital signatures.
• Trust ensured via digital cer?ficates.
• Separa?on of du?es (merchant cannot see payment info).

Disadvantages of SET
• Complex to implement.
• High infrastructure and so_ware cost.
• Requires digital cer?ficates and cer?ficate management.
• Limited user and merchant adop?on.
• Slower transac?on ?mes compared to SSL/TLS.

Difference between SSL and SET

SSL SET

SSL secures communica?on between browsers SET secures credit card payments and
and servers. Merchants manage both order and hides customer payment details from
payment details. merchants.

It developed by Netscape for secure online It developed by MasterCard and Visa

transac?ons. for safe card payments.

Developed by MasterCard and Visa for safe card Requires verifica?on by both CAs and
payments. financial ins?tu?ons.

It can secure emails, websites, and other It has limited to online financial
applica?ons. transac?ons only.
 SSL SET

Merchants can view the cardholder’s payment Card details are hidden from
informa?on. merchants, ensuring privacy.

It is easy to implement and suitable for small It is harder to implement and more
businesses. expensive to set up.

Harder to implement and more expensive to set Stronger encryp?on of 1024-bit for
up. financial security.

SSL and SET serve different purposes in the realm of online security. SSL is a general-purpose
technology that provides encryp?on and security for a wide range of online ac?vi?es, while
SET is specifically designed for securing payment transac?ons.