Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

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 at metzdowd.com