SSL PROTOCOL

Security of data in transit over the Internet becomes increasingly necessary because of steadily
growing data volume and importance. Nowadays, every user of a public network sends various
types of data, from email to credit card details daily, and he would therefore like them to be
protected when in transit over a public network. To this end, a practical SSL protocol has been
adopted for protection of data in transit that encompasses all network services that use TCP/IP to
support typical application tasks of communication between servers and clients.

The SSL protocol was originally developed by Netscape in 1996. SSL is designed to make use
of TCP as a communication layer to provide a reliable end-to-end secure and authenticated
connection between two points over a network (for example between the service client and the
server). SSL can be used for protection of data in transit in situations related to any network
service; it is used mostly in HTTP server and client applications. Today, almost each available
HTTP server can support an SSL session, whilst IE or Netscape Navigator browsers are provided
with SSL-enabled client software.

SSL OBJECTIVES AND ARCHITECTURE:

Which problems does SSL target? The main objectives for SSL are:

1. Authenticating the client and server to each other: the SSL protocol supports the use of
standard key cryptographic techniques (public key encryption) to authenticate the
communicating parties to each other. Though the most frequent application consists in
authenticating the service client on the basis of a certificate, SSL may also use the same
methods to authenticate the client.
2. Ensuring data integrity: during a session, data cannot be either intentionally or
unintentionally tampered with.
3. Securing data privacy: data in transport between the client and the server must be
protected from interception and be readable only by the intended recipient. This
prerequisite is necessary for both the data associated with the protocol itself (securing
traffic during negotiations) and the application data that is sent during the session itself.

SSL is in fact not a single protocol but rather a set of protocols that can additionally be further
divided in two layers:

1. the protocol to ensure data security and integrity: this layer is composed of the SSL
Record Protocol,

1
 2. the protocols that are designed to establish an SSL connection: three protocols  are used
in this layer: the SSL Handshake Protocol, the SSL Change Cipher SpecPprotocol and the
SSL Alert Protocol

How SSL Works:

The method has been developed keeping in mind the basic objectives of SSL: confidentiality,
integrity and authentication of both sender and receiver.

To ensure integrity, we use a one-way hashing algorithm on the message copy to generate a
message digest. This algorithm uses statistical methods to compute a checksum (or message
digest) from the characters in the message. If the content or position of even a single character is
changed, the message digest will not match.

To secure the message digest itself from tampering, the digest is encrypted using the sender's
private key. The encrypted form of the message digest is called the digital signature of the
sender.

The receiver can decrypt the digest using the sender's public key, regenerate the digest and
compare. To ensure confidentiality, the entire message is encrypted. Since the message could be
large, we use the more efficient symmetric encryption. A random symmetric key also called
session key is generated and used to encrypt the message. To secure the symmetric key itself, it
is encrypted using the public key of the receiver and is called the digital envelope.

Finally, the symmetrically encrypted message and the digital envelope are sent to the receiver.
Only the receiver can decrypt the symmetric key, since only he possesses the private key of the
receiver. Thus we have achieved authentication of the receiver.

The receiver uses his private key to decrypt the random symmetric key. Then he uses the random
symmetric key to decrypt the main message. He locates the sender's digital signature and using
the public sender's key; he decrypts it and retrieves the message digest. He regenerates the
message digest using the known hashing function and compares it to the retrieved digest. If they
match, he is assured that the message has not been tampered with and has indeed originated from
the sender. This also ensures that the message has really come from the sender (nobody else
knows the sender's private key) and hence accomplishes the objective of authenticating the
sender.

2
 Internet
Sender Receiver
Encrypted Message + Digital Envelope
Message
Rec.Public Key Encrypted Message +Digital Envelope
Msg.+ Digital Signature
Hash ( ) Receiver Private
Key
Message Digest
Session Key Session Key

Sender Private Key Encrypted Message

Digital Signature
Message + Digital Signature
Digital Envelope
Hash ( ) Sender Public Key
Message Message
Digest Digest
==

Fig: SSL Protocol Working

DIGITAL CERTIFICATES
A digital certificate or digital ID is an attachment to an e-mail message or a program embedded
in a Web page that verifies that the sender or Web site is who or what it claims to be. In
addition, the digital certificate contains a means to send an encrypted message others cannot
read it—to the entity that sent the original Web page or e-mail message. In the case of a
downloaded program containing a digital certificate, the encrypted mes sage identifies the
software publisher (ensuring that the identity of the software matches the certificate) and
indicates whether the certificate has expired or is not. The digital certificate is a signed message
or code. Signed code or messages serve function as a photo on a driver's license or passport.
They provide proof that the person identified by the certificate. Just like a passport, a certificate
does imply anything about either the usefulness or quality of the downloaded program. Th
certificate only supplies a level of assurance that the software is genuine. The idea behind is that if
the user trusts the software developer, signed software can be trusted because, as proven by
the certificate, it came from that trusted developer.

3
 Digital certificates are used for many different types of online transactions, electronic
commerce, electronic mail, and electronic funds transfers. A digital ID veri fies a Web site
to a shopper and, optionally, identifies a shopper to a Web site. Web browsers or e-mail
programs exchange digital certificates automatically and invisibly -: requested to validate
the identity of each party involved in a transaction.

A digital certificate for software is an assurance that the software was created by specific
company. The certificate does not attest to the quality of the software, just to identify of the
company that published it. Digital certificates are issued by a certification authority (CA). A
CA can issue digital certificates to organizations or individuals. A CA requires entities applying
for digital certificates to supply appropriate proof of identities the CA is satisfied, it issues a
certificate. Then, the CA signs the certificate, and its stamp of approval is affixed in the form of a
public encryption key, which "unlocks" the certificate for anyone who receives the certificate
attached to the publisher's code.

Digital certificates cannot be forged easily. A digital certificate includes six main - elements,
including:

 Certificate owner's identifying information, such as name, organization,

address, and so on
 Certificate owner's public key
 Dates between which the certificate is valid
 Serial number of the certificate
 Name of the certificate issuer
 Digital signature of the certificate issuer

CERTIFICATION AUTHORITY
A certificate authority or certification authority (CA) is an entity that issues digital certificates
for use by other parties. It is an example of a trusted third party.

A CA issues digital certificates that contain a public key and the identity of the owner. When an
end-user tries to access an unknown URL, the web browser (e.g. Mozilla Firefox and Microsoft
Internet Explorer) will contact the CA to confirm the public key of the URL. The matching
private key is not similarly made available publicly, but kept secret by the end user who
generated the key pair. The certificate is also a confirmation or validation by the CA that the
public key contained in the certificate belongs to the person, organization, server or other entity
noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials,
so that users and relying parties can trust the information in the CA's certificates. CAs uses a
variety of standards and tests to do so. In essence, the Certificate Authority is responsible for
saying "yes, this person is who they say they are, and we, the CA, verify that". If the user trusts

4
the CA and can verify the CA's signature, then he can also verify that a certain public key does
indeed belong to whoever is identified in the certificate.

Identification requirements vary from one CA to another. CAs usually publishes identification
requirements so that any Web user or site accepting certificates from each CA understand the
stringency of that CA's validation procedures. There are only a small number of CAs because the
certificates issued are only trust worthy as the CA itself, and only a few companies have decided
to build the reputation needed to be a successful seller of digital certificates. Two of the most
commonly used CAs is Thawte and VeriSign, but other companies such as Entrust and
Equifax Secure also offer CA services.

SET PROTOCOL:
SET (Secure Electronic Transaction) is a protocol that was developed by Visa, MasterCard,
Netscape and Microsoft in 1997.SET protocol involves four entities:

 Buyer
 Merchant
 Certification Authority: CA is defined as trusted body that attests the association of a
particular individual with the corresponding public key. CA signs the digital certificate
with her private key.
 Payment Gateway: A payment gateway is an e-commerce application service provider
service that authorizes payments for e-businesses, online retailers, bricks and clicks, or
traditional brick and mortar. It is the equivalent of a physical point of sale terminal
located in most retail outlets. Payment gateway protects credit cards details encrypting
sensitive information, such as credit card numbers, to ensure that information pass
securely between the customer and the merchant and also between merchant and payment
processor.

How SET Works:

The cardholder goes to a merchant's web site and selects the items he or she wants to purchase.
The cardholder then clicks on the virtual checkout button or its equivalent.

This triggers software wallet to be invoked on the cardholder's PC. The software presents several
credit cards which the cardholder possesses, and one is chosen. The wallet software also receives
the digital certificates of two entities: the merchant and the acquiring bank (also called a payment
gateway). These two certificates are validated by traversing the hierarchy of trust, through
messages sent on the Internet to all the entities on the trust chain.

The SET software then generates a message containing two parts:

5
  The order information: The order information contains information confirming the
order
 The payment information: The payment information contains the card number and the
amount.

When the hash function is applied on these order information and payment information copies
we will get Message Digest 1 (MD1) and Message Digest 2 (MD2) respectively. Both MD1 and
MD2 are concatenated and a third Message Digest called Dual Signature Message Digest
(DSMD) is obtained by applying hash function. This step is the essence of SET protocol as this
step helps to hide the credit card information from merchant and the order information from bank
to protect privacy. This theme is called Dual Signature.

This data which includes the MD1, MD2, DSMD order info and credit info is sent automatically
to the merchant's web site. The merchant's is concerned with the order info and MD1; he
decrypts the order info and verifies the signature of the buyer. If the card info is acceptable to
merchant then the merchant signs the received MD1 with her private key along with an
encrypted Letter of Acceptance.

The payment info is then sent to the bank (payment gateway) along with MD2 and DSMD) and
merchant sends the MD1 with letter of acceptance.. The payment information is encrypted using
a random symmetric key, which, in turn, is encrypted with the payment gateway's public key, so
that only the payment gateway can decrypt it. In other words, the merchant will never know the
details of the card number of its customer.

The payment gateway when decrypts the information it will have four pieces of information:

1. MD1+ Letter of Acceptance

2. Payment information
3. MD2
4. DSMD

It will verify the digital certificates of both the merchant and the card holder and decrypt the
message to access the card number and the amount.

Bank will concatenate MD1 and MD2 and apply hash function to create another message digest
and compares it with the received DSMD to check that the particular account info and order info
matches and the integrity of message has been maintained.

This authorization response is then encrypted in the usual fashion and sent to the merchant, who,
in turn, will validate the message and store the response. Then the merchant will arrange to ship
the goods.