Chapter 12

SET for E-Commerce Transactions

The Secure Electronic Transaction (SET) is a protocol designed for protecting credit card transactions over the Internet. It is an industry-backed standard that was formed by MasterCard and Visa (acting as the governing body) in February 1996. To promote the SET standard throughout the payments community, advice and assistance for its development have been provided by IBM, GTE, Microsoft, Netscape, RSA, SAIC, Terisa, and Verisign.

SET relies on cryptography and X.509 v3 digital certificates to ensure message confidentiality and security. SET is the only Internet transaction protocol to provide security through authentication. It combats the risk of transaction information being altered in transit by keeping information securely encrypted at all times and by using digital certificates to verify the identity of those accessing payment details. The specifications of and ways to facilitate secure payment card transactions on the Internet are fully explored in this chapter.

12.1 Business Requirements for SET

This section describes the major business requirements for credit card transactions by means of secure payment processing over the Internet. They are listed below:

Figure 12.1 TCP/IP model and Internet Protocol suite. OSI, Open Systems Interconnect (seven layers); TCP/IP, Transmission Control Protocol/Internet Protocol (four layers).

12.2 SET System Participants

The participants in the SET system interactions are described in this section. A discrepancy is found between an SET transaction and a retail or mail order transaction: in a face-to-face retail transaction, electronic processing begins with the merchant or the acquirer, but in an SET transaction, the electronic processing begins with the cardholder.

• Cardholder. In the electronic commerce environment, consumers or corporate purchasers interact with merchants on personal computers over the Internet. A cardholder is an authorized holder of a payment card that has been issued by an issuer. In the cardholder's interactions, SET ensures that the payment card account information remains confidential.
• Issuer. An issuer is a financial institution (a bank) that establishes an account for a cardholder and issues the payment card. The issuer guarantees payment for authorized transactions using the payment card.
• Merchant. A merchant is a person or an organization that offers goods or services for sale to the cardholder. Typically, these goods or services are offered via a Web site or by e-mail. With SET, the merchant can offer its cardholders secure electronic interactions. A merchant that accepts payment cards must have a relationship with an acquirer (a financial institution).
• Acquirer. An acquirer is the financial institution that establishes an account with a merchant and processes payment card authorization and payments. The acquirer provides authentication 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 transfer of payments to the merchant's account. Subsequently, the acquirer is reimbursed by the issuer over some sort of payment network for electronic funds transfer (EFT).
• Payment gateway. A payment gateway acts as the interface between a merchant and the acquirer. It carries out payment authorization services for many card brands and performs clearing services and data capture. A payment gateway is a device operated by the acquirer or a designated third party that processes merchant payment messages (PMs), including payment instructions from cardholders. The payment gateway functions as follows: it decrypts the encoded message, authenticates all participants in atransaction, and reformats the SET message into a format compliant with the merchant's point of sale system. Note that issuers and acquirers sometimes choose to assign the processing of payment card transactions to third-party processors.
• Certification Authority. A CA is an entity that is trusted to issue X.509 v3 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. The primary functions of the CA are to receive registration requests, process and approve/decline requests, and issue certificates. A financial institution may receive, process, and approve certificate requests for its cardholders or merchants and forward the information to the appropriate payment card brand(s) to issue the certificates. An independent Registration Authority (RA) that processes payment card certificate requests and forwards them to the appropriate issuer or acquirer for processing. The financial institution (issuer or acquirer) forwards approved requests to the payment card brand to issue the certificates.

Figure 12.2 illustrates the SET hierarchy which reflects the relationships between the participants in the SET system, described in the preceding paragraphs. In the SET environment, there exists a hierarchy of CAs. The SET protocol specifies a method of trust chaining for entity authentication. This trust chain method entails the exchange of digital certificates and verification of the public keys by validating the digital signatures of the issuing CA. As indicated in Figure 12.2, this trust chain method continues all the way up to the root CA at the top of the hierarchy.

Figure 12.2 The SET transaction hierarchy indicating the relationships between the participants.

12.3 Cryptographic Operation Principles

SET is the Internet transaction protocol providing security by ensuring confidentiality, data integrity, authentication of each party, and validation of the participant's identity. To meet these requirements, SET incorporates the following cryptographic principles:

• Confidentiality. This is ensured by the use of message encryption. SET relies on encryption to ensure message confidentiality. In SET, message data is encrypted with a random symmetric key which is further encrypted using the recipient's public key. The encrypted message along with this digital envelope is sent to the recipient. The recipient decrypts the digital envelope with a private key and then uses the symmetric key in order to recover the original message.

• Integrity. This is ensured by the use of a digital signature. Using the public/private-key pair, data encrypted with either key can be decrypted with the other. This allows the sender to encrypt a message using the sender's private key. Any recipient can determine that the message came from the sender by decrypting the message using the sender's public key. With SET, the merchant can be assured that the order it received is what the cardholder entered. SET guarantees that the order information is not altered in transit. Note that the roles of the public and private keys are reversed in the digital signature process where the private key is used to encrypt for signature and the public key is used to decrypt for verification of signature.
• Authentication. This is also ensured by means of a digital signature, but it is further strengthened by the use of a CA. When two parties conduct business transactions, each party wants to be sure that the other is authenticated. Before a user B accepts a message with a digital signature from a user A, B wants to be sure that the public key belongs to A. One way to secure delivery of the key is to utilize a CA to authenticate that the public key belongs to A. A CA is a trusted third party that issues digital certificates. Before it authenticates A's claims, a CA could supply a certificate that offers a high assurance of personal identity. This CA may require A to confirm his or her identity prior to issuing a certificate. Once A has provided proof of his or her identity, the CA creates a certificate containing A's name and public key. This certificate is digitally signed by the CA. It contains the CA's identification information, as well as a copy of the CA's public key. To get the most benefit, the public key of the CA should be known to as many people as possible. Thus, by trusting a single key, an entire hierarchy can be established in which one can have a high degree of trust.

The SET protocol utilizes cryptography to provide confidentiality of information, ensure payment integrity, and ensure identity authentication. For authentication purposes, cardholders, merchants, and acquirers (financial institutions) will be issued with digital certificates by their sponsoring CAs. The certificates are digital documents attesting to the binding of a public key to an individual user. They allow verification of the claim that a given public key does indeed belong to a given individual user.

12.4 Dual Signature and Signature Verification

SET introduced a new concept of digital signature called dual signatures (DSs). A DS is generated by creating the message digest of two messages: order digest and payment digest. Referring to Figure 12.3, the customer takes the hash codes (message digests) of both the order message (OM) and PM by using the SHA-1 algorithm. These two hashes, and , are then concatenated and the hash code h of the result is taken. Finally, the customer encrypts (via RSA) the final hash code with his or her private key, , creating the DS. Computation of the DS is shown as follows:

Figure 12.3 Dual signature and order/payment message authentication.

Example 12.1 Computation of dual signature:

Assume that the OM and the PM are given, respectively, as follows:

Since SHA-1 sequentially processes blocks of 512 bits, that is, sixteen 32-bit words, the message padding must attach to the message block to ensure that a final padded message becomes a multiple of 512 bits. The 160-bit message digest can be computed from hashing the 512-bit padded message by the use of SHA-1. The padded OM and PM messages are, respectively,

Referring to Figure 12.4, and each are obtained as follows:

Figure 12.4 Computational analysis for the dual signature relating to Example 12.1.

Concatenating these two hash codes and appending pads yields ():

Taking the hash (SHA-1) of this concatenated message digests results in:

Transforming this resulting hash into decimal numbers yields:

The concatenated two hashes become the input to the SHA-1 hash function. Thus, the resulting hash code h is RSA encrypted with the customer's private key in order to obtain the DS.

To generate the public and private keys, choose two random primes, p and q, and compute the product . For a short example demonstration, choose and ; then and . If the merchant has the customer's public key that is taken from the customer's certificate then the customer's private key is computed using the extended Euclidean algorithm such that:

In the digital signature process, the roles of the public and private keys are reversed, where the private key is used to encrypt (sign) and the public key is used to decrypt for verification of the signature.

To encrypt the final hash value h with , first divide h into numerical blocks and encrypt block after block such that:

This is the DS formula. Now, the DS represented in RSA-encrypted decimals can be computed as:

• Merchant's signature verification. Since the merchant has the customer's public key , the merchant can decrypt the DS by making use of as follows:

  

  Now assume that the merchant is in possession of the OM and the message digest for the PM . Then, the merchant can compute the following quantity:

  

  Since is proved, the merchant has received OM and verified the signature.
• Bank's signature verification. Similarly, if the bank is in possession of DS, PM, the message digest for OM, and the customer's public key , then it can compute the following quantity:

  

  Since these two quantities are equal, , then the bank has verified the signature upon received PM.

Thus, it is verified completely that the customer has linked the OM and the PM and can prove the linkage.

---

12.5 Authentication and Message Integrity

When user A wishes to sign the plaintext information and send it in an encrypted message (ciphertext) to user B, the entire encryption process is as configured in Figure 12.5. The encryption/decryption processes for message integrity consist of the following steps.

Figure 12.5 Encryption/Decryption overview for message integrity.

Example 12.2 Message Integrity Check:

User A.

Assume that the plaintext P is given as:

The 160-bit message digest is computed from hashing the 512-bit padded plaintext by the use of SHA-1 as follows:

User A picks two random primes and . Compute the product and . Suppose the A's public key is . Then, A's private key is computed using the extended Euclidean algorithm as:

A's private key is used to sign (encrypt) the 160-bit message digest h to produce the digital signature :

Now, the message contents consist of the plaintext P, signature , and A's public key as follows:

A generates a random symmetric key K:

Using this symmetric key, A encrypts the concatenated message contents as:

and then sends them to user B.

User B.

User B chooses two random primes and , which give and , respectively.

Assume that B's public key, , is obtained from B's certificate. The symmetric key K is encrypted with B's public key to generate the digital envelope, which is computed as:

B's private key is computed using the extended Euclidean algorithm as:

The symmetric key K is recovered by decrypting the digital envelope with B's private key .

Using the recovered symmetric key, the encrypted message contents are decrypted to obtain the message contents (). The message digest is computed by decrypting the recovered signature with A's public key, and it results in:

Next, the message digest is obtained using the SHA-1 hash function of the recovered plaintext. It results in the following message digest:

Thus, the MIC is completely accomplished because these two message digests are identical. Figure 12.6 gives full details of the MIC relating to this example.

Figure 12.6 Message integrity check relating to Example 12.2.

---

12.6 Payment Processing

This section describes several transaction protocols needed to securely conduct payment processing by utilizing the cryptographic concepts introduced in Sections 12.5. The best detailed overview of SET specification appears in Book 1: Business Description issued in May 1997 by MasterCard and Visa. The following descriptions of secure payment processing are largely based on this book of the SET specification.

Figure 12.7 shows an overview of secure payment processing and it is worth looking at the outlines of several transaction protocols before reading the following detailed discussion.

Figure 12.7 Overall picture of payment processing.

12.6.1 Cardholder Registration

The cardholder must register with a CA before sending SET messages to the merchant. The cardholder needs a public/private-key pair for use with SET. The scenario of cardholder registration is described in the following.

1. Registration request/response processes

The registration process can be started when the cardholder requests a copy of the CA certificate. When the CA receives the request, it transmits its certificate to the cardholder. The cardholder verifies the CA certificate by traversing the trust chain to the root key. The cardholder holds the CA certificate to use later during the registration process.

Figure 12.8 Registration request/response processes.

• The cardholder sends the initiate request to the CA.
• Once the initiate request is received from the cardholder, the CA generates the response and digitally signs it by generating a message digest of the response and encrypting it with the CA's private key.
• The CA sends the initiate response along with the CA certificate to the cardholder.
• The cardholder receives the initiate response and verifies the CA certificate by traversing the trust chain to the root key.
• The cardholder verifies the CA certificate by decrypting it with the CA's public key and comparing the result with a newly generated message digest of the initiate response.

It is worth depicting this registration process as shown in Figure 12.8.

2. Registration form process

Figure 12.9 Registration form process.

• The cardholder generates the registration form request.
• The cardholder encrypts the SET message with a random symmetric key (No. 1). The DES key, along with the cardholder's account number, is then encrypted with the CA's public key.
• The cardholder transmits the encrypted registration form request to the CA.
• The CA decrypts the symmetric DES key (No. 1) and cardholder's account number with the CA's private key. The CA then decrypts the registration form request using the symmetric DES key (No. 1).
• The CA determines the appropriate registration form and digitally signs it by generating a message digest of the registration form and encrypting it with the CA's private key.
• The CA sends the registration form and the CA certificate to the cardholder.
• The cardholder receives the registration form and verifies the CA certificate by traversing the trust chain to the root key.
• The cardholder verifies the CA's signature by decrypting it with the CA's public key and comparing the result with a newly generated message digest of the registration form. The cardholder then completes the registration form.

The registration form process is depicted as shown Figure 12.9.

3. Certificate request/response processes

• The cardholder generates the certificate request, including the information entered into the registration form.
• The cardholder creates a message with request, the cardholder's public key and a newly generated symmetric key (No. 2), and digitally signs it by generating a message digest of the cardholder's private key.
• The cardholder encrypts the message with a randomly generated symmetric key (No. 3). This symmetric key, along with the cardholder's account information, is then encrypted with the CA's public key.
• The cardholder transmits the encrypted certificated request messages to the CA.
• The CA decrypts the No. 3 symmetric key and cardholder's account information with the CA's private key and then decrypts the certificate request using this symmetric key.
• The CA verifies the cardholder's signature by decrypting it with the cardholder's public key and comparing the result with a newly generated message digest of the certificate requested.
• The CA verifies the certificate request using the cardholder's account information and information from the registration form.
• Upon verification, the CA creates the cardholder certificate, digitally signing it with the CA's private key.
• The CA generates the certificate response and digitally signs it by generating a message digest of the response and encrypting it with the CA's private key.
• The CA encrypts the certificate response with the No. 2 symmetric key from the cardholder request.
• The CA transmits the certificate response to the cardholder.
• The cardholder verifies the certificate by traversing the trust chain to the root key.
• The cardholder decrypts the response using the symmetric key (No. 2) saved from the cardholder request process.
• The cardholder verifies the CA's signature by decrypting it with the CA's public key and comparing the result with a newly generated message digest of the response.
• The cardholder stores the certificate and information from the response for future e-commerce use.

12.6.2 Merchant Registration

Merchants must register with a CA before they can receive SET payment instructions from cardholders. In order to send SET messages to the CA, the merchant must have a copy of the CA's public key which is provided in the CA certificate. The merchant also needs the registration form from the acquirer. The merchant must identify the acquirer to the CA. The merchant registration process consists of five steps as follows: (i) The merchant requests the registration form; (ii) the CA processes this request and sends the registration form; (iii) the merchant requests certificates after receiving the registration certificates; (iv) the CA creates certificates; and (v) the merchant receives certificates.

The detailed steps for the merchant registration are described in what follows.

12.6.3 Purchase Request

The purchase request exchange should take place after the cardholder has completed browsing, selecting, and ordering. Before the end of this preliminary phase occurs, the merchant sends a completed order form to the cardholder (customer). In order to send SET messages to a merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The message from the cardholder indicates which payment card brand will be used for the transaction. The purchase request exchange consists of four messages: initiate request, initiate response, purchase request, and purchase response. The detailed discussions that follow describe each step fully.

12.6.4 Payment Authorization

During the processing of an order from a cardholder, the merchant authorizes the transaction. The authorization request and the cardholder payment instructions are then transmitted to the payment gateway.

12.6.5 Payment Capture

After completing the processing of an order from a cardholder, the merchant will request payment. The merchant generates and signs a capture request, which includes the final amount of the transaction, the transaction identifier from the OM, and other information about the transaction. A merchant's payment capture process will be described in detail in the following.

Figure 12.10 shows an overview of payment capture consisting of the merchant's capture request and the gateway's capture response.

Figure 12.10 Payment capture process.