[FYI] Did Encryption Empower These Terrorists?

[Enzo Michelangeli]

----- Original Message -----
From: "Ray Dillinger" <bear at sonic.net>
To: "Enzo Michelangeli" <em at who.net>
Cc: <lynn.wheeler at firstdata.com>; "Ben Laurie" <ben at algroup.co.uk>;
<cryptography at wasabisystems.com>; "Hadmut Danisch" <hadmut at danisch.de>;
<jim_windle at eudoramail.com>
Sent: Thursday, September 27, 2001 12:06 AM
Subject: Re: [FYI] Did Encryption Empower These Terrorists?


[...]
> >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.

But I said that the gateway is operated by the acquirer (the merchant's
bank), not by the issuer. The issuer only becomes important for cardholder's
authentication, a part that I intentionally left out because it can only be
addressed by the card associations (Visa, Mastercard etc.) who are in the
middle between acquirers and issuers. In fact, 3D Secure does it by putting
on the site that collects the card number (here the gateway, or, in Visa's
original scheme, the merchant site) a plugin that looks up the first six
digits of the PAN in a Visa-supplied directory, retrieves the issuer's
identity and redirects the browser to a URL on an issuer-managed server
responsible for the verification of the cardholder's credentials.

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

That's 3D Secure's job (see above). Once the issuer has authenticated the
cardholder, neither merchant nor acquirer can be held responsible for
chargebacks: the issuer pays, and then deals with its cardholder as it deems
fit. (If you want my opinion, the very reason why Visa developed 3D Secure
is that they are sick of being involved in the dispute resolution process).

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

I know, but that was not the goal of the protocol I outlined in my post. I
just wanted to show that SSL alone can be sufficient as cryptographic tool
to restrict the visibility of the card to the banking system (acquirer /
card associations / issuer), excluding the merchant.

Enzo





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