Maybe It's Snake Oil All the Way Down

[Anne & Lynn Wheeler]

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