At 02:01 PM 12/23/2003 -0500, Rich Salz wrote:
How many years have you been saying this, now? :) How do those modern online environments achieve end-to-end content integrity and privacy? My guess is that they don't; their use of private value-add networks made it unnecessary. If my guess is/was correct, than as more valuable transactions (or regulated data) flow over the commodity Internet, then those things will become important. Make sense? Am I right?

in days before the internet .... it was there was a lot more lo-tech attacks on financial transactions ... and when things like the credit card master file got harvested .... it was uaually pretty obviously an insider job. with the advent of the internet ... not only was it a open, insecure, commodity network .... but a lot of the attached systems were never designed to operate in effectively a hostile environment because of a lot of contributing factors .... there was significant ambiguity when a merchant master file got harvested ... where the attack originated (insider or outsider). minor side thread regarding security proportional to risk with regard to attacks on the merchant master file:
http://www.garlic.com/~lynn/2001h.html#61


during the past ten years there have been some number of technologies for attempting to compensate for just the transport of the "shared-secret" account number in a transaction on an open, hostile network .... aka primarily ssl, minor reference with regard to emerging ssl and the original payment gateway:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3


there has been a lot of threads about how much fraud SSL actually prevented .... since the major consumer retail financial related fraud ... both non-internet, pre-internet, and internet has been bulk harvesting of repositories like a merchant master transaction file (for possibly the same effort to evesdrop packets in flight and extract a single account number .... it might be possible to harvest a merchant transaction file with tens of thousands of account numbers.

so the x9a10 working group was given the requirement for preserving the integrity of the financial infrastructure for all electronic retail transactions. To meet that, the x9.59 standard was defined which basically requires end-to-end authenticated transactions between the consumer and the consumer's financial infrastructure and that account numbers used in authenticated transactions can't be used in non-authenticated transactions. With strong, end-to-end authentication, it is possible to evesdrop a x9.59 transaction, extract the account number and still not be able to execute a fraudulent financial transaction. It is also possible to harvest x9.59 account numbers from merchant transaction files and still not be able to execute fraudulent financial transaction.

Hiding account numbers has been associated with identity theft, since in environment where the transactions aren't authenticated .... the account numbers have to be effectively treated as shared-secrets. The downside is that numerous business processes all along the processing chain require access and use of the account number. Just hiding the account number with SSL did little to address the major vulnerabilities and threats. In effect, the analysis shows that it is effectively impossible to provide necessarily protection for a shared-secret account number, nobody of how deep the earth was blanketed with cryptographic technology. The solution was to change the business process, require end-to-end strong authentication and eliminate the account number as a shared-secret (i.e. knowing the account number is not sufficient for performing a fraudulent transaction). misc. x9.59 standard refs:
http://www.garlic.com/~lynn/index.html#x959


There was actually a couple other issues differentiating internet-based transactions and the VPN environment. The VPN environment was circuit based, it is possible to get service level agreements and utilized technology like modem loop-back diagnostics as part of a bootstrap problem determination procedure. Such an environment has a trouble desk and expects to finish first level problem determination in something like 5 minutes.

One of the last projects my wife and I had done before taking the early out (and doing some consulting for the payment gateway and ec-commerce stuff) was the HA/CMP product .... i.e. high availability/cluster multi-processing.
http://www.garlic.com/~lynn/subtopic.html#hacmp
There is a slight reference in one of the above aadsm5.htm archive posting to
http://www.garlic.com/~lynn/95.html#13
because some of the people in the above meeting had left and joined a client/server startup and were responsible for this thing called a commerce server .... who we then working with on this thing called a payment server for this thing that would be called e-commerce.


In any case, packet-based internet not only is commodity oriented from standpoint of security but also from the standpoint of availability, diagnostics, etc. It was possible to take an ISO8583 financial messages standards manual and repackage the same exact messages into internet packet protocol. However, it is extremely difficult to translate the standard VPN RAS (reliability, availability, serviceability) features into an internet environement. At some point in testing the payment gateway, there was a outage and a call to the trouble/call center. Three hours of manual investigation later, the trouble ticket was closed NTF (no trouble found). Trying to translate VPN-like RAS to an internet environment was much harder task than just about everything else combined (even just inventing problem diagnostic process for the call center).

In any case, there was an extremely large number of issues translating from a VPN environment to an internet environment .... way beyond simple issues like transaction evesdropping.
--
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 [EMAIL PROTECTED]

Reply via email to