Secure Electronic Transaction (SET)
Download
Report
Transcript Secure Electronic Transaction (SET)
Secure Electronic Transaction
(SET)
What Is SET?
SET is an open encryption and security
specification designed to protect credit card
transactions on the Internet.
SET is in effect a set of protocols for
ensuring security and confidentiality.
SET is a relatively new standard. It was first
used in February 1996 and was proposed by
Visa and MasterCard.
Requirements That SET Must
Accomplish
Provide confidentiality of ordering and payment
information.
Ensure the integrity of all transmitted data
Provide authentication that a cardholder is a
legitimate user of a credit card account.
Provide authentication that a merchant can accept
credit card transactions through its relationship with
a financial institution.
Key Features of SET
Confidentiality of information.
Integrity of Data.
Cardholder account authentication.
Merchant authentication.
Confidentiality of Information
A credit card holder’s personal and
payment information is secured as it travels
across the network. An interesting feature of
SET is that the merchant /seller never sees
the credit card number; this is only provided
to the issuing bank. Conventional
encryption using DES is used to provide
confidentiality.
Integrity of Data
Payment information sent from cardholders
to merchants include order information,
personal information and payment
instructions. SET guarantees that these
message contents are not altered in transit.
RSA digital signatures, using SHA-1 hash
codecs, provide message integrity.
Cardholder Account
Authentication
SET enables merchants to verify that a
cardholder is legitimate user of a valid card
account number. SET uses X.509v3 digital
certificates with RSA signatures for this
purpose.
Merchant Authentication
SET enables cardholders to verify that a
merchant has a relationship with a financial
institution allowing it to accept payment
cards. SET uses X.509v3 digital certificates
with RSA signatures for this purpose.
X.509 Authentication Service
• X.509v3 – this is an authentication service
which includes a public – certificate
associated with each user. Certificates are
assumed to be created by some trusted
Certification Authority(CA), and then placed
in a directory that can be viewed by others
who need to verify the public-key of
someone. CA signs the certificate with its
private-key thereby authenticating the fact
that this key does indeed belong to a user A.
X.509
Certificate
X.509 Certificate
Version: there are differences between
different versions of certificates.
Serial Number: unique integer value.
Issuer name: CA that created and signed the
certificate
Period Of Validity: expiration date.
X.509 Certificate Cont’d
Subject Name: The name of the user to
whom the certificate refers.
Subjects Public-key Information: public-key
of the subject.
Signature: Covers all other fields of the
certificate; it contains a hash code of all
other fields, encrypted with the CA’s private
key.
SET Participants
Cardholder
Merchant
Issuer
Acquirer
Payment Gateway
Certification Authority
Cardholder & Merchant
Cardholder
– This is an authorized holder of a payment card
(e.g, MasterCard, Visa) that has been issued by
an issuer.
Merchant
– This is a person or organization who has things
to sell to the cardholder. A merchant that
accepts credit cards must have a relationship
with an acquirer
Issuer & Acquirer
Issuer
– This is a financial institution such as a bank that
provides the card holder with the payment card.
Acquirer
– This is a financial institution that establishes an account
with the merchant and processes credit card
authorizations and payments. The acquirer provides
authorization to the merchant that a given card account
is active and that the proposed purchase does not exceed
the credit limit. The Acquirer also provides electronic
payments transfers to the merchant’s account.
Payment Gateway
This is a function that can be undertaken by
the acquirer or some third party that
processes merchant payment messages.
The payment gateway interfaces between
SET and the existing bankcard payment
networks for authorization and payment
functions.
Certification Authority(CA)
This is an entity that is entrusted to issue
X.509v3 public-key certificates for
cardholders, merchants, and payment
gateways.
Link Between SET Participants
SET Components and Participants
Events required for a Successful
SET Transaction
1. Customer Opens an account – customer
gets a credit card account from, such as a
Visa or MasterCard, with a bank that
supports SET.
2. The Customer receives a certificate – the
customer receives an X.509v3 digital
certificate which is signed by the bank.
This certificate verifies the customers
public key and it’s expiration date.
Events required for a Successful
SET Transaction Cont’d
3. Merchant Certificates – the merchant must
have two(2) certificates for the two public
keys it owns. One for signing messages
with and one for key exchange. The
merchant also needs a copy of the
payment gateway’s public-key certificate.
4. The customer places an order.
Events required for a Successful
SET Transaction Cont’d
5. Merchant Verification – The merchant sends an
order form to the customer, as well as a copy of
the merchants certificate, so the customer can
verify that he/she is dealing with a valid store.
6. Order & Payment Sent – The customer sends
order information (OI) and payment
information(PI) to the merchant together with the
customers certificate so the merchant can verify
that he is dealing with a valid customer. The PI is
encrypted in such a way that the merchant cannot
read it.
Events required for a Successful
SET Transaction Cont’d
7. Merchant Requests PI authorization – The
merchant forwards the PI to the payment
gateway, to determine whether the customer has
sufficient funds/credit for the purchase.
8. Merchant Confirms the order – merchant sends
confirmation of the order to the customer.
9. Merchant ships goods and services.
10. Merchant requests payment – this request for
payment is sent to the payment gateway, which
handles payment processing
SET’s Dual Signature
This is an innovation introduced by SET. The
purpose of the dual signature is to link two (2)
messages that are going to different recipients.
The customer needs to send OI and PI, to
merchant and bank respectively.
The merchant does not need to know the
customers credit card number (PI).
The bank does not need to know what the
customer is buying (OI).
Dual Signature
Purchase Request – Customer
Purchase Request – Merchant
Purchase Request – Merchant
1. verifies cardholder certificates using CA sigs
2. verifies dual signature using customer's public
signature key to ensure order has not been
tampered with in transit & that it was signed
using cardholder's private signature key
3. processes order and forwards the payment
information to the payment gateway for
authorization (described later)
4. sends a purchase response to cardholder
Payment Gateway Authorization
1. verifies all certificates
2. decrypts digital envelope of authorization block to obtain
3.
4.
5.
6.
7.
8.
symmetric key & then decrypts authorization block
verifies merchant's signature on authorization block
decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
verifies dual signature on payment block
verifies that transaction ID received from merchant
matches that in PI received (indirectly) from customer
requests & receives an authorization from issuer
sends authorization response back to merchant
Payment Capture
merchant sends payment gateway a
payment capture request
gateway checks request
then causes funds to be transferred to
merchants account
notifies merchant using capture response