Security and Threat Models – Secure Electronic Transaction (SET) Protocol

The subject of threat models is quite interesting in the information security space. It talks about how we model the application so that only the authorized users are allowed an access to the system, while other unauthorized users are not. It can be very naive to think that thinking about possible threats and modeling solutions based on them is straightforward. Attacks often happen from the most unexpected people and places.

The famous cryptography expert, Bruce Schneier, makes a very interesting point in this area. He says one must know what one is trying to protect against. Interestingly, this can be thought of as a very simple question to answer. However, only after one tries to find an answer can one know how difficult it is to do so. People often jump to answers such as setting up a firewall to protect the organization’s LAN. But many times, this does not turn out to be the right answer to a peculiar problem at hand. How a firewall, for example, will prevent attacks from insiders? While it can do so against possible intrusions and attacks from external sources, it would be rendered useless against an attack launched from within the LAN.

Based on this idea, Schneier takes the argument further. We shall explore the theme of his ideas in this article. For the explanation part, we shall use the SET protocol as an example.

The SET Protocol

The Secure Electronic Transaction (SET) is an open encryption and security specification that is designed for protecting credit card transactions on the Internet. The pioneering work in this area was done in 1996 by MasterCard and Visa jointly. They were joined by IBM, Microsoft, Netscape, RSA, Terisa and VeriSign. Starting from that time, there have been many tests of the concept, and by 1998 the first generation of SET-compliant products appeared in the market.

The need for SET came from the fact that MasterCard and Visa realized that for e-commerce payment processing, software vendors were coming up with new and conflicting standards. Microsoft mainly drove these on one hand, and IBM on the other. To avoid all sorts of future incompatibilities, MasterCard and Visa decided to come up with a standard, ignoring all their competition issues, and in the process, involving all the major software manufacturers.

SET is a very complex specification. In fact, when released, it took 971 pages to describe SET across three books! (Just for the record, SSL Version 3 needs 63 pages to describe). Thus, it is not possible to discuss it in great detail.

First, let us list down the parties involved in an SET transaction:

• Cardholder: Using the Internet, consumers and corporate purchasers interact with merchants for buying goods and services. A cardholder is an authorized holder of a payment card such as MasterCard or Visa that has been issued by an Issuer (discussed subsequently).
• Merchant: A merchant is a person or an organization that wants to sell goods or services to cardholders. A merchant must have a relationship with an Acquirer (discussed subsequently) for accepting payments on the Internet.
• Issuer: The issuer is a financial institution (such as a bank) that provides a payment card to a cardholder. The most critical point is that the issuer is the ultimately responsible for the payment of the cardholder’s debt.
• Acquirer: This is a financial institution that has a relationship with merchants for processing payment card authorizations and payments. The reason for having acquirers is that merchants accept credit cards of more than one brand, but are not interested in dealing with so many bankcard organizations or issuers. Instead, an acquirer provides the merchant an assurance (with the help of the issuer) that a particular cardholder account is active and that the purchase amount does not exceed the credit limits, etc. The acquirer also provides electronic funds transfer to the merchant account. Later, the issuer reimburses the acquirer using some payment network.
• Payment Gateway: This is a task can be taken up by the acquirer or it can be taken up by an organization as a dedicated function. The payment gateway processes the payment messages on behalf of the merchant. Specifically in SET, the payment gateway acts as an interface between SET and the existing card payment networks for payment authorizations. The merchant exchanges SET messages with the payment gateway over the Internet. The payment gateway, in turn, connects to the acquirer’s systems using a dedicated network line in most cases.
• Certification Authority (CA): This is an authority that is trusted to provide public key certificates to cardholders, merchants and payment gateways. In fact, CAs are very crucial to the success of SET.

Page 1 of 2

Dual Signature

SET works in a very interesting manner. The SET protocol makes use of the concept of dual signature. The idea is like this:

1. The cardholder takes the Payment Information (PI), containing the cardholder’s credit card number, expiry date, etc and hashes (digests) it to produce Payment Information Message Digest (PIMD).
2. Similarly, the cardholder digests the Order Information (OI) to obtain Order Information Message Digest (OIMD)
3. The cardholder combines PIMD and OIMD to produce Payment and Order Message Digest (POMD).
4. The cardholder encrypts the POMD with its private key. The output of this process is the Dual Signature (DS). It is called dual, because it has inputs coming from PI as well as OI.

The cardholder now sends:

• OI, PIMD, and DS to the merchant
• PI, OIMD, and DS to the payment gateway

As we can see, the merchant does not get access to PI, and hence, cannot know the cardholder’s credit card number. However, it has access to OI to process the order. Also, to validate the card holder’s order, the merchant can decrypt DS using the cardholder’s public key to obtain the first POMD; and separately combine OIMD and PIMD to also compute the second POMD. If the two POMD values match, the merchant is happy that the order was indeed sent by the cardholder.

Analyzing SET

We can see that SET helps protect the credit card number from the merchant. Moreover, the cardholder signs the transaction. Hence, the cardholder cannot claim later that her credit card was misused by someone else. This is indeed what we expect from a credit card payment protocol.

However, there is a very dangerous possibility in this model. The user would be held liable for any transaction performed by the SET software on the user’s computer. This is because all outgoing transactions will have the user’s digital signature. What if a malicious program exploits some flaw in the user’s computer, and subverts the SET software? The SET software might sign an incorrect transaction, causing financial losses to the user.

In the traditional credit card transaction (without SET), the user can at least claim that her credit card details were stolen and misused. However, what about the SET situation now? How can the user deny the digital signature?

Threat models, can therefore, be very tricky. Any solution has to take into account all such possibilities!

About the author: Atul Kahate is Head – Technology Practice, PrimeSourcing (the The Global IT Services business from i-flex solutions limited). He has authored 16 books on Information Technology, 2 on cricket, and over 1500 articles on both of these in various newspapers/journals.He writes about Java Security in this monthly column on IndicThreads.com.

Page 2 of 2