Maybe It's Snake Oil All the Way Down
Anne & Lynn Wheeler
lynn at garlic.com
Wed Jun 4 12:12:04 EDT 2003
At 12:02 PM 6/4/2003 +0100, Dave Howe wrote:
>For that matter, our system here discards the CC after use (the pre-auth
>step with the merchant bank agent gives us back a "fulfillment handle" that
>can only be used to fulfill or cancel that individual transaction - but of
>course Amazon *want* to keep your CC details so they can do their
>fast-checkout patented thingy.
the ground rules given the x9a10 working group for the x9.59 standard was
to preserve the integrity of the financial infrastructure for all (credit,
debit, stored-value, POS, internet, non-internet, aka ALL) electronic
retail payments. it was one of the things that led us down the path of
certless operation. We had previously done the work on the original payment
gateway and had to perform various kinds of due diligence on all the major
CA vendors .... which started to dawn on us that stale, static certificates
were actually redundant and superfluous in the financial business process.
http://www.garlic.com/~lynn/aadsm5.html#asrn2
http://www.garlic.com/~lynn/aadsm5.html#asrn3
sort of the clinker was starting to do operational and performance profile
on any of the existing payment networks .... and it was evident that there
was a huge mismatch between the existing payment transaction payload size
and any of the commonly used certificates (even the drastically simplified
replying-party-only certificates carrying only an account number and public
key).
Two major characteristics of X9.59 was that it would provide 1) end-to-end
authentication (aka the consumers financial institution would be the one
responsible for performing authentication) and 2) account numbers used in
X9.59 transactions could not be used in unauthenticated transactions.
Some of the '90s digitally signature oriented specifications had
authentication occurring at the internet boundary and stripping off the
certificate (avoiding the extreme certificate payload penalty in the
payment network). The downside was that the party performing the
authentication didn't necessarily have the consumer's interest in mind and
Visa subsequently presented statistics at a ISO standards meeting on the
number of transactions flowing through the network 1) with a flag claiming
to have been digitally signature authenticated and 2) they could prove that
no digital signature technology was ever involved.
Evesdropping, sniffing or harvesting account numbers in the current
infrastructure (at any point in the process, by insiders or outsiders,
traditionally financial exploits have been 90 percent insiders) can result
in fraudulent transactions. As a result, existing account numbers
effectively become a form of shared-secret and need to be protected. With
the X9.59 business rule requiring the account number to only be used in
authenticated transactions, simple harvesting of a X9.59 account number
doesn't result in fraud. Issuing financial institutions then can use
existing business processes that support mapping of different account
numbers to the same account. A discussion of the security proportional to
risk with regard to credit card transactions:
http://www.garlic.com/~lynn//2001h.html#61 Net banking, is it safe?
The issue with the use of SSL for protecting credit card transactions isn't
addressing all or even the major vulnerability to the infrastructure.
Eliminating the account number as a form of shared secret addresses all of
the vulnerabilities, not just the transaction-in-flight vulnerability
addressed by SSL. As a byproduct of addressing all of the shared-secret
related vulnerabilities, it also eliminates the need to use SSL for
protecting the shared secret while being transmitted.
Detailed report of its use in the NACHA debit network trials can be found at
http://internetcouncil.nacha.org/News/news.html
scroll down to "July 23, 2001: Digital Signatures Can Secure ATM Card Payments"
More details of X9.59 standard:
http://www.garlic.com/~lynn/index.html#x959
--
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
More information about the cryptography
mailing list