[14119] in cryptography@c2.net mail archive
Re: Is cryptography where security took the wrong branch?
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Tue Sep 9 12:31:07 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 09 Sep 2003 09:50:47 -0600
To: "Joseph Ashwood" <ashwood@msn.com>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: <cryptography@metzdowd.com>
In-Reply-To: <017501c37664$1bb99460$6601a8c0@JOSEPHAS>
At 04:25 PM 9/8/2003 -0700, Joseph Ashwood wrote:
>Actually they do target very different aspects. SET, 3D-Secure, and any
>other similar have a different target then SSL. To understand this it is
>important to realize that instead of the usual view of two-party
>transactions, credit card transactions actually take 3 parties; Issuer,
>Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also
>be applied to the Seller-Issuer communication, but on a transaction basis it
>offers nothing for the Issuer-Buyer (the important one for minimizing costs
>for the Issuer).
actually, physical credit card ... is a number of pair-wise communications
.... card-holder to merchant terminal ... merchant terminal to merchant
acquirer, merchant acquirer to interchange, interchange to issuer (credit
card model is sometimes referred to as the 4-corner box .... with
interchange trying to be transparent in the acquirer to issuer communication).
original electronic commerce with the netscape commerce server ... had SSL
for the shopping experience ... with the credit card done at the end.
Depending on the mall version of the commerce server had dedicated leased
line directly to merchant acquirer. The wider userd commerce server had a
SSL connection from the commerce server to the payment gateway (which then
interfaced to the merchant acquirer) ... effectively emulating the real
world (two pair-wise communcations).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
In the real-world .... SSL use got cut-back to only handling the credit
card part of the transaction ... and not being used for the rest of the
shopping experience.
In any case, the SSL flows exactly emulate the physical world (effectively
the front side of the virtual POS running at the merchant website ... and
the backside of the virtual POS to the acquirer) . ... modulo previous
comment that the merchant transaction file in the physical world wasn't
accessable via the internet (even tho it directly doesn't show up in the
flows). The major exploits haven't been in the transaction flow part of the
operation .... but in the business mechanics .... the major exploits have
been harvesting the merchant transaction file. Neither SSL, nor SET have
counter-measure against the major exploit (harvesting the merchant
transaction file). Both SSL and SET hid the credit card number while in
transit.
SET had all this other certificates and PKI gorp ... that significantly
increased the crypto-related burden ( much more so than SSL). In theory,
SET had an opportunity for end-to-end authentication .... but even a single
certificate represented on the order of two-orders of magnitude bloat
increase for the payload in the standard payment network (aka a single PKI
certificate tends to be one hundred times larger than the typical, base
payment transaction). The SET burden was orders of magnitude worse than the
SSL burden. This, in part is what gave way to the SET payment gateway ....
all the PKI gorp would occur at the SET payment gateway ....then all SET
related information would be thown away, a standard 8583/x9.15 transaction
created .... with an additional flag indicating that digital signature
authentication had been correctly performed ...and off it goes.
One of the VISA business people later gave a presentation at an ISO meeting
about the number of 8583 transactions flowing thru the payment network with
the SET-authenticated flag set ....but they could prove that no PKI
technology was even remotely possible for the transaction .... aka a slight
issue of end-to-end security was violated. The important issue here was
that the vision for SET ... was that if SET-authenticated transaction were
involved ... the merchant eventually would be eligible for card-holder
present discount rates ... rather than MOTO discount rates (aka having SET
authentication was proposed as being as safe as a) card-holder present, b)
card-preset, and c) track 1&2 readable). It was therefor in the interest of
the merchant side of the business to tell the issuing side of the business
that transactions were SET authenticated and the mrechant could get a much
better discount rate).
The claim was that SET enormously increased the complexity, overhead, and
payload processing ... while having little practical impact on the major
vulnerabilities.
Out of all this ... the X9A10 standards working group was giving the
requirement to preserve the integrity of the financial infrastructure for
all retail payments. The result is X9.59 which addresses all the major
exploits at both POS as well as internet (and not just credit, but debit,
stored-value, ACH, etc ... as well).
http://www.garlic.com/~lynn/index.html#x959
One of the things addressed by X9.59 was not the elimination of the ability
to harvest the merchant transaction file ... but to make the account
numbers in the merchant transaction file useless for fraud. slightly
related discussion of the "security proportional to risk" and the
vulnerability represented by the merchant transaction file
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe??
... security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
misc. recent SET refs:
http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security
took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security
took the wrong branch?
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
