The Security Model of the Proposed Model

Principles

The e-commerce model being developed in this document is founded on a number of important assumptions:

Merchants and their Commerce Service Providers (CSPs) should be able to implement the system using any technology or implementation language of their own choosing. Such choices must be independent of the infrastructure selected by the acquirer. To facilitate this flexibility, transactions will be conducted using documents conforming to specified XML Document Type Definitions (DTD) over HTTP or SSL-encoded HTTP (HTTPS). Apart from these requirements, all other aspects of the acquiring or merchant systems can be independent of choices made by the other.
When encryption of the transaction is required, the SSL certificate of the acquirer will provide such encryption. The merchant should not be required to purchase or implement a Key Management System (KMS) or purchase keys or certificates to encrypt transactions with the acquirer. This is a service provided to the merchant by the acquirer.
The time to market for a merchant to bring their e-commerce site on line should be as short, economical and simple as possible. Very few requirements for additional software or hardware should be placed upon their Internet hosting provider.

For these reasons, the merchant has three possible options for using this system:

The Buy Button option: The merchant can insert a URL containing the entire XML encoded document in a static page. The XML encoded document would contain at a minimum, the purchase description, merchant identification, and order amount. The consumer clicks on the link to the URL, be redirected to the acquirer’s SSL secured web-site, and enter their purchase card and order fulfillment information. The status of the order would normally be e-mailed back to the merchant. Optionally, the merchant can be informed of the status of an order by other means as well: an HTTP transaction, or a secure web site.
The Shopping Cart Order option: The merchant can create a dynamic URL based on some shopping cart application. This URL would include at a minimum, the purchase description, merchant identification, order number and order amount. The consumer clicks on the link to the URL, be redirected to the acquirer’s SSL secured web-site, and enter their purchase card and order fulfillment information. Again, the status of the order would normally be e-mailed back to the merchant. Optionally, the merchant can be informed of the status of an order by other means as well: an HTTP transaction, or a secure web site.
The Cardholder Order option: The merchant can create a dynamic web page based on some shopping cart application and then ask the consumer for purchase card and order information. The merchant web site would necessarily provide SSL encryption for the user to supply this information. The merchant can then open a connection to an SSL-encrypted URL of the acquiring system and transmit all information for purchase authorization. In this case, the status of the order would normally be sent back to the merchant in an HTTP response over the SSL encrypted session.

Possible Vulnerabilities

The following vulnerabilities illustrate the need for a Message Authentication Code (MAC) to be part of the transaction processing system. Both vulnerabilities assume that there is no MAC included in the transaction. As such, they are similar to some of the competitive offerings already in the marketplace.

A Possible Vulnerability: Store and Forward

By placing an order with a merchant using either a Buy Button or a Shopping Cart Order, Eve[1] can copy the URL with the XML encoded document and store it to her local machine. She edits the URL, changing the amount of the transaction to a lower amount, and then pastes this URL back into her web browser and executes the redirect. The transaction proceeds as normal. If the merchant does not validate the total amount of the transaction against the shopping cart or catalog value before fulfilling the order, Eve has effectively marked down the price of her purchase without the merchant’s knowledge.

If the merchant does notice that the amount is incorrect and does not fulfill the order, there are three possible scenarios:

The merchant discards the order and credits the original amount back to the cardholder, absorbing any transaction charges as the cost of doing business.
The merchant contacts the cardholder to request payment of the remainder of the amount owing. Eve would most likely claim that that was the price advertised on the web site and the merchant is obligated to fulfill the amount for this price. The merchant has no evidence to repudiate Eve’s claims.
The merchant reports Eve’s attempts as an attempted fraud to the authorities. Provided the fraudulent amount is large enough, and Eve resides under the same judicatory system as the merchant, this response might be reasonably successful. Eve, in her defense, could mount the same rebuttal as mentioned in the previous scenario. Alternatively, Eve could ensure that she does not live in the same province or country as the merchant, and that her fraudulent attempts are under the threshold amount to trigger a robust response from the authorities.

[1] When discussing security, it is common to describe various scenarios for analysis. In these scenarios, a malefactor trying to break into a system or compromise its security or integrity is often personified by the name "Eve." With apologies to all people named Eve who are honest, well-intentioned and honourable people, this paper will continue with this tradition.

Another Possible Vulnerability: Arbitrary Transactions against a Card

Using the third merchant option: a Cardholder Order, exploitation is trickier. Because the transaction information does not necessarily need to be included in a URL, it can be sent by the merchant server directly to the acquirer using an HTTP POST directive. Eve would not normally have access to the Store and Forward attack.

Even if she was able to discern the XML structure used for communication between the merchant and the acquirer, she is unable to get the merchant system to send the transaction to the acquirer on her behalf. She could open a connection to the acquirer herself, pretending to be the merchant and executing a transaction against a card. However, the response would come back to her and not the merchant in the HTTP response. The only effect would be that the acquiring system would process the transaction against her card to the merchant’s benefit but she would receive no order fulfillment.

With this knowledge, Eve has two possible exploits available: one a harassment exploit, and the other fraudulent.

In the harassment exploit, Eve acquires the card number of a victim that she does not like (perhaps an ex-spouse?) She then uses this number to charge up the card against a given merchant knowing that the cardholder will never get fulfillment of these orders. When statements are reconciled by the merchant, and/or the cardholder, the resulting chargebacks will cause a great deal of confusion.

In the fraudulent exploit, Eve uses her own card to attempt to generate a credit against it. The merchant will only discover the fraud when reconciling its deposit account statements, normally at the end of the month. Eve may have taken a cash advance against the credit balance in her account by then.

A Third Vulnerability: Order Authorization Spoofing

Eve used to work for a merchant that used a Buy Button option. She has copies of the e-mail sent by the acquiring system to the merchant informing the merchant that an order request was sent and approved and asking the merchant to fulfill the order.

Eve uses these e-mails as a template from which she constructs new messages. She spoofs these e-mails so that they appear to come from the acquiring system, authorizing the merchant to fulfill the specified orders yet no transaction has ever been received or processed by the acquiring system.

Possible Responses to these Vulnerabilities

IP Filtering

By verifying the source address of all connections to the acquirer, or the value of all HTTP-REFERER values, some risk can be mitigated. This mitigation is not complete because the HTTP-REFERER value could be spoofed and is not cleanly implemented by many browsers[1].

As well, the management of all merchant IP numbers greatly complicates system management for the acquirer. Whenever merchants migrate or expand to a new machine with a new IP number, they would have to inform the acquirer to enable this new IP number. When merchants abandon an old IP number or change upstream Internet providers, they would have to inform the acquirer to remove the old numbers and insert new ones. There are also many times when a firewall performs an unexpected NAT for a server, thus remapping the server’s own IP number to an unanticipated value.

Finally, IP Filtering offers the merchant no security that the e-mail confirming order authorization originated from the acquirer.

For all these reasons, IP filtering is not a sufficient mechanism for resolving the security issues posed by the scenarios above.

[1] Cf http://browserwatch.internet.com/news/story/news-980302-7.html [6]

Message Authentication Codes

The presented design uses two types of communications from the merchant to the acquiring system: encrypted and unencrypted. Encrypted communications are only required in the case of Cardholder Orders. The merchant transmits all other acquirer-directed transactions via the cardholder’s browser and does not require encryption by the merchant (although they will require encryption between the acquirer and the cardholder at some point).

However, all transactions from the merchant to the acquirer must ensure that the information was not altered between the time it was constructed by the merchant to the time it is received by the acquirer. Furthermore, should such an alteration be effected, the merchant must have the ability to repudiate the transaction and the acquirer must be able to confirm this repudiation. Similarly, in the case of e-mail notification from the acquirer to the merchant of order authorization, the acquirer must be able to repudiate the response and the merchant must be able to confirm this repudiation.

Because encryption is provided by the acquirer’s SSL certificate and SSL enabled web server, we do not need to concern ourselves with encryption of the transactions, but only with the authentication of the plaintext messages transmitted between merchants and acquirers. Such a scenario normally calls for a mechanism such as a Message Authentication Code (MAC).

Given a key and a plaintext message, MAC generation involves a one-way hashing algorithm so that a replicable bit sequence known as a MAC can be generated. However, given only the plaintext message, the recreation of the original key is very difficult[1], and given the plaintext message and the MAC, any change to the plaintext will invalidate the MAC.

In this way, the cardholder cannot effect a Store and Forward attack since any change to the amount of an order will invalidate the hash supplied by the merchant. Without the merchant’s key used to create the hash in the first place, the cardholder cannot replace the MAC with a new hash consistent with the altered value.

Neither can the cardholder effect an arbitrary transaction against a card since any card transaction requires a valid MAC generated by the merchant’s key.

Finally, if the MAC is also used to validate any e-mail from the acquirer to the merchant, the merchant can be assured that the acquirer sent the message. This is because any spoofing attempt would similarly require access to the merchant’s own key to authenticate the e-mail message.

[1] Alternatively, a number of possible keys can be generated but only one of which is the correct key. In this way, the MAC algorithm is not collision-free, but because our data is so tightly structured by the XML DTDs, the odds of a collision successfully matching the XML DTD are too remote to be considered.

Technical Specification of the MAC Generation

Because both the merchant and the acquiring systems will generate the MAC, it must be easy to implement:

either through the incorporation of existing libraries into the implementation environment,
or through a clear and efficient software algorithm that developers can write in the chosen implementation language. [1]

A number of MAC generation schemes exist. Due to the nature of this implementation, any MAC scheme must be at least resistant to known-text attacks.

The Cipher Block Chaining MAC algorithm has been shown to be secure when a secure underlying encryption algorithm is employed[2]. CBC-MAC is very secure on messages of a fixed length and very suitable for our purposes[3]. Because our messages use XML DTDs, they have a definite starting and ending point. A malefactor’s attempt to add additional content at the end of the message will fail to match the XML specifications of the transmission.

CBC-MAC uses bitwise XOR operations to construct a hashed value out of the plaintext input “P” broken into blocks “P₁”, “P₂”, … “P_n” each of size b bytes, the specified key “k” and an encryption algorithm E(k). However, the CBC-MAC algorithm is only valid for a specified length of message and only if those messages are a multiple of b bytes in length. This first restriction is to prevent malefactors from appending new information to the end of the message until the resulting forgery computes to the existing hash resulting in a “collision” for the same hash value. Because our message format is based on a DTD, this problem is removed; additional content at the end of the message would result in a poorly formed and thus invalid XML document. The second restriction is also easy to remove: If P_n < b, then pad P_n with zero bits so that P_n = b.

The algorithm if very easy to implement as visualized in the following schematic:

The CBC-MAC algorithm

[1] See Menezes, A., P. van Oorschot, & S. Vanstone. Handbook of Applied Cryptography. CRC Press. 1996. Chapter 9 for a more complete discussion of the mathematics behind this issue.

[2] Bellare, M., J. Kilian, & P. Rogaway. “The Security of the Cipher Block Chaining Message Authentication Code”. Journal of Computer and System Sciences. 61:3. December 2000. pp. 362-399.

[3] The only danger with CBC-MAC lies in the fact that the recipient necessarily holds the same key as the originator of the message. The recipient can use this key to decipher the hash in the reverse direction and generate a new message with the same hash value as the original message. Because a trusted relationship exists between the only two partners with a specific merchant key, and because of the way this design makes use of MACs and their corresponding messages, these concerns do not apply to this context.