[FYI] Did Encryption Empower These Terrorists?

[lynn.wheeler at firstdata.com]

misc discussion regarding SET NEVER intended to hide PAN from the merchant
(in part because, a merchant gets dispute notification directly from the
consumer's bank with the only reference being the PAN, the date, and the
amount).

http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards

note that the issuing (consumer) bank and the acquiring (merchant) bank
don't necessarily have the same interests. in the standard SET scenerio,
the only thing that the issuing bank sees is a flag in an 8583 message
saying that some internet gateway someplace may have correctly
authenticated a digital signature on a SET transaction. there is no
end-to-end security and/or authentication. about a year into some of the
SET deployments, somebody from VISA gave a presentation at an ISO meeting
in europe on the number of 8583 transactions arriving at an issuing bank
with the SET signature verified flag turned on and they could proove that
both the merchant, any gateway, and the acquiring bank had absolutely zero
SET and/or other digital signature technology (the flag was just being
set).

Part of the issue was that the size bloat of a SET transaction compared to
a normal 8583 transactions could approach two orders of magnitude .... in
part resulting in the gateway performing the signature authentication and
then throwing away everything and just setting a flag in the 8583 message
claiming that the authentication was performed.

Part of the x9.59 standard design point was to be light-weight enuf so that
there could be real end-to-end security with real end-to-end authentication
that actual flows with the real transaction (that was also in part derived
from the requirement that x9.59 standard could be applied to all
account-based transactions, regardless of internet, point-of-sale, debit,
credit, existing infrastructure, new infrastructure, etc).

In the x9.59 standards scenerio, the merchant doesn't even need SSL
technology (at least not for integrity/fraud reasons, some people may still
prefer SSL ... but it would be a privacy issue, not a fraud & integrity
issue). The merchant gets a couple more data elements which must be mapped
into X9.15 (or the 8583 subset equivalent) for sending directly to their
acquiring processor. The processing would be exactly the same for an
internet web site as for a point-of-sale terminal. The processing would
also be the same whether it was debit or credit (except for possibly
X9.15/8583-subset protocol differences between their credit processor and
their debit processor ... if any).

misc. past discussion regarding real end-to-end security
ttp://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy
are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#keylength On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl3 On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures,
technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk
Management and Information Security
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments
on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#privacy misc. privacy
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from
usenet group
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information
... summary
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment
standard issue
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark
Debate
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on
DSTU X9.59
http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re:
Williamette trace cache (Re: First view of Willamette))
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#23 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of
acceptance of key binding ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates

discussions regarding SSL domain name certificate infrastructure:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

general discussions regarding x9.59, privacy, authentication
http://www.garlic.com/~lynn/subtopic.html#privacy

general discussions regarding client authentication
http://www.garlic.com/~lynn/subtopic.html#radius

general discussion regarding fraud & exploits
http://www.garlic.com/~lynn/subtopic.html#fraud





Enzo Michelangeli <em at who.net> on 9/25/2001 8:56 PM wrote:

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