[Cryptography] cost-watch - the cost of the Target breach

Anne & Lynn Wheeler lynn at garlic.com
Sun Dec 7 12:46:04 EST 2014


On 12/07/14 07:20, Jerry Leichter wrote:
> And how many Web-based systems continue to be fielded today with security enforcement in the browser or other client?

long ago and far away, we were brought in as consultants to small
client/server startup that wanted to do payment transactions on their
server, they had also invented this technology called "SSL" that they
wanted to use, the result is now frequently called "electronic commerce".

Part of the work involved a payment gateway ... sits on the internet
and handles backend transactions between webservers and the payment networks.
We had responsibility for security between webservers and the payment networks
but could only make recommendations for the browser/webserver part. As far as
I know, known of the payment gateways have ever been compromised ... but almost
immediately security recommendations on the browser/webserver were violated, resulting
in many of the exploits that continue to this day.

somewhat having done "electronic commerce", in the mid-90s were were invited
into the x9a10 financial transaction working group that had been given the
requirement to preserve the integrity of the financial infrastructure for
*ALL* retail payments. (this was about the same time the card associations
were doing two different specification efforts, one in europe involving chip that was POS
only and a totally different effort that was internet only).

The resulting working group transaction standard addressed *ALL* retail payments
(not just *POS* or not just *internet*, but *ALL* retail payments).

One of the issues is the current paradigm allows information from previous
transactions to be used in a kind of "replay" attack and/or creating counterfeit
authentication. The transaction standard didn't do anything to address
skimming, evesdropping, and/or data breaches ... however it slightly tweaked
the current paradigm and eliminated being able to use previous transaction
information for doing fraudulent transactions. Now the earlier work we did
for electronic commerce involves using "SSL" to hide transaction information,
the x9a10 transaction doesn't require hiding the transaction information to
preserve the integrity of the financial infrastructure for *ALL* retail
payments ... and so eliminates that use for "SSL".

We've used a couple metaphors to describe the current paradigm:

dual-use ... since information from previous transactions can be used
for fraudulent transactions, that information has to be kept totally
confidential and never divulged. at the same time the same information
is required in dozens of business processes at millions of locations
around the world. we've periodically commented that even if the planet
was buried under miles of information hiding encryption, it still
wouldn't stop leakage

security proportional to risk ... the value of the transaction
information to the merchants is the profit on the transactions, which
can be a couple dollars (and a couple cents for the transaction
processor) ... the value of the information to the crooks is the
account balance and/or credit limit ... as a result the crooks can
afford to outspend the defenders by a factor of 100 times.

In support of the standards effort, I also designed a chip ...
at this conference
http://csrc.nist.gov/nissc/1998/index.html

I was on stage in standing room only ballroom with panel
of CTOs from various security institutions and semi-facetiously
said that I was taking a $500 mil-spec part and aggressively cost
reducing by 2-3 orders of magnitude while making it more secure.
(cost way less and way more secure than any chip being worked on
by financial infrastructures, then or now).

This chip was demo'ed in a number of booths at the 1999
BAI world-wide retail banking show in Miami.

The downside of the chip & standard was that it drastically
reduced the infrastructure for doing secure payments and also
eliminated the need for having the card associations in the
loop for payment transactions ... which enormously upsets
the status quo.

For the large US pilot deployment early part of the century
... I had advised the people doing it about the exploits
and vulnerabilities ... but for what-ever reason, they went
ahead and did it anyway ... I guess having to actually
experience the problems (not being told about them wasn't
good enough).

-- 
virtualization experience starting Jan1968, online at home since Mar1970


More information about the cryptography mailing list