[FYI] Did Encryption Empower These Terrorists?

[Ray Dillinger]

On Wed, 26 Sep 2001, Enzo Michelangeli wrote:

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

A few problems:  

1) in a typical credit card transaction, the seller neither knows, 
   nor cares, what bank issued the credit card.  Thus, connecting 
   to the correct gateway becomes a minor problem. 

2) No provision for dispute resolution.  What happens in a month 
   and a half when george gets his credit card bill back and says 
   "I've never been there and never done any business with this 
    person"?  The bank generates a chargeback and sends it to the 
    merchant who, in the absence of knowledge about the buyer's 
    identity, has no recourse.  George may or may not be the person 
    who made the transaction; but the merchant has no way to even 
    begin to try to find out. 


In general, "anonymity" and "credit" are immiscible.  If you want 
anonymous transactions, you absolutely cannot abide by the laws 
that require chargebacks, merchant and/or bank liability in case 
of fraud (instead of consumer liability), etc.  Compliance with 
those laws requires the merchant and banks to have the very 
information that anonymity prohibits them from having.

For anonymous transactions, you want something a whole lot more like 
cash, with the same failure modes (ie, no shift of liability in case 
of fraud) as cash.  That requires infrastructure which will not be 
allowed to be built.


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




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