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, authentication, and data integrity in
online communications. 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
• Encryption: SSL encrypts data transmitted over the web, ensuring privacy. If someone
intercepts the data, they will see only a jumble of characters that is nearly impossible
to decode.
• Authentication: SSL starts an authentication process called a handshake between two
devices to confirm their identities, making sure both parties 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 transmitted 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 encrypting 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 credentials safe, visible only to the email
service.

Additionally, SSL helps prevent cyber attacks by:

• Authenticating Web Servers: Ensuring that users are connecting to the legitimate
website, not a fake one set up by attackers.
• Preventing Data Tampering: Acting 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 connection.
• Confidentiality
• Message Integrity

In the SSL Record Protocol application data is divided into fragments. The fragment is
compressed and then encrypted MAC (Message Authentication Code) generated by
algorithms like SHA (Secure Hash Protocol) and MD5 (Message Digest) is appended. After
that encryption 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 authenticate 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 certificate 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 certificate and Client-
exchange-key.
• Phase-4: In Phase-4 Change Cipher Spec occurs and after this the Handshake
Protocol ends.
 SSL Handshake Protocol Phases diagrammatic representation

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. After 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 entity. 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 connection between sender and receiver. Some of them are:
• Bad Certificate: When the received certificate is corrupt.
• No Certificate: When an appropriate certificate is not available.
• Certificate Expired: When a certificate has expired.
• Certificate Unknown: When some other unspecified issue arose in processing the
certificate, rendering it unacceptable.
• Close Notify: It notifies that the sender will no longer send any messages in the
connection.
 • Unsupported Certificate: The type of certificate received is not supported.
• Certificate Revoked: The certificate received is in revocation list.
Fatal Error (level = 2):
This Alert breaks the connection between sender and receiver. The connection will be
stopped, cannot be resumed but can be restarted. Some of them are :
• Handshake Failure: When the sender is unable to negotiate an acceptable set of
security parameters given the options available.
• Decompression Failure: When the decompression function 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 transmitting private documents
over the internet. It ensures data security by encrypting 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 continuous connection 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 communication over the internet, they
have different approaches and use cases. HTTPS operates at the transport layer, securing the
entire communication 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.
Additionally, HTTPS requires a continuous connection, while S-HTTP does not, which can be a
critical factor depending on the intended application.

When choosing between S-HTTP and HTTPS, considerations should include the specific
security requirements, the complexity of the decisions regarding what to secure, and the need
for a continuous connection. Both protocols have their place and offer valuable tools in the
ongoing effort to secure internet communications.

Secure Hypertext Transfer Protocol (S-HTTP)

Pros:
• S-HTTP provides granular control over message encryption, allowing specific parts of
a message to be secured.
• It does not require a continuous connection, making it adaptable to various network
situations.
• Supports a wide range of security mechanisms, enhancing its versatility.
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 communications, 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 entire communication in an
encrypted tunnel, providing a more robust and widely used solution.
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 time and has not been altered since then.
This is crucial for applications such as digital signatures, legal documents, intellectual property
claims, and blockchain technology.

Purpose of Time Stamping

1. Integrity Verification: Ensures that a digital document has not been modified after
the timestamp was applied.
2. Non-repudiation: Proves the existence of data at a certain point in time, preventing
denial by the sender.
3. Audit Trails: Maintains tamper-proof logs for accountability.
4. Long-term Signature Validation: Digital signatures may expire or be revoked, so time
stamps help extend their validity.

Key Components
1. Time Stamping Authority (TSA):
o A trusted third party that issues time stamps.
o Provides the current time and signs the data hash along with the timestamp
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 identifiers.
3. Requester/Client:
o The entity requesting a timestamp 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. Creating Time Stamp Request (TSR)
• This request includes:
o The hash of the data.
o A unique request identifier (nonce).
o Information 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 time (accurate and synchronized).
o Verifies the format and integrity of the request.
o Signs a structure including the hash, time, 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 Verification
• 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 authenticity and non-repudiation.
• Nonce prevents replay attacks.
• Timestamp accuracy is critical—TSA usually synchronizes time using UTC or NTP
servers.

Advantages
• Tamper detection
• Lightweight and efficient
• Enhances digital signature reliability
• Can be used offline for verification
• Legally admissible in many jurisdictions

Limitations & Challenges

• Trust in TSA is critical — compromise leads to system failure.
• Long-term availability of TSA certificate and records.
• Key management and revocation issues.
Secure Electronic Transaction (SET)

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

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

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

Objectives of SET
1. Confidentiality: Ensure that information remains private between participants.
2. Integrity: Ensure that data is not altered during transmission.
3. Authentication: Verify the identities of the parties involved (cardholder, merchant,
bank).
4. Non-repudiation: Prevent any party from denying the transaction later.

Key Components
Component Description
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 communication between merchant and financial
Payment Gateway
institutions.
Certificate Authority
Issues digital certificates for authentication.
(CA)

Cryptographic Techniques Used

• Public Key Cryptography (RSA) for secure key exchange and digital signatures.
• Digital Certificates (X.509) for identity verification.
• Symmetric Key Encryption (e.g., 3DES) for encrypting sensitive data.
• Dual Signature – a unique feature to protect both order and payment information.

SET Transaction Workflow

1. Initialization and Certification

• All participants (cardholder, merchant, gateway) obtain digital certificates from a
trusted Certificate Authority (CA).
2. Shopping & Order Initiation
• Cardholder selects items and prepares to make a purchase.
• The order information (OI) and payment information (PI) are separately prepared.
3. Dual Signature Creation
• 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 certificate.
 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 certificates.
o Dual signature for authenticity.
• Processes the payment by contacting the issuer bank.
• Sends authorization to the merchant.
6. Confirmation
• Merchant completes the transaction and confirms the order to the cardholder.

Dual Signature
A dual signature is used to link the order information and payment information without
revealing them both to any single party. It ensures:
• The merchant cannot see payment details.
• The bank cannot see what was ordered.
• Both parties can verify that the transaction is legitimate.
Dual Signature = Sign(H(H(OI) || H(PI)))

Advantages of SET
• High level of security.
• Prevents card number theft.
• Non-repudiation through digital signatures.
• Trust ensured via digital certificates.
• Separation of duties (merchant cannot see payment info).

Disadvantages of SET
• Complex to implement.
• High infrastructure and software cost.
• Requires digital certificates and certificate management.
• Limited user and merchant adoption.
• Slower transaction times compared to SSL/TLS.

Difference between SSL and SET

SSL SET

SSL secures communication 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

transactions. for safe card payments.

Developed by MasterCard and Visa for safe card Requires verification by both CAs and
payments. financial institutions.

It can secure emails, websites, and other It has limited to online financial
applications. transactions only.
 SSL SET

Merchants can view the cardholder’s payment Card details are hidden from
information. 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 encryption 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 encryption and security for a wide range of online activities, while
SET is specifically designed for securing payment transactions.