Unit -4 –Internet payment systems

7/27/2019 Unit -4 Internet payment systems

1/49

Unit -4Internet payment

systems


2/49

Features of payment methods

Anonymity-Whether a third party can trance backthe transaction

Security forged payment

Overhead cost OH cost of processing payment Transferability Whether payment can be carried

out without the involvement of a third party suchas a bank

Divisibility Whether payment can be divided into arbitrary small payments

Acceptability Supported globally


3/49

4C payment methods comparison

Cash Credit card Check Credit/debit

Security Good Good Good Good

Overhead cost Lowest, in general Higher than cash

and credit/debit

because of the paper

work involved

Highest, in general Low

Transferability Yes No No No

Acceptability Yes, in general Yes, in general No, in general it can

only be used locally

No, in general it can

only be used locally

Anonymity Yes, in general No No No

Divisibility Not completely

divisible

Yes Yes Yes


4/49

Check Clearing process


5/49

Credit card


6/49

SET Protocol

SET Secure Electronic Transaction

Before SET, Credit card payment was done through SSL(Secure Socket Layer)

SSL ensure secure transmission of credit card informationover the internet but not on line authorization of card

SET is supported by Visa , Master card

Caters 3 credit card payments

Confidentiality

messages are encrypted Integritymessages signed digitally to ensure in integrity

Authentication Done through PKI


7/49

Need for SET

Each software vendors were coming up withnew and conflicting standards.

Microsoft mainly drove these on one hand,

and IBM on the other. To avoid all sorts of future incompatibilities,

MasterCard and Visa decided to come up with

a standard, ignoring all their competitionissues, and in the process, involving all themajor software manufacturers.


8/49

SET Architecture framewrok

Merchant

Certificate

authority

Payment

gateway/

AcquirerInternet

Authorization

and Capture

Existing financial

network

Authorization

and Capture

Issuer

Cardholder

Payment/Inquiry


9/49

Components

Merchant --> seller

Card holder Buyer

Issuer

Card issuing bank Acquirer Agent to link merchant to multiple

issuers

Payment gateway Connected to theacquirer


10/49

Digital Certificate system for SEF

Root CA

Brand CA

(e.g Visa

or Master)

Geopolitical CA

(e.g. Visa Asia)

Merchant CA Cardholder CAPayment

gateway CAUser level

CA


11/49

Dual Signature

SET works in a very interesting manner.

The SET protocol makes use of the concept ofdualsignature. The idea is like this:1. The cardholder takes the Payment Information (PI), containing

the cardholders credit card number, expiry date, etc andhashes (digests) it to produce Payment Information MessageDigest (PIMD).

2. Similarly, the cardholder digests the Order Information (OI) toobtain Order Information Message Digest (OIMD)

3. The cardholder combines PIMD and OIMD to produce

Payment and Order Message Digest (POMD).4. The cardholder encrypts the POMD with its private key. The

output of this process is the Dual Signature (DS). It is calleddual, because it has inputs coming from PI as well as OI.


12/49

Dual Signature

The cardholder now sends:

OI, PIMD, and DS to the merchant

PI, OIMD, and DS to the payment gateway


13/49

Dual Signature

Merchant does not get access to PI, and hence,cannot know the cardholders credit cardnumber.

However, it has access to OI to process the order.

To validate the card holders order, The merchant can decrypt DS using the cardholders

public key to obtain the first POMD

separately combine OIMD and PIMD to also compute

the second POMD. If the two POMD values match, the merchant is happy

that the order was indeed sent by the cardholder.


14/49

Dual Signature


15/49

Digital Envelope

Digital

Envelope

DES

Encryption

RSA

Encryption

keyrandom

M

Encrypted by

keyrandom

Encrypted by

keypublic_exchange,VBSkeyrandom

keypublic_exchange,VBS


16/49

SET Information Flow

(5) Authorization request

(6) Authorization response

(7) Capture request

(2) Purchase initialization response

(1) Purchase initialization request

(3) Purchase request

(4) Purchase response

Inquiry request (optional)

Inquiry response (optional)

Acquirer(Payment

Gateway)Merchant

(8) Capture response

Cardholder


17/49

Purchase Initiation

Card holderPurchase request

Message Contains Local Transaction Identity(ID)

Token N1 for thwarting replay attack

some cached certificates

Merchant Response

Unique transaction ID (generated based on localtransaction ID), serves as ID for further transactions

Nounce N1 from cardholder

and Nounce N2 generated by merchant

Its certificates and payment gateway certificates

Digitally signed by merchants private key


18/49

Replay Attack


19/49

Purchase Request

Cardholder prepares OI and PI

OI Unique transaction ID, N1 and N2 and otherdetails

PI transaction details and payment amount andmessage digest of the order description

Dual signature is generated with OI and PI

Digital envelope PI is encrypted with random symmetric key A. Cardholder info is encrypted with public key-exchange

key of payment gateway


20/49

Purchase request

Following info sent to merchant OI + DS + H [PI]

PI + DS + H [OI] (all encrypted using key A)

Key A + cardholder in (encrypted with public key-exchange key of payment gateway)

Cardholder certificates

Purchase response Verifies the card holders certificates and dual

signature Response to cardholder with certificates signed with

merchants private key


21/49

Payment authorization

Authorization request is encrypted with randomsymmetric key B

Key B is then encrypted with public key-exchange keyof payment gateway to form digital envelope

Only payment gateway can get Key B Following info sent to Payment Gateway

Encrypted authorization request and encrypted key B

PI + DS + H [OI] (all encrypted using key A)

Key A + cardholder in (encrypted with frompublic key-exchange key of payment card holder

gateway)

Cardholer and merchants certificates


22/49

Payment Authorization

Payment Gateway

Obtains key B by decryption and use it to decrypt

authorization request

Verifies merchants certificates and digital signtureof authorization request

Obtains key A and cardholder information by

means of decryption Verifies DS accordingly


23/49

Authorization response

On verification, Payment gateway forwards authorizationrequest to the issuer via current payment system

After receiving the authorization from issuer, paymentgateway sends authorization response to the merchant

Response message

transaction ID, authorization code,amount authorized, and other info abt the transaction

Authorization response Signed authorization response (encrypted with random

symmetric key C)

Key C (encrypted with public key-exchange key merchant) Capture token (encrypted with random symmetric key D )

Key D + card holder information (encrypted with public key-exchange key of payment gateway)


24/49

Payment capture

Capture request transaction ID, capture amount andother details

Capture request from Merchant to Payment gateway

Signed capture request (Encrypted using randomsymmetric key E)

Key E (encrypted with payment gateways public key-exchange key)

Signed capture token (encrypted using key D)

Key D + card holder info (encrypted with paymentgateways public key-exchange key)

Merchants digital certificates


25/49

Capture response

Capture response transaction ID, capture

amount, capture code (generated) and other info

Payment gateway to merchant

Signed capture response(Encrypted using random

symmetric key F)

Key F (encrypted with merchants public key-exchange

key)

Payment gateways digital certificates

Capture response is stored in merchant system


26/49

E - Cash

E- cash should have following properties:

Inability of third parties to determine the payee,

time or amount of payments made by an

individual. Ability of individuals to provide proof of payment,

or determine the identity of the payee under

exceptional circumstances.

Be able to stop use of the payment media if

reported stolen.


27/49

Blind signature

Blind signature schemes, first introduced by

Chaum allow a person to get a message signed

by another party without revealing any

information about the message to the otherparty.


28/49

E-Cash Coin

The electronic coins used within the Ecash system are unique in that they are partly minted by the client before being signed by the bank.

Each coin has a serial number that is generated by the clients cyberwallet software.

The serial numbers are chosen randomly and are large enough so that

there is very little chance that anyone else will ever generate the same serial numb

ers. For example, using a 100digit serial number can guarantee this. The serial number is blinded and sent to the bank to be signed. The bank is unabl

e to see the serial number on the coin it is signing. The method can be considered similar to putting the coin and a piece of carbon paper into an envelope.

The envelope is sent to the bank where it is signed and returned to the client, as shown in Figure below. The client opens the envelope and takes out the coin (unblinds it). The coin has now been signed. The carbon paper ensured that the banks si

gnature went through the envelope. The signature on the unblinded coin appears the same as any other normal digital

signature. There is no way to tell from it that the coin was signed using the blind signature protocol


29/49


30/49


31/49

Coin Keys

Problem the bank cannot see what it is signinghow can a value be assig

ned to the coin?

The problem can be solved by the bank using a different signature key for

each coin denomination.

The client informs the bank of the value it wants the blinded coin to be worth.

The bank then signs the coin with the signature key representing this deno

mination and deducts that amount from the clients acount. For example,

the bank might have a onecent signature, a 5cent signature, a 10cent sig

nature, and so on.


32/49

E-Cash

Pay by the coins

Check the validity of thecoins and whether they have

been spent and credit the

account accordingly

Debit the account and signthe blinded coins

Send the blinded coins to thebank

Return the signed blinded coins

Deposit the coins

Confirm the deposit

Ship goods or perform the service

Generate the blinded coins

Unblind the coins

Customer Bank VBS (Merchant)


33/49

Double Spending Prevention

Ecash coins are just pieces of data that can be copied. To prevent copied coins from being spent repeatedly, this possible double spending must be prevented.

To ensure that a serial number is not spent twice, the minting bank must record every coin that is deposited back to that bank. A very large database of all spent serial numberssoon develops. A valid unspent coin must Be signed, with any denominational signature, by the

bank

Have an expiry date associated with it that is later than the present date

Not appear in the database of spent coins.


34/49

Double Spending


35/49

E-Check

Electronic check will contain an instruction to

the payers bank to make a payment of a

specified amount to an identified payee.

The fact that the check is in electronic form

and is being conveyed across computer

networks should allow more flexibility in the

handling of the check


36/49

E-Check


37/49

Deposit and Clear


38/49

Cash and transfer


39/49

Lock Box


40/49


41/49

Micro Payment

Need for a payment system that can

efficiently transfer very small amounts,

perhaps less than a penny, in a single

transaction

Micropayments, however, have not been

available in conventional commerce, and their

introduction opens up many new areas of

business


42/49

MilliCent

Developed at Digital Equipment Corporation (

now Compaq) which is designed to allow pay

ments as low as onetenth of a cent ($0.001)

to be made.

A Millicent payment can be efficiently

validated at a vendors site without the need

to contact a third party


43/49

Purchasing with MilliCent


44/49

Scrip Scrip is a piece of data used to represent microcurrency

within the Millicent system. Scrip has the following propertie

A piece of scrip represents a prepaid value, much like prepaid phone c

ards, fare cards, or coupons.

Scrip can represent any denomination of currency. Expected values ran

ge from onetenth of a cent up to about $5, although there are no defined upper or lowerbound limits.

The security of scrip is based on the assumption that it is only used to

represent small amounts of money.

It is vendorspecific and thus has value at one vendor only.

It can be spent only once. Double spending will be detected locally by the vendor at the time of purchase.

It can be spent only by its owner. A shared secret is used to prevent sto

len scrip being spent.


45/49

Scrip

Scrip cannot be tampered with or its value changed.

It is computationally expensive to counterfeit scrip. The cost of doing so outwe

ighs the value of the scrip itself.

Scrip makes no use ofpublickey cryptography. It can be efficiently produced, v

alidated, and protected using a oneway hash function and limited symmetric

cryptography. Scrip cannot provide full anonymity. It has visible serial numbers that could be

recorded and traced.


46/49

Purchasing with MilliCent


47/49

Payword

PayWord is a creditbased micropayment scheme designed by Ron Rivest(MIT Laboratory for Computer Science, Massachusetts) and Adi Shamir(Weizmann Institute of Science, Rehovot, Israel)

PayWord uses chains of hash values to represent user credit within thesystem.

Each hash value, called a PayWord, can be sent to a merchant payment.

A PayWord chain is vendorspecific and the user digitally signs acommitment to honor payments for that chain.

Brokers mediate between users and vendors and maintain accounts forboth.

They vouch for users by issuing a PayWord certificate allowing that user togenerate PayWords. T

They redeem spent PayWord chains from vendors, transferring theamount spent from the users account to the vendor.


48/49

Probability based micro payment

In the previous micropayment schemes eachand every payment is processed by the vendorand later verified and redeemed at a broker

or bank. To minimize the number of micropayment

transactions that must be performed, theprobability theory can be applied so that there

is a specified likelihood or chance that thepayment will be performed.


49/49

Probability based micro payment

The value of the transaction is equal to the probabilityof making an actual payment multiplied by the value ofthat actual payment

Transaction_value = Probability * Payment_amount

For example, instead of making 1,000 micropaymentseach worth 1 cent, one might make a $10 paymentwith a 1/1,000 probability

Probabilitybased micropayments eliminate the cost of

making the actual micropayment for most transactions,but add the overhead of fairly predicting a random

event with known probability

Documents

Unit -4 –Internet payment systems