Your SlideShare is downloading. ×
Unit 9 set
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Unit 9 set

938
views

Published on

Secure electronic transaction , dual signature

Secure electronic transaction , dual signature


0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
938
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Prof. Chintan Patel Information Security MEFGI , RAJKOT Unit - 9
  • 2. • “An open encryption and security specification designed to protect credit card transaction on internet” • Companies : Microsoft, VISA , MasterCard , Netscape, RSA , Terisa , and Verisign. • SET is not a payment system , it’s a set of protocol for  To provide secure communication channel among all parties involved in a transaction.  Provide trust by using X.509v3 certificates.  Ensure privacy. Information must be available to parties in a transaction when and where necessary.
  • 3. • Provide confidentiality in Payment info. (PI) and order Info.(OI). • Ensure integrity of all transmitted data. • Provide authentication that a cardholder is a valid user of credit card account. • Facilitate interoperability among software and network provider. • Create a protocol that neither depends on transport security mechanism nor prevents their use.
  • 4. • Prevents merchant from learning the card holder’s credit card number.  Encryption by DES is used for to provide confidentiality • Integrity of data :  Guarantees of integrity using RSA digital signature using SHA-1,  For some messages HMAC using SHA-1 • Cardholders account authentication :  Uses X.509v3 digital certificate with RSA signature • Merchant authentication :  Cardholders can verify that merchant has relationship with financial institute that allows them to accept payment cards  X.509v3 digital certificate with RSA signature
  • 5. • Card holder :  you • Merchant :  bigbazar or flipcart • Issuer :  bank that provides cardholder with the payment card , responsible for payment of debt of the cardholder • Acquire :  Axis bank, provides authorization to the merchant that a given card account is active and proposed purchase does not exceed the credit limit.  Also provides electronic transfer of payment to the merchant’s account. • Payment gateway :  Function operated by the acquire or a designated third parties that processes merchant payment messages.
  • 6. 1. The customer opens an account. 2. The customer receives a certificate.(contains customer’s public key) 3. Merchants have their own certificates. (Two certificates: one for signing messages and the other for key exchange.) 4. The customer places an order. 5. The merchant is verified. (merchant sends a copy of its certificate so that customer can verify it.) 6. The order and payment are sent. >The payment information is encrypted in such a way that it can not be read by the merchant. > Customer’s certificate enables the merchant to verify the customer.
  • 7. 7. The merchant requests payment authorization. >Merchant sends the payment information to payment gateway, requesting authorization. 8. The merchant confirms the order. >Merchant sends confirmation to customer. 9. The merchant provides the goods or service. >Merchant ships goods to customer. 10. The merchant requests payments. >Merchant sends payment request to the payment gateway, which handles payment processing.
  • 8. • Objective: to link two messages that are intended for two different recipients. • Customer wants to send: 1. Order Information (OI) to merchant. 2. Payment information (PI) to bank. >Customer wants to link these two items and also wants to keep them separate.
  • 9. • Merchant does not need to know about Customer credit card number. • Bank does not need to know the details of customer’s order. • However, these two items must be linked to resolve any dispute. • Customer can prove that this payment was intended for this order not for other goods or service. • //Merchant can separate the OI and PI per order //
  • 10. • Customer takes the hash (SHA-1) of PI. • Customer takes the hash of OI. • Concatenates these two and takes hash of the result. • Customer signs the final hash with his private key. DS = EKRc[H(H(PI)||H(OI))]
  • 11. • The operation for dual signature is as follows:  Take the hash (SHA-1) of the payment and order information.  These two hash values are concatenated [H(PI) || H(OI)] and then the result is hashed.  Customer encrypts the final hash with a private key creating the dual signature. H(OI))]||)(([ PIHHEDS cKR
  • 12. • Merchant has DS, OI, and PIMD. >Merchant computers 1. H(PIMD||H(OI)). 2. DKUC[DS] >If both these items are equal, the merchant has verified the DS. //Merchant is never sent the PI//
  • 13. >The bank has DS, PI, and OIMD. >The bank computers 1. H(H(PI)||OIMD). 2. DKUC [ DS ] >If both these items are equal, the merchant has verified the DS. //The bank is never sent the OI.//
  • 14. • The merchant has received OI and verified the signature. • The bank has received PI and verified the signature. • The customer has linked the OI and PI and can prove the linkage.
  • 15.  card holder registration  merchant registration  purchase request  payment authorization  payment capture  certificate query  purchase inquiry  purchase notification  sale transaction  authorization reversal  capture reversal  credit reversal
  • 16. • Look at three steps: 1. Purchase request 2. Payment authorization 3. Payment capture
  • 17. • Browsing, Selecting, and Ordering is Done • Purchasing Involves 4 Messages: I. Initiate Request II. Initiate Response III. Purchase Request IV. Purchase Response
  • 18. • Basic Requirements:  Cardholder Must Have Copy of Certificates for Merchant and Payment Gateway • Customer Requests the Certificates in the Initiate Request Message to Merchant  Brand of Credit Card  ID Assigned to this Request/response pair by customer  Nonce
  • 19. • Merchant Generates a Response  Signs with Private Signature Key  Include Customer Nonce  Include Merchant Nonce (Returned in Next Message)  Transaction ID for Purchase Transaction • In Addition …  Merchant’s Signature Certificate  Payment Gateway’s Key Exchange Certificate
  • 20. • Cardholder Verifies Two Certificates Using Their CAs and Creates the OI and PI. • Message Includes:  Purchase-related Information  Order-related Information  Cardholder Certificate
  • 21.  Purchase-related Information: Forwarded to the Payment Gateway by the Merchant  PI  Dual Signature calculated over PI and OI and signed with the customer’s private signature key  OI Message Digest (OIMD)  Digital Envelope  Order-related Information: Information needed by Merchant  OI  Dual Signature  PI Message Digest (PIMD)  Cardholder Certificate: Contains the Cardholder’s public signature key  Used by Merchant and by Payment Gateway
  • 22. • When the merchant receives the Purchase Request message, it performs the following actions:  Verify the cardholder certificates by means of its CA signatures.  Verifies the dual signature using the customer’s public key signature.
  • 23.  Processes the order and forwards the payment information to the payment gateway for authorization.  Sends a purchase response to the cardholder.
  • 24. • Message that Acknowledges the Order and References Corresponding Transaction Number. • Block is  Signed by Merchant Using its Private Key  Block and Signature Are Sent to Customer Along with Merchant’s Signature Certificate • Upon Reception  Verifies Merchant Certificate  Verifies Signature on Response Block  Takes the Appropriate Action
  • 25. • The payment process is broken down into two steps:  Payment authorization  Payment capture
  • 26. Purchase Authentication • The merchant sends an authorization request message to the payment gateway consisting of the following: • Authorization Request Message:  Purchase-related Information: Customer Information  PI  Dual Signature  OI Message Digest (OIMD)  Digital Envelope  Authorization-related Information: Merchant Information  Authorization Block:  Transaction ID  Signed with Merchant’s Private Key  Encrypted with One-time Key Generated by Merchant  Digital Envelope: Encrypt One-time Key with Private Key  Certificates:  Cardholder’s Signature Key Certificate (Verify Dual Sign.)  Merchant’s Signature Key Certificate (Verify Merchant)  Merchant’s Key-exchange Certificate (Gateway )
  • 27. • Verify All Certificates • Decrypt Authorization Block Digital Envelope to Obtain Symmetric Key and Decrypt Block • Verify Merchant Signature on Authorization Block • Decrypt Payment Block Digital Envelope to Obtain Symmetric Key and Decrypt Block • Verify Dual Signature on Payment Block • Verify Received Transaction ID Received from Merchant Matches PI Received from Customer • Request and Receive Issuer Authorization
  • 28. Authorization Response Message: •Authorization-related Information: Authorization blocks Signed by Gateway’s private key Encrypted with one-time symmetric key generated by Gateway Digital envelope containing one-time key encrypted with Merchant’s public key • Capture Token Information: Information to be used to effect payment. Block Signed, encrypted Capture Token with Digital Envelope Not processed by merchant Must be returned with a payment request • Certificate: The Gateway’s signature key certificate.
  • 29. Simple purchase transaction: • Four messages between merchant and customer • Two messages between merchant and payment gateway • 6 digital signatures • 9 RSA encryption/decryption cycles • 4 DES encryption/decryption cycles • 4 certificate verifications Scaling: • Multiple servers need copies of all certificates
  • 30. • Next lecture : Firewall

×