Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

Anne & Lynn Wheeler lynn at garlic.com
Tue Dec 23 22:23:07 EST 2003


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 majordomo at metzdowd.com



More information about the cryptography mailing list