Set Secure Electronic Transaction(SET)

Secure Electronic Transaction
(SET)
Suraj Dhalwar
Sushant Todkar
Snehit Deokar
Chinta Yashwanth

Outline:
♦ History
♦ SET and Requirements
♦ Key Features
♦ SET Participants
♦ Events in SET
♦ Key Technologies in SET
♦ Dual Signature
♦ Conclusion

History/Background:
-Internet shopping didn’t quite pick
up as consumers considered financial
transactions over the internet, unsafe
-Lacks the one on one transaction
feeling.
-Visa & MC came up with the idea
what we call as 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.

SET Participants
♦ Cardholder
♦ Merchant
♦ Issuer
♦ Acquirer
♦ Payment Gateway
♦ Certification Authority

SET Components and Participants

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.

Set Secure Electronic Transaction(SET)

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

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.

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

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.

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

Key Technologies of SET
♦ Confidentiality of information: DES
♦ Integrity of data: RSA digital signatures
with SHA-1 hash codes
♦ 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

♦ 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.
SET’s Dual Signature

Why Dual Signature?
♦ Suppose that customers send the merchant two messages:
• The signed order information (OI).
• The signed payment information (PI).
• In addition, the merchant passes the payment information
(PI) to the bank.
♦ If the merchant can capture another order information (OI) from
this customer, the merchant could claim this order goes with the
payment information (PI) rather than the original.

Purchase Request – Customer
The cardholder generates a one-time symmetric encryption key, KS,

Merchant Verifies Purchase Request
♦ 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.

Merchant Verification (cont’d)
– Processes the order and
forwards the payment
information to the
payment gateway for
authorization.
– Sends a purchase
response to the
cardholder.

Payment Gateway Authorization
1. verifies all certificates
2. decrypts digital envelope of authorization block to obtain
symmetric key & then decrypts authorization block
3. verifies merchant's signature on authorization block
4. decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
5. verifies dual signature on payment block
6. verifies that transaction ID received from merchant
matches that in PI received (indirectly) from customer
7. requests & receives an authorization from issuer
8. 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

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

Advantages:
-Privacy: Uses 1024 bit public key
cryptography which renders the
intercepted message unreadable !
-Integrity: Hashing & signing ensures
message sent is unaltered.
-Authentication: Uses digital
certificates to ensure the parties are
really who they claim to be.

CONCLUSION
-Uses 1024–bit cipher keys, making it
one of the strongest encryption
applications.
-If we use 100 computers each
processing 10 MIPS, it would take
2.8 x 10 11
years to break just ONE
encrypted message !!!!
Source: http://www.rsa.com/set/html/howstrong.html

Set Secure Electronic Transaction(SET)

More Related Content

What's hot (20)

Similar to Set Secure Electronic Transaction(SET) (20)

Recently uploaded (20)