The document discusses electronic payment protocols. It describes the requirements of an e-payment protocol including anonymity, divisibility, transference, and overspending detection. It then summarizes the Kim and Lee protocol which uses certificate issuing, payment, and redemption schemes involving a user, bank, and merchant. Limitations are discussed along with a proposed protocol using a blind signature scheme involving registration, blind, transaction, and redemption schemes. Finally, it explains the Secure Electronic Transaction (SET) protocol involving participants, features, requirements, and dual signature implementation through purchase request, payment authorization, and payment capture events.

1. ELECTRONIC
PAYMENT
PROTOCOL
AJU MATHEWTHOMAS
1

2. Requirements of a E-Payment
Protocol:E Payment protocol encompasses three participants
(1) User  Purchases e-currency from the bank employing actual money by e payment. User then
utilizes e-currency to carry out e-payment to buy goods.
(2) Merchant  Data storage which provides user with both services and information
(3) Bank The trusted authority who mediates between user and merchant to ease the duties
they carry out.
Shared set of characteristics for an E-Payment protocol are :
(1) Anonymity  E-cash must not supply any user with information
(2) Divisibility  E-Cash can be subdivided since the notes have a basic piece
(3) Transference  E-Cash can be transferred to a trusted authority by providing the suitable
amount of currency
(4) Over spending detection  Must be used only once.
2

3. Kim and Lee Protocol:
■ An E-Payment protocol that supports multiple merchants.
■ Protocol is divided into three schemes : (i) Certificate issuing scheme (ii) Payment Scheme (iii)
Redemption Scheme
(1) Certificate Issuing Scheme:
3
User(U) requests a
certificate to a bank B by
sending his secret
information
The bank B passes
CU[User Certificate] and
SU will be employed for
the root value in payment
scheme later
User creates his/her public
and secret key pair (PKU
,SKU) & passes PKU with IU
that contains max no: of
merchants(N) ,size of
hash (n) with his credit
info to the bank
The bank generates
special infoTU which acts
as a key factor of the root
value. Only the bank can
generate the new hash
values

4. Kim and Lee Protocol (Cont.):
■ TU = h(U,rB , K) where U  User Information , rB  arbitrary number chosen by the bank and K
is the private key of the bank
■ SU=(si |si=h(si+1,Tu ),i=N-1,…..0) where si is created by a shared user bank private key
■ The certificate CU in which all the elements as well as the expiry date of the certificate EU are
signed by the bank B and pass to the User with SU and a nonce rU
■ CU = (IDB, IDU, PKU, TU, IU, EU )SKB
Where IDB  Identity of the bank
IDU  Identity of the user
PKU  Public Key of the user
TU  special information generated by the bank to the user
IU  User Certificate serial number credit card information
EU  Expiry information of the user details
SKB  Secret Key of the bank
4

5. Kim and Lee Protocol (Cont.)
Payment Scheme:
■ The root value of pay words is merged with si obtained from the bank which enables the user
U to employ the rest of the unspent pay-words in chain for multiple payments to other
merchants
■ The user generates pay-words and commitment after obtaining the certificate
■ The commitment contains identity of the merchant, the certificate, expiry date of the
commitment (EM ), root elements (wj , h(wj ,sk ) ) and other data IM such that 0≤j ≤n employed
to set up root values for other merchants.Then user signs the element MU = (V,CU, w0, h(wj ,sk
),EM , IM ,)SKU
■ To spend the remainder of the pay-words in chain,The user U must set the root value of pay-
words to be spent in subsequent payment scheme with the merging of hash chain values
respectively created by the user U and the bank B
5

6. Kim and Lee Protocol (Cont.)
Redemption Scheme:
■ Merchant performs the redemption operation with the bank with in a pre agreed period of time.
■ Bank verifies if the payment request of the merchant is correct or not by checking the certificate.
■ First, Merchant orders for redemption to a bank B by passing the user U commitment and payment
parameter.
■ Bank B checks merchant’s signature noticeable at the certificate and redeems Pj +1 to an equivalent
amount of money
■ Bank processes redemption orders from merchants less than N before being overdue
■ Finally bank completes the redemption process when the last received value wi is less than the max
value of the hash chains
6

7. Limitations of Kim and Lee Protocol:
■ The system performance is reduced by necessarily frequent signing in each transaction
■ The customer has to keep different hash chains and corresponding indices
■ The dispute arises if the merchant forges transaction records or the customer double spends
■ To securely deposit, the bank has to collect all pay-words belonging to the same chain. It
needs an additional storage space and wastes undetermined waiting time
7

8. Proposed Protocol:
■ The proposed protocol is divided into four schemes, (1) registration scheme (2) blind scheme, (3)
transaction scheme, and (4) redemption scheme
■ The blind scheme is introduced using a RSA type blind signature.This improvement makes the
pay-word protocol more efficient and keeps all other characteristics consistent
Blind Scheme
■ The user passes a withdrawl order to the bank prior to his order for any service from merchant
Step 1: Bank
■ Select secretly and randomly two large prime p and q
■ Calculate modulus nB = p *q
■ Compute ø(n) = ( p −1)(q −1)
■ Choose exponent key e where 1<e< ø(n) and gcd (e, ø(n) )=1
■ Calculate private key w where e*w ≡ 1mod ø(n)
■ Determine the public key (e,nB ) and private key (w, ø(n),p,q)
8

9. Proposed Protocol (Cont.):
Step 2 User:
■ Select arbitrary numbers r and u
■ Calculate a = r^e h(x0 ) (u^2 +1 )mod ø(n)
■ Pass (b,a) to the bank
Step 3 Bank:
■ Select an arbitrary number x1 < ø(n)
■ Pass x1 to the user
Step 4 User:
■ Choose an arbitrary value r1
■ Calculate b2 = r*r1
■ Pass α = b2 ^ e * (u-x1 ) mod ø(n) to the bank
9

10. Proposed Protocol (Cont.):
Step 5 Bank:
■ Calculate α^-1 mod ø(n)
■ Compute t1 = h(b)^w * (a(x1 ^2 + 1) * α ^-2)^2*w mod ø(n)
■ Pass (α^-1 ,t1 ) to the user
Step 6 User:
■ Calculate c1 = (u*x1 +1)* α^-1 *(b2)^e = (u*x1 + 1) (u – x1) ^ -1 modø(n)
■ Calculate s1 = t1 * r^2 * r1 ^4 modø(n)
■ Parameter (b,c1,s1) is the signature on message x0
■ Verification can be done if s1 ^e ≡ h(b)h(x0)^2 * (c1 ^2 + 1)^2 modø(n)
10

11. What is SET Protocol:
■ A cryptographic security protocol designed to ensure security & Integrity of electronic
transactions done using credit cards & debit cards.
■ Protocol was developed byVisa & Mastercard in 1996.
■ Wide range of companies like IBM, RSA, Microsoft,Terisa etc were involved in developing the
initial specification
■ Aim was to impart security to the electronic transactions which in turn will reduce operational
cost , reducing cost and it also decreases technology costs
■ Salient Features  (i) Confidentiality - All messages will be encrypted
(ii)Trust – All parties will have digital certificates
(iii) Privacy – Information will be made available only when and where
necessary
11

12. Requirement of a SET Protocol:
■ To provide confidenality of payment and ordering information
■ Ensure the integrity of all transmitted data
■ It has to keep the Payment Information & Order Information confidential by
appropriate encryptions
■ It has to be resistive against message modifications
■ It should provide interoperability and make use of best security mechanisms
12

13. Who are the participants in SET
• User who buys the productCard Holder
• Person who sells the productMerchant
• Bank of Card HolderIssuer
• Financial Institution established to the merchant who accepts the
payment from the bankAcquirer
• Function interface between SET& the existing bankcard payment
networks or authorization and payment functionsPayment Gateway
• An entity that is trusted to issue X.509v3 public key certificates for
cardholders, merchants and payment gatewaysCertification Authority
13

14. 14

15. How SET is carried out
■ The customer opens an account with a card issuer like Mastercard,VISA etc
■ Customer receives a X.509v3 certificate signed by the bank
■ A merchant who accepts a certain brand of card must possess two X.509V3 certificates
One for signing and one for key exchange
■ Customer places an order for a product through merchant’s website
■ The merchant then sends a copy of its certificate for verification
■ The customer then sends order & payment information to the merchant
■ The merchant requests payment authorization from the payment gateway prior to shipment
■ The merchant confirms order to the customer
■ The merchant provides the good or service to the customer
■ The merchant requests payment from the payment gateway
15

16. 16

17. Dual Signature
■ The concept of dual signature is aimed at connecting two information pieces meant for two
different receivers
1. Order Information for merchant
2. Payment Information for Bank
17

18. Concept of Dual Signatures:
■ Here Information related to payment will be send to the bank
■ Order information will be send to the merchant
■ Plain text of order information and message digest of payment information will be send to the
merchant
■ Plaintext of payment information and message digest of order information will be send to the
bank
■ The dual signature obtained by encrypting the message digest of Payment Order information
(POMD) will be decrypted by both the merchant and the bank using the public key of customer
obtained from the certificates
■ The certification authority provides the public key of the customer
■ The encryption is done by using private key of the customer and follows RSA encryption
■ Hashing algorithm used  SHA 1
18

19. Implementation of SET:
■ Three events should be generated to implement SET effectively
19
• Done by the
customer and
request will be
send to the
merchant
Purchase
Request
• It will be done by
the financial
institution
Payment
Authorization
• Request from the
merchant to send
the payment to
the merchant’s
bank account
Payment
Capture

20. Purchase Request:
20

21. Purchase Request ( Cont.):
■ Here Payment information, message digest of order information and dual signature will be
encrypted by using a secret key
■ This secret key is encrypted using the public key of the bank and output obtained by encrypting
using the public key is called digital envelope
■ Along with digital envelope and the encrypted component of payment info, OIMD and dual
signature Order information , MD of Payment Information and dual signature and certificate
containing the public key of the customer will also be send to the merchant
■ Merchant needs private key of the bank in order to decrypt the digital envelope which is impossible
■ Merchant applies hash on Order information to get the message digest and will be appended along
with the PIMD to get POMD after further hashing
■ Merchant uses public key of the customer to decrypt the dual signature in order to get the POMD
and this POMD will be compared with the generated POMD mentioned in the above step
21

22. Payment Authorization:
22

23. Payment Authorization (Cont.)
■ Here digital envelope & encrypted version of PI, OIMD and digital signature will be send to
the bank
■ Bank decrypts the digital envelope using its private key to get the secret key
■ This secret key will be used to decrypt the combination of PI, OIMD and digital signature
■ Bank will apply hash on the payment information to get PIMD and it will be appended with
OIMD to get POMD after hashing
■ Digital signature received will be decrypted using the public key of the customer which was
sent along with the certificate to get POMD
■ This POMD will be compared with the generated POMD above
■ If both matches,Then it indicates payment info is not altered during the transmission
23

24. Payment Capture:
■ Here merchant will send transaction id and purchase request id to the acquirer.
■ Acquirer will check and debits the amount from the customer and the same amount gets
credited to the merchant’s account
24

25. References:
■ Secure E Payment Protocol by Sattar J Aboud
■ A Review of Secure Authentication based e-Payment protocol by Mr. B Ratnakanth and Prof
P.s Avadhani
■ Geeks for Geeks  Secure Electronic transaction (https://www.geeksforgeeks.org/secure-
electronic-transaction-set-protocol/)
■ Youtube  Secure Electronic transaction by Sundeep Saradhi Kanthety
(https://www.youtube.com/watch?v=Fu82aJJ3tQQ&t=4s)
25

26. 26