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 cardholders 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 cardholders credit card
number.
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.
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 merchants 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 holders certificates and dual
signature
Response to cardholder with certificates signed with
merchants 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 merchants certificates



Payment Authorization
Payment Gateway
Obtains key B by decryption and use it to decrypt
authorization request
Verifies merchants 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 gateways public key-
exchange key)
Signed capture token (encrypted using key D)
Key D + card holder info (encrypted with payment
gateways public key-exchange key)
Merchants 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 merchants public key-exchange
key)
Payment gateways 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 Ecash 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 clients 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 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 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 (unbli
nds 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 si
gnature protocol




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 wo
rth.
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.




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
Ecash 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 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

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 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

Purchasing with MilliCent

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 defi
ned 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 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 publickey 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.



Purchasing with MilliCent

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 the
system.
Each hash value, called a PayWord, can be sent to a merchant payment.
A PayWord chain is vendorspecific 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
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