6.3. SET - Secure Electronic Transactions

SET (Secure Electronic Transaction) was developed by the SET Consortium, which includes organizations such as Visa, MasterCard, GTE, IBM, Microsoft, VeriSign, SAIC, RSA Data Security, and others [5]. SET provides confidentiality of payment and order information. Payment information cannot be viewed by the merchant; only by the payment authorization and processing entities. Order information can only be seen by the merchant and not by the payment processing entities. Through SET, merchants are authenticated to guarantee they can accept payment card transactions and cardholders are authenticated as legitimate users of a credit card.

Instead of using a plastic credit card, customers use an electronic wallet (e-wallet). This is a helper application or a plug-in to the browser and is used to store all the information about the credit cards the customer possesses as well as SET digital certificates for each of these cards. A digital certificate (see Section 5.4.1) serves the purpose of the signature and a picture ID on credit card transactions carried out in the physical world. Cardholders, merchants, and payment gateways have SET digital certicates used for mutual authentication during a SET transaction.

The three main entities involved in a SET purchase transaction are the customer's e-wallet, the merchant's POS software, and the payment gateway. The payment gateway, also called the acquirer payment gateway, is the interface between the acquirer bank and the banking network that supports authorizations and settlement [5]. The payment gateway serves the same purposes as the Card Processing Service described before.

6.3.1. Use of Cryptography in SET

The main cryptographic processes used by SET to carry out its transactions are authentication through digital certificates, digital signatures, digital envelopes, double signatures, and simple encapsulation with signature and baggage. Chapter 5 explained how digital certificates can be used to authenticate two parties involved in a message exchange. As we saw, digital certificates are used to carry the public key of the certicate owner. Digital certificates are issued by trusted Certificate Authorities (CAs), which sign the certificates with their private keys. In SET, CAs are organized in a hierarchical fashion. From the top down, the hierarchy consists of a root CA, a brand (e.g., Visa or MasterCard) CA, a geopolitical (e.g., Brazil) CA, and a cardholder CA. Each CA in the chain signs the certificates it issues. SET requires that all certificates in the chain be verified.

Digital signatures in SET work as described in Chapter 5. The thing to keep in mind is that digital signatures in SET use the Secure Hashing Algorithm (SHA-1) to generate message digests and 1,024-bit RSA for encrypting the message digest with the sender's private key. It should also be noted that when SET uses symmetric encryption, it uses the Data Encryption Standard (DES) as explained in the following subsections.

6.3.1.1. Digital Envelopes

A digital envelope is basically a DES-encrypted message along with the RSA-encrypted key used in DES encryption. The process of creating and opening a digital envelope is illustrated in Fig. 6.3. To create a digital envelope, the sender randomly generates a key to be used in DES encryption (step 1). This key is used to encrypt the message using DES (step 2). The DES key is encrypted with RSA using the receiver's public key (step 2). The digital envelope is then formed by concatenating the DES-encrypted message with the RSA-encrypted DES key. This envelope is transmitted to the receiver (step 3).

Only the intended receiver will be able to open the digital envelope because the receiver's private key is necessary to decrypt, using RSA, the DES key (step 4). The DES key is then used to decrypt the DES-encrypted message to obtain the original message (step 5).

So, creating a digital envelope requires one DES encryption and one RSA public operation. Opening a digital envelope requires one DES decryption and one RSA private key operation.

6.3.1.2. Double Signatures

When SET sends an authorization request from the e-wallet to the merchant's POS software, it sends both order information and payment information. However, as we mentioned at the beginning of this section, SET shields the payment information from the merchant but allows it to pass to the payment gateway as we will see in Section 6.3.2. For that purpose, SET uses a doubly signed message. We illustrate the creation of a doubly signed message with the help of Fig. 6.4.

Imagine that the e-wallet (EW) wants to send a two-part message to the merchant's POS software. Part one of the message is intended to the merchant and part two to the payment gateway. The e-wallet software creates a digital envelope for the message intended to the merchant using the merchant's public key and a digital envelope for the message intended to the payment gateway (PG) using the payment gateway's public key (step 1). At the same time, a message digest is created for both messages using SHA-1 as a hashing algorithm (step 2). Both message digests are concatenated (step 3). A message digest of the concatenated message digest is generated using SHA-1 (step 4) and is encrypted using RSA with the e-wallet private key (step 5). This is the double signature for the message. Each of the message digests generated in step 2 are encrypted using RSA with the e-wallet's private key (step 6). This creates a digital signature (see Chapter 5) for each of the messages. The doubly signed message is then composed of the concatenation of the envelope for message 1, the signature for message 1, the envelope for message 2, the signature for message 2, and the double signature.

When the merchant receives the doubly signed message, it cannot open the digital envelope addressed to the payment gateway (message 2 in Fig. 6.4). It can however open the digital envelope for the message addressed to the merchant (message 1) and verify the signatures as shown in Fig. 6.5. In step 1, the merchant opens the envelope for the message addressed to it using RSA and the merchant's private key. This recovers the original message. Using SHA-1, a digest of this message is created (step 2). The message digest for message 2 is recovered by using RSA and the e-wallet's public key (step 3). Both message digests are then concatenated and a digest of the concatenated digest is generated using SHA-1 (step 4). In step 5, the double signature is decrypted using RSA and the e-wallet's public key. The result of this operation should be identical to the digest of the concatenated message digests if i) the doubly signed message came from the customer's e-wallet, ii) message 1 was addressed to the merchant and signed by the customer, and iii) message 2 was signed by the customer.

Double signing (see Fig. 6.4) involves the following cryptographic operations: two create digital envelope operations (each requires one DES operation and one RSA public key operation); three SHA-1 operations; and three RSA private key operations. Processing a doubly signed message (see Fig. 6.5) requires one open envelope operation (one DES and one RSA private key operation), two SHA-1 operations, and two RSA public key operations.

6.3.1.3. Simple Encapsulation with Signature and Baggage

There are some instances in SET where additional levels of security and protection are needed when sending messages. These messages carry an extra piece of information, called a baggage, that may be used in a reply message as will become clear when we describe the message flows in Section 6.3.2. A baggage is a mechanism by which encrypted data is appended to a message in such a way that the message and baggage are linked to one another [5].

Figure 6.6 describes how a message and its baggage are signed and encapsulated. We will refer to this process as EncB. A digest of the baggage is created using SHA-1 (step 1). The original message and the digest of the baggage are concatenated (step 2). The result of this step is signed with the sender's private key (step 3). The results of steps 2 and 3 are concatenated (step 4). A digital envelope for the concatenation obtained in step 4 is created (step 5). Finally, the result of step 5 is concatenated with the baggage (step 6) resulting in an encapsulated signed message with baggage.

The receiver of an EncB message will be able to open the envelope with its private key and verify the signature of step 4 using the sender's public key. Once the envelope is opened, the receiver can retrieve the digest of the baggage and regenerate it from the baggage to further verify the integrity of the baggage.

Generating an EncB message requires one SHA-1 operation, one sign operation (one private RSA and one SHA-1 operation), and one create envelope operation (one public RSA and and one DES operation). Receiving an EncB message requires one open envelope operation (one private RSA and one DES operation), one signature verification (one public RSA and one SHA-1 operation), and an additional SHA-1 operation for checking the integrity of the baggage.

6.3.2. SET Message Flow

SET is only invoked when the customer is ready to make a payment. At this point, the customer has already sent an order to the e-business site and is probably looking at a screen that describes the order with all the items to be purchased as well as the total price to be paid. The customer then selects the credit card to be used and SET starts its operation.

With the help of the CSID of Fig. 6.7, we describe next the flow of messages between the entities involved in a a SET payment transaction. We use EW, M, and PG to denote the customer's e-wallet, the merchant's POS software, and the payment gateway, respectively.

We concentrate on the payment and authorization transactions only since capture processing can be carried out out-of-band in SET and because SET servers may be dedicated to authorization only; capture and settlement may be highly batched reducing the transaction volume significantly [5].