Every time someone places an order in an electronic transaction over the Internet, large quantities of information are transmitted. These data must be protected from unwanted eavesdroppers in order to ensure the customer’s privacy and prevent credit fraud. Requirements for a good electronic commerce system include the following:

1. Authenticity: Participants in a transaction cannot be impersonated and signatures cannot be forged.

2. Integrity: Documents such as purchase orders and payment instructions cannot be altered.

3. Privacy: The details of a transaction should be kept secure.

4. Security: Sensitive account information such as credit card numbers must be protected.

All of these requirements should be satisfied, even over public communication channels such as the Internet.

In 1996, the credit card companies MasterCard and Visa called for the establishment of standards for electronic commerce. The result, whose development involved several companies, is called the SET, or Secure Electronic ${\mathrm{T}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}}^{\text{TM}}$ protocol. It starts with the existing credit card system and allows people to use it securely over open channels.

The SET protocol is fairly complex, involving, for example, the SSL protocol in order to certify that the cardholder and merchant are legitimate and also specifying how payment requests are to be made. In the following we’ll discuss one aspect of the whole protocol, namely the use of dual signatures.

There are several possible variations on the following. For example, in order to improve speed, a fast symmetric key system can be used in conjunction with the public key system. If there is a lot of information to be transmitted, a randomly chosen symmetric key plus the hash of the long message can be sent via the public key system, while the long message itself is sent via the faster symmetric system. However, we’ll restrict our attention to the simplest case where only public key methods are used.

Suppose Alice wants to buy a book entitled How to Use Other People’s Credit Card Numbers to Defraud Banks, which she has seen advertised on the Internet. For obvious reasons, she feels uneasy about sending the publisher her credit card information, and she certainly does not want the bank that issued her card to know what she is buying. A similar situation applies to many transactions. The bank does not need to know what the customer is ordering, and for security reasons the merchant should not know the card number. However, these two pieces of information need to be linked in some way. Otherwise the merchant could attach the payment information to another order. Dual signatures solve this problem.

The three participants in the following will be the Cardholder (namely, the purchaser), the Merchant, and the Bank (which authorizes the use of the credit card).

The Cardholder has two pieces of information:

• $\text{GSO }=\text{ Goods}\text{and}\text{Service}\text{Order}$, which consists of the cardholder’s and merchant’s names, the quantities of each item ordered, the prices, etc.

• $\text{PI }=\text{ Payment}\text{Instructions}$, including the merchant’s name, the credit card number, the total price, etc.

The system uses a public hash function; let’s call it $H$. Also, a public key cryptosystem such as RSA is used, and the Cardholder and the Bank have their own public and private keys. Let $E_C$, $E_M$, and $E_B$ denote the (public) encryption functions for the Cardholder, the Merchant, and the Bank, and let $D_C$, $D_M$, and $D_B$ be the (private) decryption functions.

The Cardholder performs the following procedures:

1. Calculates $GSOMD=H(E_M(GSO))$, which is the message digest, or hash, of an encryption of $GSO$.

2. Calculates $PIMD=H(E_B(PI))$, which is the message digest of an encryption of $PI$.

3. Concatenates $GSOMD$ and $PIMD$ to obtain $PIMD||GSOMD$, then computes the hash of the result to obtain the payment-order message digest $POMD=H(PIMD||GSOMD)$.

4. Signs $POMD$ by computing $DS=D_C(POMD)$. This is the dual signature.

5. Sends $E_M(GSO)$, $DS$, $PIMD$, and $E_B(PI)$ to the Merchant.

The Merchant then does the following:

1. Calculates $H(E_M(GSO))$ (which should equal GSOMD).

2. Calculates $H(PIMD||H(E_M(GSO)))$ and $E_C(DS)$. If they are equal, then the Merchant has verified the Cardholder’s signature and is therefore convinced that the order is from the Cardholder.

3. Computes $D_M(E_M(GSO))$ to obtain $GSO$.

4. Sends $GSOMD$, $E_B(PI)$, and $DS$ to the Bank.

The Bank now performs the following:

1. Computes $H(E_B(PI))$ (which should equal PIMD).

2. Concatenates $H(E_B(PI))$ and $GSOMD$.

3. Computes $H\left(H(E_B(PI))||GSOMD\right)$ and $E_C(DS)$. If they are equal, the Bank has verified the Cardholder’s signature.

4. Computes $D_B(E_B(PI))$, obtaining the payment instructions $PI$.

5. Returns an encrypted (with $E_M$) digitally signed authorization to the Merchant, guaranteeing payment.

The Merchant completes the procedure as follows:

1. Returns an encrypted (with $E_C$) digitally signed receipt to the Cardholder, indicating that the transaction has been completed.

The Merchant only sees the encrypted form $E_B(PI)$ of the payment instructions, and so does not see the credit card number. It would be infeasible for the Merchant or the Bank to modify any of the information regarding the order because the hash function is used to compute $DS$.

The Bank only sees the message digest of the Goods and Services Order, and so has no idea what is being ordered.

The requirements of integrity, privacy, and security are met by this procedure. In actual implementations, several more steps are required in order to protect authenticity. For example, it must be guaranteed that the public keys being used actually belong to the participants as claimed, not to impostors. Certificates from a trusted authority are used for this purpose.