System and Network Security

Dr. Ashok Kumar Das

Professor
Center for Security, Theory and Algorithmic Research
International Institute of Information Technology, Hyderabad
E-mail: [email protected]
URL: https://www.iiit.ac.in/faculty/ashok-kumar-das/
https://sites.google.com/view/iitkgpakdas/

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 1 / 26
 Secure Electronic Transaction (SET)

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 2 / 26
Secure Electronic Transaction (SET)

Background
SET is an open encryption and security specification designed to
protect credit card transactions on the Internet.
SETv1 emerged from a call for security standards by MasterCard
and Visa in February 1996.
A wide range of companies were involved in developing the initial
specification, including IBM, Microsoft, Netscape, RSA, Terisa,
and Verisign.
Beginning in 1996, there have been numerous tests of the
concept, and by 1998 the first wave of SET-compliant products
was available.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 3 / 26
Secure Electronic Transaction (SET)

Background
SET is not itself a payment system.
Rather, SET is a set of security protocols and formats that enables
users to employ the existing credit card payment infrastructure on
an open network, such as the Internet, in a secure fashion.
SET provides three services:
I Provides a secure communications channel among all parties
involved in a transaction
I Provides trust by the use of X.509v3 digital certificates
I Ensures privacy because the information is only available to parties
in a transaction when and where necessary

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 4 / 26
SET Key features

Confidentiality of information: Cardholder account and

payment information is secured as it travels across the network.
An interesting and important feature of SET is that it prevents the
merchant from learning the cardholder’s credit card number; this
is only provided to the issuing bank. Conventional encryption by
DES is used to provide confidentiality.
Integrity of data: Payment information sent from cardholders to
merchants includes order information, personal data, and
payment instructions. SET guarantees that these message
contents are not altered in transit. RSA digital signatures, using
SHA-1 hash codes, provide message integrity. Certain messages
are also protected by HMAC using SHA-1.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 5 / 26
SET Key features

Cardholder account authentication: SET enables merchants to

verify that a cardholder is a 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.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 6 / 26
 Figure 17.8. Secure Electronic Commerce Components
Secure Electronic Transaction (SET)
(This item is displayed on page 551 in the print version)
SET Participants

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 7 / 26
SET Participants
Cardholder: A cardholder is an authorized holder of a payment
card (e.g., MasterCard, Visa) that has been issued by an issuer.
Merchant: A merchant is a person or organization that has goods
or services to sell to the cardholder.
Issuer: This is a financial institution, such as a bank, that provides
the cardholder with the payment card.
Acquirer: This is a financial institution that establishes an account
with a merchant and processes payment card authorizations and
payments.
Payment gateway: This is a function operated by the acquirer or
a designated third party that processes merchant payment
messages.
Certification authority (CA): This is an entity that is trusted to
issue X.509v3 public-key certificates for cardholders, merchants,
and payment gateways. The success of SET will depend on the
existence of a CA infrastructure available for this purpose.
Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 8 / 26
Secure Electronic Transaction (SET)
Sequence of events that are required for a transaction
1. The customer opens an account. The customer obtains a
credit card account, such as MasterCard or Visa, with a bank that
supports electronic payment and SET.
2. The customer receives a certificate. After suitable
verification of identity, the customer receives an X.509v3 digital
certificate, which is signed by the bank. The certificate verifies the
customer’s RSA public key and its expiration date. It also
establishes a relationship, guaranteed by the bank, between the
customer’s key pair and his or her credit card.
3. Merchants have their own certificates. A merchant who
accepts a certain brand of card must be in possession of two
certificates for two public keys owned by the merchant: one for
signing messages, and one for key exchange. The merchant also
needs a copy of the payment gateway’s public-key certificate.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 9 / 26
Secure Electronic Transaction (SET)
Sequence of events that are required for a transaction
4. The customer places an order. This is a process that may
involve the customer first browsing through the merchant’s Web
site to select items and determine the price. The customer then
sends a list of the items to be purchased to the merchant, who
returns an order form containing the list of items, their price, a
total price, and an order number.
5. The merchant is verified. In addition to the order form, the
merchant sends a copy of its certificate, so that the customer can
verify that he or she is dealing with a valid store.
6. The order and payment are sent. The customer sends both
order and payment information to the merchant, along with the
customer’s certificate. The order confirms the purchase of the items in
the order form. The payment contains credit card details. The payment
information is encrypted in such a way that it cannot be read by the
merchant. The customer’s certificate enables the merchant to verify the
customer.
Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 10 / 26
Secure Electronic Transaction (SET)

Sequence of events that are required for a transaction

7. The merchant requests payment authorization. The
merchant sends the payment information to the payment gateway,
requesting authorization that the customer’s available credit is
sufficient for this purchase.
8. The merchant confirms the order. The merchant sends
confirmation of the order to the customer.
9. The merchant provides the goods or service. The merchant
ships the goods or provides the service to the customer.
10. The merchant requests payment. This request is sent to the
payment gateway, which handles all of the payment processing.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 11 / 26
Secure Electronic Transaction (SET)

Dual Signature (DS)

Assume entity (A) has a composite message hMB , MC i,
where MB is the message of entity B and MC for entity C.
B needs to be sure that C receives MC .
C needs to be sure that B receives MB .
DS = EKRA [H(H(MB )||H(MC ))] is called the “dual signature”,
where E(·)/D(·) is the public key encryption/decryption using
RSA, KRA is the private key of A and KUA is the corresponding
public key of A.
A sends the message: hMB , H(MC )||DSi to B.
A also sends the message: hMC , H(MB )||DSi to C.
B and C can verify the signature without seeing each other’s
messages.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 12 / 26
Secure Electronic Transaction (SET)
Dual Signature

<MB || H(MC) || DS>

<MC || H(MB) || DS>

B C

MB = message for entity B

DS = dual signature
MC = message for entity C

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 13 / 26
Secure Electronic Transaction (SET)

Verification the dual signature by entity B

H(MB)
MB H

H(MC) || H

KUA
DS H(H(MB) || H(MC))

H(H(MB) || H(MC)) Compare?

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 14 / 26
Secure Electronic Transaction (SET)

Verification the dual signature by entity C

H(MC)
MC H

H(MB) || H

KUA
DS H(H(MB) || H(MC))

H(H(MB) || H(MC)) Compare?

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 15 / 26
Use of Dual Signature in Secure Electronic
Transaction (SET)

The sole purpose of the dual signature is to link two messages

that are intended for two different recipients.
In this case, the customer (C) wants to send the order information
(OI) to the merchant (M) and the payment information (PI) to the
bank.
The merchant does not need to know the customer’s credit card
number.
The bank does not need to know the details of the customer’s
order.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 16 / 26
Secure Electronic Transaction (SET)

Dual Signature

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 17 / 26
Use of Dual Signature in Secure Electronic
Transaction (SET)

Summary:
1 The merchant (M) has received OI and verified the signature.
2 The bank has received PI and verified the signature.
3 The customer has linked the OI and PI, and can prove the linkage.

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 18 / 26
Steps in a Secure Electronic Transaction (SET)
Cardholder Merchant Payment Gateway
PinitReq
−−−−−−→
PinitRes
←−−−−−
PReq
−−−→
PRes
←−−−
(sent anytime after PReq)
AuthReq
−−−−−−→
AuthRes
←−−−−−−
InqReq
−−−−−→
InqRes
←−−−−
CapReq
−−−−−→
CapRes
←−−−−−
Intialization (PInitReq/PInitRes)
Purchase Order (PReq/PRes)
Authorization (AuthReq/AuthRes)
Capture of Payment (CapReq/CapRes)
Cardholder Inquiry (InqReq/InqRes) [Optional]
Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 19 / 26
PinitReq (Payment Initiate Request)

BrandID
[Thumbs]
LID C
Chall C

BrandID: the brand of the credit card that the customer (i.e.,
cardholder) is using
LID C: a local ID for the transaction
[Thumbs]: optional list of certificates (thumbs) already stored by
the cardholder software
Chall C: the cardholder (customer)’s challenge, i.e., a random
nonce used to ensure timeliness

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 20 / 26
PinitRes (Payment Initiate Response)
TransID

DATE

Chall_C

Chall_M

SIG
M

CA

CM

TransID: a globally unique ID that is combined with the LID C to form

the complete transaction ID
DATE: Merchant’s current date/time
Chall M: Merchant’s challenge, i.e., a random nonce used to ensure
timeliness
CM : Merchant’s signature certificate (X.59v3)
CA : Payment gateway’s key exchange certificate (X.509v3)
PInitRes = {EKRM [TransID, DATE, Chall C, Chall M], CA , CM }
Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 21 / 26
PReq (Purchase Request)

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 22 / 26
PReq (Purchase Request)
Table: Order Information (OI)

OIData
H(PIData)
Dual Signature (DS)

Table: Order Information Data (OIData)

TransID
BrandID
DATE
Chall C
Chall M
ODSalt (random nonce)
DS = EKRC [H[H(PIData)||H(OIData)]]; KRC = private signature
key of cardholder (i.e., customer)
Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 23 / 26
PReq (Purchase Request)
Table: Payment Information (OI)

PIData
H(OIData)
Dual Signature (DS)

Table: Payment Information Data (OIData)

TransID
Amount
DATE
Encrypted Card Data = EKUA [CardData]
Chall M
H(Order)
KUA : Bank (Acquirer)’s public key

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 24 / 26
PReq (Purchase Request)

Table: Card Data

CC# (credit card number)
Expiry (expiry date of the credit card)
PAN Nonce (one-time-use)
PIN Nonce (CCV: Card Verification Value)

Table: Order
Description
Amount
ODSalt (Order description nonce)

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 25 / 26
PRes (Merchant’s Purchase Response Message)

Table: PRes
TransID
CompletionCode
[Results]
Chall C
SIGM

CompletionCode indicates whether the authorization or capture

steps have been completed
Results contain the authorization or capture codes for the
transactions if these steps have been completed
PRes = EKRM [TransID, CompletionCode, [Results], Chall C]

Dr. Ashok Kumar Das (IIIT Hyderabad) System and Network Security 26 / 26