15.8 Secure Electronic Transaction – Introduction to Cryptography with Coding Theory, 3rd Edition

15.8 Secure Electronic Transaction

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 TransactionTM 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:

  • GSO = GoodsandServiceOrder, which consists of the cardholder’s and merchant’s names, the quantities of each item ordered, the prices, etc.

  • PI = PaymentInstructions, 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 EC, EM, and EB denote the (public) encryption functions for the Cardholder, the Merchant, and the Bank, and let DC, DM, and DB be the (private) decryption functions.

The Cardholder performs the following procedures:

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

  2. Calculates PIMD=H(EB(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=DC(POMD). This is the dual signature.

  5. Sends EM(GSO), DS, PIMD, and EB(PI) to the Merchant.

The Merchant then does the following:

  1. Calculates H(EM(GSO)) (which should equal GSOMD).

  2. Calculates H(PIMD||H(EM(GSO))) and EC(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 DM(EM(GSO)) to obtain GSO.

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

The Bank now performs the following:

  1. Computes H(EB(PI)) (which should equal PIMD).

  2. Concatenates H(EB(PI)) and GSOMD.

  3. Computes HH(EB(PI))||GSOMD and EC(DS). If they are equal, the Bank has verified the Cardholder’s signature.

  4. Computes DB(EB(PI)), obtaining the payment instructions PI.

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

The Merchant completes the procedure as follows:

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

The Merchant only sees the encrypted form EB(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.