[FYI] Did Encryption Empower These Terrorists?

[Enzo Michelangeli]

On Mon, 24 Sep 2001 lynn.wheeler at firstdata.com wrote:

> If it was so easy ... it wouldn't be a problem. An objective of the
> original e-commerce deployments was that the account number file not be
> co-located on the webserver. Since a large number of subsequent deployments
> have co-located on the webserver or on some equally accessable location
> would tend to indicate that it isn't as easy as it might first appear.

Many merchants need a unique identifier for the buyer, and their
traditional processes often use the PAN (card number, for credit
transactions). According to what I heard, at one point the original specs
of SET were altered in order to accomodate, as an option, the visibility
of the PAN to the merchant, thereby giving up the other advantage of SET
besides cardholder's authentication (i.e., protection of the card number
from eyes different from cardholder's or banking system's).

As Ben noted, it is not difficult to combine the following two
requirements:

a) protection of PAN from any party different from cardholder or acquiring
bank 
b) no special software installed on cardholder's PC besides an SSL-capable
browser

For example, let's suppose that the acquirer run a stateful trusted and
well protected machine (gateway), and the merchant a simple secure web
server whose CGI scripts can act as SSL clients. The transaction protocol
could work this way:

1. At check-out time, the merchant server connects to the gateway with
SSL, authenticates itself (even simple username/password is OK) and passes
to the gateway the details of the transaction, minus the card number (that
it doesn't have).

2. The gateway creates a record in an internal database, stores the data
there, and returns a unique and unguessable handle (a random-looking
string with a length of a few tens of characters).

3. The merchant server redirects the buyer's browser to the gateway,
passing it the handle (e.g., appended to the URL as "get" parameter). Also
this HTTP session is over SSL.

4. The gateway prompts the buyer for the card number and other personal
details, in a form also containing the handle as hidden field.

5. The buyer enters the requested data, and submits. The gateway, through
the handle, retrieves the transaction record, combines its data with the
card number and other data entered by the buyer, processes the
authorization request through the card associations' network, gets back
the auth code, stores it in the database transaction record, and redirects
the browser to a URL on the merchant server, again appending the record's
handle as parameter.

6. The merchant server gets the handle, opens another SSL connection (also
authenticated) to a URL on the gateway also passing it the handle, and
gets back a receipt confirming the authorization. It then displays a
"Thank you" page to the buyer's browser, and communicates all the data to
the division in charge for the order's fulfillment. The End.

And lo: no fancy crypto (apart from SSL), which also helps performances;
no client certificates; and no bulky wallets that someone gotta pay for
(and have to be installed, and often crash Windows ;-) ). Also the
merchant server just needs very simple and inexpensive SSL client
software: cURL, CryptSSL+LWP, JSSE, whatever.

The only piece still missing here is the cardholder authentication: the
gateway is managed by the acquiring bank, but only the issuing bank has
business relationships with the cardholder, and is in the position of
putting in place authentication mechanisms. That's where 3D Secure may
help.

Cheers --

Enzo
 




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com