Scribd
Upload
38 views19 pages

L30 - Secure Electronic Transaction

SET (Secure Electronic Transaction) is a protocol that aims to secure credit card transactions on the internet. It uses encryption, digital signatures, and certificates to authenticate parties and ensure confidentiality, integrity, and non-repudiation of payment information and orders. A dual signature links the payment and order information while limiting what each recipient receives. The payment process involves authorization from the payment gateway followed by capture once the goods are delivered.

Uploaded by

Shivam Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
38 views19 pages

L30 - Secure Electronic Transaction

SET (Secure Electronic Transaction) is a protocol that aims to secure credit card transactions on the internet. It uses encryption, digital signatures, and certificates to authenticate parties and ensure confidentiality, integrity, and non-repudiation of payment information and orders. A dual signature links the payment and order information while limiting what each recipient receives. The payment process involves authorization from the payment gateway followed by capture once the goods are delivered.

Uploaded by

Shivam Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Secure Electronic

Transaction
Secure Electronic
Transaction
• An application-layer security mechanism, consisting
of a set of protocols.
• Protect credit card transaction on the Internet.
• Companies involved:– MasterCard, Visa, IBM,
Microsoft, Netscape, RSA, Cyber Cash, Net Bill
• Not an ordinary payment system.
• It has a complex technical specification
SET Business
Requirements
• Provide confidentiality of payment and ordering
information.
• Ensure the integrity of all transmitted data.
• Provide authentication that a cardholder is a ultimate
user of a credit card account
• Provide authentication that a merchant can accept
credit card transactions through its relationship with
a financial institution
SET Business Requirements (cont’d)

• Ensure the use of the best security practices and system design
techniques to protect all legitimate parties in an electronic
commerce transaction
• Create a protocol that neither depends on transport security
mechanisms nor prevents their use
• Facilitate and encourage interoperability among software and
network providers
Secure Electronic
Transaction : Protocol
• Confidentiality: All messages are encrypted
• Trust: All parties must have digital certificates
• Privacy: information made available only when and where
necessary
• Developed by Visa and MasterCard
• Designed to protect credit card transactions
Parties in SET
Implementation of SET
• Data Confidentiality  Encryption
• Who am I dealing with?  Authentication
• Message integrity  Message Digest
• Non-repudiation  Digital Signature
• Access Control  Certificate Attributes
SET Transactions
• The customer sends order and 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 goods or service to the
customer.
• The merchant requests payment from the payment
gateway.
SET Transactions
Key Technologies of SET
• Confidentiality of information:
Encryption
• Integrity of data: RSA digital signatures with SHA-1 hash codes
etc
• Cardholder account authentication:
X.509v3 digital certificates with RSA signatures
• Merchant authentication:
X.509v3 digital certificates with RSA signatures
• Privacy: separation of order and payment information using
dual signatures
Dual Signatures for SET
 Concept: Link Two Messages Intended for Two Different Receivers:
• Order Information (OI): Customer to Merchant
• Payment Information (PI): Customer to Bank

 Goal: Limit Information to A “Need-to-Know”Basis:


• Merchant does not need credit card number.
• Bank does not need details of customer order.
• Afford the customer extra protection in terms of privacy by keeping
these items separate.
• This link is needed to prove that payment is intended for this order and not
some other one.
Dual Signature Operation

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.
DS = EKRC [ H(H(PI) | | H(OI)) ]
SET Supported
Transactions
card holder registration  purchase notification
merchant registration  sale transaction
purchase request
payment authorization  authorization reversal
payment capture  capture reversal
certificate query  credit reversal
purchase inquiry
Credit Card Protocols
• SSL (System Session Layer ) 1 or 2 parties have private keys
• TLS (Transport Layer Security)

• SEPP (Secure Encryption Payment Protocol)


– MasterCard, IBM, Netscape
• STT (Secure Transaction Technology)
– VISA, Microsoft

• SET (Secure Electronic Transactions)


– MasterCard, VISA all parties have certificates
Payment Process
• The payment processis broken downinto two
steps:
• Payment authorization
• Payment capture
• Payment Authorization
• The merchant sends an authorization request message to the payment
gateway consisting of the following:
• Purchase-related information
• PI
• Dual signature calculated over the PI & OI and signed with customer’s
private key.
• The OI message digest (OIMD)
• The digital envelop
• Authorization-related information
• Certificates
Payment Authorization (cont’d)
• Authorization-related information
• An authorization block including:
• A transaction ID
• Signed with merchant’s private key
• Encrypted one-time session key
• Certificates
• Cardholder’s signature key certificate
• Merchant’s signature key certificate
• Merchant’s key exchange certificate
Payment: Payment Gateway
• 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
SET Interoperability
• Software development on SET protocol
• Brokat, Entrust, Globeset, GTE, IBM, TrinTech, Verisign

• SET costs
• Software development
• Hardware and runtime increases with high volume of
transactions

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy