SSL and Millicent Protocols

Presented by:
Shivnarayan Rajappa (A2305213004)
Soorya M (A2305213014)
Siddhant Bansal (A2305213034)
Sachin Kaja (A2305213510)
Siddharth Singh (A2305213513)
Rohan Sampson (A2305213519)

INTRODUCTION

SSL (Secure Sockets Layer) is an encryption protocol which is used to

secure the transmission of sensitive information over the Internet. It was
developed by Netscape and was in version 3.0 when a new protocol TLS
(Transport Layer Security) was introduced as a new version of SSL.
TLS 1.0 was comparable to SSL 3.0 but TLS 1.1 and 1.2 have significant
improvements over SSL. Both terms SSL and TLS are used interchangeably
today. SSL is built over the TCP/IP layer so that other protocols like HTTPS on
the higher levels are unaffected.

While performing sensitive tasks on the Internet, such as bank

transactions or confidential work, we need some form of encryption so that the
information may not be accessed by a third party. SSL enables this by allowing
the purchase of SSL Certificates from a Certified Authority (CA). CAs like
DigiCert let people purchase an SSL certificate for their sites. They run a
background check and assign the domain a certificate which proves that they are
trustworthy. Since the browser trusts the CA, and the CA trusts the website a
trustworthy connection may be established between the user and the server.

SSL works using both asymmetric and symmetric encryption schemes.

There is a handshaking process which allows a secure connection to be
established between the client and the server. Symmetric encryption uses the

same key to encrypt and decrypt the data. It is very fast and efficient, but if the
key is lost or a third party obtains it, then the information is at risk. Asymmetric
encryption uses 2 different keys for encryption and decryption a public key
and a private key.
Anything encrypted with the public key can only be decrypted by the
private key, and vice versa. This form of encryption is very costly (1000 times
costlier than symmetric) but provides significantly more protection from third
party attacks.

WORKING OF SSL/TLS PROTOCOL

SSL is divided into four layers Record Layer, ChangeCipherSpec

Protocol, Alert Protocol and Handshake protocol.

Record Layer:
The record layer formats the Alert, ChangeCipherSpec, Handshake and
application protocol messages. This formatting provides a header for each
message. The fields that comprise the five-byte header of the Record Layer are:
Protocol Definition (1 byte),
Protocol Version (2 bytes) and
Length (2 bytes).
The protocol messages that follow the header cannot be longer than 16,384
bytes, as specified by the SSL protocol. It provides the facilities like
confidentiality through encryption and integrity check using MAC. MAC
information is very much necessary in this layer, as it checks the integrity of the
record. This is nothing but, a hash value. MAC value is the hash value
calculated from sequence number, padding, primary data, and secret key. So
now the whole data along with the MAC is encrypted with a symmetric key and
this whole encrypted data along with the Header form complete record, ready
for transmission over TCP.

ChangeCipherSpec Protocol:
The ChangeCipherSpec layer is composed of one message that signals
the beginning of secure communications between the client and server. Though
the ChangeCipherSpec Protocol uses the Record Layer format, the actual
ChangeCipherSpec message is only one byte long, and signals the change in
communications protocol by having a value of 1.

Alert Protocol:

This protocol sends errors, problems or warnings about the connection

between the two parties. This layer is formed with two fields: the Severity
Level and Alert Description.
Severity Level: The Severity Level sends messages with a 1 or 2
value, depending on the level of concern. A message with a value of 1 is a
cautionary or warning message, suggesting that the parties discontinue their
session and reconnect using a new handshake. A message with a value of 2 is a
fatal alert message, and requires that the parties discontinue their session.
Alert Description: The Alert Description field indicates the specific error
that caused the Alert Message to be sent from a party. The alert descriptions can
be any of the followingCloseNotify, UnexpectedMessage, BadRecordMAC, DecompressionFailure,
HandshakeFailure, NoCertificate, BadCertificate, UnsupportedCertificate,
CertificateRevoked, CertificateExpired, CertificateUnknown, IllegalParameter.

Handshake Protocol:
Shivs Text

The next stage of handshake involves authentication and key exchange between
both parties.
1. Server's authentication:
o server's certificate or server's public key
o certificate request
o "hello done" notification
2. Client's authentication:
o client's certificate or client's public key
o certificate verification
Authentication and key exchange are both done by sending certificates, as
long as both sides can provide them. Using all the data transferred between the

client and the server, the client will generate a premaster secret. It will use the
servers public key to encrypt a premaster secret and send it to the server.

If the server has requested client authentication (an optional step in

the handshake), the client also signs another piece of data that is unique to
this handshake and known by both the client and server. In this case the
client sends both the signed data and the client's own digital certificate to the
server along with the encrypted premaster secret.
If the server has requested client authentication, the server attempts to
authenticate the client. If the client cannot be authenticated, the session is
terminated. If the client can be successfully authenticated, the server uses its
private key to decrypt the premaster secret, then performs a series of steps
which the
The premaster secret is used to generate a master secret which in turn will
be used to generate symmetric keys for data exchange. Both the client and the
server use the master secret to generate session keys which are symmetric keys
used to encrypt and decrypt information exchanged during the SSL session and
to verify its integrity.
Depending on if there were certificates send, and depending on the type
of these certificates, both sides may be able to verify each other's identity by
checking the validity of these certificates. This validity check is the only part of
SSL which may fail without SSL aborting the connection immediately.
The handshake's final stage.
3. server's finish:
o change cipher spec
o "finished" notification
4. client's finish:
o change cipher spec
o "finished" notification

The client informs the server that future messages from the client will
be encrypted with the session key. It then sends a separate encrypted
message indicating that the client portion of the handshake is finished.
The server sends a message to the client informing it that future
messages from the server will be encrypted with the session key. It then
sends a separate encrypted message indicating that the server portion of the
handshake is finished.

The change cipher spec message is simply a byte with value 1 which tells
the other side to set up the cipher suite agreed on in the first stage (one for data
encryption and one for subsequent key exchanges). The notification at the end
marks the completion of the handshake. It is already encrypted using the
agreed-on algorithms, and it contains a message authentication code derived
from the preceding handshake.

Advantages
Authentication
In addition to encryption, a proper SSL certificate also provides authentication.
This means you can be sure that you are sending information to the right server
and not to a criminals server. Any of the computers could pretend to be your

website and trick your users into sending them personal information. It is only
possible to avoid this by using a proper Public Key Infrastructure (PKI), and
getting an SSL Certificate from a trusted SSL provider.

Confidentiality
When the connection is established between the client and server, they both
transfer their messages through encryption which can only be decrypted using
the keys they have. This helps in keeping the data sent over by the client to be
only accessed by the server and hence prevents attacks such as man in middle,
phishing, spoofing. It also helps in e-commerce websites and to gain trust of the
customers.

Protects from phishing

A phishing email is an email sent by a criminal who tries to impersonate your
website. The email usually includes a link to their own website or uses a manin-the-middle attack to use your own domain name. Because it is very difficult
for these criminals to receive a proper SSL certificate, they wont be able to
perfectly impersonate your site.

Shivs Text

Millicent Protocol
A secure Internet payment system is required that is cost-effective and
convenient for the purchase of low-priced services and access to electronic
resources at prices in the range 0.1100 cents, for example to charge users for
web page access, email transmissions or Internet phone calls. Most existing

payment schemes such as credit card transactions are too expensive for these
purposes. Here we describe the solution offered by the Millicent scheme. The
scheme employs the simple form of secret-key-based digital signature to reduce
its computational cost. Encryption is used only where privacy is required.E
The authors of the Millicent protocol have summarized the drawbacks of
the payment methods currently available as follows. All of them will require
cryptographic security, their computing and communication costs vary, but they
are significant in all cases.E

The Millicent scheme:

The Millicent project has developed a scheme for the secure distribution
and use of scrip a specialized form of digital cash that is designed for use in
low-value transactions. Millicent is of interest here because it employs several
of the security techniques described in this chapter with an outcome that is quite
different from those of SSL and other security systems. Scrip is a form of digital
cash that is valid only for a specific vendor. It is designed to offer the following
features:

it has value only at a specific vendor

it can be specounterfeite
it is tamper-resistant and hard to counterfeit
it can be spent only by its rightful owner
it can be produced and validated efficiently

The design of the Millicent scheme is scalable because each vendors

server is responsible only for validating the scrip that it has issued. Customers
can acquire scrip directly from the vendor, or from a broker who holds scrip for
many vendors, by performing a conventional transaction.
Scrip, the vendor-specific currency introduced by Millicent, is
represented by digital tokens with the following format:

The properties field is available for uses determined by the vendor it might for
example include the customers country or state of residence, so that the
appropriate tax rate can be applied. The certificate is a digital signature
protecting all the fields in the scrip against modification. The signature is
produced by the MAC method described in Section 7.4.2. The purpose of the
remaining fields will emerge in the following description.
Scrip is generated and distributed by Brokers brokers are servers that deal in
scrip in bulk, relieving customers and vendors of some of the overheads
involved. Brokers exchange scrip for real cash, buying scrip (or the right to
generate scrip) from vendors at a discount and selling scrip to customers against
credit card or other payments. Customers may buy scrip for several vendors
from a single broker, aggregating the charges and paying at the end of a period.
Millicent was designed as an electronic cash system that avoids the
communication overheads and the delays associated with a centralized system,
while providing security adequate to prevent fraudulent use. The security of
scrip is based on digital signatures; encryption is used for secrecy where
necessary. Low-cost cryptography is used because there is no point in making
the cost of breaking the security of the system greater than the value of the
transactions for which it is used.
The Millicent scheme is free-standing. It can be implemented without support
from other services, such as a secure name service, because it does not depend
upon an externally authenticated identity for customers or vendors. Instead,
Millicent generates and distributes unique secret keys for use by the parties to
scrip transactions.

Scrip:
Scrip has the following fields :
Vendor identifies the vendor for the scrip.
Value gives the value of the scrip.

 ID# is the unique identifier of the scrip. Some portion of it is used to

select the master_scrip_secret used for the certificate.
Cust_ID# is used to produce the customer secret. A portion
of Cust_ID# is used to select the master_customer_secret which is also
used in producing the customer secret.
Expires is the expiration time for the scrip.
Props are extra data describing customer properties (age, state of
residence, etc.) to the vendor.
Certificate is the signature of the scrip.

The certificate of a piece of scrip is generated by hashing the body of the scrip
with a secret. The secret is selected using a portion of the scrip's ID#. This is
used to check if the scrips value has been tampered with or not or in other
words, this is used to check the validity of the scrip.

The certificate is recomputed and checked against the certificate sent with the
scrip. If the scrip has been tampered with, then the two certificates will not
match. Second, there is a unique identifier (ID#) included in the scrip body and
the vendor can check for double spending by seeing if it has recorded that
identifier as already spent. Generating and validating scrip each require a little
text manipulation and one hash operation. Unless the secret is known, scrip
cannot be counterfeited or altered.

Millicent Protocols
Scrip in the clear
In the simplest possible Millicent protocol, the customer just sends an
unspent piece of scrip in the clear (i.e., not encrypted or protected in any way)
along with each request to the vendor. The vendor returns the desired result
along with a new piece of scrip (also in the clear) as change.
This protocol offers almost no security: an eavesdropping third party can
intercept the scrip being returned as change and use it himself. When the
rightful owner later attempted to spend the scrip, the vendor would have a
record of it being previously spent, and would refuse the request.

Private and secure

To add security and privacy to the Millicent protocol, we establish a

shared secret between the two parties and then use the secret to set up a secure
communications channel using an efficient, symmetric encryption method.
In Millicent, scrip can be used to establish this shared key. When a
customer buys an initial piece of scrip for a vendor, a secret is generated based
on the customer identifier, and returned securely with the scrip. This requires
either that the transaction be performed using some secure non-Millicent
protocol, or that the scrip be purchased using a secure Millicent transaction.
The vendor does not directly record the secret associated with the piece of
scrip. Instead, the customer identifier (Cust_ID#) field of the scrip allows rapid
recalculation of the secret. The customer identifier must be unique whenever
scrip is transmitted to a new customer, but it need not have any connection to
the identity of the customer.
When the vendor receives the request, he derives the customer secret
from the customer identifier in the scrip, derives the message key from the
customer secret, and uses the message key to decrypt the request. The change
scrip can be returned in the clear, while the response and any new secrets are
returned to the customer encrypted by the message key.

Secure without encryption

As in the previous protocol, the customer securely gets an initial piece of

scrip and customer secret. To make a purchase, the customer sends the request,
scrip, and a "signature" of the request to the vendor. The signature is produced
in the same way that the certificate of the scrip is produced. The scrip and
request are concatenated with the customer secret. The customer runs an
efficient cryptographic one-way hash function over this string and sends the
resulting hash as the signature.
When the vendor receives the request, he derives the customer secret
from the scrip and regenerates the signature for the request. If the scrip or
request have been tampered with in any way, the signature will not match.