You are on page 1of 49

Unit -4 –Internet payment

systems
Features of payment methods
• Anonymity-Whether a third party can trance back
the 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 such
as a bank
• Divisibility – Whether payment can be divided in
to arbitrary small payments
• Acceptability – Supported globally


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

Check Clearing process
Credit card

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 information
over 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
– Integrity ¬ messages signed digitally to ensure in integrity
– Authentication ¬ Done through PKI

Need for SET
• Each software vendors were coming up with
new 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 competition
issues, and in the process, involving all the
major software manufacturers.
SET Architecture framewrok


Merchant

Certificate
authority
Payment
gateway/
Acquirer
Internet
Authorization
and Capture
Existing financial
network
Authorization
and Capture

Issuer

Cardholder
Payment/Inquiry
Components
• Merchant --> seller
• Card holder ¬ Buyer
• Issuer ¬ Card issuing bank
• Acquirer ¬ Agent to link merchant to multiple
issuers
• Payment gateway ¬ Connected to the
acquirer
Digital Certificate system for SEF

Root CA
Brand CA
(e.g Visa
or Master)
Geopolitical CA
(e.g. Visa Asia)
Merchant CA
Cardholder CA
Payment
gateway CA
User level
CA
Dual Signature
• SET works in a very interesting manner.
• The SET protocol makes use of the concept of dual
signature. The idea is like this:
1. The cardholder takes the Payment Information (PI), containing
the cardholder’s credit card number, expiry date, etc and
hashes (digests) it to produce Payment Information Message
Digest (PIMD).
2. Similarly, the cardholder digests the Order Information (OI) to
obtain 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 called
dual, because it has inputs coming from PI as well as OI.

Dual Signature





• The cardholder now sends:
– OI, PIMD, and DS to the merchant
– PI, OIMD, and DS to the payment gateway

Dual Signature
• Merchant does not get access to PI, and hence,
cannot know the cardholder’s credit card
number.
• However, it has access to OI to process the order.
• To validate the card holder’s order,
– The merchant can decrypt DS using the cardholder’s
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.
Dual Signature

Digital Envelope

Digital
Envelope
DES
Encryption
RSA
Encryption
key
random

C
C
C
C
M
Encrypted by
key
random

Encrypted by
key
public_exchange,VBS

key
random

key
public_exchange,VBS

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
Purchase Initiation
• Card holder ¬Purchase request
– Message Contains Local Transaction Identity(ID)
– Token N1 for thwarting replay attack
– some cached certificates
• Merchant ¬ Response
– Unique transaction ID (generated based on local
transaction 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 merchant’s private key
Replay Attack

Purchase Request
• Cardholder prepares
– OI and PI
– OI¬ Unique transaction ID, N1 and N2 and other
details
– PI ¬ transaction details and payment amount and
message 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
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 holder’s certificates and dual
signature
– Response to cardholder with certificates signed with
merchant’s private key
Payment authorization
• Authorization request is encrypted with random
symmetric key B
• Key B is then encrypted with public key-exchange key
of 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 from
public key-exchange key of payment card holder
gateway)
Cardholer and merchant’s certificates



Payment Authorization
• Payment Gateway
– Obtains key B by decryption and use it to decrypt
authorization request
– Verifies merchant’s certificates and digital signture
of authorization request
– Obtains key A and cardholder information by
means of decryption
– Verifies DS accordingly

Authorization response
• On verification, Payment gateway forwards authorization
request to the issuer via current payment system
• After receiving the authorization from issuer, payment
gateway 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)

Payment capture
• Capture request ¬ transaction ID, capture amount and
other details
• Capture request from Merchant to Payment gateway
– Signed capture request (Encrypted using random
symmetric key E)
– Key E (encrypted with payment gateway’s public key-
exchange key)
– Signed capture token (encrypted using key D)
– Key D + card holder info (encrypted with payment
gateway’s public key-exchange key)
– Merchant’s digital certificates

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 merchant’s public key-exchange
key)
– Payment gateway’s digital certificates
• Capture response is stored in merchant system
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.


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 other
party.


E-Cash Coin
• The electronic coins used within the E‐cash system are unique in that they are part
ly minted by the client before being signed by the bank.
• Each coin has a serial number that is generated by the client’s cyber
wallet 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 100‐digit 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 consider
ed 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 s
hown in Figure below. The client opens the envelope and takes out the coin (un‐bli
nds it). The coin has now been signed. The carbon paper ensured that the bank’s si
gnature went through the envelope.
• The signature on the un‐blinded 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 si
gnature protocol




Coin Keys
• Problem the bank cannot see what it is signing¬how 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 wo
rth.
• The bank then signs the coin with the signature key representing this deno
mination and deducts that amount from the client’s acount. For example,
the bank might have a one‐cent signature, a 5‐cent signature, a 10‐cent sig
nature, and so on.




E-Cash

© Pay by the coins
® Check the validity of the
coins and whether they have
been spent and credit the
account accordingly
C Debit the account and sign
the blinded coins
C Send the blinded coins to the
bank
C Return the signed blinded coins
C Deposit the coins
³ Confirm the deposit
Ship goods or perform the service
C Generate the blinded coins
C Unblind the coins
Customer
Bank
VBS (Merchant)
Double Spending Prevention
• E‐cash coins are just pieces of data that can be copied. To p
revent copied coins from being spent repeatedly, this possi
ble double spending must be prevented.
• To ensure that a serial number is not spent twice, the minti
ng bank must record every coin that is deposited back to th
at bank. A very large database of all spent serial numbers
soon 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 pres
ent date
– Not appear in the database of spent coins.



Double Spending

E-Check
• Electronic check will contain an instruction to
the payer’s 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

E-Check

Deposit and Clear

Cash and transfer

Lock Box

Fund transfer

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



MilliCent
• Developed at Digital Equipment Corporation (
now Compaq) which is designed to allow pay
ments as low as one‐tenth of a cent ($0.001)
to be made.
• A Millicent payment can be efficiently
validated at a vendor’s site without the need
to contact a third party

Purchasing with MilliCent

Scrip
• Scrip is a piece of data used to represent micro‐currency
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 one‐tenth of a cent up to about $5, although there are no defi
ned upper‐ or lower‐bound limits.
– The security of scrip is based on the assumption that it is only used to
represent small amounts of money.
– It is vendor‐specific and thus has value at one vendor only.
– It can be spent only once. Double spending will be detected locally by t
he 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.
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 of public‐key cryptography. It can be efficiently produced, v
alidated, and protected using a one‐way hash function and limited symmetric
cryptography.
– Scrip cannot provide full anonymity. It has visible serial numbers that could be
recorded and traced.



Purchasing with MilliCent

Payword
• PayWord is a credit‐based 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 the
system.
• Each hash value, called a PayWord, can be sent to a merchant payment.
• A PayWord chain is vendor‐specific and the user digitally signs a
commitment to honor payments for that chain.
• Brokers mediate between users and vendors and maintain accounts for
both.
• They vouch for users by issuing a PayWord certificate allowing that user to
generate PayWords. T
• They redeem spent PayWord chains from vendors, transferring the
amount spent from the users account to the vendor.

Probability based micro payment
• In the previous micropayment schemes each
and every payment is processed by the vendor
and later verified and redeemed at a broker
or bank.
• To minimize the number of micropayment
transactions that must be performed, the
probability theory can be applied so that there
is a specified likelihood or chance that the
payment will be performed.

Probability based micro payment
• The value of the transaction is equal to the probability
of making an actual payment multiplied by the value of
that actual payment
Transaction_value = Probability * Payment_amount
For example, instead of making 1,000 micropayments
each worth 1 cent, one might make a $10 payment
with a 1/1,000 probability
• Probability‐based 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