2008: The year of hack the vote?

Anne & Lynn Wheeler lynn at garlic.com
Sat Dec 29 15:04:37 EST 2007


Jack Lloyd wrote:
 > The only reason this 'must' be true is because an anonymous and secure
 > payment system is a terror which thankfully our federal governments
 > and central banks protect us from. While Amazon and others obviously
 > like being able to build customer profiles of everyone, I don't doubt
 > that they would be perfectly willing to accept an anonymous payment as
 > long as the money is good (and, of course, that the transaction costs
 > are no more than a credit card and/or the order flow is sufficient
 > that it is worth building support for it).

in the mid-90s, the x9a10 financial standard working group had
been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments ... which resulted
in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

in the same timeframe, the EU (in conjunction with eu-dpd)
made statements that electronic payments at point-of-sale
should be as anonymous as cash.

this was interpreted as meaning that names should be
removed from payment cards (plastic and magstripe).
the contention was that (because of poor authentication)
retail outlets could cross-check names on the cards against
some other form of "ID". the implication that removing
names might help promote other integrity measures.

in the x9.59 standard, we claimed that the improved
integrity allowed meeting the EU-DPD objectives.
We also claimed that x9.59 was privacy agnostic
i.e. it allowed for privacy. The "ALL" requirement
given to the x9a10 financial standard working
group met internet, face-to-face, point-of-sale,
electronic commerce. It also met debit, credit,
ACH, as well as stored-value cards ... aka the
same X9.59 was applicable to *ALL*. In the debit/credit
scenario some countries have "know your customer"
mandates associating account numbers with individuals
... which we claimed was outside the x9.59 standard.
Supposedly with appropriate regulated access to
information, govs can obtain information associating
account activity with individuals.

However, the very same x9.59 standard also works
with stored-value/gift cards ... which doesn't have
similar "know your customer" mandates.
http://www.garlic.com/~lynn/subpubkey.html#privacy

And in fact, most stored-value/gift cards share a lot
of the same exact processing with the debit/credit
processing ... the addition of x9.59 could provide for
the exactly same level of integrity thruout debit,
credit, and stored-value/gift processing.

for other drift, in the mid-90s ... there were some
of the other payment efforts specifically for the
internet which had so much payload and processing bloat
that it made it impractical past the toy demo stage
http://www.garlic.com/~lynn/subpubkey.html#bloat

related recent post on infrastructure provisioning and bloat of
toy demos:
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed

about the same time, there were completely different
chip card oriented efforts for point-of-sale. one of the
scenarios of some of the chipcard pilot projects in
the late 90s and early part of this century was that
they managed to increase the vulnerabilities
(magstripe vis-a-vis chipcards)
http://www.garlic.com/~lynn/subintegrity.html#yescard

the common excuse from the period, was that chips
cost so much that it wasn't possible to afford integrity
that actually improved over magstripe. The other
possible observation was that some of the chipcard
efforts were so chip myopic ... that they couldn't
realize that they were actually making it worse
for the overall infrastructure.

A big issue for merchants isn't anonymous payments
... it is cost of doing business. This has been in
the news quite a bit recently in the form of
interchange fees ... recent posts
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed

the other area is in the liability related to breaches
(and/or the costs of countermeasures to breaches).

i've mentioned before that we had been called in
to consult with small client/server startup that wanted
to do payments on their server. They had this technology
they called SSL and it is frequently now referred to
as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

and then we got dragged into involved with the x9a10
financial standard. as part of attempting to meet the
requirement to preserve the integrity of the financial
infrastructure for all retail payments ... we did some detailed
threat and vulnerability analysis. A big item that came out
were infrastructure vulnerabilities ... breaches, skimming,
harvesting, evesdropping, ... a whole slew of things.

we identified that much of the vulnerability could be
attributed to the account number and transaction
information has diametrically opposing requirements
... 1) it has to be readily available for large number of
different business processes and 2) since the crooks
can use the same information for various kinds of
essentially replay attacks ... the information has to
be kept confidential and never divulged.

we've also talked about this as the dual-use nature
of the information ... and that even if the planet
was buried under miles of (information hiding) encryption,
it still wouldn't be able to prevent information leakage.

So another part of the x9.59 financial standard
was to eliminate the dual-use nature of the information,
making it useless for crooks ... aka x9.59 didn't do
anything to prevent information leakage ... it just eliminated
the information leakage as a vulnerability. a related
recent post
http://www.garlic.com/~lynn/2007v.html#74 folklore indeed

from this stand-point ... the x9.59 financial standard addresses
both drastically reducing fraud in the infrastructure as well
as drastically reducing the infrastructure costs for fraud
countermeasures.




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



More information about the cryptography mailing list